La política d’IPsec s’està empassant el teu trànsit local: com saber-ho

La impressora de l’escriptori deixa de respondre en el moment en què el túnel puja, i res a la configuració del túnel no esmenta la impressora. El que sol haver passat és que s’ha escrit un rang protegit prou ampli per incloure-la, de manera que la màquina ara intenta xifrar trànsit que havia de quedar-se al segment local. Llegir la política instal·lada explica la captura; estreny-la al lloc correcte manté protegit el trànsit remot. El recorregut des de la petició que falla fins a la política coincident triga uns minuts.

Segueix el flux abans de canviar un selector

Comença per la petició que falla i anota quatre valors: l’adreça d’origen que fa servir la màquina, la destinació exacta, la ruta que tria el nucli i la política que coincideix amb aquest parell.

Aquests quatre fets decideixen si la captura és deliberada o accidental. Una destinació que cau dins del selector remot està protegida per disseny, encara que el disseny fos erroni. Una destinació fora d’ell que tot i així es captura vol dir que alguna altra cosa hi coincideix, i canviar el selector no ajudarà. Els dos casos són habituals, i una sola comanda els distingeix.

Fes-ho abans d’editar res, perquè el cas interessant és la subxarxa local que se solapa amb un rang privat que la connexió protegeix. Prefixos coneguts com 192.168.0.0/16 apareixen en moltes xarxes, i un selector escrit per a un d’ells pot cobrir el teu sense que te n’adonis.

Tres tipus de local que es comporten diferent

Una destinació assignada a aquest amfitrió, una destinació al mateix enllaç i una destinació darrere una altra interfície són tres casos diferents. El nucli tracta cadascun de manera diferent quan decideix si el trànsit necessita protecció.

El trànsit generat per la mateixa passarel·la tampoc no és el mateix que el trànsit reenviat des d’un client. Una política que sembla correcta per al trànsit reenviat pot capturar la pròpia sessió de gestió de la passarel·la, i així és com un administrador perd l’accés mentre arregla el túnel.

L’hàbit útil és anomenar el cas en veu alta: aquest paquet ve de mi, va al meu enllaç o passa per mi? Cada resposta assenyala un lloc diferent on estrènyer. Escriure el cas també evita que la següent persona torni a fer la mateixa feina.

Quan el rang protegit és tot un espai privat, els tres casos hi poden caure alhora, i el símptoma passa a ser una màquina que no arriba enlloc excepte al punt final del túnel.

Llegeix la política instal·lada, no el fitxer

Els fitxers de configuració descriuen la intenció; el nucli té les polítiques que coincideixen de debò. Mostra els dos i tracta una discrepància com la primera troballa.

Aquestes comandes mostren la ruta triada per a la destinació i les polítiques instal·lades en cada direcció:

ip route get 192.168.50.20
ip xfrm policy list
sudo swanctl --list-conns

La ruta et diu quina interfície faria servir el paquet. La llista de polítiques et diu si després s’aplica una plantilla a aquest paquet, i la llista de connexions mostra quins selectors creu el dimoni que ha instal·lat. Si la destinació apareix en un selector remot, has trobat la captura sense endevinar.

Estrény el selector o evita la destinació

Hi ha dues reparacions admeses i responen a preguntes diferents. Estrènyer el selector diu que aquesta connexió només protegeix un rang més petit, cosa que és correcta quan el rang més ampli era un error. Afegir una excepció diu que aquesta destinació concreta no s’ha de protegir mai, cosa que és correcta quan el rang protegit és realment ampli i una destinació és l’excepció.

Tria la primera quan puguis, perquè un selector més petit és més fàcil de raonar i apareix a la definició de la connexió. Tria la segona quan el rang ampli sigui intencionat i l’excepció sigui un sol amfitrió o una subxarxa que puguis anomenar.

Totes dues pertanyen a la configuració que posseeix la connexió. Una regla en temps d’execució afegida a mà desapareix a la següent reconnexió, i la fallada torna en un moment en què ningú no recorda la solució temporal.

Excepcions que sobreviuen a una reinstal·lació

Després del canvi, repeteix la mateixa petició innòcua i mira els mateixos comptadors. La destinació local hauria de respondre, i la destinació remota prevista hauria de seguir mostrant trànsit xifrat.

Aquestes dues comprovacions confirmen que l’excepció va sobreviure i que la protecció no:

ip xfrm policy list | grep -c out
ping -c 3 192.168.50.20

Després desconnecta i reconnecta el túnel a propòsit, i repeteix les dues. Una excepció que funciona abans de la reconnexió i falla després s’ha aplicat a la capa equivocada, i és la manera més habitual que aquest problema torni.