Plusieurs automates PLC utilisent la même adresse IP : comment concevoir le NAT et le VPN ?

Quand un constructeur livre plusieurs machines à partir du même modèle d'adressage PLC/HMI, chacune doit recevoir une identité unique visible depuis le système central. Cette identité peut être obtenue par renumérotation, par traduction statique ou par une traduction intégrée au VPN, mais elle doit toujours produire un chemin aller-retour sans ambiguïté. Sinon, après le raccordement de plusieurs machines au même SCADA central, l'adresse 192.168.1.10 ne suffit plus à désigner le bon automate : le VPN peut être établi alors que le PLC reste inaccessible, voire que la connexion atteint le mauvais site.

Points essentiels

Le conflit apparaît lorsque plusieurs domaines d'adressage identiques sont réunis. Il faut d'abord inventorier l'identifiant du site, le rôle de l'équipement, son adresse d'origine, son alias visible depuis le centre, le préfixe source central, les flux autorisés et le responsable de la règle. Le choix entre renumérotation, NAT statique 1:1, redirection statique de ports et NAT over VPN dépend ensuite de la maîtrise des adresses par l'OEM, des ports acceptés par l'application centrale, du comportement réel du protocole, des fonctions du routeur et du coût de retour arrière. Un VPN protège et transporte les paquets, mais ne rend pas automatiquement uniques des adresses privées identiques. Seuls des essais du chemin retour, de l'association entre tunnel et adresse, de la reconnexion, des journaux et du rollback complet permettent de démontrer qu'un site ne sera pas confondu avec un autre.

---

Vérifier que le conflit vient des adresses, et non du VPN ou du PLC

Les adresses privées définies par la RFC 1918 peuvent être réutilisées dans des domaines isolés. Deux machines non interconnectées peuvent donc employer le même réseau 192.168.1.0/24. Dès que ces domaines rejoignent un environnement routable commun, le chevauchement doit être résolu : avec la seule adresse de destination, le routeur central ne peut pas choisir la bonne machine.

La notion d'address realm de la RFC 2663 précise cette frontière. Une même adresse peut représenter des hôtes différents dans deux domaines, mais leur interconnexion exige une limite explicite de traduction ou de routage. Dans l'architecture étudiée ici, le tunnel IPsec de site à site assure le transport et la protection. Si le concentrateur VPN reçoit de deux tunnels le même réseau distant 192.168.1.0/24, sans politique, sélecteur ni traduction permettant de les distinguer, l'ambiguïté de routage demeure.

Le diagnostic doit donc commencer par la table de routage centrale, les politiques VPN et les adresses source et destination observées dans les paquets. Deux tunnels qui annoncent le même préfixe, ou deux équipements SCADA configurés avec la même cible, révèlent un défaut structurel. Reconstruire le tunnel, remplacer la carte SIM ou augmenter le délai de communication du PLC ne crée aucune identité unique.

Établir l'identité de chaque machine et la responsabilité de chaque traduction

Une documentation qui indique seulement « PLC : 192.168.1.10 » est insuffisante. Pour chaque objet traduit, l'inventaire doit au minimum préciser l'identifiant du site, le numéro de série de la machine, le rôle de l'équipement, l'interface locale, l'adresse et le masque d'origine, l'alias central, le préfixe source central, l'adresse source vue par le site, les protocoles et ports autorisés, le sens du flux, l'équipement qui réalise la traduction, le nom de la règle, la table de routage ou la VRF, le pair VPN, la version du changement, le responsable et la valeur de rollback. L'inventaire des actifs et la table des points SCADA doivent relier l'identifiant du site, l'adresse d'origine, l'alias central et la version de règle ; l'équipe locale doit pouvoir reconstituer tout le chemin avant et après traduction.

Supposons que les PLC des machines A et B utilisent tous deux 192.168.1.10/24. La documentation peut attribuer 192.0.2.10 à la machine A et 198.51.100.10 à la machine B côté central, chaque alias étant lié à une règle et à un tunnel propres au site. Les blocs 192.0.2.0/24 et 198.51.100.0/24 sont des adresses réservées à la documentation par la RFC 5737. Ils ne doivent pas être repris en production : le projet doit choisir des adresses approuvées par l'organisation, uniques dans le domaine de routage central et sans conflit avec les réseaux existants du client.

Site	Machine / équipement	Adresse locale d'origine	Alias visible depuis le centre	Règle et tunnel
SITE-A	MACHINE-A / PLC	192.168.1.10/24	192.0.2.10	SITE-A-PLC-01 / VPN-A
SITE-B	MACHINE-B / PLC	192.168.1.10/24	198.51.100.10	SITE-B-PLC-01 / VPN-B

Ce schéma conceptuel illustre uniquement les alias de site et le chemin retour lorsque l'adresse source centrale ne chevauche pas le réseau des machines. Chaque site doit être isolé par son propre routeur, son interface de tunnel ou son contexte VRF/de politique, et les deux sens du flux doivent traverser le même contexte NAT et IPsec. Le dessin ne représente ni les extrémités externes du VPN, ni les sélecteurs précis, ni l'ordre d'exécution propre au constructeur, ni le Twice NAT requis lorsque la source centrale chevauche le réseau local.

Ce tableau est volontairement minimal. L'inventaire réel doit distinguer la traduction statique d'un hôte, le suivi de chaque équipement et la traduction d'un préfixe entier. Le netmap d'un sous-réseau complet, l'emploi de domaines de routage séparés et les limites de capacité sont des fonctions propres à chaque produit ; elles ne peuvent pas être déduites de la simple mention « NAT pris en charge ». Il faut également réserver des plages, masques et adresses pour les HMI, variateurs ou futurs équipements, ainsi que définir la procédure d'ajout de règles.

Une destination unique ne garantit pas encore un chemin retour correct. La RFC 5684 sur les espaces d'adressage qui se chevauchent décrit les anomalies de connectivité et d'identité qui peuvent apparaître avec des réseaux privés superposés et un VPN. Si le SCADA central utilise lui aussi l'adresse source 192.168.1.20, par exemple, le PLC de SITE-A considérera la destination de sa réponse comme locale et lancera une requête ARP au lieu d'envoyer le paquet à sa passerelle. Traduire seulement la destination 192.0.2.10 en 192.168.1.10 ne suffit alors plus. Il faut renuméroter, isoler les domaines d'adressage ou, après validation sur le modèle et le firmware ciblés, appliquer simultanément DNAT et SNAT — un Twice NAT.

Scénario	Couple d'adresses émis par le centre	Paquet après traitement par le routeur de SITE-A	Condition du chemin retour
La source centrale ne chevauche pas le réseau local	203.0.113.20 → 192.0.2.10	203.0.113.20 → 192.168.1.10	Le PLC répond via sa passerelle par défaut ; la traduction inverse est appliquée dans la même session
La source centrale appartient aussi à 192.168.1.0/24	192.168.1.20 → 192.0.2.10	203.0.113.20 → 192.168.1.10	DNAT et SNAT, préalablement validés, sont tous deux annulés sur le trajet retour

Les réseaux 192.0.2.0/24, 198.51.100.0/24 et 203.0.113.0/24 sont tous réservés aux exemples par la RFC 5737. En production, ils doivent être remplacés par des plages approuvées et non conflictuelles. Le packet walk doit consigner la source, la destination, le protocole et le port, les valeurs avant et après traduction, le domaine de routage, le tunnel et le chemin retour.

L'inventaire doit enfin préciser qui garantit l'unicité. Si chaque site choisit seul ses alias centraux, le conflit sera simplement déplacé vers le réseau central. Un plan d'adressage unique doit attribuer les plages visibles depuis le centre, tandis que les règles des routeurs industriels, le concentrateur VPN, la table des points SCADA et les dossiers de changement utilisent tous le même identifiant de site.

Comparer la renumérotation, la traduction statique et le NAT over VPN

La renumérotation est la solution la plus directe lorsque l'OEM maîtrise les adresses PLC/HMI, les paramètres des protocoles et la maintenance sur tout le cycle de vie. Chaque machine reçoit dès sa livraison un sous-réseau de site unique. Le centre utilise un routage normal, les adresses restent visibles de bout en bout et les captures de paquets sont plus simples à interpréter. En contrepartie, il faut modifier toutes les références statiques dans les PLC, HMI, variateurs, outils d'ingénierie, recettes et équipements tiers. Pour une machine déjà livrée, l'arrêt et les tests de régression peuvent coûter davantage que l'ajout d'une traduction.

La traduction statique 1:1 est une configuration possible du Basic NAT décrit par la RFC 3022 : seule l'adresse IP est traduite et un alias central fixe est réservé à un équipement. Le Basic NAT peut aussi employer un pool d'adresses attribuées dynamiquement ; il ne faut donc pas le confondre avec le seul NAT statique 1:1. Cette méthode convient lorsqu'il est impossible de modifier le modèle réseau de la machine, mais que le centre doit joindre chaque PLC comme un hôte distinct. Avant déploiement, il faut valider les règles statiques dans les deux sens, l'ARP et le routage, la granularité du pool, l'ordre des traductions et le chemin retour.

La redirection statique de ports traduit à la fois l'adresse et l'identifiant de transport. Elle peut être considérée comme une configuration entrante statique d'une fonction NAPT. Pour une connexion initiée par le SCADA central, il faut réserver une correspondance unique « protocole + IP externe + port externe → IP interne + port interne ». Un NAPT sortant dynamique ordinaire ne crée pas automatiquement cette entrée. Si le protocole réel dépend d'une découverte en broadcast ou multicast, négocie des connexions supplémentaires ou transporte des adresses dans sa charge utile, sa compatibilité doit être vérifiée dans la documentation du PLC et du protocole. La réussite sur le port principal ne suffit pas. Les exigences de mapping UDP de la RFC 4787 montrent en outre qu'une traduction de ports dépend de règles de mapping, de filtrage et de temporisation ; ce n'est pas un câble statique et sans état.

Le NAT over VPN n'est pas une autre famille de traduction. Il consiste à valider ensemble le NAT, le routage et les politiques du tunnel. L'analyse des sélecteurs, des associations de sécurité et d'ESP présentée ici concerne un VPN IPsec de site à site ; les autres VPN doivent être étudiés selon leur propre modèle de routage et de politique. Dans l'architecture de sécurité IPsec de la RFC 4301, les politiques et sélecteurs déterminent le trafic protégé, tandis que le mode tunnel ESP de la RFC 4303 assure l'encapsulation. Si deux sites présentent encore 192.168.1.0/24 au moment où les politiques centrales sont évaluées, le chiffrement ne lève pas l'ambiguïté. La RFC 3715 décrit aussi les difficultés de sélecteurs, de politiques qui se chevauchent et de renégociation lorsque NAT et IPsec sont combinés. Il faut donc établir si la traduction intervient avant ou après le tunnel, et si les sélecteurs portent sur les adresses avant ou après traduction.

Solution	Conditions favorables	Coût principal	Points à valider
Renumérotation	L'OEM maîtrise toutes les références statiques et les tests de régression	Modification des équipements et fichiers d'ingénierie, avec arrêt possible	Toutes les références, le routage, la découverte et le rollback
Traduction statique 1:1	Le modèle de la machine ne peut pas changer et le centre exige une IP unique	Gestion d'un pool d'alias et de règles statiques bidirectionnelles	Granularité, ordre des traductions, chemin retour, adresses dans la charge utile
Redirection statique de ports	Peu de services, et l'application centrale accepte des ports différents	Inventaire des ports et état NAT plus complexes	Règle entrante, connexions supplémentaires, temporisation UDP, lisibilité des journaux
NAT over VPN	Plusieurs sites convergent vers un concentrateur contrôlé	Couplage du NAT, du routage et des politiques de tunnel	Quintuplets avant/après, sélecteurs, domaine de routage, restauration dans les deux sens

Ancrer routage, contrôle d'accès et journaux à la frontière du routeur industriel

Dans cette topologie, un routeur industriel qui possède les fonctions nécessaires et qui a été validé avec le firmware ciblé peut servir de frontière de traduction. Il voit les adresses d'origine côté machine, les adresses côté amont ou VPN, les contrôles d'accès et l'état des liaisons. Les achats et les essais en laboratoire doivent néanmoins confirmer la traduction statique, le routage par politique ou l'isolation des domaines, l'ordre des opérations, le chemin retour, les journaux de règles, les limites de capacité ainsi que la sauvegarde et le rollback de la configuration. La mention « NAT et VPN pris en charge » ne prouve pas qu'un équipement sait gérer des sous-réseaux superposés.

Les règles de pare-feu doivent associer l'identité authentifiée du pair, la politique stable du tunnel ou de la SA, l'interface ou la VRF, le préfixe d'origine autorisé, l'alias central attribué, le sens du flux et l'ensemble minimal de services. Le SPI change lorsque la SA est recréée ou renouvelée ; il convient aux journaux et à la corrélation d'événements en exploitation, mais pas comme clé durable d'une règle. Selon le traitement entrant défini par la RFC 4301, un paquet déchiffré qui ne correspond pas aux sélecteurs de sa SA doit être rejeté et produire un événement auditable. Un tunnel ne doit jamais pouvoir annoncer l'adresse d'un autre site. Les questions générales d'exposition publique, de gestion des identifiants VPN et d'accès distant restent distinctes : ici, la frontière est limitée aux adresses superposées et à la prévention des erreurs de site.

Les journaux doivent permettre de relier une connexion centrale au site, à l'identité du pair, au tunnel, aux adresses avant et après traduction, au protocole, au port et au nom de la règle. Un simple état « VPN connected », sans sélecteur, règle appliquée ni trace de traduction, ne prouve pas que l'ingénieur a joint la bonne machine. Les changements de configuration doivent eux aussi disposer d'une version et d'une valeur de rollback afin d'éviter que la table SCADA et les règles du routeur divergent après une intervention locale.

Prouver avec le SCADA et le site qu'aucune connexion ne croise les machines

La recette doit suivre une séquence reproductible :

1. Vérifier statiquement que chaque identité routable ne correspond qu'à un seul site ou équipement : l'alias pour le NAT 1:1, le triplet « protocole + alias + port externe » pour une redirection de port, ou le couple « VRF/tunnel + préfixe d'origine » pour des domaines de routage isolés. Contrôler aussi les quintuplets avant et après traduction, les sélecteurs VPN, la passerelle par défaut du PLC/HMI ou sa route de retour explicite vers la même frontière NAT, l'absence de cible SCADA dupliquée et la présence de l'identifiant du site dans le nom de la règle.

2. Connecter uniquement la machine A et lire une valeur en lecture seule qui permet de l'identifier sans danger. Un opérateur local ou un journal indépendant doit confirmer que la requête atteint bien A. Déconnecter ensuite A, connecter B et répéter le test.

3. Mettre A et B en ligne simultanément. À partir de la matrice des flux autorisés, tester les sessions initiées par le centre et les remontées initiées sur site ; contrôler le chemin retour, les journaux de traduction et l'interrogation simultanée. Un ping ne suffit pas : les protocoles TCP/UDP réellement utilisés doivent être testés, ainsi que la découverte, les callbacks et les connexions supplémentaires lorsqu'ils existent.

4. Exécuter des essais négatifs : envoyer une adresse pourtant valide depuis le mauvais tunnel, usurper l'adresse source d'un autre site et viser un port non autorisé. Ces trois flux doivent être rejetés, avec un journal qui les rattache au site, au tunnel, aux sélecteurs et à la règle.

5. Simuler la perte d'un site puis valider la reconnexion TCP, le rétablissement UDP après expiration de la temporisation configurée et la communication bidirectionnelle après un rekey IPsec. Quand la machine A est hors ligne, les requêtes qui lui sont destinées doivent échouer ou expirer ; elles ne doivent jamais aboutir sur B.

6. Redémarrer le routeur ou le concentrateur VPN et exécuter le rollback complet uniquement en laboratoire ou pendant une fenêtre de maintenance approuvée, avec le procédé dans un état sûr. Le bundle known-good doit être versionné, déjà vérifié et contenir le NAT, le routage, les tunnels, le contrôle d'accès et la table des points SCADA. En cas d'échec, le système doit se fermer de manière sûre, puis tous les tests anti-confusion doivent être rejoués.

Si le protocole autorise des écritures, la validation doit commencer dans un environnement isolé ou pendant une fenêtre approuvée, sur un objet qui ne modifie pas l'état du procédé. En production, la recette commence par des opérations en lecture seule. Le NIST SP 800-82 Rev. 3 et le guide CISA Configuring and Managing Remote Access for Industrial Control Systems insistent tous deux sur le contrôle des accès, la supervision et les contraintes d'exploitation.

Choisir un modèle qui reste observable et réversible

Les pages actuelles des Wavetel WR143 et WR255 indiquent des catégories de fonctions telles que NAT, VPN, routage statique et par politique, pare-feu, SNMP et RMS. Les présentations de WRTOS et RMS apportent également un contexte sur l'administration et l'observabilité centralisées. Ces informations permettent de dresser une liste de candidats, mais elles ne confirment publiquement ni la traduction statique 1:1, ni le netmap d'un préfixe, ni la VRF ou plusieurs tables de routage, ni l'ordre NAT/VPN, ni la capacité de mapping, ni les journaux de règles, ni un rollback en un clic.

Si vous évaluez la gamme de routeurs cellulaires industriels Wavetel, transmettez au fournisseur un exemple d'adresses superposées, le plan des sources et destinations centrales, les protocoles PLC réels, la topologie VPN et le nombre de sites simultanés. Demandez une démonstration, sur le firmware ciblé, fondée sur le même packet walk et la même liste de recette. Le choix final doit dépendre de la capacité à observer, auditer et annuler chaque traduction comme un ensemble cohérent.

FAQ

Pourquoi deux machines en 192.168.1.0/24 ne peuvent-elles pas être routées directement dans le même VPN ?

Parce que le centre voit le même préfixe de destination et ne peut pas sélectionner la machine A ou B à partir de la seule adresse IP. Le VPN transporte et protège les paquets, mais il faut encore un objet de routage unique, des domaines séparés ou une traduction explicite.

Quand faut-il renuméroter plutôt qu'utiliser le NAT ?

La renumérotation est généralement plus lisible lorsque l'OEM maîtrise toutes les adresses, les références statiques et le processus de test, et qu'il souhaite conserver des adresses transparentes de bout en bout. Si un équipement tiers ne peut pas être modifié, si une machine déjà livrée ne peut pas être arrêtée ou si le modèle doit rester identique, le NAT peut être envisagé, au prix d'une gestion supplémentaire des mappings, journaux et rollbacks.

Quelle différence entre une traduction statique 1:1 et une redirection de ports ?

La traduction 1:1 attribue à un équipement une adresse traduite fixe, tout en conservant ses ports de service habituels côté central. La redirection de ports permet à plusieurs équipements de partager une adresse en les distinguant par leurs ports. Elle suppose que l'application centrale accepte ces ports différents et exige un inventaire unique des protocoles et ports externes ainsi qu'un suivi de l'état NAT.

Le SCADA central doit-il enregistrer l'adresse d'origine du PLC ou son alias ?

Les paramètres de connexion centraux utilisent généralement l'alias visible depuis le centre. L'inventaire des actifs, la table des points et le journal des changements doivent toutefois relier l'identifiant du site, l'adresse d'origine, l'alias, le préfixe source central, l'adresse source observée sur site et la version de règle. Conserver une seule adresse ne permet pas d'expliquer le chemin retour et affaiblit le diagnostic comme l'audit.

Un VLAN suffit-il à résoudre le problème de plusieurs PLC portant la même adresse IP ?

Un VLAN isole un domaine de diffusion de niveau 2, mais il ne crée pas automatiquement des destinations de niveau 3 différentes pour le SCADA central. Si le centre doit joindre simultanément plusieurs PLC portant la même adresse, il faut encore des alias uniques, des domaines de routage isolés ou une traduction explicite préalablement validée.

Comment vérifier qu'une traduction ne conduit jamais à la mauvaise machine ?

Testez d'abord chaque site séparément, puis tous les sites simultanément avec les protocoles réels, le chemin retour et les journaux de règles. Ajoutez des essais depuis le mauvais tunnel, avec une adresse de site usurpée et vers un port non autorisé. Enfin, pendant une fenêtre contrôlée, validez la perte de liaison, le rekey, le redémarrage et le rollback complet. Une requête destinée à la machine A ne doit jamais atteindre B lorsque A est hors ligne.