OpenVPN-motor eller Tunnelblick: kven eig Mac VPN-økta?

Homebrew installerer eit OpenVPN-program; Tunnelblick installerer ein behandlar som køyrer éin eller fleire motorar. Dette er ulike lag, og det nyttige spørsmålet er ikkje om du likar å bruke ein terminal. Det er kven som eig konfigurasjonen, DNS-endringane, førespurnaden om påloggingsinformasjon og oppryddinga når økta sluttar. Éin eigar av desse laga er det som gjer oppsettet føreseieleg.

Gå gjennom dei fem kontrollane nedanfor i rekkjefølgje. Den første som har to eigarar er den som lagar dei merkelege halvtilkopla tilstandane folk gir OpenVPN sjølv skulda for. Kvar kontroll namngir provet som avgjer han.

Kontroll éin: kva OpenVPN-binærfil som faktisk køyrer

Køyr pgrep -fl openvpn medan du er tilkopla, og les heile kommandolinja. Den første stien er motoren som faktisk køyrer. På Apple Silicon ligg ei Homebrew-installasjon vanlegvis under /opt/homebrew, medan Intel-Macar brukar /usr/local, og Tunnelblick køyrer ein motor frå sin eigen applikasjonspakke.

Tunnelblick samlar motorar og lèt ein konfigurasjon velje éin. Oppdatering av Homebrew-formelen endrar den sjølvstendige binærfilen, ikkje motoren som ein Tunnelblick-profil startar. Viss du samanliknar versjonar for å forklare ein åtferdsforskjell, samanlikn motoren i prosesslista og ikkje den i pakkehandsamaren. Berre versjonsstrengen fortel deg ikkje kva profil den motoren lasta.

Ein kopiert profil kan òg få to motorar til å sjå identiske ut medan dei les ulike filer. Profilstien på kommandolinja fortel kva konfigurasjon den køyrande prosessen lasta; ein profil som er open i ein editor er ikkje prov. Samanlikn den stien før du samanliknar åtferd.

Kontroll to: kven endrar DNS og ruter

Motoren kan køyre OpenVPN sine eigne up- og down-direktiv, men behandlaren kan eige den same livssyklusen. Namneservarinnstillingane til Tunnelblick styrer dei standard tilkopling- og fråkopling-skripta, og når den integrasjonen er aktivert, kan konkurrerande direktiv i profilen bli ignorerte.

Det har noko å seie fordi DNS er der ein fungerande tunnel oftast ser øydelagd ut. Sjekk scutil --dns medan du er tilkopla, legg merke til kva oppløysar som er først, og stadfest at han kjem tilbake etter fråkopling. Viss profilen ventar å setje DNS sjølv medan behandlaren òg styrer det, vil ein av dei to tape.

Avgjer kva lag som eig DNS før den første tilkoplinga, og fjern deretter det tapande direktivet i staden for å la begge stå. Ruteendringar følgjer same regel: éin eigar, synleg i konfigurasjonen, med ein dokumentert attopprettingsveg.

Kontroll tre: kvar påloggingsinformasjonen kjem frå

Ein interaktiv førespurnad og ein prosess utan overvaking har ulike krav. Påloggingsinformasjon som er lagra av éin applikasjon er ikkje automatisk tilgjengeleg for ein annan prosess, og eit nøkkelringselement som er avgrensa til behandlaren kan vere usynleg for ein sjølvstendig motor starta frå eit skal.

List kjelda til påloggingsinformasjon for profilen: eit klient sertifikat og ein nøkkel, ein førespurnad om brukarnamn og passord, eller eit token frå ein ekstern hjelpar. Stadfest deretter at den valde eigaren kan nå den kjelda utan eit menneske viss tilkoplinga skal overleve ein omstart.

Kontroll fire: kven startar, overvaker og stoppar prosessen

Ei sjølvstendig utrulling treng ein overvakar viss ho skal halde seg oppe. Launchd kan starte motoren ved pålogging eller på førespurnad, starte han på nytt etter ein krasj og stoppe han reint, men nokon må skrive og eige den jobben. Å køyre kommandoen i ein terminal fungerer for ein test og ikkje for ein brukar som lukkar vindauget.

Viss Tunnelblick blir verande eigar, bruk dei støtta kontrollane i staden for å starte ein andre motor. Homebrew-binærfilen startar, med ein kopiert profil, ei uavhengig tilkopling med sin eigen konfigurasjon og integrasjonskontekst i staden for å kommandere den eksisterande Tunnelblick-økta.

Uansett kva eigar du vel, definer kva som skjer ved dvale, nettverksbyte og utlogging. Ein behandlar handterer vanlegvis desse hendingane; ein bar prosess gjer det vanlegvis ikkje, og den resulterande utdaterte ruta eller oppløysaren blir lett lesen feil som ein serverfeil.

Kontroll fem: korleis overleveringa blir stadfesta

Test den nye eigaren med den gamle deaktivert, og test deretter den gamle igjen viss du planlegg å behalde han. Ein privat ressurs som svarar under éin arbeidsflyt og ikkje under den andre, er prov om den manglande integrasjonen, ikkje om serveren.

Ved overlevering til ein sjølvstendig motor, noter profilbanen, binærbanen, overvakaren, DNS-eigaren og kjelda til påloggingsinformasjon. Stadfest deretter den private ressursen, banen til det offentlege internettet og ei rein fråkopling i den rekkjefølgja. Viss DNS eller ruter blir verande etter fråkopling, er den nye eigaren ikkje ferdig.

Ved overlevering til Tunnelblick, vel motoren for konfigurasjonen, aktiver DNS-integrasjonen du ønskjer og fjern profildirektiv som kjempar mot han. Gjenta deretter dei same tre kontrollane. Ei tilkopling som fungerer, men lèt oppløysaren stå endra, er ei mislukka overlevering, sjølv om tunnelen kom opp.

Pakking avgjer ikkje serverkompatibilitet. Sjekk dei eigne klientkrava til tenesta, og vel motoren åleine berre når du har tenkt å levere styringa av han.