Mehrere SPS mit derselben IP-Adresse: NAT und VPN mit Industrieroutern richtig planen

Wenn ein Maschinenbauer mehrere Anlagen mit derselben SPS-/HMI-Adressvorlage ausliefert, braucht jede Maschine zuerst eine eindeutige, von der Zentrale aus sichtbare Identität. Erst dann lässt sich durch Umadressierung, statische Adressabbildung oder NAT im VPN ein eindeutiger bidirektionaler Pfad aufbauen. Andernfalls laufen mehrere Standorte über Industrierouter und VPN in derselben zentralen SCADA zusammen, obwohl jede SPS beispielsweise 192.168.1.10 verwendet. Das Ergebnis lautet dann häufig: „Der VPN-Tunnel steht, aber die SPS ist nicht erreichbar – oder die Verbindung landet an der falschen Maschine.“

Das Wichtigste in Kürze

Das eigentliche Problem mehrfach verwendeter Maschinennetze ist die Mehrdeutigkeit, sobald getrennte Adressräume zusammengeführt werden. Erfassen Sie deshalb zuerst Standort-ID, Gerätefunktion, Originaladresse, zentrale Aliasadresse, Quellpräfix der Zentrale, zulässige Kommunikationsrichtungen und Verantwortliche. Wählen Sie danach anhand der Kontrolle über statische Geräteadressen, der Portanforderungen der zentralen Anwendung, des tatsächlichen Protokollverhaltens, der Routerfunktionen und des Rückfallaufwands zwischen Umadressierung, statischem 1:1-NAT, statischer Portabbildung und NAT over VPN. Ein VPN schützt und transportiert Daten, macht identische private Adressen aber nicht automatisch eindeutig. Erst Tests von Rückweg, Tunnel- und Adressbindung, Wiederanlauf, Protokollierung und gemeinsamem Rollback belegen, dass eine Verbindung nicht am falschen Standort endet.

---

Zuerst die Adressüberschneidung als Ursache nachweisen

Private Adressen nach RFC 1918 dürfen in voneinander getrennten Adressräumen mehrfach vorkommen. Zwei nicht gekoppelte Maschinen können daher jeweils 192.168.1.0/24 verwenden. Sobald diese Netze in einer gemeinsamen Routing-Umgebung zusammenlaufen, müssen Überschneidung und Routing-Mehrdeutigkeit jedoch aufgelöst werden. Ein zentraler Router kann sonst nicht allein anhand der Zieladresse entscheiden, welche Maschine gemeint ist.

Der in RFC 2663 definierte „address realm“ beschreibt diese Grenze präzise: Dieselbe Adresse kann in verschiedenen Adressräumen unterschiedliche Hosts bezeichnen, doch die Kommunikation zwischen diesen Räumen benötigt eine eindeutige Routing- oder Übersetzungsgrenze. Die hier betrachteten IPsec-Standorttunnel stellen nur Transport und Schutz zwischen Standorten bereit. Meldet ein zentraler VPN-Hub zwei identische entfernte Netze an, ohne sie durch Richtlinien, Selektoren oder Adressübersetzung auseinanderzuhalten, bleibt das Routing mehrdeutig.

Prüfen Sie bei der Fehlersuche zuerst die zentrale Routingtabelle, die VPN-Richtlinien sowie die tatsächlich beobachteten Quell- und Zieladressen. Wenn zwei Tunnel 192.168.1.0/24 bekannt geben oder die SCADA zwei Maschinen unter derselben Ziel-IP führt, ist der strukturelle Konflikt bereits sichtbar. Ein erneuter Tunnelaufbau, ein SIM-Tausch oder längere SPS-Timeouts schaffen keine eindeutige Zielidentität.

Maschinenidentität und Übersetzungsverantwortung dokumentieren

Ein Adressplan darf nicht bei „SPS = 192.168.1.10“ enden. Für jedes Mapping gehören mindestens Standort-ID, Maschinenseriennummer, Gerätefunktion, lokale Schnittstelle, Original-IP mit Maske, zentrale Alias-IP, Quellpräfix der Zentrale, die am Standort sichtbare Quelladresse, freigegebene Protokolle und Ports, Kommunikationsrichtung, übersetzendes Gerät, Regelname, Routingtabelle oder VRF, VPN-Gegenstelle, Änderungsstand, Verantwortliche und Rückfallwert in eine gemeinsame Dokumentation. Asset- und Variablenlisten der Zentrale müssen Standort-ID, Originaladresse, Aliasadresse und Regelversion miteinander verknüpfen; das Vor-Ort-Team muss den vollständigen Pfad vor und nach der Übersetzung nachvollziehen können.

Angenommen, die SPS von Maschine A und Maschine B verwendet jeweils 192.168.1.10/24. In der Dokumentation kann Maschine A zentral als 192.0.2.10 und Maschine B als 198.51.100.10 erscheinen, jeweils gebunden an die Regel und den Tunnel ihres Standorts. Die Netze 192.0.2.0/24 und 198.51.100.0/24 sind gemäß RFC 5737 ausschließlich für Dokumentationsbeispiele reserviert. Sie dürfen nicht unverändert in einer realen Anlage eingesetzt werden. Für das Projekt sind freigegebene Adressen zu wählen, die im zentralen Routingbereich eindeutig sind und sich nicht mit bestehenden Kundennetzen überschneiden.

Standort	Maschine/Gerät	Lokale Originaladresse	Zentrale Aliasadresse	Regel und Tunnel
SITE-A	MACHINE-A / SPS	192.168.1.10/24	192.0.2.10	SITE-A-PLC-01 / VPN-A
SITE-B	MACHINE-B / SPS	192.168.1.10/24	198.51.100.10	SITE-B-PLC-01 / VPN-B

Die Konzeptgrafik zeigt nur Standort-Aliasadressen und bidirektionale Rückwege für den Fall, dass sich das Quellnetz der Zentrale nicht mit dem Maschinennetz überschneidet. Jeder Standort muss durch einen eigenen Router, eine eigene Tunnelschnittstelle oder einen separaten VRF-/Richtlinienkontext isoliert sein; Hin- und Rückweg müssen denselben NAT- und IPsec-Kontext durchlaufen. Nicht dargestellt sind die äußeren VPN-Endpunkte, konkrete Selektoren, die herstellerspezifische Verarbeitungsreihenfolge sowie Twice NAT bei einer zusätzlichen Überschneidung des zentralen Quellnetzes.

Die Tabelle ist bewusst ein Minimalbeispiel. Ein vollständiger Plan muss zwischen statischem Mapping eines einzelnen Hosts, einer Liste einzelner Geräte und der Abbildung eines ganzen Präfixes unterscheiden. Ob ein Router Netmap für vollständige Präfixe oder getrennte Routingbereiche unterstützt und wie viele Einträge möglich sind, ist herstellerspezifisch und darf nicht aus der bloßen Angabe „NAT wird unterstützt“ abgeleitet werden. Für HMIs, Antriebe und später hinzukommende Geräte sind außerdem Adresspool, Maske, Reserven und das Verfahren für neue Regeln festzulegen.

Eine eindeutige Zieladresse garantiert noch keinen funktionierenden Rückweg. RFC 5684 analysiert die Folgen überlappender privater Netze in VPN-Umgebungen. Verwendet beispielsweise auch die zentrale SCADA eine Quelladresse wie 192.168.1.20, hält die SPS in SITE-A das Antwortziel für einen lokalen Teilnehmer und versucht es per ARP zu erreichen, statt das Standardgateway zu verwenden. Dann genügt es nicht, nur 192.0.2.10 nach 192.168.1.10 umzusetzen. Erforderlich sind entweder eine Umadressierung, getrennte Adressräume oder – nach Prüfung auf dem vorgesehenen Gerät und Firmwarestand – eine kombinierte Ziel- und Quellübersetzung (DNAT und SNAT, also Twice NAT).

Szenario	Von der Zentrale erzeugtes Adresspaar	Nach Verarbeitung durch Router SITE-A	Bedingung für den Rückweg
Zentrales Quellnetz überschneidet sich nicht	203.0.113.20 → 192.0.2.10	203.0.113.20 → 192.168.1.10	Die SPS antwortet über ihr Standardgateway; die Rückübersetzung erfolgt im selben Kontext
Zentrale Quelle liegt ebenfalls in 192.168.1.0/24	192.168.1.20 → 192.0.2.10	203.0.113.20 → 192.168.1.10	Geprüfte DNAT- und SNAT-Regeln stellen beide Richtungen konsistent wieder her

Auch 203.0.113.0/24 ist ein RFC-5737-Dokumentationsnetz. In realen Projekten müssen alle drei Beispielbereiche durch freigegebene, konfliktfreie Adressen ersetzt werden. Schreiben Sie Quelle und Ziel, Protokoll und Port, Werte vor und nach NAT, Routingbereich, Tunnel und Rückweg als prüfbaren Paketpfad auf.

Der Adressplan muss außerdem festlegen, wer die Eindeutigkeit verwaltet. Wenn jeder Standort seine zentrale Aliasadresse selbst auswählt, verlagert sich der Konflikt lediglich von der Maschine in die Zentrale. Ein zentraler Adressplan sollte die sichtbaren Netze vergeben; Routerregeln, VPN-Hub, SCADA-Variablenliste und Änderungsnachweis müssen dieselbe Standort-ID referenzieren.

Umadressierung, statisches Mapping und NAT over VPN vergleichen

Umadressierung ist die direkteste Lösung, wenn der Maschinenbauer die Adressen von SPS, HMI und Antrieben sowie alle Protokollkonfigurationen über den gesamten Lebenszyklus kontrolliert. Jede Maschine erhält von Beginn an ein global eindeutiges Standortnetz. Die Zentrale verwendet normales Routing, die Ende-zu-Ende-Adressen bleiben sichtbar, und Paketmitschnitt sowie Fehlersuche werden einfacher. Dafür müssen statische Referenzen in SPS, HMI, Antrieben, Engineering-Projekten, Rezepturen und Fremdgeräten geändert werden. Bei bereits ausgelieferten Maschinen können Stillstandsfenster und Regressionstests teurer sein als eine zusätzliche NAT-Grenze.

Statisches 1:1-NAT ist eine mögliche Ausprägung des in RFC 3022 beschriebenen Basic NAT: Nur die IP-Adresse wird umgesetzt, und ein Gerät erhält dauerhaft eine eindeutige zentrale Aliasadresse. Basic NAT kann auch dynamische Abbildungen aus einem Adresspool umfassen und ist daher nicht mit statischem 1:1-NAT gleichzusetzen. Ein statisches 1:1-Mapping eignet sich, wenn die Maschinenvorlage unverändert bleiben muss, die Zentrale aber jede SPS wie einen eigenständigen Host ansprechen soll. Vor der Umsetzung sind bidirektionale Regeln, ARP und Routing, die Granularität des Adresspools, die Verarbeitungsreihenfolge und der Rückweg zu prüfen.

Statische Portabbildung übersetzt Adresse und Transportport und ist eine mögliche statische Eingangsregel einer NAPT-Funktion. Für eine von der SCADA initiierte Verbindung muss die Zuordnung „Protokoll + externe IP + externer Port → interne IP + interner Port“ fest und eindeutig sein. Gewöhnliches dynamisches Ausgangs-NAPT erzeugt diesen eingehenden Pfad nicht automatisch. Nutzt das reale Protokoll Broadcast- oder Multicast-Erkennung, dynamisch ausgehandelte Zusatzverbindungen oder Adressen in der Nutzlast, ist die Funktion anhand der Unterlagen des SPS- und Protokollherstellers gesondert zu validieren. Ein erfolgreicher Test des Hauptports reicht nicht aus. Auch die UDP-NAT-Anforderungen in RFC 4787 zeigen, dass Abbildung, Filterung und Zeitgeber zustandsbehaftet sind.

NAT over VPN ist kein von NAT unabhängiges Adressverfahren. Übersetzung, Routing und Tunnelrichtlinien müssen als ein gemeinsamer Datenpfad geprüft werden. Die Aussagen zu Selektoren, Security Associations (SA) und ESP beziehen sich hier auf IPsec-Standorttunnel; andere VPN-Verfahren sind nach ihrem eigenen Routing- und Richtlinienmodell zu bewerten. Ein IPsec Security Gateway nach RFC 4301 wählt geschützten Verkehr anhand von Richtlinien und Selektoren aus, während der ESP-Tunnelmodus nach RFC 4303 die Kapselung übernimmt. Gelangen zwei Standorte weiterhin als 192.168.1.0/24 in dieselbe zentrale Richtlinie, beseitigt die Verschlüsselung die Mehrdeutigkeit nicht. RFC 3715 beschreibt zudem Probleme, die aus der Kombination von NAT und IPsec entstehen können, darunter Selektoren, überlappende Richtlinien und Neuverhandlungen. Deshalb muss eindeutig feststehen, ob NAT vor oder nach der Tunnelverarbeitung erfolgt und ob die Selektoren die ursprünglichen oder die übersetzten Adressen verwenden.

Verfahren	Geeignet, wenn …	Hauptaufwand	Unbedingt zu prüfen
Umadressierung	Der OEM kontrolliert alle statischen Referenzen und Regressionstests	Geräte- und Projektänderungen, eventuell Stillstand	Alle Referenzen, Routing, Erkennung und Rollback
Statisches 1:1-NAT	Die Maschinenvorlage bleibt unverändert, die Zentrale braucht eindeutige IPs	Adresspool und bidirektionale statische Regeln	Mapping-Granularität, Reihenfolge, Rückweg, IP-Adressen in Nutzdaten
Statische Portabbildung	Wenige Dienste, zentrale Anwendung akzeptiert unterschiedliche Ports	Portliste und komplexeres zustandsbehaftetes Mapping	Statische Eingangsregel, Zusatzverbindungen, UDP-Zeitgeber, lesbare Logs
NAT over VPN	Mehrere Standorte laufen kontrolliert in einem Hub zusammen	NAT-, Routing- und Tunnelrichtlinien sind gekoppelt	Fünf-Tupel vor/nach NAT, Selektoren, Routingbereich, bidirektionale Wiederherstellung

Routing, Zugriffskontrolle und Protokollierung am Industrierouter bündeln

In der hier beschriebenen Topologie kann ein Industrierouter die Übersetzungsgrenze bilden, wenn das Zielmodell und der konkrete Firmwarestand die benötigten Funktionen nachweislich beherrschen. An dieser Grenze treffen die Originaladressen des Maschinennetzes, die übergeordnete beziehungsweise VPN-seitige Adressierung, Zugriffskontrolle und Verbindungszustand zusammen. Beschaffung und Labortest müssen statisches Mapping, Policy Routing oder getrennte Routingbereiche, Reihenfolge der Übersetzung, Rückweg, Trefferprotokolle, Kapazitätsgrenzen sowie Sicherung und Rollback der Konfiguration verifizieren. „NAT und VPN unterstützt“ belegt noch nicht, dass ein Gerät überlappende Netze korrekt verarbeitet.

Firewall-Regeln sollten den authentifizierten Gegenstellenbezug, eine stabile Tunnel- oder SA-Richtlinie, Schnittstelle oder VRF, zulässige Originalpräfixe, vergebene Aliasadressen, Richtung und minimal erforderliche Dienste miteinander verknüpfen. Die SPI ändert sich bei SA-Neuaufbau oder Rekeying; sie eignet sich für Laufzeitprotokolle und Ereigniskorrelation, nicht als dauerhafter Regelschlüssel. Nach den Eingangsregeln von RFC 4301 muss ein entschlüsseltes Paket verworfen und als prüfbares Ereignis protokolliert werden, wenn es nicht zu den Selektoren der zugehörigen SA passt. Ein falscher Tunnel darf keine Adressen eines anderen Standorts anmelden. Öffentliche Erreichbarkeit, VPN-Zugangsdaten und allgemeine Fernzugriffskontrollen bleiben ein eigenes Thema; hier geht es nur um die für doppelte Adressen und die Standorttrennung erforderlichen Grenzen.

Ein Protokolleintrag muss eine zentrale Verbindung bis zu Standort, Gegenstellenidentität, Tunnel, Adresse vor und nach NAT, Protokoll beziehungsweise Port und Regelname zurückverfolgen lassen. Die Meldung „VPN connected“ ohne Selektor-, Regel- und NAT-Treffer belegt nicht, dass ein Techniker die richtige Maschine erreicht. Auch Konfigurationsänderungen benötigen Versions- und Rückfallinformationen, damit SCADA-Variablenliste und Routerregeln nach einer Vor-Ort-Änderung nicht auseinanderlaufen.

Mit SCADA- und Vor-Ort-Tests eine Verwechslung der Standorte ausschließen

Führen Sie die Abnahme in einer reproduzierbaren Reihenfolge durch:

1. Prüfen Sie statisch, dass jede routbare Identität genau einem Standort oder Gerät zugeordnet ist: Bei 1:1-NAT ist es die Aliasadresse, bei Portabbildung „Protokoll + Alias + externer Port“ und bei getrennten Routingbereichen „VRF/Tunnel + Originalpräfix“. Verifizieren Sie außerdem die Fünf-Tupel vor und nach NAT, die Übereinstimmung von VPN-Selektoren und Mapping-Liste sowie das Standardgateway oder eine explizite Rückroute von SPS/HMI zur selben Grenze, die das Reverse NAT ausführt. In der SCADA darf kein Verbindungsziel doppelt verwendet werden; jeder Regelname muss die Standort-ID enthalten.

2. Verbinden Sie zunächst nur Maschine A und lesen Sie einen sicher identifizierbaren Nur-Lese-Wert. Eine Person vor Ort oder ein unabhängiger Protokolleintrag muss bestätigen, dass die Anfrage A erreicht hat. Trennen Sie anschließend A, verbinden Sie B und wiederholen Sie denselben Test.

3. Nehmen Sie A und B gleichzeitig in Betrieb. Testen Sie gemäß der freigegebenen Kommunikationsmatrix sowohl zentral initiierte Verbindungen als auch aktive Meldungen vom Standort. Kontrollieren Sie Rückweg, NAT-Protokolle und parallele Abfragen. Ein Ping genügt nicht; die tatsächlich verwendeten TCP-/UDP-Protokolle sowie gegebenenfalls Erkennung, Rückrufe und Zusatzverbindungen sind separat zu prüfen.

4. Führen Sie Negativtests durch: Senden Sie eine zulässige Adresse über den falschen Tunnel, täuschen Sie die Quelladresse eines anderen Standorts vor und greifen Sie auf einen nicht freigegebenen Port zu. Alle drei Versuche müssen verworfen werden; die Protokolle müssen Standort, Tunnel, Selektor und Regel zuordnen können.

5. Simulieren Sie den Ausfall eines einzelnen Standorts. Prüfen Sie den erneuten TCP-Verbindungsaufbau, UDP nach Ablauf der konfigurierten Leerlaufzeit sowie die bidirektionale Kommunikation nach einem IPsec-Rekey. Fällt Maschine A aus, muss eine Anfrage an A fehlschlagen oder in ein Timeout laufen. Sie darf niemals bei Maschine B ankommen.

6. Starten Sie Router oder VPN-Hub nur im Labor oder in einem genehmigten Wartungsfenster neu, wenn sich der Prozess in einem sicheren Zustand befindet, und testen Sie danach den gemeinsamen Rollback. Das versionierte, geprüfte Known-Good-Paket muss NAT, Routing, Tunnel, Zugriffskontrolle und SCADA-Variablenliste umfassen. Bei einem Fehler muss der Zugriff sicher gesperrt werden; anschließend ist die vollständige Prüfung gegen Standortverwechslung zu wiederholen.

Wenn das Protokoll Schreibzugriffe unterstützt, beginnen Sie in einer isolierten Umgebung oder in einem freigegebenen Wartungsfenster mit einem sicheren Objekt, das den Produktionszustand nicht verändert. Die Abnahme in der Produktion sollte standardmäßig nur lesend starten. NIST SP 800-82 Rev. 3 und der CISA-Leitfaden Configuring and Managing Remote Access for Industrial Control Systems betonen kontrollierten Zugriff, Überwachung und betriebliche Randbedingungen.

Eine wartbare und rückrollbare Lösung für das Zielmodell auswählen

Die derzeit geprüften Produktinformationen zu Wavetel WR143 und WR255 nennen Funktionskategorien wie NAT, VPN, statisches beziehungsweise richtlinienbasiertes Routing, Firewall sowie SNMP/RMS. Die Informationen zu WRTOS und RMS liefern zusätzlichen Hintergrund zu Verwaltung und zentraler Beobachtbarkeit. Diese Angaben eignen sich für eine erste Kandidatenliste, bestätigen aber weder statisches 1:1-Mapping und Netmap ganzer Präfixe noch VRF beziehungsweise mehrere Routingtabellen, NAT vor oder nach dem VPN, Mapping-Kapazität, Trefferprotokolle oder einen Ein-Klick-Rollback.

Wenn Sie einen Wavetel Industrierouter bewerten, stellen Sie dem Anbieter Ihr Beispiel mit doppelten Adressen, den zentralen Quell- und Zieladressplan, das reale SPS-Protokoll, die VPN-Topologie und die Anzahl paralleler Standorte zur Verfügung. Lassen Sie den Datenpfad und die Abnahmeliste auf dem vorgesehenen Firmwarestand vorführen. Entscheidend ist, dass sich jede Abbildung beobachten, auditieren und gemeinsam mit den zugehörigen Regeln zurückrollen lässt.

Häufig gestellte Fragen

Warum lassen sich zwei Maschinennetze mit 192.168.1.0/24 nicht direkt über dasselbe VPN routen?

Die Zentrale sieht dasselbe Zielpräfix zweimal und kann anhand der IP-Adresse nicht zwischen Maschine A und Maschine B wählen. Ein VPN schützt und transportiert den Verkehr, benötigt aber weiterhin eindeutige Routingobjekte, getrennte Adressräume oder eine explizite Übersetzung.

Wann ist eine Umadressierung besser als NAT?

Wenn der OEM alle Geräteadressen, statischen Referenzen und Testabläufe kontrolliert und dauerhaft transparente Ende-zu-Ende-Adressen wünscht, ist eine Umadressierung meist leichter zu verstehen und zu betreiben. Können ausgelieferte Anlagen nicht stillgesetzt werden, sind Fremdgeräte unveränderbar oder muss die Vorlage identisch bleiben, kann NAT sinnvoll sein. Dann müssen Mapping, Protokollierung und Rollback konsequent verwaltet werden.

Worin unterscheiden sich statisches 1:1-NAT und Portabbildung?

Beim statischen 1:1-NAT erhält ein Gerät eine feste übersetzte IP-Adresse; die Zentrale kann seine normalen Dienstports verwenden. Bei einer statischen Portabbildung teilen sich mehrere Geräte eine Adresse und werden über unterschiedliche Ports unterschieden. Dafür muss die zentrale Anwendung abweichende Ports unterstützen, und die eindeutigen Protokoll-/Portzuordnungen sowie das zustandsbehaftete Verhalten müssen dokumentiert werden.

Soll die zentrale SCADA die Originaladresse oder die übersetzte Adresse speichern?

Als Verbindungsziel nutzt die SCADA normalerweise die zentrale Aliasadresse. Asset-, Variablen- und Änderungsnachweise müssen jedoch Standort-ID, Originaladresse, Aliasadresse, Quellpräfix der Zentrale, die am Standort sichtbare Quelle und die Regelversion gemeinsam führen. Nur eine der beiden Adressen zu speichern reicht weder für die Erklärung des Rückwegs noch für eine belastbare Fehlersuche und Prüfung aus.

Kann ein VLAN allein mehrere SPS mit derselben IP-Adresse trennen?

Ein VLAN kann getrennte Layer-2-Broadcast-Domänen schaffen, erzeugt für eine zentrale SCADA aber nicht automatisch unterschiedliche Layer-3-Ziele. Soll die Zentrale mehrere SPS mit derselben Adresse gleichzeitig per Routing erreichen, braucht sie weiterhin eindeutige Aliasadressen, voneinander getrennte Routingbereiche oder eine geprüfte explizite Übersetzung.

Wie lässt sich nachweisen, dass ein Mapping nicht zur falschen Maschine führt?

Nehmen Sie zuerst jeden Standort einzeln und danach alle Standorte gleichzeitig in Betrieb. Prüfen Sie mit dem realen Protokoll beide Richtungen, Rückwege und Regelprotokolle. Ergänzen Sie Negativtests über einen falschen Tunnel, mit vorgetäuschter Standortquelle und auf nicht freigegebene Ports. Testen Sie danach in einem kontrollierten Wartungsfenster Ausfall, Rekeying, Neustart und gemeinsamen Rollback. Eine Anfrage an Maschine A darf bei deren Ausfall niemals Maschine B erreichen.