Служба приложений Azure не видит маршрут к VPN.

Содержание

Вопрос или проблема
Ответ или решение
Теория
Пример
Применение

Вопрос или проблема

У меня есть App Service, который использует частные конечные точки и частные ссылки для подключения к экземпляру SQL в той же группе ресурсов. Я также пытаюсь настроить соединение IPsec Tunnel/сайт-к-сайту VPN для подключения App Service к другому сайту за пределами Azure.

У меня есть vnet, который был создан для упомянутого выше подключения App Service к SQL. App Service находится в подсети, названной web, как часть этого подключения.

Чтобы настроить мой IPsec:

Я создал подсеть GatewaySubnet в существующем vnet
Я создал шлюз виртуальной сети в существующем vnet
Я назначил шлюзу виртуальной сети общедоступный IP-ресурс из той же группы ресурсов
Я создал локальный шлюз сети с общедоступным IP и внутренним IP другого сайта как адресное пространство
Я создал соединение в этом шлюзе виртуальной сети типа (сайт-к-сайту/IPsec), используя VNG и LNG с общим ключом
Я создал таблицу маршрутов и связал подсеть web с ней
Я создал маршрут в этой таблице маршрутов, который направляет внутренний IP из настроек локального шлюза сети для перехода к VNG
Я пытался принудительно маршрутизировать App Service, установив WEBSITE_VNET_ROUTE_ALL в 1 в переменных окружения App Service App Settings.

Я установил VnetRouteAll в true для App Service.

Я перезапустил и даже остановил и запустил App Service после всех этих изменений.

Это результаты некоторых команд CLI, которые, как я полагаю, показывают, что все настроено правильно, но App Service не усвоил маршрут.

Я пытался использовать cUrl, tcpping, nslookup из App Service Kudu Powershell и Console, и каждый раз не удавалось найти 10.95.4.51

PS /home/mber> az network vnet subnet show --resource-group myname --vnet-name vn-myname-test --name web --query "{Subnet: name, RouteTable: routeTable.id}"
{
  "RouteTable": "/subscriptions/*********/resourceGroups/myname/providers/Microsoft.Network/routeTables/rt-myname-test",
  "Subnet": "web"
}
PS /home/mber> az network route-table route list --resource-group myname --route-table-name rt-myname-test --query "[].{RouteName: name, AddressPrefix: addressPrefix, NextHopType: nextHopType}"
[
  {
    "AddressPrefix": "10.95.4.51/32",
    "NextHopType": "VirtualNetworkGateway",
    "RouteName": "to-10.95.4.51"
  }
]
PS /home/mber> az network vpn-connection list --resource-group myname --query "[].{VPNConnection: name, Status: connectionStatus, ProvisioningState: provisioningState}"
[
  {
    "ProvisioningState": "Succeeded",
    "Status": null,
    "VPNConnection": "vpn-myname-test"
  }
]
PS /home/mber> az network vpn-connection show --resource-group myname --name vpn-myname-test --query "{Name:name, Status:connectionStatus, ProvisioningState:provisioningState}"
{
  "Name": "vpn-myname-test",
  "ProvisioningState": "Succeeded",
  "Status": "Connected"
}
PS /home/mber> az webapp vnet-integration list --name mynamedev --resource-group myname
[
  {
    "certThumbprint": null,
    "id": "/subscriptions/*********/resourceGroups/myname/providers/Microsoft.Web/sites/mynamedev/virtualNetworkConnections/web",
    "location": "East US 2",
    "name": "web",
    "resourceGroup": "myname",
    "routes": null,
    "type": "Microsoft.Web/sites/virtualNetworkConnections",
    "vnetResourceId": "/subscriptions/*********/resourceGroups/myname/providers/Microsoft.Network/virtualNetworks/vn-myname-test/subnets/web"
  }
]

Ответ или решение

Проблема, с которой вы столкнулись, связана с невозможностью Azure App Service обнаружить маршрут к VPN, несмотря на настройку и интеграцию виртуальных сетей (VNet) и шлюзов. Давайте разберем ситуацию более подробно и предложим возможные решения.

Теория

Использование Azure App Service с частными конечными точками (Private Endpoints) и ссылками (Private Links) обеспечивает безопасное соединение с ресурсами внутри Azure, такими как SQL экземпляры, не раскрывая их в публичный интернет. Однако, при этом иногда возникают сложности при взаимодействии с внешними сайтами через VPN. Причиной этого может быть неправильная конфигурация маршрута или недостаточная поддержка со стороны шлюзов и подсетей.

Пример

В вашем случае вы уже настроили виртуальную сеть (VNet) с несколькими подетями, включая специальную подсеть для шлюза (GatewaySubnet). На этой виртуальной сети также развернуты шлюзы: виртуальный сетевой шлюз (VNG) и локальный сетевой шлюз (LNG), что должно позволить безопасно подключаться к внешним ресурсам через IPsec туннель. Кроме того, создана таблица маршрутов, связанная с подсетью web, в которой расположено ваше приложение. С этим маршрутом вы пытаетесь перенаправить трафик через виртуальный сетевой шлюз к внутреннему IP-адресу внешнего ресурса.

Поскольку вы видите, что состояние VPN-соединения успешно установлено, проблема скорее всего связана с конфигурацией маршрутизации или, возможно, с самим App Service.

Применение

Рассмотрим возможные причины и решения для вашей проблемы:

Проверка конфигурации VNet: Убедитесь, что все элементы вашей конфигурации правильно настроены. Проверьте, что App Service корректно подключен к подсети web и имеет доступ ко всем нужным маршрутным таблицам.
Проверка маршрута и шлюза:
- Убедитесь, что маршрутный таблица корректно настроена для использования Virtual Network Gateway в качестве следующего прыжка. Для этого выполните дополнительные проверки текущих маршрутов.
- Убедитесь в наличии необходимых разрешений на уровне подсети и интерфейсов для передачи пакетов через VPN.
Проверка конфигураций App Service:
- Проверьте правильность установки переменных среды WEBSITE_VNET_ROUTE_ALL. Данная переменная должна быть установлена в 1, что позволяет приложению использовать все маршруты VNet.
- Также убедитесь, что параметры VNetRouteAll правильно установлены, и app service действительно использует все доступные маршруты.
Диагностика связи:
- Используйте средства диагностики на стороне App Service (через Kudu Console) для проверки доступности внешнего IP. Инструменты nslookup, cUrl и tcpping могут помочь в определении, где именно происходит обрыв связи.
- Проверьте настройки VNet-интеграции через az webapp vnet-integration list.
Проверка служб:
- Убедитесь, что не были внесены изменения в другие службы Azure, которые могут ограничивать доступность, такие как Azure Firewall или изменения в политики безопасности сети.
Отладка с Netstat и Traceroute: Хотя Azure App Service может иметь ограничения на выполнение некоторых команд, попробуйте выяснить маршрут следования пакетов до целевого IP.
Логи и Мониторинг: Откройте логи на уровне шлюзов и установите более детальный мониторинг для выявления ошибок или задержек в пакетах.
Обратитесь к поддержке Azure: Если все вышеуказанные шаги не помогли, не стесняйтесь обращаться в поддержку Azure. Бывает, что проблемы возникают на уровне инфраструктуры, и специалисты Azure могут предложить помощь или прояснить ситуацию.

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