Esta guía lleva un router MikroTik RouterOS desde "Access Gate en el rack" hasta "tráfico OT fluyendo a través del gate", de principio a fin. 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. Los comandos son para RouterOS 7.
Qué se construirá
El Access Gate es un appliance 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 | Desde donde se accede a la consola web del Access Gate |
| Puerto de administración del Access Gate (5) | DHCP, o 192.168.254.50 | Interfaz de gestión |
| Subred de protección | 100.65.0.0/29, router 100.65.0.1 | Enlace punto a punto con el gate |
| Puerto de protección del Access Gate (1) | 100.65.0.6 | Tráfico de entrada/salida, overlay y resolver 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, resolver 100.65.0.6 | Nombres para los activos |
1. Conectividad física: dos puertos, dos subredes
Coloque el puerto de administración y el puerto de protección en subredes distintas para que el tráfico de gestión y el tráfico dirigido nunca compartan un dominio de difusión. Asigne una dirección a cada interfaz: una para administración y otra para protección.
# ether5 -> Access Gate admin port (5) | ether2 -> Access Gate protection port (1)
/ip address add address=192.168.254.1/24 interface=ether5 comment="AG admin"
/ip address add address=100.65.0.1/29 interface=ether2 comment="AG protection"
Cablee ether5 al puerto de administración (5) del Access Gate y ether2 al puerto de protección (1). La interfaz de administración obtiene un lease 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. Agregar 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. Agregue una ruta para que cualquier tráfico destinado a ese rango se reenvíe a través de 100.65.0.6, el puerto de protección del Access Gate:
/ip route add dst-address=100.64.0.0/16 gateway=100.65.0.6 comment="Secure Twin overlay"
Léase así: para la red de destino 100.64.0.0/16, el gateway (siguiente salto) es 100.65.0.6. A partir de aquí, cualquier paquete dirigido a una dirección twin (overlay) sale del router, llega al Access Gate por su puerto de protección y el gate lo redirige 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 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: entregue el resolver a los clientes mediante DHCP:
/ip dhcp-server network set [find where address=192.168.1.0/24] dns-server=100.65.0.6 -
Solo el subdominio: RouterOS reenvía una zona concreta con una entrada estática de tipo
FWD, de modo que solosecure.acme.corpva al gate y el resto sigue usando el resolver existente:/ip dns static add type=FWD name=secure.acme.corp match-subdomain=yes forward-to=100.65.0.6Consulte Configuring Access Gate DNS para el patrón de DNS dividido (split-DNS).
4. Dirigir el tráfico a través del gate
Elija según si desea capturar toda una subred o llegar a activos específicos.
-
Basado en origen (toda la subred OT): marque todo el tráfico originado en la subred OT y enrute el tráfico marcado hacia el gate. Una sola regla pone la subred bajo el Secure Twin sin tocar ningún dispositivo:
/ip firewall mangle add chain=prerouting src-address=192.168.1.0/24 \ action=mark-routing new-routing-mark=via-ag passthrough=yes comment="steer OT to AG" /ip route add dst-address=0.0.0.0/0 gateway=100.65.0.6 routing-table=via-agQué hace esto: la regla de mangle etiqueta cada paquete de la subred OT con la marca de enrutamiento
via-ag, y la ruta en esa tabla de enrutamiento envía todo el tráfico marcado a100.65.0.6, de modo que una sola regla hace pasar toda la subred por el gate. Esta es la forma RouterOS del enrutamiento basado en origen. -
Basado en destino (activos específicos): acceda a los activos por sus direcciones twin a través de la ruta overlay del paso 2, o agregue una ruta para un destino específico vía
100.65.0.6. Use esto para control por flujo; consulte gateway NAT (L3).
5. Verificar la ruta completa
Desde un dispositivo OT, acceda a un destino exactamente como antes. El router ahora dirige el flujo a través del gate en el camino de salida.
# from the OT device (192.168.1.10)
ping 192.168.2.20
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.
También puede probar la dirección IT a OT: desde un cliente IT, acceda a un activo OT por su dirección twin o nombre DNS (ping 100.64.1.10). La ruta overlay lleva ese paquete al gate, que lo redirige al dispositivo real.
Resumen
Se asignaron direcciones a dos interfaces de RouterOS en dos subredes (VLAN de administración + protección /29), se colocó el gate en 100.65.0.6, se enrutó el overlay hacia él, se apuntó el DNS a su resolver y se dirigió el tráfico con una tabla de enrutamiento marcada mediante mangle o con una ruta de destino. El tráfico OT ahora fluye a través del Access Gate sin ningún cambio en los activos.