Como o IPsec baseado em rotas funciona com uma interface XFRM

O IPsec baseado em rotas entrega à tabela de rotas uma decisão que antes era tomada pelos seletores de política. No Linux, a peça que torna isso possível é a interface XFRM: um dispositivo virtual cujo tráfego é correspondido com o estado IPsec por um identificador de interface, e não por um seletor. Criar uma leva um único comando e não prova nada sobre a existência de um túnel. O dispositivo é um gancho entre o roteamento e a política de segurança, e ambos os lados desse gancho precisam estar configurados antes que algo seja protegido.

O que o dispositivo é e o que não é

Uma interface XFRM é uma alça de roteamento. Os pacotes roteados para dentro dela são correspondidos com políticas XFRM que referenciam o mesmo identificador de interface, e se existirem uma política e um estado, eles são encapsulados. Sem isso, a interface existe, os contadores ficam parados e o tráfego vai para um lugar inútil.

Essa é a primeira divisão diagnóstica. Uma rota para dentro do dispositivo é um fato de roteamento, um estado instalado é um fato de segurança, e um contador que sobe no dispositivo não é nem um nem outro. Quando as pessoas dizem que o túnel está no ar porque a interface mostra UP, estão descrevendo os sinalizadores de link de um dispositivo virtual que não tem par próprio. O sinalizador significa que o dispositivo foi criado e habilitado, nada mais.

Outra fronteira: o identificador de interface não é um nome. Dois dispositivos com nomes parecidos e identificadores diferentes não compartilham estado, e uma conexão configurada com o identificador errado instala um estado que nenhuma rota jamais usará.

Construa uma na ordem correta

Comece pelo dispositivo externo e por um número que você também colocará na configuração do daemon. O exemplo usa eth0 como interface externa e 42 como identificador, endereços que você deve substituir pelos seus.

Levante o dispositivo e então confirme o identificador que o kernel registrou antes de tocar na configuração de VPN:

sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip link set xfrm0 up
ip -d link show xfrm0 | grep -o 'if_id [0-9]*'

Agora configure a conexão no strongSwan com o mesmo identificador, pois o daemon precisa instalar políticas e estados que fazem referência a ele. Defina os seletores de tráfego local e remoto para a faixa que você pretende rotear e então roteie essa faixa para dentro do dispositivo. A configuração do daemon e a tabela de rotas precisam concordar tanto sobre o identificador quanto sobre os destinos, e nenhuma fornece a outra.

Mantenha IKE e ESP fora da rota do túnel

Uma rota padrão apontada para dentro do dispositivo XFRM captura os pacotes encapsulados e também o tráfego que eles carregam. O resultado é um laço: o gateway tenta enviar o próprio ESP pelo túnel que o ESP deveria construir.

A correção é uma rota mais específica para o endereço externo do par pela interface física, que vence a rota padrão porque corresponde a mais bits. O roteamento baseado em marcas faz o mesmo trabalho quando vários túneis compartilham uma tabela, e o strongSwan documenta ambas as abordagens para implantações baseadas em rotas.

Escolha o que escolher, verifique que o pacote externo sai sem encapsulamento. Uma verificação rápida é fazer ping no endereço externo do par depois que o túnel sobe; se isso falhar enquanto a interface está no ar, suspeite de captura e não de alcance. O mesmo raciocínio vale para a porta IKE, porque o tráfego UDP do próprio daemon não pode ser roteado para o dispositivo que ele tenta estabelecer.

Verifique os contadores em dois lugares antes de culpar a criptografia

Os contadores de interface e os contadores de estado medem etapas diferentes. Pacotes roteados para dentro do dispositivo incrementam o dispositivo mesmo quando nenhum estado corresponde, enquanto os contadores de estado só se movem para o tráfego que realmente foi encapsulado.

Leia ambos e depois leia a visão do daemon sobre a associação filha:

ip -s link show xfrm0
sudo ip xfrm state list | grep -E 'src|proto|mode'
sudo swanctl --list-sas

Contadores do dispositivo subindo com saída de estado vazia significam que o roteamento funciona e a política não corresponde, normalmente um erro de identificador ou de seletor. Contadores de estado subindo enquanto o lado remoto não relata nada significam que os pacotes saem mas não chegam ou falham na autenticação, o que aponta para o caminho ou para a configuração do par. Uma associação filha listada com zero tráfego é um problema de seletor em uma das pontas, não uma cifra quebrada.

Decida quem instala as rotas

Dois donos para uma tabela de rotas são a fonte usual de flapping. Se o daemon instala rotas automaticamente, seu gerente de rede não deve instalar também uma rota padrão pelo mesmo dispositivo, e uma rota manual adicionada por um script de inicialização será removida na próxima vez que o daemon se reconfigurar.

Escolha um dono e anote. Quando o daemon é dono das rotas, mantenha o script de inicialização fora da tabela e deixe a definição da conexão descrever os seletores de tráfego. Quando é o gerente de rede, desative a instalação automática e aceite que o daemon não reparará uma rota ausente na reconexão.

As regras de encaminhamento e de firewall são uma decisão separada por cima, porque um gateway que deixa passar o tráfego de outros hosts precisa das duas. O IPsec baseado em rotas torna esse tráfego fácil de expressar com ferramentas de roteamento comuns; não torna a camada de política opcional.