Stopp den rette OpenVPN-tilkoplinga: forgrunn, systemd eller NM

Å lukke eit terminalvindauge er ikkje det same som å lukke ein tunnel, og å drepe ein prosess er ikkje det same som å stoppe ei teneste. På Linux avheng kommandoen som faktisk koplar frå av kva komponent som starta tilkoplinga og derfor eig livssyklusen hennar. Samanlikninga nedanfor dekkjer dei fire ordningane du mest truleg møter, og identifikatoren kvar av dei treng.

Klientar i forgrunn og daemoniserte klientar

Ein klient som blir starta for hand i eit terminalvindauge, høyrer til det terminalvindauget. Ctrl+C leverer eit avbrot, klienten riv ned grensesnittet sitt, og tunnelen blir avslutta. Ingenting anna treng å varslast.

Ein klient som blir starta via ei shell-innpakning og forlaten i bakgrunnen, høyrer til ingen bestemd, og det er tilfellet der folk grip etter killall. Finn prosessen først, stadfest at kommandolinja nemner profilen du meiner, og send deretter det vanlege avslutningssignalet. Ein overvaka prosess som blir drepen under overvakaren sin, blir ganske enkelt starta på nytt, og difor er det viktigare å identifisere eigaren enn å velje eit signal. Send berre signal til prosessgruppa når du har stadfesta at ingen annan tunnel deler henne.

SIGUSR1 er ikkje ei fråkopling; det ber klienten starte tunnelen på nytt.

systemd-instansar

Når ein unit eig tilkoplinga, er uniten objektet som skal stoppast. Malinstansar som openvpn-client@office ber profilnamnet, og å stoppe malmålet i staden for instansen kan påverke kvar klient på verten.

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

Les ExecStart til uniten når du er usikker på kva profil instansen lasta.

Ein unit som er aktivert, kjem tilbake ved neste oppstart, noko som er eit eige vedtak frå å stoppe han no. Deaktiver han først etter at du har bestemt at tilkoplinga ikkje skal kome tilbake, og noter vedtaket der den neste administratoren finn det.

NetworkManager-profilar

Ein profil som blir administrert av NetworkManager, er ikkje ein prosess du kan sende signal til. Administratoren eig livssyklusen, og objektet det skal handlast på er den aktive tilkoplinga, identifisert med UUID og ikkje med visingsnamn. Å lese den aktive lista først viser òg om ein annan tunnel køyrer under eit namn du ikkje forventa.

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

Visingsnamn blir gjentekne, og namnet på ei profilfil er ikkje identifikatoren, så kopier UUID-en frå lista. Viss tilkoplinga kjem rett tilbake, er det noko som aktiverer henne: ein secondaries-oppføring på ei basistilkopling, eit dispatcher-skript eller eit auto-tilkoplingsflagg. Å stoppe tilkoplinga til administratoren er det rette første steget, og reaktiveringa er det neste spørsmålet. Ikkje slett profilen for å stoppe reaktiveringa, for det fjernar òg påloggingsinformasjonen du kanskje treng i morgon.

Kommandoreferansen til administratoren dokumenterer korleis eit down-mål blir valt.

OpenVPN 3-økter

OpenVPN 3 Linux brukar ein øktmodell i staden for ein prosess per tunnel. Du undersøkjer øktene tenesta kjenner, og handlar deretter på éin øktbane. Banen er identifikatoren, og han kan ikkje bytast ut med eit konfigurasjonsnamn.

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

Å kople frå kvar økt er ei anna handling, og ho bør vere medviten.

Same vert kan halde økter frå fleire brukarar, så list før du handlar og stadfest eigaren av økta du er i ferd med å avslutte.

Kva du skal kontrollere etterpå

Kontroller tre ting etter kva som helst av desse stoppa: lista over aktive tilkoplingar inneheld ikkje lenger tunnelen, grensesnittet er borte, og eit ruteoppslag for ei intern adresse vel ikkje lenger ei tunneleining. Bestem deretter kva som skjer ved neste oppstart.

ip -brief address
ip route get 10.8.0.1

Å fjerne eit grensesnitt for hand stoppar ikkje eigaren, og det lèt oppryddinga halvferdig.

Å kople frå no, forhindre neste automatiske start og tillate trafikk utanfor VPN etterpå er tre separate val. Gjer kvart av dei eksplisitt.