Wi-Fi-dən mobil şəbəkəyə keçiddən sonra kill-switch: nə pozulur

Bir anda noutbuk ofis Wi-Fi şəbəkəsindədir, bir anda telefondan qoşulub, və siz pəncərələri dəyişməyi bitirməmişdən tunel göstəricisi yenidən yaşıl olur. Yaşıl işıq yalnız tunelin yenidən qoşulduğunu bildirir; boşluq zamanı marşrutlaşdırma və bloklama siyasətinin nə etdiyi başqa sualdır. Həmin siyasət son quraşdırma zamanı tərtib edilmiş uyğunluq şərtləri toplusudur və keçidin indicə sildiyi interfeysi, ünvanı və ünvan ailəsini adlandırır. Ona görə eyni keçid eyni görünən üç nəticə verir: bloklama davam edir, siyasət öz bərpasını bloklayır, ya da heç nənin əhatə etmədiyi bir yol açılır.

Ekranda bu üç vəziyyəti heç nə ayırmır, ona görə göstəricinin hansı rəngi göstərdiyini deyil, qaydaların hansı identifikatorlara bağlandığını soruşun. Linux-da qayda interfeysi və ya ondan doldurulan ipset-i adlandıra bilər; Android-də VpnService-ə setUnderlyingNetworks vasitəsilə hansı əsas şəbəkələri izləyəcəyi deyilə bilər. Hər bağlama dəyişdirilmək üzrə olan linkə işarə edir və hər biri sonradan yenidən qiymətləndirilməlidir.

Keçid əslində nəyi yenidən yazır

Köhnə link yoxa çıxanda kernel onun ünvanlarını silir, ondan keçən marşrutları geri götürür və mənbə ünvan seçimini qalanlardan yenidən qurur. Defolt marşrut yeni şlüzə keçir, köhnə qaydaların istinad etdiyi interfeys indeksi isə ya yox olur, ya da başqa cihaz üçün təkrar istifadə edilir. Hər link üzrə həlledicilər də yenilənir, amma marşrutlarla eyni anda deyil. Bütün bunlar VPN müştərisinin altında baş verir, ona görə yalnız öz tunel vəziyyətinə baxan müştəri bunların heç birini görmür.

Problem budur ki, qayda arxasındakı məqsəd yerinə konkret identifikatoru kodlaşdırır. Tunel interfeysindən çıxmayan hər şeyi atan qayda interfeys adını kodlaşdırır; son nöqtəyə icazə verən qayda isə yeni şəbəkənin başqa yerə yönləndirə biləcəyi ünvanı kodlaşdırır. Identifikator yox olduqda qayda görünən şəkildə səhv olmur, ya heç nəyə uyğun gəlməyi dayandırır, ya da səhv şeyə uyğun gəlməyə başlayır.

Xarici tuneli deşik açmadan yenidən qurmaq

Xarici nəqliyyat köhnə mənbə ünvanına bağlanmışdı, ona görə yenisindən yeni soket açmalıdır. Son nöqtə hərfi ünvan deyil, host adı olduqda, blok hələ qüvvədə ikən axtarış uğurlu olmalıdır. Sıra tələsi budur: son nöqtədən başqa hər şeyi atmaq üçün kifayət qədər sərt siyasət onu tapmaq üçün lazım olan axtarışı da atacaq — əgər həll blok qaldırılmazdan əvvəl baş vermirsə və ya hələ canlı tuneldən keçirilmirsə. Hər iki sıra işləyə bilər, ancaq müştəri hansı sırada olduğunu bilirsə.

Müştərilər burada diaqnoz qoyarkən vacib olan bir şəkildə fərqlənir. Bəziləri əvvəl həll edir, sonra qaydaları qurur, ona görə keçid görünən kəsintiyə başa gəlir və sonra özü bərpa olunur; digərləri bloku saxlayır və axtarışı daşımaq üçün sağ qalan tunelə güvənir, bu isə tunel linklə birlikdə öləndə tamamilə uğursuz olur. Bağlantını bərpa etmək üçün geniş birbaşa defolt əlavə etmək testi həmişə keçirir və qarşısını aldığınız sızmanı həmişə saxlayır.

Hələ də köhnə şlüzə baxan marşrut fərqli səbəbdən eyni ilişib qalmış bərpanı verir, ona görə müştərini günahlandırmazdan əvvəl cədvəli oxuyun. Aşağıdakı əmrlər kernelin həqiqətən istifadə edəcəyi interfeysi və mənbə ünvanını adlandırır, bu da bir sətirdə köhnə yolun hələ qurulub-qurulmadığını həll edir.

ip route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

Yeni link IPv6 gətirəndə, qaydalar gətirməyəndə

Mobil və qonaq şəbəkələr çox vaxt qlobal IPv6 prefiksi verir, hətta ofisin kabel LAN-ı bunu heç vaxt etməmiş olsa da. Yalnız IPv4 qaydaları kimi yazılmış siyasət — əksər əl ilə yazılmış iptables və nftables reseptlərinin defolt forması — bunun heç birini əhatə etmir. Tunel qoşulu qalır, IPv6 əlçatanlığı olan tətbiqlər ondan kənara çıxır və göstərici fərqi göstərə bilmir, çünki tunel həqiqətən işləyir. Əks hal da eyni dərəcədə geniş yayılmışdır: yalnız IPv6 üçün qaydalar toplusu v6 təklif etməyən şəbəkədə heç nə etmir.

Linkin təklif etdiyini siyasətin qeyd etdiyi ilə keçidin hər iki tərəfində müqayisə edin. Bunlar müştərinin işlədiyi eyni faktları çap edir:

ip -4 route show default
ip -6 route show default
sudo nft list ruleset | grep -c 'ip6 '

Əgər ikinci əmr defolt marşrut çap edirsə, üçüncü isə sıfır qaytarırsa, yeni link maşını heç bir qaydanın izləmədiyi IPv6 ilə çıxara bilər. Keçiddən sonra üçünü də yenidən işə salın, çünki maraqlı rəqəm iki işə salma arasındakı fərqdir. Əgər ikinci heç nə çap etmirsə, tərs hal tətbiq olunur və hər hansı v6-ağır siyasət orada sadəcə bəzəkdir.

Həlledici sessiyanın ortasında əl dəyişdirir

Müasir sistemlərdə həlledicilər linklərə bağlanır, ona görə yeni link yeni həlledici dəsti və bəlkə də fərqli split-DNS görünüşü ilə gəlir. systemd-resolved hər link üçün bir scope saxlayır və aralarında marşruta görə seçir, macOS isə scoped həllediciləri dinamik anbardan oxuyur və interfeys sırasına riayət edir. Öz həlledicisini quran müştəri linkinkilə rəqabət aparır və heç kimin izləmədiyi prioritet qaydaları qalibi həll edir. Sonra ad həlli poza bilər, halbuki paket filtrləmə yazıldığı işi məhz yerinə yetirir.

Qurulmuş həlledici yerinə aktiv olanı oxuyun. systemd hostunda status alt əmri hər scope-un hansı linkdən gəldiyini və private-DNS adının qüvvədə olub-olmadığını göstərir:

resolvectl status --no-pager
resolvectl query intranet.example.com

Sorğu tuneldən deyil, fiziki linkdən çıxırsa, müştəri prioritet yarışını uduzub və heç bir firewall tənzimləməsi adlandırmanı düzəltməyəcək. Keçidin hər iki tərəfində sorğu yolunu müqayisə edib hansının yer dəyişdiyini görün. Yeni şəbəkənin yönləndirə bilmədiyi özəl ünvana həll olunan ad üçüncü haldır və xəta kimi deyil, timeout kimi görünür.

Keçidi məşq etdirin və qeydi saxlayın

Dəyişikliyi gözləmək yerinə qəsdən təkrar istehsal edin. Tuneli birinci linkdə qaldırın, uzunömürlü ötürmə və təkrar axtarış başladın, sonra linki dəyişin və hansının sağ qaldığına baxın. Köhnə linkin yoxa çıxması ilə tunelin qoşulduğunu bildirməsi arasındakı intervalı qeyd edin, çünki siyasətin dayandığı və ya dayanmadığı pəncərə elə həmin pəncərədir. Ardıcıllığı əks istiqamətdə də işə salın ki, nəticə birtərəfli olmasın.

İstisnalar öz keçidinə ehtiyac duyur, çünki köhnə şəbəkədə əsaslandırılmış bypass yenisində avtomatik əsaslandırılmır. Ev LAN-ındakı printer, NAS və ya captive portal-ın mobildə qarşılığı yoxdur və ora çatan istisna da qarşılığı olmayan qaydaya çevrilir.

Hər istiqamət üçün interfeys adlarını, təklif olunan ailələri, qüvvədə olan həlledicini və kəsintinin uzunluğunu yazın. Yenidən qoşulma nəqliyyatın bərpa olunduğunu sübut edir, boşluq zamanı blokun dayandığını yox, və bunlar biletdə ayrı iddialardır. Bu qeydlə növbəti keçid yaddaşla deyil, bilinən vəziyyətlə müqayisə olunur.