Azure UDR ka VPN гејтвеју: једно одредиште, а не сав излазни саобраћај

Усмерите један Azure префикс на VPN гејтвеј без премештања целог излазног саобраћаја. Прочитајте ефективне руте, повежите подмрежу оптерећења и довршите повратну путању.

Додајете кориснички дефинисану руту за један спољашњи префикс, усмеравате је на VPN гејтвеј и саобраћај и даље излази преко Azure интернет путање. Или излази исправно и одговор се никада не враћа. Оба исхода долазе из исте грешке: третирања Azure следећег скока као целокупног дизајна. Табела рута одлучује само који излаз пакет узима унутар Azure. Шта се са њим дешава после тунела и како се одговор враћа друга је половина коју морате изградити.

Следећи скок је гејтвеј, а не IP адреса уређаја

UDR шаље одговарајући префикс типу следећег скока, а VirtualNetworkGateway је тип, не адреса. Људи налепе приватну IP адресу гејтвеја у VirtualAppliance руту и онда се питају зашто ништа не одговара, јер тај тип очекује NIC или интерни балансер оптерећења. Microsoft документација о рутирању такође ограничава гејтвеј следећи скок на виртуелну мрежу чији је гејтвеј VPN гејтвеј. ExpressRoute, Route Server и Virtual WAN чвориште се не адресирају том опцијом.

Проверите шта виртуелна мрежа заиста има пре него што напишете руту. Ако дизајн рутира кроз чвориште, рута припада власнику рутирања чворишта, а не споку који случајно уређујете.

Прочитајте ефективну руту пре било какве измене

Azure комбинује системске руте, префиксе научене преко BGP-а и UDR-ове у ефективну табелу рута по NIC-у, а најдужи одговарајући префикс побеђује без обзира одакле долази. За исти префикс UDR побеђује BGP руту. Тај поредак је разлог зашто застарео UDR из ранијег експеримента може тихо надјачати префикс који сте управо научили кроз тунел.

Прво погледајте ефективну табелу, па одлучите да ли додајете руту или је замењујете:

az network nic show-effective-route-table \
  --resource-group rg-net --name vm-web-nic -o table

Читајте и колону извора, не само префикс. Рута са исправним префиксом и погрешним извором каже вам који објекат уредити и спашава вас од додавања друге руте која губи од прве.

Напишите руту према стварном префиксу и подмрежи

Користите стварни префикс одредишта, узет из услуге до које заиста долазите, уместо јавног опсега копираног са форумске објаве. Почните са једном одобреном услугом пре него што размотрите подразумевану руту која премешта сав излазни саобраћај. Затим прикачите табелу рута на подмрежу радног оптерећења. Гејтвеј подмрежа има своје захтеве, а прикачињање ваше табеле тамо квари гејтвеј уместо да усмерава оптерећење.

Креирајте руту, затим повежите табелу са подмрежом која хостује оптерећење:

az network route-table route create --resource-group rg-net --route-table-name rt-egress \
  --name to-partner --address-prefix 203.0.113.0/24 --next-hop-type VirtualNetworkGateway
az network vnet subnet update --resource-group rg-net --vnet-name vnet-app \
  --name snet-web --route-table rt-egress

И пропагација је важна. Уз омогућену BGP пропагацију на тој табели, научени префикси појављују се уз оне које сте написали, а специфичнији научени префикс може победити шири UDR. Онемогућите пропагацију само када желите да скуп UDR-ова буде меродаван за ту подмрежу.

Довршите локалну половину или ток умире тамо

Локални гејтвеј мора прихватити Azure извор, проследити га одредишту и дозволити апликацију. Његова даља путања може бити интернет излаз или други приватни скок, али та одлука припада плану, а не Azure табели рута. Уобичајени неуспех је повратак. Интернет одредиште неће рутирати приватни Azure извор назад до вас, па одговор одлази на сопствени подразумевани гејтвеј и умире, или никада не излази.

Два дизајна то решавају и нису заменљиви. Преведите извор на излазу, тако да одредиште одговара на јавну адресу коју поседује локална мрежа. Или сачувајте извор и изградите рутирану повратну везу да се одговори враћају кроз тунел. Одаберите једно и запишите коју ће адресу апликација видети.

Селектори и листе дозвола одвојени су од свега овога. Избор Azure следећег скока не проширује VPN селекторе саобраћаја и не мења листу дозвољених извора спољне услуге.

Проверите према извору који одредиште види

Пошаљите захтев са стварног радног оптерећења, а не са прескочног хоста у другој подмрежи, затим прочитајте изворну адресу коју је одредиште приметило. Та једна вредност говори који је од два повратна дизајна на снази. Затим проверите повратну путању и потврдите да обичан управљачки саобраћај до VM-а још ради, јер подразумевана рута додата случајно покаже се као прекинута SSH сесија много пре него као покварена апликација.

Транзит преко изабраног префикса много је ужа промена од присилног тунелирања. Држите га уским и враћање је брисање једне руте.

Повезани чланци