OpenVPN variklis ar Tunnelblick: kam priklauso Mac VPN sesija?

Homebrew įdiegia OpenVPN programą; Tunnelblick įdiegia tvarkyklę, kuri paleidžia vieną ar daugiau variklių. Tai skirtingi sluoksniai, ir naudingas klausimas nėra tai, ar jums patinka naudotis terminalu. Jis yra tai, kam priklauso konfigūracija, DNS pakeitimai, prisijungimo duomenų užklausa ir valymas sesijai pasibaigus. Vienas šių sluoksnių savininkas daro sąranką nuspėjamą.

Pereikite penkis patikrinimus žemiau iš eilės. Pirmasis, turintis du savininkus, yra tas, kuris sukuria keistas pusiau prisijungusias būsenas, kurias žmonės priskiria pačiam OpenVPN. Kiekvienas patikrinimas įvardija įrodymą, kuris jį išsprendžia.

Pirmas patikrinimas: kuri OpenVPN dvejetainė byla iš tikrųjų veikia

Prisijungę paleiskite pgrep -fl openvpn ir perskaitykite visą komandų eilutę. Pirmasis kelias yra variklis, kuris iš tikrųjų veikia. Apple Silicon Homebrew diegimas paprastai yra /opt/homebrew kataloge, o Intel Mac naudoja /usr/local, ir Tunnelblick paleidžia variklį iš savo programos paketo vidaus.

Tunnelblick supakuoja variklius ir leidžia konfigūracijai pasirinkti vieną. Homebrew formulės atnaujinimas pakeičia atskirą dvejetainę bylą, o ne variklį, kurį paleidžia Tunnelblick profilis. Jei lyginate versijas, norėdami paaiškinti elgsenos skirtumą, lyginkite variklį procesų sąraše, o ne tą, kuris yra paketų tvarkyklėje. Vien versijos eilutė nepasakys, kokį profilį tas variklis įkėlė.

Nukopijuotas profilis taip pat gali leisti dviem varikliams atrodyti vienodai, nors jie skaito skirtingus failus. Profilio kelias komandų eilutėje pasako, kokią konfigūraciją įkėlė veikiantis procesas; redaktoriuje atidarytas profilis nėra įrodymas. Palyginkite tą kelią prieš lygindami elgseną.

Antras patikrinimas: kas keičia DNS ir maršrutus

Variklis gali vykdyti pačios OpenVPN up ir down direktyvas, tačiau tvarkyklė gali valdyti tą patį gyvavimo ciklą. Tunnelblick vardų serverio nustatymai valdo standartinius prisijungimo ir atsijungimo scenarijus, o kai ši integracija įjungta, konkuruojančios profilio direktyvos gali būti ignoruojamos.

Tai svarbu, nes DNS yra vieta, kur veikiantis tunelis dažniausiai atrodo sugedęs. Prisijungę patikrinkite scutil --dns, atkreipkite dėmesį, kuris resolveris pirmas, ir patvirtinkite, kad jis grįžta po atsijungimo. Jei profilis tikisi pats nustatyti DNS, o tvarkyklė taip pat jį valdo, vienas iš dviejų pralaimės.

Nuspręskite, kuris sluoksnis valdo DNS prieš pirmąjį prisijungimą, tada pašalinkite pralaiminčią direktyvą, o ne palikite abi. Maršrutų pakeitimai laikosi tos pačios taisyklės: vienas savininkas, matomas konfigūracijoje, su dokumentuotu atkūrimo keliu.

Trečias patikrinimas: iš kur atsiranda prisijungimo duomenys

Interaktyvi užklausa ir procesas be priežiūros turi skirtingus reikalavimus. Vienos programos išsaugoti prisijungimo duomenys nėra automatiškai prieinami kitam procesui, o prie tvarkyklės priskirtas raktų saugyklos elementas gali būti nematomas atskiram varikliui, paleistam iš apvalkalo.

Išvardykite profilio prisijungimo duomenų šaltinį: kliento sertifikatas ir raktas, vartotojo vardo ir slaptažodžio užklausa arba išorinio pagalbininko pateiktas žetonas. Tada patvirtinkite, kad pasirinktas savininkas gali pasiekti tą šaltinį be žmogaus, jei ryšys turi išgyventi perkrovimą.

Ketvirtas patikrinimas: kas paleidžia, prižiūri ir sustabdo procesą

Atskiram diegimui reikia prižiūrėtojo, jei jis turi likti veikti. Launchd gali paleisti variklį prisijungus arba pagal poreikį, paleisti iš naujo po gedimo ir tvarkingai sustabdyti, bet kažkas turi parašyti tą užduotį ir jai priklausyti. Komandos vykdymas terminale tinka testui, o ne vartotojui, kuris užveria langą.

Jei Tunnelblick lieka savininku, naudokite jo palaikomus valdiklius, o ne paleiskite antrą variklį. Homebrew dvejetainė byla, gavusi nukopijuotą profilį, atidaro nepriklausomą ryšį su savo konfigūracija ir integracijos kontekstu, o ne komanduoja esamą Tunnelblick sesiją.

Kad ir kokį savininką pasirinktumėte, apibrėžkite, kas vyksta miegant, keičiantis tinklui ir atsijungiant. Tvarkyklė paprastai tvarko tuos įvykius; plikas procesas paprastai ne, o atsiradęs pasenęs maršrutas ar resolveris lengvai palaikomas serverio gedimu.

Penktas patikrinimas: kaip tikrinamas perdavimas

Išbandykite naują savininką su išjungtu senuoju, o paskui dar kartą išbandykite senąjį, jei ketinate jį palikti. Privatus išteklius, kuris atsako viename darbo sraute, o kitame ne, yra trūkstamos integracijos įrodymas, o ne serverio.

Perduodant atskiram varikliui, užsirašykite profilio kelią, dvejetainės bylos kelią, prižiūrėtoją, DNS savininką ir prisijungimo duomenų šaltinį. Tada ta tvarka patikrinkite privatų išteklių, kelią į viešą internetą ir švarų atsijungimą. Jei po atsijungimo lieka DNS ar maršrutai, naujasis savininkas dar nebaigtas.

Perduodant Tunnelblick, pasirinkite konfigūracijos variklį, įjunkite numatomą DNS integraciją ir pašalinkite profilio direktyvas, kurios jai prieštarauja. Tada pakartokite tuos pačius tris patikrinimus. Ryšys, kuris veikia, bet palieka pakeistą resolverį, yra nepavykęs perdavimas, net jei tunelis pakilo.

Pakavimas neišsprendžia suderinamumo su serveriu. Patikrinkite pačios paslaugos kliento reikalavimus ir rinkitės vieną variklį tik tada, kai ketinate patys užtikrinti jo valdymą.