Əlaqə kəsici yalnız IPv4-ü bloklayır: IPv6 niyə hələ də çıxır

Tunel düşür, əlaqə kəsici işə düşdüyünü bildirir və yükləmə davam edir. IPv4 qaydalarında heç nə pozulmayıb. Tətbiq sadəcə həmin qaydaların heç vaxt yazılmadığı bir yola keçib.

İki protokollu cihazların iki müstəqil çıxış yolu var. Onlardan birini bloklamaq yarım blokdur.

İki qayda dəsti, iki defolt

Linux-da iptables və ip6tables ayrı siyasətləri olan ayrı cədvəllərdir. IPv4 cədvəlinin INPUT və OUTPUT zəncirlərini DROP-a qoymaq IPv6 cədvəlində heç nəyi dəyişmir, orada defolt adətən ACCEPT-dir. Eyni bölünmə nftables-da da mövcuddur; orada bir ailəni yoxlayıb görə bilərsiniz ki, qaydalarınızı yalnız biri daşıyır. Bu asimmetriya normaldır və bütün problem də elə budur.

Buna görə də əlaqə kəsici hərtərəfli görünə və qismən davrana bilər. IPv4 qaydalarını yazan skript işlədi, sayğaclar artır, log sətri görünür və IPv6 paketi fiziki interfeysdən tamamilə toxunulmadan çıxır.

Müştərinizin həqiqətən quraşdırdığını oxuyun, marketinq səhifəsinin vəd etdiyini deyil. Bəzi müştərilər IPv6-nı tunelə yönləndirir, bəziləri onu qəsdən bloklayır, bəziləri isə platforma səviyyəsində kilid başqa qayda tətbiq edərkən onu toxunulmaz qoyur. Burada etibar etməyə dəyər yeganə mənbə istehsalçının sənədləridir.

İnterfeys konfiqurasiyası sizə nə deyir

wg-quick-in təlimat səhifəsi IPv6 qaydalarını nümunə konfiqurasiyasına daxil edir və səbəb məhz bu boşluqdur. Nümunə bəzək deyil. O, ona görə mövcuddur ki, tək IPv4 qaydaları ikinci ailəni açıq buraxardı.

Nümunənin yarısını köçürmək siyasətin yarısını yaradır. Bu, bu sızmanın ən çox yayılmış mənbəyidir. Bir blog yazısı nümunəni uzunluq üçün qısaldıb. Sonra qısaldılmış versiya hamının yenidən istifadə etdiyi şablona çevrildi.

# what is actually installed, per family?
sudo iptables -S OUTPUT | head -20
sudo ip6tables -S OUTPUT | head -20

# nftables: inspect each family separately
sudo nft list ruleset inet | head -40

# does this host even have a usable IPv6 path?
ip -6 route show default

Əgər ikinci əmr icazəverən siyasət çap edirsə, birinci isə DROP çap edirsə, müştəriyə toxunmadan cavabı tapmısınız. Bu asimmetriya səhvdır.

Niyə bir axtarış bütün hekayə deyil

Bir ad həm A qeydi, həm də AAAA qeydi qaytara bilər və tətbiqlər hamısı eyni cür seçim etmir. Brauzer şəbəkə təklif edəndə IPv6-ya üstünlük verib uğursuzluqda geri qayıda bilər, fon sinxronizasiyası və ya yeniləyici isə öz həlledicisini və öz üstünlüyünü istifadə edir. Buna görə IPv4 üzərində bir uğurlu sınaq bir yolu sübut edir, siyasəti deyil.

Şəbəkə keçidləri də cavabı dəyişir. Başqa Wi-Fi şəbəkəsinə qoşulmaq, yuxudan oyanmaq və ya mobil şəbəkəyə keçmək cihaza yeni IPv6 prefiksi verə bilər və ofis LAN-ında kifayət görünən siyasət onu əhatə etməyə bilər.

Tunelin söndüyü vəziyyəti sınayın

Qoşulmuş halda sınaq tunelin işlədiyini söyləyir. Maraqlı sınaq əlçatmaz vəziyyətdir, çünki əlaqə kəsicinin dayanmalı olduğu an məhz odur. Tuneli qəsdən dayandırın, sonra qoruduğunuz tətbiqdən vacib təyinatları yoxlayın.

# with the tunnel stopped, does anything still leave?
ip -6 route get 2606:4700:4700::1111
curl -6 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv6.example.net/
curl -4 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv4.example.net/

Hər iki ailə qapalı şəkildə uğursuz olmalıdır. IPv4 sorğusu vaxt aşımına uğrayırsa və IPv6 sorğusu status kodu qaytarırsa, siyasət natamamdır və tuneli nə qədər yenidən sınasanız da bu dəyişməyəcək.

Sənədləşdirilmiş istisnaları da həmin sınaqda saxlayın. Yerli şəbəkə kəşfi, DHCP yenilənməsi və ya VPN son nöqtəsinə bootstrap yolu əlçatan qalmalı ola bilər və bu istisnalar kəsinti zamanı aşkar edilmək əvəzinə siyasətdə adlandırılmalıdır. Tunel yenidən qalxa bilmədiyi üçün uğursuz olan sızma sınağı təhlükəsizlik tapıntısı deyil, bağlantı tapıntısıdır.