Com funciona IPsec basat en rutes amb una interfície XFRM

IPsec basat en rutes lliura a la taula d'encaminament una decisió que abans prenien els selectors de política. A Linux, la peça que ho fa possible és la interfície XFRM: un dispositiu virtual el trànsit del qual s'emparella amb l'estat d'IPsec mitjançant un identificador d'interfície en lloc d'un selector. Crear-ne una requereix una sola ordre i no demostra res sobre si existeix un túnel. El dispositiu és un ganxo entre l'encaminament i la política de seguretat, i tots dos costats d'aquest ganxo s'han de configurar abans que res quedi protegit.

Què és el dispositiu i què no és

Una interfície XFRM és un mànec d'encaminament. Els paquets encaminats cap a ella s'emparellen amb polítiques XFRM que fan referència al mateix identificador d'interfície, i si existeixen una política i un estat, s'encapsulen. Sense això, la interfície existeix, els comptadors no es mouen i el trànsit va a un lloc inútil.

Aquesta és la primera divisió diagnòstica. Una ruta cap al dispositiu és un fet d'encaminament, un estat instal·lat és un fet de seguretat, i un comptador que puja al dispositiu no és ni una cosa ni l'altra. Quan la gent diu que el túnel està aixecat perquè la interfície mostra UP, està descrivint els indicadors d'enllaç d'un dispositiu virtual que no té parell propi. L'indicador només significa que el dispositiu s'ha creat i habilitat, res més.

Una altra frontera: l'identificador d'interfície no és un nom. Dos dispositius amb noms semblants i identificadors diferents no comparteixen estat, i una connexió configurada amb l'identificador equivocat instal·la un estat que cap ruta no farà servir mai.

Construeix-ne una en l'ordre correcte

Comença pel dispositiu exterior i un número que també posaràs a la configuració del dimoni. L'exemple fa servir eth0 com a interfície exterior i 42 com a identificador, adreces que hauries de substituir per les teves.

Aixeca el dispositiu i després confirma l'identificador que el nucli ha registrat abans de tocar la configuració 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]*'

Ara configura la connexió a strongSwan amb el mateix identificador, ja que el dimoni ha d'instal·lar polítiques i estats que hi fan referència. Fixa els selectors de trànsit local i remot al rang que vols encaminar i després encamina aquest rang cap al dispositiu. La configuració del dimoni i la taula d'encaminament han de coincidir tant en l'identificador com en les destinacions, i cap de les dues no forneix l'altra.

Mantén IKE i ESP fora de la ruta del túnel

Una ruta per defecte apuntada cap al dispositiu XFRM captura els paquets encapsulats així com el trànsit que transporten. El resultat és un bucle: la passarel·la intenta enviar el seu propi ESP pel túnel que l'ESP ha de construir.

La solució és una ruta més específica per a l'adreça exterior del parell a través de la interfície física, que guanya la ruta per defecte perquè coincideix en més bits. L'encaminament basat en marques fa la mateixa feina quan diversos túnels comparteixen una taula, i strongSwan documenta tots dos enfocaments per a desplegaments basats en rutes.

Triïs el que triïs, verifica que el paquet exterior surti sense encapsular. Una comprovació ràpida és fer ping a l'adreça exterior del parell un cop el túnel és aixecat; si falla mentre la interfície és aixecada, sospita de captura i no de connectivitat. El mateix raonament s'aplica al port IKE, perquè el trànsit UDP del mateix dimoni no s'ha d'encaminar cap al dispositiu que intenta establir.

Comprova els comptadors en dos llocs abans de culpar el xifratge

Els comptadors d'interfície i els comptadors d'estat mesuren etapes diferents. Els paquets encaminats cap al dispositiu incrementen el dispositiu encara que cap estat coincideixi, mentre que els comptadors d'estat només es mouen per al trànsit que realment s'ha encapsulat.

Llegeix tots dos i després llegeix la visió del dimoni sobre l'associació filla:

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

Comptadors del dispositiu que pugen amb una sortida d'estat buida volen dir que l'encaminament funciona i la política no coincideix, normalment un error d'identificador o de selector. Comptadors d'estat que pugen mentre el costat remot no informa de res volen dir que els paquets surten però no arriben o fallen l'autenticació, cosa que apunta al camí o a la configuració del parell. Una associació filla llistada amb zero trànsit és un problema de selector en un extrem, no un xifrador espatllat.

Decideix qui instal·la les rutes

Dos propietaris per a una taula d'encaminament és la causa habitual de flapping. Si el dimoni instal·la rutes automàticament, el teu gestor de xarxa no ha d'instal·lar també una ruta per defecte pel mateix dispositiu, i una ruta manual afegida per un script d'inici s'eliminarà el proper cop que el dimoni es reconfigure.

Tria un propietari i escriu-ho. Quan el dimoni és propietari de les rutes, mantén l'script d'inici fora de la taula i deixa que la definició de la connexió descrigui els selectors de trànsit. Quan ho és el gestor de xarxa, desactiva la instal·lació automàtica i accepta que el dimoni no repararà una ruta que falta en reconnectar.

Les regles de reenviament i de tallafoc són una decisió separada a sobre, perquè una passarel·la que deixa passar el trànsit d'altres amfitrions necessita totes dues. IPsec basat en rutes fa que aquest trànsit sigui fàcil d'expressar amb eines d'encaminament corrents; no fa que la capa de política sigui opcional.