Azure UDR do prehoda VPN: en cilj, ne ves izhodni promet

Dodate uporabniško določeno pot za eno zunanjo predpono, jo usmerite na prehod VPN in promet še vedno odhaja po internetni poti Azure. Ali pa odhaja pravilno in odgovor se nikoli ne vrne. Oba izida izhajata iz iste napake: obravnavati naslednji skok v Azure kot celotno zasnovo. Tabela poti odloča le, kateri izhod paket zavzame znotraj Azure. Kaj se z njim zgodi po tunelu in kako se odgovor vrne, je druga polovica, ki jo morate zgraditi.

Naslednji skok je prehod, ne IP naprave

UDR pošlje ustrezno predpono tipu naslednjega skoka, VirtualNetworkGateway pa je tip, ne naslov. Ljudje prilepijo zasebni IP prehoda v pot VirtualAppliance in se nato sprašujejo, zakaj se nič ne ujema, ker ta tip pričakuje omrežno kartico ali notranji razporejevalnik obremenitve. Microsoftova dokumentacija o usmerjanju tudi omejuje naslednji skok prehoda na virtualno omrežje, katerega prehod je prehod VPN. ExpressRoute, Route Server in zvezdišče Virtual WAN se s to možnostjo ne naslavljajo.

Preverite, kaj ima virtualno omrežje v resnici, preden napišete pot. Če zasnova usmerja skozi zvezdišče, pot pripada lastniku usmerjanja zvezdišča, ne kraku, ki ga urejate.

Preberite veljavno pot, preden karkoli spremenite

Azure združi sistemske poti, predpone, naučene prek BGP, in UDR v veljavno tabelo poti za vsako omrežno kartico, in najdaljša ujemajoča se predpona zmaga ne glede na izvor. Za isto predpono UDR premaga pot BGP. Ta vrstni red je razlog, da lahko zastarela UDR iz prejšnjega poskusa tiho prepiše predpono, ki ste jo pravkar spoznali skozi tunel.

Najprej poglejte veljavno tabelo, nato se odločite, ali pot dodajate ali jo zamenjujete:

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

Preberite tudi stolpec vira, ne le predpone. Pot s pravilno predpono in napačnim virom vam pove, kateri objekt urediti, in vas obvaruje pred dodajanjem druge poti, ki izgubi proti prvi.

Napišite pot glede na resnično predpono in podomrežje

Uporabite resnično predpono cilja, vzetega iz storitve, ki jo dejansko dosegate, namesto javnega obsega, kopiranega iz objave na forumu. Začnite z eno odobreno storitvijo, preden razmislite o privzeti poti, ki premakne ves izhodni promet. Nato pripnite tabelo poti na podomrežje delovne obremenitve. Podomrežje prehoda ima svoje zahteve, in pripenjanje vaše tabele tja pokvari prehod, namesto da bi usmerjalo obremenitev.

Ustvarite pot, nato povežite tabelo s podomrežjem, ki gosti delovno obremenitev:

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

Pomembno je tudi širjenje. Če je na tej tabeli omogočeno širjenje BGP, se naučene predpone pojavijo ob vaših, in bolj specifična naučena predpona lahko premaga širšo UDR. Širjenje onemogočite le, ko želite, da je nabor UDR merodajen za to podomrežje.

Dokončajte lokalno polovico, sicer tok tam umre

Lokalni prehod mora sprejeti vir iz Azure, ga posredovati cilju in dovoliti aplikacijo. Njegova nadaljnja pot je lahko internetni izhod ali drug zasebni skok, vendar ta odločitev pripada načrtu, ne tabeli poti Azure. Običajna napaka je vrnitev. Internetni cilj ne bo usmerjal zasebnega vira Azure nazaj k vam, zato odgovor odide na svoj privzeti prehod in umre, ali pa sploh ne odide.

Dve zasnovi to rešujeta in nista zamenljivi. Prevedite vir na izhodu, da cilj odgovori na javni naslov, ki ga ima lokalno omrežje. Ali ohranite vir in zgradite usmerjen povratni odnos, da se odgovori vračajo skozi tunel. Izberite eno in zapišite, kateri naslov bo aplikacija videla.

Izbirniki in seznami dovoljenih so ločeni od vsega tega. Izbira naslednjega skoka Azure ne razširi izbirnikov prometa VPN in ne spremeni seznama dovoljenih virov zunanje storitve.

Preverite z virom, ki ga vidi cilj

Pošljite zahtevo iz resnične delovne obremenitve, ne iz preskočnega gostitelja v drugem podomrežju, nato preberite izvorni naslov, ki ga je cilj opazil. Ta ena vrednost vam pove, katera od dveh povratnih zasnov je vzpostavljena. Nato preverite pot odgovora in potrdite, da običajen upravljalni promet do VM še deluje, ker privzeta pot, dodana po pomoti, se pokaže kot prekinjena seja SSH veliko prej, kot se pokaže kot pokvarjena aplikacija.

Tranzit prek izbrane predpone je veliko ožja sprememba kot vsiljeno tuneliranje. Ohranite jo ozko in razveljavitev je brisanje ene poti.