Ломает ли VPN-клиент на вашем веб-сервере его ответы?

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

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

Симптом: отвечает локально и не снаружи

Внутри сети ответу не нужно пересекать туннель, поэтому страница загружается и служба выглядит здоровой. Снаружи запрос доходит до хоста, а ответ направляется в VPN, где у дальнего конца нет причин его принимать. Браузер видит тайм-аут, а не отказ, и это признак одностороннего пути, а не закрытого порта.

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

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

Что на самом деле сопоставляет селектор источника

В политической маршрутизации Linux правило вроде from 192.168.50.2 сопоставляет пакеты, источником которых является этот адрес. Оно не кодирует тот факт, что пакет продолжает разговор, вошедший через домашний маршрутизатор, и не знает, какой процесс его создал. Адрес в этом примере иллюстративен; замените его на адрес, который ваш хост действительно использует. Относитесь к строке как к утверждению об адресах и ни к чему большему.

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

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

Проверьте обратный путь и трафик, который вы не собирались освобождать

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

ip rule show
ip route show table 100
ip route get 203.0.113.44 from 192.168.50.2
ss -ltnp '( sport = :443 )'

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

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

Решите, насколько узким может быть исключение

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

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

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