OpenVPN-motor eller Tunnelblick: hvem ejer Mac VPN-sessionen?

Homebrew installerer et OpenVPN-program; Tunnelblick installerer en manager, der kører en eller flere motorer. Det er forskellige lag, og det nyttige spørgsmål er ikke, om du kan lide at bruge en terminal. Det er, hvem der ejer konfigurationen, DNS-ændringerne, anmodningen om legitimationsoplysninger og oprydningen, når sessionen slutter. Én ejer af de lag er det, der gør opsætningen forudsigelig.

Gå gennem de fem kontroller nedenfor i rækkefølge. Den første, der har to ejere, er den, der skaber de mærkelige halvtilsluttede tilstande, som folk giver OpenVPN selv skylden for. Hver kontrol navngiver det bevis, der afgør den.

Kontrol et: hvilken OpenVPN-binærfil der faktisk kører

Kør pgrep -fl openvpn, mens du er tilsluttet, og læs hele kommandolinjen. Den første sti er den motor, der faktisk kører. På Apple Silicon bor en Homebrew-installation normalt under /opt/homebrew, mens Intel-Macs bruger /usr/local, og Tunnelblick kører en motor inde fra sin egen applikationspakke.

Tunnelblick samler motorer og lader en konfiguration vælge en af dem. Opdatering af Homebrew-formlen ændrer den selvstændige binærfil, ikke den motor, som en Tunnelblick-profil starter. Hvis du sammenligner versioner for at forklare en adfærdsforskel, så sammenlign motoren på proceslisten frem for den i pakkehåndteringen. Versionsstrengen alene fortæller dig ikke, hvilken profil den motor indlæste.

En kopieret profil kan også få to motorer til at se identiske ud, mens de læser forskellige filer. Profilstien på kommandolinjen fortæller dig, hvilken konfiguration den kørende proces indlæste; en profil, der er åben i en editor, er ikke bevis. Sammenlign den sti, før du sammenligner adfærd.

Kontrol to: hvem ændrer DNS og ruter

Motoren kan køre OpenVPNs egne up- og down-direktiver, men manageren kan eje den samme livscyklus. Tunnelblicks navneserverindstillinger styrer dens standard tilslutnings- og afbrydelsesskripter, og når den integration er aktiveret, kan konkurrerende direktiver i profilen blive ignoreret.

Det betyder noget, fordi DNS er der, hvor en fungerende tunnel oftest ser ødelagt ud. Tjek scutil --dns, mens du er tilsluttet, bemærk hvilken resolver der er først, og bekræft, at den vender tilbage efter afbrydelse. Hvis profilen forventer at sætte DNS selv, mens manageren også styrer det, vil en af de to tabe.

Beslut, hvilket lag der ejer DNS, før den første tilslutning, og fjern derefter det tabende direktiv i stedet for at lade begge blive stående. Ruteændringer følger samme regel: én ejer, synlig i konfigurationen, med en dokumenteret gendannelsessti.

Kontrol tre: hvor legitimationsoplysningerne kommer fra

En interaktiv anmodning og en uovervåget proces har forskellige krav. Legitimationsoplysninger, der er gemt af én applikation, er ikke automatisk tilgængelige for en anden proces, og et nøgleringselement, der er knyttet til manageren, kan være usynligt for en selvstændig motor, der startes fra en shell.

List kilden til legitimationsoplysninger for profilen: et klientcertifikat og en nøgle, en anmodning om brugernavn og adgangskode eller et token fra en ekstern hjælper. Bekræft derefter, at den valgte ejer kan nå den kilde uden et menneske, hvis forbindelsen skal overleve en genstart.

Kontrol fire: hvem starter, overvåger og stopper processen

En selvstændig udrulning har brug for en supervisor, hvis den skal blive oppe. Launchd kan starte motoren ved login eller efter behov, genstarte den efter et nedbrud og stoppe den pænt, men nogen skal skrive og eje den opgave. At køre kommandoen i en terminal virker til en test og ikke til en bruger, der lukker vinduet.

Hvis Tunnelblick bliver ejeren, brug dens understøttede kontroller i stedet for at starte en anden motor. Homebrew-binærfilen starter, når den får en kopieret profil, en uafhængig forbindelse med sin egen konfiguration og integrationskontekst i stedet for at kommandere den eksisterende Tunnelblick-session.

Hvilken ejer du end vælger, definer hvad der sker ved dvale, netværksskift og logud. En manager håndterer normalt de hændelser; en bar proces gør det normalt ikke, og den resulterende forældede rute eller resolver er let at fejllæse som en serverfejl.

Kontrol fem: hvordan overdragelsen verificeres

Test den nye ejer med den gamle deaktiveret, og test derefter den gamle igen, hvis du planlægger at beholde den. En privat ressource, der svarer under ét arbejdsflow og ikke under det andet, er bevis om den manglende integration, ikke om serveren.

Ved en overdragelse til en selvstændig motor skal du notere profilens sti, binærfilens sti, supervisoren, DNS-ejeren og kilden til legitimationsoplysninger. Bekræft derefter den private ressource, stien til det offentlige internet og en ren afbrydelse i den rækkefølge. Hvis DNS eller ruter bliver tilbage efter afbrydelse, er den nye ejer ikke færdig.

Ved en overdragelse til Tunnelblick skal du vælge motoren til konfigurationen, aktivere den DNS-integration, du ønsker, og fjerne profildirektiver, der kæmper imod den. Gentag derefter de samme tre kontroller. En forbindelse, der virker, men efterlader resolveren ændret, er en mislykket overdragelse, selv om tunnelen kom op.

Pakning afgør ikke serverkompatibilitet. Tjek tjenestens egne klientkrav, og vælg kun motoren alene, når du har til hensigt at levere dens styring.