Filtro de tráfego VPN ou regra IPsec: onde o Windows aplica uma porta

Um utilizador de VPN do Windows deve alcançar HTTPS num servidor e não SMB no mesmo servidor, e uma rota não consegue exprimir isso. Ambos os pedidos transportam o mesmo endereço de destino, por isso o prefixo que envia o tráfego para o túnel transporta também o fluxo que queria excluir. Separar os dois exige uma regra que examine algo mais fino do que o destino.

Duas intenções diferentes constroem-se com dois mecanismos do Windows diferentes. Misturá-las produz uma política que parece completa enquanto aplica metade do que pretendia.

Uma rota não separa dois serviços num mesmo endereço

O encaminhamento nativo da VPN baseia-se em prefixos: decide quais destinos passam pelo túnel e quais ficam de fora. É a ferramenta certa para manter uma sub-rede dentro e outra fora, e é cega às portas por construção. Um filtro de tráfego no perfil VPN acrescenta uma segunda dimensão: faz corresponder protocolo, endereço remoto e porta remota ao que pode atravessar essa interface. Uma regra IPsec trabalha num terceiro lugar e exprime quais fluxos exigem proteção e com quem se autenticam. As três respondem a perguntas diferentes e nenhuma substitui as outras.

Comece por escrever a frase pretendida. Permitir apenas HTTPS é uma frase de acesso, enquanto exigir IPsec para HTTPS é uma frase de proteção, e as duas conduzem a uma configuração diferente.

A restrição de acesso e a exigência de proteção divergem

Uma restrição de acesso diz o que pode usar a interface, e é aplicada permitindo um conjunto e recusando tudo o resto. Uma exigência de proteção diz quais fluxos têm de ser cifrados e autenticados, e é aplicada negociando associações de segurança que lhes correspondam. A primeira produz um pedido bloqueado quando algo não está na lista, enquanto a segunda produz uma ligação que ou transporta a proteção exigida ou não se estabelece. Tratar uma como a outra é como uma política acaba sem bloquear nada ou sem proteger nada.

A consequência prática é que uma lista de filtros é um conjunto fechado. Assim que existe uma lista no perfil, o tráfego nessa interface que não corresponde a nenhuma entrada é recusado, pelo que DNS, as trocas de autenticação e qualquer dependência de que a aplicação precise exigem entradas próprias. Acrescentar uma regra ampla para silenciar as recusas reabre toda a interface e anula a restrição em silêncio. A lista deve ser tão curta quanto a exigência permite e tão completa quanto a aplicação requer.

Construa a lista de filtros como um conjunto completo

Os perfis VPNv2 transportam a lista de filtros separadamente da lista de rotas, e as suas entradas são propriedades do perfil e não comandos. Para o exemplo HTTPS a entrada precisa do protocolo 6, do endereço remoto e da porta remota, implementados pelo canal de gestão ou ProfileXML para o tipo de perfil em uso. A definição do filtro de tráfego VPNv2 da Microsoft afirma que as condições dentro de uma regra se combinam enquanto identificadores de regra separados funcionam como alternativas.

TrafficFilterList/0/Protocol            = 6
TrafficFilterList/0/RemoteAddressRanges = 10.60.4.20/32
TrafficFilterList/0/RemotePortRanges    = 443
RouteList/0/Address                     = 10.60.4.0/24

Os valores de porta nessa lista descrevem a porta do serviço na extremidade remota, e a porta local deve ficar sem restrições para que a porta de origem efémera do cliente não seja filtrada. Fazer o contrário produz uma regra que não corresponde a nada e um quebra-cabeças que leva uma tarde.

Escreva a rota e o filtro como duas decisões separadas. A rota decide que este servidor é alcançado pelo túnel, e o filtro decide que serviços podem usar esse caminho.

Prove ambos os resultados com dois pedidos

Teste o fluxo permitido e o fluxo recusado separadamente, e leia a falha em vez da página em falta. Uma recusa que chega depressa é uma decisão de política, enquanto um tempo limite é mais provavelmente uma rota em falta ou um serviço que não escuta. Os comandos abaixo executam os dois pedidos e mostram as regras em vigor.

Test-NetConnection 10.60.4.20 -Port 443
Test-NetConnection 10.60.4.20 -Port 445
Get-NetIPsecRule -DisplayName *Vpn*
Get-VpnConnection -Name Corp

Uma recusa rápida no teste SMB com um teste HTTPS bem-sucedido é o resultado que o filtro devia produzir. Uma recusa nas duas portas significa que a lista carece de algo de que a sessão precisa, e um tempo limite nas duas aponta para encaminhamento e não para filtragem. Se os fluxos protegidos mostrarem nenhuma associação de segurança na saída do IPsec, a exigência de proteção não está satisfeita mesmo quando a ligação tem sucesso. Leia as quatro saídas em conjunto, porque cada uma por si sustenta uma história diferente.

Registe o perfil efetivo, o conjunto de regras e a política do par em conjunto com os resultados. As notas históricas de compatibilidade sobre clientes Windows mais antigos não descrevem o que as funcionalidades de perfil gerido de hoje suportam num determinado gateway. O comportamento específico de cada versão pertence ao registo, não à suposição.