Um seletor IPsec amplo não é permissão para todos os serviços

Dois pares concordam em proteger uma sub-rede inteira, e alguém lê esse acordo como permissão para alcançar todos os serviços dentro dela. Esse é o mito: o seletor diz qual tráfego o túnel está disposto a transportar, e não diz nada sobre quais serviços a organização permite. Um par de dispositivos pode negociar legitimamente uma faixa ampla de endereços enquanto a política de acesso dentro dela permite duas portas, e ambas as afirmações continuam verdadeiras ao mesmo tempo.

Cobertura protegida não é autorização

Um seletor de tráfego faz parte do acordo do túnel. Ele restringe ou confirma o que os pares vão cifrar entre si, e um seletor amplo costuma ser a coisa mais simples de operar quando os dois lados têm muitos fluxos a transportar. O filtro de serviços é outro controle em outro ponto do caminho, e decide o que pode realmente ser usado depois que o pacote foi decifrado. Remover o filtro para fazer um teste passar transforma uma decisão de política em acidente.

Mantenha os dois registros separados no documento de projeto, porque um leitor que vê apenas o seletor vai inferir uma autorização que nunca foi concedida. Duas linhas em um registro de mudança evitam isso, e levam menos tempo do que a discussão que vem depois.

Descreva um fluxo pelas duas pontas

Anote o iniciador, o respondedor, a origem e o destino conforme apresentados, o protocolo e as duas portas. Depois inverta cada um desses rótulos para o outro ponto final, porque a porta de origem efêmera de um cliente se torna a porta de destino de uma resposta e a rede remota se torna a local. Uma configuração copiada de um lado para o outro sem essa inversão é como os filtros acabam permitindo exatamente a direção errada. Escreva a tabela uma vez e construa os dois filtros a partir dela.

Combine o modelo de seleção antes de copiar qualquer coisa, já que um projeto baseado em política e um projeto baseado em rotas expressam a mesma intenção por objetos diferentes. Anote o nome do modelo ao lado do fluxo, ou o próximo engenheiro passará uma tarde combinando objetos que nunca foram comparáveis.

Encontre o filtro que realmente se aplica

Em um ASA, o filtro VPN é uma ACL anexada a uma política de grupo e aplicada ao tráfego após a decifragem e antes da cifragem. A documentação de política de grupo da Cisco também descreve herança, incluindo um valor no nível do usuário que substitui o valor da política de grupo. Portanto, a ACL que você editou pode não ser a ACL que governa a sessão à sua frente. O mesmo vale para o objeto de usuário, que pode sobrepor o grupo sem deixar muita evidência visível.

Inspecione a sessão efetiva em vez do objeto que você lembra ter alterado, e anote qual objeto de política a fornece. Esse único passo resolve um número surpreendente de relatos do tipo „o filtro está certo, mas não funciona“.

Direção, portas e o caso inverso

A convenção documentada coloca a rede remota, ou os endereços de cliente remoto atribuídos, na posição de origem e a rede local na posição de destino, com as respostas expressas pela troca das posições dos endereços. As regras de porta ficam por cima dessa convenção e merecem mais cuidado do que os endereços.

O modelo documentado pode deixar uma regra de porta de destino afetar a iniciação inversa que usa essa mesma porta de origem, o que significa que o filtro não é simplesmente uma regra de requisição de mão única com respostas inofensivas anexadas. Raciocine explicitamente pelas duas direções de iniciação e inclua o caso que você pretende negar.

A mesma documentação limita o filtro a conexões iniciais, então ele não é aplicação universal de todo canal secundário que uma aplicação inspecionada abre. Onde a política completa precisa dessa cobertura, ela pertence a uma fronteira separada, e não a uma ACL esticada além do seu propósito.

Teste três casos antes de considerar pronto

Aceite o fluxo pretendido, recuse um serviço que a política proíbe e exercite o caso de direção inversa sobre o qual você raciocinou. Execute-os sob um plano aprovado com as mesmas identidades e seletores que você vai implantar. Um teste que só mostra o serviço permitido funcionando demonstra o túnel, não a política.

Mantenha a cobertura negociada e a decisão de acesso como dois registros, porque explicar o que uma VPN permite exige os dois.