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

Dodate korisnički definisanu rutu za jedan vanjski prefiks, usmjerite je na VPN gateway i saobraćaj i dalje izlazi preko Azure internet putanje. Ili izlazi ispravno i odgovor se nikada ne vrati. Oba ishoda dolaze iz iste greške: tretiranja Azure sljedećeg skoka kao cjelokupnog dizajna. Tabela ruta samo odlučuje koji izlaz paket uzima unutar Azure. Šta se s njim dogodi nakon tunela i kako se odgovor vraća druga je polovina koju morate izgraditi.

Sljedeći skok je gateway, a ne IP adresa uređaja

UDR šalje odgovarajući prefiks tipu sljedećeg skoka, a VirtualNetworkGateway je tip, a ne adresa. Ljudi zalijepe privatnu IP adresu gatewaya u VirtualAppliance rutu i onda se pitaju zašto ništa ne odgovara, jer taj tip očekuje NIC ili interni load balancer. Microsoftova dokumentacija o rutiranju također ograničava gateway sljedeći skok na virtualnu mrežu čiji je gateway VPN gateway. ExpressRoute, Route Server i Virtual WAN čvorište ne adresiraju se tom opcijom.

Provjerite šta virtualna mreža zaista ima prije nego što napišete rutu. Ako dizajn rutira kroz čvorište, ruta pripada vlasniku rutiranja čvorišta, a ne spoku koji slučajno uređujete.

Pročitajte efektivnu rutu prije bilo kakve izmjene

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

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

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 s ispravnim prefiksom i pogrešnim izvorom kaže vam koji objekt urediti i spašava 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, umjesto javnog opsega kopiranog s forumske objave. Počnite s jednom odobrenom uslugom prije nego što razmotrite zadanu rutu koja premješta sav izlazni saobraćaj. Zatim prikvačite tabelu ruta na podmrežu radnog opterećenja. Gateway podmreža ima svoje zahtjeve, a prikvačivanje vaše tabele tamo kvari gateway umjesto da usmjerava opterećenje.

Kreirajte rutu, zatim povežite tabelu s 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 pobijediti širi UDR. Onemogućite propagaciju samo kada želite da skup UDR-ova bude mjerodavan za tu podmrežu.

Završite lokalnu polovinu ili tok umire tamo

Lokalni gateway mora prihvatiti Azure izvor, proslijediti ga odredištu i dozvoliti aplikaciju. Njegova daljnja putanja može biti internet izlaz ili drugi privatni skok, ali ta odluka pripada planu, a ne Azure tabeli ruta. Uobičajeni neuspjeh je povratak. Internet odredište neće rutirati privatni Azure izvor natrag do vas, pa odgovor ide na svoj zadani gateway i umire, ili nikada ne izlazi.

Dva dizajna to rješavaju i nisu zamjenjivi. Prevedite izvor na izlazu, tako da odredište odgovara na javnu adresu koju posjeduje 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 vidjeti.

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

Provjerite prema izvoru koji odredište vidi

Pošaljite zahtjev sa stvarnog opterećenja, a ne s preskočnog hosta u drugoj podmreži, zatim pročitajte izvornu adresu koju je odredište primijetilo. Ta jedna vrijednost govori koji je od dva povratna dizajna na snazi. Zatim provjerite povratnu putanju i potvrdite da obični upravljački saobraćaj do VM-a još radi, jer zadana ruta dodana slučajno pokaže se kao slomljena SSH sesija mnogo prije nego kao slomljena aplikacija.

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