Usuario de MikroTik VPN que chega demasiado lonxe: límiteo a un só host e un só porto

O túnel lévantase, o inicio de sesión ten éxito e todos os hosts da rede responden. Iso non é unha VPN avariada; é unha VPN sen modelo de permisos. RouterOS autentica a conta e despois encamiña os seus paquetes coma os de calquera outro, así que a devasa debe achegar o límite. Engadir ese límite sen romper o inicio de sesión é todo o traballo.

A autenticación remata onde comeza o permiso

Unha vez erguida a sesión PPP, os paquetes do cliente entran na cadea forward coma o tráfico de calquera outra interface. Se a política forward do router é permisiva, o consultor herda esa permisividade ao iniciar sesión. A conta nunca levou un alcance, así que non hai nada na conta que cambiar. O conxunto de regras escribiuse para empregados e a nova sesión simplemente se lle uniu.

Comprobe a que ruta se refire a solicitude antes de escribir nada. O tráfico aos hosts detrás do router cruza forward, mentres que o tráfico ao propio router, incluídos winbox e SSH, cruza input. Un alcance que só cobre forward deixa o dispositivo aberto ao mesmo cliente.

As dúas cadeas precisan unha decisión, aínda que a decisión sexa deixar input pechado. Esa escolla pertence á solicitude de acceso, non a unha idea posterior.

Vincule a sesión a unha lista con nome

Un perfil PPP pode pór o enderezo que entrega nunha lista de enderezos con nome ao comezar a sesión. Iso converte un enderezo de túnel transitorio en algo que a devasa pode emparellar por nome, e a entrada desaparece cando remata a sesión. A conta entón herda o alcance do seu perfil en lugar dunha regra que fixa un enderezo de forma ríxida.

Cree primeiro o perfil e logo vincule o secret a el de xeito explícito. Un secret que aínda apunta ao perfil predeterminado reproduce o problema orixinal.

Nomee o perfil e a lista de modo que as súas tarefas sexan evidentes, e comente ambos coa referencia da solicitude. Un perfil pode servir varias persoas co mesmo alcance, mentres que a lista segue identificando cada sesión viva. É máis barato de revisar ca unha regra por persoa.

/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

Rexiste o servizo permitido nunha lista

Pon o servidor permitido na súa propia lista de enderezos en lugar de incrustar o enderezo nunha regra de filtro. A lista pódese auditar, ampliar e comentar, e a regra que a consome non cambia cando o servidor se move. Unha soa entrada parece excesiva ata que chega o segundo host, cousa que adoita ocorrer.

Emparelle unha lista cando o enderezo é dinámico ou balanceado, e emparelle o enderezo directamente cando está reservado e é estable. Calquera das dúas opcións lese con claridade se o comentario nomea o servizo e o propietario.

Limite o protocolo e o porto ademais do host. Unha aceptación para un host sen restrición de porto abre todos os servizos que ese host executa, o que é máis amplo do que pretenden a maioría das solicitudes de acceso. O porto forma parte do permiso, non un detalle que se engade despois.

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

Ordene o salto antes de calquera aceptación ampla

Unha regra de salto envía o tráfico reenviado desde a lista acoutada a unha cadea privada onde toda a política cabe en tres liñas. A primeira regra acepta o destino e o porto permitidos, e a última descarta todo o demais. O salto debe estar por riba de calquera aceptación ampla en forward, porque unha aceptación anterior fai que o salto nunca se execute. Manteña a aceptación de established e related antes do salto para que o tráfico de retorno siga fluíndo.

Comprobe que ningunha regra fasttrack poida levar este tráfico máis alá da cadea acoutada. Fasttrack evita o resto do percorrido do filtro, e unha sesión acoutada que pasa por fasttrack non está acoutada en absoluto.

Repita a decisión para a cadea input se os servizos propios do router deben ser inalcanzables. Un alcance que bloquea o tráfico reenviado e deixa winbox aberto só está medio rematado.

/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 e pertenza á lista

Desde o cliente, probe o servizo permitido e un que debe fallar, e despois lea as estatísticas de regras no router. Os contadores de aceptación e descarte mostran que ruta tomou cada paquete, algo que o cliente non pode ver. Confirme tamén que o enderezo da sesión viva apareceu na lista acoutada.

Unha lista baleira significa que a conta está noutro perfil ou que o perfil perdeu o seu axuste de lista de enderezos. Un contador de descarte que sobe cun servizo permitido que falla significa que o destino ou o porto non coinciden co que envía o cliente.

Probe o mesmo servizo por nome e por enderezo antes de concluír nada. Un fallo de resolución de nomes parece exactamente un porto bloqueado desde o lado do cliente. Despois rexiste o perfil, ambas as dúas listas e o único servizo permitido na solicitude de acceso para que a seguinte revisión compare en lugar de reconstruír.

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