Ce guide accompagne pas à pas la mise en service d'un routeur MikroTik RouterOS, depuis « Access Gate dans le rack » jusqu'à « trafic OT circulant à travers la passerelle ». Vous connectez deux ports, attribuez à la passerelle une place sur le réseau, puis choisissez comment le trafic l'atteint. Aucune modification n'est apportée aux équipements OT. Les commandes sont en RouterOS 7.
Ce que vous allez construire
Access Gate est un équipement physique que vous câblez sur deux ports appartenant à deux sous-réseaux distincts : un port admin sur votre VLAN admin, et un port de protection sur un petit sous-réseau dédié qui porte 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 | Réseau depuis lequel la console web d'Access Gate est accessible |
| 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, routeur 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 équipement obtient un jumeau 1:1 |
| Sous-réseau OT | 192.168.1.0/24, PLC 192.168.1.10 (jumeau 100.64.1.10) | Équipements, inchangés |
| Zone DNS | secure.acme.corp, résolveur 100.65.0.6 | Noms des équipements |
1. Connectivité physique : deux ports, deux sous-réseaux
Placez le port admin et le port de protection sur des sous-réseaux différents afin que le trafic de gestion et le trafic acheminé ne partagent jamais le même domaine de diffusion. Adressez une interface pour l'admin, une pour la protection.
# 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"
Câblez ether5 sur le port admin (5) d'Access Gate et ether2 sur le port de protection (1). L'interface admin obtient un bail DHCP depuis le VLAN admin, ou se configure par défaut à 10.0.0.1 après environ une minute en l'absence de serveur DHCP ; définissez-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 équipement obtient un jumeau. Ajoutez une route pour que tout trafic à destination de cette plage soit transmis via 100.65.0.6, le port de protection d'Access Gate :
/ip route add dst-address=100.64.0.0/16 gateway=100.65.0.6 comment="Secure Twin overlay"
À lire ainsi : pour le réseau de destination 100.64.0.0/16, la passerelle (prochain saut) est 100.65.0.6. Dès lors, tout paquet adressé à une adresse jumeau (overlay) quitte le routeur, arrive sur Access Gate par son port de protection, et la passerelle le proxifie vers l'équipement réel ; atteindre une adresse overlay est donc ce qui fait 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'équipements en adresses overlay. Vous pouvez l'utiliser pour tout le trafic ou uniquement pour un sous-domaine.
-
Tout le trafic : distribuez le résolveur aux clients via DHCP :
/ip dhcp-server network set [find where address=192.168.1.0/24] dns-server=100.65.0.6 -
Sous-domaine uniquement : RouterOS transfère une zone unique via une entrée statique
FWD, de sorte que seulsecure.acme.corpest dirigé vers la passerelle et que tout le reste conserve votre résolveur existant :/ip dns static add type=FWD name=secure.acme.corp match-subdomain=yes forward-to=100.65.0.6Consultez Configuring Access Gate DNS pour le modèle DNS split-horizon.
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 : vous filtrez sur le point de départ du paquet. Le routage basé sur la destination sécurise ce qui va vers un équipement : vous filtrez sur sa destination. Utilisez l'un, l'autre, ou les deux, selon ce que vous voulez protéger. Dans les deux cas, l'Access Gate assure la traduction entre l'adresse réelle de l'équipement et son jumeau.
Basé sur la source : sécuriser ce qui vient du sous-réseau OT
/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
Chaque paquet qui quitte le sous-réseau OT est marqué puis routé vers la passerelle, quelle que soit sa destination. Une seule règle place tout le sous-réseau sous le Secure Twin sans toucher à aucun équipement. Il s'agit de la forme RouterOS du routage basé sur la source.
Basé sur la destination : sécuriser ce qui va vers un équipement
# La route overlay de l'étape 2 couvre déjà tous les jumeaux ; celle-ci se limite à un seul équipement
/ip route add dst-address=100.64.1.10/32 gateway=100.65.0.6 comment="jumeau du PLC uniquement"
Tout ce qui est adressé à un jumeau part vers la passerelle, quel que soit l'expéditeur. Aucune règle mangle nécessaire, c'est du routage par destination ordinaire. Consultez NAT de passerelle (L3).
5. Vérifier le chemin complet
Depuis un équipement OT, atteignez une destination exactement comme avant. Le routeur achemine désormais le flux à travers la passerelle à la sortie.
# from the OT device (192.168.1.10)
ping 192.168.2.20
Sur Access Gate, le flux apparaît dans 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.
Vous pouvez également tester le sens IT vers OT : depuis un client IT, atteignez un équipement OT par son adresse jumeau ou son nom DNS (ping 100.64.1.10). La route overlay achemine ce paquet vers la passerelle, qui le proxifie vers l'équipement réel.
Ce qui réside où
Le routeur ne contient qu'une seule chose : une règle qui dit, en substance, « ces paquets, transmets-les à ce prochain saut ». Qu'elle porte sur la source ou sur la destination, elle est statique.
Tout le reste réside sur 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 RouterOS, et rien n'y est configuré.
Cette séparation mérite d'être explicitée à l'équipe réseau, car « nous devons configurer votre routeur » semble alarmant jusqu'à ce qu'ils voient qu'il s'agit d'une règle de transfert, non d'un moteur de politique. Leur processus de gestion des changements ne verra qu'une ou deux règles, une seule fois.
Récapitulatif
Vous avez adressé deux interfaces RouterOS sur deux sous-réseaux (VLAN admin + protection /29), placé la passerelle à 100.65.0.6, routé l'overlay vers elle, pointé le DNS vers son résolveur, et acheminé le trafic par la source, par la destination, ou les deux. Le trafic OT circule désormais à travers Access Gate sans aucune modification sur les équipements.