OpenVPN-motor eller Tunnelblick: vem äger Mac VPN-sessionen?

Homebrew installerar ett OpenVPN-program; Tunnelblick installerar en hanterare som kör en eller flera motorer. Det är olika lager, och den användbara frågan är inte om du gillar att använda en terminal. Det är vem som äger konfigurationen, DNS-ändringarna, begäran om inloggningsuppgifter och städningen när sessionen slutar. En enda ägare för dessa lager gör uppsättningen förutsägbar.

Gå igenom de fem kontrollerna nedan i ordning. Den första som har två ägare är den som skapar de märkliga halvanslutna tillstånden som folk skyller på OpenVPN självt. Varje kontroll namnger beviset som avgör den.

Kontroll ett: vilken OpenVPN-binärfil som faktiskt körs

Kör pgrep -fl openvpn medan du är ansluten och läs hela kommandoraden. Den första sökvägen är motorn som faktiskt körs. På Apple Silicon ligger en Homebrew-installation vanligtvis under /opt/homebrew, medan Intel-Macar använder /usr/local, och Tunnelblick kör en motor inifrån sitt eget applikationspaket.

Tunnelblick samlar motorer och låter en konfiguration välja en. Att uppdatera Homebrew-formeln ändrar den fristående binärfilen, inte motorn som en Tunnelblick-profil startar. Om du jämför versioner för att förklara en beteendeskillnad, jämför motorn i processlistan och inte den i pakethanteraren. Bara versionssträngen berättar inte vilken profil den motorn laddade.

En kopierad profil kan också få två motorer att se identiska ut medan de läser olika filer. Profilens sökväg på kommandoraden berättar vilken konfiguration den körande processen laddade; en profil som är öppen i en editor är inte bevis. Jämför den sökvägen innan du jämför beteende.

Kontroll två: vem ändrar DNS och rutter

Motorn kan köra OpenVPN:s egna up- och down-direktiv, men hanteraren kan äga samma livscykel. Tunnelblicks namnserverinställningar styr dess standardanslutnings- och frånkopplingsskript, och när den integrationen är aktiverad kan konkurrerande direktiv i profilen ignoreras.

Det spelar roll eftersom DNS är där en fungerande tunnel oftast ser trasig ut. Kontrollera scutil --dns medan du är ansluten, notera vilken resolver som är först och bekräfta att den kommer tillbaka efter frånkoppling. Om profilen förväntar sig att sätta DNS själv medan hanteraren också styr det, förlorar en av de två.

Bestäm vilket lager som äger DNS före den första anslutningen och ta sedan bort det förlorande direktivet i stället för att låta båda stå kvar. Ruttändringar följer samma regel: en ägare, synlig i konfigurationen, med en dokumenterad återställningsväg.

Kontroll tre: varifrån inloggningsuppgifterna kommer

En interaktiv begäran och en process utan övervakning har olika krav. Inloggningsuppgifter som sparas av en applikation är inte automatiskt tillgängliga för en annan process, och ett nyckelringsobjekt som är knutet till hanteraren kan vara osynligt för en fristående motor som startats från ett skal.

Lista källan till inloggningsuppgifter för profilen: ett klientcertifikat och en nyckel, en begäran om användarnamn och lösenord, eller en token som tillhandahålls av en extern hjälpare. Bekräfta sedan att den valda ägaren kan nå den källan utan en människa om anslutningen ska överleva en omstart.

Kontroll fyra: vem startar, övervakar och stoppar processen

En fristående utrullning behöver en övervakare om den ska hållas igång. Launchd kan starta motorn vid inloggning eller på begäran, starta om den efter en krasch och stoppa den rent, men någon måste skriva och äga det jobbet. Att köra kommandot i en terminal fungerar för ett test och inte för en användare som stänger fönstret.

Om Tunnelblick fortsätter som ägare, använd dess stödda kontroller i stället för att starta en andra motor. Homebrew-binärfilen startar, med en kopierad profil, en oberoende anslutning med sin egen konfiguration och integrationskontext i stället för att kommendera den befintliga Tunnelblick-sessionen.

Vilken ägare du än väljer, definiera vad som händer vid vila, nätverksbyte och utloggning. En hanterare hanterar vanligtvis dessa händelser; en bar process gör det vanligtvis inte, och den resulterande inaktuella rutten eller resolvern läses lätt fel som ett serverfel.

Kontroll fem: hur överlämningen verifieras

Testa den nya ägaren med den gamla inaktiverad och testa sedan den gamla igen om du planerar att behålla den. En privat resurs som svarar i ett arbetsflöde och inte i det andra är bevis om den saknade integrationen, inte om servern.

Vid överlämning till en fristående motor, notera profilens sökväg, binärfilens sökväg, övervakaren, DNS-ägaren och källan till inloggningsuppgifter. Verifiera sedan den privata resursen, vägen till det publika internet och en ren frånkoppling i den ordningen. Om DNS eller rutter finns kvar efter frånkoppling, är den nya ägaren inte klar.

Vid överlämning till Tunnelblick, välj motorn för konfigurationen, aktivera den DNS-integration du avser och ta bort profildirektiv som motarbetar den. Upprepa sedan samma tre kontroller. En anslutning som fungerar men lämnar resolvern ändrad är en misslyckad överlämning, även om tunneln kom upp.

Paketering avgör inte serverns kompatibilitet. Kontrollera tjänstens egna klientkrav och välj motorn ensam bara när du tänker tillhandahålla dess hantering.