OpenVPN-moottori vai Tunnelblick: kuka omistaa Macin VPN-istunnon?

Homebrew asentaa OpenVPN-ohjelman; Tunnelblick asentaa hallinnan, joka ajaa yhtä tai useampaa moottoria. Ne ovat eri kerroksia, eikä hyödyllinen kysymys ole, pidätkö päätteen käytöstä. Vaan kuka omistaa määrityksen, DNS-muutokset, tunnistetietojen kyselyn ja siivouksen istunnon päättyessä. Yksi omistaja näille kerroksille tekee asetuksesta ennustettavan.

Käy alla olevat viisi tarkistusta läpi järjestyksessä. Ensimmäinen, jolla on kaksi omistajaa, tuottaa ne oudot puoliksi yhdistetyt tilat, jotka ihmiset laittavat OpenVPN:n itsensä syyksi. Jokainen tarkistus nimeää todisteen, joka ratkaisee sen.

Tarkistus yksi: mikä OpenVPN:n binaaritiedosto todella pyörii

Suorita pgrep -fl openvpn yhteyden aikana ja lue koko komentorivi. Ensimmäinen polku on moottori, joka todella pyörii. Apple Siliconilla Homebrew-asennus sijaitsee yleensä polun /opt/homebrew alla, kun taas Intel Macit käyttävät polkua /usr/local, ja Tunnelblick ajaa moottoria oman sovelluspakettinsa sisältä.

Tunnelblick kokoaa moottorit ja antaa määrityksen valita yhden. Homebrew-kaavan päivittäminen muuttaa erillistä binaaritiedostoa, ei sitä moottoria, jonka Tunnelblick-profiili käynnistää. Jos vertailet versioita selittääksesi käyttäytymiseroa, vertaile prosessiluettelon moottoria äläkä paketinhallinnan moottoria. Pelkkä versiomerkkijono ei kerro, minkä profiilin se moottori latasi.

Kopioitu profiili voi myös saada kaksi moottoria näyttämään samalta, vaikka ne lukevat eri tiedostoja. Komentorivin profiilipolku kertoo, minkä määrityksen käynnissä oleva prosessi latasi; editorissa avoinna oleva profiili ei ole todiste. Vertaa tätä polkua ennen kuin vertaat käyttäytymistä.

Tarkistus kaksi: kuka muuttaa DNS:n ja reitit

Moottori voi ajaa OpenVPN:n omia up- ja down-direktiivejä, mutta hallinta voi omistaa saman elinkaaren. Tunnelblickin nimipalvelinasetukset ohjaavat sen vakioita yhdistämis- ja katkaisuskriptejä, ja kun tämä integraatio on käytössä, profiilin kilpailevat direktiivit voidaan jättää huomiotta.

Sillä on väliä, koska DNS on paikka, jossa toimiva tunneli näyttää useimmin rikkinäiseltä. Tarkista scutil --dns yhteyden aikana, huomaa mikä ratkaisin on ensimmäinen ja varmista, että se palaa katkaisun jälkeen. Jos profiili odottaa asettavansa DNS:n itse ja hallinta hoitaa sitä myös, toinen kahdesta häviää.

Päätä, mikä kerros omistaa DNS:n ennen ensimmäistä yhteyttä, ja poista sitten häviävä direktiivi sen sijaan, että jättäisit molemmat paikoilleen. Reittimuutokset noudattavat samaa sääntöä: yksi omistaja, näkyvissä määrityksessä, dokumentoidulla palautuspolulla.

Tarkistus kolme: mistä tunnistetiedot tulevat

Vuorovaikutteisella kyselyllä ja valvomattomalla prosessilla on eri vaatimukset. Yhden sovelluksen tallentama tunnistetieto ei ole automaattisesti toisen prosessin käytettävissä, ja hallintaan rajattu avainnipun kohde voi olla näkymätön kuoresta käynnistetylle erilliselle moottorille.

Luettele profiilin tunnistetietojen lähde: asiakasvarmenne ja avain, käyttäjänimen ja salasanan kysely tai ulkoisen apurin toimittama token. Vahvista sitten, että valittu omistaja pääsee tähän lähteeseen ilman ihmistä, jos yhteyden on tarkoitus kestää uudelleenkäynnistys.

Tarkistus neljä: kuka käynnistää, valvoo ja pysäyttää prosessin

Erillinen käyttöönotto tarvitsee valvojan, jos sen on tarkoitus pysyä käynnissä. Launchd voi käynnistää moottorin kirjautuessa tai pyynnöstä, käynnistää sen uudelleen kaatumisen jälkeen ja pysäyttää sen siististi, mutta jonkun on kirjoitettava ja omistettava se työ. Komennon ajaminen päätteessä toimii testiin eikä käyttäjälle, joka sulkee ikkunan.

Jos Tunnelblick jää omistajaksi, käytä sen tuettuja säätimiä toisen moottorin käynnistämisen sijaan. Homebrew-binääri käynnistää kopioidulla profiililla itsenäisen yhteyden omalla määrityksellään ja integraatiokontekstillaan sen sijaan, että komentaisi olemassa olevaa Tunnelblick-istuntoa.

Minkä omistajan valitsetkin, määrittele, mitä tapahtuu unessa, verkon vaihtuessa ja uloskirjautuessa. Hallinta hoitaa yleensä ne tapahtumat; paljas prosessi yleensä ei, ja syntyvä vanhentunut reitti tai ratkaisin on helppo tulkita palvelinvirheeksi.

Tarkistus viisi: miten siirto varmennetaan

Testaa uutta omistajaa vanhan ollessa pois päältä ja testaa sitten vanhaa uudelleen, jos aiot pitää sen. Yksityinen resurssi, joka vastaa yhdessä työnkulussa eikä toisessa, on todiste puuttuvasta integraatiosta, ei palvelimesta.

Kun siirrät erilliselle moottorille, kirjaa profiilin polku, binaaritiedoston polku, valvoja, DNS:n omistaja ja tunnistetietojen lähde. Tarkista sitten tässä järjestyksessä yksityinen resurssi, polku julkiseen internetiin ja puhdas katkaisu. Jos DNS tai reitit jäävät katkaisun jälkeen, uusi omistaja ei ole valmis.

Kun siirrät Tunnelblickille, valitse määritykselle moottori, ota käyttöön aikomasi DNS-integraatio ja poista profiilin direktiivit, jotka vastustavat sitä. Toista sitten samat kolme tarkistusta. Yhteys, joka toimii mutta jättää ratkaisimen muutetuksi, on epäonnistunut siirto, vaikka tunneli nousi.

Paketointi ei ratkaise palvelinyhteensopivuutta. Tarkista palvelun omat asiakasvaatimukset ja valitse pelkkä moottori vain silloin, kun aiot itse huolehtia sen hallinnasta.