Executouse demasiado pronto o script up de OpenVPN, ou nunca estivo listo?

O script up execútase, sae con cero e a tarefa que contén non logra alcanzar un servizo privado que dous segundos despois funciona perfectamente desde un terminal. O instinto é o tempo, e a reparación habitual é unha espera, que oculta a carreira sen entendela. A lectura máis útil é que “up” nomea un gancho, non unha garantía de preparación. Disparase cando se configura o dispositivo de túnel, o que ocorre antes das rutas, do DNS e, sen dúbida, antes de calquera aplicación detrás do túnel.

A proba no intérprete de ordes tivo éxito porque se executou despois de que todo se asentase. O gancho executouse nun momento concreto.

Onde se sitúa up na orde de arranque

OpenVPN configura o dispositivo de túnel e despois executa o gancho up. A instalación de rutas é unha etapa posterior e ten o seu propio gancho, por iso unha tarefa dependente da ruta colocada en up pode ver un dispositivo sen unha ruta útil. Pon o traballo de rutas en route-up e o problema de tempo adoita desaparecer.

O manual documenta esta orde e o contorno que recibe cada gancho. Esa orde é toda a explicación do clásico informe “funciona desde o meu intérprete de ordes”, e tamén é a razón pola que o mesmo script pode pasar nunha máquina e fallar noutra cunha etapa de rutas máis lenta. Ningún dos dous resultados di nada sobre a calidade do script.

A preparación do DNS e das aplicacións chega aínda máis tarde. Nin sequera as rutas instaladas son proba de que o extremo remoto estea escoitando, de que un nome se resolva ou de que exista unha sesión de escritorio para unha tarefa do ámbito dun usuario.

Que herda realmente o gancho

Un gancho execútase baixo a conta e o contorno do proceso OpenVPN, o que non é o mesmo que o seu intérprete de ordes interactivo. Pode carecer dun bus de sesión de usuario, dun contorno de escritorio ou dunha credencial que só se desbloquea ao iniciar sesión. Anote cales desas cousas necesita realmente a tarefa.

Iso importa para tarefas que parecen de rede pero dependen do contexto de usuario: montar un recurso compartido cunha credencial de usuario, configurar un proxy por usuario ou configurar unha impresora. Un gancho de túnel privilexiado é o lugar equivocado para elas, e ningunha cantidade de espera arranxa unha sesión ausente.

Cando unha tarefa falla nun gancho, rexistre a conta, o contorno e a primeira operación que fallou. Iso separa o tempo prematuro dun problema de permisos ou de contexto, e os dous teñen reparacións completamente distintas. Adiviñar entre eles é como unha reparación de cinco minutos se converte nunha tarde enteira.

Por que engadir unha espera non é unha comprobación de preparación

Unha espera retrasa o script e despraza a xanela da carreira. Nun día rápido a tarefa ten éxito; nun día lento volve fallar, e o fallo vólvese máis difícil de reproducir porque o retraso parece funcionar. Un retraso que só funciona con carga lixeira é unha coincidencia, non unha reparación.

Se a dependencia é unha ruta, use o gancho que corresponde á instalación de rutas. Se a dependencia é un servizo detrás do túnel, use unha comprobación limitada que espere esa condición concreta e falle con claridade cando nunca chega.

Manteña o fallo explícito. Un gancho que sae con cero mentres o seu traballo real fallou é peor que un gancho que falla, porque o xestor de servizos rexistra un éxito e ninguén volve mirar. Unha liña de rexistro do propio script é a forma máis barata de mantelo honesto.

A limpeza e a reconexión merecen o mesmo coidado

Un script que cambia estado compartido necesita unha ruta de desfacer correspondente. As rutas, as entradas do resolutor e as marcas de devasa que engade un gancho deben ser idempotentes e reversibles, ou unha reconexión apilará unha segunda copia sobre a primeira.

As reconexións tamén poden executar ganchos máis a miúdo que un inicio completo do servizo. Unha interface persistente que restablece unha sesión pode desencadear de novo o ciclo up e route-up, así que un script que supón unha execución por arranque acabará comportándose mal. Conte as execucións no rexistro durante un día de oscilacións para ver con que frecuencia se executa realmente. Despois faga que o script sexa seguro para executarse tantas veces.

Probe o ciclo de vida que fallou, non un comando posterior. Reproduza o arranque ou a reconexión, observe como se executa o gancho e confirme que a tarefa tivo éxito no momento en que realmente se executa. Un éxito desde un intérprete de ordes interactivo despois é evidencia sobre a dependencia, non proba de que a ruta de arranque funcione.

Nomee o evento do que depende cada tarefa e despois vincúlea a ese evento. Todo o demais é un retraso que finxe ser unha comprobación.