Почему виртуальная машина Azure с VPN-устройством теряет обратный путь
VPN-устройству в виртуальной машине Azure нужны согласованные UDR, флаг пересылки сетевой карты и политика гостевой системы. Проследите один запрос филиала через все три.
Виртуальная машина Azure, на которой работает VPN-устройство, находится внутри двух независимых систем принятия решений. Azure решает, откуда пакет покидает подсеть, используя таблицы маршрутов и настройку пересылки сетевой карты. Собственная операционная система устройства решает, передавать ли расшифрованный пакет дальше. Туннель, который поднимается безупречно, всё равно может отказать во второй системе, и именно там останавливается большинство таких развёртываний.
Три владельца одного пути
Возьмите сеть филиала 192.168.50.0/24 и подсеть рабочей нагрузки 10.0.10.0/24, а устройство находится по адресу 10.0.0.4 в собственной подсети. Один запрос затрагивает три отдельные конфигурации.
| Decision | Configured in | How it fails |
|---|---|---|
| Where the workload subnet sends branch traffic | Azure route table entry | Traffic leaves the subnet and never reaches the appliance |
| Whether a NIC may accept traffic not addressed to it | Azure NIC IP forwarding | Packets arrive and disappear at the interface |
| Whether the guest forwards decrypted traffic | Guest OS or vendor appliance policy | Tunnel is up, workload is unreachable |
| Whether the workload accepts the source | NSG and service policy | Requests delivered, replies refused |
Каждой строкой в большинстве организаций владеет отдельная команда, поэтому эта неисправность обычно приходит как три заявки вместо одной.
Маршрут, который указывает на устройство
Свяжите таблицу маршрутов с подсетью рабочей нагрузки и задайте префиксу филиала следующий переход типа Virtual appliance с 10.0.0.4 в качестве адреса. Используйте доступный частный адрес устройства, никогда его публичную точку входа VPN. Следующий переход должен быть адресом, до которого подсеть рабочей нагрузки уже может добраться. Оставьте остальную маршрутизацию рабочей нагрузки в покое, если вы сознательно не решили заменить маршрут по умолчанию.
Держите устройство в его собственной подсети и убедитесь, что маршрут, отправляющий трафик филиала на устройство, не перехватывает и собственный исходящий путь устройства. Такая петля выглядит как здоровый туннель без ответов, и это крайне неприятно отлаживать в 2 часа ночи.
Флаг сетевой карты, который все забывают
В Azure есть настройка пересылки IP для каждой сетевой карты, и по умолчанию она выключена. Она существует потому, что пересылающая карта получает пакеты, адресованные чему-то другому, и тихое отбрасывание их — безопасное значение по умолчанию для всех остальных.
az network nic update --resource-group rg-net --name appliance-nic --ip-forwarding true включает её для одного интерфейса. Руководство Microsoft по пересылке на сетевой карте требует этой настройки на каждой подключённой карте, которая пересылает трафик, поэтому устройству с одной картой она всё равно нужна на этой карте.
Флаг — не маршрут и не правило брандмауэра. Его включение даёт разрешение и ничего больше.
Что гостевая система делает с расшифрованным пакетом
Когда туннель завершается, собственный стек устройства принимает следующее решение. В гостевой системе Linux пересылка IPv4 — это настройка времени выполнения, и sysctl -w net.ipv4.ip_forward=1 она держится до следующей загрузки. Сохраните её в файле в /etc/sysctl.d/ вместо этого. У устройства производителя есть свой эквивалент, а инструкции для Linux, вставленные в платформу производителя, обычно не делают вообще ничего.
Политика брандмауэра гостя снова отдельная, как и группа сетевой безопасности рабочей нагрузки. Разрешение UDP 500 и 4500 к публичному адресу виртуальной машины защищает туннель; оно ничего не говорит о том, может ли расшифрованный запрос филиала добраться до порта рабочей нагрузки.
Проследите один запрос и его ответ
Выберите один разрешённый поток и проследите его от начала до конца. Филиалу нужен маршрут для 10.0.10.0/24 через подключение к площадке, устройству нужен путь доставки к подсети рабочей нагрузки, а подсети рабочей нагрузки нужен обратный маршрут к филиалу.
Решите заранее, сохраняет ли проект адрес источника филиала или транслирует его. NAT меняет то, что видит рабочая нагрузка, поэтому её правила доступа должны описывать модель, которую вы действительно выбрали, а не предполагаемый адрес шлюза.
Успешное рукопожатие доказывает одно звено этой цепочки. Путь завершён, когда ответ возвращается через то же устройство и собственная политика рабочей нагрузки это разрешает.