Selectors de trànsit d’IPsec: què cobreixen i què no

Els selectors de trànsit anomenen el trànsit interior que protegeix un acord d’IPsec, i la parella es negocia en lloc de suposar-se. Dos extrems poden autenticar-se perfectament l’un a l’altre i tot i així discrepar sobre quins paquets pertanyen a dins del túnel. Aquesta discrepància és invisible a l’estat de la connexió, que normalment informa d’un túnel sa. Llegir els selectors des dels dos extrems i després seguir una destinació ho troba més de pressa que qualsevol quantitat d’edició de política.

Llegeix-los des dels dos extrems

Cada extrem descriu el seu costat com a local i l’altre costat com a remot. Per tant, la mateixa parella de prefixos apareix intercanviada a les dues configuracions, i això és correcte i no pas contradictori. Invertir la perspectiva és el primer que cal fer quan un acord que funciona sembla equivocat sobre el paper. Comparar dues fitxers l’una al costat de l’altra sense intercanviar-les produeix una discrepància que no existeix.

Els valors no sempre són subxarxes úniques. Els selectors d’IKEv2 poden portar rangs d’adreces, números de protocol i rangs de ports, i així és com una política protegeix un servei en lloc de tota una xarxa. Un selector més estret que el trànsit previst produeix un túnel que transporta algunes destinacions i n’exclou d’altres en silenci.

Escriu els dos costats en una taula abans de canviar res. L’exercici normalment resol la qüestió sense tocar cap fitxer de configuració.

L’estretament és decisió del respondedor

L’iniciador proposa, i el respondedor pot acceptar només un subconjunt. IKEv2 permet al respondedor estrényer els selectors de trànsit oferts, i el resultat estret és el que realment s’instal·la. Llegir la configuració de l’iniciador descriu, doncs, una oferta, no l’acord.

Per això una subxarxa afegida al client pot produir un túnel que funciona i que tot i així rebutja la destinació nova. El servidor va estrényer l’oferta fins al que la seva política permet, mentre el fitxer del client encara llista el rang més ampli. Només l’estat negociat mostra la veritat: a Linux, ip xfrm policy i la llista de child SA a la documentació d’IKEv2 de strongSwan informen del que es va instal·lar i no del que es va demanar. Quan els dos discrepen, la política del respondedor és la que cal canviar.

Una proposta rebutjada és un símptoma diferent d’una d’estreta. El rebuig apareix al registre de negociació i no deixa cap associació child.

Segueix una destinació d’un cap a l’altre

Tria una destinació real més l’adreça d’origen que el client faria servir per a ella, i després segueix aquesta parella per tres decisions independents. La ruta tria un camí, el selector decideix si aquest camí està protegit, i el tallafoc decideix si el paquet està permès. Cadascun pot fallar pel seu compte, i un selector ampli no repara cap dels altres.

ip route get 10.20.30.41
ip xfrm policy list
swanctl --list-sas

La consulta de ruta anomena la interfície i l’adreça d’origen que portarien el paquet. La llista de polítiques mostra si existeix una política de túnel corresponent per a aquesta parella, incloent-hi la direcció i el nivell. La llista d’SA mostra els selectors child negociats juntament amb comptadors, així que una associació child amb zero paquets després d’haver intentat trànsit és la signatura de selectors que exclouen el que s’envia. Tres ordres, tres respostes diferents, i només una explica una caiguda silenciosa.

Si els comptadors child es mouen mentre l’aplicació encara falla, el problema és més enllà del túnel. Això mou la investigació cap al receptor o el tallafoc de l’host remot i no cap als selectors.

Mantingues els dos objectius separats

Protegir una subxarxa d’oficina i enviar tota la navegació per una sortida remota són requisits diferents amb selectors diferents. Un perfil fet per a un rarament serveix per a l’altre, i barrejar-los produeix o una fuita o una divisió trencada. Ampliar el rang protegit vol dir canviar els dos extrems i la seva política de reenviament, perquè un canvi unilateral es converteix en una proposta rebutjada. Aquesta és la manera més comuna que un túnel que funcionava deixi de funcionar després d’una edició petita.

Els selectors descriuen la cobertura criptogràfica, les rutes trien camins, i les aplicacions imposen els seus propis permisos. Un túnel que ho cobreix tot encara no pot arribar a un servei lligat a loopback, i una ruta cap al túnel encara necessita un selector que inclogui la destinació. Comprova els tres contra la mateixa petició de prova, i la discrepància es nomenarà sola.