Zwei Standorte, ein Subnetz: für jeden eine Alias-Sicht aufbauen

Zwei Kundenstandorte betreiben beide 192.168.50.0/24, und ein Remote-Techniker muss an jedem Standort einen Drucker unter derselben Adresse erreichen. Kein Routing-Trick löst diese Mehrdeutigkeit von allein. Jeder Standort braucht eine eigene Adresssicht, und das Gateway muss den Standort aus dieser Sicht wählen, bevor es etwas weiterleitet.

Der Plan hat vier Teile: Alias-Präfixe, beide Übersetzungsrichtungen, Overlay-Richtlinie und Namen. Jeder muss zu den anderen passen.

Wählen Sie ein Alias-Präfix pro Standort

Weisen Sie jedem Standort ein vollständiges Alias-Präfix zu, das niemandem sonst im Umfeld gehört. Ein Plan für zwei Standorte könnte 192.168.50.0/24 von Standort A auf 172.21.10.0/24 und das identische LAN von Standort B auf 172.21.20.0/24 abbilden. Prüfen Sie die Kandidaten gegen jedes beteiligte Netzwerk, einschließlich Cloud-VPCs und anderer VPN-Pools. Privater Adressraum wird von jeder Organisation geteilt, daher sagt die Tatsache, dass ein Bereich RFC 1918 ist, nichts darüber aus, ob er hier frei ist.

Veröffentlichen Sie den Alias, nicht das native Subnetz, für Remote-Benutzer. Der native Bereich bleibt eine lokale Tatsache.

In beide Richtungen übersetzen

In beide Richtungen übersetzen. Die Zielzuordnung schreibt eine Alias-Adresse in die native Adresse am besitzenden Standort um. Die Quellzuordnung schreibt den entfernten Aufrufer in einen Alias um, den andere Standorte unterscheiden können.

Eine statische Eins-zu-eins-Zuordnung ist deterministisch, und das macht die Implementierung nicht zustandslos. Die Rückübersetzung kann vom Verbindungszustand abhängen, und Failover oder asymmetrische Pfade können einen Plan brechen, der das ignoriert. Die Dokumentation der Plattform entscheidet, welcher dieser Fälle gilt.

Die genaue Stufe, auf der Richtlinie, Selektoren und Routen greifen, unterscheidet sich zwischen richtlinienbasiertem IPsec, routenbasierten Tunneln und anderen Produkten. Entwerfen Sie für das, was Sie betreiben.

Tragen Sie den Plan durch das Overlay

In einem Hub weisen Sie jedes Alias-Präfix dem Standortpfad zu, der es besitzt, und erlauben nur den Transit, den die Aufgabe benötigt. In einem Mesh braucht jeder relevante Peer dasselbe Präfix und dasselbe Richtlinienwissen. Das Hinzufügen von Tunneln behebt mehrdeutige Adressierung nicht von selbst.

Die Veröffentlichung des gesamten Subnetzes ist breiter als die Veröffentlichung eines Dienstes. Wenn nur wenige Maschinen oder Ports benötigt werden, halten Sie die Zugriffsregeln enger als die Zuordnung.

Die Header-Übersetzung schreibt Anwendungsnutzlasten nicht um. Weiterleitungen, eingebettete Adressen in Konfigurationsdateien und quellbasierte Berechtigungen können die native Adresse weiterhin tragen. Testen Sie den Anwendungspfad, nicht nur den Ping. Eine funktionierende ICMP-Antwort beweist, dass die Zuordnung existiert, und sagt nichts darüber aus, ob die Anwendung den Alias akzeptiert.

Korrigieren Sie die Namen, die jeder Aufrufer sieht

Geben Sie Wartungsnamen Antworten, die zur Sicht des Aufrufers passen. Wenn der Remote-Techniker einen Hostnamen auflöst, sollte er die Alias-Adresse für diesen Standort zurückgeben, nicht den gemeinsamen nativen Bereich.

Prüfen Sie DNS-Sichten pro Standort vor dem ersten Wartungsfenster. Ein Name, der auf das native Subnetz auflöst, schickt den Aufrufer zurück in die Mehrdeutigkeit, die der Plan beseitigen sollte.

Pro Standort erfassen und prüfen

Nehmen Sie jeden Standort einzeln von einem echten Aufrufer ab und bestätigen Sie, welche Maschine geantwortet hat. Erfassen Sie die native Adresse, den Alias, das besitzende Gateway und den erlaubten Dienst zusammen.

Diese Inventarliste ist es, die die Unterscheidung bewahrt, wenn ein dritter Standort mit demselben Standard-LAN hinzukommt. Der richtlinienbasierte IPsec-NAT-Leitfaden dokumentiert ein konkretes Übersetzungsmodell; er ist kein Vertrag für jede Plattform.