O OpenVPN que arranca antes da rede não é uma falha
Um cliente que arranca antes de o servidor estar acessível está a repetir tentativas, não a falhar. Separe ordem, DNS, autenticação e recuperação após a ligação.
Arranca o cliente no arranque, a unidade reporta ativo, e o túnel não está lá. A conclusão natural é que o serviço falhou ao iniciar, e a correção natural é iniciá-lo de novo. Ambas estão erradas com frequência suficiente para merecer uma regra: um cliente em execução que está a repetir tentativas parece exatamente um avariado visto de fora. A diferença está no que o processo faz, não no estado da unidade.
Mito: um serviço iniciado significa um túnel a funcionar
Uma unidade ativa prova que o processo foi lançado e não terminou. Não prova que o perfil foi carregado, que o certificado foi aceite, nem que o outro extremo respondeu. Um cliente empacotado pode ficar minutos num ciclo de tentativas enquanto o systemd só reporta sucesso. Essa lacuna entre estado e comportamento é o tema todo.
O caso oposto é igualmente comum. O processo pode ter terminado depois de falhar a leitura de uma chave, e a unidade reporta então um estado de falha que nada diz sobre o porquê. Ambos os estados precisam do registo para serem distinguidos.
Leia o journal da instância em vez do estado da unidade. A linha da razão está no registo, não no rótulo de estado.
Mito: as definições de repetição cobrem todas as falhas
A resolução de nomes e as repetições de transporte são controlos separados com valores por omissão separados. resolv-retry governa as procuras repetidas de um nome de anfitrião remoto, e o valor por omissão documentado continua a tentar indefinidamente. connect-retry define o intervalo entre tentativas, enquanto connect-retry-max pode limitar quantas vezes cada entrada remota é tentada. Verifique que etapa o registo nomeia antes de alterar qualquer um deles.
Nada disso se aplica a um perfil malformado, a uma chave privada ilegível ou a uma conta rejeitada. Esses precisam de correção, e um cliente que continua a repeti-los não está a progredir.
Repetir para sempre um certificado não aprovado não é motivo para remover a verificação. É motivo para ler o erro.
Mito: um lançador chega, por isso acrescente outro
Uma ligação já gerida pelo NetworkManager ou por uma unidade empacotada não precisa de um segundo lançador ligado a ela. Dois processos a competir pelas mesmas rotas produzem interfaces duplicadas, registos confusos e um túnel que oscila por razões que ninguém vê. A segunda cópia chega normalmente como solução para o primeiro estar lento.
Decida que componente é dono do túnel antes de acrescentar seja o que for. Depois remova o outro lançador em vez de o desativar e esperar.
O dono também determina de onde vêm as repetições e as credenciais, e é por isso que esta decisão vem antes de qualquer afinação. A propriedade vem primeiro exatamente por essa razão.
O que precisa mesmo de ordem
A ordem pode esperar por um endereço configurado, e é tudo o que garante. network-online.target atrasa a ativação até o gestor considerar a rede ativa, e a definição de ativa depende do gestor. Não diz nada sobre se o nome do anfitrião VPN resolve, se o ouvinte responde ou se um portal cativo deixou o dispositivo entrar.
Leia a unidade instalada e quaisquer drop-ins antes de acrescentar dependências. Um After= amplo em cada serviço de rede atrasa o arranque sem estabelecer a ligação de que realmente precisa.
Ordene a dependência que consegue testar, e verifique tudo o resto com uma sonda de prontidão. Uma sonda que abre o túnel vence um temporizador que adivinha.
O que acontece depois de o túnel subir pela primeira vez
O arranque é um evento entre muitos. A ligação de acesso muda, uma sessão de portal expira, o par reinicia. Distinga uma reconexão interna de uma saída de processo tratada pelo gestor de serviços, porque as duas têm donos diferentes e deixam provas diferentes.
A autenticação interativa condiciona a recuperação sem supervisão. Uma unidade em segundo plano não desbloqueia um chaveiro do ambiente de trabalho nem responde a um pedido de MFA, por isso siga o arranjo de credenciais aprovado para o contexto do serviço.
Decida em separado o que as aplicações podem fazer enquanto o túnel está em baixo. A repetição restaura uma ligação, enquanto uma política de bloqueio decide se o tráfego direto é permitido nesse intervalo.