Depois da decifragem: qual política vê primeiro o seu tráfego VPN
O cabo não diz nada sobre qual regra processou o fluxo. Nomeie o gancho de política e o salto seguinte, e prove que a resposta segue o mesmo caminho.
Um fluxo VPN pode estar perfeitamente cifrado e perfeitamente autenticado e ainda assim acabar onde ninguém planejou. O cabo que você liga não determina qual regra processa o pacote interno; isso fazem o gancho de política e a rota. Por isso dois desenhos idênticos num diagrama de rack podem ter uma aplicação completamente diferente. Escolher entre eles começa por nomear o controlo que vê primeiro o fluxo decifrado.
Decida pelo gancho de política, não pela porta
Cada plataforma VPN avalia o tráfego decifrado em algum ponto antes de o encaminhar, e esse ponto tem um nome na configuração. Numa plataforma é um filtro de política de grupo, noutra uma política de interface ou um par de zonas, e num equipamento que encaminha pode ser simplesmente a cadeia forward. O gancho é o que aplica a regra, enquanto a porta do comutador é apenas onde o cabo termina. Encontrar o gancho é a primeira decisão, porque tudo o resto é colocação em relação a ele.
Antes de olhar para o hardware, escreva o fluxo: quem é a origem, para onde vai, que protocolo o transporta e que serviço é permitido. Depois encontre o controlo que aplica cada um desses quatro factos.
Dois caminhos, duas histórias de aplicação
Duas formas são comuns e cada uma pode estar correta para um requisito diferente.
endpoint -> shared inside subnet -> server
endpoint -> dedicated transit -> policy firewall -> server subnetA primeira forma pode aplicar tudo o que é necessário na gateway, desde que a política esteja escrita para esse destino e o servidor não tenha um caminho que a contorne. A segunda acrescenta uma fronteira, mas só se as rotas e a política fizerem o tráfego atravessá-la de facto. Um servidor no mesmo segmento do ponto final pode nunca seguir o salto intermédio imaginado. O diagrama mostra a intenção e a tabela de rotas mostra o que acontece.
Verifique com uma consulta de rota e não com o desenho. A interface por onde o pacote sai e o salto seguinte que escolhe decidem se a segunda forma se comporta como foi desenhada.
ip route get 10.30.7.20
sudo iptables -S FORWARD
sudo tcpdump -ni inside0 host 10.30.7.20Separe a topologia do isolamento
Partilhar uma sub-rede não torna um local não confiável, e um trânsito dedicado não o torna protegido. O que decide é a restrição realmente aplicada, o encaminhamento que realmente acontece e quem administra cada peça. Contar comutadores não diz nada sobre nenhuma das três. Decida a partir da política e da rota, e deixe a topologia seguir a decisão.
Trate também as populações de tráfego em separado. Os pools de acesso remoto, os prefixos local-a-local e as redes de linha privada podem partilhar um equipamento e ainda assim precisar de regras diferentes, porque a identidade e o risco diferem. Uma regra escrita para uma população cobre silenciosamente as outras quando partilham um plano de endereços.
Verifique a falha e a gestão de cada colocação
Cada colocação tem um modo de falha, e a pergunta útil é o que continua a funcionar quando um componente para. Várias interfaces lógicas num único equipamento morto não dão recuperação independente, e uma firewall a jusante que partilha a mesma alimentação ou o mesmo administrador não é uma segunda fronteira. Pergunte por onde passa o caminho de gestão, porque uma consola acessível apenas pelo túnel não é caminho de recuperação nenhum; ssh [email protected] true de fora do túnel é a forma mais barata de provar que a consola não depende dele. A documentação de política de grupo de uma plataforma coloca o filtro em tráfego posterior à decifragem e anterior à cifragem, que é exatamente o tipo de gancho nomeado a procurar em qualquer produto.
Escreva a história de falha de cada candidato ao lado da história de aplicação. Uma colocação que ganha na inspeção e perde na recuperação é uma troca, e deve ser registada como tal em vez de descoberta durante um incidente.
Aceite com um fluxo permitido e um negado
Com um plano de testes aprovado, verifique três coisas a partir da origem VPN real: uma aplicação que devia funcionar, um recurso que não devia, e a direção por onde a resposta regressa. A negação é a prova de que a política está ativa, enquanto o fluxo permitido apenas demonstra que existe um caminho.
Guarde o caminho escolhido e o resultado da política em conjunto, porque um resultado sem caminho não é reproduzível e um caminho sem resultado não é defensável. Esse par é muito mais útil para escolher um ponto de ligação do que qualquer afirmação sobre que camada de comutação é intrinsecamente mais segura.