Eu tenho a seguinte configuração de VPN:
+------------+ +------------+ +------------+
| outpost |----------------| kino |----------------| guchuko |
+------------+ +------------+ +------------+
OS: FreeBSD 6.2 OS: Gentoo 2.6.32 OS: Gentoo 2.6.33.3
Keyname: client3 Keyname: server Keyname: client1
eth0: 10.0.1.254 eth0: 203.x.x.x eth0: 192.168.0.6
tun0: 192.168.150.18 tun0: 192.168.150.1 tun0: 192.168.150.10
P-t-P: 192.166.150.17 P-t-P: 192.168.150.2 P-t-P: 192.168.150.9
O Kino é o servidor e tem cliente-para-cliente ativado. Eu estou usando "fragmento 1400" e "mssfix" em todas as três máquinas. Um teste mtu em ambas as conexões é bem sucedido.
Todas as três máquinas têm o encaminhamento de ip ativado, por isso nas caixas do gentoo:
net.ipv4.conf.all.forwarding = 1
E isso na caixa do FreeBSD:
net.inet.ip.forwarding: 1
No diretório "ccd" do servidor, estão os seguintes arquivos:
client1:
iroute 192.168.0.0 255.255.255.0
client3:
iroute 10.0.1.0 255.255.255.0
A configuração do servidor tem estas rotas configuradas:
push "route 192.168.0.0 255.255.255.0"
push "route 10.0.1.0 255.255.255.0"
route 192.168.0.0 255.255.255.0
route 10.0.1.0 255.255.255.0
A tabela de roteamento do Kino é assim:
192.168.150.0 192.168.150.2 255.255.255.0 UG 0 0 0 tun0
10.0.1.0 192.168.150.2 255.255.255.0 UG 0 0 0 tun0
192.168.0.0 192.168.150.2 255.255.255.0 UG 0 0 0 tun0
192.168.150.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
O posto avançado é assim:
192.168.150 192.168.150.17 UGS 0 17 tun0
192.168.0 192.168.150.17 UGS 0 2 tun0
192.168.150.17 192.168.150.18 UH 3 0 tun0
E Guchuko é assim:
192.168.150.0 192.168.150.9 255.255.255.0 UG 0 0 0 tun0
10.0.1.0 192.168.150.9 255.255.255.0 UG 0 0 0 tun0
192.168.150.9 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
Agora, os testes.
Pings de Guchuko para o LAN IP do Outpost funcionam bem, assim como o reverso - pings do Outpost para o IP da LAN de Guchuko. No entanto ...
Pings do Outpost, para uma máquina na LAN da Guchuko funcionam bem:
.(( root@outpost )). (( 06:39 PM )) :: ~ ::
# ping 192.168.0.3
PING 192.168.0.3 (192.168.0.3): 56 data bytes
64 bytes from 192.168.0.3: icmp_seq=0 ttl=63 time=462.641 ms
64 bytes from 192.168.0.3: icmp_seq=1 ttl=63 time=557.909 ms
Mas um ping de Guchuko para uma máquina na LAN do Outpost não:
.(( root@guchuko )). (( 06:43 PM )) :: ~ ::
# ping 10.0.1.253
PING 10.0.1.253 (10.0.1.253) 56(84) bytes of data.
--- 10.0.1.253 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2000ms
O tcpdump de tunch de Guchuko mostra:
18:46:27.716931 IP 192.168.150.10 > 10.0.1.253: ICMP echo request, id 63009, seq 1, length 64
18:46:28.716715 IP 192.168.150.10 > 10.0.1.253: ICMP echo request, id 63009, seq 2, length 64
18:46:29.716714 IP 192.168.150.10 > 10.0.1.253: ICMP echo request, id 63009, seq 3, length 64
O tcpdump do Outpost no tun0 mostra:
18:44:00.333341 IP 192.168.150.10 > 10.0.1.253: ICMP echo request, id 63009, seq 3, length 64
18:44:01.334073 IP 192.168.150.10 > 10.0.1.253: ICMP echo request, id 63009, seq 4, length 64
18:44:02.331849 IP 192.168.150.10 > 10.0.1.253: ICMP echo request, id 63009, seq 5, length 64
O So Outpost está recebendo a solicitação ICMP destinada à máquina em sua sub-rede, mas parece não estar encaminhando-a. O Outpost tem gateway_enable="YES" em seu rc.conf que configura corretamente net.inet.ip.forwarding para 1 como mencionado anteriormente. Até onde sei, isso é tudo o que é necessário para fazer uma caixa do FreeBSD encaminhar pacotes entre interfaces. Há algo mais que eu poderia estar esquecendo? FWIW, ping 10.0.1.253 do Kino tem o mesmo resultado - o tráfego não é encaminhado.
ATUALIZAÇÃO: Descobri que só posso fazer ping de determinados IPs na LAN de Guchuko no Outpost. Do Outpost eu posso pingar 192.168.0.3 e 192.168.0.2, mas 192.168.99 e 192.168.0.4 são inacessíveis. O mesmo comportamento do tcpdump pode ser visto. Acho que isso significa que o problema não pode ser devido ao encaminhamento ou encaminhamento de ip, porque o Outpost pode alcançar ALGUNS hosts na LAN de Guchuko, mas não em outros, e da mesma forma, Guchuko pode alcançar dois hosts na LAN do Outpost, mas não outros. Isso me deixa confuso.