Какой пакет должна сопоставлять политика VPN с двумя WAN?

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

Назовите два разговора

Представьте удалённого сотрудника, подключённого к офисному шлюзу, который открывает HTTPS к внутреннему серверу приложений. В линии два независимых разговора, и на каждом конце у них разные адреса. Внешний разговор идёт между двумя конечными точками VPN: от адреса шлюза к адресу партнёра, с тем протоколом и портом, которые согласовало развёртывание. Внутренний разговор идёт от адреса, выданного клиенту, к адресу сервера приложений на порту 443.

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

Найдите, где ваша политика действительно видит пакет

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

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

Подтвердите согласованный транспорт

Для IPsec, инкапсулированного в UDP, RFC 3948 помещает ESP внутрь UDP и использует маркер, не являющийся ESP, чтобы IKE оставался различимым на общем порту. Обычный ESP — это протокол IP, а не порт TCP или UDP, поэтому правило межсетевого экрана, написанное по номеру порта, вообще не совпадёт с ним. Это различие решает, нужна ли вашей политике WAN правило UDP, правило протокола или и то и другое.

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

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

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

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

Проверьте оба уровня двумя записями

Одна запись на интерфейсе WAN и одна внутри туннеля решают вопрос быстрее любого сравнения конфигураций. Запустите их со шлюза, пока одобренный клиент выполняет один запрос, и сохраните оба файла.

sudo tcpdump -ni wan1 'udp port 4500' -c 20
sudo tcpdump -ni tun0 'tcp port 443 and host 203.0.113.10' -c 20
ip route get 203.0.113.10 from 10.8.0.6

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