Per què una VPN pot semblar connectada quan no funciona res

El vostre client informa de connectat mentre la interfície està aixecada i el navegador esgota el temps, i cap d'aquestes tres afirmacions no és falsa. Connectat descriu una capa que no té res a veure amb la pàgina que heu demanat. Decidir quina capa informa requereix una sol·licitud nova i una ullada al comptador que demostraria que el trànsit s'ha mogut. Un reinici llença aquesta evidència i reconstrueix les condicions que intentàveu observar.

Tres coses diferents anomenades connectat

A baix de tot, connectat pot significar que un procés de client s'executa i manté un sòcol cap a un igual. Per sobre, pot significar que existeix una interfície amb una adreça, que un dispositiu persistent o una rutina de recuperació poden crear sense cap sessió viva al darrere. Al nivell de control, pot significar que s'ha negociat una associació, cosa que no diu res sobre si un sol paquet hi ha passat per sota. Cadascuna sobreviu a fallades a què les altres no sobreviuen, i un client normalment mostra la més forta que pot reclamar.

Una icona verda i un túnel mort són, per tant, compatibles i no contradictoris; informen d'objectes diferents. Aquesta és tota la raó per la qual aquesta fallada es diagnostica malament una i una altra vegada com un error del client.

Envieu una sol·licitud inofensiva a una destinació que realment necessiteu abans de tocar el dimoni, i manteniu el bloc de trànsit directe requerit al seu lloc mentre treballeu. Un reinici esborra l'ordre dels esdeveniments i després els recrea prou a prop per amagar la causa, i per això el mateix tiquet torna una setmana després sense res de nou. Una sol·licitud, una lectura del comptador i el desencadenant que va produir la fallada són l'evidència mínima.

Quin comptador demostra que els paquets s'han mogut

A IPsec, l'associació IKE i l'associació CHILD són objectes separats, i només el child porta els comptadors que responen aquesta pregunta. Llista el child, observa si els paquets augmenten en les dues direccions i compara-ho amb el que l'aplicació intenta fer. Una associació instal·lada a zero és una troballa diferent d'una que augmenta mentre l'aplicació encara falla; la primera vol dir que el trànsit no se selecciona, la segona que es mou i que la fallada és més enllà. Llegiu els comptadors dues vegades, amb uns segons de diferència, perquè una sola mostra no pot mostrar una tendència.

swanctl --list-sas
ip xfrm state list
ip -s link show dev tun0

Els comptadors a zero apunten a la selecció: l'encaminament, la política, un espai de noms del qual va sortir el paquet o una interfície a la qual el client mai no es va lligar. Els comptadors creixents apunten lluny del túnel, així que continueu amb el reenviament a l'extrem llunyà, la resolució de noms, el camí de tornada i el servei de destinació, en aquest ordre. Un protocol sense objecte child separat exposa la mateixa evidència en els seus propis termes, així que feu servir el que informa sobre l'estat de l'igual i el recompte de paquets en lloc de manllevar el vocabulari d'IPsec. La forma de la lectura importa més que l'eina que l'ha produïda.

On se situa la fallada després que els comptadors es moguin

Una passarel·la que respon a la seva pròpia adreça de gestió demostra que la passarel·la funciona, no que res al darrere serveixi la vostra sol·licitud, així que proveu el costat llunyà i no la caixa del mig. La resolució de noms amaga les fallades millor que res, perquè un resolutor al qual no es pot arribar pel túnel esgota el temps exactament com una connexió morta. Dues consultes separen aquests casos, i totes dues són barates. Pregunteu primer al resolutor que el túnel empeny, i després pregunteu a un resolutor públic pel mateix nom.

dig +short host.example
dig +short @10.20.0.1 host.example
ping -c 2 10.20.0.25

Un nom que es resol pel resolutor públic però no pel del túnel vol dir que el camí DNS està trencat, mentre que un nom que es resol per tots dos i encara esgota el temps al navegador apunta al camí de tornada o al servei. Si el ping per adreça té èxit i l'aplicació encara refusa, la xarxa va lliurar la sol·licitud i el servei la va rebutjar, cosa que és una etapa molt posterior.

Registreu el desencadenant i després canvieu una cosa

Registreu què va precedir la fallada: un període d'inactivitat, un canvi de xarxa, una renovació de clau, un portàtil reprès o un sistema restaurat. Aquests produeixen mecanismes diferents, i normalment només el sistema restaurat es repara sol, que és exactament el cas que no us ensenya res. Un reinici elimina l'ordre dels esdeveniments i després recrea condicions prou properes per amagar la causa. Escriviu el desencadenant mentre encara és reproduïble.

Aleshores feu una correcció recolzada i repetiu la sol·licitud original juntament amb el desencadenant que va produir la fallada. La inactivitat és el desencadenant més fàcil de reproduir, així que és la confirmació més ràpida que la correcció ha abordat el mecanisme i no el símptoma.

El que voleu informar és la prova que el trànsit que volíeu enviar ha arribat al servei al qual volíeu arribar. Una icona que es torna verda, una pàgina en memòria cau que es carrega i un comptador que es mou demostren tots menys que una sol·licitud completada contra la destinació prevista. Manteniu junts la sol·licitud, la lectura del comptador i el desencadenant, perquè la propera persona pugui distingir una correcció d'una coincidència.