Que OpenVPN arrinque antes ca a rede non é un fallo

Inicia o cliente ao arrincar, a unidade informa de que está activa e o túnel non está. A conclusión natural é que o servizo non arrincou, e a solución natural é volver iniciarlo. Ambas as dúas cousas son abondo a miúdo erróneas como para mereceren unha regra: un cliente en marcha que reintenta parécese exactamente a un roto desde fóra. A diferenza está no que fai o proceso, non no estado da unidade.

Mito: un servizo iniciado significa un túnel que funciona

Unha unidade activa demostra que o proceso se lanzou e non saíu. Non demostra que o perfil se cargase, que o certificado se aceptase nin que o outro extremo respondese. Un cliente empaquetado pode quedar minutos nun bucle de reintentos mentres systemd non informa máis que de éxito. Esa fenda entre estado e comportamento é todo o asunto.

O caso contrario é igual de común. O proceso pode saír tras non poder ler unha chave, e a unidade informa entón dun estado fallido que non di por que. Ambos os estados necesitan o rexistro para distinguirse.

Lea o rexistro da instancia en lugar do estado da unidade. A liña do motivo está no rexistro, non na etiqueta de estado.

Mito: os axustes de reintento cobren todos os fallos

A resolución de nomes e os reintentos de transporte son controis separados con valores predeterminados separados. resolv-retry goberna as buscas repetidas dun nome de host remoto, e o valor documentado segue intentándoo indefinidamente. connect-retry fixa o intervalo entre intentos, mentres que connect-retry-max pode limitar cantas veces se proba cada entrada remota. Comprobe que etapa nomea o rexistro antes de cambiar calquera deles.

Nada diso se aplica a un perfil malformado, unha chave privada ilexible ou unha conta rexeitada. Estes necesitan unha corrección, e un cliente que os reintenta non avanza.

Reintentar para sempre un certificado non aprobado non é motivo para quitar a verificación. É motivo para ler o erro.

Mito: un lanzador abonda, así que engada outro

Unha conexión xa xestionada por NetworkManager ou por unha unidade empaquetada non necesita un segundo lanzador conectado. Dous procesos que compiten polas mesmas rutas producen interfaces duplicadas, rexistros confusos e un túnel que oscila por motivos que ninguén ve. A segunda copia adoita chegar como solución provisional porque a primeira é lenta.

Decida que compoñente posúe o túnel antes de engadir nada. Despois retire o outro lanzador en lugar de desactivalo e esperar.

O propietario tamén determina de onde veñen os reintentos e as credenciais, por iso esta decisión vai antes de calquera axuste. A propiedade vai primeiro exactamente por ese motivo.

Que necesita realmente unha orde

A orde pode esperar unha dirección configurada, e iso é todo o que garante. network-online.target atrasa a activación ata que o xestor considera que a rede está levantada, e a definición de levantada depende do xestor. Non di nada sobre se se resolve o nome de host da VPN, se o oínte responde ou se un portal cativo admitiu o dispositivo.

Lea a unidade instalada e calquera drop-in antes de engadir dependencias. Un After= amplo en cada servizo de rede atrasa o arrinque sen establecer a conexión que realmente necesita.

Ordee a dependencia que pode probar e comprobe todo o demais cunha sonda de dispoñibilidade. Unha sonda que abre o túnel supera a un temporizador que adiviña.

Que ocorre despois de que o túnel suba por primeira vez

O arrinque é un suceso entre moitos. A ligazón de acceso cambia, unha sesión de portal caduca, o par reiníciase. Distinga unha reconexión interna dunha saída de proceso que xestiona o xestor de servizos, porque ambas teñen propietarios distintos e deixan probas distintas.

A autenticación interactiva limita a recuperación desatendida. Unha unidade en segundo plano non desbloquea un chaveiro de escritorio nin responde a un desafío MFA, así que siga o arranxo de credenciais aprobado para o contexto do servizo.

Decida por separado que poden facer as aplicacións mentres o túnel está caído. O reintento restaura unha conexión, mentres que unha política de bloqueo decide se se permite tráfico directo nesa fenda.