Access Gate mit MikroTik bereitstellen

Dieser Leitfaden führt einen MikroTik RouterOS-Router von „Access Gate im Rack" bis „OT-Datenverkehr fließt durch das Gate", von Anfang bis Ende. Sie verbinden zwei Ports, geben dem Gate einen Platz im Netzwerk und legen fest, wie der Datenverkehr dorthin gelangt. An den OT-Geräten ändert sich nichts. Die Befehle gelten für RouterOS 7.

Was Sie aufbauen werden

Das Access Gate ist ein physisches Gerät, das Sie mit zwei Ports an zwei verschiedenen Subnetzen verbinden: einem Admin-Port in Ihrem Admin-VLAN und einem Protection-Port in einem kleinen dedizierten Subnetz, das den Datenverkehr trägt, den Sie durch das Gate leiten.

Referenzlabor

1. Physische Verbindung: zwei Ports, zwei Subnetze

Legen Sie den Admin-Port und den Protection-Port auf verschiedene Subnetze, damit Management-Datenverkehr und gesteuerter Datenverkehr niemals eine Broadcast-Domain teilen. Weisen Sie einem Interface die Admin-Adresse und dem anderen die Protection-Adresse zu.

# ether5 -> Access Gate admin port (5)   |  ether2 -> Access Gate protection port (1)
/ip address add address=192.168.254.1/24 interface=ether5 comment="AG admin"
/ip address add address=100.65.0.1/29    interface=ether2 comment="AG protection"

Verbinden Sie ether5 mit dem Access Gate Admin-Port (5) und ether2 mit dem Protection-Port (1). Das Admin-Interface bezieht eine DHCP-Lease aus dem Admin-VLAN oder fällt nach etwa einer Minute auf 10.0.0.1 zurück, wenn keine vorhanden ist. Setzen Sie es über die Konsole statisch auf 192.168.254.50, wenn Sie eine feste Adresse bevorzugen.

2. Route für das Overlay einrichten

Der Secure Twin befindet sich im Overlay 100.64.0.0/16, dem parallelen Adressraum, in dem jedes Asset einen Twin erhält. Fügen Sie eine Route hinzu, damit jeder Datenverkehr für diesen Bereich über 100.65.0.6, den Protection-Port des Access Gate, weitergeleitet wird:

/ip route add dst-address=100.64.0.0/16 gateway=100.65.0.6 comment="Secure Twin overlay"

Zu lesen als: Für das Zielnetzwerk 100.64.0.0/16 ist das Gateway (Next Hop) 100.65.0.6. Ab jetzt verlässt alles, was an eine Twin-(Overlay-)Adresse gerichtet ist, den Router, trifft am Protection-Port des Access Gate ein, und das Gate leitet es per Proxy an das echte Gerät weiter. Das Ansprechen einer Twin-Adresse ist also das, was den Fluss durch das Gate zieht.

3. DNS auf das Access Gate zeigen lassen

Das Gate betreibt einen Resolver unter 100.65.0.6, der Asset-Namen in Overlay-Adressen auflöst. Sie können ihn für alles oder nur für eine Subdomain verwenden.

• Alles: Den Resolver per DHCP an Clients übergeben:

  /ip dhcp-server network set [find where address=192.168.1.0/24] dns-server=100.65.0.6
  

• Nur Subdomain: RouterOS leitet eine einzelne Zone mit einem statischen FWD-Eintrag weiter, sodass nur secure.acme.corp an das Gate geht und alles andere Ihren bestehenden Resolver verwendet:

  /ip dns static add type=FWD name=secure.acme.corp match-subdomain=yes forward-to=100.65.0.6
  

  Siehe Configuring Access Gate DNS für das Split-DNS-Muster.

4. Datenverkehr durch das Gate steuern

Zwei Wege, Datenverkehr zum Gate zu bringen. Quellbasiertes Routing sichert, was von einem Netzwerk kommt: Sie filtern danach, wo das Paket gestartet ist. Zielbasiertes Routing sichert, was zu einem Asset geht: Sie filtern nach dem Ziel. Nutzen Sie das eine, das andere oder beides, je nachdem, was Sie schützen wollen. In beiden Fällen übersetzt das Access Gate zwischen der realen Adresse des Assets und seinem Twin.

/ip firewall mangle add chain=prerouting src-address=192.168.1.0/24 \
    action=mark-routing new-routing-mark=via-ag passthrough=yes comment="steer OT to AG"
/ip route add dst-address=0.0.0.0/0 gateway=100.65.0.6 routing-table=via-ag

# Die Overlay-Route aus Schritt 2 deckt bereits alle Twins ab; diese hier begrenzt es auf ein Asset
/ip route add dst-address=100.64.1.10/32 gateway=100.65.0.6 comment="nur der PLC-Twin"

5. Den vollständigen Pfad überprüfen

Erreichen Sie von einem OT-Gerät aus ein Ziel genau wie bisher. Der Router leitet den Fluss nun beim Ausgang durch das Gate.

# from the OT device (192.168.1.10)
ping 192.168.2.20

Auf dem Access Gate erscheint der Fluss unter seinem Enclave mit der Overlay-Identität des Geräts (100.64.1.10); Identität, Policy und Verschlüsselung werden angewendet, bevor das Paket weitergeleitet wird, und die Antwort wird per NAT an das echte Gerät zurückgeleitet.

Sie können auch die Richtung IT zu OT testen: Erreichen Sie von einem IT-Client aus ein OT-Asset über seine Twin-Adresse oder seinen DNS-Namen (ping 100.64.1.10). Die Overlay-Route trägt das Paket zum Gate, das es per Proxy an das echte Gerät weiterleitet.

Was wo liegt

Der Router enthält genau eine Sache: eine Regel, die sinngemäß besagt: „Diese Pakete werden an diesen Next-Hop übergeben." Ob sie auf der Quelle oder auf dem Ziel aufsetzt, sie ist statisch.

Alles andere liegt auf dem Access Gate: Authentifizierung, Enclave-ACLs, Proxying, Credential-Injection, Session-Recording, TLS-Terminierung und Logging. Nichts davon lässt sich auf RouterOS ausdrücken, und nichts davon gehört dorthin.

Diese Trennung sollte man dem Netzwerkteam gegenüber klar benennen, denn „wir müssen Ihren Router konfigurieren" klingt beunruhigend, bis man sieht, dass es sich um eine Übergaberegel handelt, nicht um eine Policy-Engine. Ihr Change-Control-Prozess sieht ein oder zwei Regeln, einmalig.

Zusammenfassung

Sie haben zwei RouterOS-Interfaces auf zwei Subnetzen adressiert (Admin-VLAN + Protection /29), das Gate unter 100.65.0.6 platziert, das Overlay dorthin geroutet, DNS auf seinen Resolver gezeigt und den Datenverkehr nach Quelle, nach Ziel oder nach beidem gesteuert. OT-Datenverkehr fließt nun durch das Access Gate, ohne dass sich an einem Asset etwas ändert.

Verwandte Themen

• Deploy Secure Twin with Source-Based Routing
• Configuring Access Gate DNS
• Deploy Secure Twin via Gateway NAT (L3)
• Choosing a Secure Twin deployment