TroutTrout

Implementar Access Gate con Cisco Meraki

Conecta un Access Gate a un Meraki MX/MS desde el Dashboard de extremo a extremo: dos puertos en dos VLANs, la ruta estática de superposición, DNS por VLAN y enrutamiento basado en destino, para que el tráfico OT fluya a través del gate.

7 min read · Last updated 2026-08-12

Esta guía lleva un dispositivo de seguridad Meraki MX (con un switch MS) desde "Access Gate en el rack" hasta "tráfico OT fluyendo a través del gate", de principio a fin, todo desde el Dashboard. Se conectan dos puertos, se asigna al gate un lugar en la red y se elige cómo llega el tráfico. Nada cambia en los dispositivos OT.

Qué se construirá

Access Gate cableado a un router existente por dos puertos: un puerto de administración en la VLAN de administración y un puerto de protección en una subred /29 dedicada
Access Gate cableado a un router existente por dos puertos: un puerto de administración en la VLAN de administración y un puerto de protección en una subred /29 dedicada

El Access Gate es un dispositivo físico que se cablea a dos puertos en dos subredes diferentes: un puerto de administración en la VLAN de administración y un puerto de protección en una pequeña subred dedicada que transporta el tráfico que se dirige a través del gate.

Laboratorio de referencia

ElementoDirecciónFunción
VLAN de administración192.168.254.0/24 (VLAN 254)Desde donde se accede a la consola web del Access Gate
Puerto de administración del Access Gate (5)DHCP, o 192.168.254.50Interfaz de gestión
Subred de protección100.65.0.0/29 (VLAN 65), MX 100.65.0.1Enlace punto a punto con el gate
Puerto de protección del Access Gate (1)100.65.0.6Tráfico de entrada/salida, overlay y resolver DNS
Overlay de Secure Twin100.64.0.0/16Espacio paralelo; cada activo obtiene un twin 1:1
Subred OT192.168.1.0/24, PLC 192.168.1.10 (twin 100.64.1.10)Activos, sin cambios
Zona DNSsecure.acme.corp, resolver 100.65.0.6Nombres para los activos

1. Conectividad física: dos puertos, dos VLANs

Coloque el puerto de administración y el puerto de protección en VLANs diferentes para que el tráfico de gestión y el tráfico dirigido nunca compartan un dominio de broadcast.

  1. Cree las VLANs en Security & SD-WAN → Configure → Addressing & VLANs:
    • VLAN 254: 192.168.254.0/24, IP del MX 192.168.254.1 (administración).
    • VLAN 65: 100.65.0.0/29, IP del MX 100.65.0.1 (protección).
  2. Asigne los puertos del switch en Switch → Ports en el MS:
    • Puerto de acceso en VLAN 254 → cablee al puerto de administración (5) del Access Gate.
    • Puerto de acceso en VLAN 65 → cablee al puerto de protección (1) del Access Gate.

La interfaz de administración obtiene un arrendamiento DHCP de la VLAN de administración, o toma por defecto 10.0.0.1 tras aproximadamente un minuto si no hay ninguno; configúrela como estática en 192.168.254.50 desde la consola si prefiere una dirección fija.

2. Añadir una ruta para el overlay

El Secure Twin reside en el overlay 100.64.0.0/16, el espacio de direcciones paralelo donde cada activo obtiene un twin. Añada una ruta estática en Security & SD-WAN → Configure → Routing (Static routes) para que cualquier tráfico destinado a ese rango se reenvíe a 100.65.0.6, el puerto de protección del Access Gate:

  • Subred: 100.64.0.0/16
  • IP del siguiente salto: 100.65.0.6

A partir de aquí, cualquier paquete dirigido a una dirección twin (overlay) se envía al Access Gate por su puerto de protección, y el gate lo redirige mediante proxy al dispositivo real; alcanzar una dirección twin es lo que hace que el flujo pase por el gate.

3. Apuntar el DNS al Access Gate

El gate aloja un resolver en 100.65.0.6 que convierte nombres de activos en direcciones overlay. Puede usarlo para todo o solo para un subdominio.

  • Todo: en Addressing & VLANs, edite el DHCP de la VLAN OT y configure Custom nameservers en 100.65.0.6. Todos los dispositivos de esa VLAN resolverán a través del gate.
  • Solo subdominio: el MX no admite reenvío condicional por zona, así que mantenga su DNS existente y añada un reenviador condicional para secure.acme.corp → 100.65.0.6 en el servidor DNS del sitio (Windows DNS, BIND o Infoblox). Consulte Configuración del DNS del Access Gate.

4. Dirigir el tráfico a través del gate

El MX no ofrece enrutamiento de políticas basado en origen de forma general, por lo que en Meraki el tráfico se dirige por destino, que es exactamente para lo que está diseñado el Secure Twin.

  • Basado en destino (recomendado en Meraki): la ruta estática del overlay del paso 2 hace pasar todo el tráfico 100.64.0.0/16 por el gate. Acceda a cada activo por su dirección twin o su nombre DNS, y el flujo pasará por el Access Gate. Este es el patrón de NAT de gateway (L3).
  • Por activo mediante Twin IPs: cuando sea posible cambiar cómo se direcciona un activo, modificar IPs migra un dispositivo a la vez sin ningún cambio de enrutamiento.

5. Verificar el camino completo

Desde un dispositivo OT, acceda a un activo por su nombre DNS o dirección twin:

ping plc-line-1.secure.acme.corp   # from a client that resolves via 100.65.0.6

En el Access Gate, el flujo aparece bajo su enclave con la identidad overlay del dispositivo (100.64.1.10); la identidad, la política y el cifrado se aplican antes de reenviar el paquete, y la respuesta se traduce mediante NAT de vuelta al dispositivo real.

Resumen

Se crearon dos VLANs en el MX, se cableó el gate a dos puertos del MS en dos subredes (VLAN de administración + /29 de protección), se asignó al gate la dirección 100.65.0.6, se enrutó el overlay hacia él, se apuntó el DNS a su resolver y se dirigió el tráfico por destino. El tráfico OT ahora fluye a través del Access Gate sin ningún cambio en los activos.

Relacionados