Cuando no puedes cambiar el activo y este se alcanza por IP en lugar de por nombre, la redirección puede vivir por completo en la red. El router o el gateway L3 por el que el tráfico ya pasa reescribe el destino de los flujos que elijas hacia el overlay Secure Twin, empujándolos a través de Access Gate. El activo sigue hablando con la dirección real de su par; el gateway hace el resto.
El objetivo
El activo (zt-a) apunta a la dirección real de su par (10.0.0.3), exactamente como siempre lo ha hecho. No puedes, o no quieres, reconfigurarlo, y se alcanza por IP, no por nombre. El único punto que sí controlas es el gateway L3 que su tráfico ya cruza.
Así que haces que el gateway se encargue del trabajo: hace NAT de destino de los flujos que elijas, reescribiendo 10.0.0.3 a su gemelo de overlay 100.64.100.3, y los reenvía a Access Gate. Nada cambia en el activo; la redirección es una única regla en el router.
Cómo funciona
Tres piezas trabajan en conjunto, todas en el gateway y en Access Gate, ninguna en el activo:
- El rango del overlay define un mapeo 1:1 (un "binat") entre cada dirección del underlay y su dirección de overlay Secure Twin. En este laboratorio conserva el último octeto:
10.0.0.Xen el underlay se corresponde con100.64.100.Xen el overlay. - Una regla de NAT de destino en el gateway L3 reescribe el destino de los flujos seleccionados desde la dirección del underlay hacia su gemelo de overlay, de modo que el paquete queda ahora dirigido al overlay.
- Una ruta hacia Access Gate lleva el rango del overlay hasta el gate, que hace binat de la dirección de overlay de vuelta al dispositivo real, aplica la política del enclave y devuelve la respuesta a través del gateway.
Como la reescritura ocurre en el gateway, la propia dirección del activo, su gateway y su enrutamiento quedan exactamente como estaban; nunca llega a saber que su tráfico fue redirigido.
Laboratorio de referencia
El ejemplo reutiliza la misma subred plana de dispositivos que las guías de modificar las IP y proxy ARP (L2): un host detrás de un router, 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), sin cambios |
| zt-b | 10.0.0.3 | Dispositivo heredado B (destino) |
| Router / gateway L3 | 10.0.0.1 | Hace NAT de destino de los flujos seleccionados hacia el overlay |
| 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, de modo que zt-b (10.0.0.3) tiene el gemelo de overlay 100.64.100.3.
Paso a paso
1. Definir el rango del overlay
El rango del overlay es un rango de direcciones reservado para los activos protegidos por Access Gate, donde cada dirección de overlay se mapea 1:1 con una dirección del underlay. El valor por defecto es 100.64.0.0/16, parte del rango reservado CGNAT. En este laboratorio el overlay 100.64.100.0/24 se mapea al underlay 10.0.0.0/24. Consulta Desplegar Secure Twin con Twin IPs para definir los rangos y el puerto Secure Twin en la interfaz de usuario.
2. Hacer NAT de destino del flujo en el gateway L3
En el router, añade una regla DNAT que reescriba el destino de los flujos que quieres controlar desde la dirección del underlay hacia su gemelo de overlay. Acótala al flujo específico para que el tráfico no relacionado quede intacto.
# En el gateway L3: hacer DNAT del tráfico de zt-a con destino a zt-b hacia su gemelo de overlay
iptables -t nat -A PREROUTING -s 10.0.0.4 -d 10.0.0.3 -j DNAT --to-destination 100.64.100.3
El DNAT ocurre antes de la decisión de enrutamiento, de modo que el paquete ya está dirigido a 100.64.100.3 cuando el gateway elige su siguiente salto.
3. Enrutar el rango del overlay hacia Access Gate
Envía el rango del overlay a Access Gate, de modo que el paquete recién NATeado se reenvíe al gate en lugar de volver a la subred local.
ip route add 100.64.100.0/24 via <access-gate-ip>
4. Verificar el camino completo
zt-a hace ping a su par en su dirección real, sin cambios, y el gateway redirige silenciosamente el flujo a través de Access Gate.
ping -c3 10.0.0.3
Access Gate hace binat de 100.64.100.3 de vuelta al zt-b real (10.0.0.3), aplica la política y devuelve la respuesta a través del gateway. Un TTL reducido en la respuesta confirma que el flujo atravesó el gate en lugar de quedarse local.
El camino completo
zt-a (10.0.0.4) [targets the REAL peer 10.0.0.3, unchanged]
-> Router / L3 gateway (10.0.0.1) [DNAT 10.0.0.3 -> 100.64.100.3, route to Access Gate]
-> Access Gate (Secure Twin 100.64.100.4/24, policy enforcement) [binat 100.64.100.3 -> 10.0.0.3]
-> zt-b (10.0.0.3)
-> and back, un-NATed to zt-a
Desde el punto de vista de zt-a, alcanzó a su vecino en la dirección de siempre. En realidad, el gateway L3 reescribió el destino hacia el overlay y la sesión pasó a través de Access Gate, sin ningún cambio en la dirección, el gateway o el enrutamiento de ninguno de los dos dispositivos.
Una redirección que vive en el gateway
El NAT de gateway mantiene la redirección totalmente fuera de los extremos: el activo nunca se reconfigura y no interviene ningún DNS; el router simplemente reescribe el destino de los flujos que elijas. Recurre a él cuando eres dueño del gateway L3 pero no de los activos, y el tráfico se alcanza por IP.
Si puedes cambiar el activo, modificar las IP es más simple; si el activo se alcanza por nombre, usa DNS; si no hay ningún salto L3 entre los dos dispositivos, el proxy ARP (L2) lo hace en el switch.