Stopp den riktige OpenVPN-tilkoblingen: forgrunn, systemd eller NM

Å lukke et terminalvindu er ikke det samme som å lukke en tunnel, og å drepe en prosess er ikke det samme som å stoppe en tjeneste. På Linux avhenger kommandoen som faktisk kobler fra av hvilken komponent som startet tilkoblingen og derfor eier livssyklusen dens. Sammenligningen nedenfor dekker de fire ordningene du mest sannsynlig møter, og identifikatoren hver av dem trenger.

Klienter i forgrunn og daemoniserte klienter

En klient som startes for hånd i et terminalvindu, tilhører det terminalvinduet. Ctrl+C leverer en avbrudd, klienten river ned grensesnittet sitt, og tunnelen avsluttes. Ingenting annet trenger å varsles.

En klient som startes via en shell-innpakning og forlates i bakgrunnen, tilhører ingen bestemt, og det er tilfellet der folk griper etter killall. Finn prosessen først, bekreft at kommandolinjen nevner profilen du mener, og send deretter det vanlige avslutningssignalet. En overvåket prosess som drepes under overvåkeren sin, blir ganske enkelt startet på nytt, og derfor er det viktigere å identifisere eieren enn å velge et signal. Send bare signal til prosessgruppen når du har bekreftet at ingen annen tunnel deler den.

SIGUSR1 er ikke en frakobling; det ber klienten starte tunnelen på nytt.

systemd-instanser

Når en unit eier tilkoblingen, er uniten objektet som skal stoppes. Malinstanser som openvpn-client@office bærer profilnavnet, og å stoppe malmålet i stedet for instansen kan påvirke hver klient på verten.

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

Les unitens ExecStart når du er usikker på hvilken profil instansen lastet.

En unit som er aktivert, kommer tilbake ved neste oppstart, noe som er en egen beslutning fra å stoppe den nå. Deaktiver den først etter at du har bestemt at tilkoblingen ikke skal komme tilbake, og noter beslutningen der den neste administratoren finner den.

NetworkManager-profiler

En profil som administreres av NetworkManager, er ikke en prosess du kan sende signal til. Administratoren eier livssyklusen, og objektet det skal handles på er den aktive tilkoblingen, identifisert med UUID og ikke med visningsnavn. Å lese den aktive listen først viser også om en annen tunnel kjører under et navn du ikke forventet.

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

Visningsnavn gjentas, og en profilfil sitt navn er ikke identifikatoren, så kopier UUID-en fra listen. Hvis tilkoblingen kommer rett tilbake, er det noe som aktiverer den: en secondaries-oppføring på en basistilkobling, et dispatcher-skript eller et auto-tilkoblingsflagg. Å stoppe administratorens tilkobling er det riktige første steget, og reaktiveringen er det neste spørsmålet. Ikke slett profilen for å stoppe reaktiveringen, for det fjerner også påloggingsinformasjonen du kanskje trenger i morgen.

Administratorens kommandoreferanse dokumenterer hvordan et down-mål velges.

OpenVPN 3-økter

OpenVPN 3 Linux bruker en øktmodell i stedet for en prosess per tunnel. Du undersøker øktene tjenesten kjenner, og handler deretter på én øktbane. Banen er identifikatoren, og den kan ikke byttes ut med et konfigurasjonsnavn.

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

Å koble fra hver økt er en annen handling, og den bør være bevisst.

Samme vert kan holde økter fra flere brukere, så list før du handler og bekreft eieren av økten du er i ferd med å avslutte.

Hva du skal kontrollere etterpå

Kontroller tre ting etter hvilken som helst av disse stoppene: listen over aktive tilkoblinger inneholder ikke lenger tunnelen, grensesnittet er borte, og et ruteoppslag for en intern adresse velger ikke lenger en tunnel-enhet. Bestem deretter hva som skjer ved neste oppstart.

ip -brief address
ip route get 10.8.0.1

Å fjerne et grensesnitt for hånd stopper ikke eieren, og det etterlater oppryddingen halvferdig.

Å koble fra nå, forhindre neste automatiske start og tillate trafikk utenfor VPN etterpå er tre separate valg. Gjør hvert av dem eksplisitt.