Azure UDR do VPN gejtveja: jedna destinacija, a ne sav izlazni saobraćaj

Dodajete korisnički definisanu rutu za jedan spoljašnji prefiks, usmerite je na VPN gejtvej i saobraćaj i dalje izlazi preko Azure internet putanje. Ili izlazi ispravno i odgovor se nikad ne vrati. Oba ishoda potiču iz iste greške: tretiranja Azure sledećeg skoka kao celokupnog dizajna. Tabela ruta odlučuje samo koji izlaz paket uzima unutar Azure. Šta se s njim dešava posle tunela i kako se odgovor vraća druga je polovina koju morate izgraditi.

Sledeći skok je gejtvej, a ne IP adresa uređaja

UDR šalje odgovarajući prefiks tipu sledećeg skoka, a VirtualNetworkGateway je tip, ne adresa. Ljudi nalepe privatnu IP adresu gejtveja u VirtualAppliance rutu i onda se pitaju zašto ništa ne odgovara, jer taj tip očekuje NIC ili interni load balanser. Microsoft dokumentacija o rutiranju takođe ograničava gejtvej sledeći skok na virtuelnu mrežu čiji je gejtvej VPN gejtvej. ExpressRoute, Route Server i Virtual WAN hab se ne adresiraju tom opcijom.

Proverite šta virtuelna mreža zaista ima pre nego što napišete rutu. Ako dizajn rutira kroz hab, ruta pripada vlasniku rutiranja haba, a ne spoku koji slučajno uređujete.

Pročitajte efektivnu rutu pre bilo kakve izmene

Azure kombinuje sistemske rute, prefikse naučene preko BGP-a i UDR-ove u efektivnu tabelu ruta po NIC-u, a najduži odgovarajući prefiks pobeđuje bez obzira odakle dolazi. Za isti prefiks UDR pobeđuje BGP rutu. Taj poredak je razlog zašto zastareo UDR iz ranijeg eksperimenta može tiho nadjačati prefiks koji ste upravo naučili kroz tunel.

Prvo pogledajte efektivnu tabelu, pa odlučite da li dodajete rutu ili je zamenjujete:

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

Čitajte i kolonu izvora, ne samo prefiks. Ruta sa ispravnim prefiksom i pogrešnim izvorom kaže vam koji objekat urediti i spasava vas od dodavanja druge rute koja gubi od prve.

Napišite rutu prema stvarnom prefiksu i podmreži

Koristite stvarni prefiks odredišta, uzet iz usluge do koje zaista dolazite, umesto javnog opsega kopiranog sa forumske objave. Počnite sa jednom odobrenom uslugom pre nego što razmotrite podrazumevanu rutu koja premešta sav izlazni saobraćaj. Zatim prikačite tabelu ruta na podmrežu radnog opterećenja. Gejtvej podmreža ima svoje zahteve, a prikačinjanje vaše tabele tamo kvari gejtvej umesto da usmerava opterećenje.

Kreirajte rutu, zatim povežite tabelu sa podmrežom koja hostuje opterećenje:

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

I propagacija je važna. Uz omogućenu BGP propagaciju na toj tabeli, naučeni prefiksi pojavljuju se uz one koje ste napisali, a specifičniji naučeni prefiks može pobediti širi UDR. Onemogućite propagaciju samo kada želite da skup UDR-ova bude merodavan za tu podmrežu.

Dovršite lokalnu polovinu ili tok umire tamo

Lokalni gejtvej mora prihvatiti Azure izvor, proslediti ga odredištu i dozvoliti aplikaciju. Njegova dalja putanja može biti internet izlaz ili drugi privatni skok, ali ta odluka pripada planu, a ne Azure tabeli ruta. Uobičajeni neuspeh je povratak. Internet odredište neće rutirati privatni Azure izvor natrag do vas, pa odgovor odlazi na sopstveni podrazumevani gejtvej i umire, ili nikada ne izlazi.

Dva dizajna to rešavaju i nisu zamenjivi. Prevedite izvor na izlazu, tako da odredište odgovara na javnu adresu koju poseduje lokalna mreža. Ili sačuvajte izvor i izgradite rutiranu povratnu vezu da se odgovori vraćaju kroz tunel. Odaberite jedno i zapišite koju će adresu aplikacija videti.

Selektori i liste dozvola odvojeni su od svega ovoga. Odabir Azure sledećeg skoka ne proširuje VPN selektore saobraćaja i ne menja listu dozvoljenih izvora spoljne usluge.

Proverite prema izvoru koji odredište vidi

Pošaljite zahtev sa stvarnog radnog opterećenja, a ne sa preskočnog hosta u drugoj podmreži, zatim pročitajte izvornu adresu koju je odredište primetilo. Ta jedna vrednost govori koji je od dva povratna dizajna na snazi. Zatim proverite povratnu putanju i potvrdite da običan upravljački saobraćaj do VM-a još radi, jer podrazumevana ruta dodata slučajno pokaže se kao prekinuta SSH sesija mnogo pre nego kao pokvarena aplikacija.

Tranzit preko izabranog prefiksa mnogo je uža promena od prisilnog tuneliranja. Držite ga uskim i vraćanje je brisanje jedne rute.