OpenVPN diz que a inicialização foi concluída: por que o prompt não volta
A última linha do registro marca o fim da inicialização, não o fim do programa. Escolha entre depurar em primeiro plano, uma unidade de serviço e o modo daemon.
Nada está travado quando o terminal fica silencioso depois da última linha do registro. Essa é a forma esperada de um cliente em primeiro plano: ele terminou de iniciar e agora fica ali transportando tráfego. O prompt do shell não é o sinal de sucesso que parece.
Trate a mensagem como a fronteira entre a inicialização e o estado estável, porque é exatamente isso que ela marca.
A mensagem marca o fim da inicialização, não o fim do processo
OpenVPN imprime essa linha depois de abrir o dispositivo, configurar a interface, instalar as rotas e concluir a troca TLS com o par. Em seguida o processo continua rodando, porque o trabalho dele é manter o túnel aberto e encaminhar pacotes. Um programa em primeiro plano não volta ao prompt enquanto ainda faz esse trabalho. A saída silenciosa depois é normal, já que o cliente só fala quando algo muda.
Se a linha aparecer e a conexão morrer depois, esse é outro evento, e o registro dirá isso depois do fato.
Ctrl+C é uma decisão, não um conserto
Pressionar Ctrl+C envia uma interrupção, que o cliente trata como um pedido de desligamento. O prompt volta, o túnel desaparece e qualquer sessão que o use termina. Isso parece progresso e na verdade é o contrário. Se o objetivo é uma conexão persistente, a resposta é mover o processo para um lugar onde ele possa continuar sem o seu terminal, não interrompê-lo.
Deixá-lo em primeiro plano é a escolha certa enquanto você depura, porque os erros posteriores continuam visíveis na mesma janela. Um minuto de silêncio não prova nada em nenhuma direção; teste um recurso através do túnel em vez de observar a saída.
O que a mensagem não prova
A conclusão é uma afirmação local sobre a configuração do próprio cliente. Ela não diz que o outro lado responde, que as rotas instaladas correspondem ao que você precisa ou que a resolução de nomes pelo túnel funciona. Um perfil de túnel dividido pode estar perfeitamente inicializado enquanto um compartilhamento da empresa continua inacessível porque a rota ou a política de DNS nunca o cobriu. As instâncias do lado do servidor imprimem uma linha semelhante quando estão prontas para aceitar clientes, o que não é o mesmo que ter um cliente conectado.
«O servidor iniciou» e «o laptop consegue abrir o compartilhamento» são observações de dois lugares diferentes, e misturá-las manda você depurar o host errado.
Executar sem terminal
Para uma implantação persistente, use a disposição de serviço que a plataforma suporta. Num host com systemd isso é uma instância openvpn-client@office com o perfil em /etc/openvpn/client, iniciada e habilitada para sobreviver a reinicializações. O Community OpenVPN também oferece --daemon junto com --log ou --log-append, o que desanexa o processo e envia a saída para um arquivo. As duas abordagens mudam como o processo roda; nenhuma corrige uma rota ou torna saudável uma aplicação remota.
Verifique que você não está iniciando uma segunda instância ao lado de uma que um serviço já gerencia. Dois clientes reivindicando o mesmo perfil produzem registros confusos e um túnel que você não pretendia.
Escolha a disposição que combina com a tarefa
Primeiro plano para diagnóstico, serviço para tudo o que precisa sobreviver à sessão, modo daemon quando não há um gerenciador de serviços para usar como apoio. Esses três cobrem os casos comuns, e cada um tem um motivo claro para existir. Escolher um deles por acidente é o que produz o relatório «funciona até a janela fechar».
Quando o túnel deve ficar, confirme depois que ele volta após uma reinicialização e que os registros dele chegam a algum lugar onde você vai olhar. A linha de inicialização também aparece nesses registros, e então ninguém precisa vigiar um terminal por causa dela.