Um einen Secure Twin über IP NAT bereitzustellen, fügen Sie am L3-Gateway eine Destination-NAT-Regel hinzu, die die gewählten Flows von der echten Adresse des Peers auf dessen Overlay-Zwilling umschreibt, und routen dann den Overlay-Bereich zum Access Gate. Das Asset spricht weiterhin die echte Adresse an und erfährt nie von der Umleitung. Die NAT-Regeln liegen auf Ihrem Router: Diese Methode ist Best-effort.
Wenn Sie das Asset nicht ändern können und es per IP statt per Name erreicht wird, kann die Umleitung vollständig im Netzwerk stattfinden. Der Router oder das L3-Gateway, das der Datenverkehr ohnehin durchläuft, schreibt das Ziel der von Ihnen gewählten Datenflüsse auf das Secure-Twin-Overlay um und schiebt sie durch Access Gate. Das Asset kommuniziert weiterhin mit der realen Adresse seines Peers; das Gateway erledigt den Rest.
Welches Problem löst IP NAT?
Das Asset (ein HMI im OT-VLAN) spricht die echte Adresse seines Peers an (192.168.2.20), genau wie immer. Sie können oder wollen es nicht umkonfigurieren, und es wird über IP erreicht, nicht über einen Namen. Der einzige Punkt, den Sie kontrollieren, ist das L3-Gateway, das sein Verkehr ohnehin passiert.
Also lassen Sie das Gateway die Arbeit machen: Es setzt Destination-NAT auf die Flows, die Sie auswählen, schreibt 192.168.2.20 auf den Overlay-Zwilling 100.64.2.20 um und leitet sie an das Access Gate weiter. Am Asset ändert sich nichts, die Umleitung ist eine einzige Regel auf dem Router.
Diese Methode funktioniert nur, wenn die beiden Enden in unterschiedlichen Subnetzen liegen, sodass ihr Verkehr das Gateway tatsächlich passiert. Zwei Geräte im selben Segment machen ARP füreinander und schalten die Frames direkt: Der Router sieht diese Pakete nie, und eine DNAT-Regel auf ihm kann sie niemals greifen. Nutzen Sie für diesen Fall ARP NAT (L2), das auf Layer 2 abfängt.
Da die Umleitung auf der L3-Grenze zwischen einer OT-Zone und einer IT-Zone sitzt, ist sie auch der natürliche Ort, um einen IEC-62443-Conduit zwischen beiden zu ziehen und die Zugriffskontrollnachweise zu erzeugen, die NIS2 Artikel 21 und NERC CIP-005 verlangen.
Wie funktioniert IP NAT?
Drei Teile arbeiten zusammen, alle auf dem Gateway und dem Access Gate, keines auf dem Asset:
- Der Overlay-Bereich definiert eine 1:1-Zuordnung (ein „Binat") zwischen jeder Underlay-Adresse und ihrer Secure-Twin-Overlay-Adresse. In diesem Lab entspricht das Serversubnetz
192.168.2.Xdem Overlay100.64.2.X. - Eine Destination-NAT-Regel auf dem L3-Gateway schreibt das Ziel der ausgewählten Flows von der Underlay-Adresse auf ihren Overlay-Zwilling um, sodass das Paket nun an das Overlay adressiert ist.
- Eine Route zum Access Gate führt den Overlay-Bereich zum Gate, das die Overlay-Adresse per Binat auf das echte Gerät zurückführt, die Enclave-Policy durchsetzt und die Antwort über das Gateway zurückgibt.
Da die Umschreibung auf dem Gateway passiert, bleiben die eigene Adresse des Assets, sein Gateway und sein Routing exakt so, wie sie waren: Es erfährt nie, dass sein Verkehr umgeleitet wurde.
Referenzlabor
Das Beispiel zeigt ein OT-Gerät, das einen Server in einem anderen Subnetz erreicht, also genau den Fall, für den diese Methode gebaut ist: Die beiden Enden sind durch einen gerouteten Hop getrennt, und dieser Hop ist das Einzige, was Sie kontrollieren.
| Element | Adresse | Rolle |
|---|---|---|
| HMI | 192.168.1.10 | OT-Gerät (Quelle), unverändert |
| Historian | 192.168.2.20 Underlay, 100.64.2.20 Overlay | Server, mit dem das HMI spricht, anderes Subnetz |
| Router / L3-Gateway | 192.168.1.1 (OT), 192.168.2.1 (Server) | Setzt Destination-NAT auf das Overlay |
| Access Gate | Interconnect 100.65.0.4/29, Server-Overlay 100.64.2.0/24 | Overlay-Identitäten, Policy-Durchsetzung |
Die Zuordnung erhält die letzten beiden Oktette: 192.168.2.X im Serversubnetz entspricht 100.64.2.X im Overlay, der Historian (192.168.2.20) hat also den Overlay-Zwilling 100.64.2.20.
Einen Secure Twin über IP NAT (L3) bereitstellen, Schritt für Schritt
1. Den Overlay-Bereich definieren
Legen Sie im Access Gate ein Subnetz für das Servernetz an und geben Sie ihm ein Overlay, damit jeder Server eine Secure-Twin-Adresse bekommt. In diesem Lab entspricht das Underlay 192.168.2.0/24 dem Overlay 100.64.2.0/24. Zum Definieren von Bereichen und des Secure-Twin-Ports in der Oberfläche siehe Twin IPs.
2. Destination-NAT auf dem L3-Gateway setzen
Fügen Sie auf dem Router eine DNAT-Regel hinzu, die das Ziel der zu schützenden Flows von der Underlay-Adresse auf ihren Overlay-Zwilling umschreibt. Begrenzen Sie sie auf den konkreten Flow, damit übriger Verkehr unberührt bleibt.
# Auf dem L3-Gateway: DNAT für Verkehr vom HMI zum Historian auf dessen Overlay-Zwilling
iptables -t nat -A PREROUTING -s 192.168.1.10 -d 192.168.2.20 -j DNAT --to-destination 100.64.2.20
Das DNAT greift vor der Routing-Entscheidung, das Paket ist also bereits an 100.64.2.20 adressiert, wenn das Gateway seinen nächsten Hop wählt.
3. Den Overlay-Bereich zum Access Gate routen
Schicken Sie den Overlay-Bereich zum Access Gate, damit das frisch genattete Paket an das Gate geht und nicht weiter ins Serversubnetz.
ip route add 100.64.2.0/24 via 100.65.0.4 # Access-Gate-Interconnect
4. Den vollständigen Pfad prüfen
Das HMI erreicht den Historian unter seiner echten, unveränderten Adresse, und das Gateway leitet den Flow still über das Access Gate um.
ping -c3 192.168.2.20 # vom HMI (192.168.1.10)
Das Access Gate führt 100.64.2.20 per Binat auf den echten Historian (192.168.2.20) zurück, wendet die Policy an und gibt die Antwort über das Gateway zurück. Eine reduzierte TTL in der Antwort bestätigt, dass der Flow das Gate passiert hat und nicht direkt geroutet wurde.
Wie der vollständige Pfad aussieht
HMI (192.168.1.10) [spricht den ECHTEN Server 192.168.2.20 an, unverändert]
-> Router / L3-Gateway (192.168.1.1) [DNAT 192.168.2.20 -> 100.64.2.20, Route zum Access Gate]
-> Access Gate (Interconnect 100.65.0.4/29, Policy-Durchsetzung) [Binat 100.64.2.20 -> 192.168.2.20]
-> Historian (192.168.2.20)
-> und zurück, ent-NATet zum HMI
Aus Sicht des HMI hat es den Historian unter der gewohnten Adresse erreicht. Tatsächlich hat das L3-Gateway das Ziel auf das Overlay umgeschrieben und die Sitzung lief über das Access Gate, ohne Änderung an Adresse, Gateway oder Routing eines der beiden Geräte.
Wann Sie das einsetzen, und wann nicht
Die Umleitung liegt vollständig im L3-Gateway. Das Asset wird nie umkonfiguriert und es ist keine Namensauflösung beteiligt: Der Router schreibt einfach das Ziel der Flows um, die Sie auswählen.
Das passt, wenn Sie das L3-Gateway besitzen, aber nicht die Assets, der Peer über IP erreicht wird und es einen gerouteten Hop im Pfad gibt. Beachten Sie, dass die NAT-Regeln bei Ihnen liegen: Sie bauen, pflegen und dokumentieren sie, und der Support dafür ist Best-effort oder Premium statt Standard.
Nutzen Sie einen anderen Weg, wenn Sie die Assets überhaupt anfassen können. Twin DNS und Twin IPs migrieren ein Asset nach dem anderen und werden vollständig unterstützt; Source-Based Routing verschiebt ein ganzes Subnetz mit einer Routing-Policy statt einer NAT-Regel und wird ebenfalls vollständig unterstützt. Gibt es keinen L3-Hop zwischen den beiden Geräten, kann diese Methode nicht funktionieren und ARP NAT (L2) macht es am Switch. Siehe Ihr Secure-Twin-Deployment wählen.