IPv6 trafiki VPN-dən, yoxsa birbaşa keçməlidir?

Keçən ay iki nəfər məndən əks nəticələr istədi: biri IPv6-nın VPN ilə əhatə olunmasını, digəri ofis printerinin işləməyə davam etməsini istəyirdi. Tək bir ::/0 marşrutu hər ikisini özü təmin edə bilməz. Bu marşrutun tunelin içində olub-olmadığı üç şərtdən asılıdır və birinci şərt onu əksər kommersiya çıxışları üçün istisna edir. Çıxış IPv6 daşımırsa, standart marşrutu ona yönəltmək trafikinizi göndəriləcək yeri olmayan tuneldə gizlədir.

Cavabı üç şərt müəyyən edir

Standart marşrut bir sətirdir, ::/0, və daha dəqiq marşrutu olmayan istənilən IPv6 təyinatına uyğun gəlir (RFC 4291). Onu quraşdırmaq asandır. Bunu etməli olub-olmadığınıza qərar vermək üç şərtə bağlıdır.

Birinci şərt: qoşulduğunuz çıxışda işlək IPv6 var və onu ötürməyə hazırdır. İkinci şərt: müştəriniz tunel son nöqtəsinə yol saxlayır; bu nöqtə adətən yönləndirmək üzrə olduğunuz aralığın içində yerləşir. Üçüncü şərt: tuneldən kənarda qalmalı olan yerli IPv6 təyinatlarını adlandıra bilirsiniz.

Hər şərt öz üsulu ilə uğursuz olur; buna görə təxmin etmək bir axşama başa gəlir. Uğursuz birinci şərt sizə səssizlik və düzgün görünən marşrut cədvəli verir. Uğursuz ikinci şərt əl sıxışmanı başladıqdan bir neçə saniyə sonra öldürür. Uğursuz üçüncü şərt işlək tunel və printerin yanında narazı bir həmkar qoyur.

Çıxış həqiqətən IPv6 daşıyırmı?

IPv6 ünvanı olan tunel interfeysi o tayla bağlı heç nə sübut etmir. Bir çox kommersiya profili içəridə yalnız IPv4-dür: server sizə v4 ünvanı verir və qalan hər şeyi atır. Üstəlik AllowedIPs-dən standart marşrut qurun və nüvə IPv6-nı həmyaşıdının heç vaxt görmədiyi interfeysə məmnuniyyətlə göndərəcək.

Tunel qalxarkən müştəridən sınaqdan keçirin. ping -6 -c 3 2001:4860:4860::8888 və ip -6 route get 2001:4860:4860::8888 fərqli suallara cavab verir: cavab qayıdırmı və nüvə hansı cihazı seçdi. İkincisi tunelinizi göstərdikdə, birincisi heç nə qaytarmadıqda problem marşrutda deyil, çıxışdadır.

Çıxışı özünüz idarə edirsinizsə, müştəri sınağı keçə bilər, amma yol yenə də çıxılmaz qalır. Şlüz qovşağında net.ipv6.conf.all.forwarding=1 olduğunu və onun firewallunun tuneldən ötürülən paketləri qəbul etdiyini təsdiqləyin. Ötürməyi rədd edən çıxışa düzgün yönləndirilmiş paket müştəri tərəfindən məhz marşrut xətası kimi görünür.

Müştəri son nöqtəyə yolunu saxlaya bilirmi?

Bu, məni yalnız IPv6 işləyən WireGuard son nöqtəsi olan noutbukda tutan haldır. Son nöqtənin ünvanı adi qlobal ünvandır, deməli ::/0-ın içindədir. Bütün prefiksi interfeysə yönəldin və əl sıxışma paketləri hələ qurmağa çalışdıqları tunelin içinə özlərini qovacaq. Tunel heç vaxt qalxmır və müştəri çıxışında bunun səbəbi deyilmir.

wg-quick Linux-da bunu həll edir. Marşrutları AllowedIPs-dan çıxarır, öz cədvəlinə yerləşdirir və son nöqtəyə trafikin əvvəlcə əsas cədvəl vasitəsilə həll olunması üçün siyasət qaydası əlavə edir: suppress_prefixlength 0 qaydası, onu ip -6 rule-da tapırsınız. Buna görə wg-quick up orada uğur qazanır, əl ilə yazılmış ip -6 route add default dev wg0 isə sizi kəsir.

Hər iki vəziyyəti ip -6 route get <endpoint-v6> ilə yoxlayın, tuneli qaldırmazdan əvvəl və sonra. Cavab tunel cihazınıza dəyişirsə, tunelin ehtiyac duyduğu yolu silmisiniz. Marşrutları özünüz yazdıqda son nöqtə üçün ilkin şlüz vasitəsilə host marşrutu əlavə edin, ya da son nöqtəyə IPv4 üzərindən qoşulun və IPv6-nı yükə buraxın.

Tuneldən kənarda nə qalmalıdır?

Daha dəqiq marşrutlar standartı üstələyir, buna görə öz marşrutu olan on-link prefiks və ya ULA aralığı əlavə səy olmadan işləməyə davam edir. Bu, bir çox tam tunel IPv4 quruluşunun yaşamasının sakit səbəbidir: LAN prefiksləri standartdan daha dəqiqdir və heç vaxt tunelə girmir.

Yerli cihaz qlobal ünvanla əlyetərli olduqda bu pozulur; bu, eyni routerin açıq prefiks verdiyi printer, NAS və ya televizor üçün normaldır. Həmin ünvanlar ::/0-a uyğun gəlir, başqa heç nəyə yox, ona görə də hər şeylə birlikdə tunelə keçir və yox olur.

Protokola görə deyil, təyinat üzrə qərar verin. İki-üç yerli host vacibdirsə, onların prefikslərinə fiziki interfeysdən çıxış marşrutu verin və ya danışıqlar dəstindən çıxarın. Siyahı böyüməyə davam edirsə, dürüst cavab yazılı istisna siyahısı ilə IPv6 üçün bölünmüş tuneldir, davamlı yamaq vurduğunuz standart deyil.

Cavab xeyrdirsə, bloklayın

IPv6-nı marşrutsuz buraxmaq onu tək buraxmaqla eyni deyil. İşlək IPv6 standartı olan host tunel IPv4 daşıyarkən ondan istifadə etməyə davam edir, buna görə trafik VPN-in yanından çıxır və IPv6-ya üstünlük verən hər xidmət real ünvanınızı görür. Bu sızıntıdır, bölünmüş tunel deyil.

Birini seçin və hansını seçdiyinizi yazın. Standartı yönəldin və yuxarıdakı güzəştləri qəbul edin, ya da tunel müddətində IPv6-nı söndürün. Prefiksi AllowedIPs-dan çıxarmaq tək başına kifayət etmir, çünki əməliyyat sistemi öz standartını saxlayır. Linux-da kobud variant sysctl -w net.ipv6.conf.all.disable_ipv6=1-dır; incə variant IPv6-nı firewall qaydası ilə tuneldən kənarda atır. Telefon müştəriləri eyni işi görən açıq IPv6 bloklama açarı ilə gəlir.

Sızıntı kimi yoxlayın

Tuneli qaldırın və açara güvənmək əvəzinə vəziyyəti oxuyun. ip -6 route show default bir standart göstərməlidir və ip -6 route get yerli şəbəkənizdən kənar təyinat üçün tunel cihazını adlandırmalıdır. Bağlantı kəsiləndən sonra hər ikisini təkrarlayın: tuneldən uzun yaşayan standart axtardığınız xətadır.

Sonra digər istiqaməti sınaqdan keçirin. Yerli şəbəkədəki hostdan müştəriyə onun yerli IPv6 ünvanı ilə çatın. Bu işləməyi dayandırırsa, o vaxt marşrut cədvəli nə deyirdisə də, üçüncü şərt heç vaxt ödənilməmişdi.

Nəticəni növbəti şəxsin tapa biləcəyi yerə yazın: hansı prefikslər yerli qalır, niyə və müştəri bağlantı kəsiləndən sonra nə edir. Runbook-dakı iki sətir növbəti mühəndisi gecə yarısı son nöqtə döngəsini yenidən kəşf etməkdən xilas edir.