У меня следующая конфигурация 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
Kino является сервером, и для него включен клиент-клиент. Я использую «фрагмент 1400» и «mssfix» на всех трех машинах. MTU-тест на обоих соединениях прошел успешно. На всех трех машинах включена переадресация ip на ящиках gentoo:
net.ipv4.conf.all.forwarding = 1
И это в коробке FreeBSD:
net.inet.ip.forwarding: 1
В каталоге ccd сервера находятся следующие файлы:
client1:
iroute 192.168.0.0 255.255.255.0
client3:
iroute 10.0.1.0 255.255.255.0
В конфигурации сервера настроены следующие маршруты:
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
Таблица маршрутизации Kino выглядит так:
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
Форпост такой:
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
А Гучуко такая:
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
А теперь тесты.
Пинги от Гучуко к LAN IP-адресу Outpost работают нормально, как и обратное - пинги от Outpost к LAN IP-адресу Гучуко. Тем не мение...
Пинги от Outpost к машине в LAN Гучуко работают нормально:
.(( 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
Но пинг от Гучуко к машине в локальной сети Outpost не дает:
.(( 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
Tcpdump Гучуко из tun0 показывает:
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
Tcpdump Outpost на tun0 показывает:
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
Итак, Outpost получает ICMP-запрос, предназначенный для машины в его подсети, но, похоже, не пересылает его. Outpost имеет gateway_enable = "YES" в его rc.conf, который правильно устанавливает net.inet.ip.forwarding в 1, как упоминалось ранее. Насколько мне известно, это все, что требуется для того, чтобы ящик FreeBSD пересылал пакеты между интерфейсами. Могу ли я что-то забыть? FWIW, пинг 10.0.1.253 из Kino дает тот же результат - трафик не перенаправляется.
ОБНОВЛЕНИЕ: я обнаружил, что могу пинговать только определенные IP-адреса в локальной сети Гучуко из Outpost. Из Outpost я могу пинговать 192.168.0.3 и 192.168.0.2, но 192.168.99 и 192.168.0.4 недоступны. Можно увидеть то же поведение tcpdump. Я думаю, это означает, что проблема не может быть связана с ipforwarding или маршрутизацией, потому что Outpost может достигать НЕКОТОРЫХ хостов в локальной сети Гучуко, но не других, и аналогично, Гучуко может достигать двух хостов в локальной сети Outpost, но не других. Это меня сбивает с толку.
Я бы проверил две вещи:
Во-первых, проверьте, нет ли брандмауэра или чего-то еще на хостах без пинга, которые питаются icmp.
Во-вторых, проверьте правила маршрутизации на машинах, на которых вы не можете выполнить пинг, чтобы убедиться, что у них есть записи маршрута, которые будут получать ответы обратно на шлюз VPN (либо напрямую, либо через маршрут по умолчанию, который знает, как добраться до шлюза VPN). Snoop / wirehark целевой интерфейс на недоступном узле, чтобы убедиться, что вы можете видеть поступающие запросы и то, куда идут ответы.