Seletores de tráfego IPsec: o que cobrem e o que não cobrem

Os seletores de tráfego nomeiam o tráfego interno que um acordo IPsec protege, e o par é negociado em vez de presumido. Dois extremos podem autenticar-se perfeitamente um ao outro e mesmo assim discordar sobre quais pacotes pertencem ao interior do túnel. Essa discordância é invisível no estado da conexão, que normalmente relata um túnel saudável. Ler os seletores dos dois extremos e depois perseguir um destino encontra-a mais depressa do que qualquer quantidade de edição de política.

Leia-os dos dois extremos

Cada extremo descreve o seu próprio lado como local e o outro lado como remoto. O mesmo par de prefixos aparece, por isso, trocado nas duas configurações, e isso é correto e não contraditório. Inverter a perspetiva é a primeira coisa a fazer quando um acordo que funciona parece errado no papel. Comparar dois ficheiros lado a lado sem os trocar produz uma discrepância que não existe.

Os valores nem sempre são sub-redes únicas. Os seletores IKEv2 podem transportar intervalos de endereços, números de protocolo e intervalos de portas, e é assim que uma política protege um serviço em vez de toda uma rede. Um seletor mais estreito do que o tráfego pretendido produz um túnel que transporta alguns destinos e exclui outros em silêncio.

Escreva os dois lados numa única tabela antes de mudar seja o que for. O exercício costuma resolver a questão sem tocar num ficheiro de configuração.

O estreitamento é decisão do respondedor

O iniciador propõe, e o respondedor só pode aceitar um subconjunto. O IKEv2 permite ao respondedor estreitar os seletores de tráfego oferecidos, e o resultado estreitado é o que é realmente instalado. Ler a configuração do iniciador descreve, portanto, uma oferta, não o acordo.

É por isso que uma sub-rede acrescentada ao cliente pode produzir um túnel que funciona e que ainda assim recusa o novo destino. O servidor estreitou a oferta até ao que a sua política permite, enquanto o ficheiro do cliente ainda lista o intervalo mais amplo. Só o estado negociado mostra a verdade: no Linux, ip xfrm policy e a lista de child SA na documentação IKEv2 da strongSwan relatam o que foi instalado e não o que foi pedido. Quando os dois divergem, é a política do respondedor que tem de mudar.

Uma proposta rejeitada é um sintoma diferente de uma estreitada. A rejeição aparece no registo de negociação e não deixa qualquer associação child.

Siga um destino de ponta a ponta

Escolha um destino real mais o endereço de origem que o cliente usaria para ele, e depois siga esse par por três decisões independentes. A rota escolhe um caminho, o seletor decide se esse caminho está protegido, e a firewall decide se o pacote é permitido. Cada um pode falhar por si, e um seletor amplo não repara nenhum dos outros.

ip route get 10.20.30.41
ip xfrm policy list
swanctl --list-sas

A consulta de rota indica a interface e o endereço de origem que levariam o pacote. A lista de políticas mostra se existe uma política de túnel correspondente para esse par, incluindo a direção e o nível. A lista de SA mostra os seletores child negociados juntamente com contadores, por isso uma associação child com zero pacotes depois de se tentar tráfego é a assinatura de seletores que excluem o que é enviado. Três comandos, três respostas diferentes, e só uma delas explica uma queda silenciosa.

Se os contadores child se movem enquanto a aplicação continua a falhar, o problema está para lá do túnel. Isso desloca a investigação para o ouvinte ou a firewall do anfitrião remoto e não para os seletores.

Mantenha os dois objetivos separados

Proteger uma sub-rede de escritório e enviar toda a navegação por uma saída remota são requisitos diferentes com seletores diferentes. Um perfil construído para um raramente serve para o outro, e misturá-los produz ou uma fuga ou uma divisão quebrada. Alargar o intervalo protegido significa mudar os dois extremos e a sua política de encaminhamento, porque uma alteração unilateral torna-se uma proposta rejeitada. É a forma mais comum de um túnel que funcionava deixar de funcionar após uma pequena edição.

Os seletores descrevem a cobertura criptográfica, as rotas escolhem caminhos, e as aplicações impõem as suas próprias permissões. Um túnel que cobre tudo continua a não conseguir alcançar um serviço ligado ao loopback, e uma rota para o túnel continua a precisar de um seletor que inclua o destino. Verifique os três contra o mesmo pedido de teste, e a discrepância nomeia-se a si mesma.