Azure UDR prema VPN gatewayu: jedno odredište, a ne sav izlazni promet

Dodajete korisnički definiranu rutu za jedan vanjski prefiks, usmjeravate je na VPN gateway i promet i dalje izlazi preko Azureove internetske putanje. Ili izlazi ispravno i odgovor se nikada ne vraća. Oba ishoda dolaze iz iste pogreške: tretiranja Azureovog sljedećeg skoka kao cijelog dizajna. Tablica ruta samo odlučuje koji izlaz paket uzima unutar Azura. Što se s njim dogodi nakon tunela i kako se odgovor vraća druga je polovica 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 usmjeravanju 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 što virtualna mreža zaista ima prije nego što napišete rutu. Ako dizajn usmjerava kroz čvorište, ruta pripada vlasniku usmjeravanja čvorišta, a ne govornici koju slučajno uređujete.

Pročitajte efektivnu rutu prije bilo kakve izmjene

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

Prvo pogledajte efektivnu tablicu, 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 stupac izvora, ne samo prefiks. Ruta s ispravnim prefiksom i pogrešnim izvorom govori 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 raspona kopiranog s forumske objave. Počnite s jednom odobrenom uslugom prije nego što razmotrite zadanu rutu koja premješta sav izlazni promet. Zatim prikvačite tablicu ruta na podmrežu radnog opterećenja. Gateway podmreža ima svoje zahtjeve, a prikvačivanje vaše tablice tamo kvari gateway umjesto da usmjerava opterećenje.

Stvorite rutu, zatim povežite tablicu s podmrežom koja hosta 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 tablici, 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.

Dovršite lokalnu polovicu ili tok umire tamo

Lokalni gateway mora prihvatiti Azureov izvor, proslijediti ga odredištu i dopustiti aplikaciju. Njegova daljnja putanja može biti internetski izlaz ili drugi privatni skok, ali ta odluka pripada planu, a ne Azureovoj tablici ruta. Uobičajeni neuspjeh je povratak. Internetsko odredište neće usmjeravati privatni Azureov izvor natrag prema vama, pa odgovor odlazi 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 usmjereni povratni odnos da se odgovori vraćaju kroz tunel. Odaberite jedno i zapišite koju će adresu aplikacija vidjeti.

Selektori i popisi dopuštenih odvojeni su od svega ovoga. Odabir Azureovog sljedećeg skoka ne proširuje VPN selektore prometa i ne mijenja popis dopuštenih izvora vanjske usluge.

Provjerite prema izvoru koji odredište vidi

Pošaljite zahtjev sa stvarnog radnog 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 promet 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.