VPN MTU mifləri: paketləriniz niyə kiçilir və yer hara gedir

Kimsə sizə VPN-in "MTU üzündən paket itirdiyini" deyir, siz tuneli 1400-ə qoyursunuz və ötürmə yenidən işləyir. Bu nəticə diaqnoz kimi hiss olunur. Bu, adətən, hesab təsadüfüdür: heç vaxt müəyyən etmədiyiniz həddin altına sığacaq qədər kiçik bir rəqəm seçdiniz və növbəti şəbəkədə fərqli büdcə ilə həmin hədlə yenidən qarşılaşacaqsınız.

Bunun çoxunu iki mif yaradır. Birincisi, tunel interfeysinin MTU-sunun yolun MTU-su olmasıdır. İkincisi, enkapsulyasiyanın "bir başlıq"a başa gəlməsi və PPPoE-nin saymağa dəyər heç bir şeyə başa gəlməməsidir. Hər ikisi elə yanlışdır ki, seçdiyiniz rəqəm əslində müəyyən olunduğu halda ixtiyari görünür.

Birinci mif: tunelin MTU-su yolun MTU-sudur

Tunel interfeysində təyin etdiyiniz dəyər, tətbiqin aşağı ötürəcəyi ən böyük daxili paket barədə yerli vəddir. Yolun həqiqi tutumu sizinlə uzaq tərəf arasındakı hər bir keçidin xassəsidir və marşrut dəyişdikdə, mobil bağlantı keçid etdikdə və ya trafik fərqli pirləşməyə getdikdə dəyişə bilər. Təyin edilmiş 1500 sizə hostunuzun nə quracağını deyir, şəbəkənin nə daşıyacağını yox.

Yol MTU kəşfi bu ikisini uzlaşdırmaq üçün mövcuddur və əks əlaqədən asılıdır. IPv4-də tam ölçülü paketi ötürə bilməyən marşrutlaşdırıcı ICMP "fragmentation needed" mesajı göndərməlidir və göndərən öz təxminini aşağı salır. IPv6-da ekvivalent Packet Too Big mesajıdır və marşrutlaşdırıcılar tranzitdə heç fraqmentləşdirmir. Bu əks əlaqə süzüldükdə göndərən yolun daşıya bilmədiyi paketləri istehsal etməyə davam edir və heç nə ona səbəbi demir.

İkinci mif: enkapsulyasiya bir başlığa başa gəlir

Xarici qatları vicdanla sayın. Xarici IP başlığı IPv4 üçün 20 bayt, IPv6 üçün 40 baytdır. NAT-dan keçid üçün UDP enkapsulyasiyası 8 əlavə edir. Tunel protokolu öz başlığını, bir inisializasiya vektoru və ya nonce, şifrənin blok və ya düzlənmə sərhədinə qədər doldurma, bir sonluq və bütövlük yoxlama dəyəri əlavə edir. Protokoldan və şifrədən asılı olaraq cəm daxili paket hələ başlamamışdan onlarla bayta çatır.

Sonra daxili paketin öz başlıqları üçün yenidən çıxın. Tunelin içindəki TCP seqmenti öz 20 baytlıq IP başlığını və 20 baytlıq TCP başlığını daşıyır, TCP-nin MSS-i isə tunelin nominal yükündən deyil, MTU-dan törəyir. Buna görə də ping kiçik yüklə uğur qazana bilər, halbuki fayl ötürməsi dayanır: alətlər fərqli şeyləri yoxlayır və yalnız biri tam ölçülü TCP seqmentini işə salır.

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

Birinci əmr təyin edilmiş tunel MTU-sunu göstərir. İki yoxlama 1472 baytlıq yük göndərir; bu, IPv4 və ICMP başlıqlarının 28 baytı ilə birlikdə 1500 baytlıq paketdir, sonra isə daha kiçik biri. Böyük yoxlama tamamilə uğursuz olub kiçiyi uğur qazanırsa, ümumi marşrut problemi deyil, ölçüdən asılı nasazlığınız var.

Üçüncü mif: PPPoE hələ də sizə təmiz 1500 verir

Adi PPPoE giriş keçidi 1500 baytlıq IP paketi daşımır. PPPoE başlığı və PPP protokol sahəsi Ethernet çərçivəsinin içində 8 bayt tutur, bu da IP paketi üçün 1492 qoyur. Bu, RFC 2516-da təsvir olunan ənənəvi həddir. Belə bir keçid üzərində VPN işlədirsinizsə, tunelin əlavə yükü 1500-dən deyil, həmin 1492-dən çıxır.

RFC 4638, həm giriş konsentratoru, həm də müştəri avadanlığı dəstəklədikdə daha böyük PPP yükünün razılaşdırılması üsulunu müəyyən edir; buna görə də tək "bu bağlantı PPPoE istifadə edir" ifadəsi konkret rəqəmi sübut etmir. Yerli parametr heç vaxt onun üçün konfiqurasiya olunmadığı paketi ara cihaza qəbul etdirə bilməz, yəni faydalı sual etiketin nə dediyi deyil, keçidin həqiqətən nə razılaşdırdığıdır.

Niyə nasazlıq seçici görünür

Kiçik sorğuların uğur qazanması və böyük ötürmələrin dayanması yol MTU qara dəliyinin klassik əlamətidir. Əl sıxma, DNS sorğusu və API çağırışı hamısı sığır; toplu ötürmə bir keçiddə ölən tam ölçülü seqmentlər yaradır və problemi bildirməli olan ICMP mesajı heç vaxt gəlmir. Bağlantı qaydasında görünür, yükləmə isə donur; bu da insanları yolun yerinə serverə baxmağa yönəldir.

İkinci və əlaqəli səhv üç rəqəmi qarışdırmaqdır: interfeys MTU-su, TCP MSS-i və protokolun öz fraqmentləşdirmə və ya doldurma parametri. Marşrutlaşdırıcıda MSS sıxılması elan olunan MSS-i yenidən yazır ki, göndərən daha kiçik seqmentlər qursun; bu, tunel MTU-sunu dəyişmir və UDP trafikinə kömək etmir. Əlaqəli göründükləri üçün hər üçünü eyni rəqəmə qoymaq, işləyən quraşdırmanın xoşniyyətli dəyişikliklə pozulma üsuludur.

Nəyi, hansı ardıcıllıqla dəyişməli

Dəlillə başlayın. Yuxarıdakı yoxlamalarla nasazlığın ölçüdən asılı olduğunu təsdiqləyin, sonra keçən ən kiçik ölçüsü və uğursuz olan ən böyüyü tapın. Tuneli günahlandırmazdan əvvəl giriş keçidinin həqiqi MTU-sunu yoxlayın; PPPoE keçidi büdcəni VPN ona toxunmamışdan əvvəl məhdudlaşdırır. Dəyişikliyin geri qaytarıla bilməsi üçün ilkin dəyərləri qeyd edin.

Sonra müştərinin sənədləşdirdiyi ən kiçik düzəlişi tətbiq edin. Bir çox müştəri tunel MTU-su ilə birlikdə MSS düzəltmə seçimi təqdim edir və MSS seçimi çox vaxt TCP üçün daha yaxşı qoldur, çünki hər paketi kiçiltmədən göndərənə çatır. Eyni təyinatı və eyni ötürməni yenidən sınayın və qərar verdiyiniz rəqəmləri qeyd edin. Bir giriş şəbəkəsində işləyən tunel dəyəri universal sabit deyil və növbəti sahənin öz büdcəsi olacaq.