VPN köçdü: OpenVPN müştəriniz niyə hələ də köhnə IP-yə zəng edir

Provayder ictimai ünvanınızı dəyişdi, siz dinamik DNS qeydini yenilədiniz, amma müştəri hələ də qoşula bilmir. Bayırdan qeydin yayılmadığı görünür. Çox vaxt qeyd qaydasındadır və müştəri köçmədən əvvəl həll etdiyi ünvana zəng edir, çünki işləyən tunel və saxlanmış profil hər ikisinin serverin harada yaşadığına dair öz fikri var. Üç qat razılaşmalıdır və onlar fərqli cədvəllərlə yenilənir.

DNS-in dediyinə deyil, profilin nəyə zəng etdiyinə baxın

Faktiki istifadə etdiyiniz bağlantını açın və remote sətrini oxuyun. Oradakı rəqəmsal ünvan heç vaxt hostname yenilənməsini izləmir, qeyd nə qədər düzgün olsa da.

Sonra redaktə etdiyiniz profilin müştərinin yüklədiyi profil olduğunu yoxlayın. İdxal edilmiş profillər adi haldır: menecer aylar əvvəl surət götürüb öz versiyasını saxlaya bilər, ona görə endirmələr qovluğundaki fayl ilə tətbiqdəki giriş fərqli ola bilər. DNS-i ayıklamağa başlamazdan əvvəl müştərinin öz bağlantı detallarındaki son nöqtəni müqayisə edin.

İki fayl, bir son nöqtə — burada adi tapıntı budur.

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

Müştərinin növbəti bağlantı cəhdini oxuyun

Bağlantını ətraflı jurnalla yenidən başladın və əlaqə saxlayacağı ünvanı adlandıran sətri oxuyun. Vacib olan həmin dəyərdir, brauzerinizin həll etdiyi deyil.

Həlledici keşi əvvəlki cavabı hələ də saxlaya bilər və bəzi şəbəkələr onu qeydin TTL-nin tələb etdiyindən daha uzun saxlayır. Başqa yerdən sınaqdığınız ictimai həllediciyə deyil, müştərinin faktiki istifadə etdiyi həllediciyə sorğu göndərin.

Jurnal yeni ünvanı göstərirsə və bağlantı yenə də alınmırsa, problem yerini dəyişib: paket harasa gedir və heç kim cavab vermir. Bu dinləyici, firewall və ya port yönləndirmə məsələsidir və müştərinin həll yolunda deyil, server tərəfindədir. Bu iki nasazlığı ayrı saxlayın, çünki əlçatmaz dinləyicini DNS problemi kimi qəbul etmək sizi eyni dövrəni iki dəfə gəzdirmiş olur.

Hansı yenidən başlatmanı etdiyinizi bilin

Bütün yenidən başlatmalar eyni vəziyyəti qorumur, buna görə ünvan dəyişikliyi prosesin necə təkrar işə salındığından asılı olaraq fərqli davrana bilər. Siqnal ilə başladılan yumşaq yenidən başlatma əvvəlki sessiyanın daha çox kontekstini saxlayır, tam dayanma və başlatma isə yenidən konfiqurasiyadan başlayır. Müştərinin yenidən həll edib-etmədiyini sınayırsınızsa, konfiqurasiyadan başlayan yolu istəyirsiniz.

Davamlılıq parametrləri də vacibdir, çünki onlar yeni ünvanların ardınca qaçmaq üçün deyil, autentifikasiya olunanı saxlamaq üçün nəzərdə tutulub.

Ən təmiz sınaq nəzərdə tutulan profildən təzə başlatmadır, ardınca son nöqtəni adlandıran jurnal sətrinə baxış. Qismən qorunmuş sessiyadan öyrəndiyiniz hər şey həmin sessiya haqqında bir ifadədir.

Dörd seçim və onların ayrı vəzifələri

Hostname ilə remote yenidən həlli ümumiyyətlə mümkün edən parametrdir; o sətirdəki hərfi ünvan bunu istisna edir. resolv-retry axtarış uğursuz olduqda nə baş verdiyini idarə edir və 2.6 onu artıq susmaya görə sonsuz edir. Ona görə onu əlavə etmək heç nəyi dəyişmir və o, heç vaxt fərqli cavab üçün dövri yoxlama planlaşdırmır. Onun yeni ünvanlar üçün sorğu göndərdiyini deyən hər kəs bərpanı təzəliklə qarışdırıb.

persist-remote-ip təzəlikdən çox davamlılıqla bağlıdır: son autentifikasiya olunan son nöqtəni, dəstəklədiyi yumşaq yenidən başlatmalar boyunca təkrar istifadə edir. Köçməni sınayarkən bu istədiyinizin əksidir. Qurğunuz onu aktivləşdirirsə, sınaq üçün söndürün, sonra yeni son nöqtə sübut olunduqdan sonra bərpa edin. Açıq qalsa, uğurlu yenidən qoşulma sizə DNS haqqında heç nə deməyə bilər.

float sessiya ortasında ünvanı dəyişmiş autentifikasiya olunmuş peer-i qəbul edir və yalnız bunu dəstəkləyən quruluşlarda. O, DNS-i yeniləmir və provayder dəyişikliyini özbaşına izləməyəcək. Onu gəzən peer-lər üçün dayanıqlılıq xüsusiyyəti kimi qəbul edin, serverlər üçün dinamik ünvan mexanizmi kimi deyil.

Müştərini günahlandırmazdan əvvəl yeni son nöqtəni təsdiqləyin

Şəbəkənizin xaricindən yeni ünvanın konfiqurasiya edilmiş portda dinləyicisi olduğunu və provayderin yönləndirməsinin ona işarə etdiyini yoxlayın. Açıq portu olmayan maşın üçün düzgün A qeydi insanların keşə aid etdiyi simptomun eynisini yaradır.

Sonra yenidən qoşulun və iki şeyi təsdiqləyin: müştəri gözlənilən server sertifikatına qarşı autentifikasiya olundu və sessiya nəzərdə tutduğunuz resursa çatır. Ünvan dəyişikliyi identifikasiya tələblərini aşağı salmır və yanlış son nöqtəyə uğurla qoşulma uğursuz olandan pisdir. OpenVPN 2.6 təlimatı dörd seçimin hamısını öz əhatəsi ilə sadalayır və profilin yanında saxlanılacaq yoxlama siyahısı budur.

İnzibati girişinizi daşıyan tuneli yenidən başlatmazdan əvvəl serverə bantdan kənar yol saxlayın. Bu tək ehtiyat tədbiri bu ssenarinin yaratdığı hadisələrin çoxunu qarşısını alır.