Inspeccionar una interfície VPN de Linux amb ip link, capa per capa

La icona del client diu connectat, la interfície existeix, i l’aplicació continua sense arribar enlloc. Aquesta combinació és habitual, perquè una interfície virtual pot romandre present mentre falten el seu parell remot, les seves adreces o les seves rutes. ip link és la primera eina correcta, i també la més fàcil de sobreinterpretar. Els senyals i els comptadors descriuen una capa, i les capes que hi ha a sobre fallen de manera independent. També és l’eina que la gent cita quan vol demostrar que el túnel està aixecat, precisament l’afirmació que no pot sostenir tota sola.

Llegeix la interfície abans de llegir la icona

Comença amb ip -details link show dev tun0 tal com es documenta al manual d’ip-link, substituint el nom convencional per la interfície que el teu client posseeix realment. Els senyals, el tipus, l’MTU i la identitat de la interfície són observacions útils. La redacció de l’estat d’una interfície virtual no ha de comportar-se com la indicació de portadora d’un cable físic, així que tracta UP com una afirmació sobre la interfície i no sobre el túnel.

Aquesta distinció explica el cas més desconcertant: una interfície que persisteix mentre el costat remot es reconnecta o és inabastable.

Els paràmetres de persistència poden mantenir l’enllaç precisament perquè la reconnexió no el reconstrueixi, cosa que significa que la presència no és salut.

Afegeix comptadors i una petició que els hauria d’utilitzar

Utilitza la vista d’estadístiques admesa ip -s link show dev tun0, i anota els comptadors de paquets i bytes en tots dos sentits. Després genera una petició innòcua que hauria de travessar la interfície i compara el sentit rellevant. Una petició que va agafar la ruta directa d’una altra aplicació no mourà aquests comptadors, i aquest és el punt de l’exercici.

Si el comptador de transmissió es mou i el de recepció no, el paquet va sortir i no va tornar res. Aquest és un problema diferent del d’una interfície que mai no ha portat res. Si tots dos comptadors es mouen i l’aplicació continua fallant, la fallada és per sobre de la interfície, cosa que és un progrés i no un carreró sense sortida.

Pren la lectura dues vegades, una abans i una després, en lloc de confiar en una única instantània.

Les adreces i les rutes són passos separats

Un enllaç pot existir sense el prefix, la configuració del resolutor o la ruta que necessita l’aplicació. Comprova l’adreça amb ip address show dev tun0, després comprova quina ruta triaria la destinació amb ip route get per a l’objectiu real. Aquestes tres observacions responen tres preguntes diferents, i només l’última tracta de l’enviament.

En IPsec també poden importar la política de seguretat i l’estat de l’associació, i no tots els dissenys IPsec apareixen com una interfície tun simple. Buscar un dispositiu tun que mai no havia d’existir és una manera ràpida d’arribar a una conclusió equivocada.

Anota el nom exacte, l’espai de noms i l’hora amb qualsevol sortida que conservis, perquè un nom d’aspecte idèntic en un altre contenidor o en una sessió restaurada representa un context completament diferent.

No esborris allò que no has identificat

Una interfície desconeguda no és automàticament obsoleta. Identifica’n el propietari abans de treure res, i quan l’eliminació sigui realment volguda, fes servir el desmuntatge documentat del client o la configuració gestionada. Esborrar un túnel viu per veure què passa és una prova que respon una pregunta que ningú no ha fet.

Si la interfície pertany a un entorn de contenidors o a un espai de noms de xarxa que no has creat, el propietari és a una ordre de distància i val la pena trobar-lo primer.

Aquesta precaució també s’aplica a ip link set down, que sembla reversible i sovint no ho és.

Què t’ha de deixar la inspecció

Una bona inspecció acaba amb quatre fets: el nom i l’espai de noms de la interfície, els seus senyals i l’MTU, el delta de comptadors d’una petició real, i la ruta i l’adreça que l’aplicació necessita de veritat. Amb això escrit, el pas següent és obvi i pertany a una capa concreta. Sense això, cada canvi posterior és una suposició amb un pla de reversió.

Compara aquests quatre fets amb els mateixos quatre d’una sessió que funciona. Si el nom i l’espai de noms coincideixen però el delta de comptadors és zero, la petició no va arribar mai al túnel. Si el delta és saludable i la ruta apunta a un altre lloc, el túnel està bé i l’encaminament no. Aquesta comparació és el que converteix una pila de sortida en una decisió.

Guarda la sortida amb el tiquet, perquè una comparació posterior només és útil si veus què ha canviat.

Després tanca el cercle tornant a provar l’aplicació, perquè la interfície mai no va ser el que importava a l’usuari.