Este documento ofrece un ejemplo de cómo puedes configurar sistemas de red existentes para resolver este caso de uso concreto. No constituye un estándar ni una integración oficialmente soportada de Access Gate.
En algunos casos, modificar una IP de destino o hacer NAT a nivel de router no es una opción. Cuando esto ocurre, es posible aprovechar la VLAN privada y el proxy ARP para desplegar el overlay seguro de Access Gate sin cambiar los dispositivos finales, su gateway ni su enrutamiento.
Los dispositivos siguen comportándose como si hablaran con un vecino de la misma subred, mientras cada paquete se desvía discretamente a través del overlay para aplicar las políticas.
El objetivo
Los equipos OT e IT heredados no se pueden reconfigurar a la ligera. A menudo no puedes cambiar la IP de un PLC, instalar un agente, añadir una ruta estática ni apuntarlo a un nuevo gateway, ya sea porque el fabricante lo prohíbe, porque no existe la ventana de mantenimiento o simplemente porque el dispositivo es anterior a la idea. Y precisamente son esos los activos que necesitan protección, y el tráfico Este-Oeste entre ellos es justo lo que una red plana deja totalmente expuesto.
La redirección de tráfico resuelve esto en la capa 2. Dos dispositivos de la misma subred normalmente hacen ARP entre sí y conmutan las tramas directamente, de forma invisible para cualquier control de seguridad. Trout se introduce en ese intercambio respondiendo al ARP en nombre del destino, de modo que el dispositivo de origen envía sus tramas al camino de Access Gate en lugar de al par, creyendo que nada ha cambiado. Access Gate traduce entonces el flujo hacia el overlay, aplica la política del enclave y lo entrega.
El resultado refleja la filosofía del puerto de monitorización: los activos sensibles quedan intactos, la producción sigue en línea y no se requiere ningún recableado ni cambio en los dispositivos. Donde la monitorización aporta visibilidad pasiva, la redirección añade control activo, usando el mismo principio no intrusivo.
Cómo funciona
La redirección se apoya en tres mecanismos que actúan en conjunto, todos aplicados en el bridge o por debajo de él, nunca en los dispositivos finales:
- El aislamiento de puertos elimina el camino directo de capa 2 entre ambos dispositivos, de modo que sus tramas ya no pueden conmutarse entre sí.
- El proxy ARP (modo VLAN privada) permite que el elemento de redirección responda a las solicitudes ARP dirigidas al par aislado con su propia dirección MAC, capturando la trama que el dispositivo cree estar enviando a su vecino.
- La traducción de destino reescribe el tráfico capturado desde la dirección local hacia su identidad en el overlay y lo enruta hasta Access Gate, que la vuelve a mapear al dispositivo real y devuelve la respuesta.
Como la interceptación ocurre en la capa 2, los dispositivos finales nunca se enteran de que algo cambió. Su configuración IP, su gateway y su lógica de vecindad quedan exactamente como estaban. Solo su tabla ARP se actualiza discretamente para apuntar la IP del par a la MAC del elemento de redirección.
Laboratorio de referencia
El ejemplo siguiente usa un host situado detrás de un router. Es representativo de un despliegue real: una subred plana de dispositivos servida por el firewall, con Access Gate accesible a través del overlay en una arquitectura lollipop.
| Elemento | Dirección | Rol |
|---|---|---|
| zt-a | 10.0.0.4 | Dispositivo heredado A (origen) |
| zt-b | 10.0.0.3 | Dispositivo heredado B (destino) |
| Elemento de redirección | 10.0.0.2 en el bridge | Intercepta y traduce |
| Router | 10.0.0.1 | Gateway de borde y ruta hacia Access Gate |
| Access Gate | 100.65.0.4/29, Secure Twin 100.64.100.4/24 | Identidades del overlay, aplicación de políticas |
El mapeo conserva el último octeto: 10.0.0.X en la subred local se corresponde con 100.64.100.X en el overlay.
Paso a paso
1. Confirmar el estado inicial
Ambos dispositivos están en el mismo bridge y pueden alcanzarse directamente. Esta es la línea base plana y sin protección.
ping -c2 10.0.0.3 # funciona: conmutación L2 directa
2. Eliminar el camino directo de capa 2
Aísla los puertos de ambos dispositivos en el bridge para que sus tramas ya no puedan conmutarse entre sí. El puerto del elemento de redirección y el uplink permanecen sin aislar, de modo que ambos dispositivos siguen pudiendo alcanzarlos.
# veth del lado del host para cada contenedor, configurado en el bridge
sudo ip link set {} type bridge_slave isolated on # zt-a
sudo ip link set veth6680885b type bridge_slave isolated on # zt-b
# verificar
bridge -d link show | grep -B1 isolated
Confirma que el atajo está roto. El par ya no responde al ARP, por lo que la entrada de vecindad queda incompleta:
ping -c2 10.0.0.3 # falla: ARP INCOMPLETE
ip neigh show # 10.0.0.3 ... INCOMPLETE
3. Responder al ARP en nombre del par
Asigna al elemento de redirección una dirección en el bridge y habilita el proxy ARP en modo VLAN privada para que pueda responder a las solicitudes ARP de los pares aislados. El proxy ARP estándar se niega a responder por una dirección situada en la misma interfaz que el solicitante; proxy_arp_pvlan es el ajuste diseñado para segmentos aislados (VLAN privada) y permite exactamente esa respuesta.
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
Ahora el dispositivo de origen resuelve a su par con la MAC del elemento de redirección:
ip neigh show
# 10.0.0.3 dev eth0 lladdr 00:16:3e:84:aa:ba REACHABLE
El dispositivo cree haber encontrado a su vecino. En realidad ha encontrado a Trout.
4. Traducir hacia el overlay
Reescribe el tráfico destinado a la dirección local del par hacia su identidad en el overlay, y aplica masquerade para que la respuesta regrese al elemento de redirección y sea des-traducida. Los dispositivos finales permanecen por completo en términos de la subred 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
Ejemplo de configuración
5. Enrutar hacia Access Gate a través del firewall
Envía el rango del overlay a Access Gate a través del propio gateway de la subred, de modo que el tráfico salga por la interfaz creada para este segmento en lugar de tomar prestado otro camino.
sudo ip route add 100.64.100.0/24 via 10.0.0.1 dev zt-lab metric 50
# confirmar el camino
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. Configurar el overlay en Access Gate
En el lado de Access Gate, crea una red que coincida con esta subred, con su overlay asociado.
Así como los activos que quieres proteger.
7. Verificar el camino completo
El dispositivo hace ping a su "vecino" y funciona, pero ahora el tráfico viaja a través de Access Gate.
sudo tcpdump -ni enp6s0 host 100.64.100.3 &
ping -c3 10.0.0.3
sudo pkill tcpdump
Captura esperada:
El tráfico sale del elemento de redirección como 10.0.0.2 -> 100.64.100.3, alcanza Access Gate a través del firewall y regresa. El TTL reducido confirma que atravesó el gate en lugar de conmutarse directamente.
El camino completo
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
Desde el punto de vista del dispositivo, hizo ping a un vecino de su propia subred. En realidad, cada trama pasó por Access Gate para su inspección y la aplicación de políticas, sin ningún cambio en la dirección, el gateway ni el enrutamiento del dispositivo.
Una forma no intrusiva de aplicar Zero Trust
Como la redirección se construye por completo sobre ARP y el aislamiento de capa 2, los dispositivos protegidos nunca se reconfiguran. No hay agente, ni nuevo gateway, ni ruta estática, ni tiempo de inactividad. Los activos heredados que nunca pueden tocarse quedan bajo la protección de Zero Trust usando únicamente las primitivas de red ya presentes a su alrededor.
Esto hace posible proteger el tráfico Este-Oeste de entornos donde recablear y cambiar los dispositivos finales simplemente no son opciones, el mismo principio de funcionamiento que hay detrás de la monitorización de Trout: obtener el control que necesitas mientras la producción sigue en línea y los activos sensibles permanecen intactos.