Acceso de VPN a VLAN: construía a matriz antes das regras
Roles dun lado, servizos do outro. Cinco comprobacións converten un deseño vago de acceso de VPN a VLAN nunha táboa que o responsable da devasa pode implementar.
Empece pola matriz, non pola sintaxe da devasa. Unha táboa con roles dun lado e servizos do outro pode revisala o responsable dunha aplicación, discutila o responsable de seguridade e implementala quen teña a pasarela. Esa revisión sae máis barata que depurar regras nas que ninguén se puxo de acordo.
Unha hora escribíndoa aforra despois unha semana de arqueoloxía de regras. O deseño fala de quen chega a que servizo, e esa é a parte que sobrevive a unha renumeración.
Paso 1: nomee os roles antes das redes
Empece polas persoas, non polo conmutador. Anote cada grupo que se conecta en remoto e a única frase que describe que fai ese grupo, como persoal de almacén lendo niveis de existencias ou un contratista mantendo unha integración. Se dous grupos recibisen o mesmo acceso, para este propósito son un só rol.
Détase aquí se un rol só existe por un organigrama. Un rol sen unha necesidade de servizo propia convértese nunha fila de celas idénticas, e as filas idénticas invitan a que alguén conceda máis adiante unha subrede enteira por comodidade. Divida polo que fai a xente, non por quen asina os seus gastos. Seis roles adoitan ser demasiados para unha oficina pequena e tres adoita ser o correcto.
Paso 2: converta cada cela nunha declaración de servizo
Unha cela que di «Aplicacións» non é comprobable. Unha cela que di «HTTPS ao host ERP no 443, desde o grupo de persoal» si o é. Substitua cada nome de rede por un destino, un protocolo e un porto, e despois engada a dependencia sen a cal o servizo non funciona, como o resolvedor interno ou o provedor de identidade.
| 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 |
A columna de dirección atrapa os erros máis caros. O permiso para que o persoal abra unha aplicación non implica permiso para que os servidores de aplicacións abran conexións de volta aos portátiles do persoal, e unha regra con estado que permite a primeira dirección a miúdo lese como se permitise a segunda.
Paso 3: decida onde a identidade se converte en política
Alguén ten que converter unha sesión autenticada nun rol que a pasarela poida aplicar. As opcións admitidas inclúen política de grupo entregada polo backend de autenticación, atributos de sesión de confianza ou grupos de enderezos separados por rol. As tres funcionan; unha etiqueta enviada polo cliente non. Escolla o mecanismo que documenta a súa pasarela, non o que describe unha publicación de foro.
Asignar un enderezo que só parece pertencer a unha VLAN é a mesma non-resposta con outro traxe. A guía de Netgate sobre as regras de devasa de OpenVPN deixa clara a separación: permitir que o túnel se levante é unha decisión distinta de permitir que o tráfico o atravese.
Anote que mecanismo escolleu e onde está configurado. Cando un rol cambia, esa nota é a diferenza entre unha edición e unha cacería por tres interfaces. Tamén lle di a un auditor onde mirar primeiro.
Paso 4: vixíe o enderezo de orixe que ve o destino
A política de reenvío ten que coincidir coa orixe real no límite. Se a pasarela traduce os clientes VPN ao seu propio enderezo, cada devasa posterior ve unha soa orixe e perde a capacidade de decidir por rol. Se conserva o enderezo do cliente, a ruta de volta ten que existir para ese grupo.
Probe as dúas direccións antes de escribir as regras finais e despois rexistre a orixe observada xunto a cada cela. Execute a mesma comprobación desde dous roles distintos e compare o resultado. Se ambos mostran o enderezo da pasarela, a distinción de roles xa se perdeu. Unha matriz que supón enderezos conservados mentres a pasarela fai tradución de orixe falla na primeira ACL posterior.
Paso 5: probe cada cela antes de publicar
Converta cada cela permitida nunha operación representativa e cada cela denegada nun caso negativo. Execute ambos desde un cliente no rol real, non desde a consola da pasarela, porque a consola evita a ruta que está a probar.
# 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 é un achado, non unha casualidade, e o seu sitio está na matriz como cela fallida ata que se corrixa a regra. Manteña os comandos de proba xunto á táboa para que o seguinte revisor os volva executar en lugar de reconstruír o razoamento.
A táboa rematada sobrevive á pasarela para a que se escribiu. As regras cambian co firmware e co fabricante, mentres que a fila que di que un contratista chega a un servizo de proxecto segue sendo certa ata que ese traballo cambie.