VPN MTU mīti: kāpēc jūsu paketes sarūk un kur paliek vieta

Kāds jums saka, ka VPN "zaudē paketes MTU dēļ", jūs iestatāt tuneli uz 1400, un pārsūtīšana atkal strādā. Šis rezultāts šķiet kā diagnoze. Parasti tas ir aritmētisks sakritības gadījums: jūs izvēlējāties skaitli, kas ir pietiekami mazs, lai ietilptu zem robežas, kuru jūs nekad neidentificējāt, un jūs atkal sastapsiet šo pašu robežu nākamajā tīklā ar citu budžetu.

Lielāko daļu no tā izraisa divi mīti. Pirmais ir tāds, ka tuneļa saskarnes MTU ir ceļa MTU. Otrais ir tāds, ka iekapsulēšana maksā "vienu galveni", bet PPPoE nemaksā neko, ko būtu vērts skaitīt. Abi ir nepareizi tā, ka izvēlētais skaitlis šķiet patvaļīgs, lai gan patiesībā tas ir noteikts.

Pirmais mīts: tuneļa MTU ir ceļa MTU

Vērtība, ko iestatāt tuneļa saskarnē, ir lokāls solījums par lielāko iekšējo paketi, ko ieviešana nodos uz leju. Ceļa reālā kapacitāte ir katras saites starp jums un tālo galu īpašība, un tā var mainīties, kad mainās maršruts, kad mobilais savienojums tiek nodots vai kad trafiks izvēlas citu peering. Iestatītais 1500 pasaka, ko būvēs jūsu hosts, nevis ko pārvadās tīkls.

Ceļa MTU atklāšana pastāv, lai saskaņotu abus, un tā ir atkarīga no atgriezeniskās saites. IPv4 gadījumā maršrutētājam, kas nevar pārsūtīt pilna izmēra paketi, būtu jānosūta ICMP "fragmentation needed" ziņojums, un sūtītājs samazina savu aplēsi. IPv6 gadījumā ekvivalents ir Packet Too Big ziņojums, un maršrutētāji tranzītā vispār nefragmentē. Kad šī atgriezeniskā saite tiek filtrēta, sūtītājs turpina radīt paketes, ko ceļš nevar pārvadāt, un nekas tam nepasaka kāpēc.

Otrais mīts: iekapsulēšana maksā vienu galveni

Godīgi saskaitiet ārējos slāņus. Ārējā IP galvene ir 20 baiti IPv4 vai 40 IPv6. UDP iekapsulēšana NAT šķērsošanai pievieno 8. Tuneļa protokols pievieno savu galveni, inicializācijas vektoru vai nonce, polsterējumu līdz šifra bloka vai izlīdzinājuma robežai, beigu daļu un integritātes pārbaudes vērtību. Atkarībā no protokola un šifra kopsumma ērti sasniedz desmitus baitu vēl pirms iekšējās paketes sākuma.

Pēc tam atkal atņemiet pašas iekšējās paketes galvenes. TCP segments tuneļa iekšienē nes savu 20 baitu IP galveni un 20 baitu TCP galveni, un TCP MSS tiek atvasināts no MTU, nevis no tuneļa nominālās lietderīgās kravas. Tāpēc ping ar mazāku kravu var izdoties, kamēr faila pārsūtīšana iestrēgst: rīki pārbauda dažādas lietas, un tikai viens no tiem izmanto pilna izmēra TCP segmentu.

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

Pirmā komanda ziņo iestatīto tuneļa MTU. Abas zondes sūta 1472 baitu kravu, kas kopā ar 28 baitu IPv4 un ICMP galvenēm ir 1500 baitu pakete, un pēc tam mazāku. Ja lielā zonde pilnībā neizdodas un mazā izdodas, jums ir no izmēra atkarīga kļūda, nevis vispārēja maršrutēšanas problēma.

Trešais mīts: PPPoE joprojām dod tīru 1500

Parasta PPPoE piekļuves saite nepārvadā 1500 baitu IP paketi. PPPoE galvene un PPP protokola lauks aizņem 8 baitus Ethernet kadrā, atstājot 1492 IP paketei. Tā ir tradicionālā robeža, kas aprakstīta RFC 2516. Ja virs šādas saites darbināt VPN, tuneļa papildu izmaksas nāk no šiem 1492, nevis no 1500.

RFC 4638 definē veidu, kā vienoties par lielāku PPP lietderīgo kravu, ja to atbalsta gan piekļuves koncentrators, gan klienta aprīkojums, tāpēc vien "šis savienojums izmanto PPPoE" nepierāda konkrētu skaitli. Lokāls iestatījums nevar piespiest starpniekieriņu pieņemt paketi, kurai tas nekad nav konfigurēts, tāpēc lietderīgais jautājums ir, par ko saite patiešām vienojās, nevis ko saka etiķete.

Kāpēc kļūme šķiet selektīva

Mazu pieprasījumu izdošanās un lielu pārsūtīšanu iestrēgšana ir klasiskā ceļa MTU melnā cauruma pazīme. Rokasspiediens, DNS vaicājums un API izsaukums visi ietilpst; masveida pārsūtīšana rada pilna izmēra segmentus, kas mirst vienā saitē, un ICMP ziņojums, kam bija jāziņo par problēmu, nekad neierodas. Savienojums izskatās kārtībā, un lejupielāde karājas, kas liek cilvēkiem skatīties uz serveri, nevis ceļu.

Otra, saistīta kļūda ir sajaukt trīs skaitļus: saskarnes MTU, TCP MSS un paša protokola fragmentācijas vai polsterējuma iestatījumu. MSS saspiešana maršrutētājā pārraksta izsludināto MSS, lai sūtītājs veidotu mazākus segmentus; tas nemaina tuneļa MTU un nepalīdz UDP trafikam. Dot visiem trim vienu un to pašu skaitli, jo tie šķiet saistīti, ir veids, kā labi domāta izmaiņa salauž strādājošu konfigurāciju.

Ko mainīt un kādā secībā

Sāciet ar pierādījumiem. Apstipriniet ar iepriekš minētajām zondēm, ka kļūme ir atkarīga no izmēra, un pēc tam atrodiet mazāko izmēru, kas iziet cauri, un lielāko, kas neizdodas. Pirms vainot tuneli, pārbaudiet piekļuves saites reālo MTU; PPPoE saite ierobežo budžetu vēl pirms VPN tai pieskaras. Pierakstiet sākotnējās vērtības, lai izmaiņu varētu atsaukt.

Pēc tam piemērojiet mazāko pielāgojumu, ko dokumentē klients. Daudzi klienti piedāvā tuneļa MTU un MSS labošanas opciju, un MSS opcija bieži ir labākā svira TCP, jo tā sasniedz sūtītāju, nesamazinot katru paketi. Vēlreiz pārbaudiet to pašu galamērķi un to pašu pārsūtīšanu un pierakstiet skaitļus, pie kuriem apstājāties. Tuneļa vērtība, kas darbojas vienā piekļuves tīklā, nav universāla konstante, un nākamajai vietai būs savs budžets.