Веб-сервер исчезает, когда подключается клиент VPN

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

Симптом: запросы внутрь, ответы наружу через неправильную дверь

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

Подтвердите это, наблюдая, куда уходит ответ, а не наблюдая, как приходит запрос.

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

Два маршрута по умолчанию и одно решение о маршрутизации

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

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

Туннель ведёт себя правильно всё время. Ему сказали нести маршрут по умолчанию, и он делает именно это.

Исправьте обратный путь, не сломав туннель

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

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

Исключение назначения подходит для службы со стабильным публичным адресом, а привязка демона к физическому адресу, а не ко всем адресам, делает это исключение безопаснее. Правило политики, выбирающее таблицу по источнику, удерживает собственные соединения хоста внутри туннеля и одновременно возвращает ответы службы через шлюз WAN. Маскировка ответов на интерфейсе WAN приводит к тому же пути ценой сокрытия адреса клиента из журналов службы. Разовое изменение маршрута по умолчанию — это диагностика, а не конфигурация, потому что клиент переписывает маршруты при каждом переподключении.

ip rule show
ip route get 203.0.113.9 from 192.0.2.44

Когда хост маршрутизирует и для LAN за собой

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

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

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