VPN taşındı: OpenVPN istemciniz neden hâlâ eski IP'yi arıyor

Sağlayıcı genel adresinizi değiştirdi, dinamik DNS kaydını güncellediniz ve istemci hâlâ bağlanamıyor. Dışarıdan bakınca kayıt yayılmamış gibi görünüyor. Çoğu zaman kayıt doğrudur ve istemci taşınmadan önce çözdüğü adresi arar, çünkü çalışan bir tünel ile kayıtlı bir profil sunucunun nerede yaşadığına dair kendi fikrine sahiptir. Üç katmanın anlaşması gerekir ve bunlar farklı takvimlerle güncellenir.

DNS'in ne dediğine değil, profilin neyi aradığına bakın

Gerçekten kullandığınız bağlantıyı açın ve remote satırını okuyun. Oradaki sayısal adres, kayıt ne kadar doğru olursa olsun, ana bilgisayar adı güncellemesini asla izlemez.

Ardından düzenlediğiniz profilin istemcinin yüklediği profil olup olmadığını kontrol edin. İçe aktarılmış profiller yaygındır: bir yönetici aylar önce kopya alıp kendi sürümünü tutmuş olabilir, bu yüzden indirme klasörünüzdeki dosya ile uygulamadaki girdi farklı olabilir. DNS'i hata ayıklamaya başlamadan önce istemcinin kendi bağlantı ayrıntılarındaki uç noktayı karşılaştırın.

İki dosya, tek uç nokta — burada olağan bulgu budur.

grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.net

İstemcinin bir sonraki bağlantı denemesini okuyun

Bağlantıyı ayrıntılı günlüklemeyle yeniden başlatın ve bağlanacağı adresin adlandırıldığı satırı okuyun. Önemli olan o değerdir, tarayıcınızın çözdüğü değil.

Çözümleyici önbelleği önceki yanıtı hâlâ tutuyor olabilir ve bazı ağlar bunu kaydın TTL'inin istediğinden daha uzun süre tutar. Başka bir yerden test ettiğiniz genel bir çözümleyiciye değil, istemcinin gerçekte kullandığı çözümleyiciye sorun.

Günlük yeni adresi gösteriyor ve bağlantı yine de başarısız oluyorsa sorun yer değiştirmiştir: paket bir yere gidiyor ve kimse yanıt vermiyor. Bu bir dinleyici, güvenlik duvarı ya da bağlantı noktası yönlendirme sorunudur ve istemcinin çözümleme yolunda değil, sunucu tarafındadır. Bu iki arızayı ayrı tutun, çünkü erişilemeyen bir dinleyiciyi DNS sorunu olarak ele almak sizi aynı döngüden iki kez geçirir.

Hangi yeniden başlatmayı yaptığınızı bilin

Her yeniden başlatma aynı durumu korumaz, bu yüzden adres değişikliği sürecin nasıl geri dönüştürüldüğüne göre farklı davranabilir. Bir sinyalle tetiklenen yumuşak yeniden başlatma önceki oturumun bağlamını daha çok korur, tam durdurma ve başlatma ise yeniden yapılandırmadan başlar. İstemcinin yeniden çözümleyip çözümlemediğini test ediyorsanız, yapılandırmadan başlayan yolu istersiniz.

Kalıcılık ayarları da önemlidir, çünkü bunlar yeni adreslerin peşinden koşmak için değil, kimliği doğrulanmış olanı korumak için tasarlanmıştır.

En temiz test, amaçlanan profilden taze bir başlatma ve ardından uç noktayı adlandıran günlük satırına bir bakıştır. Kısmen korunmuş bir oturumdan öğrendiğiniz her şey o oturum hakkında bir ifadedir.

Dört seçenek ve ayrı işleri

Ana bilgisayar adıyla remote, yeniden çözümlemeyi baştan mümkün kılan ayardır; o satırdaki düz bir adres bunu imkânsız kılar. resolv-retry bir arama başarısız olduğunda ne olacağını denetler ve 2.6 bunu zaten varsayılan olarak sonsuz yapar. Dolayısıyla eklemek hiçbir şeyi değiştirmez ve hiçbir zaman farklı bir yanıt için düzenli kontrol planlamaz. Bunun yeni adresleri yokladığını söyleyen, kurtarmayı tazelikle karıştırmıştır.

persist-remote-ip tazelik değil süreklilikle ilgilidir: desteklediği yumuşak yeniden başlatmalar boyunca en son kimliği doğrulanan uç noktayı yeniden kullanır. Bir taşınmayı test ederken bu, istediğinizin tam tersidir. Derlemeniz etkinleştiriyorsa test için kapatın, yeni uç nokta kanıtlandığında geri açın. Açık bırakılırsa, başarılı bir yeniden bağlanma size DNS hakkında hiçbir şey söylemeyebilir.

float, adresi oturum ortasında değişen kimliği doğrulanmış bir eşi kabul eder ve yalnızca bunu destekleyen düzenlerde. DNS'i yenilemez ve sağlayıcı değişikliğini kendi başına izlemez. Bunu dolaşan eşler için bir dayanıklılık özelliği olarak görün, sunucular için dinamik adres mekanizması olarak değil.

İstemciyi suçlamadan önce yeni uç noktayı doğrulayın

Ağınızın dışından, yeni adresin yapılandırılmış bağlantı noktasında bir dinleyicisi olduğunu ve sağlayıcının yönlendirmesinin oraya işaret ettiğini kontrol edin. Açık bağlantı noktası olmayan bir makine için doğru A kaydı, insanların önbelleğe yüklediği belirtinin aynısını üretir.

Sonra yeniden bağlanın ve iki şeyi doğrulayın: istemci beklenen sunucu sertifikasına karşı kimlik doğruladı ve oturum amaçladığınız kaynağa ulaşıyor. Adres değişikliği kimlik gereksinimlerini düşürmez ve yanlış uç noktaya başarıyla bağlanmak, başarısız olandan daha kötüdür. OpenVPN 2.6 kılavuzu dört seçeneğin hepsini kendi kapsamlarıyla listeler ve profile eşlik etmesi gereken kontrol listesi budur.

Yönetim erişiminizi taşıyan tüneli yeniden başlatmadan önce sunucuya bant dışı bir yol bulundurun. Bu tek önlem, bu senaryonun ürettiği olayların çoğunu önler.