Ce guide accompagne le déploiement d'un appliance de sécurité Meraki MX (avec un switch MS) depuis « Access Gate dans le rack » jusqu'à « trafic OT circulant à travers la passerelle », de bout en bout, entièrement depuis le Dashboard. Vous connectez deux ports, attribuez une place à la passerelle sur le réseau et choisissez comment le trafic l'atteint. Aucune modification n'est apportée aux équipements OT.
Ce que vous allez construire
L'Access Gate est un appliance physique que vous câblez à deux ports sur deux sous-réseaux différents : un port admin sur votre VLAN admin, et un port de protection sur un petit sous-réseau dédié qui transporte le trafic que vous acheminez à travers la passerelle.
Laboratoire de référence
| Élément | Adresse | Rôle |
|---|---|---|
| VLAN admin | 192.168.254.0/24 (VLAN 254) | Accès à la console web d'Access Gate |
| Port admin d'Access Gate (5) | DHCP, ou 192.168.254.50 | Interface de gestion |
| Sous-réseau de protection | 100.65.0.0/29 (VLAN 65), MX 100.65.0.1 | Lien point à point vers la passerelle |
| Port de protection d'Access Gate (1) | 100.65.0.6 | Trafic entrant/sortant, overlay et résolveur DNS |
| Overlay Secure Twin | 100.64.0.0/16 | Espace parallèle ; chaque asset reçoit un jumeau 1:1 |
| Sous-réseau OT | 192.168.1.0/24, PLC 192.168.1.10 (jumeau 100.64.1.10) | Assets, inchangés |
| Zone DNS | secure.acme.corp, résolveur 100.65.0.6 | Noms des assets |
1. Connectivité physique : deux ports, deux VLANs
Placez le port admin et le port de protection sur des VLANs différents afin que le trafic de gestion et le trafic acheminé ne partagent jamais le même domaine de diffusion.
- Créez les VLANs dans Security & SD-WAN → Configure → Addressing & VLANs :
- VLAN 254 :
192.168.254.0/24, IP MX192.168.254.1(admin). - VLAN 65 :
100.65.0.0/29, IP MX100.65.0.1(protection).
- VLAN 254 :
- Affectez les ports du switch dans Switch → Ports sur le MS :
- Port d'accès en VLAN 254 → câblé au port admin (5) d'Access Gate.
- Port d'accès en VLAN 65 → câblé au port de protection (1) d'Access Gate.
L'interface admin obtient un bail DHCP depuis le VLAN admin, ou prend par défaut l'adresse 10.0.0.1 après environ une minute en l'absence de serveur DHCP ; configurez-la en statique à 192.168.254.50 depuis la console si vous préférez une adresse fixe.
2. Ajouter une route vers l'overlay
Le Secure Twin réside dans l'overlay 100.64.0.0/16, l'espace d'adressage parallèle où chaque asset reçoit un jumeau. Ajoutez une route statique dans Security & SD-WAN → Configure → Routing (Static routes) afin que tout trafic à destination de cette plage soit transmis à 100.65.0.6, le port de protection d'Access Gate :
- Sous-réseau :
100.64.0.0/16 - IP du prochain saut :
100.65.0.6
À partir de là, tout paquet adressé à une adresse jumeau (overlay) est envoyé à l'Access Gate sur son port de protection, et la passerelle le proxifie vers l'équipement réel. Atteindre une adresse jumeau suffit donc à faire passer le flux à travers la passerelle.
3. Pointer le DNS vers Access Gate
La passerelle héberge un résolveur à 100.65.0.6 qui traduit les noms d'assets en adresses overlay. Vous pouvez l'utiliser pour tout le trafic ou uniquement pour un sous-domaine.
- Tout le trafic : dans Addressing & VLANs, modifiez le DHCP du VLAN OT et définissez Custom nameservers sur
100.65.0.6. Tous les équipements de ce VLAN résolvent alors via la passerelle. - Sous-domaine uniquement : le MX ne prend pas en charge le transfert conditionnel par zone ; conservez votre DNS existant et ajoutez un redirecteur conditionnel pour
secure.acme.corp → 100.65.0.6sur votre serveur DNS de site (Windows DNS, BIND ou Infoblox). Voir Configuring Access Gate DNS.
4. Acheminer le trafic à travers la passerelle
Deux façons d'amener le trafic vers la passerelle. Le routage basé sur la source sécurise ce qui **vient d'**un réseau. Le routage basé sur la destination sécurise ce qui va vers un équipement. Dans les deux cas, l'Access Gate assure la traduction entre l'adresse réelle de l'équipement et son jumeau.
Sur Meraki, utilisez le routage basé sur la destination. C'est une seule route statique, le comportement est identique sur MX et MS, et cela couvre tous les clients de tous les VLAN. Le MX propose aussi une option basée sur la source, mais elle ne concerne que le trafic pour lequel le MX n'a pas de route : elle n'amènera donc pas vers la passerelle le trafic OT destiné à vos autres VLAN locaux.
Basé sur la destination : sécuriser ce qui va vers un équipement (à privilégier)
La route overlay de l'étape 2 couvre déjà tous les jumeaux. Pour ne viser qu'un équipement, ajoutez une Static Route dans Security & SD-WAN → Configure → Routing :
- Subnet :
100.64.1.10/32 - Next hop IP :
100.65.0.6 - Active : Always active
Atteignez un équipement par son adresse jumeau ou son nom DNS et le flux passe par la passerelle, quel que soit l'expéditeur. C'est le schéma NAT de passerelle (L3).
Deux points à ne pas manquer. La plage de jumeaux ne doit chevaucher aucun VLAN détenu par le MX ni aucune route statique existante : les routes connectées et les routes plus spécifiques l'emportent, et le trafic contournerait discrètement la passerelle. Et laissez Active sur Always active : avec le suivi par ping, une passerelle qui cesse de répondre retire la route, le trafic bascule sur le chemin par défaut, et vous obtenez un contournement silencieux au lieu d'une coupure franche.
Lorsque vous pouvez modifier l'adressage d'un équipement, la modification des IP migre un équipement à la fois sans aucun changement de routage.
Basé sur la source : sécuriser ce qui vient du sous-réseau OT
Le MX ne fait pas de policy-based routing sur le LAN, mais il propose le source-based default routing (MX 15.4+, VLAN activés). Dans Security & SD-WAN → Configure → Addressing & VLANs, choisissez Add source-based route, sélectionnez le VLAN OT, réglez le type de prochain saut sur LAN et l'adresse sur 100.65.0.6.
Lisez la limite avant de vous y fier : une route par défaut basée sur la source ne s'applique qu'aux destinations pour lesquelles le MX n'a pas de route, et elle vise le VLAN entier, pas un hôte. Elle couvre le trafic qui quitte le site. Elle ne couvre pas les échanges OT vers IT à l'intérieur, puisque le VLAN IT figure déjà dans la table de routage.
Pour les flux est-ouest OT vers IT, atteignez le service IT par son jumeau, ou terminez le sous-réseau OT sur un équipement L3 en amont, un commutateur Catalyst ou un FortiGate, et appliquez-y le routage basé sur la source.
Déplacement de la passerelle : l'Access Gate devient la passerelle du sous-réseau
L'option la plus forte, et la plus intrusive. Retirez le VLAN OT de la table d'adressage du MX et terminez ce sous-réseau sur l'Access Gate. La passerelle devient la gateway des hôtes de l'enclave et leur fournit le DHCP. Sur le MX, ajoutez une route statique pour le sous-réseau de l'enclave pointant vers l'adresse de transit de la passerelle. Si c'est votre stack MS qui détient l'interface VLAN, retirez-la de ce côté et routez le sous-réseau vers la passerelle via un VLAN de transit.
Cela impose un contrôle sur tout ce qui quitte l'enclave, inter-VLAN compris, sans dépendre de l'adressage par jumeau. Cela nécessite une fenêtre de maintenance et fait de l'Access Gate une dépendance forte pour ce sous-réseau : réservez-le donc aux enclaves petites et clairement délimitées.
5. Vérifier le chemin complet
Depuis un équipement OT, atteignez un asset par son nom DNS ou son adresse jumeau :
ping plc-line-1.secure.acme.corp # from a client that resolves via 100.65.0.6
Sur l'Access Gate, le flux apparaît sous son enclave avec l'identité overlay de l'équipement (100.64.1.10) ; l'identité, la politique et le chiffrement s'appliquent avant que le paquet soit transmis, et la réponse est NATée vers l'équipement réel.
Lancez ensuite un traceroute vers l'adresse réelle de l'équipement. Il ne doit pas passer par la passerelle. C'est le comportement attendu, et cela vous indique exactement le contournement qui subsiste : tout ce qui continue d'utiliser l'adresse réelle échappe au contrôle. Testez depuis un client à l'intérieur du VLAN, pas depuis le dashboard Meraki.
Ce qui réside où
Le MX ne contient qu'un seul élément : une route statique qui dit, en substance, « trafic pour la plage overlay, transmets-le à ce prochain saut. » Elle est statique. Vous l'écrivez une fois et n'y touchez plus jamais, même lorsque la politique d'enclave change d'une semaine à l'autre.
Tout le reste réside sur l'Access Gate : authentification, ACL d'enclave, proxification, injection de credentials, enregistrement de sessions, terminaison TLS et journalisation. Rien de tout cela n'est exprimable sur le MX, et rien n'y est configuré.
Cette séparation mérite d'être explicitée à l'équipe réseau, car « nous devons modifier votre appliance de sécurité » semble alarmant jusqu'à ce qu'ils constatent qu'il s'agit d'une règle de transfert, pas d'un moteur de politique. Leur gestion des changements ne voit qu'une route, une seule fois.
Récapitulatif
Vous avez créé deux VLANs sur le MX, câblé la passerelle à deux ports MS sur deux sous-réseaux (VLAN admin + protection /29), adressé la passerelle à 100.65.0.6, routé l'overlay vers elle, pointé le DNS vers son résolveur et acheminé le trafic par destination. Le trafic OT circule désormais à travers l'Access Gate sans aucune modification des assets.