Wi-Fi dəyişəndə və ya Ethernet qoşulanda VPN niyə düşür
'Yeni SSID, giriş nöqtələri arasında keçid və qoşulmuş kabel tuneli üç fərqli yerdə qırır. Mənbə ünvanını, sonra marşrutu, sonra protokolu yoxlayın.'
İki şey bir nasazlıq kimi bildirilir: noutbuk başqa Wi-Fi şəbəkəsinə keçib, ya da Wi-Fi işləyərkən kabel qoşulub. Klient hələ də qoşulduğunu deyir, ikon sağlam görünür, tunel isə heç nə daşımır. Altda yalnız üç vəziyyət parçası hərəkət edə bilər - keçid, yerli ünvan, standart marşrut - və hansının hərəkət etdiyi tunelin özü bərpa olunacağını, yoxsa yenidən qoşulma lazım olduğunu müəyyən edir. Mən onları bu sıra ilə yoxlayıram, çünki hesab parametrlərini dəyişmək heç birini heç vaxt düzəltməyib.
Keçid, ünvan və marşrut bir-birindən asılı olmayaraq hərəkət edir
Eyni şəbəkədə giriş nöqtələri arasında keçid adətən L2 hadisəsidir. Radio yenidən assosiasiya edir, interfeys öz ünvanını və şlüzünü saxlayır, tunelin asılı olduğu heç nə dəyişmir, buna görə böyük ofisdə gəzinti bəzən hiss olunmadan keçir. Başqa SSID-ə qoşulmaq belə deyil: köhnə interfeys düşə bilər, DHCP yeni ünvan, yeni şlüz və yeni həlledicilər verir, tunelin istifadə etdiyi xarici axın isə mövcud olmaqdan çıxır.
Ethernet üçüncü bir forma əlavə edir. Wi-Fi heç vaxt düşmür, yəni heç bir keçid hadisəsi baş vermir, amma simli interfeys öz ünvanı ilə peyda olur və çox vaxt metrikdə standart marşrutu qazanır. Tunel artıq üstünlük verilməyən yolla işləməyə davam edir, ya da klient soketini başladığı simsiz şəbəkəyə bağlı saxlayır. Brauzerdən hər ikisi eyni görünür: kabel yerinə oturan anda səhifələr donur.
Yəni ilk sual Wi-Fi-nin dəyişib-dəyişmədiyi deyil. Sual bundan ibarətdir: tunel işləyərkən bağlı olduğunuz ünvan, yoxsa son nöqtəyə marşrut dəyişdi.
Xarici soket indicə yox olmuş ünvana bağlanıb
Hər tunel xarici axındır: serverin ünvanı və portu ilə danışan yerli ünvan və port. Linux-da bu, köhnə mənbəyə bağlanmış UDP soketidir; ünvanı daşıyan interfeys silindikdə göndərişlər ya EADDRNOTAVAIL ilə uğursuz olur, ya da serverin heç vaxt görmədiyi mənbə ilə yeni interfeysdən çıxır.
Uzaq tərəf öz sancağını saxlayır. MOBIKE olmayan IKEv2 SA ünvan cütü ilə müəyyən edilir, OpenVPN sessiyası öyrəndiyi peer ünvanına bağlanır, NAT xəritəsi isə onu yaradan özəl ünvana, porta və açıq ünvana aiddir. Fərqli NAT-ın arxasına keçin və hər cavab artıq mövcud olmayan xəritəyə göndərilir. Maşınınızda heç nə səhv konfiqurasiya edilməyib; beşlik sizin tərk etdiyiniz şəbəkəni göstərir.
Nəzəriyyə qurmadan əvvəl vəziyyəti oxuyun:
ss -unphər tunel soketinin həqiqətən saxladığı yerli ünvanı və portu göstərir.ip route get 203.0.113.10kernelin son nöqtə üçün indi istifadə edəcəyi mənbə ünvanını və cihazı çap edir.wg show wg0 endpoints,swanctl --list-sasvə ya klient jurnalı uzaq tərəfin danışdığını düşündüyü peer ünvanını göstərir.
Soket ünvanı ilə marşrut axtarışı uyğun gəlmirsə, qırığı tapmısınız və heç bir etimad məlumatı dəyişikliyi ona toxunmayacaq.
Hər protokol yeni mənbə ünvanı ilə nə edir
Klientlər dəyişikliyi müxtəlif dərəcədə udur; mən də cədvəli klient konfiqurasiyası ilə müqayisə edirəm, yenidən qoşulma davranışından təxmin yürütmək əvəzinə.
| Tunnel | Recovery behaviour | Failure signature |
|---|---|---|
| WireGuard | Updates the peer endpoint when an authenticated packet arrives from a new address; no handshake needed if traffic continues. | Handshake current, no return traffic; wg show still lists the old endpoint. |
| IKEv2/IPsec | MOBIKE (RFC 4555) moves the SA to the new address; without it the responder discards packets from an unknown source. | DPD or keepalive timeouts, then a full rekey or a dead SA. |
| OpenVPN over UDP | --float accepts a packet from a new source mid-session; otherwise the session stays tied to the original peer address. | Idle until ping-restart fires, then a visible reconnect. |
| OpenVPN over TCP | The tunnel is a byte stream, so a changed source address breaks it outright. | Immediate reset and a new connection attempt. |
WireGuard-ın roam qaydası yalnız bir istiqamətdə işləyir: klient əvvəlcə yeni ünvandan göndərməlidir. Hələ köhnə interfeysə bağlı olan soket bunu heç vaxt etmir, buna görə tunel işlək görünə bilər, handshake taymeri isə qocalmağa davam edir. protokol təsviri son nöqtənin yenilənmə şərtini dəqiq göstərir və hər hansı konfiqurasiyanı dəyişməzdən əvvəl oxumağa dəyər.
MOBIKE razılaşdırılır, fərz edilmir. Server onu təklif etmirsə, klient yenidən qurmalıdır və bu, spinner-dən çıxarmaq əvəzinə SA siyahısından və ya jurnaldan təsdiqlədiyiniz faktdır.
Marşrut üstünlüyü yolu müəyyən edir, Wi-Fi ikonu deyil
Hər iki interfeys işləyərkən kernel metrik və prefiks uzunluğuna görə seçir. ip route show default namizədləri sadalayır və ip route get 203.0.113.10 mənbə ünvanı da daxil olmaqla real qərarı həll edir. Metriki 100 olan simli standart və 600 olan simsiz standart o deməkdir ki, kabel yerinə oturan anda son nöqtə köçür, əvvəllər soket açmış hər tətbiq isə köhnə mənbəyini saxlayır.
Windows eyni şeyi avtomatik interfeys metrikaları ilə edir, keçid sürətinə görə meyilləndirilir. Get-NetRoute -DestinationPrefix 0.0.0.0/0 namizədləri sıralayır və Find-NetRoute -RemoteIPAddress 203.0.113.10 yığının seçəcəyi interfeysi və mənbəni qaytarır. Xarici soketini bir interfeysə bağlayan klient metrikanın dönməsindən sonra da onu istifadə etməyə davam edir; bu, marşrut nasazlığı deyil, bağlama qərarıdır.
Android parçalanmanı görünən edir: ConnectivityManager mövcud şəbəkələri və ayrıca standartı bildirir, soketi Network obyektinə bağlayan VPN tətbiqi isə yenidən bağlayana qədər o bağlamanı saxlayır. macOS-da, scutil --nwi əsas interfeysi və sistemin istifadə edəcəyi sıranı çap edir.
DNS, MTU və IPv6 qoşulma ilə birlikdə hərəkət edir
Yeni qoşulma yeni həlledicilər gətirir. systemd-resolved ilə DNS hər keçid üçündür, resolvectl status hansı keçidin adı cavablandırdığını göstərir, öz həlledicisini verən qonaq şəbəkəsi isə keçid yenidən üstünlük qazanana qədər tunelin ötürdüyü DNS-i istifadəsiz qoya bilər. Captive portal işi pisləşdirir: ilk HTTPS sorğusunu son nöqtə əvəzinə portal cavablandırır və klient ölü server qeyd edir.
Yol MTU-su da dəyişir. Ethernet və Wi-Fi adətən 1500 bayt, PPPoE 1492, mobil keçidlər isə çox vaxt daha az daşıyır. Daha kiçik MTU miras alan tunel böyük paketlərdə donur, kiçik sorğular isə uğurlu olur, bu da yarımçıq qoşulma kimi oxunur. ping -M do -s 1472 203.0.113.10 DF qoyulmuş 1500 baytlıq paket göndərir; sükut yolun fərz etdiyinizdən kiçik olduğunu bildirir.
IPv6 digər yarıdır. Yeni prefiks verən şəbəkə ikili stack klientinin istifadə edəcəyi mənbəni dəyişir, yalnız v4 tunel isə siyasət yetişənə qədər v6 trafikini xaricdə qoyur. ip -6 route show default və ip -6 addr show yeni keçidin ümumiyyətlə v6 yolu olub-olmadığını cavablandırır.
Keçidi təsvir etmək əvəzinə onu təkrar istehsal edin
Bir zərərsiz sorğu seçin və dəyişikliyin hər iki tərəfində eyni üç əmri işlədin: ip -br addr, ip route show default, ip route get 203.0.113.10. Sonra tunelin hələ də paket buraxıb-buraxmadığını izləyin - tcpdump -ni any udp port 51820 WireGuard üçün, başqa hər şey üçün uyğun port. Köhnə mənbədən çıxan paketlər bağlama problemini bildirir. Yeni mənbədən çıxan və cavab almayan paketlər uzaq tərəfi və ya aradakı NAT-ı bildirir.
İlk nasazlıqla hansı hadisənin üst-üstə düşdüyünü qeyd edin: keçidin düşməsi, ünvanın dəyişməsi və ya standart marşrutun dəyişməsi. Bunlar fərqli sahiblərə işarə edir - yenidən bağlanmalı klient, yenidən alınmalı ünvan və ya daimi bypass qaydasına deyil, konfiqurasiya faylına aid marşrut.
Düzəldi deməzdən əvvəl birbaşa trafik blokunun boşluq boyunca hələ də qaldığını və adların yeni qoşulma ilə həll olunduğunu təsdiqləyin. Klient keçiddən sonra köhnə son nöqtəni saxlayırsa, əvvəlcə roam və ya float parametrini düzəldin. Düzgün roam edir və hələ də cavab almırsa, serverin peer kimliyinə və yoldakı NAT-a baxın, hər iki şəbəkə kontekstini yazıda saxlayın ki, növbəti şəxs onları müqayisə edə bilsin.