OpenVPN motoru mu Tunnelblick mi: Mac VPN oturumunun sahibi kim?

Homebrew bir OpenVPN programı kurar; Tunnelblick bir veya daha fazla motor çalıştıran bir yönetici kurar. Bunlar farklı katmanlar ve faydalı soru terminal kullanmayı sevip sevmediğiniz değil. Yapılandırmanın, DNS değişikliklerinin, kimlik bilgisi isteminin ve oturum bittiğinde temizliğin kime ait olduğudur. Bu katmanlar için tek bir sahip olması kurulumu öngörülebilir kılar.

Aşağıdaki beş denetimi sırayla yapın. İki sahibi olan ilk denetim, insanların OpenVPN’in kendisine yüklediği tuhaf yarı bağlı durumları üreten denetimdir. Her denetim, onu çözen kanıtı adlandırır.

Birinci denetim: hangi OpenVPN ikili dosyası gerçekten çalışıyor

Bağlıyken pgrep -fl openvpn komutunu çalıştırın ve tüm komut satırını okuyun. İlk yol, gerçekten çalışan motordur. Apple Silicon'da Homebrew kurulumu genellikle /opt/homebrew altında bulunur, Intel Mac'ler /usr/local kullanır ve Tunnelblick motoru kendi uygulama paketinin içinden çalıştırır.

Tunnelblick motorları paketler ve yapılandırmanın birini seçmesine izin verir. Homebrew formülünü güncellemek bağımsız ikili dosyayı değiştirir, bir Tunnelblick profilinin başlattığı motoru değil. Davranış farkını açıklamak için sürümleri karşılaştırıyorsanız paket yöneticisindeki motoru değil, süreç listesindeki motoru karşılaştırın. Yalnızca sürüm dizesi o motorun hangi profili yüklediğini söylemez.

Kopyalanmış bir profil, farklı dosyalar okurken iki motoru aynı görünür kılabilir. Komut satırındaki profil yolu, çalışan sürecin hangi yapılandırmayı yüklediğini söyler; bir düzenleyicide açık profil kanıt değildir. Davranışı karşılaştırmadan önce o yolu karşılaştırın.

İkinci denetim: DNS'i ve yolları kim değiştiriyor

Motor OpenVPN'in kendi up ve down yönergelerini çalıştırabilir, ancak yönetici aynı yaşam döngüsüne sahip olabilir. Tunnelblick'in ad sunucusu ayarları standart bağlantı ve bağlantı kesme betiklerini denetler ve bu entegrasyon etkinken profildeki rakip yönergeler yok sayılabilir.

Bu önemlidir çünkü DNS, çalışan bir tünelin en sık bozuk göründüğü yerdir. Bağlıyken scutil --dns komutunu kontrol edin, hangi çözümleyicinin önce geldiğini not edin ve bağlantı kesildikten sonra geri döndüğünü doğrulayın. Profil DNS'i kendisi ayarlamayı beklerken yönetici de onu yönetiyorsa ikisinden biri kaybeder.

İlk bağlantıdan önce DNS'in hangi katmana ait olduğuna karar verin, sonra ikisini de bırakmak yerine kaybeden yönergeyi kaldırın. Yol değişiklikleri aynı kuralı izler: tek sahip, yapılandırmada görünür, belgelenmiş bir geri yükleme yolu ile.

Üçüncü denetim: kimlik bilgileri nereden geliyor

Etkileşimli bir istem ile gözetimsiz bir süreç farklı gereksinimlere sahiptir. Bir uygulamanın kaydettiği kimlik bilgisi otomatik olarak başka bir süreç için kullanılabilir değildir ve yöneticiye sınırlı bir anahtarlık öğesi, kabuktan başlatılan bağımsız bir motor için görünmez olabilir.

Profil için kimlik bilgisi kaynağını listeleyin: bir istemci sertifikası ve anahtarı, kullanıcı adı ve parola istemi ya da harici bir yardımcının sağladığı belirteç. Ardından, bağlantı bir yeniden başlatmayı atlatacaksa seçilen sahibin o kaynağa insan olmadan ulaşabildiğini doğrulayın.

Dördüncü denetim: süreci kim başlatıyor, gözetliyor ve durduruyor

Bağımsız bir kurulum ayakta kalacaksa bir gözetleyiciye ihtiyaç duyar. Launchd motoru oturum açılışında veya istek üzerine başlatabilir, çökmeden sonra yeniden başlatabilir ve temiz biçimde durdurabilir, ancak birinin o işi yazması ve sahibi olması gerekir. Komutu terminalde çalıştırmak bir test için işe yarar, pencereyi kapatan kullanıcı için yaramaz.

Tunnelblick sahip olmaya devam ederse ikinci bir motor başlatmak yerine desteklenen denetimlerini kullanın. Homebrew ikili dosyası, kopyalanmış bir profille, mevcut Tunnelblick oturumuna komuta etmek yerine kendi yapılandırması ve entegrasyon bağlamıyla bağımsız bir bağlantı açar.

Hangi sahibi seçerseniz seçin, uyku, ağ değişikliği ve oturum kapatma sırasında ne olacağını tanımlayın. Yönetici bu olayları genellikle işler; çıplak süreç genellikle işlemez ve ortaya çıkan eski yol veya çözümleyici kolayca sunucu arızası olarak okunur.

Beşinci denetim: devir nasıl doğrulanır

Eski sahip devre dışıyken yeni sahibi test edin, sonra eski sahibi tutmayı planlıyorsanız onu yeniden test edin. Bir iş akışında yanıt veren diğerinde vermeyen özel bir kaynak, eksik entegrasyon hakkında kanıttır, sunucu hakkında değil.

Bağımsız bir motora devir için profil yolunu, ikili dosya yolunu, gözetleyiciyi, DNS sahibini ve kimlik bilgisi kaynağını kaydedin. Ardından bu sırayla özel kaynağı, genel internete giden yolu ve temiz bir bağlantı kesmeyi doğrulayın. Bağlantı kesildikten sonra DNS veya yollar kalırsa, yeni sahip bitmemiştir.

Tunnelblick'e devir için yapılandırmanın motorunu seçin, amaçladığınız DNS entegrasyonunu açın ve ona karşı çıkan profil yönergelerini kaldırın. Ardından aynı üç denetimi yineleyin. Çalışan ancak çözümleyiciyi değişmiş bırakan bir bağlantı, tünel açılmış olsa bile başarısız bir devirdir.

Paketleme sunucu uyumluluğunu belirlemez. Hizmetin kendi istemci gereksinimlerini kontrol edin ve motoru tek başına yalnızca yönetimini sağlamayı düşünüyorsanız seçin.