Acesso de VPN a VLAN: construa a matriz antes das regras
Papéis de um lado, serviços do outro. Cinco verificações transformam um desenho vago de acesso de VPN a VLAN numa tabela que o responsável pela firewall pode implementar.
Comece pela matriz, não pela sintaxe da firewall. Uma tabela com papéis de um lado e serviços do outro pode ser revista pelo responsável de uma aplicação, discutida pelo responsável de segurança e implementada por quem detém a gateway. Essa revisão sai mais barata do que depurar regras com que ninguém concordou.
Uma hora a escrevê-la poupa depois uma semana de arqueologia de regras. O desenho fala de quem chega a que serviço, e é essa a parte que sobrevive a uma renumeração.
Passo 1: nomeie os papéis antes das redes
Comece pelas pessoas, não pelo comutador. Anote cada grupo que se liga remotamente e a única frase que descreve o que esse grupo faz, como pessoal de armazém a ler níveis de existências ou um contratante a manter uma integração. Se dois grupos recebessem o mesmo acesso, são um só papel para este efeito.
Pare aqui se um papel só existe por causa de um organigrama. Um papel sem necessidade própria de serviço torna-se uma linha de células idênticas, e linhas idênticas convidam alguém a conceder mais tarde uma sub-rede inteira por conveniência. Divida pelo que as pessoas fazem, não por quem assina as suas despesas. Seis papéis costumam ser demasiados para um escritório pequeno e três é muitas vezes o correcto.
Passo 2: transforme cada célula numa declaração de serviço
Uma célula que diz «Aplicações» não é verificável. Uma célula que diz «HTTPS para o anfitrião ERP na 443, a partir do conjunto de pessoal» é. Substitua cada nome de rede por um destino, um protocolo e uma porta, e depois acrescente a dependência sem a qual o serviço não funciona, como o resolvedor interno ou o fornecedor 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 coluna da direção apanha os erros mais caros. A permissão para o pessoal abrir uma aplicação não implica permissão para os servidores de aplicações abrirem ligações de volta para os portáteis do pessoal, e uma regra com estado que permite a primeira direção é muitas vezes lida como permitindo a segunda.
Passo 3: decida onde a identidade se torna política
Alguém tem de converter uma sessão autenticada num papel que a gateway possa aplicar. As opções suportadas incluem política de grupo fornecida pelo backend de autenticação, atributos de sessão de confiança ou conjuntos de endereços separados por papel. As três funcionam; uma etiqueta enviada pelo cliente não. Escolha o mecanismo que a sua gateway documenta, não o que uma publicação de fórum descreve.
Atribuir um endereço que apenas parece pertencer a uma VLAN é a mesma não-resposta com outro fato. O guia da Netgate sobre as regras de firewall do OpenVPN torna a separação clara: permitir que o túnel suba é uma decisão diferente de permitir que o tráfego passe por ele.
Anote que mecanismo escolheu e onde está configurado. Quando um papel muda, essa nota é a diferença entre uma edição e uma caça por três interfaces. Também diz a um auditor onde olhar primeiro.
Passo 4: vigie o endereço de origem que o destino vê
A política de encaminhamento tem de coincidir com a origem real na fronteira. Se a gateway traduz os clientes VPN para o seu próprio endereço, cada firewall a jusante vê uma só origem e perde a capacidade de decidir por papel. Se preserva o endereço do cliente, o caminho de retorno tem de existir para esse conjunto.
Teste as duas direções antes de escrever as regras finais e depois registe a origem observada junto a cada célula. Execute a mesma verificação a partir de dois papéis diferentes e compare o resultado. Se ambos mostrarem o endereço da gateway, a distinção de papéis já se perdeu. Uma matriz que assume endereços preservados enquanto a gateway faz tradução de origem falha na primeira ACL a jusante.
Passo 5: teste cada célula antes de publicar
Converta cada célula permitida numa operação representativa e cada célula negada num caso negativo. Execute ambas a partir de um cliente no papel real, não da consola da gateway, porque a consola contorna o caminho que está a testar.
# 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'Um caso negativo que liga é um achado, não uma casualidade, e o seu lugar está na matriz como célula falhada até a regra ser corrigida. Mantenha os comandos de teste ao lado da tabela para que o próximo revisor os volte a executar em vez de reconstruir o raciocínio.
A tabela terminada sobrevive à gateway para a qual foi escrita. As regras mudam com o firmware e o fornecedor, enquanto a linha que diz que um contratante chega a um serviço de projeto continua verdadeira até esse trabalho mudar.