Deter a conexión OpenVPN correcta: primeiro plano, systemd ou NM

Pechar unha xanela de terminal non é o mesmo que pechar un túnel, e matar un proceso non é o mesmo que deter un servizo. En Linux a orde que realmente desconecta depende de que compoñente iniciou a conexión e, polo tanto, posúe o seu ciclo de vida. A comparación seguinte cobre as catro disposicións que máis probablemente atopará, e o identificador que necesita cada unha.

Clientes en primeiro plano e demonizados

Un cliente iniciado á man nun terminal pertence a ese terminal. Ctrl+C entrega unha interrupción, o cliente desmonta a súa interface e o túnel remata. Non hai que avisar nada máis.

Un cliente iniciado mediante un envoltorio de shell e deixado en segundo plano non pertence a ninguén en particular, e ese é o caso no que a xente recorre a killall. Busque primeiro o proceso, confirme que a súa liña de ordes menciona o perfil que quere e logo envíe o sinal de terminación normal. Un proceso supervisado que se mata baixo o seu supervisor simplemente reiniciarase, por iso identificar o propietario importa máis que escoller un sinal. Envíe o sinal ao grupo de procesos só cando confirmou que ningún outro túnel o comparte.

SIGUSR1 non é unha desconexión; pide ao cliente que reinicie o túnel.

Instancias de systemd

Cando unha unidade posúe a conexión, a unidade é o obxecto que hai que deter. As instancias de modelo como openvpn-client@office levan o nome do perfil, e deter o obxectivo de modelo en lugar da instancia pode afectar todos os clientes do host.

systemctl list-units 'openvpn-client@*'
systemctl stop [email protected]

Lea o ExecStart da unidade cando non estea seguro de que perfil cargou a instancia.

Unha unidade habilitada volverá no próximo arranque, o que é unha decisión separada de detela agora. Deshabilítea só despois de decidir que a conexión non debe volver, e anote esa decisión onde a atope o seguinte administrador.

Perfís de NetworkManager

Un perfil xestionado por NetworkManager non é un proceso ao que poida enviar un sinal. O xestor posúe o ciclo de vida, e o obxecto sobre o que hai que actuar é a conexión activa, identificada por UUID e non polo nome visible. Ler primeiro a lista activa tamén mostra se hai un segundo túnel en execución cun nome que non esperaba.

nmcli connection show --active
nmcli connection down uuid actual-uuid

Os nomes visibles repítense, e o nome dun ficheiro de perfil non é o seu identificador, así que copie o UUID da listaxe. Se a conexión volve de inmediato, algo a está a activar: unha entrada secondaries nunha conexión base, un script dispatcher ou unha marca de conexión automática. Deter a conexión do xestor é o primeiro paso correcto, e a reactivación é a seguinte pregunta. Non elimine o perfil para deter a reactivación, porque iso tamén borra as credenciais que quizais necesite mañá.

A referencia de ordes do xestor documenta como se selecciona un obxectivo down.

Sesións de OpenVPN 3

OpenVPN 3 Linux usa un modelo de sesións en lugar dun proceso por túnel. Inspecciona as sesións que coñece o servizo e logo actúa sobre unha ruta de sesión. A ruta é o identificador, e non é intercambiable cun nome de configuración.

openvpn3 sessions-list
openvpn3 session-manage --path /net/openvpn/v3/sessions/... --disconnect

Desconectar todas as sesións é unha acción distinta, e debería ser deliberada.

O mesmo host pode albergar sesións de varios usuarios, así que liste antes de actuar e confirme o propietario da sesión que está a piques de rematar.

Que verificar despois

Comprobe tres cousas tras calquera destas detencións: a lista de conexións activas xa non contén o túnel, a interface desapareceu, e unha consulta de ruta para un enderezo interno xa non selecciona un dispositivo de túnel. Despois decida que ocorre no próximo arranque.

ip -brief address
ip route get 10.8.0.1

Eliminar unha interface á man non detén o propietario, e deixa a limpeza a medias.

Desconectar agora, impedir o próximo arranque automático e permitir despois o tráfico que non é VPN son tres eleccións separadas. Faga cada unha explícita.