WireGuard handshake işləyir, internet yoxdur: paketi izləyin
Handshake yalnız açarları və əlçatanlığı sübut edir. AllowedIPs-dən başlayıb yönləndirmə, NAT və geri marşrut boyunca bir paketi izləyin ki, harada dayandığını görəsiniz.
Tunel işləkdir, wg show təzə handshake göstərir, serverin tunel ünvanına ping edə bilirsiniz və ondan sonra heç nə cavab vermir. İnsanın ilk istəyi açarları yenidən yaratmaq və ya konfiqurasiyanı yenidən paylaşmaqdır. Bu isə yolun artıq işlədiyi sübut olunmuş yeganə hissəsini dəyişdirir.
Tamamlanmış handshake iki peerin açarlar barədə razılaşdığını, UDP-nin endpoint-ə çatdığını və kripto marşrutlaşdırmasının paketi qəbul etdiyini bildirir. Paketin sonra serverdən çıxa bilib-bilmədiyi barədə isə heç nə demir.
Yəni təxmin etmək yerinə bir paketi izləyin. Onun ölə biləcəyi dörd yer var və hər biri fərqli iz buraxır.
Handshake əslində nəyi sübut edir
WireGuard UDP protokoludur: Noise handshake ilə sessiya qurur və sonra peer üçün paketləri şifrələyir. wg show bir neçə saniyəlik handshake və artan ötürmə sayğacı göstərirsə, endpoint, açarlar və peerin açıq açarı hamısı düzgündür.
Sübut etmədiyi odur ki, klientiniz internetə gedən trafiki ümumiyyətlə interfeysə göndərir, server onu yönləndirməyə hazırdır və ya cavab geri yol tapa bilir. Bunlar kernel marşrutlaşdırması və firewall qərarlarıdır və tuneldən kənarda verilir.
Serverin tunel ünvanına ping etməyin bu qədər aldadıcı test olmasının səbəbi budur. Həmin paket serverin özünə ünvanlanıb, ona görə də yerli olaraq bitir. Heç vaxt yönləndirməyə, heç vaxt tərcüməyə və heç vaxt internetdən geri marşrutuna ehtiyac duymur.
AllowedIPs marşrut qərarıdır
Klientdə AllowedIPs iki iş görür. O, hansı təyinat ünvanlarının bu peerin tunelinə göndərildiyini müəyyən edən kriptoaçar marşrut cədvəlidir və peerin sizdən qəbul edəcəyi mənbə ünvanlarının siyahısıdır. Klient konfiqurasiyasında yalnız 10.8.0.0/24 göstərilibsə, ictimai təyinatlar interfeysə heç vaxt daxil olmur və adi default marşrutunuz onları tuneldən kənarda daşıyır. Onda tunel mükəmməl işləyir və istədiyiniz heç nəyi etmir.
Konfiqurasiya faylının dediyinə deyil, klientin həqiqətən quraşdırdığına baxın:
wg show wg0 allowed-ipsip route get 1.1.1.1
İkinci əmr həlledicidir. Cavab fiziki interfeysinizi və adi şlüzü göstərirsə, paket tuneldən keçmir və server tərəfindəki heç bir dəyişiklik bunu düzəltməyəcək. IPv4 üçün 0.0.0.0/0, IPv6 üçün ::/0 ayrıca əlavə edin; bir ailə üçün hər şeyi tutan qayda digərini öz yolunda qoyur və bu, işlək IPv4 tuneli ilə dayanmış IPv6 axtarışının geniş yayılmış səbəbidir.
Paket şlüzdə harada ölür
Marşrut düzdürsə və paket yenə heç yerə getmirsə, o, serverə çatır və orada dayanır. Dörd yoxlama əksər şlüzləri əhatə edir.
Yönləndirmə. sysctl net.ipv4.ip_forward əmrinin 0 qaytarması klassik cavabdır və bir çox distributiv hələ də standart olaraq 0-dadır. O, 1 olmalıdır və yenidən başlatmada yox olan əmr yerinə sysctl drop-in faylında davamlı qoyulmalıdır. IPv6 yönləndirməsi ayrıca açardır.
Filtr siyasəti. Standart drop siyasəti olan FORWARD zənciri tuneldən keçən trafiki atacaq, hostun özünə gedən trafikə isə icazə verəcək, bu da simptoma tam uyğun gəlir. Saxlanmış faylı deyil, canlı qaydalar dəstini oxuyun: nft list ruleset və ya iptables -S.
Tərcümə və ya marşrutlaşdırma. Şəxsi tunel ünvanlarından istifadə edən klientlərə ya serverin çıxış interfeysində mənbə NAT, ya da yuxarı şəbəkənin geri qaytarmağı bildiyi marşrutlaşdırılmış prefiks lazımdır. Aralarındakı seçim ünvan planına uyğun edilir. Prefiksi artıq geri marşrutlaşdıran şəbəkəyə MASQUERADE əlavə etmək zərərsiz, lakin faydasızdır; heç bir marşrut olmayan yerdə onu buraxmaq isə cavabları marşrutsuz şəxsi diapazona ünvanlanmış qoyur.
Geri yol. Marşrutlaşdırılmış dizaynlarda yuxarı router-ə serverinizə işarə edən marşrut lazımdır. Provayder şəbəkəsi də bunu bloklaya bilər: bir neçə bulud instansiyada mənbə və təyinat yoxlamasını aktivləşdirir və bu yoxlama söndürülənədək mənbəyi instansiyanın öz ünvanı olmayan paketləri səssizcə atır.
DNS marşrutlaşdırmadan fərqli şəkildə sıradan çıxır
Məlum ünvana gedən paket və ad axtarışı ayrı-ayrı nasazlıqlardır və xəta mesajları əks istiqamətlərdə yanıldır. ping 1.1.1.1 işləyirsə və brauzer heç nə yükləyə bilmirsə, marşrut qaydasındadır, ad həlli deyil. Ping özü uğursuz olursa, DNS əhəmiyyətsizdir və əvvəlki bölməyə qayıtmısınız.
wg-quick konfiqurasiyadakı DNS = sətrindən resolver təyin edə bilər və systemd-resolved-un hər keçid üçün öz davranışı var. Resolver-i yalnız tunelin içindən əlçatan ünvanla əvəz edən VPN tunel düşən anda hər axtarışı uğursuz edəcək və bu, tunelin interneti pozması kimi görünür.
| Symptom | Layer to inspect |
|---|---|
| Tunnel address pings, nothing else does | Client route, then gateway forwarding |
| Public IP pings, hostnames fail | Resolver selection and reachability |
| Handshake completes, no reply ever | FORWARD policy or missing NAT on the server |
| Small requests work, large transfers stall | MTU and TCP MSS clamping |
Sübut verən bir sıra
Əvvəlcə klient tərəfindəki yoxlamanı aparın, çünki bu bir əmrdir və ehtimalların yarısını aradan qaldırır. Sonra serverin ümumiyyətlə internet çıxışı olmaq üçün qurulduğunu təsdiqləyin; şəxsi giriş üçün qurulmuş şlüz ictimai təyinatlar uğursuz olduqda pozulmuş sayılmır.
Serverdə klientdən ping göndərərkən interfeysə baxın: tcpdump -ni wg0 icmp sorğunu göstərməlidir, tcpdump -ni eth0 icmp isə onun çıxdığını göstərməlidir, tərcümə olunsun və ya olunmasın. Birincidə görünüb ikincidə heç görünmürsə, dayanma serverin özündədir. Çıxır və heç bir cavab qayıtmırsa, problem yuxarıdadır və bu, başqa söhbətdir.
Nəhayət, düzəlişin yenidən başlatmadan sonra da qalmasını təmin edin. Yönləndirmə sysctl faylına, firewall qaydaları onları yükləyən xidmətə, klient marşrutları isə interfeysi qaldıran konfiqurasiyaya aid olmalıdır, unudacağınız bir shell-ə deyil. Yenidən qoşulun, eyni iki testi təkrarlayın və sayğacların hərəkət etdiyini təsdiqləyin.