OpenVPN mühərriki, yoxsa Tunnelblick: Mac VPN sessiyası kimə aiddir?

Homebrew OpenVPN proqramı quraşdırır; Tunnelblick isə bir və ya bir neçə mühərriki işə salan menecer quraşdırır. Bunlar fərqli qatlamlardır və faydalı sual terminaldan istifadə etməyi sevib-sevmədiyiniz deyil. Sual konfiqurasiyanın, DNS dəyişikliklərinin, etimad məlumatı sorğusunun və sessiya bitəndə təmizləmənin kimə aid olmasıdır. Bu qatlamlar üçün vahid sahib qurğunun proqnozlaşdırıla bilən olmasını təmin edir.

Aşağıdakı beş yoxlamanı sıra ilə keçin. İki sahibi olan ilk yoxlama, insanların OpenVPN özünə yazdığı qəribə yarımqoşulmuş vəziyyətləri yaradan yoxlamadır. Hər yoxlama onu həll edən sübutu adlandırır.

Birinci yoxlama: hansı OpenVPN icra faylı həqiqətən işləyir

Qoşulmuş vəziyyətdə pgrep -fl openvpn əmrini işə salın və tam əmr sətrini oxuyun. Birinci yol həqiqətən işləyən mühərrikdir. Apple Silicon-da Homebrew quraşdırması adətən /opt/homebrew altında yerləşir, Intel Mac-lər isə /usr/local istifadə edir, Tunnelblick isə mühərriki öz tətbiq paketinin içindən işə salır.

Tunnelblick mühərrikləri paketləyir və konfiqurasiyaya birini seçməyə imkan verir. Homebrew formülünü yeniləmək ayrıca ikili faylı dəyişir, Tunnelblick profilinın işə saldığı mühərriki deyil. Davranış fərqini izah etmək üçün versiyaları müqayisə edirsinizsə, paket menecerindəki mühərriki deyil, proses siyahısındakı mühərriki müqayisə edin. Yalnız versiya sətri sizə o mühərrikin hansı profili yüklədiyini deməyəcək.

Kopyalanmış profil iki mühərriki eyni görünən edə bilər, halbuki onlar fərqli faylları oxuyur. Əmr sətrindəki profil yolu işləyən prosesin hansı konfiqurasiyanı yüklədiyini göstərir; redaktorda açıq profil sübut deyil. Davranışı müqayisə etməzdən əvvəl həmin yolu müqayisə edin.

İkinci yoxlama: DNS-i və marşrutları kim dəyişir

Mühərrik OpenVPN-in öz up və down göstərişlərini işlədə bilər, lakin menecer həmin həyat dövrünə sahib ola bilər. Tunnelblick-in ad serveri ayarları onun standart qoşulma və ayrılma skriptlərini idarə edir və bu inteqrasiya aktiv olduqda profildəki rəqib göstərişlər nəzərə alınmaya bilər.

Bu vacibdir, çünki DNS işləyən tunelin ən çox sınıq göründüyü yerdir. Qoşulmuş vəziyyətdə scutil --dns yoxlayın, hansı həlledicinin birinci olduğuna diqqət edin və ayrıldıqdan sonra geri qayıtdığını təsdiqləyin. Profil DNS-i özü qurmağı gözləyirsə, menecer də onu idarə edirsə, ikisindən biri uduzacaq.

İlk qoşulmadan əvvəl DNS-in hansı qatlama aid olduğunu qərarlaşdırın, sonra hər ikisini yerində saxlamaq əvəzinə uduzan göstərişləri silin. Marşrut dəyişiklikləri də eyni qaydaya tabedir: bir sahib, konfiqurasiyada görünən və sənədləşdirilmiş bərpa yolu ilə.

Üçüncü yoxlama: etimad məlumatları haradan gəlir

İnteraktiv sorğu ilə nəzarətsiz prosesin tələbləri fərqlidir. Bir tətbiqin saxladığı etimad məlumatı avtomatik olaraq başqa proses üçün əlçatan deyil və menecerə aid açar zənciri elementi qabıqdan işə salınan ayrıca mühərrik üçün görünməz ola bilər.

Profil üçün etimad məlumatı mənbəyini sadalayın: müştəri sertifikatı və açar, istifadəçi adı və parol sorğusu, yoxsa xarici köməkçinin təqdim etdiyi token. Sonra seçilmiş sahibin, əgər bağlantı yenidən başladılmadan sonra da davam etməlidirsə, insan olmadan həmin mənbəyə çata bildiyini təsdiqləyin.

Dördüncü yoxlama: prosesi kim başladır, nəzarət edir və dayandırır

Ayrıca yerləşdirmə işlək qalmalıdırsa, nəzarətçiyə ehtiyac duyur. Launchd mühərriki girişdə və ya tələb üzrə başlada, qəzadan sonra yenidən işə sala və təmiz dayandıra bilər, lakin bu işi kiminsə yazması və sahib olması lazımdır. Əmri terminalda işlətmək test üçün yararlıdır, pəncərəni bağlayan istifadəçi üçün deyil.

Tunnelblick sahib qalırsa, ikinci mühərrik başlatmaq əvəzinə onun dəstəklənən idarəetmə vasitələrindən istifadə edin. Homebrew ikili faylı, kopyalanmış profil verildikdə, mövcud Tunnelblick sessiyasına əmr vermək əvəzinə öz konfiqurasiyası və inteqrasiya konteksti ilə müstəqil bağlantı açır.

Hansı sahibi seçsəniz də, yuxu, şəbəkə dəyişikliyi və çıxış zamanı nə baş verdiyini müəyyənləşdirin. Menecer adətən bu hadisələri idarə edir; sadə proses isə adətən etmir və yaranan köhnəlmiş marşrut və ya həlledici asanlıqla server nasazlığı kimi oxunur.

Beşinci yoxlama: təhvilin necə yoxlanıldığı

Yeni sahibi köhnə sahib söndürülmüş halda sınaqdan keçirin, sonra köhnə sahibi saxlamağı planlaşdırırsınızsa, onu yenidən sınaqdan keçirin. Bir iş axınında cavab verən, digərində verməyən şəxsi resurs çatışmayan inteqrasiya barədə sübutdur, server barədə deyil.

Ayrıca mühərrikə təhvil üçün profil yolunu, ikili fayl yolunu, nəzarətçini, DNS sahibini və etimad məlumatı mənbəyini qeyd edin. Sonra şəxsi resursu, açıq internet yolunu və təmiz ayrılmanı bu sıra ilə yoxlayın. Əgər ayrıldıqdan sonra DNS və ya marşrutlar qalırsa, yeni sahib hələ bitməyib.

Tunnelblick-ə təhvil üçün konfiqurasiya üçün mühərriki seçin, nəzərdə tutduğunuz DNS inteqrasiyasını aktivləşdirin və ona qarşı çıxan profil göstərişlərini silin. Sonra eyni üç yoxlamanı təkrarlayın. İşləyən, lakin həlledicini dəyişilmiş qoyan bağlantı uğursuz təhvildir, tunel qalxmış olsa belə.

Paketləmə server uyğunluğunu həll etmir. Xidmətin öz müştəri tələblərini yoxlayın və yalnız onun idarəetməsini təmin etmək niyyətindəsinizsə, tək mühərriki seçin.