Ett frånkopplingsskript misslyckas oftast av en enda anledning: det vänder sig till fel ägare. En tunnel som styrs av communityns OpenVPN GUI tillhör den GUI-sessionen, en tunnel som startats av en Windows-tjänst tillhör tjänsten, och OpenVPN Connect tillhör ingen av dem. Gå igenom dessa kontroller i ordning och stanna när ägaren är oklar. Att skicka ett kill-kommando eftersom ägaren var tvetydig är precis hur frånkopplingen av en profil blir ett avbrott för hela platsen.

För en GUI-styrd anslutning är det användbara kommandot ett meddelande till GUI:t, inte en signal till openvpn.exe.

Fastställ först ägaren

Titta på vilket program som faktiskt visar det anslutna tillståndet innan du skriver något. En ikon i aktivitetsfältet betyder att GUI-sessionen äger den. En tjänstepost betyder att tjänsten gör det. Ett separat programfönster med egen profillista betyder ingen av dem, och dess eget versionsspecifika gränssnitt gäller.

Kontrollera även kontot och skrivbordssessionen. En schemalagd uppgift som körs som en annan användare, eller i en icke-interaktiv session, bör inte antas styra det GUI som en inloggad person ser. Den missanpassningen ger ett kommando som avslutas rent och inte ändrar något, och det är den dyraste typen av fel att felsöka ur en logg.

Skicka sedan ägarens egen frånkoppling

Om GUI:t är installerat på sökvägen i exemplet och det finns en profil som heter office, är hela kommandot en rad:

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

Byt ut den mot din faktiska installationssökväg och det exakta konfigurationsnamnet, inklusive stora och små bokstäver så som GUI:t visar dem. Projektets kommandodokumentation listar de GUI-kontroller som stöds, och det här exemplet tillhör enbart OpenVPN GUI — det är inte ett kommando för varje program med OpenVPN i namnet.

För en tjänstestyrd tunnel är rätt kontroll tjänsten, inte GUI-binären. Granska den installerade tjänsten och de profiler den hanterar innan du stoppar något, eftersom ett stopp kan fälla flera tunnlar samtidigt och du får inget resultat per profil tillbaka.

Kontrollera att inget annat faller

GUI:t dokumenterar också kommandot disconnect_all, och dess omfattning är just anledningen till att det är fel verktyg för ett skript som bara ska stoppa office. Om du frestas att använda det för enkelhetens skull, fråga vad mer som är anslutet på den maskinen och hur användaren kommer att märka det.

taskkill /F /IM openvpn.exe är sämre på två sätt. Det väljer processer efter den körbara filens namn och tvingar fram avslut, så det uttrycker varken ett profilnamn eller ägarens normala frånkopplingssekvens. Att kalla det en prydlig avstängning döljer båda problemen bakom en enda utgångsstatus.

Vilken väg du än väljer, kontrollera påverkans omfattning före ändringen: lista de anslutna profilerna, notera vilka som ska överleva och kontrollera dem igen efteråt.

Bekräfta tillståndet, inte utgångskoden

Efter att ha begärt frånkopplingen, läs tillståndet för den namngivna anslutningen via dess ägare i stället för att lita på kommandots returvärde. Om nästa steg behöver nätverket efter nedmonteringen, vänta på den tillståndsändringen med en uttrycklig tidsgräns i stället för att anta att städningen var klar när processen återvände. Ett skript som tävlar med nedmonteringen kommer att misslyckas ibland och VPN får skulden.

Om tillståndet aldrig ändras är ägaren förmodligen inte den du vände dig till. Kontrollera sessionen och kontot igen innan du eskalerar till ett starkare kommando.

Vad som ska stå i loggen

Logga profilnamnet, ägaren du vände dig till och startkontexten, plus det resulterande tillståndet. Häll inte hela konfigurationen eller autentiseringsuppgifterna i uppgiftsloggen, och logga inte kommandoraden om den innehåller en sökväg till en fil med hemligheter.

Ett felmeddelande som namnger profilen och kontexten räcker för att nästa person ska kunna återskapa problemet. En logg som bara registrerar en generisk utgångskod skickar dem tillbaka till början, och det är precis där gissningarna börjar om.

Relaterade artiklar