Azure UDR til en VPN-gateway: én destinasjon, ikke hele utgangen

Du legger til en brukerdefinert rute for ett eksternt prefiks, peker den på VPN-gatewayen, og trafikken går fortsatt ut via Azures internettbane. Eller den går ut riktig og svaret kommer aldri tilbake. Begge utfallene kommer fra samme feil: å behandle Azures neste hopp som hele designet. Rutetabellen avgjør bare hvilken utgang en pakke tar inne i Azure. Hva som skjer med den etter tunnelen, og hvordan svaret kommer tilbake, er en andre halvdel du må bygge.

Neste hopp er en gateway, ikke en IP for et apparat

En UDR sender et samsvarende prefiks til en type neste hopp, og VirtualNetworkGateway er en type, ikke en adresse. Folk limer inn gatewayens private IP i en VirtualAppliance-rute og lurer på hvorfor ingenting samsvarer, fordi den typen i stedet forventer et NIC eller en intern lastbalanserer. Microsofts dokumentasjon for ruting begrenser også gatewayens neste hopp til et virtuelt nettverk der gatewayen er en VPN-gateway. ExpressRoute, Route Server og en Virtual WAN-hubb adresseres ikke av det alternativet.

Sjekk hva det virtuelle nettverket faktisk har før du skriver ruten. Hvis designet ruter gjennom en hubb, tilhører ruten hubens rutingseler, ikke spoket du tilfeldigvis redigerer.

Les den effektive ruten før du endrer noe

Azure kombinerer systemruter, BGP-lærte prefikser og UDR-er i en effektiv rutetabell per NIC, og det lengste samsvarende prefikset vinner uansett hvor det kom fra. For samme prefiks slår en UDR en BGP-rute. Den rekkefølgen er grunnen til at en gammel UDR fra et tidligere eksperiment stille kan overstyre prefikset du nettopp lærte gjennom tunnelen.

Se på den effektive tabellen først, og avgjør deretter om du legger til en rute eller erstatter en:

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

Les også kildekolonnen, ikke bare prefikset. En rute med riktig prefiks og feil kilde forteller deg hvilket objekt du skal redigere, og sparer deg for å legge til en andre rute som taper mot den første.

Skriv ruten mot det virkelige prefikset og subnettet

Bruk destinasjonens virkelige prefiks, hentet fra tjenesten du faktisk når, i stedet for et offentlig område kopiert fra et foruminnlegg. Begynn med én godkjent tjeneste før du vurderer en standardrute som flytter all utgang. Fest deretter rutetabellen til subnettet for arbeidsbelastningen. Gateway-subnettet har egne krav, og å feste tabellen din der ødelegger gatewayen i stedet for å styre arbeidsbelastningen.

Opprett ruten, og bind deretter tabellen til subnettet som er vert for arbeidsbelastningen:

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 betyr også noe. Med BGP-propagering aktivert på den tabellen vises lærte prefikser ved siden av dem du skrev, og et mer spesifikt lært prefiks kan slå en bredere UDR. Deaktiver propagering bare når du vil at UDR-settet skal være autoritativt for det subnettet.

Fullfør den lokale halvdelen, ellers dør flyten der

Den lokale gatewayen må godta Azure-kilden, videresende den til destinasjonen og tillate applikasjonen. Videre vei kan være en internettutgang eller et annet privat hopp, men den beslutningen hører hjemme i planen, ikke i Azures rutetabell. Den vanlige feilen er returveien. En internettdestinasjon vil ikke rute en privat Azure-kilde tilbake til deg, så svaret går til sin egen standardgateway og dør, eller forlater aldri.

To design løser dette, og de er ikke utbyttbare. Oversett kilden ved utgangen, slik at destinasjonen svarer til en offentlig adresse som det lokale nettverket eier. Eller bevar kilden og bygg et rutet returforhold slik at svar kommer tilbake gjennom tunnelen. Velg ett, og skriv ned hvilken adresse applikasjonen vil se.

Selektorer og tillatelseslister er atskilt fra alt dette. Å velge et Azure-neste hopp utvider ikke VPN-trafikkselektorene og endrer ikke en ekstern tjenestes kilde-tillatelsesliste.

Verifiser med kilden destinasjonen observerer

Send forespørselen fra den virkelige arbeidsbelastningen i stedet for fra en sprenghost i et annet subnet, og les deretter kildeadressen destinasjonen observerte. Den ene verdien forteller deg hvilket av de to returdesignene som er på plass. Sjekk deretter svarveien, og bekreft at vanlig administrasjonstrafikk til VM-en fortsatt virker, fordi en standardrute lagt til ved et uhell vises som en brutt SSH-økt lenge før den vises som en ødelagt applikasjon.

Transitt gjennom et valgt prefiks er en mye smalere endring enn tvungen tunneling. Hold den smal, og tilbakerullingen er å slette én rute.