[FUG-BR] Problema com openvn
Mario Lobo
lobo em bsd.com.br
Quinta Julho 24 11:58:46 BRT 2014
Ale a todos.
Tenho o seguinte cenário:
LANa <--> FBSD-GW <--> INTERNET <--> OPENVPN SRV <--> LANb
Usando o openvpn client tanto numa WS da LANa como no FBSD-GW funciona
beleza.
Minha idea é rodar o openvpn client no FBSD-GW e usar a tun0 como gateway
da LANa para a LANb.
Log do FBSD-GW openvpn:
Thu Jul 24 08:37:47 2014 TUN/TAP device /dev/tun0 opened
Thu Jul 24 08:37:47 2014 do_ifconfig, tt->ipv6=0,
tt->did_ifconfig_ipv6_setup=0
Thu Jul 24 08:37:47 2014 /sbin/ifconfig tun0 172.10.5.229 172.10.5.230 mtu
1500 netmask 255.255.255.255 up
Thu Jul 24 08:37:49 2014 /sbin/route add -net 10.10.0.0 172.10.5.230
255.255.252.0
add net 10.10.0.0: gateway 172.10.5.230
Thu Jul 24 08:37:49 2014 /sbin/route add -net 172.10.2.44 172.10.5.230
255.255.255.255
add net 172.10.2.44: gateway 172.10.5.230
Thu Jul 24 08:37:49 2014 /sbin/route add -net 172.10.5.1 172.10.5.230
255.255.255.255
add net 172.10.5.1: gateway 172.10.5.230
Thu Jul 24 08:37:49 2014 /sbin/route add -net 172.10.3.0 172.10.5.230
255.255.255.240
add net 172.10.3.0: gateway 172.10.5.230
Thu Jul 24 08:37:49 2014 /sbin/route add -net 172.10.2.0 172.10.5.230
255.255.255.192
add net 172.10.2.0: gateway 172.10.5.230
Thu Jul 24 08:37:49 2014 /sbin/route add -net 172.10.1.0 172.10.5.230
255.255.255.240
add net 172.10.1.0: gateway 172.10.5.230
Thu Jul 24 08:37:49 2014 Initialization Sequence Completed
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
options=80000<LINKSTATE>
inet 172.10.5.229 --> 172.10.5.230 netmask 0xffffffff
Opened by PID 51795
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 187.23.102.129 UGS 0 23469757 sk0
10.10.0.0/22 172.10.5.230 UGS 0 0 tun0
10.10.1.0/24 link#6 U 0 5158857 re1
10.10.1.254 link#6 UHS 0 0 lo0
172.10.1.0/28 172.10.5.230 UGS 0 11 tun0
172.10.2.0/26 172.10.5.230 UGS 0 29 tun0
172.10.2.44/32 172.10.5.230 UGS 0 0 tun0
172.10.3.0/28 172.10.5.230 UGS 0 0 tun0
172.10.5.1/32 172.10.5.230 UGS 0 0 tun0
172.10.5.229 link#11 UHS 0 0 lo0
172.10.5.230 link#11 UH 0 0 tun0
172.16.3.0/24 link#2 U 0 42161366 re0
172.16.3.1 link#2 UHS 0 0 lo0
fib 1
192.168.0.0/24 link#5 U 0 1 sk1
192.168.0.20 link#5 UHS 0 0 lo0
fib 0
187.23.102.128/29 link#4 U 0 0 sk0
187.23.102.130 link#4 UHS 0 3621 lo0
OBS - O FBSD-GW tem 2 fibs e o openvpn client roda na fib0,
que é a fib default, e tambem o porque da regra pass esta sem route-to. Há
tambem 2 LAN nele (re0 e re1).
Ping do FBSD-GW para um servidor na LANb:
[~]>ping 172.10.2.28
PING 172.10.2.28 (172.10.2.28): 56 data bytes
64 bytes from 172.10.2.28: icmp_seq=0 ttl=127 time=201.900 ms
64 bytes from 172.10.2.28: icmp_seq=1 ttl=127 time=499.521 ms
64 bytes from 172.10.2.28: icmp_seq=2 ttl=127 time=259.940 ms
Conexão do FBSD-GW para um servidor na LANb:
[~]>telnet 172.10.1.7 3389
Trying 172.10.1.7...
Connected to adsl-172-10-1-7.dsl.sndg02.sbcglobal.net.
Escape character is '^]'.
Para isso, adicionei o seguinte ao pf.conf:
nat on tun0 from ! (tun0) to any -> (tun0) port 1024:65535
pass log quick on tun0 all
OBS -- Esta regra de pass é a numero 0 !!
Aqui um ping de uma WS da LANa para um servidor LANb:
[~]>ping 172.10.1.7
PING 172.10.1.7 (172.10.1.7): 56 data bytes
64 bytes from 172.10.1.7: icmp_seq=0 ttl=126 time=138.295 ms
64 bytes from 172.10.1.7: icmp_seq=1 ttl=126 time=108.962 ms
64 bytes from 172.10.1.7: icmp_seq=2 ttl=126 time=284.854 ms
PING 172.10.2.28 (172.10.2.28): 56 data bytes
64 bytes from 172.10.2.28: icmp_seq=0 ttl=126 time=280.377 ms
64 bytes from 172.10.2.28: icmp_seq=1 ttl=126 time=207.054 ms
64 bytes from 172.10.2.28: icmp_seq=2 ttl=126 time=397.242 ms
E um tcpdump do FBSD-GW:
[~]>tcpdump -i tun0 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type NULL (BSD loopback), capture size 96 bytes
08:48:09.470985 IP 172.10.5.229 > 172.10.1.7: ICMP echo request, id 56407,
seq 0, length 64
08:48:09.609126 IP 172.10.1.7 > 172.10.5.229: ICMP echo reply, id 56407,
seq 0, length 64
08:48:10.484599 IP 172.10.5.229 > 172.10.1.7: ICMP echo request, id 56407,
seq 1, length 64
08:48:10.593410 IP 172.10.1.7 > 172.10.5.229: ICMP echo reply, id 56407,
seq 1, length 64
08:48:11.486604 IP 172.10.5.229 > 172.10.1.7: ICMP echo request, id 56407,
seq 2, length 64
08:48:11.771323 IP 172.10.1.7 > 172.10.5.229: ICMP echo reply, id 56407,
seq 2, length 64
08:50:36.861807 IP 172.10.5.229 > 172.10.2.28: ICMP echo request, id 52398,
seq 0, length 64
08:50:37.142004 IP 172.10.2.28 > 172.10.5.229: ICMP echo reply, id 52398,
seq 0, length 64
08:50:37.880531 IP 172.10.5.229 > 172.10.2.28: ICMP echo request, id 52398,
seq 1, length 64
08:50:38.087434 IP 172.10.2.28 > 172.10.5.229: ICMP echo reply, id 52398,
seq 1, length 64
08:50:38.882218 IP 172.10.5.229 > 172.10.2.28: ICMP echo request, id 52398,
seq 2, length 64
08:50:39.279326 IP 172.10.2.28 > 172.10.5.229: ICMP echo reply, id 52398,
seq 2, length 64
Como podem ver, o nat ta funcionando e o pacote encontra o caminho de volta
para a LANa WS.
Agora, O PROBLEMA:
Ping é a única coisa que funciona !
Qualquer outro tipo de conexão sequer toca na tun0 do FBSD-GW!!
Tentativa de conexão de uma LANa WS (172.16.3.40) para um servidor da LANb:
[~]>telnet 172.10.1.7 3389
Trying 172.10.1.7...
Dump da iface LANa do FBSD-GW :
[~]>tcpdump -i re0 -n host 172.16.3.40 and port 3389
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on re0, link-type EN10MB (Ethernet), capture size 96 bytes
08:58:13.945180 IP 172.16.3.40.11942 > 172.10.1.7.3389: Flags [S], seq
2976879078, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 3358365
ecr 0], length 0
08:58:16.952340 IP 172.16.3.40.11942 > 172.10.1.7.3389: Flags [S], seq
2976879078, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 3361373
ecr 0], length 0
08:58:20.155346 IP 172.16.3.40.11942 > 172.10.1.7.3389: Flags [S], seq
2976879078, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 3364576
ecr 0], length 0
Dump da iface tun0 do FBSD-GW :
[~]>tcpdump -i tun0 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type NULL (BSD loopback), capture size 96 bytes
SILENCIO MORTAL !!
Não consigo entender porque um pacote ping acha o seu caminho de volta para
a LANa WS mas nenhum outro consegue !!
Já estou a 3 dias pesquisando, ja tentei tudo que é forma de
nat/route-to/replay-to que eu podia imaginar mas nenhuma delas, que não a
forma abaixo, sequer mantem o ping funcionando!
nat on tun0 from ! (tun0) to any -> (tun0)
pass log quick on tun0 all
Já esgotei meu conhecimento tentando resolver isso e não consigo.
Alguem poderia me dar uma luz?
Obrigado,
--
Mario Lobo
http://www.mallavoodoo.com.br
FreeBSD since version 2.2.8 [not Pro-Audio.... YET!!] (99,7% winfoes FREE)
Mais detalhes sobre a lista de discussão freebsd