vpn.persistent segueix intentant-ho, però no et manté connectat

NetworkManager exposa una propietat, vpn.persistent, i la gent li demana que respongui quatre qüestions diferents alhora. La seva documentació d'origen és acurada: la persistència s'aplica quan el servei VPN l'admet i el perfil l'activa, i llavors es demana a la connexió que sobrevisqui als canvis d'enllaç i a les interrupcions fins a una desconnexió explícita. La mateixa documentació també mostra que la propietat té el valor false per defecte, cosa que no és el que assumeixen la majoria dels plans de recuperació. Llegeix-ho com una petició d'intent, no com una promesa de resultat.

Què compromet realment la configuració

Un valor desat en un perfil és una instrucció per al gestor, i el gestor ha de lliurar aquesta instrucció a un connector VPN que sàpiga què fer-ne. Si el connector instal·lat ignora la propietat, el perfil s'activa igualment i el registre queda en silenci, que és el pitjor dels dos móns per a qui depuri el problema més endavant. Res dins d'un perfil no pot obligar un connector a implementar un comportament que no té, així que l'únic resultat visible és una absència.

Per això la condició de la documentació importa més que l'interruptor. Comprova quin connector i quina versió tens realment, i escriu la versió al costat de la descripció de la connexió perquè la propera persona no hagi de redescobrir-ho. Una política de recuperació basada en un indicador no implementat falla exactament una vegada en producció i sempre en el moment més inconvenient.

Tractar la propietat com un intent també fixa l'expectativa correcta per a les proves. No comproves si l'indicador està definit; comproves si va passar alguna cosa quan va caure l'enllaç. Són experiments diferents, i només un d'ells val una tarda.

Quatre qüestions que s'ajunten en una

L'activació pregunta què posa el VPN en marxa en primer lloc. Un perfil de NetworkManager es pot lligar a una connexió base, un servei OpenVPN gestionat per separat té la seva pròpia arrencada, i afegir un tercer llançador a aquesta disposició et dona dos propietaris amb idees diferents sobre qui mana. Decideix quin component és propietari de l'arrencada abans d'afegir un altre disparador.

La recuperació pregunta què passa quan l'enllaç canvia o desapareix, que és la qüestió estreta que aborda vpn.persistent. La vivacitat pregunta si el client pot saber que l'extrem llunyà ha deixat de respondre, i el comportament de keepalive o de reinici d'OpenVPN respon a això en el seu lloc; els dos mecanismes sovint es descriuen amb la mateixa paraula i s'implementen en llocs diferents. Prova'ls per separat, amb eines diferents, o atribuiràs un comportament a l'altre.

La intenció pregunta si es vol la reconnexió de bon principi, i és la qüestió que l'enquesta d'estat no pot respondre. Una aturada deliberada i una interrupció produeixen el mateix estat inactiu, així que qualsevol cosa que reconecti per absència està endevinant una decisió humana. Endevinar està bé fins al moment que passa per sobre d'algú.

Una llista de verificació que les manté separades

Executa els esdeveniments en ordre en lloc de llegir la configuració i raonar sobre ella, i registra què mostra cadascun amb una marca de temps.

Primer, activa la connexió base prevista i confirma que el VPN s'ha aixecat pel disparador que esperaves i no per un mecanisme que havies oblidat que estava instal·lat. Segon, durant una interrupció aprovada, compara els esdeveniments VPN del gestor, l'estat de recuperació del client propietari i una petició nova a un recurs privat. Tercer, desconecta deliberadament, espera i confirma que res no reinicia el perfil a la teva esquena.

El tercer pas és el que la gent omet, i és el que troba el defecte real més sovint. Un vigilant que consulta si hi ha un perfil actiu i es reconnecta quan no n'hi ha desfarà alegrement una desconnexió intencionada de l'usuari. Des del seient de l'usuari això no és resiliència; és una màquina que no obeeix. Pregunta'ls abans d'afegir-ne un.

Escriu els resultats al mateix document que la descripció de la connexió. Una política de recuperació és tan bona com l'última vegada que algú la va veure fallar expressament. Les marques de temps fan visible la diferència a qui llegeixi les notes després.

L'autenticació forma part de la recuperació

Reconnectar-se no és un acte purament de xarxa. Si el flux aprovat necessita un repte nou, un codi d'un sol ús o un secret al qual el context d'activació no pot arribar, cap configuració de persistència no el pot produir del no-res.

Això explica un patró familiar: la connexió es recupera en una màquina amb un clauer desbloquejat i falla a la mateixa màquina després d'un reinici. La capa de xarxa va fer exactament el que se li va demanar i la capa de credencials no tenia res a oferir.

Arregla el flux de credencials en lloc d'escurçar l'interval de reintent. Reintents més ràpids contra una petició que ningú pot respondre generen soroll al registre i una falsa impressió que s'està intentant alguna cosa.

La persistència no és un kill switch

La propietat intenta mantenir o restaurar la relació VPN. No decideix què poden fer les aplicacions mentre el VPN està caigut, i no bloqueja res per si mateixa.

Si el requisit és que no surti cap trànsit fora del túnel, això és una política separada amb el seu propi mecanisme, les seves pròpies proves i les seves pròpies formes de fallada. Suposar que la persistència ho cobreix converteix una decisió de seguretat en un accident.

Registra les dues meitats a les notes de recuperació: què va intentar el VPN i quin trànsit d'aplicacions es va permetre mentre l'intent estava en curs.