Por que uma rota OpenVPN perde para uma política XFRM do strongSwan

Os pacotes podem seguir uma rota OpenVPN e ainda assim serem capturados por uma política IPsec, e essa combinação parece um bug de roteamento de todos os ângulos menos do ângulo certo. O Linux resolve uma rota e depois consulta um banco de dados de políticas de segurança separado, então uma rota de destino mais específica não desloca uma política XFRM correspondente. O sintoma visível é tráfego que sai do host e nunca chega, enquanto os dois túneis se declaram saudáveis. Três opções resolvem isso, e qual você escolhe depende de qual dos dois caminhos deve carregar esse prefixo.

Duas decisões, não uma

A seleção de rota responde a uma pergunta estreita: qual próximo salto e qual endereço de origem devem carregar este pacote. O banco de políticas de segurança responde a outra: este pacote exige proteção IPsec, e sob quais seletores. Ambos rodam para o mesmo pacote, e satisfazer o primeiro não diz nada sobre o segundo. É por isso que mudar uma métrica ou adicionar uma rota estática pode deixar o sintoma intacto.

Um seletor IPsec amplo é a causa habitual. Uma política que protege 172.16.0.0/12 também cobre 172.20.8.0/24, que um administrador pode pretender alcançar pelo túnel OpenVPN. A intenção só existe na tabela de roteamento, e o banco de políticas nunca soube dela.

Trate isso como um conflito entre dois caminhos de proteção configurados e não como uma disputa entre duas métricas. A correção pertence ao componente que foi configurado com o escopo errado.

Leia a rota que o kernel realmente escolhe

Comece pela consulta que o kernel faz, incluindo o endereço de origem e qualquer regra de política que possa desviá-la para outra tabela. Uma rota na tabela principal pode nunca ser consultada se uma regra anterior escolher outra tabela, e a correspondência do prefixo mais longo só se aplica dentro da tabela que uma regra escolhe.

ip rule show
ip route show table all
ip route get 172.20.8.20 from 10.44.7.15

O último comando é o que importa, porque imprime a rota escolhida junto com o endereço de origem que o kernel usaria. Compare essa saída com o seletor com o qual a política IPsec corresponde. Quando a rota aponta para a interface OpenVPN e a política ainda corresponde ao mesmo par, você reproduziu o conflito sem adivinhar.

Mantenha os despejos livres de endereços não relacionados antes que cheguem a um chamado. Uma tabela de roteamento de um host de produção carrega topologia interna, e só as linhas que respondem à pergunta merecem ser coladas.

Leia também a política que se aplica

A listagem de políticas mostra direção, seletores e o modelo que decide o que acontece com um pacote correspondente. Leia primeiro a direção de saída, depois o lado de entrada para o tráfego de retorno, porque uma exceção unidirecional produz uma conexão que começa e nunca termina.

ip -s xfrm policy
swanctl --list-sas

Compare os seletores da listagem com os prefixos que a conexão negociou. Desativar a instalação de rotas do strongSwan não remove essas políticas, e mudar uma métrica não altera qual par de origem e destino uma política protege. Essas duas falsas correções merecem ser descartadas cedo, porque são as primeiras que as pessoas tentam.

Se a listagem não contiver nenhuma política para o prefixo esperado, o problema está em outro lugar e a tabela de roteamento provavelmente está dizendo a verdade. Se contiver uma política mais ampla que cobre o prefixo, você encontrou a captura.

Três opções quando os dois caminhos são legítimos

Restringir o seletor IPsec é a opção mais limpa quando o prefixo amplo era uma comodidade e não um requisito. Reduzir o seletor de tráfego remoto às sub-redes que realmente pertencem atrás do IPsec elimina o conflito para todos os hosts de uma vez, e custa uma renegociação de chaves em vez de um novo componente.

Uma exceção passthrough é a opção cirúrgica quando o seletor amplo precisa permanecer. O strongSwan suporta uma conexão separada cujo filho usa o modo pass, o que diz ao kernel que o tráfego correspondente não deve ser processado pelo IPsec. O endereço remoto de loopback impede que essa conexão seja escolhida para pares de entrada, e os seletores devem descrever o par autorizado real e não tudo.

connections {
    openvpn-exception {
        remote_addrs = 127.0.0.1
        children {
            openvpn-exception {
                local_ts = 10.44.7.0/24
                remote_ts = 172.20.8.0/24
                mode = pass
                start_action = trap
            }
        }
    }
}

Os exemplos de configuração do strongSwan documentam esse tipo de política e a convenção de par de loopback. A terceira opção é um projeto baseado em roteamento com interfaces XFRM, que liga a política ao tráfego roteado por uma interface nomeada em vez de a um seletor global. É uma migração e não um ajuste, e o tráfego ainda precisa satisfazer os seletores negociados.

Prove a exceção sem enfraquecer o resto

Depois de carregar a mudança, teste a exceção e um destino comum que deve continuar protegido. Verifique os dois sentidos, depois derrube o túnel OpenVPN e confirme o que acontece com o tráfego excecionado. Uma exceção que envia esse prefixo abertamente em silêncio quando o túnel está fora é uma decisão de política que você deve tomar de propósito, não descobrir durante um incidente.

Anote qual prefixo usa qual caminho e por quê. Senão o próximo engenheiro que vir um seletor amplo reabrirá a mesma investigação, e a resposta estará em uma mensagem de commit que ninguém lê.