Расширение сайта VPN: следуйте обратному маршруту за шлюзом

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

Дальний шлюз — это конечная точка шифрования

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

Нарисуйте путь из трёх частей: филиал к ближнему шлюзу, ближний к дальнему, дальний шлюз к приложению. У каждой части свой владелец и свой режим отказа.

Прочитайте оба направления политики туннеля

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

Записывайте источник и назначение как адреса, а не как названия сайтов. Неоднозначность здесь позже всплывёт как озадачивающая асимметрия.

Добавьте маршрут вперёд и подтвердите допуск

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

ip route get 10.30.5.10 from 10.10.1.50
traceroute -n -s 10.10.1.50 10.30.5.10

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

Проверьте из филиала, затем повторно проверьте старый путь

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

curl -sS -m 5 http://10.30.5.10:8080/health
ping -c 3 10.20.1.1

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

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