DHCP yenilənməsindən sonra VPN düşür? Ünvanları müqayisə edin

İcarə müqaviləsinin yenilənməsi və VPN nasazlığı jurnallarda o qədər tez-tez birlikdə görünür ki, insanlar birinin digərini törətdiyi qənaətinə gəlirlər. Vaxt uyğunluğu realdır; səbəb əlaqəsi adətən deyil. Yenilənmə icarəni verən serverə göndərilən, eyni bağlantını istifadə etməyə davam etmək istəyən tək nöqtəli sorğudur və server müştəri bir ünvanı belə dəyişmədən onu uzada bilər. Hadisə ətrafında müştərinin öz dəyərlərini nəzərdən keçirmək səssizcə yenilənmiş icarəni işləyən tunelin altında həqiqətən dəyişmiş şəbəkədən ayırır.

Qopan müştəridən başlayın

Əvvəlcə müştərinin bağlantı jurnalını açın və qopmanın vaxtını saniyəyə qədər qeyd edin. Sonra həmin dəqiqə üçün əməliyyat sisteminin şəbəkə jurnalını açın və interfeysin nə etdiyini sıra ilə oxuyun. Bu sıra bütün araşdırmadır: qopmadan əvvəl DHCP hadisəsi, DHCP hadisəsindən əvvəl qopma və aralarında heç nə olmayan iki hadisə üç fərqli nəticədir. Tunel artıq yenidən qoşularkən sadəcə icarədən bəhs edən jurnal sətri bəzəkdir, sübut deyil.

Xronologiyanı yaddaşda saxlamaq əvəzinə gedərkən yazın. Fərqli alətlərin vaxt möhürləri nadir hallarda tam uyğun gəlir və fərqin özü bəzən izahat olur.

Hadisə ətrafındakı dörd dəyəri müqayisə edin

Dörd dəyər əlaqənin yerli tərəfini real dəyişikliyi tutmaq üçün kifayət qədər yaxşı təsvir edir: interfeys ünvanı, standart şlüz, həlledici siyahısı və interfeysin işlək vəziyyəti. Onları qopmadan sonra bir dəqiqə ərzində götürün və tunel sağlam ikən alınmış çəkilişlə müqayisə edin.

ip -4 -brief addr show dev wlan0
ip -4 route show default
resolvectl status | grep -A3 'DNS Servers'
journalctl -u NetworkManager --since -10m --no-pager | grep -i dhcp

Dəyişməmiş ünvan, dəyişməmiş şlüz və dəyişmiş həlledici siyahısı marşrutlaşdırmaya deyil, ad həllinə işarə edir və tunel sağ qalmış, tətbiqlər isə hostları tapmaqdan dayanmış ola bilər. Dəyişmiş şlüz yerli şəbəkədən çıxan yolun yerini dəyişdiyini bildirir ki, bu da əvvəlkinə baxan marşrutu etibarsız etməyə kifayətdir. Əgər dörd dəyərin hamısı sağlam çəkilişlə üst-üstə düşürsə, icarə sizin səbəbiniz deyil və müştərinin öz yenidən qoşulma məntiqi mövzuya çevrilir. Müqayisəni nasazlıq görünən zaman götürün, çünki yenidən yükləmədən sonra alınmış sağlam çəkilişin ünvan tarixçəsi fərqlidir və uyğun gəlməyəcək.

Yenilənmə nəyi dəyişə bilər, nəyi bilməz

RFC 2131 yenilənməni icarə müddətinin yarısında ilkin serverə sorğu kimi təsvir edir; ilk cəhd cavabsız qalsa, müddətin səkkizdə yeddisində istənilən serverə yenidən bağlanma nəzərdə tutulur. Heç bir addım müştərinin fərqli ünvan almasını tələb etmir və əməkdaşlıq edən server adətən mövcud bağlantını uzadır. Əsl ünvan dəyişikliyi adətən başqa yolla gəlir: yenilənməni rədd edən server, vəziyyətini itirib yenidən başlayan müştəri və ya cihazı fərqli seqmentə köçürən şəbəkə.

Əlaqənin xarici tərəfi heç bir yerli dəyişiklik olmadan də dəyişə bilər. Operator səviyyəli çevirmə arxasında VPN həmyaşıdının gördüyü ünvan yerli icarənin etdiyi heç nədən asılı olmayaraq yenidən təyin edilə bilər və bu təyinat müştərinin içindən yerli şəbəkə nasazlığı ilə eyni görünür. Yerli bildirilən ünvanı həmyaşıd tərəfin müşahidəsi ilə müqayisə etmək onları ayırmağın yeganə yoludur.

Müştəri uyğunlaşa bilmədikdə

Nəqliyyatını köhnə ünvana bağlayan, həmyaşıda köhnəlmiş marşrut keşləyən və ya interfeys kimliyini saxlayan müştəri artıq mövcud olmayan yolda təkrar cəhdlər edə bilər. Bu uyğunlaşma qüsurdur və hostun artıq çata bilmədiyi ünvana doğru təkrar ötürmələr kimi görünür. Bəzi müştərilər bunu dizaynla həll edir: məsələn, WireGuard düzgün autentifikasiya edilmiş paket yeni mənbədən gəldikdə həmyaşıdın son nöqtəsini yeniləyir.

Xidməti bərpa edən əl ilə yenidən başlatma uyğunlaşmanın harada uğursuz olduğuna dair ipucudur, icarə və tunellərin uyğunsuz olduğuna sübut deyil. Sınaq zamanı bloklama siyasətini yerində saxlayın, əks halda sınağın özü başqa səbəbli kəsinti olur. Müştərinin özü bərpa edib-etmədiyini, bunun nə qədər çəkdiyini və hansı ünvana təkrar cəhd etdiyini qeyd edin; bu ardıcıllıq sizə interfeysdə göstərilən qopma səbəbindən çoxunu deyir.

Günahlandırmadan əvvəl hadisəni təkrarlayın

Cədvəli gözləmək əvəzinə şəraiti təkrar istehsal edin: icarəni buraxıb yenidən alın və ya ekvivalent nəzarətli hadisəni məcburi edin və tunelin sağ qalıb-qalmadığını izləyin. İdarə olunan şəbəkədə hər hansı ünvan dəyişikliyini şəbəkə sahibi ilə əlaqələndirin, çünki təsadüfi statik təyinat həmin ünvanı artıq tutan cihazla toqquşa bilər.

Dəstəklənən düzəlişdən sonra eyni hadisəni təkrarlayın və sonra tətbiqi və ad sorğusunu sınayın, çünki yenidən qoşulan lakin DNS-i pozan tunel vacib sınaqdan daha zəif bir sınaqdan keçir. Planlaşdırılmış icarəni səbəb adlandırmaq əvəzinə müşahidə etdiyiniz konkret dəyişikliyi vaxt möhürü ilə birlikdə bildirin. Bu iki hesabat arasındakı fərq növbəti şəxsin nasazlığı təkrar istehsal edə bilməsidir, yoxsa yalnız şaiqəni.