Azure-UDR zu einem VPN-Gateway: ein Ziel, nicht der gesamte Ausgang

Sie fügen eine benutzerdefinierte Route für ein externes Präfix hinzu, richten sie auf das VPN-Gateway und der Verkehr verlässt Azure trotzdem über den Internetpfad. Oder er verlässt Azure korrekt und die Antwort kommt nie zurück. Beide Ergebnisse stammen vom selben Fehler: den nächsten Hop in Azure für das ganze Design zu halten. Die Routentabelle entscheidet nur, welchen Ausgang ein Paket innerhalb von Azure nimmt. Was danach im Tunnel geschieht und wie die Antwort zurückkommt, ist eine zweite Hälfte, die Sie bauen müssen.

Der nächste Hop ist ein Gateway, keine Appliance-IP

Eine UDR schickt ein passendes Präfix an einen Typ für den nächsten Hop, und VirtualNetworkGateway ist ein Typ, keine Adresse. Leute kleben die private IP des Gateways in eine VirtualAppliance-Route und wundern sich, warum nichts passt, denn dieser Typ erwartet stattdessen eine NIC oder einen internen Load Balancer. Die Routingdokumentation von Microsoft beschränkt den nächsten Hop des Gateways außerdem auf ein virtuelles Netzwerk, dessen Gateway ein VPN-Gateway ist. ExpressRoute, Route Server und ein Virtual WAN Hub werden von dieser Option nicht adressiert.

Prüfen Sie, was das virtuelle Netzwerk tatsächlich hat, bevor Sie die Route schreiben. Wenn das Design über einen Hub routet, gehört die Route dem Routingverantwortlichen des Hubs und nicht dem Spoke, den Sie gerade bearbeiten.

Lesen Sie die effektive Route, bevor Sie etwas ändern

Azure kombiniert Systemrouten, über BGP gelernte Präfixe und UDRs in einer effektiven Routentabelle pro NIC, und das längste passende Präfix gewinnt, egal woher es stammt. Für dasselbe Präfix schlägt eine UDR eine BGP-Route. Diese Reihenfolge ist der Grund, warum eine alte UDR aus einem früheren Versuch das Präfix, das Sie gerade über den Tunnel gelernt haben, still überschreiben kann.

Schauen Sie zuerst auf die effektive Tabelle und entscheiden Sie dann, ob Sie eine Route hinzufügen oder ersetzen:

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

Lesen Sie auch die Quellspalte, nicht nur das Präfix. Eine Route mit dem richtigen Präfix und der falschen Quelle sagt Ihnen, welches Objekt zu bearbeiten ist, und erspart Ihnen eine zweite Route, die gegen die erste verliert.

Schreiben Sie die Route gegen das echte Präfix und Subnetz

Verwenden Sie das echte Präfix des Ziels, entnommen aus dem Dienst, den Sie tatsächlich erreichen, statt eines öffentlichen Bereichs aus einem Forumsbeitrag. Beginnen Sie mit einem freigegebenen Dienst, bevor Sie eine Standardroute erwägen, die den gesamten Ausgang verschiebt. Hängen Sie dann die Routentabelle an das Subnetz der Workload. Das Gateway-Subnetz hat eigene Anforderungen, und Ihre Tabelle dort anzuhängen bricht das Gateway, statt die Workload zu lenken.

Erstellen Sie die Route und binden Sie dann die Tabelle an das Subnetz, das die Workload beherbergt:

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

Auch die Propagation zählt. Ist die BGP-Propagation auf dieser Tabelle aktiviert, erscheinen gelernte Präfixe neben den von Ihnen geschriebenen, und ein spezifischeres gelerntes Präfix kann eine breitere UDR schlagen. Deaktivieren Sie die Propagation nur, wenn der UDR-Satz für dieses Subnetz maßgeblich sein soll.

Vervollständigen Sie die lokale Hälfte, sonst stirbt der Fluss dort

Das lokale Gateway muss die Azure-Quelle annehmen, sie an das Ziel weiterleiten und die Anwendung zulassen. Sein weiterer Weg kann ein Internetausgang oder ein anderer privater Hop sein, aber diese Entscheidung gehört in den Plan und nicht in die Azure-Routentabelle. Der übliche Fehler ist die Rückrichtung. Ein Internetziel wird eine private Azure-Quelle nicht zu Ihnen zurückrouten, also geht die Antwort an ihr eigenes Standardgateway und stirbt, oder sie verlässt das Netz nie.

Zwei Designs lösen das, und sie sind nicht austauschbar. Übersetzen Sie die Quelle am Ausgang, damit das Ziel an eine öffentliche Adresse antwortet, die das lokale Netzwerk besitzt. Oder bewahren Sie die Quelle und bauen Sie eine geroutete Rückbeziehung, damit Antworten über den Tunnel zurückkommen. Wählen Sie eines und notieren Sie, welche Adresse die Anwendung sehen wird.

Selektoren und Allowlists sind davon getrennt. Einen Azure-Next-Hop zu wählen erweitert die VPN-Verkehrsselektoren nicht und ändert keine Quell-Allowlist eines externen Dienstes.

Prüfen Sie anhand der vom Ziel beobachteten Quelle

Senden Sie die Anfrage von der echten Workload statt von einem Sprunghost in einem anderen Subnetz und lesen Sie dann die Quelladresse, die das Ziel beobachtet hat. Dieser eine Wert sagt Ihnen, welches der beiden Rückdesigns eingerichtet ist. Prüfen Sie als Nächstes den Antwortpfad und bestätigen Sie, dass normaler Verwaltungsverkehr zur VM weiter funktioniert, denn eine versehentlich hinzugefügte Standardroute zeigt sich als abgebrochene SSH-Sitzung lange bevor sie sich als defekte Anwendung zeigt.

Ein Transit über ein ausgewähltes Präfix ist eine viel engere Änderung als erzwungenes Tunneling. Halten Sie ihn eng, und der Rückbau ist das Löschen einer Route.