Malkonektu unu OpenVPN GUI-profilo, ne ĉiujn tunelojn

Malkonekta skripto kutime malsukcesas pro unu kialo: ĝi alparolas la malĝustan posedanton. Tunelo administrata de la komunuma OpenVPN GUI apartenas al la seanco de tiu GUI, tunelo startigita de Windows-servo apartenas al la servo, kaj OpenVPN Connect apartenas al neniu el ili. Trapasu ĉi tiujn kontrolojn laŭorde kaj haltu, kiam la posedanto ne klaras. Sendi kill-komandon ĉar la posedanto estis ambigua estas ĝuste tiel unu profila malkonekto fariĝas paneo de la tuta ejo.

Por GUI-administrata konekto, la utila komando estas mesaĝo al la GUI, ne signalo al openvpn.exe.

Unue determinu la posedanton

Rigardu, kiu programo fakte montras la konektitan staton, antaŭ ol vi skribos ion. Piktogramo en la sistemopleto signifas, ke la GUI-seanco posedas ĝin. Serva ero signifas, ke la servo posedas ĝin. Aparta aplikaĵa fenestro kun propra profillisto signifas neniun el ambaŭ, kaj validas ĝia propra versiospecifa fasado.

Kontrolu ankaŭ la konton kaj la labortablan seanson. Planita tasko kuranta kiel alia uzanto, aŭ en neinteraga seanco, ne estu supozata kiel reganto de la GUI, kiun ensalutinta persono vidas. Tiu miskongruo produktas komandon, kiu finiĝas pure kaj ŝanĝas nenion, kaj tio estas la plej multekosta speco de paneo por spuri el protokolo.

Poste sendu la propran malkonekton de la posedanto

Se la GUI estas instalita ĉe la ekzempla vojo kaj ekzistas profilo nomata office, la tuta komando estas unu linio:

"C:\Program Files\OpenVPN\bin\openvpn-gui.exe" --command disconnect office

Anstataŭigu ĝin per via reala instala vojo kaj la preciza agorda nomo, inkluzive de uskleco kiel la GUI montras ĝin. La komanda dokumentaro de la projekto listigas la subtenatajn GUI-regilojn, kaj ĉi tiu ekzemplo apartenas nur al OpenVPN GUI — ĝi ne estas komando por ĉiu aplikaĵo kun OpenVPN en sia nomo.

Por servoposedata tunelo, la ĝusta regilo estas la servo, ne la GUI-dosiero. Kontrolu la instalitan servon kaj la profilojn, kiujn ĝi administras, antaŭ ol haltigi ion ajn, ĉar halto povas faligi plurajn tunelojn samtempe kaj vi ne ricevos rezulton por unuopa profilo.

Kontrolu, ke nenio alia falas

La GUI ankaŭ dokumentas komandon disconnect_all, kaj ĝia amplekso estas ĝuste la kialo, ke ĝi estas la malĝusta ilo por skripto, kiu devas haltigi nur office. Se vi estas tentata uzi ĝin pro simpleco, demandu, kio alia estas konektita sur tiu maŝino kaj kiel la uzanto rimarkos.

taskkill /F /IM openvpn.exe estas pli malbona laŭ du manieroj. Ĝi elektas procezojn laŭ la nomo de la plenumebla dosiero kaj devigas finiĝon, do ĝi esprimas nek profilan nomon nek la normalan malkonektan sinsekvon de la posedanto. Nomi tion pura malŝalto kaŝas ambaŭ problemojn malantaŭ unu sola elira stato.

Kiun ajn vojon vi elektos, kontrolu la amplekson de la efiko antaŭ la ŝanĝo: listigu la konektitajn profilojn, notu kiuj devas postvivi, kaj kontrolu ilin denove poste.

Konfirmu la staton, ne la eliran kodon

Post peti la malkonekton, legu la staton de la nomita konekto tra ĝia posedanto anstataŭ fidi la redonan valoron de la komando. Se la sekva paŝo bezonas la reton post la malkonstruo, atendu tiun statŝanĝon kun eksplicita tempolimo anstataŭ supozi, ke la purigado finiĝis kiam la procezo revenis. Skripto, kiu kuras konkurse kun la malkonstruo, malsukcesos foje kaj la VPN ricevos la kulpon.

Se la stato neniam ŝanĝiĝas, la posedanto verŝajne ne estas tiu, kiun vi alparolis. Rekontrolu la seanson kaj la konton antaŭ ol eskali al pli forta komando.

Kion meti en la protokolon

Protokolu la profilan nomon, la posedanton, kiun vi alparolis, kaj la lanĉan kuntekston, plus la rezultan staton. Ne elverŝu la plenan agordon aŭ la akreditaĵojn en la taskan protokolon, kaj ne protokolu la komandan linion se ĝi enhavas vojon al dosiero kun sekretoj.

Erarmesaĝo, kiu nomas la profilon kaj la kuntekston, sufiĉas por ke la sekva persono reproduktu la problemon. Protokolo, kiu registras nur ĝeneralan eliran kodon, resendas ilin al la komenco, kaj ĝuste tie la konjektado rekomenciĝas.