Private VPN-Adressbereiche planen, bevor Standorte kollidieren
Überlappende private Bereiche brechen das Routing, noch bevor ein Tunnel steht. Erfassen Sie die Präfixe, dimensionieren Sie Client-Pools getrennt von Standort-LANs und testen Sie von der Gegenseite.
Zwei Standorte, die beide 192.168.1.0/24 verwenden, erreichen jeweils das Internet und trotzdem einander nicht. Das Gateway meldet keinen Fehler; es installiert eine Route für dieses Präfix und schickt jedes Paket zu dem Peer, der es zuerst beansprucht hat. Weder Handshake noch Cipher-Liste noch Interface-Metrik sagen, welcher Peer falsch liegt. Adressplanung ist der Teil des Designs, der das klärt, bevor sich jemand verbindet.
Jeden Bereich erfassen, der erreichbar sein muss
Notieren Sie die Bereiche, die geroutet werden müssen, nicht nur die, die Sie konfigurieren. Das heißt Standort-LANs, VPN-Client-Pools, Cloud-Subnetze, Management- und Out-of-Band-Netze, Laborsegmente und die Netze, aus denen Nutzer üblicherweise von zu Hause zugreifen. Ein Consumer-Router, der als 192.168.1.0/24 ausgeliefert wird, ist nicht hypothetisch, und dasselbe Präfix taucht in Hotels und Konferenzzentren auf. Die Inventur ist eine Tabelle aus Präfix, Eigentümer und Zweck und das einzige Artefakt, das verhindert, dass derselbe Bereich zweimal vergeben wird.
| Prefix | Purpose | Owner |
|---|---|---|
| 10.20.0.0/16 | site LANs | network team |
| 10.20.100.0/22 | VPN client pool | remote access |
| 10.20.200.0/24 | management | operations |
Ergänzen Sie die Präfixe, die Sie im nächsten Jahr erwarten, denn ein Plan, der nur heute abdeckt, scheitert am ersten neuen Standort. Markieren Sie in jeder Zeile, wer sie ändern kann, nicht nur, wem sie gehört.
Die Wiederverwendung macht es schwer: privater Adressraum ist endlich, und jede Organisation betrachtet 10.0.0.0/8 als ihren eigenen. Ein Plan kann nicht versprechen, dass kein künftiges Gast-LAN auf einem Ihrer Präfixe landet, also muss das Design sagen, was passiert, wenn es doch geschieht. Zwei Regeln erledigen das meiste. Legen Sie Client-Pools in einen zusammenhängenden Block, den Sie zusammenfassen können, und vergeben Sie nie einen Bereich, den ein anderes Team bereits routet. Alles Übrige ist ein Verzeichnis, das jemand aktuell hält.
Warum eine Überlappung die Routing-Tabelle besiegt
Eine Route ist ein Präfix plus ein nächster Hop, und die Weiterleitung wählt das längste passende Präfix. Wenn zwei Peers dasselbe 192.168.1.0/24 beanspruchen, hält die Tabelle einen Eintrag dafür, also verlässt der Verkehr beider Standorte denselben Tunnel. Der zweite Standort ist nicht falsch konfiguriert; er ist unerreichbar, weil der erste für dieselben Adressen antwortet. Keine Metrik kann sie trennen, denn der Treffer entsteht, bevor Metriken herangezogen werden.
Der Fehler ist asymmetrisch und leicht fehlzudeuten. Hosts an Standort A erreichen das Gateway und einige Dienste, während die Hosts von Standort B nichts beantworten, und das Log zeigt in beide Richtungen einen gesunden Tunnel. Dieses Muster ist eine Adresskollision und kein Authentifizierungs- oder Firewallfehler, und um es zu bestätigen, braucht es einen Tabellenauszug im Vergleich zur Inventur.
Client-Pool und Standortbereiche bewusst dimensionieren
Ein VPN-Client-Pool ist ein Bereich, den das Gateway Adresse für Adresse ausgibt, seine Größe begrenzt also die Parallelität. Ein /24 fasst 254 nutzbare Adressen, was für ein kleines Team großzügig und für eine Filiale mit Containern knapp ist; ein /22 kostet im privaten Raum nichts extra und beseitigt die Debatte. Halten Sie den Pool zusammenhängend und frei von jedem Standort-LAN, damit die Sammelroute zu den Clients nie einen Standort verschluckt. Reservieren Sie den Bereich auch dann, wenn der Pool leer ist, denn ein ungeschriebener Bereich ist der, den der nächste Ingenieur vergibt.
Standorte erhalten Bereiche, dimensioniert für erwartete Hosts plus Wachstum, ausgerichtet an einer Grenze, die sich sauber zusammenfassen lässt. Bewusste Lücken zwischen Zuteilungen kosten nichts und schaffen Raum für spätere Aggregation.
Prüfen Sie dann die Richtung, die Menschen vergessen: den Rückweg. Jeder Standort-Router braucht eine Route zum Client-Pool, und der Konzentrator braucht eine Route zu jedem Standortpräfix, den er bedient. Eine aufgeräumte Präfixtabelle ohne Weg zurück zum Pool ist weiterhin ein kaputtes Design, und das Symptom ist eine Einbahnverbindung, die nichts beantwortet. Halten Sie beide Richtungen in derselben Tabelle und prüfen Sie sie, wann immer ein Standort hinzukommt.
Übersetzung und Umnummerierung lösen verschiedene Probleme
Wenn eine Überlappung bereits besteht, gibt es zwei ehrliche Optionen und eine unehrliche. Umnummerierung beseitigt die Kollision dauerhaft und kostet ein Wartungsfenster plus jede fest codierte Adresse, die Sie vergessen haben. Adressübersetzung bildet den privaten Bereich einer Seite am Tunnelrand auf einen anderen Bereich ab, was beide Standorte unangetastet lässt, aber Zustand hinzufügt, Protokolle bricht, die Adressen einbetten, und Logs schwerer lesbar macht. Die unehrliche Option ist eine Host-Route zu einem einzelnen Server, die einen Test besteht und alles andere scheitern lässt.
Wählen Sie nach Kontrolle und Lebensdauer. Ein Standort, den Sie besitzen und planen können, gehört auf den Umnummerierungspfad; ein Partnernetz, das Sie nicht anfassen können und das für eine Anwendung genutzt wird, ist ein Kandidat für Übersetzung mit dokumentiertem Mapping. Schreiben Sie dieses Mapping auf, denn eine Übersetzung, die nur in einer Konfigurationsdatei existiert, verschwindet in dem Moment, in dem die Datei ersetzt wird.
Von der Gegenseite testen, bevor Sie ausrollen
Testen Sie aus einem Netz, das das Gateway nicht beherbergt, denn das eigene LAN des Gateways verbirgt die meisten Routingfehler. Verbinden Sie einen Client hinter einem gewöhnlichen Heimrouter und erreichen Sie dann einen Dienst an jedem Standort und einen innerhalb des Client-Pools. Testen Sie auch die Gegenrichtung, von einem Standort-Host zum Client, denn Rückwege scheitern unabhängig. Ein Test, der nur das Gateway anpingt, beweist, dass der Tunnel steht, und nichts weiter.
Halten Sie Bereiche, Eigentümer und Übersetzungs-Mappings in einem gemeinsamen Verzeichnis, das der nächste Standort liest, bevor er etwas vergibt. Prüfen Sie es, wenn ein Standort hinzukommt, und behandeln Sie einen undokumentierten Bereich als Defekt statt als Überraschung.
Das Verzeichnis ist das Ergebnis. Ein Plan, der in drei Köpfen lebt, scheitert beim ersten Mal, wenn einer von ihnen im Urlaub ist, und eine in Produktion gefundene Überlappung kostet mehr, als die Tabelle gekostet hätte.