VPN DNS raporu: yeniden üretilebilmesi için neler yer almalı

«DNS bozuk» bir sonuçtur ve bir yardımcının üzerine gidebileceği bir sonuç değildir. Raporun yararlı kısmı hatanın şeklidir: hangi ad, hangi çözümleyici üzerinden, hangi yanıtla. Üç ayrıntı bir şikâyeti yeniden üretilebilir bir şeye dönüştürür ve özel kısımlar yeniden adlandırıldıktan sonra üçü de güvenle paylaşılabilir. Aşağıdakiler, birinin yardım edebilmesi için VPN DNS raporunun gerektirdiği asgaridir.

Bir ad kategorisi, bir hüküm değil

Adın kendisiyle başlayın ve sınıflandırın: genel, iç, kısa, tam nitelikli veya belirli bir sonekle sunulan. Genel adlar çözülürken başarısız olan iç ad, erişilebilirliğe değil çözümleyici seçimine işaret eder. Tüm adlar başarısız olursa bu, çözümleyiciye giden yola işaret eder, ki bu farklı kanıtlarla yapılan farklı bir araştırmadır. Kategori tanıyı taşır ve tam dize gizlenebilir.

Hatanın tünelin açık olmasını gerektirip gerektirmediğini veya tünel kapandıktan sonra mı oluştuğunu söyleyin. Yalnızca VPN etkinken bozulan ad bağlantı başına yapılandırmayı, bağlantı kesildikten sonra bozulan ad ise kalan durumu ima eder. Raporlar bunu genellikle atlar ve sonra ilk önerinin neden yardımcı olmadığını merak eder.

Çözümleyici yolunu kaydedin

Açıkça seçilmiş bir sunucuya gönderilen sorgu ile bir uygulamanın olağan araması farklı deneylerdir. Hatanın hangisinden kaynaklandığını söyleyin, çünkü çalışan bir sunucuya elle yapılan sorgu yalnızca sunucunun çalıştığını kanıtlar. Aşağıdaki komutlar sistem yolunu doğrudan sorudan ayırır.

resolvectl status --no-pager
getent hosts host.internal
dig +short host.internal @10.20.30.53

Durum çıktısı, bağlantı başına sunucuları ve yönlendirme alan adlarını adlandırır, yani split DNS’in kararlaştırıldığı yer. getent çağrısı, nsswitch sırası dahil, uygulamanın izlediği yolu izler. Doğrudan sorgu ikisini de atlar ve tek bir sunucuyu yalıtılmış olarak sınar. Üçünden hangisinin başarısız olduğunu ve hangisinin başarılı olduğunu bildirin, okuyucu artık yolu tahmin etmek zorunda kalmaz.

Kontrollü karşılaştırmayı belirtin

Bir değişkeni değiştirin ve neyin değiştiğini söyleyin. Genel adlar çözülürken iç adların başarısız olması bir seçim sorunudur; her adın zaman aşımına uğraması bir yol sorunudur; özel bir adın genel bir adrese çözülmesi ise yanlış çözümleyiciye sızıntıdır. Bu üçünden ikisinin tünelin açık olup olmamasıyla hiçbir ilgisi yoktur. Tüm sorguların bozuk olduğunu iddia eden bir rapor genellikle hiç çalıştırılmamış bir karşılaştırma içerir.

Çözümlemeyi teslimattan ayırın. Ad çözüldüğünde ve site hâlâ başarısız olduğunda DNS aşaması başarılı olmuştur ve rapor bunu söylemelidir, çünkü sonraki adım çözümleyici değil bir yol veya bir dinleyicidir. Bu tek ayrım, herhangi bir günlük kesitinden daha sık olarak tam bir soru turunu kurtarır.

Ad alanını gizleyin, ilişkileri koruyun

İç adlar, değiştirmeler yapıyı koruduğu sürece değiştirilebilir. Her ayrı sunucuyu ve soneki sabit bir etikete eşleyin ve bu eşlemeyi paylaşılan kopyanın dışında tutun. Her iç ana bilgisayarı aynı yer tutucuyla değiştirmek, raporun ihtiyaç duyduğu kanıtı tam olarak yok eder, çünkü okuyucu artık bir sonekin çözüldüğünü, diğerinin çözülmediğini göremez. Aynı kural adresler için de geçerlidir: önek ilişkilerini koruyun ve politika gerektiriyorsa ana bilgisayar bitlerini değiştirin.

Kaydı doğrulanmış kanaldan gönderin ve tanının asla ihtiyaç duymadığını dışarıda bırakın. Parolalar, özel anahtarlar ve ilgisiz şirket adları bir DNS sorusunun parçası değildir. Okuyucunun ihtiyacı olan şey hata kategorisi, çözümleyici yolu, tam hata ve yaptığınız tek karşılaştırmadır.