OpenVPN-engine of Tunnelblick: wie bezit de Mac VPN-sessie?

Homebrew installeert een OpenVPN-programma; Tunnelblick installeert een beheerder die een of meer engines draait. Dat zijn verschillende lagen, en de nuttige vraag is niet of u graag een terminal gebruikt. Het is wie de configuratie, de DNS-wijzigingen, de vraag om inloggegevens en het opruimen aan het einde van de sessie bezit. Eén eigenaar voor die lagen is wat de opzet voorspelbaar maakt.

Doorloop de vijf controles hieronder in volgorde. De eerste met twee eigenaren is degene die de vreemde half-verbonden toestanden veroorzaakt die mensen OpenVPN zelf verwijten. Elke controle noemt het bewijs dat hem beslecht.

Controle één: welk OpenVPN-binair bestand echt draait

Voer pgrep -fl openvpn uit terwijl u verbonden bent en lees de volledige opdrachtregel. Het eerste pad is de engine die echt draait. Op Apple Silicon staat een Homebrew-installatie meestal onder /opt/homebrew, terwijl Intel-Macs /usr/local gebruiken, en Tunnelblick draait een engine vanuit zijn eigen toepassingspakket.

Tunnelblick bundelt engines en laat een configuratie er één kiezen. Het bijwerken van de Homebrew-formule verandert het zelfstandige binaire bestand, niet de engine die een Tunnelblick-profiel start. Als u versies vergelijkt om een gedragsverschil te verklaren, vergelijk dan de engine in de processenlijst en niet die in de pakketbeheerder. De versiereeks alleen vertelt u niet welk profiel die engine heeft geladen.

Een gekopieerd profiel kan ook twee engines identiek laten lijken terwijl ze verschillende bestanden lezen. Het profielpad in de opdrachtregel vertelt welke configuratie het draaiende proces heeft geladen; een profiel dat in een editor openstaat is geen bewijs. Vergelijk dat pad voordat u gedrag vergelijkt.

Controle twee: wie DNS en routes wijzigt

De engine kan OpenVPN's eigen up- en down-directieven uitvoeren, maar de beheerder kan dezelfde levenscyclus bezitten. De nameserver-instellingen van Tunnelblick beheren de standaard verbindings- en verbrekingsscripts, en wanneer die integratie is ingeschakeld, kunnen concurrerende directieven in het profiel worden genegeerd.

Dat is belangrijk omdat DNS de plek is waar een werkende tunnel het vaakst kapot lijkt. Controleer scutil --dns terwijl u verbonden bent, noteer welke resolver de eerste is en bevestig dat hij na het verbreken terugkomt. Als het profiel verwacht DNS zelf in te stellen terwijl de beheerder het ook beheert, verliest een van de twee.

Bepaal welke laag DNS bezit vóór de eerste verbinding en verwijder daarna het verliezende directief in plaats van beide te laten staan. Routewijzigingen volgen dezelfde regel: één eigenaar, zichtbaar in de configuratie, met een gedocumenteerd herstelpad.

Controle drie: waar de inloggegevens vandaan komen

Een interactieve vraag en een proces zonder toezicht hebben verschillende eisen. Inloggegevens die door de ene toepassing zijn opgeslagen, zijn niet automatisch beschikbaar voor een ander proces, en een sleutelhanger-item dat aan de beheerder is gebonden kan onzichtbaar zijn voor een zelfstandige engine die vanuit een shell is gestart.

Noem de bron van inloggegevens voor het profiel: een clientcertificaat en sleutel, een vraag om gebruikersnaam en wachtwoord, of een token van een externe helper. Bevestig daarna dat de gekozen eigenaar die bron zonder mens kan bereiken als de verbinding een herstart moet overleven.

Controle vier: wie het proces start, bewaakt en stopt

Een zelfstandige uitrol heeft een toezichthouder nodig als hij moet blijven draaien. Launchd kan de engine bij het inloggen of op verzoek starten, na een crash opnieuw starten en netjes stoppen, maar iemand moet die taak schrijven en bezitten. De opdracht in een terminal uitvoeren werkt voor een test en niet voor een gebruiker die het venster sluit.

Als Tunnelblick eigenaar blijft, gebruik dan de ondersteunde bedieningselementen in plaats van een tweede engine te starten. Het Homebrew-binaire bestand opent met een gekopieerd profiel een onafhankelijke verbinding met zijn eigen configuratie en integratiecontext in plaats van de bestaande Tunnelblick-sessie te besturen.

Welke eigenaar u ook kiest, definieer wat er gebeurt bij slaap, netwerkwijziging en uitloggen. Een beheerder handelt die gebeurtenissen meestal af; een kaal proces meestal niet, en de resulterende verouderde route of resolver wordt gemakkelijk verkeerd gelezen als een serverfout.

Controle vijf: hoe de overdracht wordt geverifieerd

Test de nieuwe eigenaar met de oude uitgeschakeld en test de oude daarna opnieuw als u die wilt houden. Een privébron die binnen de ene werkstroom antwoordt en binnen de andere niet, is bewijs over de ontbrekende integratie, niet over de server.

Noteer voor een overdracht naar een zelfstandige engine het profielpad, het pad van het binaire bestand, de toezichthouder, de DNS-eigenaar en de bron van inloggegevens. Verifieer daarna de privébron, het pad naar het openbare internet en een schone verbreking in die volgorde. Als DNS of routes na het verbreken blijven bestaan, is de nieuwe eigenaar niet klaar.

Selecteer voor een overdracht naar Tunnelblick de engine voor de configuratie, schakel de beoogde DNS-integratie in en verwijder profieldirectieven die daartegen vechten. Herhaal daarna dezelfde drie controles. Een verbinding die werkt maar de resolver gewijzigd achterlaat, is een mislukte overdracht, ook als de tunnel omhoogkwam.

Verpakking beslist niet over servercompatibiliteit. Controleer de eigen cliëntvereisten van de dienst en kies de engine alleen wanneer u van plan bent het beheer ervan te leveren.