Datenverkehr zwischen zwei Filialen über ein Azure VPN-Gateway routen

Zwei Filialen können Datenverkehr über ein Azure VPN-Gateway austauschen, ohne dass ein direkter Tunnel zwischen ihnen besteht. Jede Filiale öffnet eine Site-to-Site-Verbindung zu demselben Gateway, und das Gateway gibt die gelernten Präfixe zwischen den beiden Verbindungen weiter. Was das möglich macht, ist nicht der zweite Tunnel, sondern der Routenaustausch: Filiale A muss das Präfix von Filiale B lernen, und B das von A. Arbeiten Sie die folgenden Prüfungen der Reihe nach durch und halten Sie bei der ersten an, die fehlschlägt, denn jeder spätere Schritt hängt davon ab.

Voraussetzungen, bevor Sie irgendetwas konfigurieren

Vier Bedingungen entscheiden, ob dieses Design überhaupt funktionieren kann. Das Gateway muss routenbasiert sein und auf einer SKU laufen, die BGP unterstützt, beide Verbindungen müssen BGP aktiviert haben, die Adressräume der Filialen dürfen sich nicht überschneiden, und keine Seite darf sich auf NAT verlassen, um ihr echtes Präfix zu verbergen.

Planen Sie die ASNs bewusst. Der dokumentierte Standardwert von Azure ist 65515, und jeder Filialrouter braucht eine eigene private ASN, die weder mit dem Gateway noch mit der anderen Filiale kollidiert. Einen Standard wiederzuverwenden, ohne eine bestehende Gateway-Konfiguration zu prüfen, ist der Weg, auf dem ein AS-Pfad später abgelehnt wird.

Bestätigen Sie außerdem, dass Sie kein VNet-Peering-Verhalten erwarten. Das Gateway tauscht Routen zwischen den beiden Verbindungen aus, die Sie konfiguriert haben; es macht beliebige Peerings nicht transitiv. Wenn ein drittes Netzwerk beide Filialen erreichen soll, braucht es seine eigene Verbindung oder seinen eigenen Routenpfad, nicht die Annahme, dass das Gateway den Verkehr auffächert. Schreiben Sie diese Grenze vor dem ersten Änderungsfenster auf, denn es ist die Designentscheidung, zu der Menschen zurückkehren, wenn später ein Standort hinzukommt.

In dieser Reihenfolge konfigurieren

Jeder Schritt hat ein beobachtbares Ergebnis, fahren Sie also erst fort, wenn es erscheint.

1. Aktivieren Sie BGP auf dem virtuellen Netzwerkgateway und notieren Sie seine ASN und Peer-Adresse.
2. Erstellen Sie pro Filiale ein lokales Netzwerkgateway mit dem echten Adressraum dieser Filiale, ihrer ASN und ihrer BGP-Peer-Adresse.
3. Erstellen Sie jede Site-to-Site-Verbindung und aktivieren Sie BGP auf der Verbindung selbst.
4. Konfigurieren Sie den Filialrouter so, dass er mit der von Azure zugewiesenen Gateway-Adresse peert und nicht annahmegemäß mit dem öffentlichen IKE-Endpunkt des Gateways.

Beim vierten Schritt bleiben die meisten Versuche hängen. Die von Azure gemeldete BGP-Peer-Adresse ist die, die der Filialrouter als Nachbar verwenden muss, und sie ist nicht immer die Adresse, die man aus dem Tunnel-Diagramm erwartet.

Annoncieren Sie das Filialpräfix selbst, zum Beispiel 10.10.0.0/16 aus A und 10.20.0.0/16 aus B. Annoncieren Sie keine Default-Route und kein breites Aggregat, um ein fehlendes spezifisches Netz abzudecken; die Lücke kommt später als stilles schwarzes Loch zurück.

Den Routenaustausch an beiden Enden überprüfen

Der Verbindungsstatus ist nicht die Prüfung. IPsec kann auf beiden Verbindungen aktiv sein, während kein Präfix zwischen ihnen übertragen wird. Lesen Sie die BGP-Peers des Gateways und seine gelernten Routen und bestätigen Sie dann, dass die Route zur anderen Filiale als nutzbarer Pfad erscheint.

Ein in einer BGP-Tabelle vorhandenes Präfix kann die Weiterleitungsentscheidung trotzdem an eine statische Route oder ein spezifischeres Präfix verlieren. Prüfen Sie die ausgewählte Route, nicht nur die empfangene.

Den Rückweg auf der LAN-Seite verfolgen

Das ist der Teil, der in Azure korrekt aussieht und vor Ort scheitert. Ein Host in Filiale A schickt sein Paket nur dann an den VPN-Router von A, wenn dieser Router sein Standardgateway ist oder wenn der Host oder sein Gateway eine Route für das Präfix von B hat. Dasselbe muss in der anderen Richtung gelten.

Wenn ein separater Core-Switch das Standardgateway des LAN ist, braucht er die Route zur anderen Filiale mit Zeiger auf den VPN-Router. Ohne sie kommt die Anfrage an und die Antwort verlässt den Standort über den Internetpfad, und der Benutzer sieht eine Verbindung, die sich öffnet und dann hängt.

Greifen Sie nicht zu einer Netzwerksicherheitsgruppe im Gateway-Subnetz, um das zu beheben. Dieses Subnetz hat eigene Anforderungen, und eine NSG dort ist kein unterstützter Ersatz für Richtlinien auf der Filialseite. Filterung gehört auf die Filial-Firewalls und auf die Workloads selbst, wo die Regeln von den Personen geprüft werden können, denen sie gehören. Diese Regeln in eine Subnetz-NSG zu verschieben, verbirgt sie zudem vor dem Team, das den nächsten Ausfall debuggen wird.

Die Operation zulassen und dann mit einem verweigerten Test beweisen

Eine gelernte Route ist keine Berechtigung. Erlauben Sie Quelle, Ziel und Dienst, die Sie tatsächlich brauchen, durch die Filial-Firewalls und die Endpoint-Richtlinie, und lassen Sie den Rest verweigert.

Testen Sie von einer gewöhnlichen Workload in Filiale A zu einem echten Dienst in Filiale B, bestätigen Sie die Antwort und versuchen Sie dann eine Operation, die verboten bleiben muss. Verkehr, den die VPN-Appliance selbst erzeugt, kann eine andere Quelladresse verwenden und die LAN-Routing-Stufe überspringen, daher beweist ein erfolgreicher Ping vom Router weniger, als es scheint.

Schließen Sie ab, indem Sie vier Fakten notieren: die ausgetauschten Präfixe, die verwendeten ASNs, den LAN-Rückweg für jede Seite und die Richtlinie, die den Dienst zulässt. Fehlt eines davon, funktioniert das Setup bis zur ersten Änderung, und dann kann niemand erklären, warum.