Clientes VPN e a LAN: cando usar unha zona separada

Pór a interface do túnel na zona da LAN é o camiño máis curto cara a unha VPN que funciona, e normalmente é o valor predeterminado incorrecto. Concede ao cliente remoto a mesma confianza que ten a LAN por cable, algo que a tarefa raramente esixe. Unha zona separada custa unhas cantas regras e fai visible a fronteira. A decisión non é se as zonas son mellores; é que tres condicións se aplican á súa rede.

O nome da zona non cifra nada nin autentica ningún usuario. Só agrupa interfaces para o modelo de políticas da devasa.

Que controla realmente a pertenza a unha zona

Unha zona agrupa interfaces ou tráfico dentro do modelo da devasa. Despois, a súa configuración de entrada, saída e reenvío goberna roles distintos. A entrada é o tráfico cara ao propio encamiñador; o reenvío é o tráfico que o atravesa cara a outro host. A documentación de OpenWrt sobre zonas trata entrada, saída e reenvío como axustes separados exactamente por ese motivo.

Un permiso da zona VPN cara á zona LAN non é automaticamente un permiso inverso. As regras de reenvío son direccionais, e unha regra que permite tráfico de cliente a servidor non permite sesións de servidor a cliente. Un cliente que pode abrir unha conexión cara a un servidor non é un cliente ao que o servidor poida abrir unha conexión de volta.

Esa distinción é a razón pola que unha zona separada resulta útil: pode declarar cada dirección e cada rol de forma explícita. Escriba a dirección xunto a cada regra.

Decisión un: entrada, reenvío ou ambas

Se os clientes remotos necesitan DNS do encamiñador, permita entrada só para ese servizo. Se necesitan chegar a un servidor de ficheiros, permita reenvío cara a ese destino. A maioría dos deseños VPN necesitan ambas as cousas, pero para servizos distintos.

O acceso amplo de entrada a todos os servizos locais case nunca é necesario. Trate a administración do encamiñador como unha decisión separada do acceso a aplicacións. Se o encamiñador só necesita responder DNS, escriba ese único permiso e deixe o resto pechado.

Decisión dous: que recursos necesitan os clientes remotos

Enumere os rangos de clientes, os destinos e os servizos que a VPN debe ofrecer antes de escribir regras. Unha lista de destinos é máis útil que unha etiqueta de confianza, porque sobrevive a unha migración da devasa.

Manteña as interfaces de xestión separadas do acceso habitual ás aplicacións. Un cliente remoto que chega a un wiki non necesita por iso a páxina de administración do encamiñador nin a consola do hipervisor.

Se un destino permitido pode reenviar máis aló, a fronteira da zona remata na devasa, non no que o destino faga despois.

Decisión tres: como demostrará a fronteira

Probe un fluxo permitido e outro denegado a propósito despois de cada cambio. Demostrar que un sitio web carga non revela un permiso amplo non intencionado. Probe desde o rango de enderezos do cliente VPN, non desde a LAN, e inclúa a dirección que espera que falle. Anote ambos os resultados xunto á regra.

Conserve o acceso de recuperación da pasarela antes de modificar a política da zona remota. Use a configuración xestionada persistente en lugar de edicións en tempo de execución, ou o vindeiro reinicio restaurará a antiga confianza. Unha copia da configuración anterior, gardada fóra do dispositivo, é a reversión máis barata que terá nunca.

Cando a rede medre, documente a pertenza e o propósito das regras. Unha interface recentemente conectada non debería herdar privilexios só porque alguén lle deu un nome de zona conveniente.