Tráfego do cliente VPN e estado do firewall: fluxo externo e interno

O handshake VPN termina, o cliente recebe um endereço, e um serviço atrás do gateway continua a recusar a conexão. O firewall muitas vezes faz exatamente o que lhe foi dito. Permitiu o fluxo externo do túnel, que é um pacote diferente da conexão da aplicação desencapsulada. Seguem-se duas decisões: qual fluxo está a autorizar, e se a fronteira acompanha o estado de todo.

Enquanto não separar as duas coisas, cada alteração de regra é um palpite.

O firewall vê dois pacotes diferentes

Antes da desencapsulação, o firewall vê tráfego endereçado ao ponto final VPN: um fluxo UDP externo para o ouvinte. Depois da desencapsulação, um pacote encaminhado transporta o endereço interno do cliente e o destino do serviço.

Uma autorização para o fluxo externo não autoriza a conexão TCP encaminhada. Podem ser avaliadas em cadeias diferentes, contra interfaces diferentes e com endereços diferentes após a tradução.

Compare capturas de posições equivalentes nos dois lados. Uma captura na extremidade do túnel e uma captura no servidor mostram tuplos diferentes para a mesma sessão.

Primeira decisão: autorizar o túnel ou o serviço

Se o cliente só precisa do próprio ponto final VPN, a autorização externa pode bastar. Se precisa de um serviço para lá do gateway, é necessária uma autorização de encaminhamento para esse destino e porta. Uma regra de túnel que também autoriza o serviço é uma decisão de conceção que deve nomear, não um acidente.

Mantenha o intervalo de clientes e o âmbito do serviço estreitos. Uma autorização da sub-rede do túnel para toda a LAN é uma decisão de confiar em cada anfitrião, não um atalho para uma aplicação.

Escreva as duas regras em separado. A regra do túnel e a regra do serviço falham de formas diferentes e são depuradas com provas diferentes. Quando uma falha, sabe que camada inspecionar primeiro.

Segunda decisão: com estado ou sem estado em cada fronteira

Uma regra de fluxo estabelecido pode admitir respostas para uma troca autorizada, mas o seu comportamento depende do produto. Um grupo de segurança na nuvem costuma manter estado; uma lista de controlo de sub-rede muitas vezes não o mantém e exige tratamento explícito nos dois sentidos. Não assuma que cada fronteira do caminho trata o estado da mesma forma. Enumere cada fronteira e marque-a com ou sem acompanhamento de estado antes de conceber as regras.

Se uma regra mudar, os fluxos seguidos existentes podem continuar a funcionar enquanto os novos falham, ou o contrário. Essa diferença é uma pista útil, não uma razão para limpar todo o estado das ligações num gateway em produção.

Teste com um pedido novo e controlado e inspecione os contadores relevantes. Um teste limpo é melhor do que um reinício perturbador. Anote o nome do contador no registo de alterações para que o próximo teste use a mesma prova.

Verifique o caminho de retorno com a mesma política

Envie um novo pedido do cliente para o serviço e depois verifique os contadores de ida e de retorno em cada fronteira. Confirme que a resposta usa o caminho esperado, sobretudo se houver tradução envolvida.

Mantenha estreitos o intervalo de clientes previsto e o âmbito do serviço, e verifique o caminho de retorno com o mesmo conjunto de regras que autorizou o pedido. Uma regra que só funciona porque um fluxo antigo continua aberto não é uma regra funcional.