Stoppa rätt OpenVPN-anslutning: förgrund, systemd eller NM

Att stänga ett terminalfönster är inte samma sak som att stänga en tunnel, och att döda en process är inte samma sak som att stoppa en tjänst. På Linux beror kommandot som faktiskt kopplar från på vilken komponent som startade anslutningen och därför äger dess livscykel. Jämförelsen nedan täcker de fyra upplägg du mest sannolikt möter, och den identifierare som varje behöver.

Klienter i förgrunden och daemoniserade klienter

En klient som startas för hand i en terminal tillhör den terminalen. Ctrl+C levererar ett avbrott, klienten river ner sitt gränssnitt och tunneln avslutas. Inget annat behöver underrättas.

En klient som startas via ett shell-omslag och lämnas i bakgrunden tillhör ingen särskild, och det är fallet där folk griper efter killall. Hitta processen först, bekräfta att dess kommandorad nämner den avsedda profilen och skicka sedan den vanliga avslutningssignalen. En övervakad process som dödas under sin övervakare startas helt enkelt om, därför är det viktigare att identifiera ägaren än att välja en signal. Skicka bara signal till processgruppen när du har bekräftat att ingen annan tunnel delar den.

SIGUSR1 är inte en frånkoppling; det ber klienten starta om tunneln.

systemd-instanser

När en unit äger anslutningen är uniten objektet som ska stoppas. Mallinstanser som openvpn-client@office bär profilnamnet, och att stoppa mallmålet i stället för instansen kan påverka varje klient på värden.

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

Läs unitens ExecStart när du är osäker på vilken profil instansen laddade.

En unit som är aktiverad kommer tillbaka vid nästa start, vilket är ett separat beslut från att stoppa den nu. Inaktivera den först efter att du har beslutat att anslutningen inte ska komma tillbaka, och anteckna beslutet där nästa administratör hittar det.

NetworkManager-profiler

En profil som hanteras av NetworkManager är inte en process som du kan skicka en signal till. Hanteraren äger livscykeln, och objektet som ska hanteras är den aktiva anslutningen, identifierad med UUID och inte med visningsnamn. Att läsa den aktiva listan först visar också om en andra tunnel körs under ett namn du inte förväntade dig.

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

Visningsnamn upprepas, och en profilfils namn är inte dess identifierare, så kopiera UUID:t från listan. Om anslutningen kommer tillbaka direkt aktiverar något den: en secondaries-post på en basanslutning, ett dispatcher-skript eller en autoconnect-flagga. Att stoppa hanterarens anslutning är det rätta första steget, och återaktiveringen är nästa fråga. Ta inte bort profilen för att stoppa återaktiveringen, eftersom det också tar bort inloggningsuppgifterna du kan behöva i morgon.

Hanterarens kommandoreferens dokumenterar hur ett down-mål väljs.

OpenVPN 3-sessioner

OpenVPN 3 Linux använder en sessionsmodell i stället för en process per tunnel. Du granskar de sessioner som tjänsten känner till och agerar sedan på en sessionssökväg. Sökvägen är identifieraren, och den kan inte bytas ut mot ett konfigurationsnamn.

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

Att koppla från varje session är en annan åtgärd, och den bör vara avsiktlig.

Samma värd kan hålla sessioner från flera användare, så lista innan du agerar och bekräfta ägaren till den session du är på väg att avsluta.

Vad du ska kontrollera efteråt

Kontrollera tre saker efter varje sådant stopp: listan över aktiva anslutningar innehåller inte längre tunneln, gränssnittet är borta, och en vägsökning för en intern adress väljer inte längre en tunnelenhet. Bestäm sedan vad som händer vid nästa start.

ip -brief address
ip route get 10.8.0.1

Att ta bort ett gränssnitt för hand stoppar inte ägaren, och det lämnar städningen halvfärdig.

Att koppla från nu, förhindra nästa automatiska start och tillåta trafik utanför VPN efteråt är tre separata val. Gör vart och ett av dem uttryckligt.