Azure UDR k bráne VPN: jeden cieľ, nie celá odchádzajúca prevádzka

Nasmerujte jeden prefix Azure na bránu VPN bez presunu celej odchádzajúcej prevádzky. Prečítajte efektívne trasy, pripojte podsiete úlohy a dokončite cestu späť.

Pridáte používateľom definovanú trasu pre jeden externý prefix, nasmerujete ju na bránu VPN a prevádzka stále odchádza internetovou cestou Azure. Alebo odchádza správne a odpoveď sa nikdy nevráti. Oba výsledky pochádzajú z tej istej chyby: považovať ďalší skok v Azure za celý návrh. Tabuľka trás rozhoduje len o tom, ktorým výstupom paket v Azure odíde. Čo sa s ním stane po tuneli a ako sa vráti odpoveď, je druhá polovica, ktorú musíte postaviť.

Ďalší skok je brána, nie IP adresa zariadenia

UDR posiela zodpovedajúci prefix typu ďalšieho skoku a VirtualNetworkGateway je typ, nie adresa. Ľudia vložia privátnu IP brány do trasy VirtualAppliance a potom sa čudujú, prečo nič nesedí, lebo tento typ očakáva sieťovú kartu alebo interný load balancer. Dokumentácia Microsoftu k smerovaniu tiež obmedzuje ďalší skok brány na virtuálnu sieť, ktorej brána je bránou VPN. ExpressRoute, Route Server a hub Virtual WAN sa touto možnosťou adresovať nedajú.

Pred písaním trasy overte, čo virtuálna sieť skutočne má. Ak návrh smeruje cez hub, trasa patrí vlastníkovi smerovania hubu, nie spoku, ktorý práve upravujete.

Pred akoukoľvek zmenou si prečítajte efektívnu trasu

Azure zlučuje systémové trasy, prefixy naučené cez BGP a UDR do efektívnej tabuľky trás pre každú sieťovú kartu a najdlhší zodpovedajúci prefix vyhráva bez ohľadu na pôvod. Pre rovnaký prefix UDR poráža trasu BGP. Kvôli tomuto poradiu môže starý UDR z predchádzajúceho experimentu potichu prepísať prefix, ktorý ste práve spoznali cez tunel.

Najprv sa pozrite na efektívnu tabuľku a potom rozhodnite, či trasu pridávate alebo nahrádzate:

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

Čítajte aj stĺpec zdroja, nielen prefix. Trasa so správnym prefixom a nesprávnym zdrojom vám povie, ktorý objekt upraviť, a ušetrí vás pridania druhej trasy, ktorá prehrá s prvou.

Napíšte trasu podľa skutočného prefixu a podsiete

Použite skutočný prefix cieľa prevzatý zo služby, na ktorú skutočne dosahujete, namiesto verejného rozsahu skopírovaného z príspevku na fóre. Začnite jednou schválenou službou, než zvážite predvolenú trasu, ktorá presunie všetku odchádzajúcu prevádzku. Potom pripojte tabuľku trás k podsieti úlohy. Podsieť brány má vlastné požiadavky a pripojenie vašej tabuľky tam bránu pokazí, namiesto toho aby úlohu smerovalo.

Vytvorte trasu a potom pripojte tabuľku k podsieti, ktorá hostuje úlohu:

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

Záleží aj na propagácii. Keď je na tejto tabuľke povolená propagácia BGP, naučené prefixy sa objavia vedľa tých, ktoré ste napísali, a konkrétnejší naučený prefix môže poraziť širší UDR. Propagáciu vypnite len vtedy, keď chcete, aby množina UDR bola pre túto podsieť autoritatívna.

Dokončite lokálnu polovicu, inak tok tam zomrie

Lokálna brána musí prijať zdroj z Azure, odovzdať ho cieľu a povoliť aplikáciu. Jej ďalšia cesta môže byť internetový výstup alebo iný privátny skok, ale toto rozhodnutie patrí do plánu, nie do tabuľky trás Azure. Zvyčajným zlyhaním je návrat. Internetový cieľ nebude smerovať privátny zdroj z Azure späť k vám, takže odpoveď ide na vlastnú predvolenú bránu a zomrie, alebo vôbec neodíde.

Dva návrhy to riešia a nie sú zamestiteľné. Preložte zdroj na výstupe, aby cieľ odpovedal na verejnú adresu, ktorú vlastní lokálna sieť. Alebo zachovajte zdroj a postavte smerovaný vzťah pre návrat, aby sa odpovede vracali tunelom. Vyberte jedno a zapíšte, ktorú adresu aplikácia uvidí.

Selektory a zoznamy povolených sú od toho všetkého oddelené. Voľba ďalšieho skoku v Azure nerozširuje selektory prevádzky VPN a nemení zoznam povolených zdrojov externej služby.

Overte podľa zdroja, ktorý cieľ vidí

Pošlite požiadavku zo skutočnej úlohy, nie z odrazového hostiteľa v inej podsieti, a potom prečítajte zdrojovú adresu, ktorú cieľ pozoroval. Táto jediná hodnota vám povie, ktorý z dvoch návrhov návratu je nasadený. Potom skontrolujte cestu odpovede a potvrďte, že bežná prevádzka správy k virtuálnemu počítaču stále funguje, pretože predvolená trasa pridaná omylom sa prejaví ako prerušená relácia SSH oveľa skôr, než ako pokazená aplikácia.

Tranzit cez vybraný prefix je oveľa užšia zmena než vynútené tunelovanie. Udržte ho úzky a vrátenie späť znamená zmazať jednu trasu.

Súvisiace články