Motor OpenVPN sau Tunnelblick: cine deține sesiunea VPN a Mac-ului?

Homebrew instalează un program OpenVPN; Tunnelblick instalează un manager care rulează unul sau mai multe motoare. Acestea sunt straturi diferite, iar întrebarea utilă nu este dacă îți place să folosești un terminal. Ci cine deține configurația, modificările DNS, solicitarea credențialelor și curățarea la sfârșitul sesiunii. Un singur proprietar pentru aceste straturi face configurarea previzibilă.

Parcurge cele cinci verificări de mai jos în ordine. Prima care are doi proprietari este cea care produce stările ciudate pe jumătate conectate pe care oamenii le pun pe seama OpenVPN însuși. Fiecare verificare numește dovada care o decide.

Verificarea unu: care binar OpenVPN rulează de fapt

Rulează pgrep -fl openvpn cât timp ești conectat și citește întreaga linie de comandă. Prima cale este motorul care rulează de fapt. Pe Apple Silicon o instalare Homebrew se află de obicei sub /opt/homebrew, în timp ce Mac-urile Intel folosesc /usr/local, iar Tunnelblick rulează un motor din interiorul propriului pachet de aplicație.

Tunnelblick include motoare și permite unei configurații să aleagă unul. Actualizarea formulei Homebrew schimbă binarul independent, nu motorul pe care îl pornește un profil Tunnelblick. Dacă compari versiuni pentru a explica o diferență de comportament, compară motorul din lista de procese, nu pe cel din managerul de pachete. Doar șirul versiunii nu îți va spune ce profil a încărcat acel motor.

Un profil copiat poate face doi motori să pară identici în timp ce citesc fișiere diferite. Calea profilului din linia de comandă îți spune ce configurație a încărcat procesul care rulează; un profil deschis într-un editor nu este o dovadă. Compară acea cale înainte de a compara comportamentul.

Verificarea doi: cine schimbă DNS-ul și rutele

Motorul poate executa propriile directive up și down ale OpenVPN, dar managerul poate deține același ciclu de viață. Setările de server de nume ale Tunnelblick controlează scripturile standard de conectare și deconectare, iar când acea integrare este activă, directivele concurente din profil pot fi ignorate.

Asta contează pentru că DNS-ul este locul unde un tunel funcțional pare stricat cel mai des. Verifică scutil --dns cât timp ești conectat, notează care resolver este primul și confirmă că revine după deconectare. Dacă profilul se așteaptă să seteze DNS-ul singur în timp ce managerul îl administrează și el, unul dintre cei doi va pierde.

Decide ce strat deține DNS-ul înainte de prima conectare, apoi elimină directiva care pierde în loc să le lași pe amândouă. Modificările de rută urmează aceeași regulă: un singur proprietar, vizibil în configurație, cu o cale de restaurare documentată.

Verificarea trei: de unde vin credențialele

O solicitare interactivă și un proces nesupravegheat au cerințe diferite. O credențială salvată de o aplicație nu este automat disponibilă pentru alt proces, iar un element din breloc limitat la manager poate fi invizibil pentru un motor autonom pornit dintr-un shell.

Enumeră sursa credențialelor pentru profil: un certificat și o cheie de client, o solicitare de nume de utilizator și parolă, sau un token furnizat de un ajutor extern. Apoi confirmă că proprietarul ales poate ajunge la acea sursă fără o persoană dacă conexiunea trebuie să supraviețuiască unei reporniri.

Verificarea patru: cine pornește, supraveghează și oprește procesul

O implementare autonomă are nevoie de un supraveghetor dacă trebuie să rămână pornită. Launchd poate porni motorul la autentificare sau la cerere, îl poate reporni după un accident și îl poate opri curat, dar cineva trebuie să scrie și să dețină acea sarcină. Rularea comenzii într-un terminal funcționează pentru un test și nu pentru un utilizator care închide fereastra.

Dacă Tunnelblick rămâne proprietar, folosește comenzile sale acceptate în loc să pornești un al doilea motor. Binarul Homebrew, primind un profil copiat, deschide o conexiune independentă cu propria configurație și propriul context de integrare în loc să comande sesiunea Tunnelblick existentă.

Indiferent de proprietarul ales, definește ce se întâmplă la repaus, la schimbarea rețelei și la deconectare. Un manager tratează de obicei aceste evenimente; un proces gol de obicei nu, iar ruta sau resolverul învechite rezultate sunt ușor de interpretat greșit ca o defecțiune a serverului.

Verificarea cinci: cum se verifică predarea

Testează noul proprietar cu cel vechi dezactivat, apoi testează din nou cel vechi dacă intenționezi să îl păstrezi. O resursă privată care răspunde într-un flux de lucru și nu în celălalt este o dovadă despre integrarea lipsă, nu despre server.

Pentru o predare către un motor autonom, notează calea profilului, calea binarului, supraveghetorul, proprietarul DNS-ului și sursa credențialelor. Apoi verifică resursa privată, calea către internetul public și o deconectare curată în această ordine. Dacă DNS-ul sau rutele rămân după deconectare, noul proprietar nu a terminat.

Pentru o predare către Tunnelblick, selectează motorul pentru configurație, activează integrarea DNS dorită și elimină directivele profilului care i se opun. Apoi repetă aceleași trei verificări. O conexiune care funcționează dar lasă resolverul modificat este o predare eșuată, chiar dacă tunelul a urcat.

Ambalarea nu rezolvă compatibilitatea cu serverul. Verifică cerințele proprii de client ale serviciului și alege doar motorul doar atunci când intenționezi să îi asiguri administrarea.