Следующий шаг в маршруте VPN: почему шлюз должен быть доступен локально

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

Это руководство охватывает обычный случай: ноутбук на 192.168.20.0/24, шлюз VPN с адресом LAN 192.168.20.5 и удалённая сеть 10.70.0.0/24 за этим шлюзом. Все команды ниже предполагают, что вы на ноутбуке, если не сказано иное.

Два адреса, один маршрут

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

Поэтому первая проверка — не «работает ли шлюз», а «находится ли шлюз на этом звене». Собственная подсеть ноутбука, его запись ARP или соседа и интерфейс в маршруте должны совпадать. Адрес, который существует только внутри 10.70.0.0/24, может быть назначением второго маршрута, но никогда — via первого.

К чему следующий шаг обязывает шлюз

Установка маршрута на ноутбуке решает только первую передачу. Затем шлюзу нужен свой путь: включённая пересылка, туннельный маршрут для 10.70.0.0/24 и любая политика доступа, определяющая, кто может им пользоваться. В Linux это net.ipv4.ip_forward=1 плюс туннельный маршрут; межсетевому экрану перед ним нужно правило, разрешающее пересылаемый поток.

Обратное направление — та часть, которую люди забывают. У удалённой стороны должен быть маршрут обратно в 192.168.20.0/24, либо проект должен транслировать источник ноутбука во что-то, что удалённая сторона знает. Работающий ping со шлюза доказывает, что шлюз достигает удалённой сети; он ничего не говорит о том, переживут ли пакеты ноутбука обратный путь.

Проверьте поиск с того хоста, который отправляет

Спросите ядро, какой следующий шаг оно выберет, и прочитайте интерфейс в ответе:

ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5

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

Затем повторите тест из правильного места. Запрос, созданный на шлюзе, использует собственный адрес источника шлюза, что может скрыть отсутствующий обратный маршрут или политику, разрешающую только определённые источники. Руководство по ip-route разделяет назначение, шлюз и переопределение onlink, и переопределение стоит понять до того, как его использовать.

Не используйте onlink, чтобы подделать доступность

onlink велит ядру пропустить проверку доступности шлюза и всё равно отправить к нему. Оно не создаёт путь, не разрешает ARP для отсутствующего адреса и не заставляет удалённый маршрутизатор отвечать на вашем сегменте Ethernet. Оно законно для шлюзов, которые отвечают, но не находятся в подключённой подсети, и это ловушка, когда его применяют, чтобы заглушить ошибку, которую вы не объяснили.

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

Туннели «точка-точка» — это не Ethernet

Туннельное устройство не делает ARP и часто не имеет осмысленной подсети соседей. Его маршруты часто выглядят как 10.70.0.0/24 dev tun0, вообще без via, потому что партнёр — единственная другая конечная точка. Копирование via в стиле LAN в эту таблицу создаёт маршрут, который ядро может отвергнуть или, что хуже, такой, который указывает на адрес, на который партнёр никогда не отвечает.

Держите две модели в руководстве раздельно: у маршрута LAN есть достижимый шлюз, у туннельного маршрута есть интерфейс и партнёр. WireGuard, OpenVPN и IPsec показывают немного разные формы, поэтому записывайте форму, которую вы действительно использовали, вместо обобщения с одного хоста.

Добавьте, подтвердите, откатите

Всё изменение — три команды и одна проверка, и его следует записать именно в этом порядке:

sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5

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