Por que unha ruta de OpenVPN perde ante unha política XFRM de strongSwan

Os paquetes poden seguir unha ruta de OpenVPN e aínda así ser capturados por unha política IPsec, e esa combinación parece un erro de enrutamento desde todos os ángulos menos o correcto. Linux resolve unha ruta e despois consulta unha base de datos de políticas de seguridade separada, así que unha ruta de destino máis específica non despraza unha política XFRM coincidente. O síntoma visible é tráfico que sae do host e nunca chega, mentres ambos os túneles se declaran sans. Tres opcións o resolven, e cal elixa depende de cal dos dous camiños debe levar ese prefixo.

Dúas decisións, non unha

A selección de ruta responde unha pregunta estreita: que seguinte salto e que enderezo de orixe deben levar este paquete. A base de datos de políticas de seguridade responde outra: este paquete require protección IPsec e baixo que selectores. Ambas se executan para o mesmo paquete, e satisfacer a primeira non di nada sobre a segunda. Por iso cambiar unha métrica ou engadir unha ruta estática pode deixar o síntoma intacto.

Un selector IPsec amplo é a causa habitual. Unha política que protexe 172.16.0.0/12 tamén cobre 172.20.8.0/24, ao que un administrador pode querer chegar polo túnel de OpenVPN. A intención só existe na táboa de enrutamento, e a base de datos de políticas nunca a coñeceu.

Tráteo como un conflito entre dous camiños de protección configurados e non como unha competición entre dúas métricas. A corrección pertence ao compoñente que se configurou co alcance equivocado.

Lea a ruta que o núcleo elixe de verdade

Comece pola consulta que fai o núcleo, incluído o enderezo de orixe e calquera regra de política que puidese desviala a outra táboa. Unha ruta da táboa principal pode non consultarse nunca se unha regra anterior elixe outra táboa, e a coincidencia do prefixo máis longo só se aplica dentro da táboa que elixe unha regra.

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 ruta elixida xunto co enderezo de orixe que o núcleo usaría. Compare esa saída co selector co que coincide a política IPsec. Cando a ruta apunta á interface de OpenVPN e a política segue coincidindo co mesmo par, reproduciu o conflito sen adiviñar.

Manteña os volcados libres de enderezos non relacionados antes de que cheguen a un tícket. Unha táboa de enrutamento dun host de produción leva topoloxía interna, e só as liñas que responden a pregunta merecen pegarse.

Lea a política que tamén se aplica

A listaxe de políticas mostra dirección, selectores e o modelo que decide que ocorre cun paquete coincidente. Lea primeiro a dirección de saída e despois o lado de entrada para o tráfico de retorno, porque unha excepción unidireccional produce unha conexión que comeza e nunca se completa.

ip -s xfrm policy
swanctl --list-sas

Compare os selectores da listaxe cos prefixos que negociou a conexión. Desactivar a instalación de rutas de strongSwan non elimina esas políticas, e cambiar unha métrica non altera que par de orixe e destino protexe unha política. Esas dúas falsas solucións convén descartalas cedo porque son as primeiras que a xente proba.

Se a listaxe non contén ningunha política para o prefixo que esperaba, o problema está noutro sitio e a táboa de enrutamento probablemente di a verdade. Se contén unha política máis ampla que cobre o prefixo, atopou a captura.

Tres opcións cando ambos os camiños son lexítimos

Estreitar o selector IPsec é a opción máis limpa cando o prefixo amplo era unha comodidade e non un requisito. Reducir o selector de tráfico remoto ás subredes que de verdade pertencen detrás de IPsec elimina o conflito para todos os hosts á vez, e custa unha renegociación de chaves en vez dun compoñente novo.

Unha excepción de paso directo é a opción cirúrxica cando o selector amplo debe quedar. strongSwan admite unha conexión separada cuxo fillo usa o modo pass, que lle di ao núcleo que o tráfico coincidente non debe procesarse por IPsec. O enderezo remoto de loopback evita que esa conexión se elixa para pares entrantes, e os selectores deben describir o par autorizado real e non todo.

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 configuración de strongSwan documentan este tipo de política e a convención de par de loopback. A terceira opción é un deseño baseado en enrutamento con interfaces XFRM, que liga a política ao tráfico enrutado por unha interface con nome en lugar dun selector global. É unha migración e non un axuste, e o tráfico debe seguir satisfacendo os selectores negociados.

Demostre a excepción sen debilitar o resto

Despois de cargar o cambio, probe a excepción e un destino corrente que deba seguir protexido. Comprobe ambos os sentidos, despois baixe o túnel de OpenVPN e confirme que ocorre co tráfico exceptuado. Unha excepción que envía ese prefixo en claro en silencio cando o túnel está caído é unha decisión de política que convén tomar a propósito, non descubrir durante un incidente.

Anote que prefixo usa que camiño e por que. Se non, o seguinte enxeñeiro que vexa un selector amplo reabrirá a mesma investigación, e a resposta estará nunha mensaxe de commit que ninguén le.