WireGuard tam tunel: AllowedIPs 0.0.0.0/0 kifayət etmir

Peer-in AllowedIPs sahəsinə 0.0.0.0/0, ::/0 yazmaq hamının xatırladığı addımdır və yalnız peer-in hansı trafiki daşımasına icazə verildiyini müəyyən edir. Bu prefikslər heç bir marşrut yaratmır, o biri tərəfdə heç nə yönləndirmir və hər tətbiqin resolver-ini olduğu yerdə saxlayır. Tam tunelin tam tunel olması üçün dörd ayrı şey eyni vaxtda doğru olmalıdır və onları aşağıdakı ardıcıllıqla yoxlamaq yaxşıdır, çünki sonrakı yoxlama əvvəlkini xilas edə bilməz. Aşağıdakı hər yoxlama maşından oxuna bilən bir faktdır, tətbiq olunduğuna ümid etdiyiniz bir parametr deyil.

Peer prefiksinin nə seçdiyi və nə seçmədiyi

AllowedIPs həm seçici, həm də icazə vericidir. Yerli tərəfə hansı təyinatların bu peer-ə göndərilə biləcəyini, qəbul edən tərəfə isə bu peer-in hansı mənbə ünvanlarını təqdim edə biləcəyini bildirir. Bütün iş bundan ibarətdir. Bu təsvirdə hostda marşrut yaradan, uzaq tərəfdə yönləndirməni aktivləşdirən və ya ad həllinə toxunan heç nə yoxdur.

Buna görə də konfiqurasiya tam görünə və split tunel kimi davrana bilər. Prefiks peer-in hər şeyi qəbul edəcəyini deyir; host-un marşrut cədvəli oraya həqiqətən nə çatdığını, şlüz isə nəyinsə çıxıb-çıxmadığını həll edir. Bu üç qərardan heç biri peer bölməsində yaşamır.

Müştərini yönləndirmək, yalnız peer siyahısını deyil

Məsələn, wg-quick kimi menecerlər host-un marşrut cədvəlini sizin üçün proqramlaşdırır, buna görə də iki eyni konfiqurasiya faylı interfeysin necə qalxdığından asılı olaraq fərqli davranır. Minimal profil bir dəfəyə oxunacaq qədər qısadır:

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.net:51820

İşi iki detal daşıyır. Address sahəsi müştərinin sahib olduğuna inandığı subnet deyil, tək host prefiksidir, və default AllowedIPs-i real default marşruta çevirən menecredir. Eyni faylı ip link və wg setconf ilə qaldırın və heç bir marşrut görünmür, bu sınıq tunel kimi görünür, əslində isə marşrut addımı atlanmış sağlam tuneldir. wg-quick təlimatı yönləndirməni və Table davranışını sənədləşdirir.

Nəticəni fayl yerinə oxuyun: ip route get 1.1.1.1 tunel interfeysini göstərməlidir və wg show hərəkət edən ötürmə sayğacı ilə son handshake göstərməlidir. Marşrutsuz handshake menecerin heç vaxt işləmədiyini bildirir və profili yenidən redaktə etmək bunu düzəltməyəcək. İnterfeysi istifadəçinin başladacağı şəkildə başladın, əks halda test deployment-i deyil, sizin shell-inizi ölçür.

Endpoint-i tuneldən kənarda saxlamaq

Tam tunel hər təyinatı tutur, o cümlədən mövcud olmaq üçün danışmalı olduğu təyinatı. Menecerlər bunu endpoint üçün orijinal şlüz vasitəsilə host marşrutu əlavə etməklə həll edir, buna görə də düzgün konfiqurasiyada demək olar ki, həmişə bir qəsdən edilmiş istisna olur. Konfiqurasiyanın yarısını menecer, digər yarısını əl ilə tətbiq etmək bu istisnanın itməsinin adi yoludur.

Endpoint bir neçə ünvana və ya daşımadığınız ailəyə həll olunan host adıdırsa, istisna pis köhnəlir və tunel adi görünən yenidən qoşulmadan sonra uğursuz ola bilər. Endpoint-i nəzarət etdiyiniz ünvana bağlayın və ya menecerin onu yenidən qiymətləndirdiyini təsdiqləyin, və hər şəbəkə dəyişikliyindən sonra host marşrutunu yenidən oxuyun.

Eyni mexanizm tam tunelin niyə captive portal ilə toqquşduğunu izah edir. Portal tunelinizin indi tutduğu trafiki kəsməyi gözləyir, buna görə otel və hava limanı şəbəkələrində tuneli portal girişindən sonra qaldırırsınız, heç vaxt əvvəl deyil.

Şlüzdə yönləndirmə və cavab yolu

Şlüzdə daşıdığınız ailə üçün yönləndirməni aktivləşdirin, tərcümə edərkən forward zəncirinə hər iki istiqamətdə icazə verin və mənbəyə xas axtarışla qayıdış yolunu təsdiqləyin. Bunların heç biri uğurlu handshake-dən irəli gəlmir, çünki handshake yalnız iki peer-in UDP mübadilə edə bildiyini sübut edir. Dekapsullaşdırılmış paketin sonra nə olacağı barədə heç nə demir.

sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
ip route get 1.1.1.1 from 10.8.0.2

Axtarış müştəridə deyil, şlüzdə aparılır, əks halda başqa marşrut cədvəlini oxuyursunuz. Səhv interfeysi göstərirsə və ya marşrut yoxdur deyirsə, o zaman heç bir müştəri tərəfi dəyişikliyi internet çıxışı yaratmayacaq. Şlüz çıxışda müştəri ünvanlarını tərcümə etdikdə cavab həmin tərcümə vəziyyətindən asılıdır, buna görə qayda axının yalnız gedən istiqaməti üçün deyil, hər iki istiqaməti üçün mövcud olmalıdır.

DNS və uğursuzluq vəziyyəti, ayrıca yoxlanılır

Protokolun özü heç bir tətbiqin resolver-ini konfiqurasiya etmir. wg-quick distribusiyanın resolver inteqrasiyası vasitəsilə DNS sətrini tətbiq edir, öz stack-ləri olan konteynerlər və brauzerlər buna məhəl qoymaya bilər, və buna görə tunel paketləri mükəmməl daşıyarkən ad uğursuz ola bilər. Ünvan yerinə host adı ilə yoxlayın və profildəki serverin cavab verdiyini fərz etmək yerinə hansı serverin cavab verdiyini qeyd edin.

Ünvan ailələri ayrı cavabı olan ayrı bir testdir. v4 default tətbiqin v6 bağlantısının nə edəcəyi barədə heç nə demir və ikinci ailəni səssizcə sızdıran tunel ucadan uğursuz olan tuneldən pisdir. Hər ailə üzərindən ad sorğulayın, hər sorğunun istifadə etdiyi interfeysi oxuyun və tərcümə sayğaclarını əvvəl və sonra yoxlayın, çünki heç nəyə uyğun gəlməyən qayda çatışmayan qayda ilə eyni görünür.

Nəhayət, tunel dayandıqda istədiyiniz vəziyyəti yoxlayın. Tam tunel iddia etdiyi trafik üçün qapalı uğursuz olmalıdır: interfeys düşərsə və tətbiqlər fiziki link üzərindən səssizcə davam edərsə, dizayn əlavə addımlarla split tuneldir. Nəzərdə tutulan uğursuzluq davranışını yazın, onu qəsdən yoxlayın və dörd cavabı qeyd edərək bitirin — hansı menecer interfeysi qaldırır, hansı marşrut default-u daşıyır, şlüzdə kim yönləndirir və tərcümə edir, və hansı resolver cavab verir.