Acceso de VPN a VLAN: construya la matriz antes que las reglas
Roles a un lado, servicios al otro. Cinco comprobaciones convierten un diseño vago de acceso de VPN a VLAN en una tabla que el responsable del cortafuegos puede implementar.
Empiece por la matriz, no por la sintaxis del cortafuegos. Una tabla con roles a un lado y servicios al otro puede revisarla el responsable de una aplicación, discutirla el responsable de seguridad e implementarla quien tenga la puerta de enlace. Esa revisión sale más barata que depurar reglas en las que nadie se puso de acuerdo.
Una hora escribiéndola ahorra después una semana de arqueología de reglas. El diseño habla de quién llega a qué servicio, y esa es la parte que sobrevive a un renumerado.
Paso 1: nombre los roles antes que las redes
Empiece por las personas, no por el conmutador. Anote cada grupo que se conecta en remoto y la única frase que describe qué hace ese grupo, como personal de almacén leyendo niveles de existencias o un contratista manteniendo una integración. Si dos grupos recibieran el mismo acceso, para este propósito son un solo rol.
Deténgase aquí si un rol solo existe por un organigrama. Un rol sin una necesidad de servicio propia se convierte en una fila de celdas idénticas, y las filas idénticas invitan a que alguien conceda más adelante una subred entera por comodidad. Divida por lo que hace la gente, no por quién firma sus gastos. Seis roles suelen ser demasiados para una oficina pequeña y tres a menudo es lo correcto.
Paso 2: convierta cada celda en una declaración de servicio
Una celda que dice «Aplicaciones» no es comprobable. Una celda que dice «HTTPS al host ERP en el 443, desde el grupo de personal» sí lo es. Sustituya cada nombre de red por un destino, un protocolo y un puerto, y luego añada la dependencia sin la cual el servicio no funciona, como el resolutor interno o el proveedor de identidad.
| Check | Passes when | Stop if |
|---|---|---|
| Destination named | Host and port appear in the cell | Cell names a VLAN or a subnet |
| Direction stated | Initiator and responder are both clear | Cell implies two-way access |
| Dependency listed | DNS or identity path is explicit | Whole infrastructure range is granted |
| Negative case written | At least one denied pair is recorded | Only allow rules exist |
La columna de dirección atrapa los errores más caros. El permiso para que el personal abra una aplicación no implica permiso para que los servidores de aplicaciones abran conexiones de vuelta a los portátiles del personal, y una regla con estado que permite la primera dirección a menudo se lee como si permitiera la segunda.
Paso 3: decida dónde la identidad se convierte en política
Alguien tiene que convertir una sesión autenticada en un rol que la puerta de enlace pueda aplicar. Las opciones admitidas incluyen política de grupo entregada por el backend de autenticación, atributos de sesión de confianza o grupos de direcciones separados por rol. Las tres funcionan; una etiqueta enviada por el cliente no. Elija el mecanismo que documenta su puerta de enlace, no el que describe una publicación de foro.
Asignar una dirección que solo parece pertenecer a una VLAN es la misma no-respuesta con otro traje. La guía de Netgate sobre las reglas de cortafuegos de OpenVPN deja clara la separación: permitir que el túnel se levante es una decisión distinta de permitir que el tráfico lo atraviese.
Anote qué mecanismo eligió y dónde está configurado. Cuando un rol cambia, esa nota es la diferencia entre una edición y una cacería por tres interfaces. También le dice a un auditor dónde mirar primero.
Paso 4: vigile la dirección de origen que ve el destino
La política de reenvío tiene que coincidir con el origen real en el límite. Si la puerta de enlace traduce los clientes VPN a su propia dirección, cada cortafuegos posterior ve un solo origen y pierde la capacidad de decidir por rol. Si conserva la dirección del cliente, la ruta de vuelta tiene que existir para ese grupo.
Pruebe ambas direcciones antes de escribir las reglas finales y luego registre el origen observado junto a cada celda. Ejecute la misma comprobación desde dos roles distintos y compare el resultado. Si ambos muestran la dirección de la puerta de enlace, la distinción de roles ya se ha perdido. Una matriz que supone direcciones conservadas mientras la puerta de enlace hace traducción de origen falla en la primera ACL posterior.
Paso 5: pruebe cada celda antes de publicar
Convierta cada celda permitida en una operación representativa y cada celda denegada en un caso negativo. Ejecute ambos desde un cliente en el rol real, no desde la consola de la puerta de enlace, porque la consola evita la ruta que está probando.
# allowed: staff role reaches the ERP endpoint
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://erp.internal.example/health
# denied: the same role must not reach a management host
nc -vz -w 3 10.30.5.11 22
# observed source address at the destination
sudo tcpdump -ni any 'tcp port 443 and host 10.30.20.15'Un caso negativo que conecta es un hallazgo, no una casualidad, y su sitio está en la matriz como celda fallida hasta que se corrija la regla. Mantenga los comandos de prueba junto a la tabla para que el siguiente revisor los vuelva a ejecutar en lugar de reconstruir el razonamiento.
La tabla terminada sobrevive a la puerta de enlace para la que se escribió. Las reglas cambian con el firmware y el fabricante, mientras que la fila que dice que un contratista llega a un servicio de proyecto sigue siendo cierta hasta que ese trabajo cambie.