Statische Routen oder ein Routing-Protokoll über ein Site-to-Site-VPN?

Beide Optionen transportieren Pakete zwischen Standorten, die Entscheidung hängt also nicht davon ab, welches Protokoll neuer ist, und auch die Größe des Tunnels gibt sie nicht vor. Drei Bedingungen geben sie vor: wie viele Präfixe sich ändern und wie oft, ob das Design ein automatisches Failover zwischen Pfaden braucht, und wie viel Control-Plane-Maschinerie das Team um drei Uhr morgens betreiben kann. Beantworten Sie das ehrlich, und die Wahl trifft sich meist von selbst. Der Rest dieses Textes ist, was jede Antwort kostet.

Drei Bedingungen entscheiden

Die erste Bedingung ist die Änderungsrate. Eine Handvoll stabiler Subnetze mit klarer Zuständigkeit lässt sich jahrelang von Hand pflegen, und jede Route bleibt eine Zeile, die jemand lesen und prüfen kann. Dutzende Präfixe, die sich mit Kommen und Gehen von Projekten verschieben, sind ein anderes Problem, denn jede Verschiebung muss jedes Gerät erreichen, das den alten Pfad noch kennt.

Die zweite ist das Fehlerverhalten. Wenn ein Ausweichpfad aktiv werden muss, ohne dass ein Mensch es bemerkt, muss etwas den Fehler erkennen und die Route zurückziehen. Statisches Routing kann das nur über Tracking oder bedingte Installation, und nur für die Fehler, die Sie im Voraus bedacht haben.

Die dritte ist die Bereitschaft zu einer zweiten Control Plane. Ein Routing-Protokoll bringt Sitzungen, Authentifizierung, Filter und Auswahlrichtlinie mit, und all das braucht Monitoring plus einen Änderungsprozess. Das sind dauerhafte Betriebskosten, keine einmalige Konfigurationsaufgabe.

Die Tabelle unter dem dritten Absatz ist die Kurzfassung, und die drei Abschnitte danach erklären, warum jede Zeile dort steht, wo sie steht. Lesen Sie die Zeilen gegen Ihre eigene Standortzahl, bevor Sie wählen, denn eine Entscheidung, die die Betriebskosten ignoriert, ist nur eine halbe Entscheidung.

Was statisches Routing wirklich kostet

Eine statische Route muss auf beiden Seiten des Tunnels korrekt sein. Ein Subnetz hinzuzufügen bedeutet, das entfernte Gateway, das lokale Gateway und meist auch den Rückweg zu bearbeiten, und wer eines davon vergisst, erzeugt einen einseitigen Fehler, der wie ein Anwendungsfehler aussieht. Das Anwendungsteam sieht Zeitüberschreitungen, während das Netzwerkteam eine Route sieht, die vorhanden und scheinbar gesund ist. Keines der Teams irrt sich, und deshalb dauert es so lange, diesen Fehler zu verorten.

Ein statischer Eintrag bleibt auch installiert, nachdem der Pfad darunter verschwindet. Sofern die Plattform kein Tracking liefert, zeigt die Route weiter auf einen nächsten Hop, der nicht mehr weiterleitet, und der Verkehr verschwindet, statt umzuschalten. Diese Stille ist der Preis, den Sie akzeptieren, wenn Sie die einfache Option wählen.

Schreiben Sie die Tracking-Methode neben jede Route, notieren Sie, welche Fehler sie abdeckt, und halten Sie die Liste bei der Tunnelkonfiguration. Sonst entdeckt ein Benutzer den nächsten Ausfall statt des Netzwerks, was immer die teurere Entdeckung ist.

Was dynamisches Routing wirklich kostet

Ein Protokoll kündigt neue Präfixe an, zieht unerreichbare zurück und drückt eine Präferenz zwischen Pfaden aus. Das ist wirklich nützlich, wenn mehrere Standorte oder redundante Tunnel sonst bei jeder Änderung abgestimmte Eingriffe bräuchten. Es ist auch der Grund, warum das Protokoll Sie im ungünstigsten Moment überraschen kann. Jede dieser Aktionen ist eine Zustandsänderung, die Sie nicht selbst vorgenommen haben.

Es entstehen zwei Zustände, die sich widersprechen können. Der Tunnel kann stehen, während die Routing-Sitzung liegt, und die Sitzung kann stehen, während ihre Ankündigungen das Subnetz auslassen, das die Anwendung braucht. Beide sehen aus wie ein Netz, das halb funktioniert, und keiner ist auf einer Tunnel-Statusseite sichtbar.

Filter und Richtlinie werden deshalb Teil des Designs statt eines Nachgedankens. Ein Protokoll, das alles ankündigt, kündigt irgendwann etwas Falsches an, und das falsche Präfix reist schneller als die Person, die es korrigieren kann. Schreiben Sie die Filter, bevor die erste Sitzung aktiviert wird, damit die erste Ankündigung schon bewusst ist.

Steuern Sie, was die Routing-Sitzung sagen darf

Legen Sie die erlaubte Präfixliste pro Peer fest und erzwingen Sie sie am Eingang, denn ein ausgehender Filter kann nicht verhindern, dass ein Peer Ihnen eine Default-Route schickt. Defaults und Aggregate sind hier die teuren Fehler: Sie können fremde Pfade still durch einen einzigen gelernten Eintrag ersetzen, der legitim aussieht. Weisen Sie sie ausdrücklich zurück, es sei denn, das Design will sie wirklich.

Schreiben Sie den zuständigen Standort neben jedes Netz, bevor die erste Sitzung hochkommt, denn diese Zuordnung ist die Quelle der Filterliste und keine Dokumentationszierde. Ohne sie muss die Person, die einen Filter bearbeitet, raten, welcher Standort das Präfix ankündigen soll.

Die Umverteilung zwischen zwei Protokollen ist der Ort, an dem Schleifen beginnen, und an dem dasselbe Präfix zweimal mit Attributen ankommt, die sich nicht sauber vergleichen lassen. Halten Sie Umverteilung aus dem Design heraus, bis eine konkrete Anforderung sie erzwingt, und wenn sie sein muss, markieren und filtern Sie die Routen an der Grenze.

Rutenbasierte Tunnel-Schnittstellen machen dynamisches Routing leichter darstellbar, weil der Tunnel zu einer Schnittstelle mit Routen wird statt zu einer Richtlinie, die Selektoren abgleicht. Das beseitigt nicht die Frage nach dem Peer-Umfang: die IPsec-Selektoren müssen den Verkehr, den Sie routen wollen, weiterhin zulassen.

Testen Sie den Fehlerpfad, nicht den Glücksfall

Was immer Sie wählen, nehmen Sie ein Uplink herunter und bestätigen Sie, dass der Verkehr wandert oder dass er so ausfällt, wie Sie es dokumentiert haben. Ein Design, das nur mit beiden gesunden Pfaden getestet wurde, ist ein Design, das gar nicht getestet wurde. Messen Sie die Erkennungszeit, während Sie dort sind, denn die gemessene Zahl ist die Zahl, die Nutzer erleben werden.

Bestätigen Sie dann den Rückweg unabhängig, denn asymmetrisches Routing über ein VPN ist üblich und unsichtbar, bis ein zustandsbehaftetes Gerät die Antworten verwirft. Ein Fluss, der in eine Richtung funktioniert, beweist nur die Hälfte des Weges.

Reihenfolge der Arbeit: Präfixe zählen, entscheiden, wie Fehler erkannt werden sollen, prüfen, wer das Protokoll betreiben kann, steuern, was angekündigt wird, dann einen Ausfall von Anfang bis Ende testen. Jeder Schritt liefert eine Tatsache, die der nächste braucht.