Ev VPN sunucusu için dinamik DNS gerekli mi?

Dinamik DNS adı düzeltir, giriş yolunu değil. Üç kontrol, bir ana makine adının ev VPN sunucusu için yeterli olup olmadığına ya da giriş yolunun bozuk olduğuna karar verir.

İnsanların bana sorduğu ev VPN arızalarının çoğu DNS arızası değil, yine de önce dinamik DNS aboneliği alıyorlar. Bir şeyi yapılandırmadan önce, ana makine adının gerçekten bozuk olan parça olup olmadığına karar verin. Güncelleyici, sağlayıcınızın verdiği adres değiştiğinde kaydı yeniden yazar; bir bağlantı noktası açamaz, operatör NAT'ını geçemez ya da çalışan bir WireGuard oturumunun uç noktasının değiştiğini fark etmesini sağlayamaz. Dinamik DNS'in çözümün tamamı mı yoksa yalnızca bir satırı mı olduğuna üç koşul karar verir.

Birinci koşul: adresiniz gerçekten değişiyor

Konut adresleri sıradan nedenlerle değişir: modem elektrik kesintisinden sonra yeniden eşitlenir, sağlayıcı havuzu yeniden dengeler, uzun bir kesintiden sonra yeni kiralama gelir. Bazı hatlarda da seyrek değişir ve aynı adresin bir yıl dayandığını gördüm; iş paketlerinde çoğu zaman statik bir adres bulunur. On iki ayda hiçbir şey değişmediyse, elle düzenlediğiniz tek bir A kaydı, canlı tutulacak bir artırılmış süreç daha az demektir.

Tahmin etmek yerine ölçün. Yönlendiricinin durum sayfasındaki WAN adresini okuyun ve dış dünyanın gördüğüyle karşılaştırın. Bunu LAN'daki bir makineden çalıştırın:

curl -fsS https://api.ipify.org; echo

İki değer farklıysa yönlendiricinizin önünde bir şey çeviri yapıyor ve hiçbir ana makine adı güncellemesi bunu düzeltmez. 100.64.0.0/10 içindeki bir adres, operatör düzeyi NAT için ayrılmış ortak aralıktır ve doğru güncellenmiş bir adın dışarıdan yine de zaman aşımına uğramasının olağan nedeni budur.

İkinci koşul: istemciler adı yeniden çözüyor

Kısa TTL, insanların atladığı kısımdır. Özyinelemeli çözümleyiciler kaydın TTL'ine uyar, ancak istemci yığınları ayrı önbellekler ve hâlihazırda ayakta olan bir tünel hiçbir şeyi yeniden çözmez. Hata ayıklarken kaydı 60-300 saniyeye ayarlayın; bu, eski bir yanıtın sunulduğu pencereyi kısaltır ve bağlı bir oturumu taşımaz.

OpenVPN her yeniden bağlanmada satırı remote vpn.example.net 1194 yeniden çözer ve resolv-retry infinite arama başarısız olduğunda çıkmak yerine yeniden denemeye devam etmesini sağlar. Sunucuda float kurulmuş bir oturumun kaynak adresi değişen bir eşi izlemesine izin verir. WireGuard daha doğrudandır: wg-quick up yapılandırma uygulandığında Endpoint adresini çözer ve istemci tüneli yeniden kurduğunda onu yeniden çözer, bu yüzden eski adrese karşı hâlâ başarılı olan bir el sıkışma durana kadar başarılı olmayı sürdürür.

Bu fark planı biçimlendirir. İstemciler istek üzerine bağlanıyorsa bir adres değişikliği tek bir yeniden bağlanmaya mal olur. Oturumu günlerce açık tutuyorlarsa tünelin bir sonraki el sıkışmada öleceğini bekleyin ve ayakta kaldığını varsaymak yerine istemcinin yeniden denemesini sağlayın.

Üçüncü koşul: giriş yolu hâlâ açık

Dinamik DNS yalnızca adın neye işaret ettiğini değiştirir, başka bir şeyi değil. Yönlendiricideki bağlantı noktası yönlendirmesi, VPN ana makinesindeki güvenlik duvarı kuralı ve sağlayıcının gelen paketlere izin vermesi, kayıt bir anlam kazanmadan önce var olmalıdır. Yönlendirmenin neyi hedeflediğine bakın: arayüz yerine bir WAN adresine sabitlenmişse, adres değişikliği yönlendirmeyi sessizce bozar ve suç kayda yüklenir.

Dışarıdan test edin. Wi-Fi kapalıyken hücresel verideki bir telefon en ucuz dürüst testtir; aynı LAN'daki bir dizüstü bilgisayar değildir. Ad, genel adresinize çözümlendiğinde ve yönlendiricide NAT döngüsü yoksa, içeriden yapılan test başarısız olur ama kayıt tamamen doğrudur; çoğu insanı hiç yanlış olmamış bir kaydı düzenlemeye gönderen de budur.

Üçü de tuttuğunda ne çalıştırmalı

ddclient, küçük bir ana makine için en az şaşırtan güncelleyicidir. Asgari yapılandırma, sağlayıcının gördüğü adresi yayımlar ve bu, çift NAT hatasını atlar:

protocol=dyndns2
use=web, web=https://api.ipify.org
server=updates.your-dns-provider.net
login=vpn-home
password=update-token
vpn.example.net

Bunu shell döngüsü yerine birkaç dakikada bir systemd zamanlayıcısından çalıştırın ve başarıyı varsaymak yerine sağlayıcının yanıtını günlüğe yazın. Kimlik bilgisine bir anahtar gibi davranın, çünkü her istemcinin nereye gönderileceğine o karar verir: hesap parolası yerine sınırlı bir güncelleme belirteci kullanın, dosyayı 0600 kipinde tutun ve güncellemeleri HTTPS üzerinden gönderin.

Bağlanmadan önce doğrulayın

Tek bir sorgu size dünyanın geri kalanının ne gördüğünü söyler ve bir değişiklikten sonra beklemeniz gereken TTL'i yazdırır:

dig +noall +answer vpn.example.net @1.1.1.1

O adresi yönlendiricinin WAN adresiyle karşılaştırın. Eşleşiyorlarsa ad işini yapıyor demektir ve hâlâ başarısız olan şey gelen erişilebilirlik, bir anahtar veya yeniden çözmemiş bir istemcidir. Farklıysalar güncelleyici yanlış arayüzü yayımlıyordur; çoğu zaman yönlendiricinin kendisinde değil arkasındaki VPN ana makinesinde çalıştığı için.

Bir dakikalık bir geri alma hazırlayın: son çalışan adresi ve önceki TTL'i not edin, böylece sağlayıcının kötü bir öğleden sonrasında ikisini de elle yayımlayabilirsiniz.

Yanıt hayır olduğunda

Birinci veya üçüncü koşul tutmuyorsa değişen yapılandırma değil karardır. Operatör NAT'ının arkasında pratik seçenekleriniz sağlayıcıdan genel bir adres istemek, giriş noktasını sabit adresli küçük bir VPS'e taşımak, ya da kendi buluşmasını tutan bir katman kullanmaktır. Adres statikse güncelleyiciyi atlayın: bir A kaydı, IPv6 kullanıyorsanız bir AAAA kaydı, aynı bağlantı noktası yönlendirmesi.

İstemciler bağlı kalırken adres değişiyorsa dürüst düzeltme istemcide yaşar: yeniden bağlanma mantığı ve yeniden deneme aralığı, daha hızlı bir güncelleyici değil. İkinci bir sağlayıcı yalnızca aralığı gizler.

Devam etmeden önce dört şeyi sırayla doğrulayın:

  • Güncelleyicinin yayımladığı adres yönlendiricinin WAN adresiyle eşleşiyor.
  • Kaydın TTL'i, bir değişikliğin dakikalar içinde görünmesine yetecek kadar kısa.
  • Bağlantı noktası yönlendirmesi sabit bir adrese değil arayüze bağlı.
  • Son değişiklikten bu yana gerçek bir istemci yeniden bağlandı ve trafik geçirdi.

Dördü de tutuyorsa kurulumu olduğu gibi bırakın; bir sonraki arızanız adlandırma sorunu değil bir anahtar ya da güvenlik duvarı kuralıdır. Herhangi biri tutmuyorsa, bir hareketli parça daha eklemeden önce o satırı düzeltin. RFC 2136 güncelleme mekanizmasının kendisini anlatır, arka plan sürecinin hatta ne koyduğunu görmek isterseniz.

İlgili makaleler