Azure UDR į VPN šliuzą: viena paskirtis, o ne visas išėjimas

Pridedate vartotojo apibrėžtą maršrutą vienam išoriniam prefiksui, nukreipiate jį į VPN šliuzą, o srautas vis tiek išeina Azure interneto keliu. Arba išeina teisingai, o atsakymas niekada negrįžta. Abi baigtys kyla iš tos pačios klaidos: laikyti Azure kitą šuolį visu projektu. Maršrutų lentelė tik nusprendžia, kokį išėjimą paketas pasirenka Azure viduje. Kas jam nutinka po tunelio ir kaip grįžta atsakymas, yra antroji pusė, kurią turite pastatyti.

Kitas šuolis yra šliuzas, o ne įrenginio IP

UDR siunčia atitinkantį prefiksą kito šuolio tipui, o VirtualNetworkGateway yra tipas, ne adresas. Žmonės įklijuoja šliuzo privatų IP į VirtualAppliance maršrutą ir tada stebisi, kodėl niekas nesutampa, nes tas tipas vietoj to tikisi NIC arba vidinio apkrovos balansuotojo. Microsoft maršrutizavimo dokumentacija taip pat apriboja šliuzo kitą šuolį virtualiu tinklu, kurio šliuzas yra VPN šliuzas. ExpressRoute, Route Server ir Virtual WAN koncentratorius šia parinktimi neadresuojami.

Prieš rašydami maršrutą patikrinkite, ką virtualus tinklas iš tikrųjų turi. Jei projektas maršrutizuoja per koncentratorių, maršrutas priklauso koncentratoriaus maršrutizavimo savininkui, o ne spokui, kurį redaguojate.

Perskaitykite galiojantį maršrutą prieš ką nors keisdami

Azure sujungia sistemos maršrutus, BGP išmoktus prefiksus ir UDR į galiojančią maršrutų lentelę kiekvienam NIC, ir ilgiausias atitinkantis prefiksas laimi nepriklausomai nuo to, iš kur jis atsirado. Tam pačiam prefiksui UDR nugali BGP maršrutą. Dėl šios tvarkos pasenęs UDR iš ankstesnio eksperimento gali tyliai užgožti prefiksą, kurį ką tik išmokote per tunelį.

Pirmiausia pažiūrėkite į galiojančią lentelę, tada nuspręskite, ar pridedate maršrutą, ar jį pakeičiate:

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

Skaitykite ir šaltinio stulpelį, ne tik prefiksą. Maršrutas su teisingu prefiksu ir neteisingu šaltiniu pasako, kurį objektą redaguoti, ir apsaugo nuo antro maršruto, kuris pralaimi pirmajam.

Rašykite maršrutą pagal tikrą prefiksą ir potinklį

Naudokite tikrą paskirties prefiksą, paimtą iš paslaugos, kurią iš tikrųjų pasiekiate, o ne viešą diapazoną, nukopijuotą iš forumo įrašo. Pradėkite nuo vienos patvirtintos paslaugos, prieš svarstydami numatytąjį maršrutą, kuris perkelia visą išėjimą. Tada prijunkite maršrutų lentelę prie apkrovos potinklio. Šliuzo potinklis turi savo reikalavimus, o lentelės prijungimas ten sugadina šliuzą, o ne nukreipia apkrovą.

Sukurkite maršrutą, tada susiekite lentelę su potinkliu, kuriame yra apkrova:

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

Sklaida taip pat svarbi. Kai toje lentelėje įjungta BGP sklaida, išmokti prefiksai atsiranda šalia jūsų rašytų, ir konkretesnis išmoktas prefiksas gali nugalėti platesnį UDR. Išjunkite sklaidą tik tada, kai norite, kad UDR rinkinys būtų autoritetingas tam potinkliui.

Užbaikite vietinę pusę, kitaip srautas ten miršta

Vietinis šliuzas turi priimti Azure šaltinį, persiųsti jį paskirčiai ir leisti programą. Jo tolesnis kelias gali būti interneto išėjimas arba kitas privatus šuolis, tačiau šis sprendimas priklauso planui, o ne Azure maršrutų lentelei. Įprasta nesėkmė yra grįžimas. Interneto paskirtis nenukreips privataus Azure šaltinio atgal į jus, todėl atsakymas nueina į savo numatytąjį šliuzą ir miršta, arba visai neišeina.

Du projektai tai sprendžia ir jie nėra keičiami. Išverskite šaltinį išėjime, kad paskirtis atsakytų į viešą adresą, kurį turi vietinis tinklas. Arba išsaugokite šaltinį ir sukurkite maršrutizuotą grįžimo ryšį, kad atsakymai grįžtų per tunelį. Pasirinkite vieną ir užrašykite, kurį adresą programa matys.

Selektoriai ir leidimų sąrašai yra atskirai nuo viso to. Azure kito šuolio pasirinkimas nepadidina VPN srauto selektorių ir nekeičia išorinės paslaugos šaltinio leidimų sąrašo.

Patikrinkite pagal paskirties matomą šaltinį

Siųskite užklausą iš tikros apkrovos, o ne iš šuolio hosto kitame potinklyje, tada perskaitykite šaltinio adresą, kurį paskirtis matė. Ta viena reikšmė pasako, kuris iš dviejų grįžimo projektų įdiegtas. Tada patikrinkite atsakymo kelią ir įsitikinkite, kad įprastas valdymo srautas į VM vis dar veikia, nes atsitiktinai pridėtas numatytasis maršrutas pasireiškia kaip nutrūkusi SSH sesija daug anksčiau, nei pasireiškia kaip sugedusi programa.

Tranzitas per pasirinktą prefiksą yra daug siauresnis pokytis nei priverstinis tuneliavimas. Išlaikykite jį siaurą, ir atšaukimas yra vieno maršruto ištrynimas.