Ev VPN serveri üçün dinamik DNS lazımdır?

İnsanların məndən soruşduğu ev VPN nasazlıqlarının çoxu DNS nasazlığı deyil, amma yenə də əvvəlcə dinamik DNS abunəliyi alırlar. Bir şeyi quraşdırmadan əvvəl host adının həqiqətən pozulmuş hissə olub-olmadığını qərarlaşdırın. Yeniləyici, provayderin sizə verdiyi ünvan dəyişdikdə qeydi yenidən yazır; o, port aça bilməz, operator NAT-ını keçə bilməz və canlı WireGuard sessiyasının son nöqtəsinin dəyişdiyini görməsini təmin edə bilməz. Üç şərt dinamik DNS-in bütün həll olduğunu, yoxsa onun yalnız bir sətri olduğunu müəyyən edir.

Birinci şərt: ünvanınız həqiqətən dəyişir

Yaşayış ünvanları adi səbəblərdən dəyişir: modem elektrik kəsilməsindən sonra yenidən sinxronlaşır, provayder hovuzu yenidən balanslaşdırır, uzun fasilədən sonra yeni icarə gəlir. Bəzi xətlərdə isə nadir hallarda dəyişir və mən eyni ünvanın bir il boyu qaldığını görmüşəm; biznes tarifləri çox vaxt statik ünvan ehtiva edir. Əgər on iki ayda heç nə dəyişməyibsə, əl ilə redaktə etdiyiniz bir A qeydi bir daemon az deməkdir.

Təxmin etmək əvəzinə ölçün. Routerin status səhifəsində WAN ünvanını oxuyun, sonra onu xaricdən görünənlə müqayisə edin. Bunu LAN-dakı maşından işlədin:

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

Əgər iki dəyər fərqlidirsə, routerinizin qarşısında nəsə çevirmə edir və heç bir host adı yeniləməsi bunu düzəltməyəcək. 100.64.0.0/10 daxilindəki ünvan operator səviyyəli NAT üçün istifadə olunan paylaşılan aralıqdır və düzgün yenilənmiş adın xaricdən hələ də vaxt aşımına uğramasının adi səbəbi budur.

İkinci şərt: müştərilər adı yenidən sorğulayır

Qısa TTL insanların atladığı hissədir. Rekursiv həlledicilər qeydin TTL-inə əməl edir, lakin müştəri yığmaları ayrıca keşləyir və artıq qurulmuş tunel heç nəyi yenidən həll etmir. Ayıklama zamanı qeydi 60-300 saniyəyə qoyun; bu, köhnə cavabın verildiyi pəncərəni qısaldır və qoşulmuş sessiyanı köçürmür.

OpenVPN hər dəfə yenidən qoşulduqda remote vpn.example.net 1194 sətrini yenidən həll edir, və resolv-retry infinite onu yenidən cəhd etməyə davam etdirir, axtarış uğursuz olduqda çıxmaq əvəzinə. Serverdə isə float qurulmuş sessiyanın mənbə ünvanı dəyişmiş həmkarını izləməsinə imkan verir. WireGuard daha kobuddur: wg-quick up tətbiq edildikdə Endpoint həll edir, və müştəri tuneli yenidən qurduqda onu yenidən həll edir, buna görə köhnə ünvana qarşı hələ də uğurla keçən əl sıxma dayanana qədər uğurlu qalır.

Bu fərq planı formalaşdırır. Müştərilər tələb üzrə qoşulursa, ünvan dəyişikliyi bir yenidən qoşulma bahasına başa gəlir. Sessiyanı günlərlə açıq saxlayırlarsa, tunelin növbəti əl sıxmada öləcəyini gözləyin və müştərinin qalxdığını güman etmək əvəzinə yenidən cəhd etməsini təmin edin.

Üçüncü şərt: giriş yolu hələ də açıqdır

Dinamik DNS yalnız adın hara baxdığını dəyişir, başqa heç nəyi. Routerdəki port yönləndirməsi, VPN hostundakı firewall qaydası və provayderin daxil olan paketlərə icazə verməsi — hamısı qeydin əhəmiyyət kəsb etməsindən əvvəl mövcud olmalıdır. Yönləndirmənin hədəfinə baxın: əgər interfeysə deyil, WAN ünvanına bağlanıbsa, ünvan dəyişikliyi yönləndirməni səssizcə pozar və günah qeydin üstünə düşər.

Xaricdən sınayın. Wi-Fi söndürülmüş mobil datada telefon ən ucuz və dürüst sınaqdır; eyni LAN-dakı noutbuk deyil. Ad sizin ictimai ünvanınıza həll olunanda və routerdə NAT loopback yoxdursa, daxili sınaq uğursuz olur, halbuki qeyd tamamilə düzgündür — bu da çoxlarını heç vaxt səhv olmayan qeydi redaktə etməyə yönəldir.

Üçü də ödənəndə nə işlətmək lazımdır

ddclient kiçik bir host üçün ən az təəccübləndirən yeniləyicidir. Minimal konfiqurasiya provayderin gördüyü ünvanı yayımlayır və bununla ikiqat NAT səhvini yan keçir:

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

Onu shell dövrəsi yerinə hər neçə dəqiqədən bir systemd taymeri ilə işlədin və uğur güman etmək əvəzinə provayderin cavabını jurnala yazın. Etibarnaməyə açar kimi yanaşın, çünki hər müştərinin hara göndəriləcəyini o həll edir: hesab parolu yerinə məhdud yeniləmə tokeni istifadə edin, faylı 0600 rejimində saxlayın və yeniləmələri HTTPS üzərindən göndərin.

Öhdəlik götürməzdən əvvəl yoxlayın

Bir sorğu dünyanın qalan hissəsinin nə gördüyünü deyir və dəyişiklikdən sonra gözləməli olduğunuz TTL-i çap edir:

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

Həmin ünvanı routerin WAN ünvanı ilə müqayisə edin. Uyğun gəlirsə, ad öz işini görür və hələ də uğursuz olan şey daxil olan əlçatımlıq, açar və ya yenidən həll etməmiş müştəridir. Fərqlidirsə, yeniləyici səhv interfeysi yayımlayır, çox vaxt routerin özündə deyil, routerin arxasındakı VPN hostunda işlədiyi üçün.

Bir dəqiqə çəkən geri qaytarma saxlayın: son işlək ünvanı və əvvəlki TTL-i qeyd edin ki, provayderin pis gün keçirdiyi vaxt hər ikisini əl ilə yayımlaya biləsiniz.

Cavab «yox» olduqda

Birinci və ya üçüncü şərt uğursuz olarsa, konfiqurasiya deyil, qərar dəyişir. Operator NAT-ının arxasında praktik variantlarınız provayderdən ictimai ünvan istəmək, giriş nöqtəsini sabit ünvanlı kiçik VPS-ə köçürmək, və ya öz görüşmə nöqtəsini saxlayan bir örtük istifadə etməkdir. Ünvan statikdirsə, yeniləyicini atlayın: bir A qeydi, IPv6 işlədirsinizsə bir AAAA qeydi, eyni port yönləndirməsi.

Ünvan müştərilər qoşulmuş qalarkən dəyişirsə, dürüst düzəliş müştəridə yaşayır: yenidən qoşulma məntiqi və təkrar cəhd intervalı, daha sürətli yeniləyici deyil. İkinci provayder əlavə etmək yalnız intervalı gizlədir.

Davam etməzdən əvvəl dörd şeyi ardıcıl təsdiqləyin:

• Yeniləyicinin yayımladığı ünvan routerin WAN ünvanı ilə uyğun gəlir.
• Qeydin TTL-i dəyişikliyin bir neçə dəqiqə içində görünəcəyi qədər qısadır.
• Port yönləndirməsi sabit ünvana deyil, interfeysə bağlanıb.
• Son dəyişiklikdən bəri bir real müştəri yenidən qoşulub və trafik keçirib.

Dördü də ödənirsə, quraşdırmaya toxunmayın; növbəti nasazlığınız adlandırma problemi deyil, açar və ya firewall qaydasıdır. Hər hansı biri uğursuz olarsa, başqa bir hərəkətli hissə əlavə etməzdən əvvəl o sətri düzəldin. RFC 2136 yeniləmə mexanizminin özünü təsvir edir, əgər daemonun şəbəkəyə nə qoyduğunu görmək istəsəniz.