Azure UDR VPN-lüüsile: üks sihtkoht, mitte kogu väljaminev liiklus

Lisate ühe välise prefiksi jaoks kasutaja määratud marsruudi, suunate selle VPN-lüüsile ja liiklus väljub ikkagi Azure'i internetiteekonna kaudu. Või väljub õigesti ja vastus ei tule kunagi tagasi. Mõlemad tulemused tulenevad samast veast: käsitleda Azure'i järgmist hüpet kogu disainina. Marsruuditabel otsustab ainult selle, millise väljapääsu pakett Azure'i sees võtab. Mis juhtub sellega pärast tunnelit ja kuidas vastus tagasi tuleb, on teine pool, mille peate üles ehitama.

Järgmine hüpe on lüüs, mitte seadme IP

UDR saadab sobiva prefiksi järgmise hüppe tüübile ja VirtualNetworkGateway on tüüp, mitte aadress. Inimesed kleepivad lüüsi privaatse IP VirtualAppliance'i marsruudile ja imestavad siis, miks miski ei klapi, sest see tüüp ootab hoopis NIC-i või sisemist koormusbalansseerijat. Microsofti marsruutimisdokumentatsioon piirab ka lüüsi järgmist hüpet virtuaalvõrguga, mille lüüs on VPN-lüüs. ExpressRoute, Route Server ja Virtual WAN-i jaotur ei ole selle valikuga adresseeritavad.

Kontrollige, mis virtuaalvõrgus tegelikult on, enne kui marsruudi kirjutate. Kui disain marsruudib jaoturi kaudu, kuulub marsruut jaoturi marsruutimise omanikule, mitte spokile, mida parasjagu muudate.

Lugege kehtivat marsruuti enne, kui midagi muudate

Azure ühendab süsteemsed marsruudid, BGP kaudu õpitud prefiksid ja UDR-id NIC-põhiseks kehtivaks marsruuditabeliks ning pikim sobiv prefiks võidab olenemata sellest, kust see pärineb. Sama prefiksi puhul võidab UDR BGP marsruudi. Just selle järjestuse tõttu võib varasemast katsest jäänud vananenud UDR vaikselt üle kirjutada prefiksi, mille te hiljuti tunneli kaudu õppisite.

Vaadake esmalt kehtivat tabelit ja otsustage seejärel, kas lisate marsruudi või asendate selle:

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

Lugege ka allika veergu, mitte ainult prefiksi. Õige prefiksi ja vale allikaga marsruut ütleb, millist objekti muuta, ja säästab teid teise marsruudi lisamisest, mis esimesele kaotab.

Kirjutage marsruut tegeliku prefiksi ja alamvõrgu järgi

Kasutage sihtkoha tegelikku prefiksit, mis on võetud teenusest, mida te tegelikult kasutate, mitte foorumipostitusest kopeeritud avalikku vahemikku. Alustage ühe kinnitatud teenusega, enne kui kaalute vaikemarsruuti, mis liigutab kogu väljamineva liikluse. Seejärel kinnitage marsruuditabel töökoormuse alamvõrgu külge. Lüüsi alamvõrgul on omad nõuded ja tabeli sinna kinnitamine rikub lüüsi, mitte ei suuna töökoormust.

Looge marsruut ja siduge seejärel tabel alamvõrguga, kus töökoormus asub:

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

Levitus loeb samuti. Kui sellel tabelil on BGP levitus lubatud, ilmuvad õpitud prefiksid teie kirjutatute kõrvale ja täpsem õpitud prefiks võib võita laiema UDR-i. Keelake levitus ainult siis, kui soovite, et UDR-ide kogum oleks selle alamvõrgu jaoks autoriteetne.

Lõpetage kohapealne pool, muidu sureb voog seal

Kohapealne lüüs peab Azure'i allika vastu võtma, edasi saatma sihtkohta ja rakenduse lubama. Selle edasine tee võib olla interneti väljapääs või muu privaatne hüpe, kuid see otsus kuulub plaani, mitte Azure'i marsruuditabelisse. Tavaline tõrge on tagasitee. Interneti sihtkoht ei marsruudi privaatset Azure'i allikat teie juurde tagasi, nii et vastus läheb oma vaikelüüsile ja sureb, või ei välju üldse.

Kaks disaini lahendavad selle ja need ei ole vahetatavad. Tõlkige allikas väljapääsus, nii et sihtkoht vastab avalikule aadressile, mille kohapealne võrk omab. Või säilitage allikas ja ehitage marsruuditud tagasisuhe, et vastused tuleksid tunnelist tagasi. Valige üks ja kirjutage üles, millist aadressi rakendus näeb.

Selektorid ja lubatud loendid on sellest kõigest eraldi. Azure'i järgmise hüppe valimine ei laienda VPN-i liiklusselektoreid ega muuda välise teenuse allika lubatud loendit.

Kontrollige sihtkoha nähtud allika järgi

Saatke päring tegelikust töökoormusest, mitte teise alamvõrgu hüppeserverist, ja lugege seejärel allika aadressi, mida sihtkoht nägi. See üks väärtus ütleb, milline kahest tagasitee disainist on paigas. Seejärel kontrollige vastuse teed ja kinnitage, et tavaline haldusliiklus VM-i jõuab endiselt kohale, sest kogemata lisatud vaikemarsruut ilmneb katkise SSH-sessioonina palju varem kui katkise rakendusena.

Valitud prefiksi kaudu edastamine on palju kitsam muudatus kui sunnitud tunnelid. Hoidke see kitsana ja tagasipööramine tähendab ühe marsruudi kustutamist.