OpenVPN dzinējs vai Tunnelblick: kam pieder Mac VPN sesija?

Homebrew instalē OpenVPN programmu; Tunnelblick instalē pārvaldnieku, kas palaiž vienu vai vairākus dzinējus. Tie ir dažādi slāņi, un lietderīgais jautājums nav par to, vai jums patīk lietot termināli. Tas ir par to, kam pieder konfigurācija, DNS izmaiņas, akreditācijas datu pieprasījums un tīrīšana sesijas beigās. Viens šo slāņu īpašnieks padara iestatījumu paredzamu.

Izejiet piecus pārbaudījumus zemāk pēc kārtas. Pirmais, kuram ir divi īpašnieki, ir tas, kas rada dīvainos puscauršķērsotos stāvokļus, ko cilvēki piedēvē pašam OpenVPN. Katrs pārbaudījums nosauc pierādījumu, kas to izšķir.

Pirmais pārbaudījums: kura OpenVPN binārā datne patiešām darbojas

Savienojuma laikā palaidiet pgrep -fl openvpn un nolasiet visu komandrindu. Pirmais ceļš ir dzinējs, kas patiešām darbojas. Apple Silicon Homebrew instalācija parasti atrodas zem /opt/homebrew, savukārt Intel Mac izmanto /usr/local, un Tunnelblick palaiž dzinēju no sava lietotnes komplekta iekšienes.

Tunnelblick iekļauj dzinējus un ļauj konfigurācijai izvēlēties vienu. Homebrew formulas atjaunināšana maina atsevišķo bināro datni, nevis dzinēju, ko palaiž Tunnelblick profils. Ja salīdzināt versijas, lai izskaidrotu uzvedības atšķirību, salīdziniet dzinēju procesu sarakstā, nevis to, kas ir pakotņu pārvaldniekā. Tikai versijas virkne nepateiks, kuru profilu šis dzinējs ielādēja.

Kopēts profils var arī likt diviem dzinējiem izskatīties vienādi, kamēr tie lasa dažādas datnes. Profila ceļš komandrindā pateiks, kuru konfigurāciju ielādēja darbojošais process; redaktorā atvērts profils nav pierādījums. Salīdziniet šo ceļu pirms uzvedības salīdzināšanas.

Otrais pārbaudījums: kas maina DNS un maršrutus

Dzinējs var izpildīt paša OpenVPN up un down direktīvas, taču pārvaldnieks var pārvaldīt to pašu dzīves ciklu. Tunnelblick nosaukumu servera iestatījumi kontrolē tā standarta savienošanas un atvienošanas skriptus, un, kad šī integrācija ir ieslēgta, konkurējošās profila direktīvas var tikt ignorētas.

Tas ir svarīgi, jo DNS ir vieta, kur strādājošs tunelis visbiežāk izskatās salūzis. Savienojuma laikā pārbaudiet scutil --dns, ievērojiet, kurš risinātājs ir pirmais, un apstipriniet, ka tas atgriežas pēc atvienošanas. Ja profils paredz pats iestatīt DNS, kamēr pārvaldnieks to arī pārvalda, viens no diviem zaudēs.

Izlemiet, kurš slānis pārvalda DNS pirms pirmā savienojuma, tad noņemiet zaudējošo direktīvu, nevis atstājiet abas. Maršrutu izmaiņas ievēro to pašu noteikumu: viens īpašnieks, redzams konfigurācijā, ar dokumentētu atjaunošanas ceļu.

Trešais pārbaudījums: no kurienes nāk akreditācijas dati

Interaktīvam pieprasījumam un procesam bez uzraudzības ir atšķirīgas prasības. Vienas lietotnes saglabāti akreditācijas dati nav automātiski pieejami citam procesam, un pie pārvaldnieka piesaistīts atslēgu saišķa elements var būt neredzams atsevišķam dzinējam, kas palaists no čaulas.

Uzskaitiet profila akreditācijas datu avotu: klienta sertifikāts un atslēga, lietotājvārda un paroles pieprasījums vai ārēja palīga nodrošināts marķieris. Pēc tam apstipriniet, ka izvēlētais īpašnieks var sasniegt šo avotu bez cilvēka, ja savienojumam jāiztur pārstartēšana.

Ceturtais pārbaudījums: kas palaiž, uzrauga un aptur procesu

Atsevišķai izvietošanai vajadzīgs uzraugs, ja tai jāpaliek aktīvai. Launchd var palaist dzinēju pieteikšanās laikā vai pēc pieprasījuma, restartēt pēc avārijas un apturēt tīri, bet kādam šis uzdevums ir jāuzraksta un jāpieder. Komandas palaišana terminālī der testam, nevis lietotājam, kas aizver logu.

Ja Tunnelblick paliek īpašnieks, izmantojiet tā atbalstītās vadīklas, nevis palaidiet otru dzinēju. Homebrew binārā datne ar kopētu profilu atver neatkarīgu savienojumu ar savu konfigurāciju un integrācijas kontekstu, nevis komandē esošo Tunnelblick sesiju.

Lai kādu īpašnieku izvēlētos, definējiet, kas notiek miega laikā, tīkla maiņā un izlogošanās laikā. Pārvaldnieks parasti apstrādā šos notikumus; kails process parasti ne, un radušais novecojis maršruts vai risinātājs viegli tiek maldīgi nolasīts kā servera kļūda.

Piektais pārbaudījums: kā tiek pārbaudīta nodošana

Pārbaudiet jauno īpašnieku ar izslēgtu veco, pēc tam vēlreiz pārbaudiet veco, ja plānojat to paturēt. Privāts resurs, kas atbild vienā darbplūsmā un ne otrā, ir pierādījums par trūkstošo integrāciju, nevis par serveri.

Nodošanai atsevišķam dzinējam pierakstiet profila ceļu, binārās datnes ceļu, uzraugu, DNS īpašnieku un akreditācijas datu avotu. Pēc tam šajā secībā pārbaudiet privāto resursu, ceļu uz publisko internetu un tīru atvienošanu. Ja pēc atvienošanas paliek DNS vai maršruti, jaunais īpašnieks vēl nav pabeigts.

Nodošanai Tunnelblick izvēlieties konfigurācijas dzinēju, ieslēdziet paredzēto DNS integrāciju un noņemiet profila direktīvas, kas tai pretojas. Pēc tam atkārtojiet tos pašus trīs pārbaudījumus. Savienojums, kas darbojas, bet atstāj mainītu risinātāju, ir neizdevusies nodošana, pat ja tunelis pacēlās.

Iepakojums neatrisina saderību ar serveri. Pārbaudiet paša pakalpojuma klienta prasības un izvēlieties tikai dzinēju vien tad, ja plānojat nodrošināt tā pārvaldību.