Azure UDR naar een VPN-gateway: één bestemming, niet al het uitgaande verkeer

U voegt een door de gebruiker gedefinieerde route toe voor één extern prefix, wijst die naar de VPN-gateway, en het verkeer verlaat nog steeds via het internetpad van Azure. Of het verlaat correct en het antwoord komt nooit terug. Beide uitkomsten komen uit dezelfde fout: de volgende hop van Azure als het hele ontwerp zien. De routetabel bepaalt alleen welke uitgang een pakket binnen Azure neemt. Wat er daarna in de tunnel gebeurt, en hoe het antwoord terugkomt, is een tweede helft die u moet bouwen.

De volgende hop is een gateway, niet het IP van een apparaat

Een UDR stuurt een passend prefix naar een type volgende hop, en VirtualNetworkGateway is een type, geen adres. Mensen plakken het privé-IP van de gateway in een VirtualAppliance-route en vragen zich dan af waarom niets past, omdat dat type juist een NIC of een interne load balancer verwacht. De routeringsdocumentatie van Microsoft beperkt de gateway-next-hop ook tot een virtueel netwerk waarvan de gateway een VPN-gateway is. ExpressRoute, Route Server en een Virtual WAN-hub worden niet met die optie geadresseerd.

Controleer wat het virtuele netwerk werkelijk heeft voordat u de route schrijft. Als het ontwerp via een hub routeert, hoort de route bij de routeringseigenaar van de hub en niet bij de spoke die u toevallig bewerkt.

Lees de effectieve route voordat u iets wijzigt

Azure combineert systeemroutes, via BGP geleerde prefixen en UDR's in een effectieve routetabel per NIC, en het langst passende prefix wint ongeacht waar het vandaan komt. Voor hetzelfde prefix wint een UDR van een BGP-route. Die volgorde is de reden dat een verouderde UDR uit een eerder experiment stilletjes het prefix kan overschrijven dat u net via de tunnel hebt geleerd.

Kijk eerst naar de effectieve tabel en beslis dan of u een route toevoegt of vervangt:

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

Lees ook de bronkolom, niet alleen het prefix. Een route met het juiste prefix en de verkeerde bron vertelt u welk object u moet bewerken, en bespaart u een tweede route die verliest van de eerste.

Schrijf de route tegen het echte prefix en subnet

Gebruik het echte prefix van de bestemming, genomen uit de dienst die u werkelijk bereikt, in plaats van een openbaar bereik dat uit een forumbericht is gekopieerd. Begin met één goedgekeurde dienst voordat u een standaardroute overweegt die alle uitgaand verkeer verplaatst. Koppel daarna de routetabel aan het subnet van de workload. Het gatewaysubnet heeft eigen eisen, en uw tabel daar koppelen breekt de gateway in plaats van de workload te sturen.

Maak de route aan en bind de tabel daarna aan het subnet dat de workload host:

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

Propagatie is ook belangrijk. Met BGP-propagatie aan op die tabel verschijnen geleerde prefixen naast de uwe, en een specifieker geleerd prefix kan een bredere UDR verslaan. Schakel propagatie alleen uit als u wilt dat de UDR-set gezaghebbend is voor dat subnet.

Maak de on-premises helft af, anders sterft de stroom daar

De on-premises gateway moet de Azure-bron accepteren, doorsturen naar de bestemming en de toepassing toestaan. Het vervolgpad kan een internetuitgang of een andere privé-hop zijn, maar die beslissing hoort in het plan en niet in de Azure-routetabel. De gebruikelijke fout is de terugweg. Een internetbestemming routeert een privé-Azure-bron niet naar u terug, dus het antwoord gaat naar zijn eigen standaardgateway en sterft, of vertrekt helemaal niet.

Twee ontwerpen lossen dat op en ze zijn niet uitwisselbaar. Vertaal de bron bij de uitgang, zodat de bestemming antwoordt op een openbaar adres dat het on-premises netwerk bezit. Of behoud de bron en bouw een gerouteerde retourrelatie zodat antwoorden via de tunnel terugkomen. Kies er één en schrijf op welk adres de toepassing zal zien.

Selectors en allowlists staan hier los van. Een Azure-next-hop kiezen verbreedt de VPN-verkeersselectors niet en verandert de bron-allowlist van een externe dienst niet.

Verifieer met de bron die de bestemming waarneemt

Stuur het verzoek vanaf de echte workload in plaats van vanaf een spronghost in een ander subnet, en lees daarna het bronadres dat de bestemming heeft waargenomen. Die ene waarde vertelt u welk van de twee retourontwerpen actief is. Controleer daarna het antwoordpad en bevestig dat gewoon beheerverkeer naar de VM nog werkt, want een per ongeluk toegevoegde standaardroute uit zich als een gebroken SSH-sessie lang voordat ze zich uit als een gebroken toepassing.

Een transit via een geselecteerd prefix is een veel smallere wijziging dan geforceerde tunneling. Houd het smal en de terugdraai is één route verwijderen.