Два публичных IP на одной Azure VPN VM: какой за что отвечает

Два публичных IP на одной Azure VPN VM создают ожидание, которое редко оправдывается: адрес, к которому подключаются клиенты, будет и адресом, который видят сайты. Этот результат дают три независимых решения, и только первое касается слушателя туннеля. Второе — это источник в госте для перенаправляемого клиентского трафика, а третье — метод выхода Azure, применяемый к этому источнику. Измените одно, и два других останутся на месте, поэтому решайте каждое явно.

Решение 1: где заканчивается туннель

Публичный IP Azure связан с конфигурацией частного IP на NIC; это не адрес, который вы добавляете внутри гостевой операционной системы. Читайте сопоставление, а не предполагайте его: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. Какой бы частный адрес ни вернул этот запрос, именно его гость и должен фактически иметь.

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

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

Решение 2: какой источник использует перенаправленный клиент

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

Узкое правило SNAT может выбрать частный источник гостя, но не может отменить последующую трансляцию Azure. Выбирайте SNAT, когда нужна ответственность по каждому клиенту внутри VM; откажитесь от него, когда проект выхода подсети уже даёт стабильный публичный источник и вторая трансляция лишь добавила бы состояние.

Решение 3: какой метод выхода Azure побеждает

Microsoft документируетпорядок приоритета исходящего трафика: применимый маршрут к устройству или шлюзу имеет приоритет, а подключение подсети через NAT Gateway имеет приоритет над публичным IP уровня экземпляра на соответствующем пути. Именно поэтому трансляция в 10.20.0.5 не доказывает, что сайт увидит 198.51.100.20. Читайте действующую таблицу маршрутов, связь с NAT Gateway и публичный IP NIC вместе, прежде чем принять проект выхода.

Держитепараметр пересылки NIC в Azureотдельно от пересылки в Linux. Флаг облака разрешает пакеты, источник или назначение которых не назначены NIC; он не включает net.ipv4.ip_forward, и гостевая настройка не даёт разрешения облака.

У сокета туннеля своё решение об источнике

Address WireGuard под wg-quick назначает адрес интерфейсу WireGuard; это не инструкция внешней привязки UDP. Источник зашифрованного сокета следует таблице маршрутов, поэтому политический маршрут или второй маршрут по умолчанию может переместить его, не затрагивая адрес интерфейса.OpenVPN: опция local и UDP multihome ведут себя так же: они касаются слушателя и его ответов, а не интернет-источника каждого перенаправленного клиента.

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

Что принимать и в каком порядке

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

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