Per què una ruta d’OpenVPN perd contra una política XFRM de strongSwan

Els paquets poden seguir una ruta d’OpenVPN i tot i així ser capturats per una política IPsec, i aquesta combinació sembla un error d’encaminament des de tots els angles excepte el correcte. Linux resol una ruta i després consulta una base de dades de polítiques de seguretat separada, de manera que una ruta de destinació més específica no desplaça una política XFRM coincident. El símptoma visible és trànsit que surt de l’amfitrió i mai no arriba, mentre tots dos túnels es declaren sans. Tres opcions ho resolen, i quina trieu depèn de quin dels dos camins ha de portar aquest prefix.

Dues decisions, no una

La selecció de ruta respon una pregunta estreta: quin salt següent i quina adreça d’origen han de portar aquest paquet. La base de dades de polítiques de seguretat respon una altra: aquest paquet requereix protecció IPsec i sota quins selectors. Totes dues s’executen per al mateix paquet, i satisfer la primera no diu res sobre la segona. Per això canviar una mètrica o afegir una ruta estàtica pot deixar el símptoma intacte.

Un selector IPsec ampli és la causa habitual. Una política que protegeix 172.16.0.0/12 també cobreix 172.20.8.0/24, on un administrador pot voler arribar pel túnel d’OpenVPN. La intenció només existeix a la taula d’encaminament, i la base de dades de polítiques no l’ha coneguda mai.

Tracteu-ho com un conflicte entre dos camins de protecció configurats i no com una competició entre dues mètriques. La correcció pertoca al component que es va configurar amb l’abast equivocat.

Llegiu la ruta que el nucli tria realment

Comenceu per la consulta que fa el nucli, incloent-hi l’adreça d’origen i qualsevol regla de política que la pugui desviar a una altra taula. Una ruta de la taula principal pot no consultar-se mai si una regla anterior tria una taula diferent, i la coincidència del prefix més llarg només s’aplica dins de la taula que tria una regla.

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

L’última ordre és la que importa, perquè imprimeix la ruta triada juntament amb l’adreça d’origen que el nucli faria servir. Compareu aquesta sortida amb el selector amb què coincideix la política IPsec. Quan la ruta apunta a la interfície d’OpenVPN i la política encara coincideix amb el mateix parell, heu reproduït el conflicte sense endevinar.

Manteniu els bolcats lliures d’adreces no relacionades abans que arribin a un tiquet. Una taula d’encaminament d’un amfitrió de producció porta topologia interna, i només les línies que responen la pregunta val la pena enganxar.

Llegiu la política que també s’aplica

El llistat de polítiques mostra direcció, selectors i la plantilla que decideix què passa amb un paquet coincident. Llegiu primer la direcció de sortida i després el costat d’entrada per al trànsit de retorn, perquè una excepció unidireccional produeix una connexió que comença i mai no es completa.

ip -s xfrm policy
swanctl --list-sas

Compareu els selectors del llistat amb els prefixos que la connexió ha negociat. Desactivar la instal·lació de rutes de strongSwan no elimina aquestes polítiques, i canviar una mètrica no altera quin parell d’origen i destinació protegeix una política. Val la pena descartar aviat aquestes dues falses solucions perquè són les primeres que la gent prova.

Si el llistat no conté cap política per al prefix que esperàveu, el problema és en un altre lloc i la taula d’encaminament probablement diu la veritat. Si conté una política més àmplia que cobreix el prefix, heu trobat la captura.

Tres opcions quan tots dos camins són legítims

Estrenyer el selector IPsec és l’opció més neta quan el prefix ampli era una comoditat i no un requisit. Reduir el selector de trànsit remot a les subxarxes que realment pertanyen darrere d’IPsec elimina el conflicte per a cada amfitrió alhora, i costa una renegociació de claus en lloc d’un component nou.

Una excepció de pas directe és l’opció quirúrgica quan el selector ampli ha de quedar-se. strongSwan admet una connexió separada el fill de la qual fa servir el mode pass, que diu al nucli que el trànsit coincident no s’ha de processar per IPsec. L’adreça remota de loopback evita que aquesta connexió es triï per a parells entrants, i els selectors han de descriure el parell autoritzat real i no tot.

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
            }
        }
    }
}

Els exemples de configuració de strongSwan documenten aquest tipus de política i la convenció de parell loopback. La tercera opció és un disseny basat en encaminament amb interfícies XFRM, que lliga la política al trànsit encaminat per una interfície amb nom en lloc d’un selector global. És una migració i no un retoc, i el trànsit encara ha de satisfer els selectors negociats.

Demostreu l’excepció sense debilitar la resta

Després de carregar el canvi, proveu l’excepció i una destinació ordinària que ha de romandre protegida. Comproveu tots dos sentits, després atureu el túnel d’OpenVPN i confirmeu què passa amb el trànsit exceptuat. Una excepció que envia en silenci aquest prefix en clar quan el túnel està caigut és una decisió de política que hauríeu de prendre a propòsit, no descobrir durant un incident.

Anoteu quin prefix fa servir quin camí i per què. Si no, el proper enginyer que vegi un selector ampli reobrirà la mateixa investigació, i la resposta serà en un missatge de commit que ningú no llegeix.