Почему Azure Point-to-Site VPN не меняет ваш публичный IP
Туннель «точка — сайт» передаёт только маршруты виртуальной сети, поэтому ваш публичный IP остаётся локальным, пока принудительное туннелирование и SNAT брандмауэра не перенесут выход в Azure.
Я подключаю клиент Azure VPN на ноутбуке с Windows, открываю страницу эха адреса и вижу тот же публичный адрес, который выдал мой домашний роутер. Тем временем машина перехода на 10.20.0.4 отвечает, а имя частной конечной точки разрешается, значит туннель не сломан. Шлюз «точка — сайт» делает ровно то, что говорит его конфигурация по умолчанию: передаёт частные префиксы, а всё остальное оставляет на локальном канале. Получение выходного адреса, принадлежащего Azure, — это изменение схемы маршрутизации, а не ремонт.
Что шлюз объявляет по умолчанию
Шлюз передаёт маршруты для адресного пространства виртуальной сети, а также для пиринговых сетей, где разрешена транзитная передача через шлюз, и локальных префиксов, изученных через соединение «сайт — сайт» или BGP. В этом наборе нет 0.0.0.0/0. Ваша операционная система держит маршрут по умолчанию на Wi-Fi или Ethernet, поэтому пакет к публичному API вообще не попадает в туннель.
Адрес, который клиент получает внутри туннеля, — это частная аренда из пула «точка — сайт». Он идентифицирует клиента для ресурсов в VNet; это не адрес, который может увидеть интернет, и он никогда не появится как источник исходящего запроса к API SaaS. Запись в списке разрешений, построенная вокруг этой аренды, работать не может, сколько бы вы ни ждали её появления в журналах поставщика.
Раздельный туннель и принудительное туннелирование рядом
| Split tunnel, the default | Forced tunneling | |
|---|---|---|
| Internet traffic exits through | local ISP or office router | firewall or appliance inside Azure |
| Source address the API sees | your home or office IP | the firewall public IP |
| Inspection and logging in Azure | none | policy rules plus flow logs |
| Ongoing cost | gateway only | gateway, firewall hours, data processing |
| What usually breaks | nothing on the egress path | DNS, on-premises routes, overlapping local ranges |
Только вторая строка меняет адрес, который видит удалённая служба. Всё остальное в той таблице — это затраты и операционная поверхность, которые вы принимаете, когда выход нужно проверять или преобразовывать внутри Azure. Если кто-то просит вас сделать так, чтобы публичный IP изменился, он просит весь правый столбец, а не небольшую правку клиента.
Есть промежуточный вариант, который стоит назвать до того, как что-то перестраивать. Прокси или шлюзовая виртуальная машина внутри VNet даёт контролируемый адрес источника для приложений, которые можно на неё направить, не сдвигая маршрут по умолчанию у клиента. Это сохраняет обычный просмотр локальным и по-прежнему удовлетворяет партнёра, которому нужно только одно прибытие вызова API из Azure. Вариант не работает, когда требование действительно касается всего трафика, потому что всё, что игнорирует настройку прокси, всё равно выходит локально.
Заставьте туннель нести маршрут по умолчанию
На шлюзе виртуальной сети поддерживаемый способ направить весь интернет-трафик клиента в туннель — добавить настраиваемые маршруты в конфигурацию «точка — сайт». Две половины покрывают всё пространство IPv4, и каждая более конкретна, чем локальный маршрут по умолчанию, поэтому клиент предпочитает их, ничего не удаляя:
Set-AzVirtualNetworkGateway -VirtualNetworkGateway GWOBJ -CustomRoute 0.0.0.0/1,128.0.0.0/1Эта строка иллюстративна и неполна для копирования: сначала получите объект шлюза с помощью Get-AzVirtualNetworkGateway и подставьте его вместо GWOBJ, а перед запуском убедитесь, что SKU и модель развёртывания принимают настраиваемые маршруты. Те же префиксы есть на портале на странице конфигурации «точка — сайт», и это более безопасное место, чтобы задать их, если вы ещё не управляете шлюзом скриптом.
Изменение этих префиксов делает пакет клиента недействительным. Скачайте пакет клиента VPN заново и переустановите его, потому что маршруты едут внутри профиля. Клиент, который переподключается со старым профилем, сохраняет старый набор маршрутов, и вы можете потерять час на отладку изменения, которое до него так и не дошло.
В защищённом концентраторе виртуальной WAN эквивалент — маршрут по умолчанию в таблице маршрутов концентратора, связанной со шлюзом «точка — сайт», при этом трафик принимает Azure Firewall в концентраторе. Брандмауэр преобразует соединения в интернет в свои публичные IP-адреса, и именно из этого преобразования берётся новый выходной адрес. Когда у брандмауэра несколько публичных IP, любой из них может появиться как источник, поэтому список разрешений должен содержать все.
Обе схемы выше — IPv4. Два префикса /1 ничего не делают для IPv6, а поддержка IPv6 в «точка — сайт» настолько узкая, что комбинацию стоит проверить, прежде чем обещать паритет.
Проверьте маршрут, затем выход
После переустановки пакета и повторного подключения убедитесь, что клиент действительно установил половины. В Windows команда Get-NetRoute -DestinationPrefix 0.0.0.0/1 и такой же запрос для 128.0.0.0/1 должны указать интерфейс туннеля, а route print показывает оба рядом с вашим исходным маршрутом по умолчанию. В Linux ip route show должен перечислить оба префикса; если нет, профиль их так и не перенёс.
Затем снова проверьте публичный адрес с клиента и прочитайте журнал брандмауэра для того же соединения. Источником должен быть публичный IP брандмауэра с преобразованным портом. Клиент, который по-прежнему выходит локально при наличии обоих маршрутов, означает, что пакеты дошли до Azure и ушли другим путём: маршрут, заданный пользователем, в подсети шлюза, брандмауэр, который сам принудительно туннелирован в локальную сеть, или политика, отбрасывающая поток до преобразования.
Повторно проверьте один частный адресат в той же сессии. Хост перехода, который перестаёт отвечать после изменения, — обычный признак того, что новые префиксы что-то вытеснили: либо более узкий локальный маршрут, который объявлялся раньше, либо разрешение имён, которое теперь идёт к резолверу без пересылки для ваших частных зон.
Когда оставить раздельный туннель в покое
Если цель — только добраться до частного API, частной конечной точки или внутренней страницы администрирования, поведение по умолчанию дешевле и тише. Принудительное туннелирование добавляет часы брандмауэра и расходы на обработку данных, более длинный путь и ещё одно место, где каждый поток клиента может отказать. Оно также захватывает гораздо больше трафика, чем единственный адресат, о котором вы заботились.
Прибегайте к нему, когда требование сформулировано в терминах выхода: партнёр должен видеть фиксированный адрес Azure, безопасность хочет, чтобы соединения журналировались и проверялись, или данные должны уходить через одну контролируемую точку. Даже тогда схема даёт каждому пользователю общий выход, поэтому ответственность по пользователю должна идти от идентичности в приложении, а не от адреса источника.
Прежде чем закрыть изменение, подтвердите четыре вещи: установленный пакет клиента — новый, два маршрута /1 стоят на интерфейсе туннеля, частный адресат всё ещё отвечает, и журнал удалённой службы показывает адрес брандмауэра.