O que registar num VPN site-to-site: seletores e âmbito

Seis meses depois de o túnel entrar em funcionamento, uma nova sub-rede deixa de corresponder à política e o único documento na partilha diz VPN do escritório. É essa a falha que o registo de seletores evita, e é concreta: um conjunto de endereços mudou e a documentação não. Escrever o registo corretamente significa saber qual de vários conjuntos de endereços está a descrever, e registar o que o par realmente aplica em vez do que configurou.

Configurado não é negociado

Num túnel IPsec baseado em políticas, cada lado propõe seletores de tráfego: intervalos de origem e destino para a associação filha. O lado que responde pode estreitar essa proposta, pelo que a associação instalada pode cobrir menos do que a configuração lista. Um registo que copia a configuração descreve uma intenção, não o âmbito de proteção atual. Os dois divergem em silêncio, e nada na página de estado do túnel o assinala.

Mantenha as duas colunas, com a data em que as observou. O seletor configurado é o que pretendia; o negociado é o que o núcleo aplica neste momento. Quando diferem, essa diferença explica uma falha inesperada muito mais vezes do que um erro de encaminhamento.

Uma associação também não representa todos os pares configurados. Um túnel com várias combinações de seletores pode acabar com várias associações filhas, e um registo que lista uma delas é um inventário parcial. Enumere-as em vez de as resumir.

Túneis baseados em rotas selecionam de forma diferente

Com uma interface baseada em rotas, é a tabela de rotas que decide o que entra no túnel e os seletores podem ser deliberadamente amplos. É um desenho legítimo e não desleixo, e o registo tem de o descrever como tal. Anote a rota, a interface para a qual aponta e a política de firewall que limita os serviços alcançáveis. O âmbito de proteção é amplo de propósito, e o âmbito de serviço faz o estreitamento.

Copiar um modelo baseado em políticas para um túnel baseado em rotas produz um documento que descreve um mecanismo que a implementação não usa. O engenheiro seguinte procura então seletores que nunca deviam estar lá, e conclui que o túnel está mal configurado quando apenas está mal documentado.

A tradução pertence à mesma tabela

Quando o NAT apresenta um intervalo diferente ao par, registe os prefixos original e traduzido em conjunto. Anote a fase em que os seletores e as regras de acesso correspondem a eles, porque a ordem decide se o lado remoto chega a ver o endereço que escreveu. Uma tabela com apenas um dos dois intervalos é pior do que nenhuma, pois parece completa.

É este o detalhe que quebra um túnel a funcionar depois de uma alteração de NAT: o seletor continua a corresponder ao prefixo original, o par recebe agora um traduzido, e a sua rota de retorno aponta para um endereço que já não existe. Nada registra um erro no momento em que os dois deixam de coincidir.

O DNS privado pertence ao mesmo lugar. Um nome que resolve para um endereço inutilizável a partir do local relevante é um erro de documentação com um pedido de suporte anexado, e a culpa será do túnel.

Anexe o requisito de serviço

Um intervalo protegido não é uma lista de permissões. Anote que serviços devem estar alcançáveis a partir de que origem, e quem é o dono da aplicação por detrás deles. Esses dois campos respondem a perguntas diferentes, e misturá-los é como uma revisão de segurança acaba a discutir encaminhamento em vez de acesso.

Depois nomeie o administrador de rede que mantém a regra. Um inventário de seletores sem dono fica desatualizado em silêncio, e desatualizado é indistinguível de errado quando o túnel falha às duas da manhã. O dono é também quem pode confirmar que uma alteração foi deliberada.

Transforme o registo num plano de testes

Para cada caminho necessário, escolha um host de origem e de destino representativos e anote a rota, o serviço e o gateway de resposta esperados. Isso transforma o documento num plano de testes em vez de uma descrição. Leia a associação ativa com o comando abaixo e compare-a com a linha negociada que escreveu.

swanctl --list-sas

Um esqueleto de cinco linhas costuma bastar para manter o registo honesto. A versão abaixo cabe num pedido de alteração sem ser truncada:

sites: office <-> dc1
configured selector: 10.10.0.0/16 <-> 10.20.0.0/16
negotiated selector: 10.10.4.0/22 <-> 10.20.0.0/16
translated range: 172.16.4.0/22 -> 10.10.4.0/22
service and owner: erp:443 / finance-netops

Um ping só ao gateway não é o teste de aceitação. Nunca exercita o caminho de trânsito, por isso pode passar enquanto todos os fluxos encaminhados falham. Teste de um host de um lado para um serviço do outro e confirme que a resposta chega pelo túnel. Se só o ping passar, o registo acabou de encontrar o problema de encaminhamento que devia evitar. A documentação do strongSwan sobre encaminhamento explica como seletores, rotas e encaminhamento interagem num par Linux.