Kill-switch VPN serverini trafik axmadan əvvəl bloklayır
Kill-switch hansı mərhələni bloklayır: son nöqtə axtarışı, xarici marşrut, qayıdış yolu və köhnəlmiş həmkar istisnaları — təxminlər yerinə sayğaclarla.
Kill-switch gözlənilməyən istiqamətdə sıradan çıxır: onlar tunel söndüyü zaman trafiki bloklamaq üçün qurulub, tuneli quran paketlər isə özləri trafikdir. Bütün səhv bundan ibarətdir. Tuneldən çıxmayan hər şeyi atan qaydalar dəsti tuneli qaldıracaq əl sıxışmanı da atır, ona görə müştəri dövrədə yenidən cəhd edir və xəta ilk yoxlanılan mərhələyə aid edilir. Firewall-ı genişləndirməzdən əvvəl üç mərhələdən hansının rədd edildiyini öyrənin: ad axtarışı, həmkara gedən xarici paket və ya geri qayıdan cavab.
Tunel və onun öz nəqliyyatının bir-birindən asılılığı
VPN müştərisini eyni soket yolunu bölüşən iki şəbəkə vəziyyəti kimi oxuyun. Tunel yaranmazdan əvvəl müştəri fiziki adapterdə soket açır və şifrələnmiş kadrları həmkarın ünvanına və portuna göndərir. Yalnız bu mübadilə uğurlu olduqdan sonra tunel qurğusunu yaradır və marşrutları qurur. Kill-switch ikinci vəziyyətlə bağlı siyasətdir və o qədər geniş yazılıb ki, hər ikisinə şamil olunur.
İnterfeysə əsaslanan qaydalar adi formadır: bu yoldan çıxanı qəbul edin tun0 və ya wg0, qalan çıxış yolunu atın. Bu formalaşdırma müştərinin serverə öz bağlantısını istisna edə bilmir, ona görə düzgün tətbiq həmin istisnanı açıq şəkildə əlavə edir, siz də qaydaları əllə yazarkən bunu edirsiniz. Windows və macOS-da tətbiq üzrə qaydalar interfeys yerinə prosesi uyğunlaşdıraraq bunun bir hissəsindən yayınır, amma proses yenə də tunel yaranmazdan əvvəl çıxmalıdır.
Üç mərhələ, baş vermə sırası ilə
Birinci mərhələ həlldir. Profil hərfi ünvan yerinə host adı saxladıqda, müştəri heç nə göndərməzdən əvvəl DNS cavabına ehtiyac duyur. DNS-i tunel resolverinə yönəldən profil dalana gətirir: resolver yalnız axtarışın aktivləşdirməli olduğu tuneldən əlçatandır. Tuneldən kənarda həll etmək və ya son nöqtəni ünvana bərkitmək qeyri-müəyyənliyi aradan qaldırır.
İkinci mərhələ xarici paketdir; o, bu sıra ilə əvvəl marşrutlaşdırmadan, sonra firewall-dan keçməlidir. wireguard-tools bunun marşrut yarısını WireGuard üçün öz paketlərini işarələyib siyasət qaydası əlavə etməklə həll edir ki, onlar təzəcə quraşdırdığı default marşrutu ötsün; wg-quick təlimat səhifəsi həmin qaydayı və istifadə etdiyi cədvəli təsvir edir. Bu marşrutlaşdırmanı əllə yenidən qurun və ya qaydaları ikinci alətin yenidən yazmasına icazə verin, işarələnmiş paketlər yaratmalı olduqları tunelə geri göndərilə bilər.
Üçüncü mərhələ qayıdış yoludur. Cavabsız əl sıxışma çıxan atmanın sübutu deyil; o, serverin giriş qaydası və ya xəritələməni unutmuş NAT qurğusu ilə eyni dərəcədə uzlaşır. Müştəriyə toxunmazdan əvvəl bunları ayırın.
| What you see | Stage | Where to look |
|---|---|---|
| The client log repeats a resolve step and no packets appear on the wire | 1, name lookup | Resolver path while the tunnel is down |
| The send counter on the physical adapter stays flat | 2, routing | Peer route and policy rules |
| The send counter rises and a firewall drop counter rises | 2, firewall | Rule order, mark, and interface match |
| Packets leave and nothing comes back | 3, return path | Server input rules, NAT, listening port |
Müştərilər aşkar etdikləri simptomu qeyd edir, uğursuz olan mərhələni yox, ona görə cədvəl adətən jurnaladan sürətlidir.
Sayğaclar jurnallardan tez qərar verir
Linux-da, nft list ruleset və ya iptables -vnL OUTPUT hər qayda üçün paket sayğacı çap edir. Bir dəfə qoşulun, uğursuz olmasına icazə verin, sonra sayğacları yenidən oxuyun. Sayğacı dəyişən qayda əl sıxışmanın dəydiyi qaydadır; heç yerdə heç nə dəyişməyibsə, paket firewall-a heç vaxt çatmayıb. Mən qaydalar dəstinin öz əl sıxışmasını atdığını görmüşəm və bunu yalnız sayğaclar deyib.
Firewall-a heç vaxt çatmayanı hostdan heç vaxt çıxmayandan ayırmaq üçün interfeysin özünü izləyin. ip -s link show dev wlan0 göndərilən paketləri bildirir, və tcpdump -ni wlan0 udp port 51820 kadrları göstərir. Müştəri yenidən cəhd edərkən o düz qalırsa, nasazlıq netfilter-dən yuxarıdadır: çatışmayan həmkar marşrutu, hələ mövcud olmayan qurğuya yönələn siyasət qaydası və ya müştərinin udduğu soket xətası.
İstisnaları sənədləşmə ünvanları ilə sınaqdan keçirin, məsələn 203.0.113.10, beləliklə bir səhv başqasının hostunu yoxlaya bilməz.
Köhnəlmiş son nöqtə istisnası server nasazlığı kimi oxunur
Ən çaşdırıcı versiya həmkar ünvanı dəyişdikdən sonra ortaya çıxır: dinamik ünvan xidməti onu köçürüb, host yenidən qurulub və ya şəbəkənizin çıxış ünvanı fərqlidir. İstisna hələ də köhnə ünvanı göstərir, ona görə yenisinə gedən paketlər atma qaydasına dəyir. Eyni konfiqurasiya dünən işləyirdi, buna görə insanlar serverin diaqnostikasına başlayır.
Firewall qaydası daxilində host adı sizi xilas etmir. nftables-də ad qaydalar dəsti yüklənərkən həll edilir, ona görə o anda mövcud olan ünvanı bərkidir və hərfi ünvan kimi köhnəlir. Davamlı həll son nöqtə dəyişdikdə istisnanı yeniləmək və onu dar saxlamaqdır: bir həmkar ünvanı, bir nəqliyyat portu. Ünvan dəyişikliyinə dözmək üçün kifayət qədər geniş diapazon əlaqəsiz trafiki də buraxmaq üçün kifayət qədər genişdir.
Kill-switch server hostunda işləyəndə
Eyni asılılıq digər tərəfdə də var və orada onu qaçırmaq daha asandır. Əgər VPN serveriniz rolunu oynayan maşın həm də kill-switch ilə masaüstü müştəri və ya noutbukdan köçürülmüş firewall profili işlədirsə, onun atma qaydaları tunelləri sonlandıran xidmətə şamil olunur. Müştərinin əl sıxışmasına cavablar atılır, buna görə server sağlam görünərkən və tunel interfeysi istifadəsiz qalarkən hər müştəri qoşula bilmir.
Həmin host atma qaydasından əvvəl üç dar qəbul tələb edir: fiziki interfeysdə dinləmə portu, şifrəsi açılmış trafik üçün tunel interfeysi və tuneldən müştərilərin çatmalı olduğu yerə yönləndirmə. Quraşdırılmış dəsti bununla oxuyun: nft list ruleset, iptables -S, və ya pfctl -sr hər hansı dəyişiklikdən əvvəl, və yadda saxlayın ki, saxlanılan qaydalar dəsti yenidən başlatmadan sonra da qalır, ona görə oradakı səhv onu yaradan prosesdən uzun yaşayır.
Maşını bağlı saxlayan bərpa sırası
Profildən xaricə doğru işləyin. Müştərinin istifadə etdiyi həmkar ünvanını və portu oxuyun, host adının tunel olmadan həll olunduğunu təsdiqləyin, sonra yalnız fiziki adapterdə həmin ünvan və port üçün bir istisna əlavə edin. Yenidən qoşulun və göndərmə sayğacını izləyin; tamamlanmış əl sıxışma ikinci mərhələnin düzəldiyinin siqnalıdır.
Sınaq zamanı atma siyasətinin qalan hissəsini yerində saxlayın. Zərərsiz yoxlama əlaqəsiz sənədləşmə ünvanına qoşulmağa cəhd etmək və onun hələ də vaxt aşımına uğradığını təsdiqləməkdir ki, bu kill-switch-in söndürülmədiyini, işlədiyini göstərir. Tunel sabitləşdikdən sonra istisnanı sıxlaşdırın və rahatdır deyə müştəri proqramı üçün daimi hər şeyə icazə buraxmayın.
Tunel qalxır və tətbiq hələ də uğursuz olursa, qalan mərhələlər bu deyil: bölünmüş DNS, MTU və tətbiq üzrə marşrutlaşdırma hər biri qoşulmuş tunel və pozulmuş trafik yaradır və hər birinin ilk yoxlaması fərqlidir.