Azure UDR að VPN-gátt: einn áfangastaður, ekki öll útferð

Þú bætir við notandaskilgreindri leið fyrir eitt ytra forskeyti, beinir henni að VPN-gáttinni, og umferðin fer samt út um internetleið Azure. Eða hún fer rétt út og svarið kemur aldrei til baka. Báðar niðurstöður koma frá sama mistaki: að líta á næsta hopp Azure sem alla hönnunina. Leiðatöflan ræður bara hvaða útgöngu pakki tekur innan Azure. Hvað verður um hann eftir göngin, og hvernig svarið kemur aftur, er seinni helmingur sem þú verður að byggja.

Næsta hopp er gátt, ekki IP tækis

UDR sendir samsvarandi forskeyti á tegund næsta hopps, og VirtualNetworkGateway er tegund, ekki vistfang. Fólk límir einkaaðfangi gáttarinnar í VirtualAppliance-leið og spyr sig síðan hvers vegna ekkert passi, því þessi tegund væntir NIC eða innri hleðsludreifis í staðinn. Leiðsöguskjöl Microsoft takmarka líka næsta hopp gáttarinnar við sýndarnet sem hefur VPN-gátt. ExpressRoute, Route Server og Virtual WAN-hnútur eru ekki meðhöndluð með þeim valkosti.

Athugaðu hvað sýndarnetið hefur í raun áður en þú skrifar leiðina. Ef hönnunin beinir um hnút tilheyrir leiðin leiðsögustjóra hnútsins, ekki spokunni sem þú ert að breyta.

Lestu virku leiðina áður en þú breytir einhverju

Azure sameinar kerfisleiðir, forskeyti sem lærð eru með BGP og UDR í virka leiðatöflu fyrir hvert NIC, og lengsta samsvarandi forskeytið vinnur óháð því hvaðan það kemur. Fyrir sama forskeyti vinnur UDR á BGP-leið. Þessi röð er ástæðan fyrir því að gömul UDR úr fyrra tilraun getur hljóðlega yfirskrifað forskeytið sem þú varst að læra um göngin.

Skoðaðu virku töfluna fyrst og ákveddu síðan hvort þú bætir við leið eða kemur í staðinn fyrir eina:

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

Lestu líka upprunadálkinn, ekki bara forskeytið. Leið með réttu forskeyti og röngum uppruna segir þér hvaða hlut á að breyta, og bjargar þér frá því að bæta við annarri leið sem tapar fyrir þeirri fyrstu.

Skrifaðu leiðina miðað við raunverulegt forskeyti og undirnet

Notaðu raunverulegt forskeyti áfangastaðarins, tekið úr þjónustunni sem þú nærð í raun, í stað opinbers bils sem afritað er úr spjallborðsfærslu. Byrjaðu á einni samþykktri þjónustu áður en þú íhugar sjálfgefna leið sem færir alla útferð. Festu síðan leiðatöfluna við undirnet vinnuálagsins. Gáttarundirnetið hefur sínar eigin kröfur, og að festa töfluna þína þar brýtur gáttina í stað þess að stýra vinnuálaginu.

Búðu til leiðina og tengdu síðan töfluna við undirnetið sem hýsir vinnuálagið:

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

Dreifing skiptir líka máli. Með BGP-dreifingu virkri á þeirri töflu birtast lærð forskeyti við hlið þeirra sem þú skrifaðir, og sértækara lært forskeyti getur sigrað breiðara UDR. Slökktu á dreifingu aðeins þegar þú vilt að UDR-settið sé ráðandi fyrir það undirnet.

Kláraðu staðbundna helminginn eða flæðið deyr þar

Staðbundna gáttin verður að taka við Azure-upprunanum, senda hann áfram til áfangastaðarins og leyfa forritið. Frekari leið hennar getur verið internetútgangur eða annað einkahopp, en sú ákvörðun á heima í áætluninni, ekki í leiðatöflu Azure. Venjulega bilunin er afturhvarfið. Internetáfangastaður mun ekki beina einka-Azure-uppruna aftur til þín, svo svarið fer á sína eigin sjálfgefnu gátt og deyr, eða fer aldrei út.

Tvær hönnun leysa þetta og þær eru ekki skiptanlegar. Þýddu upprunann á útganginum, svo áfangastaðurinn svari á opinbert vistfang sem staðbundna netið á. Eða varðveittu upprunann og byggðu beina afturvirkni svo svör komi til baka um göngin. Veldu eitt og skrifaðu hvaða vistfang forritið muni sjá.

Valar og leyfislistar eru aðskilin frá öllu þessu. Að velja næsta hopp Azure víkkar ekki VPN-umferðarvala og breytir ekki upprunaleyfislista ytri þjónustu.

Staðfestu með upprunanum sem áfangastaðurinn sér

Sendu beiðnina frá raunverulegu vinnuálagi í stað stökkshýsils í öðru undirneti, lestu síðan upprunavistfangið sem áfangastaðurinn sá. Það eina gildi segir þér hvor af tveimur afturhvarfshönnunum er í gildi. Athugaðu síðan svarleiðina og staðfestu að venjuleg stjórnunumferð til VM virki enn, því sjálfgefin leið sem bætt var við fyrir slysni birtist sem rofin SSH-lota löngu áður en hún birtist sem biluð forrit.

Gegnumferð um valið forskeyti er miklu þrengri breyting en þvinguð göng. Haltu henni þröngri og afturköllunin er að eyða einni leið.