La VPN del router sembla correcta després d'un tall? Comproveu aquestes quatre capes

Un router que s'encén després d'un tall ha restaurat la seva configuració, no la seva connectivitat. Després d'un tall de llum, un router pot restaurar el perfil de VPN desat abans que les dependències que aquest perfil necessita estiguin a punt: el mòdem anterior pot estar encara entrenant-se, el rellotge pot ser incorrecte i l'autenticació pot no haver acabat. El llum del panell i la configuració desada descriuen la intenció, no un túnel que funcioni. Comproveu les quatre capes següents en ordre en lloc de substituir el perfil, que és el que la gent fa segon i lamenta primer.

Tot això assumeix que sou al lloc o teniu una via d'accés que no depengui del túnel que proveu. Si no la teniu, organitzeu-la abans del proper tall.

Primera capa: el WAN ha tornat realment

Comenceu pel mòdem, no pel panell del router. Un router que acaba d'arrencar abans que el seu mòdem s'hagi entrenat mostra una interfície sana sense res al darrere, i el túnel no té cap parell a qui arribar. Confirmeu que el mòdem realment reenvia, i després confirmeu que el router ha agafat la configuració del WAN que espereu. Comproveu també si l'adreça del WAN ha canviat: una adreça dinàmica que torna diferent pot invalidar una regla basada en adreça o una llista d'autoritzacions remota, i des de dins de la xarxa això sembla una fallada de la VPN.

Algunes xarxes d'accés també requereixen un pas d'admissió nou després d'un tall. Llegiu el registre del client per a la primera etapa de fallada en lloc d'endevinar: el primer error anomena la capa, i tot el que ve després és conseqüència. Anoteu l'adreça i el resultat de l'admissió al tiquet, perquè tots dos decideixen si el mateix perfil funcionarà demà. Una adreça canviada és una solució de cinc minuts i un misteri de dues hores.

Segona capa: comproveu el rellotge abans del certificat

Un rellotge incorrecte interfereix en la validesa del certificat i en tot el que depèn del temps, i un dispositiu incrustat que arrenca sense una font de temps operativa pot quedar-se amb una data antiga una estona. Llavors la validació del certificat falla per un motiu que no té res a veure amb la credencial. Un error de validesa amb dates desviades anys assenyala el rellotge; el mateix error amb dates actuals assenyala el certificat.

date -u
chronyc tracking

Utilitzeu el procés de recuperació de temps suportat i confirmeu el rellotge del router abans de tocar el perfil. Desactivar la validació per passar l'error converteix un problema temporal d'ordre en un debilitament permanent, i és l'arranjament dolent més comú en aquest escenari. Si el dispositiu no té rellotge amb bateria, l'ordre d'arrencada importa: necessita accés a la xarxa abans de sincronitzar el temps, i necessita temps abans de validar un túnel. Aquest ordre és el que cal arreglar si la mateixa fallada es repeteix després de cada tall.

Tercera capa: llegiu què diu el túnel

Comproveu l'estat propi del túnel i el resultat de la seva negociació o autenticació, no que la interfície estigui aixecada. Una interfície pot existir sense un parell establert, i un client pot mostrar-se connectat mentre la renovació de claus falla. Separeu els temps d'espera de transport dels rebuigs explícits: un temps d'espera suggereix que el camí o el parell encara no és abastable, mentre que un rebuig significa que l'extrem llunyà ha respost i ha refusat, sovint per credencials, un certificat o una identitat de parell que ja no coincideix. Enviar l'usuari a restablir la contrasenya per un temps d'espera fa perdre la tarda a tothom.

Tingueu a mà l'última configuració bona coneguda per comparar camps en lloc de reconstruir-los. Si un camp ha canviat, aquest canvi és la troballa. Compareu-lo camp per camp amb la restaurada en lloc de llegir només la restaurada. La majoria de sorpreses després d'un tall són un camp que ha tornat silenciosament a un valor per defecte de plantilla.

Quarta capa: proveu des d'un dispositiu posterior

Obriu un recurs permès i inofensiu des d'un client darrere del router, i després confirmeu quina sortida o ruta privada ha fet servir realment el trànsit. Comproveu el DNS i cada família d'adreces que dieu que cubriu, perquè la sonda pròpia del router pot tenir èxit mentre la política del client encara és incorrecta — la sonda sovint fa servir una font diferent, una taula diferent o un camí de resolució diferent.

curl -s https://ifconfig.me
nslookup example.com

Si el túnel està caigut i no només mal configurat, decidiu si els clients afectats s'han de bloquejar o poden fer servir un recurs alternatiu aprovat. Aquesta elecció pertany al pla de commutació per error abans d'un tall, no a un fil de xat durant el tall. Escriviu la sortida i el resolutor observats al tiquet del tall. Dues línies ara estalvien a la persona següent una hora d'endevinar quin camí era actiu durant la finestra.

Què cal arreglar perquè el proper tall sigui més curt

Si la fallada es repeteix, l'arranjament és l'ordre, no la configuració: pugeu el WAN, després el temps, després el túnel, després la política del client. La majoria de routers ho expressen com una dependència o un retard, i un retard curt i deliberat és millor que reescriure el perfil.

Després repetiu la prova normal de reinici un cop l'heu canviat, inclosa la comprovació al costat del client. Una prova de reinici que només mira el panell del router prova la capa menys informativa de les quatre.