IPv6 tunelinizin həmkarına ping uğursuz olur? :: ünvanını yoxlayın

IPv6 tunelinizin bir ucu digərinə ping göndərir və yalnız bir istiqamət cavab verir. İnterfeys işləkdir, marşrut düzgün görünür və jurnalda bunu izah edən heç nə yoxdur. Təyin etdiyiniz ünvan subnet-router anycast ünvanıdır, bu heç də host ünvanı deyil və iki uc nöqtəli bir əlaqədə onun tam bir çatdırılma hədəfi var: göndərən. Heç bir timeout dəyəri bunu düzəltmir, çünki ünvan sizin düşündüyünüz işi görmür.

Ünvana işarə edən simptom

Əlaqədəki hər host cavab verir, yalnız interfeys identifikatoru tam sıfır olan istisna. Belə formaya ünvanlanmış paket tərifinə görə subnetdəki marşrutlaşdırıcıya çatdırılır, ona görə də nöqtədən-nöqtəyə tuneldə o, onu göndərən maşına qayıdır. Uzaq tərəfdən bu, əlçatmaz həmkar kimi oxunur; yaxın tərəfdən isə sükut kimi. Eyni prefiksdən başqa bir identifikator qoysanız, simptom başqa heç bir dəyişiklik olmadan yox olur və bu, marşrutlara toxunmazdan əvvəl alınmalı olan təsdiqdir.

Tam sıfır identifikator anycast kimi qorunub

RFC 4291 tam sıfır interfeys identifikatorunu subnet-router anycast ünvanı kimi saxlayır, buna görə 2001:db8:4a::/64 kimi bir /64 ünvanında istifadə edilə bilən host yoxdur: 2001:db8:4a::. Bu qorunma yerini haqq edir: marşrutlaşdırıcı reklamları və qonşu aşkarlanması bu formaya müraciət edir və marşrutlaşdırıcı xidmət etdiyi prefiks üçün cavab verir. Bu dəyəri tunel uc nöqtəsinə təyin etmək bir yarpağa marşrutlaşdırıcı rolu verməkdir, buna görə heç nə qayıtmır. Prefiksdəki hər hansı digər identifikator host kimi işləyir, ona görə düzəliş adətən bir rəqəmdir.

Qorunmaya tunel uc nöqtəsindən tuta bilmədiyiniz bir rol kimi yanaşın, ətrafından marşrutla keçiləcək bir qəribəlik kimi deyil.

Host ünvanları təyin edin və prefiksi marşrutlaşdırın

İki uc üçün ::1 və ::2 seçin, birini ip -6 addr add 2001:db8:4a::2/64 dev tun0 əmri ilə əlavə edin, sonra uzaq prefiksi ünvanlamağa çalışmaq əvəzinə onu marşrutlaşdırın. 2001:db8:4a::/64 üçün tuneldən çıxan marşrut uzaq tərəfi əlçatan edir; ünvanın özü isə yalnız lokal interfeysin konfiqurasiya olunduğunu bildirir.

Tam tunel üçün üçüncü addım var: cihazdan keçən qlobal unicast üçün default marşrut, yəni hər şeyi tunelə göndərməyin IPv6 ekvivalenti. Bunu atlasanız, IPv4 tunelin içində səyahət edərkən IPv6 fiziki əlaqədən istifadə etməyə davam edir, beləliklə host məhz əhatə olunduğunu güman etdiyiniz trafiki sızdırır. Bunu ip -6 route get 2001:4860:4860::8888 əmri ilə təsdiqləyin və cavabı güman etmək əvəzinə hansı cihazı göstərdiyini oxuyun.

Multicast marşrutlaşdırmadan əvvəl rədd edilir

Android VpnService.Builder üçün LinkAddress vasitəsilə adresləri və marşrutları yoxlayır və həmin konstruktor multicast-ı qəti şəkildə rədd edir. Ona marşrut kimi multicast prefiksi verin və nəticə marşrut deyil, səhv LinkAddress parametrləri xətası olacaq, bu da şəbəkə deyil, validasiya cavabıdır. Rədd mühitə uyğundur: nöqtədən-nöqtəyə tun cihazında link qatı multicast yoxdur, ona görə də onun üzərində qrup marşrutunun quraşdırılacaq çatdırılma modeli yoxdur. Qrup ünvanlarını əl ilə konfiqurasiya etmək əvəzinə stack özü yaradır və istehlak edir.

IPv6 all-nodes və solicited-node ünvanları eyni qaydaya düşür. İnterfeys onları daşıyır, çünki stack onları oraya qoyub, siyasət onları nəzərdə tutduğu üçün deyil.

Tunel əvəzində nə daşıya bilər

Üçün multicast aşkarlanmasının tuneldən keçirilməsi qrup üzvlüyünü anlayan bir qat tələb edir: Ethernet seqmentini təqdim edən TAP körpüsü, tətbiq səviyyəsində relay və ya hansı peer-lərə replikasiya ediləcəyi açıq şəkildə deyilən marşrutlaşdırma protokolu. VpnService modelində bunların heç biri yoxdur, burada tətbiq paketləri oxuyur və yazır və tunel üçün qrupa qoşulan heç bir çağırışı yoxdur. Ya qrupları anlayan komponenti əlavə edin, ya da tələbi dizayndan çıxarın.

Unicast isə, əksinə, yuxarıdakı ünvanlardan və marşrutlardan başqa heç nə tələb etmir, buna görə tunellərin onu daşıması gözlənilir və sonra aşkarlama protokolu uğursuz olanda günah onlarda görülür.

Nə isə təyin etməzdən əvvəl üç yoxlama

Ünvanın anycast forması olmadığını təsdiqləyin, multicast olmadığını təsdiqləyin və prefiksin sadəcə cihaza təyin edildiyini deyil, marşrutlaşdırıldığını təsdiqləyin. Sonra testinizi həqiqi host olan hədəfə göndərin, çünki anycast ünvanına yönəlmiş ping göndərəni ölçür və yol haqqında heç nə demir. Bu üç yoxlamanı dəyişiklik qeydində saxlayın ki, növbəti yerləşdirmə onları yenidən kəşf etməsin.

Platformanın heç vaxt quraşdırmadığı marşrutu daha çox gözləməklə sazlamaq olmaz, heç vaxt host olmayan ünvanı isə daha yaxşı ping ilə bərpa etmək olmaz.