VPN между сайтами работает только в одну сторону: две разные неисправности

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

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

Это различие определяет, какие команды стоит выполнять.

Две неисправности, которые выглядят одинаково

В первом случае хост B отправляет SYN на A, и ничего не возвращается. Во втором хост A успешно открывает сеанс, и ответ исчезает на обратном пути. Оба пользователя говорят, что связь односторонняя, и оба описывают исчезнувший пакет, поэтому само описание не может их различить.

Спросите, какая сторона начала неудачную попытку. Этот единственный факт убирает половину возможных причин.

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

Первый случай: нет обратного пути

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

Проверьте адрес, который получатель действительно видит после трансляции, и обратный маршрут именно для этого адреса, а не для исходной подсети.

Второй случай: политика этого никогда не разрешала

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

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

Сравните до и после на одних и тех же хостах

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

tcpdump -ni any host 10.20.30.40 and port 445
conntrack -L | grep 10.20.30.40
ip route get 10.20.30.40
swanctl --list-sas

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

После исправления повторите тот же тест с того же хоста и подтвердите, что посторонний доступ по-прежнему запрещён. Статус туннеля “established” сам по себе не подтверждает ни один из двух выводов.

Похожие статьи