Почему маршрут к хосту /32 сохраняет доступность конечной точки VPN

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

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

Один адрес, одна запись в таблице

Маршрут к хосту IPv4 несёт префикс /32, а маршрут к хосту IPv6 — /128, то есть запись может совпасть ровно с одним адресом назначения. Больше в таблице ничего не двигается: покрывающая подсеть и маршрут по умолчанию остаются там, где были. Узкая запись выигрывает для этого адреса потому, что её префикс длиннее, а не потому, что её добавили позже.

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

Читайте запись от клиента наружу

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

ip route get 203.0.113.25
ip -6 route get 2001:db8:4::25
ip route show | grep -F 203.0.113.25
Find-NetRoute -RemoteIPAddress 203.0.113.25

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

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

Исключение конечной точки и ловушка рекурсии

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

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

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

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

ip route get 203.0.113.25
sudo nft list ruleset | grep -A 4 'chain output'
curl -sS --max-time 8 -o /dev/null -w '%{remote_ip}
' https://app.example.net

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

Удаляйте записи, которые больше не соответствуют реальному назначению, и отмечайте те, что оставляете. Необъяснённый /32 через три месяца неотличим от ошибки, и следующий человек удалит его, не зная, что от него зависело.

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