Azure UDR till en VPN-gateway: en destination, inte hela utgången

Du lägger till en användardefinierad väg för ett externt prefix, pekar den mot VPN-gatewayen, och trafiken lämnar ändå via Azures internetväg. Eller så lämnar den korrekt och svaret kommer aldrig tillbaka. Båda utfallen kommer från samma misstag: att behandla Azures nästa hopp som hela designen. Routetabellen avgör bara vilken utgång ett paket tar inne i Azure. Vad som händer med det efter tunneln, och hur svaret kommer tillbaka, är en andra halva du måste bygga.

Nästa hopp är en gateway, inte en IP-adress för en apparat

En UDR skickar ett matchande prefix till en typ av nästa hopp, och VirtualNetworkGateway är en typ, inte en adress. Folk klistrar in gatewayens privata IP i en VirtualAppliance-rutt och undrar sedan varför inget matchar, eftersom den typen i stället förväntar sig ett NIC eller en intern lastbalanserare. Microsofts dokumentation för routning begränsar också gatewayens nästa hopp till ett virtuellt nätverk vars gateway är en VPN-gateway. ExpressRoute, Route Server och en Virtual WAN-hubb adresseras inte av det alternativet.

Kontrollera vad det virtuella nätverket faktiskt har innan du skriver rutten. Om designen routar via en hubb tillhör rutten hubbens routningsägare, inte det spoke du råkar redigera.

Läs den effektiva rutten innan du ändrar något

Azure kombinerar systemvägar, BGP-inlärda prefix och UDR:er i en effektiv routetabell per NIC, och det längsta matchande prefixet vinner oavsett var det kom ifrån. För samma prefix slår en UDR en BGP-väg. Den ordningen är anledningen till att en gammal UDR från ett tidigare experiment tyst kan skriva över prefixet du just lärde dig genom tunneln.

Titta på den effektiva tabellen först och bestäm sedan om du lägger till en väg eller ersätter en:

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

Läs också källkolumnen, inte bara prefixet. En väg med rätt prefix och fel källa berättar vilket objekt du ska redigera, och räddar dig från att lägga till en andra väg som förlorar mot den första.

Skriv vägen mot det riktiga prefixet och subnätet

Använd destinationens riktiga prefix, hämtat från tjänsten du faktiskt når, i stället för ett offentligt intervall kopierat från ett foruminlägg. Börja med en godkänd tjänst innan du överväger en standardväg som flyttar all utgående trafik. Koppla sedan routetabellen till arbetsbelastningens subnät. Gateway-subnätet har egna krav, och att koppla din tabell där bryter sönder gatewayen i stället för att styra arbetsbelastningen.

Skapa vägen och bind sedan tabellen till subnätet som är värd för arbetsbelastningen:

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

Spridning spelar också roll. Med BGP-spridning aktiverad på den tabellen visas inlärda prefix bredvid de du skrev, och ett mer specifikt inlärt prefix kan slå en bredare UDR. Inaktivera spridning bara när du vill att UDR-uppsättningen ska vara auktoritativ för det subnätet.

Slutför den lokala halvan, annars dör flödet där

Den lokala gatewayen måste acceptera Azure-källan, vidarebefordra den till destinationen och tillåta applikationen. Dess fortsatta väg kan vara en internetutgång eller ett annat privat hopp, men det beslutet hör hemma i planen och inte i Azures routetabell. Det vanliga felet är returvägen. En internetdestination kommer inte att routa en privat Azure-källa tillbaka till dig, så svaret går till sin egen standardgateway och dör, eller lämnar aldrig.

Två designer löser detta och de är inte utbytbara. Översätt källan vid utgången, så att destinationen svarar på en offentlig adress som det lokala nätverket äger. Eller bevara källan och bygg en routad returrelation så att svar kommer tillbaka genom tunneln. Välj en och skriv ned vilken adress applikationen kommer att se.

Selektorer och tillåtelselistor är åtskilda från allt detta. Att välja ett Azure-nästa hopp vidgar inte VPN-trafikselektorerna och ändrar inte en extern tjänsts käll-tillåtelselista.

Verifiera med källan som destinationen observerar

Skicka begäran från den riktiga arbetsbelastningen i stället för från en språnghost i ett annat subnät, och läs sedan källadressen som destinationen observerade. Det enda värdet berättar vilken av de två returdesignerna som är på plats. Kontrollera sedan svarsvägen, och bekräfta att vanlig hanteringstrafik till VM:en fortfarande fungerar, eftersom en standardväg som lagts till av misstag visar sig som en bruten SSH-session långt innan den visar sig som en trasig applikation.

En transit via ett valt prefix är en mycket smalare ändring än tvingad tunnling. Håll den smal och återställningen är att radera en väg.