Diese Anleitung führt ein Meraki MX Security Appliance (mit einem MS Switch) von „Access Gate im Rack" bis „OT-Datenverkehr fließt durch das Gate", vollständig und von Anfang bis Ende über das Dashboard. Sie verbinden zwei Ports, weisen dem Gate einen Platz im Netzwerk zu und legen fest, wie der Datenverkehr dorthin gelangt. An den OT-Geräten ändert sich nichts.
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.
Referenz-Lab
| Element | Adresse | Rolle |
|---|---|---|
| Admin-VLAN | 192.168.254.0/24 (VLAN 254) | Zugriff auf die Access Gate Web-Konsole |
| Access Gate Admin-Port (5) | DHCP oder 192.168.254.50 | Management-Interface |
| Protection-Subnetz | 100.65.0.0/29 (VLAN 65), MX 100.65.0.1 | Point-to-Point-Verbindung zum Gate |
| Access Gate Protection-Port (1) | 100.65.0.6 | Datenverkehr ein/aus, Overlay und DNS-Resolver |
| Secure Twin Overlay | 100.64.0.0/16 | Paralleler Adressraum; jedes Asset erhält einen 1:1-Twin |
| OT-Subnetz | 192.168.1.0/24, PLC 192.168.1.10 (Twin 100.64.1.10) | Assets, unverändert |
| DNS-Zone | secure.acme.corp, Resolver 100.65.0.6 | Namen für Assets |
1. Physische Verbindung: zwei Ports, zwei VLANs
Legen Sie den Admin-Port und den Protection-Port auf verschiedene VLANs, damit Management-Datenverkehr und gesteuerter Datenverkehr niemals eine Broadcast-Domain teilen.
- VLANs erstellen unter Security & SD-WAN → Configure → Addressing & VLANs:
- VLAN 254:
192.168.254.0/24, MX-IP192.168.254.1(Admin). - VLAN 65:
100.65.0.0/29, MX-IP100.65.0.1(Protection).
- VLAN 254:
- Switch-Ports zuweisen unter Switch → Ports am MS:
- Access-Port in VLAN 254 → Kabel zum Access Gate Admin-Port (5).
- Access-Port in VLAN 65 → Kabel zum Access Gate Protection-Port (1).
Das Admin-Interface bezieht eine DHCP-Adresse aus dem Admin-VLAN oder fällt nach etwa einer Minute auf 10.0.0.1 zurück, falls kein DHCP verfügbar ist. Setzen Sie die Adresse über die Konsole auf statisch 192.168.254.50, wenn Sie eine feste Adresse bevorzugen.
2. Dem Overlay eine Route geben
Das 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 statische Route unter Security & SD-WAN → Configure → Routing (Static routes) hinzu, damit Datenverkehr für diesen Bereich an 100.65.0.6, den Protection-Port des Access Gate, weitergeleitet wird:
- Subnetz:
100.64.0.0/16 - Next-Hop-IP:
100.65.0.6
Ab diesem Punkt wird jeder Datenverkehr, der an eine Twin-Adresse (Overlay) gerichtet ist, an das Access Gate über seinen Protection-Port gesendet, und das Gate leitet ihn per Proxy an das echte Gerät weiter. Der Datenverkehr zu 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: Bearbeiten Sie unter Addressing & VLANs die DHCP-Einstellungen des OT-VLANs und setzen Sie Custom nameservers auf
100.65.0.6. Alle Geräte in diesem VLAN lösen dann über das Gate auf. - Nur Subdomain: Der MX unterstützt kein zonenbasiertes Conditional Forwarding. Behalten Sie Ihren vorhandenen DNS und fügen Sie einen Conditional Forwarder für
secure.acme.corp → 100.65.0.6auf Ihrem lokalen DNS-Server (Windows DNS, BIND oder Infoblox) hinzu. Siehe Configuring Access Gate DNS.
4. Datenverkehr durch das Gate steuern
Zwei Wege, Datenverkehr zum Gate zu bringen. Quellbasiertes Routing sichert, was von einem Netzwerk kommt. Zielbasiertes Routing sichert, was zu einem Asset geht. In beiden Fällen übersetzt das Access Gate zwischen der realen Adresse des Assets und seinem Twin.
Auf Meraki nutzen Sie das zielbasierte Verfahren. Es ist eine einzige statische Route, verhält sich auf MX und MS gleich und steuert jeden Client in jedem VLAN. Die MX hat auch eine quellbasierte Option, die aber nur Verkehr erfasst, für den die MX keine Route hat. Sie zieht OT-Verkehr zu Ihren anderen lokalen VLANs also nicht durch das Gate.
Zielbasiert: sichern, was zu einem Asset geht (dieses nutzen)
Die Overlay-Route aus Schritt 2 deckt bereits alle Twins ab. Um ein einzelnes Asset zu begrenzen, fügen Sie eine Static Route unter Security & SD-WAN → Configure → Routing hinzu:
- Subnet:
100.64.1.10/32 - Next hop IP:
100.65.0.6 - Active: Always active
Erreichen Sie ein Asset über seine Twin-Adresse oder seinen DNS-Namen, und der Fluss läuft über das Gate, unabhängig vom Absender. Das ist das Gateway-NAT (L3)-Muster.
Zwei Dinge müssen stimmen. Der Twin-Bereich darf sich mit keinem VLAN der MX und keiner bestehenden statischen Route überschneiden, denn verbundene und spezifischere Routen gewinnen, und der Verkehr würde das Gate unbemerkt umgehen. Und lassen Sie Active auf Always active: Bei Ping-Tracking entfernt ein Gate, das nicht mehr antwortet, die Route, der Verkehr fällt auf den Standardpfad zurück, und Sie erhalten eine stille Umgehung statt eines sauberen Ausfalls.
Wo Sie die Adressierung eines Assets ändern können, migriert die IP-Änderung ein Gerät nach dem anderen ganz ohne Routing-Änderung.
Quellbasiert: sichern, was aus dem OT-Subnetz kommt
Die MX beherrscht kein Policy-Based Routing im LAN, wohl aber Source-Based Default Routing (MX 15.4+, VLANs aktiviert). Wählen Sie unter Security & SD-WAN → Configure → Addressing & VLANs den Punkt Add source-based route, wählen Sie das OT-VLAN, setzen Sie den Next-Hop-Typ auf LAN und die Adresse auf 100.65.0.6.
Lesen Sie die Einschränkung, bevor Sie sich darauf verlassen: Eine quellbasierte Standardroute gilt nur für Ziele, für die die MX keine Route hat, und sie wirkt auf das ganze VLAN, nicht pro Host. Sie deckt Verkehr ab, der den Standort verlässt. Sie deckt OT zu IT innerhalb des Standorts nicht ab, weil das IT-VLAN bereits in der Routing-Tabelle steht.
Für Ost-West-Verkehr von OT zu IT erreichen Sie den IT-Dienst über seinen Twin, oder Sie terminieren das OT-Subnetz auf einem vorgelagerten L3-Gerät, einem Catalyst-Switch oder einer FortiGate, und wenden dort quellenbasiertes Routing an.
Gateway-Verlagerung: das Gate wird zum Gateway des Subnetzes
Die stärkste und zugleich invasivste Option. Entfernen Sie das OT-VLAN aus der Adresstabelle der MX und terminieren Sie dieses Subnetz stattdessen auf dem Access Gate. Das Gate wird zum Gateway der Enclave-Hosts und stellt für sie DHCP bereit. Fügen Sie auf der MX eine statische Route für das Enclave-Subnetz hinzu, die auf die Transit-Adresse des Gate zeigt. Besitzt Ihr MS-Stack die VLAN-Schnittstelle, entfernen Sie sie dort und routen das Subnetz über ein Transit-VLAN zum Gate.
Damit wird alles durchgesetzt, was die Enclave verlässt, inklusive Inter-VLAN-Verkehr, ohne Abhängigkeit von der Twin-Adressierung. Es erfordert ein Wartungsfenster und macht das Access Gate zu einer harten Abhängigkeit für dieses Subnetz. Heben Sie es sich also für kleine, klar abgegrenzte Enclaves auf.
5. Den vollständigen Pfad überprüfen
Erreichen Sie von einem OT-Gerät aus ein Asset über seinen DNS-Namen oder seine Twin-Adresse:
ping plc-line-1.secure.acme.corp # from a client that resolves via 100.65.0.6
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.
Führen Sie anschließend ein traceroute auf die reale Adresse des Assets aus. Es sollte nicht über das Gate laufen. Das ist so erwartet, und es zeigt Ihnen genau, wie viel Umgehung noch besteht: Alles, was weiterhin die reale Adresse nutzt, ist nicht durchgesetzt. Testen Sie von einem Client innerhalb des VLAN, nicht aus dem Meraki-Dashboard.
Was wo liegt
Der MX enthält genau eine Sache: eine statische Route, die sinngemäß besagt: „Datenverkehr für den Overlay-Bereich wird an diesen Next Hop übergeben." Sie ist statisch. Sie schreiben sie einmal und fassen sie nie wieder an, auch wenn sich die Enclave-Policy von Woche zu Woche ändert.
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 dem MX ausdrücken, und nichts davon gehört dorthin.
Diese Trennung sollte man dem Netzwerkteam gegenüber klar benennen, denn „wir müssen Ihre Security Appliance ändern" klingt beunruhigend, bis das Team sieht, dass es sich um eine Übergaberegel handelt, nicht um eine Policy-Engine. Ihr Change-Control-Prozess sieht eine Route, einmalig.
Zusammenfassung
Sie haben zwei VLANs auf dem MX erstellt, das Gate mit zwei MS-Ports in zwei Subnetzen verbunden (Admin-VLAN + Protection /29), das Gate unter 100.65.0.6 adressiert, das Overlay dorthin geroutet, DNS auf seinen Resolver gezeigt und den Datenverkehr zielbasiert gesteuert. OT-Datenverkehr fließt jetzt durch das Access Gate, ohne dass sich an einem Asset etwas geändert hat.