Azure UDR til en VPN-gateway: én destination, ikke hele udgående trafik

Du tilføjer en brugerdefineret rute for et eksternt præfiks, peger den på VPN-gatewayen, og trafikken forlader stadig Azures internetvej. Eller den forlader korrekt, og svaret kommer aldrig tilbage. Begge udfald kommer fra den samme fejl: at behandle Azures næste hop som hele designet. Rutetabellen bestemmer kun, hvilken udgang en pakke tager inde i Azure. Hvad der sker med den efter tunnelen, og hvordan svaret vender tilbage, er en anden halvdel, du skal bygge.

Det næste hop er en gateway, ikke en IP på et apparat

En UDR sender et matchende præfiks til en type for næste hop, og VirtualNetworkGateway er en type, ikke en adresse. Folk indsætter gatewayens private IP i en VirtualAppliance-rute og undrer sig så over, at intet matcher, fordi den type i stedet forventer et NIC eller en intern load balancer. Microsofts dokumentation for routing begrænser også gatewayens næste hop til et virtuelt netværk, hvis gateway er en VPN-gateway. ExpressRoute, Route Server og et Virtual WAN-hub adresseres ikke af den valgmulighed.

Kontroller, hvad det virtuelle netværk faktisk har, før du skriver ruten. Hvis designet router gennem et hub, tilhører ruten hubbens routingejer frem for det spoke, du tilfældigvis redigerer.

Læs den effektive rute, før du ændrer noget

Azure kombinerer systemruter, BGP-lærte præfikser og UDR'er i en effektiv rutetabel pr. NIC, og det længste matchende præfiks vinder, uanset hvor det kom fra. For det samme præfiks slår en UDR en BGP-rute. Den rækkefølge er grunden til, at en forældet UDR fra et tidligere eksperiment stille kan tilsidesætte det præfiks, du netop har lært gennem tunnelen.

Se på den effektive tabel først, og afgør derefter, om du tilføjer en rute eller erstatter en:

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

Læs også kildekolonnen, ikke kun præfikset. En rute med det rigtige præfiks og den forkerte kilde fortæller, hvilket objekt du skal redigere, og den redder dig fra at tilføje en anden rute, der taber til den første.

Skriv ruten mod det rigtige præfiks og undernet

Brug destinationens rigtige præfiks, taget fra den tjeneste, du faktisk når, i stedet for et offentligt område kopieret fra et forumindlæg. Begynd med én godkendt tjeneste, før du overvejer en standardrute, der flytter al udgående trafik. Tilknyt derefter rutetabellen til arbejdsbelastningens undernet. Gateway-undernettet har sine egne krav, og tilknytning af din tabel der ødelægger gatewayen i stedet for at styre arbejdsbelastningen.

Opret ruten, og bind derefter tabellen til det undernet, der hoster arbejdsbelastningen:

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 betyder også noget. Med BGP-propagering aktiveret på den tabel vises lærte præfikser ved siden af dem, du skrev, og et mere specifikt lært præfiks kan slå en bredere UDR. Deaktiver kun propagering, når du vil have UDR-sættet til at være autoritativt for det undernet.

Gør den lokale halvdel færdig, ellers dør flowet der

Den lokale gateway skal acceptere Azure-kilden, videresende den til destinationen og tillade applikationen. Dens videre vej kan være en internetudgang eller et andet privat hop, men den beslutning hører hjemme i planen og ikke i Azures rutetabel. Det sædvanlige fejltrin er returvejen. En internetdestination vil ikke rute en privat Azure-kilde tilbage til dig, så svaret går til sin egen standardgateway og dør, eller forlader aldrig stedet.

To designs løser det, og de kan ikke bruges i flæng. Oversæt kilden ved udgangen, så destinationen svarer til en offentlig adresse, som det lokale netværk ejer. Eller bevar kilden og byg et rutet returforhold, så svar kommer tilbage gennem tunnelen. Vælg én, og skriv ned, hvilken adresse applikationen vil se.

Selektorer og tilladelseslister er adskilt fra alt dette. At vælge et Azure-næste hop udvider ikke VPN-trafikselektorerne og ændrer ikke en ekstern tjenestes kilde-tilladelsesliste.

Verificér med den kilde, destinationen observerer

Send anmodningen fra den rigtige arbejdsbelastning i stedet for fra en springvært i et andet undernet, og læs derefter den kildeadresse, destinationen har observeret. Den ene værdi fortæller, hvilket af de to returdesigns der er på plads. Kontroller derefter svarvejen, og bekræft, at almindelig styringstrafik til VM'en stadig virker, fordi en standardrute, der er tilføjet ved et uheld, viser sig som en brudt SSH-session længe før, den viser sig som en brudt applikation.

Transit gennem et valgt præfiks er en langt smallere ændring end tvungen tunneling. Hold den smal, og tilbagerulningen er at slette én rute.