İkiqat yığımlı VPN: adres ailəsini siz deyil, müştəri seçir

Tunel işləyir, IPv4 saytları açılır, bir host adı isə vaxt aşımına uğrayır. Dərhal çıxarılan nəticə VPN-in xarab olduğu və ya etimad məlumatlarının səhv olduğudur, halbuki adətən heç biri doğru deyil. Ad həm IPv4, həm də IPv6 ünvanı qaytardı, tətbiq birini seçdi və həmin namizədlərdən yalnız birinin işlək yolu var idi. Seçimi müştəri etdi; tunel sadəcə seçilən ünvanı əhatə etmirdi.

Seçim əhatə zəmanəti deyil

RFC 6724-də təsvir olunan standart ünvan seçimi bir neçə variant olduqda hostun hansı mənbə və təyinat cütünə üstünlük verəcəyini müəyyən edir. Happy Eyeballs bunun üzərinə əlaqə strategiyası əlavə edir: hər iki ailədə cəhdlərə başlayır və ilk cavab verəni saxlayır, belə ki istifadəçi xarab ailənin vaxt aşımını gözləmir.

Heç bir mexanizm marşrut yaratmır. Tuneliniz yalnız IPv4 daşıyırsa, AAAA namizədi yenə də müştərinin cəhd edə biləcəyi qanuni təyinatdır və nasazlıq xəta kimi deyil, yavaş yüklənmə kimi görünür, çünki brauzer geri çəkildi. İstifadəçi xarab deyil, yavaş sayt barədə məlumat verir və dəstək bileti bu qeyri-müəyyənliyi miras alır. Problemi sabit ailə ilə təkrarlayın və hesabat dəqiqləşər.

Bu geri çəkilmə simptomun tətbiqlər arasında qeyri-sabit olmasının səbəbidir. Brauzer gecikməni gizlədir; sabit ailəli əmr sətri müştərisi isə real nasazlığı dərhal göstərir.

Sorğunun həqiqətən istifadə etdiyi ailəni tapın

Tuneldən deyil, addan başlayın. Hər iki qeyd növünü sorğulayın və nə qayıtdığını qeyd edin:

dig +short A example.com
dig +short AAAA example.com
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://example.com
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://example.com

v4 sorğusu uğur qazanıb v6 sorğusu uğursuz olursa, problemi ayıklaya biləcəyiniz formada təkrarlamısınız. Hər ikisi qabıqdan uğur qazanır, brauzer isə yenə uğursuz olursa, tunelə toxunmadan əvvəl tətbiqin öz həlledicisinə və ya keşlənmiş cavaba baxın.

Ailəni və təyinatı qeydlərinizdə saxlayın. Saytın VPN üzərindən açılmadığını deyən bileti heç kim yoxlaya bilməz, AAAA-nın uğursuz, A-nın işlək olduğunu deyən bilet isə konkret marşruta işarə edir.

Həmin ailə üçün marşrutu yoxlayın

Uğursuz ailə üçün nüvədən hansı yolu istifadə edəcəyini soruşun və onu tunelin konfiqurasiya edilmiş ünvanları ilə müqayisə edin. Linux-da ip -6 route get təyinat üçün seçiləcək interfeysi və mənbəni göstərir.

Sonra tunelin özünü yoxlayın. WireGuard həmyaşıdları icazə verilən IP-lər siyahısı daşıyır və 0.0.0.0/0 üçün qeyd IPv6 barədə heç nə demir. Həmyaşıdın siyahısında IPv6 prefiksi yoxdursa, müştərinin AAAA trafikini tunelə göndərməsinə əsas qalmır və paket hostun başqa cür edəcəyi yoldan çıxır.

Firewall qaydaları və NAT siyasəti hər ailə üzrə eyni yoxlamaya layiqdir. IPv4 üçün yazılmış qayda heç bir platformada IPv6-nı əhatə etmir və bu, bir ailənin işləyib digərinin işləməməsinin ən çox rast gəlinən səbəbidir.

Ekran şəklini sadələşdirmək üçün IPv6-nı söndürməyin

IPv6-nı sistem səviyyəsində söndürmək simptomu yox edəcək və sizi diaqnozsuz qoyacaq. O, həm də yalnız IPv6 ilə işləyən istənilən təyinatı pozur və eyni xətanı növbəti tətbiq üçün gizlədir. Əgər maşın həqiqətən IPv6 istifadə etməməlidirsə, bu, sahibi və testi olan qəsdən verilmiş siyasətdir. Hadisə zamanı onu söndürmək heç biri deyil.

Müştərinin ailə ilə nə etməli olduğunu qərar verin və bunu açıq şəkildə konfiqurasiya edin: onu tuneldən keçirin və ya dəstəklənən üsulla bloklayın ki, seçim heç vaxt əlçatmaz namizəd təklif etməsin. Hər ikisi qanuni dizayndır. Qlobal söndürmə isə heç biri deyil, çünki o, ümumiyyətlə dizayn deyil.

Biletə nə yazılmalıdır

Dörd şeyi qeyd edin: host adını, uğursuz olan ailəni, nüvənin seçdiyi marşrutu və ailəyə xas sorğunun nəticəsini. Bu dəst başqası üçün nasazlığı təkrarlamağa kifayətdir, hansı iki yolu nəzərdə tutduğunuzu təxmin etmədən.

RFC 6724 ünvan seçimi qaydaları müştərinin niyə məhz o namizədə üstünlük verdiyini izah edir, RFC 8305 isə gecikməni gizlətmiş yarış davranışını izah edir. Heç biri sizin üçün paketi marşrutlaşdırmayacaq və bu, tunelin etməli olduğu hissədir.