OpenVPN di active (exited)? Atope a instancia que iniciou

Comproba o túnel, executa systemctl status openvpn e obtén active (exited) sen Main PID e cunha lista de procesos baleira. A lectura natural é que o servizo arrincou e morreu, así que abre a unidade, atopa /bin/true e conclúe que o paquete está roto. No empaquetado de Debian ese estado é o contedor traballando como se deseñou, e o túnel vive nunha das unidades de instancia que inicia. A unidade agregada nunca lle dirá que instancia a construíu.

Que significa realmente active (exited) nesta unidade

A unidade empaquetada é dunha soa vez: o seu ExecStart é /bin/true, e RemainAfterExit=yes é o que mantén unha unidade rematada informada como active (exited). Quite esa directiva e a mesma tarefa /bin/true exitosa remata en inactive (dead), que é exactamente o estado que a xente espera e le mal na dirección contraria. O comando é un marcador de posición, e a unidade informa sobre traballo que realizan outras unidades. Nada dese arranxo está roto, e substituír /bin/true cambia o contrato de empaquetado, non o túnel.

O contedor delega. Inicia as unidades de instancia que fornece a configuración do paquete ou o seu xerador de systemd, e por iso unha lista de procesos baleira non demostra nada sobre o túnel. Cando non se selecciona ningunha instancia, o contedor segue tendo éxito e segue sen iniciar nada. O estado responde se o contedor se executou, non se existe un túnel.

Lea as tres liñas da saída de status en lugar da palabra entre parénteses. Loaded nomea o ficheiro de unidade que systemd leu, Active leva a marca de tempo da última execución exitosa e a ausencia de Main PID encaixa cunha tarefa dunha soa vez xa rematada. Esas tres liñas son tamén a forma de distinguir este contedor dun servizo que caeu un segundo despois de arrincar.

Liste as unidades antes de volver ler o estado

Pregunte a systemd que existe antes de preguntar que se executa. Un modelo pode estar instalado mentres non se crea ningunha instancia, e só unha unidade creada leva un túnel. Comece polo conxunto cargado:

systemctl list-units 'openvpn*'

Esa lista é o que systemd cargou neste momento, e é o máis parecido a un inventario de túneles. Os ficheiros de unidade instalados responden outra pregunta, e esa lista segue mostrando un modelo cando non se creou nada:

systemctl list-unit-files 'openvpn*'

Lea as dúas listas xuntas, porque un modelo na segunda e unha instancia na primeira son respostas distintas. Un modelo que existe e unha instancia que se executa non son o mesmo feito, e só a segunda significa un túnel. Os deseños de paquete tamén varían entre distribucións e versións de OpenVPN. Un modelo openvpn@ máis antigo, un par separado de client e server e un contedor de distribución poden ser todos lexítimos no seu propio empaquetado.

Adáptese á súa máquina en lugar do tutorial que atopou. O nome de instancia na saída doutra persoa pode ser office mentres o seu é home ou work. O que se transfire é o método, non a cadea.

Siga o nome de instancia ata o ficheiro que le

No modelo de client upstream o directorio de traballo da unidade é /etc/openvpn/client e o seu comando toma %i.conf de alí, así que openvpn-client@office le /etc/openvpn/client/office.conf. Confirme esa correspondencia na unidade instalada en lugar de confiar no exemplo, porque o modelo que ten pode ser máis antigo ou unha reescritura da distribución:

systemctl cat [email protected]

Lea os drop-in que aparecen ao final desa saída, porque un ficheiro baixo .d/ pode cambiar ExecStart, o directorio de traballo ou a ruta de configuración. Un perfil que descargou como office.ovpn non é o ficheiro que abre a instancia. Esa fenda é a razón habitual de que un erro nomee unha ruta que nunca editou.

As rutas relativas dentro do perfil son a seguinte trampa. Mover o ficheiro principal mentres as referencias ca, cert e key seguen sendo relativas cambia un erro de ficheiro ausente por outro erro de ficheiro ausente. O segundo apunta a un ficheiro que estaba seguro de que existía, e por iso o directorio do perfil importa máis que o nome do ficheiro.

Iníciea e despois lea o rexistro desa instancia

Inicie a instancia que acaba de inspeccionar, porque o rexistro da unidade agregada non conterá os erros do túnel. Despois lea o rexistro deste arrinque e busque nesa orde un erro de configuración, un erro de acceso a ficheiro e un erro de conexión, porque cada un falla nunha etapa distinta do arrinque.

sudo systemctl start [email protected]
journalctl -u [email protected] -b

Iniciar e habilitar son decisións separadas: start executa a unidade agora, enable prepara o próximo arrinque e enable --now fai ambas as cousas nun paso. daemon-reload rele as definicións de unidade e non reinicia un proceso en execución nin aplica un perfil editado. Despois de cambiar o perfil, reinicie a instancia, porque iso é o que rele o ficheiro.

Non poña un segundo xestor no mesmo túnel

NetworkManager e os xestores de sesión de OpenVPN 3 teñen o seu propio estado de conexión, e unha instancia de systemd xunto a un deles pon dous propietarios no mesmo túnel. O síntoma é un túnel que sobe e se substitúe segundos despois, ou un que se nega a quedar detido. Escolla o xestor que a súa distribución documenta para o escritorio e use systemd deliberadamente nun servidor.

Comprobe se xa hai un propietario antes de iniciar unha instancia. Cando un applet de escritorio mostra a conexión, a instancia que inicia compite con el en lugar de completalo. Desactive o xestor que non usa en lugar de executar ambos e esperar que a orde aguante. Ese conflito tamén explica rexistros nos que se establece un túnel e logo o desmonta un proceso que nunca iniciou.

Responda a pregunta orixinal co nome da instancia, o ficheiro que leu e a liña de rexistro que fallou. As notas de OpenVPN sobre a integración con systemd describen o deseño do modelo e a correspondencia de ficheiro pola que se resolve o nome de instancia.