VPN: удаленные хосты могут видеть клиента, клиент не может никого связаться: tap0 остается без ответа
Я был на этом для лучшей части дня. Все вроде нормально и действительно так себя ведет (ну, разве что не работает), но где-то должен быть подвох.
Сервер:
- NetgearVPN сервер
- wan: динамический IP
- LAN: 10.0.0.0/24
- IP: 10.0.0.1
Клиент:
- строптивый VPN-клиент (пробовал разные версии)
- lan: 172.16.0.0/16 (gw: 172.16.0.4)
- IP: 172.16.0.59
VPN вызывает интерфейс tap0 (диапазон ip 10.1.0.0/24), туннель установлен, проблем нет. Удаленные хосты могут пинговать и связывать клиента по виртуальному ip (10.1.0.1). Однако клиент не может получить доступ к чему-либо.
После настройки route -n выглядит так:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.16.0.4 0.0.0.0 UG 0 0 0 eth0
10.0.0.0 10.1.0.1 255.255.255.0 UG 0 0 0 tap0
10.1.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0
172.16.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
Не может быть лучше Единственный вид активности (в данном случае ping), который я вижу на интерфейсе tap0, это:
tcpdump -i tap0 -n -X -s0:
16:42:03.494457 ARP, Request who-has 10.0.0.1 tell 172.16.0.59, length 28
0x0000: 0001 0800 0604 0001 36a9 3a07 b95d ac10 ........6.:..]..
0x0010: 003b 0000 0000 0000 0a00 0001 .;..........
16:42:04.491415 ARP, Request who-has 10.0.0.1 tell 172.16.0.59, length 28
0x0000: 0001 0800 0604 0001 36a9 3a07 b95d ac10 ........6.:..]..
0x0010: 003b 0000 0000 0000 0a00 0001 .;..........
16:42:05.491419 ARP, Request who-has 10.0.0.1 tell 172.16.0.59, length 28
0x0000: 0001 0800 0604 0001 36a9 3a07 b95d ac10 ........6.:..]..
0x0010: 003b 0000 0000 0000 0a00 0001 .;..........
16:42:06.508946 ARP, Request who-has 10.0.0.1 tell 172.16.0.59, length 28
0x0000: 0001 0800 0604 0001 36a9 3a07 b95d ac10 ........6.:..]..
0x0010: 003b 0000 0000 0000 0a00 0001
Меня смущает тот факт, что ответ на запрос ARP по IP 172.16.0.59.
Когда удаленные хосты обращаются к клиенту, активность tap0 остается пустой.
Итак, я спрашиваю, где может быть улов? Несовместимость клиент-хост? неправильная конфигурация? Ошибка в клиентском программном обеспечении? Брандмауэр где-то (где?)? Где еще я могу найти журналы и информацию о том, что происходит?
1 ответ
Решено: в /etc/rc.local все еще действуют некоторые правила iptables, связанные с nat, блокирующие интерфейс vpn
Странно, потому что iptables -L ничего не показывал во время выполнения.
Это были компрометирующие правила:
/sbin/iptables -P FORWARD ACCEPT
/sbin/iptables --table nat -A POSTROUTING -o eth0 -j MASQUERADE
После того, как мы попробовали строптивый клиент на Windows и других Debian, все прошло хорошо, поэтому я пошел посмотреть, что не так с текущим. Это стоило мне дней, хотя.