Tünel ayakta, öyleyse özel ad neden hâlâ başarısız?
Çalışan bir tünel, istemcinin doğru çözümleyiciye sorduğu anlamına gelmez. Kimin yanıtladığını kontrol edin, sonra yalnızca gerçekten ihtiyaç duyan bölgeyi iletin.
Bağlantıyla ilgili her şey doğru görünüyor: tünel ayakta ve konsol özel uç noktayı gösteriyor, ancak her istek ad çözümlemede başarısız oluyor. Doğal hamle tüneli suçlamaktır, o da genellikle masum çıkar. Sorgu, özel bölge hakkında hiçbir şey bilmeyen bir sunucuya gönderiliyor. Hiçbir yönlendirme değişikliği bu yanıtı değiştirmez, çünkü sorun kime sorulduğudur.
Sorgu hangi çözümleyiciye ulaştı?
Tünele bakmadan önce her bağlantıya ekli çözümleyiciyi bulun. Linux, çözümleyici durum komutuyla bağlantı başına sunucuları gösterir; macOS ise DNS yapılandırma dökümünde kapsamlı çözümleyicileri gösterir. Yanıt hâlâ ev yönlendiricisinden geliyorsa tünel bağlantısına hiç danışılmamıştır.
resolvectl status
scutil --dns | head -40
dig +short internal.example.com
Burada iki aşama karışıyor: bir çözümleyici adresini iten sunucu ve onu etkin bağlantıya kuran istemci. Profil seçeneği içerebilir ve günlük onun geldiğini gösterebilir, ancak işletim sistemi eski sunucuyu kullanmaya devam eder. Günlüğü bağlantının bildirdiğiyle karşılaştırın ve bağlantıya güvenin.
Bulut ağının gerçekten yanıt verdiği bir adres kullanın
Bulut ağları özel adlara genellikle aralığın tabanından iki ilerideki ayrılmış adres üzerinden yanıt verir, bu yüzden 10.0.0.0 ile başlayan bir ağ 10.0.0.2 üzerinde yanıt verir. Bazı sağlayıcılar aralığı bilmeden çalışan bağlantı yerel bir çözümleyici de yayımlar; bu, ağı başka biri kurduğunda yardımcı olur. Aday adresi herhangi birine itmeden önce doğrudan sorgulayın. Çözümleyici olmayan bir adres tam olarak bir güvenlik duvarı düşürmesi gibi görünür, çünkü sorgu hiçbir zaman yanıt alamaz.
Doğrudan sorgu ağın içinden yanıt veriyor ama tünel üzerinden vermiyorsa çözümleyici doğru, iki nokta arasındaki yol değil. Bu sonuç soruşturmayı istemci profiline değil yollara, iletmeye ve erişim kurallarına taşır.
Tünel ad alanını taşımaz
Paketler geçer; adlar geçmez. Her tarafa hangi ad alanının diğerine ait olduğu söylenmelidir ve bu, bölgeyi elinde tutanın sahip olduğu ayrı bir nesnedir. Olağan biçim, tek bir ad alanı için tünel üzerinden erişilebilen bir çözümleyiciye yöneltilmiş iletmedir.
Pratikte her yön kendi kuralına ihtiyaç duyar, çünkü bölgeye sahip olan taraf sorguyu iletmelidir. Her iki yön de sorgunun kaynağının yönlendirilmesini ve izin verilmesini gerektirir; yanıtlayan taraf yanıtları internet yerine tünel üzerinden döndürmelidir. İletmeyi dar tutun, böylece yalnızca özel ad alanı bağlantıya bağlı olsun. Her sorguyu onun üzerinden göndermek, küçük bir bağımlılığı tünel düştüğü anda tam bir kesintiye dönüştürür.
Sınırları sırayla geçin
Etkin bağlantıya kurulu çözümleyiciyi, ardından o çözümleyiciye doğrudan sorguyu, ardından aynı sorguyu uzak taraftan ve son olarak aynı adı kullanan uygulamayı deneyin. Her adım bir sınırı yalıtır, böylece başarısızlık soruşturmayı yeniden başlatmak yerine nereye bakacağınızı söyler. Uygulama başarısız olurken çalışan bir yanıt DNS yerine sertifika güvenine veya bir API ilkesine işaret eder. O arızalar gerçektir ve hiçbir çözümleyici değişikliği onları onarmaz.
Hangi adımın başarısız olduğunu yazın. O tek satır bir sonraki kişinin ihtiyaç duyduğu şeydir ve kaydetmek on saniye sürer.
Zinciri bir sonraki kişinin bulabileceği yerde tutun
İtilen çözümleyiciyi, iletme kuralını, izin verilen sorgu kaynağını ve yanıtlayan uç noktayı tek bir yerde kaydedin. Özel ad yeniden başarısız olduğunda kayıt, tünelin taşınıp taşınmadığını, çözümleyici adresinin değişip değişmediğini veya bir kuralın daraltılıp daraltılmadığını gösterir. O olmadan her olay sıfırdan başlar ve aynı üç tahminle biter.
Kaydı doğru kalacak kadar kısa tutun: dört satır, bir tarih ve her parçanın sahibinin adı. Eski bir kayıt hiç olmamasından daha kötüdür, çünkü yanlış olduğu hâlde yetkili görünür.