Ĉesigu la ĝustan OpenVPN-konekton: antaŭplano, systemd aŭ NM
La komando, kiu malligas tunelon, dependas de tio, kiu startigis ĝin. Komparu la posedantojn de antaŭplano, systemd, NetworkManager kaj OpenVPN 3 antaŭ ol sendi signalon.
Fermi terminalan fenestron ne samas kiel fermi tunelon, kaj mortigi procezon ne samas kiel haltigi servon. En Linux la komando, kiu efektive malligas la konekton, dependas de kiu komponanto startigis la konekton kaj tial posedas ĝian vivciklon. La sekva komparo kovras la kvar aranĝojn, kiujn vi plej verŝajne renkontos, kaj la identigilon, kiun ĉiu bezonas.
Antaŭplanaj kaj demonigitaj klientoj
Kliento startigita mane en terminalo apartenas al tiu terminalo. Ctrl+C transdonas interrompon, la kliento malkonstruas sian interfacon, kaj la tunelo finiĝas. Nenio alia devas esti sciigita.
Kliento startigita per ŝela ĉirkaŭaĵo kaj lasita en fono apartenas al neniu aparte, kaj ĝuste tiam homoj atingas por killall. Unue trovu la procezon, konfirmu, ke ĝia komandlinio mencias la celatan profilon, kaj poste sendu la normalan finan signalon. Superrigardata procezo mortigita sub sia superrigardo simple restartiĝos, tial identigi la posedanton pli gravas ol elekti signalon. Sendu signalon al la procesgrupo nur kiam vi konfirmis, ke neniu alia tunelo ĝin dividas.
SIGUSR1 ne estas malligo; ĝi petas al la kliento restartigi la tunelon.
systemd-instancoj
Kiam unuo posedas la konekton, la unuo estas la objekto haltigenda. Ŝablonaj instancoj kiel openvpn-client@office portas la profilnomon, kaj haltigi la ŝablonan celon anstataŭ la instancon povas efiki ĉiun klienton sur la gastiganto.
systemctl list-units 'openvpn-client@*'
systemctl stop [email protected]
Legu la ExecStart de la unuo kiam vi ne certas, kiun profilon la instanco ŝargis.
Ŝaltita unuo revenos ĉe la sekva praŝargo, kio estas aparta decido ol haltigi ĝin nun. Malŝaltu ĝin nur post kiam vi decidis, ke la konekto ne revenu, kaj registru tiun decidon tie, kie la sekva administranto trovos ĝin.
NetworkManager-profiloj
Profilo administrata de NetworkManager ne estas procezo, al kiu vi povas sendi signalon. La administranto posedas la vivciklon, kaj la objekto agendota estas la aktiva konekto, identigita per UUID anstataŭ per montra nomo. Legi la aktivan liston unue ankaŭ montras, ĉu dua tunelo funkcias sub nomo, kiun vi ne atendis.
nmcli connection show --active
nmcli connection down uuid actual-uuid
Montraj nomoj ripetiĝas, kaj la nomo de profil-dosiero ne estas ĝia identigilo, do kopiu la UUID el la listo. Se la konekto tuj revenas, io aktivigas ĝin: secondaries-enskribo sur baza konekto, dispatcher-skripto, aŭ aŭtomata konekta flago. Haltigi la konekton de la administranto estas la ĝusta unua paŝo, kaj la reaktivigo estas la sekva demando. Ne forigu la profilon por haltigi la reaktivigon, ĉar tio ankaŭ forigas la legitimilojn, kiujn vi eble bezonos morgaŭ.
La komanda referenco de la administranto dokumentas, kiel down-celo estas elektata.
OpenVPN 3-sesioj
OpenVPN 3 Linux uzas sesian modelon anstataŭ procezo por tunelo. Vi inspektas la sesiojn, kiujn la servo konas, poste agas sur unu sesia vojo. La vojo estas la identigilo, kaj ĝi ne estas interŝanĝebla kun agorda nomo.
openvpn3 sessions-list
openvpn3 session-manage --path /net/openvpn/v3/sessions/... --disconnect
Malligi ĉiun sesion estas malsama ago, kaj ĝi devus esti intenca.
La sama gastiganto povas teni sesiojn de pluraj uzantoj, do listigu antaŭ ol agi kaj konfirmu la posedanton de la sesio, kiun vi finos.
Kion kontroli poste
Kontrolu tri aferojn post iu ajn el tiuj haltoj: la listo de aktivaj konektoj ne plu enhavas la tunelon, la interfaco malaperis, kaj vojserĉo por interna adreso ne plu elektas tunelan aparaton. Poste decidu, kio okazos ĉe la sekva praŝargo.
ip -brief address
ip route get 10.8.0.1
Forigi interfacon mane ne haltigas la posedanton, kaj ĝi lasas la purigadon duone farita.
Malligi nun, malhelpi la sekvan aŭtomatan starton, kaj poste permesi ne-VPN-trafikon estas tri apartaj elektoj. Faru ĉiun el ili eksplicite.