Открытие порта VPN не даёт клиентам доступа к LAN

Туннель поднимается, клиент проходит проверку, но LAN за шлюзом остаётся невидимой. Правило, которое должно было это исправить, разрешает порт VPN и работает ровно так, как записано, потому что оно касается пакетов, адресованных самому шлюзу. Трафик клиента к хосту за шлюзом имеет другой пункт назначения и другую цепочку. Успешный вход не меняет того, какую из двух цепочек проверяет ядро.

Две цепочки, два разных пункта назначения

Судьбу пакета решает то, куда он идёт, а не то, как он пришёл. Трафик на адрес шлюза доставляется локально и оценивается правилами входа. Трафик, который шлюз пересылает дальше, оценивается правилами пересылки. Один и тот же интерфейс туннеля может создавать оба вида пакетов, поэтому одно правило не может закрыть обе задачи.

Весь миф в одном предложении: разрешение слушателя ничего не говорит о разрешении сети за ним. Это два отдельных решения с отдельными доказательствами, и имя интерфейса на обоих их не объединяет.

Что на самом деле разрешает правило слушателя

Пакеты слушателя завершаются в процессе VPN, и именно это позволяет вообще поднять туннель. Страница управления шлюзом и локальный диагностический ответ тоже используют собственный путь входа хоста, поэтому проверка до шлюза проходит, а всё за ним отказывает. Оба результата верны, и ни один не про LAN.

Когда процесс декапсулирует трафик клиента для другого пункта назначения, пакет попадает на путь пересылки и требует разрешения там. Успешная проверка решает, кто такой клиент; она не решает, куда ему можно идти. У двух вопросов разные владельцы, разные журналы и разные сообщения об ошибке.

Проверяйте с клиента, никогда со шлюза

Проверка, созданная на шлюзе, идёт по собственному пути выхода хоста и может пройти, пока путь пересылки закрыт. Начните проверку с клиента и смотрите на оба конца потока.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

Если запрос появляется на tun0, а до пункта назначения ничего не доходит, пакет отбрасывается после прихода, что указывает на правила пересылки или на собственную фильтрацию пункта назначения. Если на tun0 не появляется вообще ничего, клиент даже не отправляет его в туннель, и проблема в маршрутизации на клиенте, а не в политике на шлюзе. Сравните это с запросом, который правильно уходит и ничего не возвращает, это и есть случай обратного пути.

Пересылке нужны три вещи, а не одна

Пересылка в ядре должна быть включена, правило фильтра должно принимать поток, а пункт назначения должен быть достижим с путём для возврата ответа. Если не хватает одного из трёх, тишина с точки зрения клиента одна и та же.

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

Читайте три вывода вместе. Ноль в первом делает остальные два неважными, а политика отказа по умолчанию во втором отбрасывает пакеты клиента, пока собственный трафик шлюза продолжает работать. Третий вывод показывает, почему правило слушателя никогда не было проблемой.

Держите два набора правил отдельно в документации

Запишите правило слушателя и правило пересылаемой службы отдельными строками, с отдельными владельцами и причинами. Когда порт VPN меняется или публикуется новая служба, это разделение не позволяет одному изменению молча расширить другое.

Вместо того чтобы считать каждого прошедшего проверку партнёра доверенным членом LAN, используйте узкие правила для тех диапазонов клиентов и служб, которым они нужны. Заметки о пересылке StrongSwan описывают сторону обратного маршрута и трансляции той же границы, что снова является третьим решением.

Наконец, держите слои прямыми, когда пользователю отказывают. Если запрос доходит до хоста, а приложение отклоняет учётную запись, исправляйте разрешение приложения на этом слое; расширение пересылки не может выдать учётные данные для общего доступа к файлам и расширит доступ всем остальным, кто успешно подключается.