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 hasta él. Nada cambia en los dispositivos OT. Los comandos son de RouterOS 7.
Qué se construye
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 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, router 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 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) de 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 disponible; 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 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 de 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 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 a través del gate.
3. Apuntar el DNS a Access Gate
El gate aloja un resolver 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: 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 mediante una entrada estática de tipo
FWD, de modo que solosecure.acme.corpva al gate y el resto del tráfico conserva 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.
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: se filtra por dónde empezó el paquete. El enrutamiento basado en destino protege lo que va hacia un activo: se filtra por su destino. Use uno, otro, o ambos, según lo que quiera proteger. En ambos casos el Access Gate traduce entre la dirección real del activo y su gemelo.
Basado en origen: proteger lo que viene de la subred OT
/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-ag
Cada paquete que sale de la subred OT se marca y se enruta al gate, sea cual sea su destino. Una sola regla pone toda la subred bajo el Secure Twin sin tocar ningún dispositivo. Es la forma RouterOS del enrutamiento basado en origen.
Basado en destino: proteger lo que va hacia un activo
# La ruta overlay del paso 2 ya cubre todos los gemelos; esta la limita a un solo activo
/ip route add dst-address=100.64.1.10/32 gateway=100.65.0.6 comment="solo el gemelo del PLC"
Todo lo dirigido a un gemelo va al gate, sea quien sea el remitente. No hace falta ninguna regla mangle, es enrutamiento por destino corriente. Consulte NAT de gateway (L3).
5. Verificar el camino completo
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 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 mediante proxy al dispositivo real.
Qué reside en cada lugar
El router aloja una sola cosa: una regla que dice, en esencia, "estos paquetes, entrégalos a este siguiente salto." Ya se base en el origen o en el destino, es estática.
Todo lo demás reside en Access Gate: autenticación, las ACL del enclave, el proxy, la inyección de credenciales, la grabación de sesiones, la terminación TLS y el registro. Nada de eso es expresable en RouterOS, y nada de eso va allí.
Vale la pena decirle esto explícitamente al equipo de red, porque "necesitamos configurar su router" suena alarmante hasta que ven que es una regla de transferencia, no un motor de políticas. Su control de cambios verá una o dos reglas, una sola vez.
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 por origen, por destino, o ambos. El tráfico OT ahora fluye a través de Access Gate sin ningún cambio en los activos.