openfortivpn sürekli DNS'i eziyor mu? Gerçek sahibini bulun

Bağlantıyı ayağa kalktığı andan itibaren izleyin: istemci kimlik doğrular, pppd pazarlık eder ve ardından bir şey DNS ayarlarını işletim sistemine yazar. Yalnızca VPN'in çözümleyicinizi değiştirdiğini biliyorsanız, bu aşamalardan hangisinin bunu yaptığını henüz bilmiyorsunuz. İkisi bunu yapabilir ve belgelenmiş pppd entegrasyonunu kullanan bir istemcide tek bir aktör gibi görünecek kadar yakın çalışırlar. Yazıcıyı adlandırmak ilk adımdır; yerine geçeni seçmek ikincisidir ve bu, kendi başarısızlık kiplerine sahip ayrı bir karardır.

Aşağıdaki sıra istemciyi dışa doğru izler: bağlantı neyi değiştirdi, hangi anahtar hangi yazıcıyı bastırıyor, kimin devralması gerekiyor ve sonucun yeniden bağlanmaya dayandığını nasıl doğrulayacaksınız. Her aşama farklı bir iz bırakır ve iz, devrin gerçekten gerçekleşip gerçekleşmediğini size söyleyen şeydir.

Bağlantının gerçekte neyi değiştirdiğiyle başlayın

Her zamanki komutunuzla bir kez bağlanın ve çözümlemeyi öncesi ve sonrasıyla karşılaştırın. systemd-resolved çalıştıran bir Linux ana bilgisayarında resolvectl status her bağlantı için DNS sunucularını ve arama alan adlarını yazdırır ve kendi sunucularını taşıyan yeni bir tun veya ppp bağlantısı istemci tarafındaki bir güncellemenin parmak izidir. macOS'te scutil --dns çözümleyici yapılandırmasını uygulamaların ona başvurduğu sırayla gösterir.

Bunu değişmesini beklediğiniz dosyayla karşılaştırın. Bağlantı başına görünümdeki bağlantıya bağlı girdi ve yeniden yazılmış /etc/resolv.conf iki farklı sonuçtur ve ikincisi tamamen başka bir şeyin yönettiği sembolik bir bağlantı olabilir. Çözümleyici adresini, arama alan adlarını ve arayüz adını aynı anda not edin; bunlardan herhangi birindeki değişiklik başka bir yazıcıyı işaret eder. Bu temel çizgi olmadan, sonraki her düzeltme üç bileşenden hangisinin hareket ettiğine dair bir tahmindir.

İki anahtar ve her birinin susturduğu yazıcı

openfortivpn denetleyebildiği her iki yazıcıyı da kapatan bir seçenek parçası belgeler ve her anahtarın kılavuzun aynı ayar saydığı tam olarak yazılmış bir eşdeğeri vardır.

openfortivpn gw.example.com:443 --no-dns --pppd-no-peerdns
# written out in long form
openfortivpn gw.example.com:443 --set-dns=0 --pppd-use-peerdns=0

--no-dns istemcinin ağ geçidinden öğrendiği DNS sunucularını uygulamasını engeller, --pppd-no-peerdns ise pppd'nin eş DNS'ini sisteme itmesini engeller. upstream kılavuzu PPP üzerinden DNS güncellemelerinin istemcinin kendi DNS güncellemeleriyle yarışabileceği konusunda uyarır, bu yüzden iki anahtarın ikisi de parçaya aittir, birinin yeterli sayılması yerine.

Hiçbir anahtar yedek bir çözümleyici adlandırmaz ve hiçbiri bir ağ yöneticisinin, DHCP istemcisinin veya ayrı bir VPN entegrasyonunun sonradan çözümleme yazmasını engellemez. İki yazıcıyı susturmak alanı sahiplenilmiş değil açık bırakır. Üçüncü bir bileşen DNS'i zaten yönetiyorsa parça gözlemleyebileceğiniz hiçbir şeyi değiştirmez; hiçbir şey yönetmiyorsa özel ad çözümlemesinin tek kaynağını az önce kaldırdınız. Bu yalnızca yedek sahibin önce seçildiği ve tek başına test edildiği durumda geçerli bir düzenlemedir.

Bir şeyi devre dışı bırakmadan önce sahibi seçin

Önce iş adlarına yönelik sorguları kimin yanıtlayacağına karar verin, çünkü bu seçim sonraki her şeyi kısıtlar. Mevcut çözümleyiciyi korumak, özel bölgenin istemcinin bulunduğu her yerden zaten erişilebilir olması gerektiği anlamına gelir ve ofis içindeki özel bir çözümleyici tünelin ayağa kalkmasına dayanan bir yol gerektirir. Her sorguyu tek bir iç hizmete göndermek daha keskin bir başarısızlık kipine sahip üçüncü bir politikadır: o hizmete ulaşılamadığında genel adlar özel adlarla birlikte başarısız olur.

Yol sahipliği bilerek ayrı kalır. Yol seçenekleri DNS'i değiştirdiğiniz için gerekli değildir ve bir yedek kurmadan yol kurulumunu kapatmak az önce seçtiğiniz çözümleyiciyi erişilemez hale getirebilir. Yönlendirme tablosunu özellikle çözümleyici adresi için kontrol edin, yalnızca tesadüfen test ettiğiniz uygulama alt ağı için değil.

Çözümlemeyi dosya başına değil bağlantı başına kontrol edin

Kapsamlı veya alan adı başına çözümlemesi olan bir ana bilgisayarda uygulamaların gerçekte ne kullandığının listesi tek bir /etc/resolv.conf değildir, bu yüzden çözümleyicinin durumunu platformun açığa çıkardığı şekilde okuyun.

resolvectl status
resolvectl query vpn.internal.example.com
resolvectl query example.com
ip route get 10.20.0.53

Bağlantı ayağa kalktıktan sonra bir özel ad ve bir genel ad sorun ve hangi bağlantının her birine yanıt verdiğini not edin. VPN bağlantısının alan adı başına arama listesi taşıdığı yerde, özel bir ad doğru çözümlenebilirken genel bir ad hâlâ yerel çözümleyiciye gider ve bu ayrım arıza değil çalışan tasarımdır. Özel sorgu başarısız olursa, DNS'e tekrar dokunmadan önce çözümleyiciye giden yolu inceleyin; başarılı olurken bir uygulama hâlâ başarısız oluyorsa, uygulama kendi önbelleğe alınmış veya ayrı yapılandırılmış çözümleyicisini okuyor olabilir.

Yeniden bağlanın ve bağlantı kesilmiş durumu doğrulayın

Bağlantıyı indirin ve her iki sorguyu yineleyin. Seçilen sahibin kurduğu şey o sahip tarafından kaldırılmalı veya geri yüklenmelidir, susturduğunuz istemci tarafından bırakılmamalıdır. Tünelden daha uzun yaşayan eski bağlantı başına girdi, artık erişilemeyen bir adrese özel sorgular göndermeye devam eder.

Ardından yeniden bağlanın ve aynı üç değeri tekrar okuyun: çözümleyici adresi, arama alan adları, arayüz.

Not ettiğiniz politikayla eşleşiyorlarsa devir tamamlanmıştır ve VPN istemcisi artık yazıcılardan biri değildir. Bağlantı ayağa kalktıktan birkaç saniye sonra bir değer geri kayıyorsa başka bir şey hâlâ yapılandırma uyguluyor ve sonraki adım bir bayrak daha eklemek değil o bileşeni belirlemektir. İstediğiniz son durum olaysızdır: bir sahip, belgelenmiş bir politika ve tünel var olmadan önceki gibi tam olarak çözen bağlantısı kesilmiş bir ana bilgisayar.