El programa up de l’OpenVPN es va executar massa aviat, o mai no va estar a punt?

El script up s’executa, surt amb zero i la tasca que conté no aconsegueix arribar a un servei privat que dues segons després funciona perfectament des d’un terminal. L’instint és el temps, i la reparació habitual és una espera, que amaga la cursa sense entendre-la. La lectura més útil és que “up” és el nom d’un ganxo, no una garantia de preparació. S’activa quan es configura el dispositiu de túnel, cosa que passa abans de les rutes, del DNS i, sens dubte, abans de qualsevol aplicació darrere del túnel.

La prova de l’intèrpret d’ordres va reeixir perquè es va executar després que tot s’estabilitzés. El ganxo es va executar en un moment concret.

On se situa up en l’ordre d’arrencada

OpenVPN configura el dispositiu de túnel i després executa el ganxo up. La instal·lació de rutes és una etapa posterior i té el seu propi ganxo, i per això una tasca dependent de la ruta col·locada a up pot veure un dispositiu sense cap camí útil. Posa la feina de rutes a route-up i el problema de temps normalment desapareix.

El manual documenta aquest ordre i l’entorn que rep cada ganxo. Aquest ordre és tota l’explicació de l’informe clàssic “funciona des del meu intèrpret d’ordres”, i també és la raó per la qual el mateix script pot passar en una màquina i fallar en una altra amb una etapa de rutes més lenta. Cap dels dos resultats no diu res sobre la qualitat del script.

La preparació del DNS i de les aplicacions arriba encara més tard. Fins i tot les rutes instal·lades no són prova que l’extrem remot estigui escoltant, que un nom es resolgui o que existeixi una sessió d’escriptori per a una tasca d’abast d’usuari.

Què hereta realment el ganxo

Un ganxo s’executa sota el compte i l’entorn del procés OpenVPN, cosa que no és el mateix que el vostre intèrpret d’ordres interactiu. Pot mancar-li el bus de sessió de l’usuari, un entorn d’escriptori o una credencial que només es desbloqueja en iniciar sessió. Anoteu quina d’aquestes coses necessita realment la tasca.

Això importa per a tasques que semblen de xarxa però depenen del context d’usuari: muntar un recurs compartit amb una credencial d’usuari, configurar un proxy per usuari o configurar una impressora. Un ganxo de túnel amb privilegis és el lloc equivocat per a elles, i cap quantitat d’espera no arregla una sessió absent.

Quan una tasca falla en un ganxo, anoteu el compte, l’entorn i la primera operació que ha fallat. Això separa el temps prematur d’un problema de permisos o de context, i els dos tenen reparacions completament diferents. Endevinar entre ells és com una reparació de cinc minuts es converteix en una tarda sencera.

Per què afegir una espera no és una comprovació de preparació

Una espera retarda el script i desplaça la finestra de la cursa. En un dia ràpid la tasca reïx; en un dia lent torna a fallar, i la fallada es fa més difícil de reproduir perquè el retard sembla funcionar. Un retard que només funciona amb càrrega lleugera és una coincidència, no una reparació.

Si la dependència és una ruta, feu servir el ganxo que correspon a la instal·lació de rutes. Si la dependència és un servei darrere del túnel, feu servir una comprovació limitada que esperi aquesta condició concreta i falli clarament quan no arribi mai.

Manteniu la fallada explícita. Un ganxo que surt amb zero mentre la seva feina real ha fallat és pitjor que un ganxo que falla, perquè el gestor de serveis registra un èxit i ningú torna a mirar. Una línia de registre del mateix script és la manera més barata de mantenir-ho honest.

La neteja i la reconnexió mereixen la mateixa cura

Un script que canvia estat compartit necessita un camí de desfer corresponent. Les rutes, les entrades del resolutor i les marques de tallafocs afegides per un ganxo han de ser idempotents i reversibles, o una reconnexió apilarà una segona còpia sobre la primera.

Les reconnexions també poden executar ganxos més sovint que un inici complet del servei. Una interfície persistent que restableix una sessió pot tornar a desencadenar el cicle up i route-up, així que un script que assumeix una execució per arrencada eventualment es comportarà malament. Compteu les execucions al registre durant un dia d’oscil·lacions per veure quantes vegades s’executa realment. Després feu que el script sigui segur per executar-se tantes vegades.

Proveu el cicle de vida que va fallar, no una ordre posterior. Reproduïu l’arrencada o la reconnexió, observeu com s’executa el ganxo i confirmeu que la tasca va reeixir en el moment en què realment s’executa. Un èxit des d’un intèrpret d’ordres interactiu després és evidència sobre la dependència, no prova que el camí d’arrencada funcioni.

Anomeneu l’esdeveniment del qual depèn cada tasca i després lligueu-la a aquest esdeveniment. Tota la resta és un retard que fingeix ser una comprovació.