Desplegar Secure Twin mediante ARP NAT (L2): proxy ARP en VLAN privada

Para desplegar un Secure Twin mediante ARP NAT, aísle los dos puertos de los equipos en el conmutador, deje que un elemento de redirección responda al ARP en nombre del par mediante proxy ARP en modo VLAN privada, y luego aplique destination-NAT al tráfico capturado hacia el overlay y enrútelo al Access Gate. Los equipos finales nunca se reconfiguran. Requiere conmutadores gestionados que usted administre: es un método best-effort.

A veces no puedes modificar una IP de destino ni hacer NAT a nivel de router, pero sí controlas la capa de conmutación. En ese caso, la VLAN privada y el proxy ARP permiten dirigir el tráfico Este-Oeste hacia 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 a través del overlay para aplicar las políticas.

¿Qué problema resuelve ARP NAT?

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.

Los dispositivos finales quedan intactos. Ese es el intercambio que hace este método: traslada el trabajo de configuración desde los activos hacia la capa de conmutación, donde el aislamiento de puertos y el proxy ARP hay que montarlos y mantenerlos. Nada se evita del todo, se traslada al lugar donde sí puedes intervenir. Donde el puerto de monitorización aporta visibilidad pasiva, la redirección añade control activo, y ambos dejan los activos protegidos tal como están.

¿Cómo funciona ARP NAT?

La redirección se apoya en tres mecanismos que actúan en conjunto. Todos se configuran en la capa de conmutación y en el elemento de redirección, ninguno 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.

El mapeo conserva el último octeto: 10.0.0.X en la subred local se corresponde con 100.64.100.X en el overlay.

Cómo desplegar un Secure Twin mediante ARP NAT (L2), 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.

Cómo es la ruta completa del tráfico

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.

Cuándo usarlo y cuándo no

Como la redirección se construye sobre ARP y el aislamiento de capa 2, los dispositivos protegidos nunca se reconfiguran. No hay agente en el activo, ni nuevo gateway, ni ruta estática, ni tiempo de inactividad para los propios dispositivos. Los equipos heredados que no pueden tocarse quedan bajo protección Zero Trust usando funciones de switch que normalmente ya están ahí.

Esto encaja cuando administras los switches, admiten aislamiento de puertos o VLAN privada, puedes conseguir una ventana de mantenimiento en ellos, y el router y el direccionamiento de los dispositivos están realmente fuera de alcance.

Use otra forma cuando los switches no son gestionados o pertenecen a otro equipo, la plataforma no admite VLAN privada, el segmento abarca switches de varios fabricantes con comportamientos de aislamiento distintos, o no quieres asumir un cambio de capa 2 que habrá que documentar y mantener. En esos casos, empiece por las formas recomendadas: Twin DNS o Twin IPs para migrar un activo cada vez, Source-Based Routing para mover una subred completa en un solo cambio. IP NAT (L3) es el otro método best-effort, y se aplica cuando hay un salto enrutado en la ruta. Vea Elegir su despliegue de Secure Twin.

Trátalo como una técnica a la que recurrir cuando se dan esas condiciones, no como opción por defecto para todos los despliegues. Conviene además documentarlo en el runbook de la red: un operador que depure tablas ARP meses después necesita saber por qué un vecino resuelve a la MAC del elemento de redirección.