Por que uma unidade de VPN inicia antes da rede e depois morre

Inicie a máquina, faça login e descubra que o túnel subiu e morreu alguns segundos depois. O perfil estava bem, o certificado estava bem, e o único rastro que ficou é o journal daquele boot. O que costuma ter acontecido é uma corrida: a unidade iniciou antes de a máquina ter um endereço, e a ordenação que ela declarava não significava o que parece. Tudo abaixo trata de provar essa corrida a partir de evidências e de fechá-la corretamente.

O alvo é um ponto de encontro, não um gerenciador

network-online.target não faz ideia do que é uma rede. É um ponto de coordenação que reúne o serviço que deveria atrasar a inicialização até o link ser utilizável, e delega a definição ao gerenciador de rede que for dono da máquina. Na maioria dos desktops e servidores isso significa um serviço de espera fornecido pelo NetworkManager ou pelo systemd-networkd. Se nenhum for ativado, o alvo não tem nada a esperar, então ele se completa no momento em que algo o puxa, o que pode acontecer muito antes de o DHCP responder. A linha de ordenação na sua unidade era honesta e ainda assim inútil.

A primeira pergunta, portanto, não é o que a sua unidade declara. É se algo nesta máquina está realmente fazendo a espera.

Leia o último boot em vez do arquivo da unidade

Os arquivos de unidade descrevem a intenção, e o journal descreve o que aconteceu. Peça somente aquele boot, com carimbos de tempo monotônicos para que cada mensagem fique em um único relógio. Depois encontre duas linhas: o momento em que a unidade do túnel começou a iniciar e o momento em que o endereço apareceu ou o serviço de espera terminou. Ordene esses dois números e a corrida estará confirmada ou descartada.

A visão de dependências corrobora isso. Se uma cadeia crítica para a unidade do túnel não contém nenhum serviço de espera, nada nesse caminho atrasou a inicialização, e o alvo não fez o trabalho que você supôs. Duas visões, uma conclusão.

systemctl list-units --type=service --state=running | grep wait-online
journalctl -b -o short-monotonic -u openvpn-client@office

Acrescente a espera, depois a nova tentativa

Use um drop-in em vez de editar uma unidade empacotada, para que uma atualização do pacote não descarte a mudança em silêncio. Duas diretivas importam: a unidade precisa ser ordenada depois do alvo e precisa puxar o alvo para a mesma transação. A ordem sozinha não invoca o alvo; o desejo faz isso.

A unidade empacotada do cliente OpenVPN já traz ambas. Unidades escritas à mão costumam trazer uma ou nenhuma, o que vale a pena verificar antes de acrescentar qualquer coisa.

[Service]
Restart=on-failure
RestartSec=15

Por que um sono fixo é uma armadilha

Um sono em ExecStartPre parece uma correção de ordenação e se comporta como um atraso com passos extras. Deixa mais lento cada boot, inclusive os que estavam saudáveis, e ainda perde quando o link demora mais do que o número que você escolheu.

Pior ainda, esconde se o serviço de espera funciona, então a próxima falha aparece como um problema totalmente novo em vez do mesmo com outro tempo. Um atraso curto de reinício é o instrumento melhor: não custa nada em um boot saudável e transforma uma corrida perdida em mais uma tentativa. Mantenha o intervalo modesto e deixe a unidade ter sucesso. Se ela reiniciar para sempre, o perfil está quebrado e nenhuma quantidade de novas tentativas mudará isso, então leia o log em vez de aumentar o intervalo.

Quando a ordem está correta e os nomes ainda falham

Uma unidade ativa com uma rota de túnel significa que a ordenação fez o seu trabalho e que a falha restante está uma camada acima. A forma habitual é um ajuste de resolvedor aplicado pelo script up do túnel antes de o link ou o resolvedor estar pronto para mantê-lo. Compare o estado do resolvedor durante a falha com o estado depois de reiniciar a unidade do túnel.

Se o reinício consertar as consultas, você tem um defeito de ordenação de inicialização e não um servidor DNS errado, e os dois precisam de correções diferentes. Depois prove tudo com um boot frio em vez de um reinício do serviço, porque o reinício roda contra uma rede que já está no ar e esconderá exatamente o defeito que você está perseguindo. Repita com o link deliberadamente lento e trate uma unidade que só funciona quando a rede é rápida como ainda quebrada.