Usuario de MikroTik VPN que llega demasiado lejos: limítelo a un host y un puerto

El túnel se levanta, el inicio de sesión tiene éxito y todos los hosts de la red responden. Eso no es una VPN rota; es una VPN sin modelo de permisos. RouterOS autentica la cuenta y luego enruta sus paquetes como los de cualquier otro, así que el cortafuegos debe aportar el límite. Añadir ese límite sin romper el inicio de sesión es todo el trabajo.

La autenticación termina donde empieza el permiso

Una vez levantada la sesión PPP, los paquetes del cliente entran en la cadena forward como el tráfico de cualquier otra interfaz. Si la política forward del router es permisiva, el consultor hereda esa permisividad al iniciar sesión. La cuenta nunca llevó un alcance, así que no hay nada en la cuenta que cambiar. El conjunto de reglas se escribió para empleados y la nueva sesión simplemente se le unió.

Compruebe a qué ruta se refiere la solicitud antes de escribir nada. El tráfico a los hosts detrás del router cruza forward, mientras que el tráfico al propio router, incluidos winbox y SSH, cruza input. Un alcance que solo cubre forward deja el dispositivo abierto al mismo cliente.

Ambas cadenas necesitan una decisión, aunque la decisión sea dejar input cerrado. Esa elección pertenece a la solicitud de acceso, no a una idea posterior.

Vincule la sesión a una lista con nombre

Un perfil PPP puede colocar la dirección que entrega en una lista de direcciones con nombre al iniciar la sesión. Eso convierte una dirección de túnel transitoria en algo que el cortafuegos puede emparejar por nombre, y la entrada desaparece cuando termina la sesión. La cuenta entonces hereda el alcance de su perfil en lugar de una regla que fija una dirección de forma rígida.

Cree primero el perfil y luego vincule el secret a él de forma explícita. Un secret que sigue apuntando al perfil predeterminado reproduce el problema original.

Nombre el perfil y la lista de modo que sus tareas sean obvias, y comente ambos con la referencia de la solicitud. Un perfil puede servir a varias personas con el mismo alcance, mientras que la lista sigue identificando cada sesión viva. Es más barato de revisar que una regla por persona.

/ppp profile add name=scoped-consultant remote-address=consultant-pool address-list=vpn-scoped-clients
/ppp secret add name=consultant password=... service=ovpn profile=scoped-consultant

Registre el servicio permitido en una lista

Ponga el servidor permitido en su propia lista de direcciones en lugar de incrustar la dirección en una regla de filtro. La lista se puede auditar, ampliar y comentar, y la regla que la consume no cambia cuando el servidor se mueve. Una sola entrada parece excesiva hasta que llega el segundo host, cosa que suele ocurrir.

Empareje una lista cuando la dirección es dinámica o balanceada, y empareje la dirección directamente cuando está reservada y es estable. Cualquiera de las dos opciones se lee con claridad si el comentario nombra el servicio y el propietario.

Limite el protocolo y el puerto además del host. Una aceptación para un host sin restricción de puerto abre todos los servicios que ese host ejecuta, lo que es más amplio de lo que pretenden la mayoría de solicitudes de acceso. El puerto es parte del permiso, no un detalle que se añade después.

/ip firewall address-list add list=vpn-targets address=10.0.0.10 comment="consultant RDP target"

Ordene el salto antes de cualquier aceptación amplia

Una regla de salto envía el tráfico reenviado desde la lista acotada a una cadena privada donde toda la política cabe en tres líneas. La primera regla acepta el destino y el puerto permitidos, y la última descarta todo lo demás. El salto debe estar por encima de cualquier aceptación amplia en forward, porque una aceptación anterior hace que el salto nunca se ejecute. Mantenga la aceptación de established y related antes del salto para que el tráfico de retorno siga fluyendo.

Compruebe que ninguna regla fasttrack pueda llevar este tráfico más allá de la cadena acotada. Fasttrack evita el resto del recorrido del filtro, y una sesión acotada que pasa por fasttrack no está acotada en absoluto.

Repita la decisión para la cadena input si los servicios propios del router deben ser inalcanzables. Un alcance que bloquea el tráfico reenviado y deja winbox abierto solo está medio terminado.

/ip firewall filter
add chain=forward action=jump jump-target=scoped-vpn src-address-list=vpn-scoped-clients
add chain=scoped-vpn action=accept protocol=tcp dst-address-list=vpn-targets dst-port=3389
add chain=scoped-vpn action=drop

Verifique con contadores y pertenencia a la lista

Desde el cliente, pruebe el servicio permitido y uno que debe fallar, y luego lea las estadísticas de reglas en el router. Los contadores de aceptación y descarte muestran qué ruta tomó cada paquete, algo que el cliente no puede ver. Confirme también que la dirección de la sesión viva apareció en la lista acotada.

Una lista vacía significa que la cuenta está en otro perfil o que el perfil perdió su ajuste de lista de direcciones. Un contador de descarte que sube con un servicio permitido que falla significa que el destino o el puerto no coinciden con lo que envía el cliente.

Pruebe el mismo servicio por nombre y por dirección antes de concluir nada. Un fallo de resolución de nombres parece exactamente un puerto bloqueado desde el lado del cliente. Después registre el perfil, ambas listas y el único servicio permitido en la solicitud de acceso para que la siguiente revisión compare en lugar de reconstruir.

/ip firewall filter print stats where chain=scoped-vpn
/ip firewall address-list print where list=vpn-scoped-clients