Назад | Перейти на главную страницу

VPN: удаленные хосты могут видеть клиента, клиент не может связаться ни с кем: tap0 молчит

Я был на этом большую часть дня. Вроде все нормально, и действительно так себя ведет (ну разве что не работает), но где-то должна быть загвоздка.

Сервер:

Клиент:

VPN открывает интерфейс tap0 (диапазон ip 10.1.0.0/24), туннель установлен, никаких проблем. Удаленные хосты могут пинговать и ssh клиенту по его виртуальному 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 остается пустой.

Итак, я спрашиваю, где может быть подвох? Несовместимость клиент-хост? неправильная конфигурация? Ошибка в клиентском программном обеспечении? Брандмауэр где-нибудь (где?)? Где еще я мог бы искать журналы и информацию о том, что происходит?

Решено: в /etc/rc.local все еще действуют некоторые правила iptables, связанные с nat, блокирующие интерфейс vpn

Странно, потому что iptables -L ничего не показывал во время выполнения.

Это были инкриминирующие правила: 

/sbin/iptables -P FORWARD ACCEPT 
/sbin/iptables --table nat -A POSTROUTING -o eth0 -j MASQUERADE

После опробования клиента shrew на windows и других debian все прошло хорошо, поэтому я пошел посмотреть, что не так на текущем. Но это стоило мне дней.