IPv4 VPN serveri üzərindən IPv6 yenə də IPv6 çıxışı tələb edir

Tunel qalxır, müştəri hovuzdan IPv6 ünvanı alır, amma hər IPv6 təyinatı yenə də vaxt aşımına uğrayır. Tuneldə heç nə sınıq deyil: IPv6 IPv4 nəqliyyatının içində tam yaxşı gedir və bu heç vaxt çətin hissə olmayıb. Verdiyin ünvan serverin yerinə yetirə bilmədiyi bir vəddir, çünki çıxışın onu göndərəcəyi heç bir IPv6 yuxarı axını yoxdur. Düzəliş çıxışda olmalıdır, müştəri profilində deyil.

Simptom: ünvan var, yol yoxdur

Müştəri tərəfindəki yoxlama tunel cihazında qlobal görünən IPv6 ünvanı və ora işarə edən marşrut göstərir, buna görə də bu, müştəri xətası kimi yanlış oxunur. Trafik tunelə girir, server onu dekapsulyasiya edir və sonra paket marşrut cədvəlində həqiqi bir yerə IPv6 defolt marşrutu olmayan hosta düşür. Stekdən asılı olaraq ya dərhal əlçatmazlıq, ya da səssiz itki alırsan, hər iki halda müştəri firewall ilə eyni görünən vaxt aşımı görür.

Müştəriyə toxunmazdan əvvəl serverin öz marşrut cədvəlini oxu, çünki yolun çatışmayan yarısı orada yaşayır. Bir IPv4 defolt marşrutu olan server sənə cavabı artıq demişdir.

Dekapsulyasiyadan sonra paketi izlə

Tunelin içində paket adi IPv6-dır və mənbəyi müştərinin ünvanıdır. Server nəqliyyat kapsulyasiyasını soyur və sonra IPv6 sonrakı hopa yönləndirilməli olan yerli IPv6 paketi tutur. IPv4 defolt marşrutu onu daşıya bilməz və onu IPv4-ə çevirmək heç kimin yerləşdirmədiyi başqa bir funksiyadır. Bütün uğursuzluq budur və bunun VPN dinləyicisinin IPv4 üzərindən cavab verib-verməməsi ilə heç bir əlaqəsi yoxdur.

IPv6-nın IPv4 üzərindən kapsulyasiya mexanikası RFC 4213-də təsvir olunur və oradakı mühüm detal budur ki, son nöqtələr tunelin o biri tərəfində yenə də real IPv6 bağlantısına ehtiyac duyur. Başlığı bükmək yuxarı axını sehrlə yaratmır.

İki tunel qatı, iki müstəqil yoxlama

Hər qatı ayrıca yoxla, çünki işləyən xarici tunel sınıq daxili tuneli gizlədir. Xarici yolu müştəridən serverə IPv4 ping ilə yoxla və istifadə etdiyin portu təsdiqlə. Sonra serverdə daxili yolu yoxla, burada ip -6 route defolt və ya real yuxarı axından öyrənilmiş konkret marşrut göstərməlidir və ip -6 addr yuxarı axının qəbul etdiyi mənbə prefiksini göstərməlidir. Bundan azı interfeys üzərində bəzəkdir.

Unikal-yerli ünvan və ya heç bir şeyin geri marşrutlaşdırmadığı qlobal görünən prefiks interfeysdə məmnuniyyətlə görünür və heç yerə getmir. İctimai əlçatanlığı yuxarı axın verir, ünvanın forması deyil.

Eyni şey müştəridə də keçərlidir: ip -6 route get 2001:4860:4860::8888 tunel cihazını adlandırmalıdır və əgər fiziki cihazı adlandırırsa, müştəri IPv6 üçün VPN-dən ümumiyyətlə istifadə etmir.

Mənbə prefiksi, ölçü və ICMPv6

Yuxarı axından onun yönləndirmə üçün hansı mənbə prefikslərini qəbul edəcəyini soruş və onlardan birini müştəri hovuzu üçün istifadə et. Serverin öz interfeysi üçün sənə /64 verən provayder mütləq sənə ikinci /64 və ya daha böyük blok yönləndirmir və fərq bir dəstək bileti ilə bir sualda həll olunan bir günorta sazlama işidir. Yazılı soruş və cavabı konfiqurasiya ilə birlikdə saxla.

Stekinin həqiqətən istifadə etdiyi əlavə kapsulyasiya üçün büdcə ayır və ICMPv6-nı, o cümlədən Packet Too Big-i işlək saxla. İkinci başlıq istifadə oluna bilən yükü kiçildir, buna görə kiçik ping-lərə cavab verən yol fayl ötürülməsində yenə də uğursuz ola bilər və bütün ICMPv6-nı atan firewall bərpa oluna bilən ölçü problemini qara dəliyə çevirir. Xidməti elan etməzdən əvvəl bir böyük ötürülməni sına.

Tamamilə başqa bir problem nədir

Yalnız IPv4 işləyən tətbiqə yalnız IPv6 işləyən müştəridən çatmaq tunelleşdirmə deyil, tərcümədir və qəsdən yerləşdirilmiş NAT64 quruluşu kimi bir şey tələb edir. Təyinat yalnız əlavə etdiyin üçün əlavə tunel başlığını başa düşməyəcək. Tarixi keçid xidmətləri də eyni qayğıya layiqdir: RFC 7526 6to4 anycast relay modelini ləğv etdi, buna görə onun ətrafında yazılmış təlimat artıq saxlanılan ictimai relay-i olmayan bir şeyi təsvir edir.

Serverin istifadə edilə bilən IPv6 yuxarı axını yoxdursa, seçimlər dəstəklənən yuxarı axın, fərqli çıxış və ya IPv6-nın tuneldən kənarda qalması barədə sənədləşdirilmiş qərardır. Qəbuledilməz olan müştərilərə IPv6 xidmətinin mövcud olduğunu söyləməkdir, halbuki onların adi IPv6 bağlantısı VPN-i səssizcə yan keçir.