Warum BGP über ein VPN den Underlay-Pfad nicht steuert

Zwei Standorte peeren BGP über einen IPsec-Tunnel, lernen die Präfixe des jeweils anderen, und das Diagramm wird zu Pfadsteuerung umetikettiert. Genau dieses Etikett ist der Anfang der Verwirrung. Die Sitzung tauscht tatsächlich Erreichbarkeit aus und wendet tatsächlich Politik an, aber sie hat kein Mitspracherecht dabei, welcher Anbieter, welches Kabel oder welcher Router die verschlüsselten Pakete befördert. Ich habe erlebt, wie ein Team einen funktionierenden Tunnel neu aufbaute, weil es erwartete, dass eine BGP-Routenänderung den Verkehr auf einen anderen Glasfaserpfad verschiebt, den die Sitzung nie beeinflussen konnte.

Was man annimmt, wofür eine Sitzung gut ist

Der Großteil der Erwartung kommt daher, wie eine Routenänderung im Labor aussieht. Man bewirbt ein Präfix über den Tunnel, die Gegenseite installiert es, und der Verkehr fließt. Dieselbe Abfolge passiert auf einem Router, der tatsächlich Regler für Traffic-Engineering hat, also wird beides verwechselt. Im Labor teilen sich beide Standorte meist eine Zugangsleitung, und genau deshalb zeigt sich der Unterschied dort nie.

BGP ist ein Erreichbarkeitsprotokoll. Es teilt einem Peer mit, dass man Pakete für ein Präfix zustellen kann, und lässt jede Seite die eingehenden Angebote ordnen. Über einen Tunnel ist das wirklich nützlich: Präfixe erscheinen und verschwinden, während Standorte kommen und gehen, und man kann einen Bereich ablehnen, ohne auf jedem Edge-Gerät eine statische Route zu schreiben. Was es nicht tut, ist die Router eines Anbieters unter die eigene Kontrolle zu bringen.

Das Underlay trägt den äußeren Header. Der Tunnelendpunkt sendet verschlüsselte Pakete an eine Peer-Adresse, und das Netzwerk zwischen diesen beiden Adressen leitet sie mit den Routen weiter, die seine Betreiber installiert haben. Nichts in der BGP-Sitzung ändert diese Entscheidung, es sei denn, derselbe Anbieter stellt einen unterstützten Dienst bereit, der das tut.

Was die Sitzung tatsächlich trägt

Der BGP-Speaker öffnet eine TCP-Verbindung zu Port 179 seines Peers und nutzt die Nachrichtenformate und Pfadattribute, die in RFC 4271 definiert sind. Liegt die Peer-Adresse innerhalb des Tunnels, muss der Tunnel stehen und die Adresse erreichbar sein, bevor die Sitzung überhaupt beginnen kann. Ein abgeschlossener IKE-Austausch ist kein BGP-Nachbar. Routenbasierte IPsec-Implementierungen lassen Verkehr erst durch, wenn eine passende Tunnelroute existiert, und eine politikbasierte braucht die Peer-Adresse innerhalb des geschützten Selektors. Dreht man das um, entsteht der klassische Zustand, in dem der Tunnel grün ist und die Sitzung untätig steht.

Steht die Sitzung, entscheidet die Politik, was sie überquert. Präfixlisten, AS-Path-Filter, eine Obergrenze für maximale Präfixe und eine ausdrückliche Entscheidung über Default-Routen sind das Minimum, und sie gelten in beide Richtungen. Ein Peer, der alles akzeptiert, was er erhält, kann einem eine Default-Route geben, die den lokalen Internetzugang still ersetzt. Die beiden Richtungen brauchen getrennte Listen, denn was man von einem Peer akzeptiert und was man ihm ankündigt, sind verschiedene Entscheidungen.

router bgp 65010
 neighbor 10.255.0.2 remote-as 65020
 address-family ipv4 unicast
  neighbor 10.255.0.2 prefix-list SITE-B-IN in
  neighbor 10.255.0.2 prefix-list SITE-B-OUT out
  neighbor 10.255.0.2 maximum-prefix 50

Als Nächstes beißt die MTU. Die Kapselung verkleinert die nutzbare Nutzlast, sodass ein großes Update eine Sitzung blockieren kann, die vollkommen etabliert aussieht: der Peer bleibt oben, Präfixe kommen nie an, und nichts Offensichtliches landet im Log. Begrenze die TCP-MSS auf der Tunnelschnittstelle oder setze eine Tunnel-MTU mit Platz für den Overhead, bevor du die Filter beschuldigst.

Wohin die äußeren Pakete weiterhin gehen

Verschlüsselte Pakete von einem Standort zum anderen verlassen das Netz über das, was der lokale Router für die öffentliche Adresse des Peers wählt. Kaufen beide Standorte Transit bei demselben Anbieter, kreuzen dieselbe Metro-Einrichtung, oder sitzt eine Seite hinter Carrier-Grade-NAT, überlebt der Tunnel einen Anbieterausfall nur zufällig. Tunnel-Symbole in einem Monitoring-Werkzeug zu zählen, sagt einem darüber nichts.

Routenauswahl und Installation der Weiterleitung sind ebenfalls getrennte Ereignisse. Ein Präfix kann als bestes in der BGP-Tabelle stehen und trotzdem in der Weiterleitungstabelle fehlen, weil der nächste Hop nicht auflösbar ist oder eine spezifischere Route gewinnt. Wenn jemand meldet, BGP habe das Präfix gelernt, aber der Verkehr fließe nicht, ist die nützliche Frage, ob es installiert ist und auf welchen nächsten Hop es zeigt.

Die ehrliche Antwort für eine Design-Review ist eine Liste gemeinsamer Abhängigkeiten: Zugangsleitung, Upstream-Anbieter, Einrichtung und jedes zustandsbehaftete Gerät auf dem Rückweg. Eine Sitzung über den Tunnel kann keine Abhängigkeit entfernen, über der sie nicht sitzt.

Drei Entscheidungen, die man trennen sollte

Wenn ein Design diese Dinge vermischt, dreht sich jedes Ausfallgespräch im Kreis. Trenne sie zuerst auf dem Papier und ordne dann jede dem Gerät zu, das sie tatsächlich durchsetzt.

Jede Zeile hat einen anderen Eigentümer. Die erste ist eine Verhandlung, die zweite ist Konfiguration auf den eigenen Geräten, die dritte ist überwiegend das Netz von jemand anderem. Ein Änderungsantrag, der die Zeile nennt, die er berührt, ist viel leichter zu genehmigen als einer, der BGP-Problem sagt.

Fehlermodi, für die es sich zu planen lohnt

Die Summary-Route eines Peers zu akzeptieren ist die häufigste selbst zugefügte Wunde. Jemand bewirbt ein kurzes Aggregat, um den Austausch zu vereinfachen, die Gegenseite akzeptiert es, und Verkehr für Bereiche, die nicht hinter dem Tunnel liegen, folgt dem Tunnel und stirbt. Filtere auf die exakt erwarteten Präfixe oder nutze eine Präfixliste mit den richtigen Grenzen, und akzeptiere niemals ein nacktes Aggregat, weil es die Sitzung ordentlich aussehen lässt.

Das Timing des Rückzugs ist das zweite. Die Erkennung hängt von Hold-Timern ab, von BFD, falls aktiviert, von der Dead-Peer-Erkennung des Tunnels und davon, wie schnell die Gegenseite aufhört zu annoncieren. Bestehende Sitzungen sind ein separates Problem: eine neue Route kann neue Verbindungen wiederherstellen, während etablierte TCP-Sitzungen weiter veraltete Adressen nutzen, und zustandsbehaftete Firewalls oder NAT auf dem Pfad können Einträge halten, die nicht mehr passen. Setze die Anwendungswiederherstellung in die Abnahmekriterien, statt anzunehmen, eine Routenänderung regle alles.

Die dritte ist Rückweg-Asymmetrie. Verkehr kann über den Tunnel ankommen und über eine Anbieterleitung zurückkehren, die nie dafür gedacht war, ihn zu tragen, was sich als einseitiges Audio, fehlgeschlagene Handshakes oder eine Firewall zeigt, die Antworten verwirft. Prüfe beide Richtungen getrennt.

Was in den Vertrag gehört und wie man es prüft

Verlange die erlaubten Präfixe schriftlich: wer berechtigt ist, jeden Bereich zu originieren, ob eine Default-Route erlaubt ist und welche Adressfamilien der Tunneldienst unterstützt. RFC 8212 machte explizite Import- und Exportpolitik zur Erwartung für eBGP in Implementierungen, die ihr folgen, also ist ein Peer, der sich noch auf implizites Alles-Akzeptieren verlässt, eine Nachfrage wert.

Prüfe dann vom Gerät statt vom Diagramm. Nützliche Befehle auf FRR-artigen Routern:

show bgp summary
show bgp ipv4 unicast 10.10.0.0/16
show bgp ipv4 unicast neighbors 10.255.0.2 advertised-routes
show ip route 10.10.0.0/16

Füge zwei Beobachtungen hinzu, die dir die Routing-Tabelle nicht geben kann. Zeichne auf dem äußeren Interface auf, um zu bestätigen, welche Adresse die gekapselten Pakete tatsächlich anvisieren, zum Beispiel tcpdump -ni eth0 udp port 51820 für einen WireGuard-Tunnel oder ein ESP-Filter für IPsec. Verfolge dann den Weg zur öffentlichen Adresse des Peers und vergleiche die Hops mit einem Trace innerhalb des Tunnels; folgen beide derselben Anbieterkette, lebt deine Redundanz in der Routenpolitik und nicht im Netzwerk.

Teste schließlich einen Rückzug absichtlich. Nimm den Tunnel in einem Wartungsfenster herunter, protokolliere, wie lange das Präfix installiert bleibt, was mit bestehenden Sitzungen passiert und ob die Gegenseite auf eine Route zurückfällt, die du wirklich akzeptieren würdest. Diese Übung sagt mehr über das Design als jedes Diagramm.

Eine Route ist keine Autorisierung. Die Präfixe, die man zu tauschen vereinbart, sagen nichts darüber, welche Nutzer welchen Dienst hinter dem Tunnel erreichen dürfen, also lasse Authentifizierung, erlaubte Dienste und Host-Firewalls genau dort, wo sie waren. Ein erreichbarer Peer ist auch keine Erlaubnis für unbegrenzten Transit oder für das Originieren beliebiger Adressen, und diese Art von Befugnis gehört als kommerzielle Frage in den Vertrag, nicht in eine BGP-Policy-Zeile.

• Benenne die Präfixe, die jede Seite originieren darf, und die, die sie niemals akzeptieren darf.
• Begrenze die MSS auf dem Tunnel und bestätige, dass große Updates tatsächlich ankommen.
• Liste die gemeinsamen Underlay-Abhängigkeiten auf, nicht die Anzahl der Tunnel.
• Miss einen echten Rückzug und notiere, was die Anwendung tut.