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 es un dispositivo físico que se cablea a dos puertos en dos subredes distintas: 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
| Elemento | Dirección | Función |
|---|---|---|
| VLAN de administración | 192.168.254.0/24 (VLAN 254) | Donde se accede a la consola web de Access Gate |
| Puerto de administración de Access Gate (5) | DHCP, o 192.168.254.50 | Interfaz de gestión |
| Subred de protección | 100.65.0.0/29 (VLAN 65), MX 100.65.0.1 | Enlace punto a punto con el gate |
| Puerto de protección de Access Gate (1) | 100.65.0.6 | Tráfico de entrada/salida, overlay y resolvedor DNS |
| Overlay de Secure Twin | 100.64.0.0/16 | Espacio paralelo; cada activo obtiene un twin 1:1 |
| Subred OT | 192.168.1.0/24, PLC 192.168.1.10 (twin 100.64.1.10) | Activos, sin cambios |
| Zona DNS | secure.acme.corp, resolvedor 100.65.0.6 | Nombres 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 difusión.
- Cree las VLANs en Security & SD-WAN → Configure → Addressing & VLANs:
- VLAN 254:
192.168.254.0/24, IP del MX192.168.254.1(administración). - VLAN 65:
100.65.0.0/29, IP del MX100.65.0.1(protección).
- VLAN 254:
- Asigne los puertos del switch en Switch → Ports del MS:
- Puerto de acceso en VLAN 254 → cablee al puerto de administración (5) de Access Gate.
- Puerto de acceso en VLAN 65 → cablee al puerto de protección (1) de Access Gate.
La interfaz de administración obtiene una concesión DHCP de la VLAN de administración, o toma por defecto 10.0.0.1 tras aproximadamente un minuto si no hay ninguna; configúrela como estática en 192.168.254.50 desde la consola si prefiere una dirección fija.
2. Agregar una ruta para el overlay
Secure Twin reside en el overlay 100.64.0.0/16, el espacio de direcciones paralelo donde cada activo obtiene un twin. Agregue una ruta estática en Security & SD-WAN → Configure → Routing (Static routes) para que todo el tráfico destinado a ese rango se reenvíe a 100.65.0.6, el puerto de protección de Access Gate:
- Subred:
100.64.0.0/16 - IP del siguiente salto:
100.65.0.6
A partir de aquí, cualquier tráfico dirigido a una dirección twin (overlay) se envía a Access Gate por su puerto de protección, y el gate lo redirige mediante proxy al dispositivo real; por tanto, alcanzar una dirección twin es lo que hace que el flujo pase por el gate.
3. Apuntar el DNS a Access Gate
El gate aloja un resolvedor en 100.65.0.6 que convierte los nombres de los 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 establezca 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 agregue un reenviador condicional para
secure.acme.corp → 100.65.0.6en el servidor DNS del sitio (Windows DNS, BIND o Infoblox). Consulte Configuring Access Gate DNS.
4. Dirigir el tráfico a través del gate
Dos formas de llevar el tráfico al gate. El enrutamiento basado en origen protege lo que viene de una red. El enrutamiento basado en destino protege lo que va hacia un activo. En ambos casos el Access Gate traduce entre la dirección real del activo y su gemelo.
En Meraki, use el basado en destino. Es una sola ruta estática, se comporta igual en MX y MS, y dirige a todos los clientes de todas las VLAN. El MX también tiene una opción basada en origen, pero solo captura el tráfico para el que el MX no tiene ruta, así que no llevará al gate el tráfico OT dirigido a sus otras VLAN locales.
Basado en destino: proteger lo que va hacia un activo (use este)
La ruta overlay del paso 2 ya cubre todos los gemelos. Para limitarlo a un activo, añada una Static Route en Security & SD-WAN → Configure → Routing:
- Subnet:
100.64.1.10/32 - Next hop IP:
100.65.0.6 - Active: Always active
Alcance un activo por su dirección gemela o su nombre DNS y el flujo pasa por el gate, sea quien sea el remitente. Es el patrón NAT de gateway (L3).
Dos cosas que conviene acertar. El rango de gemelos no debe solaparse con ninguna VLAN propia del MX ni con ninguna ruta estática existente, porque las rutas conectadas y las más específicas ganan y el tráfico se saltaría el gate en silencio. Y deje Active en Always active: con seguimiento por ping, un gate que deja de responder retira la ruta, el tráfico cae al camino por defecto y obtiene un bypass silencioso en lugar de una caída limpia.
Cuando pueda cambiar el direccionamiento de un activo, la modificación de IPs migra un dispositivo a la vez sin ningún cambio de enrutamiento.
Basado en origen: proteger lo que viene de la subred OT
El MX no hace policy-based routing en la LAN, pero sí tiene source-based default routing (MX 15.4+, con VLAN habilitadas). En Security & SD-WAN → Configure → Addressing & VLANs, elija Add source-based route, seleccione la VLAN OT, ponga el tipo de siguiente salto en LAN y la dirección en 100.65.0.6.
Lea el límite antes de confiar en ello: una ruta por defecto basada en origen solo se aplica a destinos para los que el MX no tiene ruta, y actúa sobre toda la VLAN, no por host. Cubre el tráfico que sale del sitio. No cubre OT hacia IT dentro de él, porque la VLAN IT ya está en la tabla de enrutamiento.
Para el tráfico este-oeste de OT a IT, alcance el servicio IT por su gemelo, o termine la subred OT en un equipo L3 superior, un switch Catalyst o un FortiGate, y aplique allí el enrutamiento basado en origen.
Reubicación de la puerta de enlace: el gate pasa a ser la gateway de la subred
La opción más contundente y también la más invasiva. Retire la VLAN OT de la tabla de direccionamiento del MX y termine esa subred en el Access Gate. El gate pasa a ser la gateway de los hosts del enclave y les sirve DHCP. En el MX, añada una ruta estática para la subred del enclave apuntando a la dirección de tránsito del gate. Si es su stack MS quien posee la interfaz VLAN, retírela allí y enrute la subred hacia el gate por una VLAN de tránsito.
Esto controla todo lo que sale del enclave, incluido el tráfico inter-VLAN, sin depender del direccionamiento por gemelos. Requiere una ventana de mantenimiento y convierte al Access Gate en una dependencia dura para esa subred, así que resérvelo para enclaves pequeños y bien delimitados.
5. Verificar la ruta completa
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 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.
Después ejecute traceroute a la dirección real del activo. No debería pasar por el gate. Eso es lo esperado, y le dice exactamente cuánto bypass le queda: todo lo que siga usando la dirección real queda sin control. Pruebe desde un cliente dentro de la VLAN, no desde el dashboard de Meraki.
Qué reside en cada lugar
El MX contiene una sola cosa: una ruta estática que dice, en esencia, "tráfico para el rango overlay, entrégalo a este siguiente salto." Es estática. Se escribe una vez y no se vuelve a tocar, aunque la política del enclave cambie semana a semana.
Todo lo demás reside en Access Gate: autenticación, las ACL del enclave, proxy, inyección de credenciales, grabación de sesiones, terminación TLS y registro. Nada de eso es expresable en el MX, y nada va allí.
Vale la pena decirlo abiertamente al equipo de red, porque "necesitamos modificar su dispositivo de seguridad" suena alarmante hasta que ven que se trata de una regla de transferencia, no de un motor de políticas. Su control de cambios ve una ruta, una vez.
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 direccionó el gate en 100.65.0.6, se enrutó el overlay hacia él, se apuntó el DNS a su resolvedor y se dirigió el tráfico por destino. El tráfico OT ahora fluye a través de Access Gate sin ningún cambio en los activos.