VPN uç nokta adı ile özel hizmet adı: iki sahip

İki ad aynı şubeyi tanımlayabilir ve tamamen farklı soruları yanıtlayabilir. vpn.branch.example uzak bir eşe VPN uç noktasının nerede bulunacağını söyler ve herhangi bir tünel var olmadan önce çözümlenmelidir. inventory.branch.example yetkili bir kullanıcıya özel bir uygulamanın nerede yaşadığını söyler ve ancak tünel kurulduktan sonra önemlidir. Birini sürdürmek diğeri için hiçbir şey yapmaz.

Herhangi birinde hata ayıklamadan önce iki kaydı da adlandırın

İkisini de sahipleriyle birlikte yazın. Uç nokta için genel adresi kimin güncellediğini ve VPN istemcisinin yanıtını nasıl yenilediğini kaydedin. Hizmet için özel adresin sahibini, kaydı hangi bölgenin tuttuğunu ve hangi çözümleyicilerin onun adına yanıt vermesi gerektiğini kaydedin.

Bu kısa liste, bu alandaki en yaygın yanlış tanıyı önler: tamamen kendi içinde yaşayan bir kaydı onarmak için çalışan bir şube tünelini yeniden başlatmak. Tünel, hizmet adı için taşıma yoludur; onun otoritesi değildir.

Bir değişiklik önerildiğinde, iki kayıttan hangisine dokunduğunu sorun. Kimse yanıt veremiyorsa değişiklik planlamaya hazır değildir.

Uç nokta, herhangi bir tünel var olmadan önce çözümlenmelidir

Şubenin internet bağlantısının yeni bir genel adres aldığını varsayalım. Uç nokta güncelleyicisi yeni adresi yayımlar ve uzak VPN uygulaması değişen yanıtı okuyabilmelidir. Hangi çözümleyici bu yanıtı sağlıyorsa tünel olmadan erişilebilir olmalıdır, yoksa istemci ancak bulamadığı şeye bağlandıktan sonra çözümleyebileceği bir adın peşinden koşar.

Bu başlangıç bağımlılığını açıkça söylemeye değer, çünkü tüm iç çözümleyiciler VPN'in arkasındayken onu yanlışlıkla oluşturmak kolaydır. Uç nokta araması için tünelden önceki bir yolu koruyun ve yeni yanıtın hemen alındığını varsaymak yerine istemcinin yeniden bağlanma davranışını doğrulayın.

Dinamik DNS'in de kayıt güncellemesinin aşamayacağı sınırları vardır. Bir kaydı güncellemek hiçbir güvenlik duvarı bağlantı noktası açmaz, NAT eşlemesi oluşturmaz ve eş kimliğini kanıtlamaz. Kapalı bağlantı noktasıyla yayımlanan bir adres, doğru çözümleyen ve yine de hiçbir şeye bağlanamayan bir istemci verir.

Son olarak, çalışan bir istemci yeniden bağlanana kadar önbelleğe alınmış uç noktayı kullanmaya devam edebilir. Notlarınızda yayımlamayı, önbelleği ve yeniden bağlanma ilkesini ayırın, böylece eski bir eş bozuk bir güncelleyici sanılmasın.

Hizmet adı uygulamanın nerede yaşadığını tanımlar

Şimdi tünelin sağlıklı kaldığını ama envanter sunucusunun 172.26.14.20 adresinden 172.26.14.35 adresine taşındığını varsayalım. Genel uç nokta kaydı etkilenmez, özel hizmet kaydının ise değişmesi gerekir. O hizmet için ayrılmış bir adres veya statik atama kullanmak bunu daha seyrek yapar; yetkili güncelleme yolu bunun amaçlandığı durumları ele alır.

Burada iki güncelleme mekanizması karıştırılır. RFC 2136 bir bölgede DNS kayıtlarını eklemek ve silmek için bir protokol tanımlar, oysa ticari bir dinamik DNS sağlayıcısı başka bir amaç için tamamen farklı bir HTTP API sunabilir. Birini kullanmak diğerinin ortamınızda bulunduğu anlamına gelmez. Ona karşı bir güncelleyici yazmadan önce bölgenizin gerçekte hangi mekanizmayı kabul ettiğini kontrol edin.

Doğru özel yanıt yalnızca ilk koşuldur. Uzak bir çağıranın onu kullanabilmesi için istemcinin özel bölgeyi taşıyan bir çözümleyiciye, o çözümleyiciye sorgulara izin veren bir ilkeye ve geri dönen adres için yönlendirmeye ihtiyacı vardır. İstemcinin ulaşamadığı bir adrese çözümlenen ad, sunucu arızası gibi görünen bir zaman aşımı üretir.

İki yolu ayrı ayrı test edin

Uç noktayı tünelin dışından, hizmeti içinden kontrol edin ve sonuçları iki bağımsız olgu olarak saklayın:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

İlk sorgu başarısız olursa sorun genel yayımlamada veya tünel öncesi çözümleme yolundadır ve hiçbir iç değişiklik yardımcı olmaz. İkincisi bir adres döndürür ama üçüncüsü tünelden bir rota göstermezse, DNS katmanı iyidir ve yönlendirme ilkesi iyi değildir.

Her adres değişikliğinden sonra çifti çalıştırın ve hangi kaydın hareket ettiğini not edin. Yalnızca «DNS güncellendi» diyen bir devir teslim, sonraki mühendisin iki yaşam döngüsünden hangisinin gerçekten çalıştığını tahmin etmesine bırakır.