OpenVPN DNS gönderir, ama çözümleyiciniz onu hiç görmeyebilir

İstemci günlüğü gönderilen DNS sunucusunu gösteriyor, tünel bağlı ve dahili bir ad hâlâ hiçbir şeye çözümlenmiyor. Göndermenin kendisinde bozuk bir şey yok. Seçenek geldi ve işletim sisteminin çözümleyicisi onu hiç kullanmadı, çünkü çoğu Unix istemcisinde OpenVPN değeri teslim eder ve uygulamayı platforma bırakır.

Belirti: günlük DNS gösteriyor ve adlar hâlâ başarısız

OpenVPN dhcp-option DNS ve alan adı bilgisini taşır, istemci de ne aldığını kaydeder. Bazı uygulamalarda istemci bu ayarları kendi içinde uygular; bazılarında ise bir entegrasyon betiğine veya ağ hizmetine sunmak üzere dışa aktarır. Günlük satırı hikâyenin yalnızca ilk yarısını anlatır. İkinci yarı istemcinin kontrol etmediği bir yerde gerçekleşir. Hata genellikle orada yaşar.

Bu yüzden bağlı bir tünel ile başarısız bir dahili ad bu kadar sık bir arada bulunur. Değer var, tüketici eksik ya da yanlış yapılandırılmış ve çözümleyici sessizce bağlantıdan önce kullandığı genel sunucuyu kullanmaya devam eder.

Alınmış olması uygulanmış olması değildir

İstemci, sistem çözümleyicisi hâlâ başka bir hizmete aitken gönderilen bir DNS değerini kaydedebilir. Tarayıcının, sistem çözümleyicisini tamamen atlayan kendi şifreli DNS politikası da olabilir; bu, bir uygulamanın dahili adları çözümlediği diğerinin çözümlemediği akılda kalıcı durumu yaratır.

Her Unix istemcisinin aynı dosyayı yeniden yazdığını varsaymak yerine uygulamanın desteklediği entegrasyonu kontrol edin. Bu varsayım, insanların hiçbir şeyin okumadığı bir çözümleyici yapılandırmasını düzenlemesinin nedenidir.

Çözümleyicinin sahibini platforma göre bulun

Windows'ta ad çözümleme ilkesi tablosu belirli son ekleri belirli sunuculara yönlendirebilir ve VPN istemcisi oraya kurallar kurabilir. Yalnızca bağdaştırıcının DNS listesini değil, ilkeyi kontrol edin. Linux'ta yapılandırma NetworkManager veya systemd-resolved'a ait olabilir ve hangisinin sahip olduğu, yeniden bağlanmanın neyi koruyacağını belirler.

Gerçek durumu sorguları gerçekten yanıtlayan araçla okuyun: systemd-resolved ana bilgisayarında resolvectl query internal.example.net veya platformun eşdeğeri. Ardından bu yanıtı istemci günlüğünün gönderdiğini iddia ettiği DNS sunucusuyla karşılaştırın.

Çözümleyici ayarlarını eşgüdüm olmadan üzerine yazan birden çok hizmeti çalıştırmaktan kaçının. İki sahip, aralıklı görünen bir sonuç üretir ve her yeniden bağlanma onu rastgele düzeltiyor ya da bozuyor gibi görünür.

Betikler ve foreign_option

OpenVPN gönderilen seçenekleri foreign_option_N adlı değişkenler aracılığıyla betiklere aktarır ve bir betik bunları çözümleyici komutlarına çevirebilir. Bu düzen desteklenen bir entegrasyondur, otomatik bir davranış değildir ve istemcide kurulup çağrılması gerekir.

Bir betiğe güveniyorsanız çalışmasını ve çıkış durumunu günlüğe kaydedin. Çalışan ama sessizce başarısız olan bir betik, betik yokmuş gibi aynı belirtiyi bırakır ve yapılandırma eksiksiz göründüğü için fark edilmesi daha zordur. Betiğin çıktısını kontrol edin, betik dosyasını değil. Var olan bir dosya, çalışmış bir betik değildir.

Günlüğü değil adı test edin

Bağlandıktan sonra istemciden yalnızca dahili bir ana bilgisayar adı sorun, sonra genel bir ad sorun, sonra hangi sunucunun yanıt verdiğini kontrol edin. Çalışan bir kurulumda iki yanıt farklı yerlerden gelir ve ikisi de tasarımla uyuşmalıdır.

Ad çözümleniyor ama hizmet başarısız oluyorsa DNS'i yeniden değiştirmek yerine yönlendirme ve uygulama erişimine geçin. OpenVPN kılavuzu dhcp-option ve betik ortamını belgeler; başka bir çözümleyici dosyasını düzenlemeden önce istemcinizin neyi uygulaması gerektiğini doğrulamak için kullanın.