IPv6 xətaları, onlara səbəb olan paket ölçüsündən daha çox protokola yazılır. İki ailə həddindən böyük paketlə həqiqətən fərqli davranır və fərqi vacib edən tuneldir. IPv4 marşrutlaşdırıcıları qaydalar icazə verdikdə paketi fraqmentləşdirə bilər, IPv6 marşrutlaşdırıcıları isə tranzitdə heç vaxt fraqmentləşdirməməlidir. IPv6 bunun əvəzinə göndərənə bildirir və göndərənin reaksiya verməsi gözlənilir. Sonradan hər şeyin səhv getməsi həmin mesajın çatıb-çatmamasından irəli gəlir.

Hər ailə nə edir

Cədvəl mexanizmi dörd sətirdə göstərir və bir sətir çaşqınlığın çoxunu izah edir.

BehaviourIPv4IPv6
Router fragments an oversized packetAllowed while DF is clearNever
Signal returned to the senderICMP Fragmentation NeededICMPv6 Packet Too Big
Size that must always work68 bytes1280 bytes
Fragmentation possibleRouters or sourceSource only

IPv6-da tranzit fraqmentləşdirmə yoxdur və təmizlənəcək DF bayrağı da yoxdur, ona görə paket çox böyük olduqda arxalanacaq bir şey qalmır. Göndərənə bildirilməlidir və göndərən buna inanmalıdır.

Tunel yolu səssizcə daraldır

VPN paket hostdan çıxmazdan əvvəl xarici başlıqlar, şifrələnmiş halda isə həm də bütövlük məlumatları əlavə edir. Daxili paket gördüyü interfeys MTU-suna sığa bilər, xarici paket isə növbəti keçidin həddini aşır, ona görə bu ilk növbədə tuneldə üzə çıxır. Tunel interfeysinin MTU-sunu qəsdən aşağı salın və ya yolda TCP MSS-i sıxın, seçdiyiniz rəqəmi və səbəbini yazın.

ESP yükü rejimdən və alqoritmlərdən asılıdır, ona görə düzgün tunel MTU-su konvensiya deyil, hesablamadır. Nə seçsəniz də, 1280 baytlıq tam daxili IPv6 paketine yer qalmalıdır, çünki hər IPv6 keçidi bu qədərini daşımalıdır. 1280 bayt IPv6 daşıya bilməyən tunel tənzimləmə problemi deyil; o ailə üçün qırıq yoldur. Yalnız IPv4 üzərində qurulmuş yerləşdirmədən MTU dəyəri kopyalandıqda məhz bu məhdudiyyət yox olur.

Niyə simptom donmadır

Uğursuzluq təmiz xəta deyil, buna görə də səhv diaqnoz qoyulur. TCP əl sıxışması tamamlanır, kiçik cavablar gəlir və böyük cavab və ya kütləvi yükləmə başlayan kimi bağlantı dayanır, çünki bunlar atılmağa kifayət qədər böyük ilk paketlərdir. SSH qoşulur və sonra ilk böyük çıxışda donur, səhifənin başlığı yüklənir, gövdəsi isə heç vaxt bitmir.

ICMPv6 paketin çox böyük olması mesajları filtrlənirsə, göndərən heç öyrənmir və eyni ölçünü təkrar-təkrar sınayır. Bu, yavaş yol deyil, qara dəlikdir və əlaməti təsadüfi itki deyil, təkrarlanan ölçü sərhədidir. Müvafiq nəzarət trafikinə icazə vermək işlək IPv6 yerləşdirməsinin bir hissəsidir, nəzakət deyil.

Öz yolunuzun asılı olduğu mesajları söndürüb nəticəni IPv6 xətası kimi təsvir etməyin. Eyni arqument IPv4-ün Fragmentation Needed mesajlarına da aiddir; onlar da firewall müəllifləri üçün eyni dərəcədə sevilməz və eyni dərəcədə zəruridir.

Sərhədi ölçün, sonra qatı düzəldin

Təxmin etmək əvəzinə yoxlayın: IPv4-də don't-fragment bayrağından, IPv6-da sabit yük ölçülərindən istifadə edin və cavabların harada dayandığını qeyd edin. ping -M do -s 1472 və ping -6 -s 1400 problemin formasını müəyyən etmək üçün kifayətdir və tracepath yol boyu aşkar edilmiş yol MTU-sunu bildirir.

Sonra rəqəmə sahib olan qatı düzəldin: tunel interfeysinin MTU-su, TCP üçün MSS sıxması və ya yolun özü. IPv6 qaydası üçün istinad RFC 8200-dir və o, qarşısını aldığı hadisədən daha qısa oxunuşdur.

Tətbiqin həqiqətən istifadə etdiyi ailəni sınayın, çünki iki yığımlı ad bir ailədə cavab verib digərində verməyə bilər və tətbiq şəbəkə dəyişikliyindən sonra keçid edə bilər. Sınadığınız ünvanı qeyd edin, çünki A qeydinə qarşı nəticə AAAA qeydi haqqında heç nə demir.

Ölçü sərhədini sübut kimi qəbul edin

Təkrarlanan ölçü sərhədi dəqiq təkrarlanan azsaylı şəbəkə nasazlıqlarındandır: eyni bayt sayında, eyni mənbədən, hər dəfə. Bu onu sirr deyil, hədiyyə edir və həm də düzəlişin ümid edilmək əvəzinə yoxlana bilməsi deməkdir.

Aşkar edilmiş MTU-nu, konfiqurasiya etdiyiniz tunel MTU-sunu və fərqi sübut edən testi bilete yazın. Növbəti şəxs eyni hesabla başqa keçiddə rastlaşacaq.

Əlaqəli məqalələr