Secure Twin über ARP NAT (L2) bereitstellen: Private-VLAN-Proxy-ARP

Um einen Secure Twin über ARP NAT bereitzustellen, isolieren Sie die beiden Geräteports am Switch, lassen ein Umleitungselement per Private-VLAN-Proxy-ARP stellvertretend für den Peer auf ARP antworten und setzen dann Destination-NAT auf den abgefangenen Verkehr Richtung Overlay, den Sie zum Access Gate routen. Die Endgeräte werden nie umkonfiguriert. Das erfordert managed Switches, die Sie administrieren: eine Best-effort-Methode.

Manchmal lässt sich eine Ziel-IP nicht ändern und auf Router-Ebene nicht NATen, wohl aber kontrollieren Sie die Switching-Ebene. Dann lässt sich East-West-Verkehr mit Private VLAN und Proxy ARP in das gesicherte Overlay von Access Gate lenken, ohne die Endgeräte, ihr Gateway oder ihr Routing zu verändern.

Die Geräte verhalten sich weiterhin so, als kommunizierten sie mit einem Nachbarn im selben Subnetz, während jedes Paket durch das Overlay geführt wird, um die Richtlinien durchzusetzen.

Welches Problem löst ARP NAT?

Alte OT- und IT-Geräte lassen sich nicht ohne Weiteres umkonfigurieren. Häufig können Sie die IP einer PLC nicht ändern, keinen Agenten installieren, keine statische Route hinzufügen und das Gerät nicht auf ein neues Gateway verweisen, sei es, weil der Hersteller es verbietet, kein Wartungsfenster existiert oder das Gerät schlicht älter ist als die Idee selbst. Doch genau diese Assets müssen geschützt werden, und der East-West-Verkehr zwischen ihnen ist genau das, was ein flaches Netzwerk weit offen lässt.

Die Verkehrsumleitung löst dies auf Layer 2. Zwei Geräte im selben Subnetz senden normalerweise ARP-Anfragen aneinander und vermitteln Frames direkt, unsichtbar für jede Sicherheitskontrolle. Trout schaltet sich in diesen Austausch ein, indem es das ARP stellvertretend für das Ziel beantwortet, sodass das Quellgerät seine Frames an den Access-Gate-Pfad statt an den Peer sendet und dabei glaubt, es habe sich nichts geändert. Access Gate übersetzt den Datenfluss dann auf das Overlay, setzt die Enclave-Richtlinie durch und stellt ihn zu.

Die Endgeräte bleiben unangetastet. Das ist der Handel, den diese Methode eingeht: Sie verlagert die Konfigurationsarbeit von den Assets auf die Switching-Ebene, wo Port-Isolation und Proxy ARP eingerichtet und gepflegt werden müssen. Nichts entfällt, es wird dorthin verlagert, wo Sie eingreifen können. Wo der Monitoring-Port passive Sichtbarkeit bietet, ergänzt die Umleitung aktive Kontrolle, und beide lassen die geschützten Assets so, wie sie sind.

Wie funktioniert ARP NAT?

Die Umleitung beruht auf drei Mechanismen, die zusammenwirken. Alle werden auf der Switching-Ebene und am Redirection Element konfiguriert, keiner auf den Endgeräten:

• Port-Isolierung entfernt den direkten Layer-2-Pfad zwischen den beiden Geräten, sodass ihre Frames nicht mehr zueinander vermittelt werden können.
• Proxy ARP (Private-VLAN-Modus) erlaubt es dem Umleitungselement, ARP-Anfragen für den isolierten Peer mit seiner eigenen MAC-Adresse zu beantworten und so den Frame abzufangen, den das Gerät vermeintlich an seinen Nachbarn sendet.
• Zielübersetzung schreibt den abgefangenen Datenverkehr von der lokalen Adresse auf seine Overlay-Identität um und leitet ihn an Access Gate weiter, das ihn wieder dem realen Gerät zuordnet und die Antwort zurückgibt.

Da die Interception auf Layer 2 stattfindet, erfahren die Endgeräte nie, dass sich etwas geändert hat. Ihre IP-Konfiguration, ihr Gateway und ihre Nachbar-Logik bleiben exakt so, wie sie waren. Nur ihre ARP-Tabelle aktualisiert sich unauffällig, sodass die IP des Peers auf die MAC des Umleitungselements zeigt.

Referenzlabor

Das folgende Beispiel verwendet einen Host hinter einem Router. Es ist repräsentativ für ein reales Deployment: ein flaches Gerätesubnetz, das von der Firewall bedient wird, mit über das Overlay erreichbarem Access Gate in einer Lollipop-Architektur.

Die Zuordnung erhält das letzte Oktett: 10.0.0.X im lokalen Subnetz entspricht 100.64.100.X im Overlay.

Einen Secure Twin über ARP NAT (L2) bereitstellen, Schritt für Schritt

1. Ausgangszustand bestätigen

Beide Geräte hängen an derselben Bridge und können sich direkt erreichen. Dies ist die flache, ungeschützte Ausgangsbasis.

ping -c2 10.0.0.3      # erfolgreich: direktes L2-Switching

2. Den direkten Layer-2-Pfad entfernen

Isolieren Sie die beiden Geräte-Ports auf der Bridge, sodass ihre Frames nicht mehr zueinander vermittelt werden können. Der Port des Umleitungselements und der Uplink bleiben nicht isoliert, sodass beide Geräte sie weiterhin erreichen können.

# host-seitiges veth für jeden Container, auf der Bridge gesetzt
sudo ip link set {} type bridge_slave isolated on             # zt-a
sudo ip link set veth6680885b type bridge_slave isolated on   # zt-b

# überprüfen
bridge -d link show | grep -B1 isolated

Bestätigen Sie, dass die Abkürzung unterbrochen ist. Der Peer beantwortet das ARP nicht mehr, sodass der Neighbour-Eintrag unvollständig bleibt:

ping -c2 10.0.0.3      # scheitert: INCOMPLETE ARP
ip neigh show          # 10.0.0.3 ... INCOMPLETE

3. ARP stellvertretend für den Peer beantworten

Geben Sie dem Umleitungselement eine Adresse auf der Bridge und aktivieren Sie dann Private-VLAN-Proxy-ARP, damit es ARP-Anfragen für die isolierten Peers beantworten kann. Standard-Proxy-ARP weigert sich, für eine Adresse auf derselben Schnittstelle wie der Anfragende zu antworten; proxy_arp_pvlan ist die Einstellung, die für isolierte (Private-VLAN-)Segmente gedacht ist und genau diese Antwort erlaubt.

sudo ip addr add 10.0.0.2/24 dev zt-lab
sudo ip link set zt-lab up

sudo sysctl -w net.ipv4.ip_forward=1
sudo sysctl -w net.ipv4.conf.zt-lab.proxy_arp=1
sudo sysctl -w net.ipv4.conf.zt-lab.proxy_arp_pvlan=1

sudo ip neigh add proxy 10.0.0.3 dev zt-lab
sudo ip neigh add proxy 10.0.0.4 dev zt-lab

Nun löst das Quellgerät seinen Peer auf die MAC des Umleitungselements auf:

ip neigh show
# 10.0.0.3 dev eth0 lladdr 00:16:3e:84:aa:ba REACHABLE

Das Gerät glaubt, seinen Nachbarn gefunden zu haben. Tatsächlich hat es Trout gefunden.

4. Auf das Overlay übersetzen

Schreiben Sie den Datenverkehr, der an die lokale Peer-Adresse gerichtet ist, auf seine Overlay-Identität um und maskieren Sie (masquerade), damit die Antwort zum Umleitungselement zurückkommt und dort zurückübersetzt wird. Die Endgeräte bleiben vollständig in den Begriffen des lokalen Subnetzes.

sudo nft add table ip zt_gate
sudo nft add chain ip zt_gate prerouting '{ type nat hook prerouting priority dstnat; }'
sudo nft add rule ip zt_gate prerouting iif zt-lab ip daddr 10.0.0.3 dnat to 100.64.100.3
sudo nft add rule ip zt_gate prerouting iif zt-lab ip daddr 10.0.0.4 dnat to 100.64.100.4
sudo nft add chain ip zt_gate postrouting '{ type nat hook postrouting priority srcnat; }'
sudo nft add rule ip zt_gate postrouting ip daddr 100.64.100.0/24 masquerade

Konfigurationsbeispiel

5. Über die Firewall zu Access Gate routen

Senden Sie den Overlay-Bereich über das Gateway des Subnetzes selbst an Access Gate, sodass der Datenverkehr über die für dieses Segment vorgesehene Schnittstelle ausgeht, statt sich einen anderen Pfad zu leihen.

sudo ip route add 100.64.100.0/24 via 10.0.0.1 dev zt-lab metric 50

# den Pfad bestätigen
ip route get 100.64.100.3
# 100.64.100.3 via 10.0.0.1 dev zt-lab src 10.0.0.2

6. Das Access-Gate-Overlay konfigurieren

Erstellen Sie auf der Access-Gate-Seite ein Netzwerk, das zu diesem Subnetz passt, mit einem zugehörigen Overlay.

Sowie die Assets, die Sie schützen möchten.

7. Den vollständigen Pfad überprüfen

Das Gerät pingt seinen „Nachbarn" und es funktioniert, doch der Datenverkehr läuft nun durch Access Gate.

sudo tcpdump -ni enp6s0 host 100.64.100.3 &
ping -c3 10.0.0.3
sudo pkill tcpdump

Erwarteter Mitschnitt:

Der Datenverkehr verlässt das Umleitungselement als 10.0.0.2 -> 100.64.100.3, erreicht Access Gate über die Firewall und kehrt zurück. Der reduzierte TTL bestätigt, dass er das Gate durchlaufen hat, statt direkt vermittelt zu werden.

Wie der vollständige Pfad aussieht

zt-a (10.0.0.4)
  -> bridge  [ARP answered by Trout, not the peer]
  -> redirection element (10.0.0.2)  [DNAT 10.0.0.3 -> 100.64.100.3, masquerade]
  -> Router (10.0.0.1)
  -> Access Gate (100.64.100.3, policy enforcement)
  -> and back, un-translated to zt-a

Aus Sicht des Geräts hat es einen Nachbarn im eigenen Subnetz gepingt. In Wirklichkeit hat jeder Frame Access Gate zur Inspektion und Richtliniendurchsetzung durchlaufen, ohne Änderung an Adresse, Gateway oder Routing des Geräts.

Wann Sie das einsetzen, und wann nicht

Da die Umleitung auf ARP und Layer-2-Isolierung aufbaut, werden die geschützten Geräte nie umkonfiguriert. Es gibt keinen Agenten auf dem Asset, kein neues Gateway, keine statische Route und keine Ausfallzeit für die Geräte selbst. Alte Anlagen, die nicht angefasst werden dürfen, kommen mit Switch-Funktionen unter Zero-Trust-Durchsetzung, die meist ohnehin vorhanden sind.

Das passt, wenn Sie die Switches administrieren, diese Port-Isolation oder Private VLAN unterstützen, Sie ein Wartungsfenster dafür bekommen, und Router sowie Geräteadressierung wirklich tabu sind.

Nutzen Sie einen anderen Weg, wenn die Switches nicht managed sind oder einem anderen Team gehören, die Plattform kein Private VLAN beherrscht, das Segment Switches mehrerer Hersteller mit unterschiedlichem Isolationsverhalten umfasst, oder Sie keine Layer-2-Änderung tragen wollen, die dokumentiert und gepflegt werden muss. Beginnen Sie dann mit den empfohlenen Wegen: Twin DNS oder Twin IPs, um ein Asset nach dem anderen zu migrieren, Source-Based Routing, um ein ganzes Subnetz in einem Schritt zu verschieben. IP NAT (L3) ist die andere Best-effort-Methode und greift, wenn es einen gerouteten Hop im Pfad gibt. Siehe Ihr Secure-Twin-Deployment wählen.

Behandeln Sie dies als eine Technik für den Fall, dass die obigen Bedingungen zutreffen, nicht als Standard für jedes Deployment. Halten Sie es außerdem im Runbook des Netzwerks fest: Wer Monate später ARP-Tabellen debuggt, muss wissen, warum ein Nachbar auf die MAC des Redirection Elements auflöst.