Ce document donne un exemple de configuration de systèmes réseau existants pour répondre à ce cas d'usage précis. Il ne constitue ni un standard ni une intégration officiellement prise en charge pour Access Gate.
Dans certains cas, modifier une IP de destination ou faire du NAT au niveau du routeur n'est pas envisageable. Il est alors possible de tirer parti d'un VLAN privé et du proxy ARP pour déployer l'overlay sécurisé d'Access Gate sans modifier les équipements finaux, leur passerelle ou leur routage.
Les équipements continuent de se comporter comme s'ils dialoguaient avec un voisin sur le même sous-réseau, tandis que chaque paquet est discrètement acheminé à travers l'overlay pour l'application des politiques.
L'objectif
Les équipements OT et IT anciens ne peuvent pas être reconfigurés à la légère. Il est souvent impossible de changer l'IP d'un PLC, d'y installer un agent, d'ajouter une route statique ou de le pointer vers une nouvelle passerelle, que ce soit parce que le fournisseur l'interdit, parce que la fenêtre de maintenance n'existe pas, ou tout simplement parce que l'équipement est antérieur à cette idée. Or ce sont précisément ces actifs qu'il faut protéger, et le trafic Est-Ouest entre eux est précisément ce qu'un réseau à plat laisse grand ouvert.
La redirection du trafic résout ce problème au niveau 2. Deux équipements sur le même sous-réseau font normalement une résolution ARP l'un vers l'autre et commutent leurs trames directement, à l'abri de tout contrôle de sécurité. Trout s'insère dans cet échange en répondant à l'ARP à la place de la cible, de sorte que l'équipement source envoie ses trames vers le chemin d'Access Gate plutôt que vers son pair, en croyant que rien n'a changé. Access Gate traduit alors le flux vers l'overlay, applique la politique de l'enclave, puis le livre.
Le résultat reflète la philosophie du port de supervision : les actifs sensibles restent intacts, la production reste en ligne, et aucun recâblage ni changement d'équipement n'est requis. Là où la supervision offre une visibilité passive, la redirection ajoute un contrôle actif, en s'appuyant sur le même principe non intrusif.
Comment ça fonctionne
La redirection repose sur trois mécanismes qui agissent de concert, tous appliqués au niveau du bridge ou en dessous, jamais sur les équipements finaux :
- L'isolation de port supprime le chemin direct de niveau 2 entre les deux équipements, de sorte que leurs trames ne peuvent plus être commutées l'une vers l'autre.
- Le proxy ARP (mode VLAN privé) permet à l'élément de redirection de répondre aux requêtes ARP destinées au pair isolé avec sa propre adresse MAC, capturant la trame que l'équipement croit envoyer à son voisin.
- La traduction de destination réécrit le trafic capturé de l'adresse locale vers son identité overlay et le route vers Access Gate, qui le remappe vers l'équipement réel et renvoie la réponse.
Comme l'interception a lieu au niveau 2, les équipements finaux n'apprennent jamais que quoi que ce soit a changé. Leur configuration IP, leur passerelle et leur logique de voisinage restent exactement telles quelles. Seule leur table ARP se met discrètement à jour pour faire pointer l'IP du pair vers la MAC de l'élément de redirection.
Labo de référence
L'exemple ci-dessous utilise un hôte placé derrière un routeur. Il est représentatif d'un déploiement réel : un sous-réseau d'équipements à plat servi par le pare-feu, avec Access Gate joignable via l'overlay dans une architecture en lollipop.
| Élément | Adresse | Rôle |
|---|---|---|
| zt-a | 10.0.0.4 | Équipement ancien A (source) |
| zt-b | 10.0.0.3 | Équipement ancien B (cible) |
| Élément de redirection | 10.0.0.2 sur le bridge | Intercepte et traduit |
| Routeur | 10.0.0.1 | Passerelle de bordure et route vers Access Gate |
| Access Gate | 100.65.0.4/29, Secure Twin 100.64.100.4/24 | Identités overlay, application des politiques |
Le mappage préserve le dernier octet : 10.0.0.X sur le sous-réseau local correspond à 100.64.100.X sur l'overlay.
Étape par étape
1. Confirmer l'état de départ
Les deux équipements sont sur le même bridge et peuvent se joindre directement. C'est la situation de référence, à plat et non protégée.
ping -c2 10.0.0.3 # réussit : commutation L2 directe
2. Supprimer le chemin direct de niveau 2
Isolez les deux ports d'équipement sur le bridge afin que leurs trames ne puissent plus être commutées l'une vers l'autre. Le port de l'élément de redirection et le lien montant restent non isolés, de sorte que les deux équipements peuvent toujours les joindre.
# veth côté hôte pour chaque conteneur, défini sur le bridge
sudo ip link set {} type bridge_slave isolated on # zt-a
sudo ip link set veth6680885b type bridge_slave isolated on # zt-b
# vérifier
bridge -d link show | grep -B1 isolated
Confirmez que le raccourci est coupé. Le pair ne répond plus à l'ARP, si bien que l'entrée de voisinage reste incomplète :
ping -c2 10.0.0.3 # échoue : ARP INCOMPLETE
ip neigh show # 10.0.0.3 ... INCOMPLETE
3. Répondre à l'ARP à la place du pair
Attribuez une adresse sur le bridge à l'élément de redirection, puis activez le proxy ARP en mode VLAN privé afin qu'il puisse répondre aux requêtes ARP destinées aux pairs isolés. Le proxy ARP standard refuse de répondre pour une adresse située sur la même interface que le demandeur ; proxy_arp_pvlan est le paramètre conçu pour les segments isolés (VLAN privé) et autorise précisément cette réponse.
sudo ip addr add 10.0.0.2/24 dev zt-lab
sudo ip link set zt-lab up
sudo sysctl -w net.ipv4.ip_forward=1
sudo sysctl -w net.ipv4.conf.zt-lab.proxy_arp=1
sudo sysctl -w net.ipv4.conf.zt-lab.proxy_arp_pvlan=1
sudo ip neigh add proxy 10.0.0.3 dev zt-lab
sudo ip neigh add proxy 10.0.0.4 dev zt-lab
L'équipement source résout désormais son pair vers la MAC de l'élément de redirection :
ip neigh show
# 10.0.0.3 dev eth0 lladdr 00:16:3e:84:aa:ba REACHABLE
L'équipement croit avoir trouvé son voisin. En réalité, il a trouvé Trout.
4. Traduire vers l'overlay
Réécrivez le trafic destiné à l'adresse du pair local vers son identité overlay, et faites du masquerade pour que la réponse revienne à l'élément de redirection afin d'y être dé-traduite. Les équipements finaux restent entièrement en termes de sous-réseau local.
sudo nft add table ip zt_gate
sudo nft add chain ip zt_gate prerouting '{ type nat hook prerouting priority dstnat; }'
sudo nft add rule ip zt_gate prerouting iif zt-lab ip daddr 10.0.0.3 dnat to 100.64.100.3
sudo nft add rule ip zt_gate prerouting iif zt-lab ip daddr 10.0.0.4 dnat to 100.64.100.4
sudo nft add chain ip zt_gate postrouting '{ type nat hook postrouting priority srcnat; }'
sudo nft add rule ip zt_gate postrouting ip daddr 100.64.100.0/24 masquerade
Exemple de configuration
5. Router vers Access Gate à travers le pare-feu
Envoyez la plage overlay vers Access Gate via la passerelle propre au sous-réseau, afin que le trafic sorte par l'interface conçue pour ce segment plutôt que d'emprunter un autre chemin.
sudo ip route add 100.64.100.0/24 via 10.0.0.1 dev zt-lab metric 50
# confirmer le chemin
ip route get 100.64.100.3
# 100.64.100.3 via 10.0.0.1 dev zt-lab src 10.0.0.2
6. Configurer l'overlay Access Gate
Côté Access Gate, créez un réseau correspondant à ce sous-réseau, avec un overlay associé.
Ainsi que les actifs que vous souhaitez protéger.
7. Vérifier le chemin complet
L'équipement fait un ping vers son « voisin » et cela fonctionne, mais le trafic transite désormais par Access Gate.
sudo tcpdump -ni enp6s0 host 100.64.100.3 &
ping -c3 10.0.0.3
sudo pkill tcpdump
Capture attendue :
Le trafic quitte l'élément de redirection sous la forme 10.0.0.2 -> 100.64.100.3, atteint Access Gate à travers le pare-feu, puis revient. Le TTL réduit confirme qu'il a traversé le gate plutôt que d'être commuté directement.
Le chemin complet
zt-a (10.0.0.4)
-> bridge [ARP answered by Trout, not the peer]
-> redirection element (10.0.0.2) [DNAT 10.0.0.3 -> 100.64.100.3, masquerade]
-> Router (10.0.0.1)
-> Access Gate (100.64.100.3, policy enforcement)
-> and back, un-translated to zt-a
Du point de vue de l'équipement, il a fait un ping vers un voisin de son propre sous-réseau. En réalité, chaque trame est passée par Access Gate pour inspection et application des politiques, sans aucun changement d'adresse, de passerelle ou de routage sur l'équipement.
Une façon non intrusive d'appliquer le Zero Trust
Comme la redirection repose entièrement sur l'ARP et l'isolation de niveau 2, les équipements protégés ne sont jamais reconfigurés. Il n'y a ni agent, ni nouvelle passerelle, ni route statique, ni interruption de service. Des actifs anciens auxquels on ne peut jamais toucher sont placés sous application Zero-Trust en n'utilisant que les primitives réseau déjà présentes autour d'eux.
Cela permet de protéger le trafic Est-Ouest d'environnements où le recâblage et les changements d'équipement ne sont tout simplement pas envisageables, selon le même principe de fonctionnement que la supervision de Trout : obtenir le contrôle dont vous avez besoin pendant que la production reste en ligne et que les actifs sensibles restent intacts.