OpenVPN-motor eller Tunnelblick: hvem eier Mac VPN-økten?

Homebrew installerer et OpenVPN-program; Tunnelblick installerer en behandler som kjører én eller flere motorer. Det er forskjellige lag, og det nyttige spørsmålet er ikke om du liker å bruke en terminal. Det er hvem som eier konfigurasjonen, DNS-endringene, forespørselen om påloggingsinformasjon og oppryddingen når økten slutter. Én eier av disse lagene er det som gjør oppsettet forutsigbart.

Gå gjennom de fem kontrollene nedenfor i rekkefølge. Den første som har to eiere er den som lager de merkelige halvtilkoblede tilstandene folk gir OpenVPN selv skylden for. Hver kontroll navngir beviset som avgjør den.

Kontroll én: hvilken OpenVPN-binærfil som faktisk kjører

Kjør pgrep -fl openvpn mens du er tilkoblet, og les hele kommandolinjen. Den første banen er motoren som faktisk kjører. På Apple Silicon ligger en Homebrew-installasjon vanligvis under /opt/homebrew, mens Intel-Macer bruker /usr/local, og Tunnelblick kjører en motor fra sin egen applikasjonspakke.

Tunnelblick samler motorer og lar en konfigurasjon velge én. Oppdatering av Homebrew-formelen endrer den selvstendige binærfilen, ikke motoren som en Tunnelblick-profil starter. Hvis du sammenligner versjoner for å forklare en atferdsforskjell, sammenlign motoren i prosesslisten og ikke den i pakkebehandleren. Bare versjonsstrengen forteller deg ikke hvilken profil den motoren lastet.

En kopiert profil kan også få to motorer til å se identiske ut mens de leser forskjellige filer. Profilbanen på kommandolinjen forteller hvilken konfigurasjon den kjørende prosessen lastet; en profil som er åpen i en editor er ikke bevis. Sammenlign den banen før du sammenligner atferd.

Kontroll to: hvem endrer DNS og ruter

Motoren kan kjøre OpenVPNs egne up- og down-direktiver, men behandleren kan eie den samme livssyklusen. Tunnelblicks navneserverinnstillinger styrer standard tilkoblings- og frakoblingsskriptene, og når den integrasjonen er aktivert, kan konkurrerende direktiver i profilen bli ignorert.

Det betyr noe fordi DNS er der en fungerende tunnel oftest ser ødelagt ut. Sjekk scutil --dns mens du er tilkoblet, legg merke til hvilken oppløser som er først, og bekreft at den kommer tilbake etter frakobling. Hvis profilen forventer å sette DNS selv mens behandleren også styrer det, vil en av de to tape.

Bestem hvilket lag som eier DNS før den første tilkoblingen, og fjern deretter det tapende direktivet i stedet for å la begge stå. Ruteendringer følger samme regel: én eier, synlig i konfigurasjonen, med en dokumentert gjenopprettingsbane.

Kontroll tre: hvor påloggingsinformasjonen kommer fra

En interaktiv forespørsel og en prosess uten overvåking har forskjellige krav. Påloggingsinformasjon som er lagret av én applikasjon, er ikke automatisk tilgjengelig for en annen prosess, og et nøkkelringselement som er begrenset til behandleren, kan være usynlig for en selvstendig motor startet fra et skall.

List kilden til påloggingsinformasjon for profilen: et klient sertifikat og en nøkkel, en forespørsel om brukernavn og passord, eller et token fra en ekstern hjelper. Bekreft deretter at den valgte eieren kan nå den kilden uten et menneske hvis tilkoblingen skal overleve en omstart.

Kontroll fire: hvem starter, overvåker og stopper prosessen

En selvstendig utrulling trenger en overvåker hvis den skal holde seg oppe. Launchd kan starte motoren ved pålogging eller på forespørsel, starte den på nytt etter en krasj og stoppe den rent, men noen må skrive og eie den jobben. Å kjøre kommandoen i en terminal fungerer for en test og ikke for en bruker som lukker vinduet.

Hvis Tunnelblick blir værende som eier, bruk de støttede kontrollene i stedet for å starte en andre motor. Homebrew-binærfilen starter, med en kopiert profil, en uavhengig tilkobling med sin egen konfigurasjon og integrasjonskontekst i stedet for å kommandere den eksisterende Tunnelblick-økten.

Uansett hvilken eier du velger, definer hva som skjer ved dvale, nettverksbytte og utlogging. En behandler håndterer vanligvis disse hendelsene; en bar prosess gjør det vanligvis ikke, og den resulterende utdaterte ruten eller oppløseren leses lett feil som en serverfeil.

Kontroll fem: hvordan overleveringen verifiseres

Test den nye eieren med den gamle deaktivert, og test deretter den gamle igjen hvis du planlegger å beholde den. En privat ressurs som svarer under én arbeidsflyt og ikke under den andre, er bevis om den manglende integrasjonen, ikke om serveren.

Ved overlevering til en selvstendig motor, noter profilbanen, binærbanen, overvåkeren, DNS-eieren og kilden til påloggingsinformasjon. Bekreft deretter den private ressursen, banen til det offentlige internettet og en ren frakobling i den rekkefølgen. Hvis DNS eller ruter blir værende etter frakobling, er den nye eieren ikke ferdig.

Ved overlevering til Tunnelblick, velg motoren for konfigurasjonen, aktiver DNS-integrasjonen du ønsker og fjern profildirektiver som kjemper mot den. Gjenta deretter de samme tre kontrollene. En tilkobling som fungerer, men lar oppløseren stå endret, er en mislykket overlevering, selv om tunnelen kom opp.

Pakking avgjør ikke serverkompatibilitet. Sjekk tjenestens egne klientkrav, og velg motoren alene bare når du har tenkt å levere styringen av den.