ddclient VPN çıkışını yayımlıyor: keşif kaynağını düzeltin

DNS adınız artık bir VPN sağlayıcısının adresine çözümleniyor ve güncelleme günlüğü tamamen sağlıklı görünüyor. Bu kombinasyon normaldir. Web tabanlı bir keşif sondası harici bir hizmete hangi kaynağı gördüğünü sorar ve istek tam tünelli bir VPN üzerinden çıktığında yanıt ev WAN adresiniz değil VPN çıkışı olur. Güncelleyici işini yaptı; iş yanlış gözleme yöneltilmişti.

Adın neye ulaşması gerektiğini doğrulayın

Gelen bir ev hizmeti için ortak bir ad, onaylanmış gelen bağlantıların o hizmete ulaşabileceği bir adres gerektirir. Paylaşılan bir sağlayıcı çıkışı yayımlamak orada gelen yönlendirme düzenlemez ve hiçbir DNS yapılandırması o yönlendirmeyi oluşturmaz. Güncelleyiciye dokunmadan önce buna karar verin, çünkü hangi adresin doğru olduğunu bu belirler.

Bir VPN istemcisinin tünel adresi için özel bir ad, başka yanıtı olan başka bir sorundur: özel DNS'e aittir ve hiç de ortak bir keşif hizmetine ihtiyaç duymaz. İki gereksinimi karıştırmak, çalışan bir yapılandırmanın kimsenin istemediği bir adresi yayımlamaya başlamasının yoludur.

Arayüz adresleri de yorum gerektirir. Ev yönlendiricisinin arkasındaki bir dizüstü adresi ortak WAN adresi değildir ve yönlendiricinin WAN adresi bile taşıyıcı düzeyinde NAT'ın arkasında olabilir; orada yayımlamak gelen erişilebilirlik sağlayamaz.

Herhangi bir şeyi değiştirmeden önce değeri yeniden üretin

İki yolu ayrı ayrı gözlemleyin. Tünel açıkken sonda çıkışı bildirir; tünel kapalıyken ya da sonda fiziksel arayüze bağlıyken ev adresini bildirir: curl --interface eth0 https://ifconfig.me. Bu iki yanıt farklıysa, güncelleyiciye dokunmadan arızayı yeniden üretmişsinizdir.

Sonra istemciyi güncelleme yapmadan yapılandırmayı denetleyen bir kipte çalıştırın, örneğin ddclient -verbose -noexec ve hangi keşif yöntemini seçtiğini okuyun. Ayrıntılı çıktı yöntemi ve elde edilen değeri adlandırır ve herhangi bir düzenlemeden önce ihtiyaç duyduğunuz olgu budur.

Keşfi seçilen yola yönlendirin

Ad ev WAN adresini yayımlamak zorundaysa keşif tam o adresi gözlemlemelidir. Kabaca tercih sırasıyla üç seçenek işe yarar: yönlendiricinin kendi desteklenen güncelleyicisiyle yayımlamasına izin verin; ddclient'ın yönlendirici durumu keşfini yönlendiricinin gerçekten sunduğu bir sayfaya karşı kullanın; ya da web sondasını koruyun ama tünelin dışına çıkması için fiziksel arayüze bağlayın.

Yönlendirici durumu yolu için yeni ddclient sürümleri usev4 ve fwv4 seçenek ailesini, sayfanın çevresindeki metin için isteğe bağlı bir atlama deseniyle kullanır. Kurulu sürümünüzün README dosyasına bakın, çünkü eski sürümler aynı fikri use ve fw ile yazar ve yanlış sürümden kopyalanan bir seçenek adı başlangıçta başarısız olur.

Web keşfini koruyorsanız, sondanın yönlendirilmesi ile güncelleme API çağrısının yönlendirilmesinin ayrı kararlar olduğunu unutmayın. Güncelleme çağrısı kaydı teslim eder; sonda teslim edilecek değeri belirler.

Sırları ve sürümleri düzenli tutun

Yönlendirici kimlik bilgileri ve sağlayıcı belirteçleri korunan bir yapılandırma dosyasına aittir, kabuk geçmişine düşen bir komut satırına değil. Ayrıntılı izler ikisini de içerebilir, bu yüzden bir kayda yapıştırmadan önce onları gizleyin. Kimliği doğrulanmış bir yönlendirici sayfasını kazımayı gerektiren bir keşif yöntemi, bu kimlik bilgilerini ürün yazılımı güncellemeleri boyunca çalışır tutmanızı da gerektirir. Onları sağlayıcı belirteciyle aynı özenle saklayın.

ddclient README keşif yaklaşımlarını ve seçenek adlarını belgeler. IPv4 ve IPv6 sonuçlarını tek bir kayıtta karıştırmayın ve bir sürümde bulunan bir seçeneğin diğerinde de bulunduğunu varsaymayın.

Değeri, sonra erişilebilirliği doğrulayın

Canlı güncellemeye izin vermeden önce önerilen adresi amaçlanan uç noktayla karşılaştırın, sonra bir yetkili güncellemeden sonra yetkili DNS'i denetleyin ve çözümleyici önbelleklerini hesaba katın. Düşük TTL beklemeyi kısaltır; yanlış bir değeri doğru yapmaz.

Ancak kayıt doğru olduktan sonra, gerekli güvenlik duvarı ve yönlendirme önceden onaylanmışken gelen hizmeti bağımsız bir ağdan test edin. Doğru bir A kaydı erişilebilir bir hizmeti kanıtlamaz ve statik bir VPN kiralaması özel adlandırmayı basitleştirebilir ama yanlış WAN'ı gösteren ortak bir ana bilgisayar adını onarmaz.