Azure UDR til ein VPN-gateway: éin destinasjon, ikkje heile utgangen

Du legg til ei brukardefinert rute for eitt eksternt prefiks, peikar ho til VPN-gatewayen, og trafikken går framleis ut via internettvegen til Azure. Eller ho går ut rett og svaret kjem aldri tilbake. Begge utfalla kjem frå same feilen: å sjå på neste hopp i Azure som heile designet. Rutetabellen avgjer berre kva utgang ei pakke tek inne i Azure. Kva som skjer med ho etter tunnelen, og korleis svaret kjem tilbake, er ei andre halvdel du må byggje.

Neste hopp er ein gateway, ikkje ein IP for eit apparat

Ei UDR sender eit samsvarande prefiks til ein type neste hopp, og VirtualNetworkGateway er ein type, ikkje ei adresse. Folk limer den private IP-en til gatewayen inn i ei VirtualAppliance-rute og undrar seg over kvifor ingenting passar, fordi den typen ventar seg eit NIC eller ein intern lastbalansar i staden. Dokumentasjonen til Microsoft om ruting avgrensar òg neste hopp for gatewayen til eit virtuelt nett der gatewayen er ein VPN-gateway. ExpressRoute, Route Server og ein Virtual WAN-hubb blir ikkje adresserte av det valet.

Sjekk kva det virtuelle nettet faktisk har før du skriv ruta. Viss designet rutar gjennom ein hubb, høyrer ruta til rutingseljaren for hubben, ikkje til spoka du tilfeldigvis redigerer.

Les den gjeldande ruta før du endrar noko

Azure slår saman systemruter, prefiks lærte via BGP og UDR-ar i ein gjeldande rutetabell per NIC, og det lengste samsvarande prefikset vinn same kvar det kom frå. For same prefiks slår ei UDR ei BGP-rute. Den rekkjefølgja er grunnen til at ei gamal UDR frå eit tidlegare eksperiment stille kan overstyre prefikset du nettopp lærte gjennom tunnelen.

Sjå på den gjeldande tabellen først, og avgjer så om du legg til ei rute eller byter ut ei:

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

Les òg kjeldekolonnen, ikkje berre prefikset. Ei rute med rett prefiks og feil kjelde fortel deg kva objekt du skal redigere, og sparer deg for å leggje til ei andre rute som tapar mot den første.

Skriv ruta mot det verkelege prefikset og subnettet

Bruk det verkelege prefikset til destinasjonen, henta frå tenesta du faktisk når, i staden for eit offentleg område kopiert frå eit foruminnlegg. Start med éi godkjend teneste før du vurderer ei standardrute som flyttar all utgang. Fest så rutetabellen til subnettet for arbeidslasta. Gateway-subnettet har eigne krav, og å feste tabellen din der øydelegg gatewayen i staden for å styre arbeidslasta.

Opprett ruta, og bind så tabellen til subnettet som husar arbeidslasta:

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

Propagering spelar òg ei rolle. Med BGP-propagering påslått på den tabellen dukkar lærde prefiks opp ved sida av dei du skreiv, og eit meir spesifikt lært prefiks kan slå ei breiare UDR. Slå av propagering berre når du vil at UDR-settet skal vere autoritativt for det subnettet.

Fullfør den lokale halvdelen, elles døyr flyten der

Den lokale gatewayen må ta imot Azure-kjelda, sende ho vidare til destinasjonen og tillate applikasjonen. Vegen vidare kan vere ein internettutgang eller eit anna privat hopp, men den avgjerda høyrer heime i planen, ikkje i rutetabellen til Azure. Den vanlege feilen er returvegen. Ein internettdestinasjon vil ikkje rute ei privat Azure-kjelde tilbake til deg, så svaret går til sin eigen standardgateway og døyr, eller forlèt aldri.

To design løyser dette, og dei er ikkje utbyttbare. Omset kjelda ved utgangen, slik at destinasjonen svarar på ei offentleg adresse som det lokale nettet eig. Eller ta vare på kjelda og bygg eit ruta returhøve slik at svar kjem tilbake gjennom tunnelen. Vel eitt, og skriv ned kva adresse applikasjonen vil sjå.

Selektorar og løyvelister er skilde frå alt dette. Å velje eit Azure-neste hopp utvidar ikkje VPN-trafikkselektorane og endrar ikkje kjelde-løyvelista til ein ekstern teneste.

Stadfest med kjelda destinasjonen ser

Send førespurnaden frå den verkelege arbeidslasta i staden for frå ein sprenghost i eit anna subnet, og les så kjeldeadressa destinasjonen såg. Den eine verdien fortel deg kven av dei to returdesigna som er på plass. Sjekk så svarvegen, og stadfest at vanleg administrasjonstrafikk til VM-en framleis verkar, fordi ei standardrute lagd til ved eit uhell viser seg som ei broten SSH-økt lenge før ho viser seg som ein øydelagd applikasjon.

Transitt gjennom eit valt prefiks er ei mykje smalare endring enn tvinga tunneling. Hald ho smal, og tilbakerullinga er å slette éi rute.