Clientes VPN y la LAN: cuándo usar una zona separada

Poner la interfaz del túnel en la zona de la LAN es el camino más corto hacia una VPN que funciona, y normalmente es el valor predeterminado equivocado. Concede al cliente remoto la misma confianza que tiene la LAN cableada, algo que la tarea rara vez exige. Una zona separada cuesta unas cuantas reglas y hace visible la frontera. La decisión no es si las zonas son mejores; es qué tres condiciones se aplican a su red.

El nombre de la zona no cifra nada ni autentica a ningún usuario. Solo agrupa interfaces para el modelo de políticas del cortafuegos.

Qué controla realmente la pertenencia a una zona

Una zona agrupa interfaces o tráfico dentro del modelo del cortafuegos. Después, su configuración de entrada, salida y reenvío gobierna roles distintos. La entrada es el tráfico hacia el propio enrutador; el reenvío es el tráfico que lo atraviesa hacia otro host. La documentación de OpenWrt sobre zonas trata entrada, salida y reenvío como ajustes separados exactamente por ese motivo.

Un permiso de la zona VPN hacia la zona LAN no es automáticamente un permiso inverso. Las reglas de reenvío son direccionales, y una regla que permite tráfico de cliente a servidor no permite sesiones de servidor a cliente. Un cliente que puede abrir una conexión hacia un servidor no es un cliente al que el servidor pueda abrir una conexión de vuelta.

Esa distinción es la razón por la que una zona separada resulta útil: puede declarar cada dirección y cada rol de forma explícita. Escriba la dirección junto a cada regla.

Decisión uno: entrada, reenvío o ambas

Si los clientes remotos necesitan DNS del enrutador, permita entrada solo para ese servicio. Si necesitan llegar a un servidor de archivos, permita reenvío hacia ese destino. La mayoría de los diseños VPN necesitan ambas cosas, pero para servicios distintos.

El acceso amplio de entrada a todos los servicios locales casi nunca es necesario. Trate la administración del enrutador como una decisión separada del acceso a aplicaciones. Si el enrutador solo necesita responder DNS, escriba ese único permiso y deje el resto cerrado.

Decisión dos: qué recursos necesitan los clientes remotos

Enumere los rangos de clientes, los destinos y los servicios que la VPN debe ofrecer antes de escribir reglas. Una lista de destinos es más útil que una etiqueta de confianza, porque sobrevive a una migración del cortafuegos.

Mantenga las interfaces de gestión separadas del acceso habitual a las aplicaciones. Un cliente remoto que alcanza una wiki no necesita por ello la página de administración del enrutador ni la consola del hipervisor.

Si un destino permitido puede reenviar más allá, la frontera de la zona termina en el cortafuegos, no en lo que el destino haga después.

Decisión tres: cómo demostrará la frontera

Pruebe un flujo permitido y otro denegado a propósito después de cada cambio. Demostrar que un sitio web carga no revela un permiso amplio no intencionado. Pruebe desde el rango de direcciones del cliente VPN, no desde la LAN, e incluya la dirección que espera que falle. Anote ambos resultados junto a la regla.

Conserve el acceso de recuperación de la puerta de enlace antes de modificar la política de la zona remota. Use la configuración gestionada persistente en lugar de ediciones en tiempo de ejecución, o el próximo reinicio restaurará la antigua confianza. Una copia de la configuración anterior, guardada fuera del dispositivo, es la reversión más barata que tendrá nunca.

Cuando la red crezca, documente la pertenencia y el propósito de las reglas. Una interfaz recién conectada no debería heredar privilegios solo porque alguien le dio un nombre de zona conveniente.