Ceļa MTU atklāšana caur VPN: izmērs un ICMP plaisa

Tunelis pabeidz savu rokasspiedienu, mazie pieprasījumi atgriežas, un pirmais lielais pārsūtījums iestājas. Šis modelis norāda uz ceļa MTU daudz agrāk nekā uz caurlaidspēju. Katrs posms maršrutā ierobežo pakešu izmēru, un iekapsulēšana daļu no šīs kvotas iztērē ārējiem galvenēm, tāpēc iekšējai pakei jābūt mazākai, nekā liecinātu neapstrādātais ceļš. Kļūme ir klusa, un tieši tāpēc to ir dārgi diagnosticēt.

Ko ceļa MTU patiesībā mēra

Ceļa MTU ir mazākais posma MTU maršrutā starp diviem resursdatoriem, nevis MTU, kas uzdrukāts jūsu vietējā saskarnē. Vietējā vērtība ir punkts, kur sākas novērtējums, un ceļš izlemj, kur tam jābeidzas. Tāpēc identisks tunelis var darboties vienā piekļuves tīklā un iestāties citā: mainījās maršruts, nevis konfigurācija. Vienreiz izmērīt un visur pieņemt ir kļūda, kas uztur šo problēmu dzīvu.

Tunelim svarīgais skaitlis ir iekšējais MTU, kas ir ārējā ceļa kvota mīnus tas, ko patērē iekapsulēšana. WireGuard pievieno ārējo IP galveni un UDP galveni; citi transporti pievieno savas. Iestatiet iekšējo izmēru pārāk lielu, un katrai pilna izmēra pakei būs vajadzīga fragmentācija, kas var arī nekad nenotikt.

Kāpēc tunelis samazina izmantojamo pakešu izmēru

Ja tuneļa saskarne saglabā fiziskā posma MTU, katra lielā pake ir atkarīga no tā, vai kāds lejāk maršrutā būs gatavs to fragmentēt. IPv4 to principā pieļauj, bet maršrutētājs, kuram pateikts nefragmentēt, tā vietā atgriež kļūdu. IPv6 maršrutētāji tranzītā nekad nefragmentē, tāpēc viens un tas pats iestatījums uzvedas citādi atkarībā no adrešu saimes. Jebkurā gadījumā sūtītājs neko neuzzina, kamēr kaut kas neatgriež ziņu.

Praktiskā sekas ir izmērs, kas iekļaujas rokasspiedienā, bet ne lietderīgajā slodzē. TLS ClientHello vai DNS vaicājums ir pietiekami mazs, lai netraucēti šķērsotu samazinātu ceļu, savukārt masveida pārsūtījums nav. Tāpēc simptomi grupējas ap konkrētām darbībām, nevis konkrētiem resursdatoriem.

Atklāšana darbojas tikai tad, kad atnāk atgriezeniskā saite

IPv4 atklāšana balstās uz don't-fragment bitu: maršrutētājs, kas nevar pārsūtīt pakei, atgriež ICMP fragmentation-needed ar nākamā lēciena MTU, un sūtītājs samazina savu novērtējumu. IPv6 tā vietā izmanto Packet Too Big ziņojumus, jo maršrutētāji tranzītā nefragmentē. Abi mehānismi pieņem, ka ziņojums atradīs ceļu atpakaļ pie sūtītāja, caur tuneli un garām jebkuram ugunsmūrim atgriešanās ceļā. Kad šis pieņēmums neizdodas, sūtītājs turpina atkārtoti mēģināt izmēru, ko ceļš nespēj pārnest.

Ugunsmūris, kas atļauj echo request un echo reply, ne vienmēr ir atļāvis šos kļūdu veidus. ICMP ir saime, un šeit svarīgie locekļi ir kļūdas, nevis atbalss pāris. Pārbaudiet vadības trafika politiku abos tuneļa galos un ceļā starp tiem, un sekojiet platformas atbalstītajai vadībai, nevis atļaujiet visus ICMP veidus visur.

Tā pati filtrēšana var būt tuneļa iekšienē. Ja iekšējais ceļš nomet kļūdu, bet ārējais ceļš to pārnes, sūtītājs var pielāgoties ierobežojumam, ko iekapsulētais trafiks nekad patiesībā neredz.

Pārbaudiet ceļu, nevis miniet skaitli

Turiet galamērķi, piekļuves tīklu un tuneli fiksētus, un mainiet tikai pakešu izmēru. don't-fragment pārbaude, kas neizdodas ar MTU mājienu, dod nākamā lēciena ierobežojumu; atkārtojiet, līdz kāds izmērs iziet, un pierakstiet gan izmēru, gan adrešu saimi.

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

Iekļaujošs ping nepierāda, ka iekļaujas reālas programmas pilna izmēra segmenti, tāpēc atkārtojiet testu ar pārsūtījumu, kas patiešām neizdevās. Salīdziniet lielāko strādājošo pārbaudi ar konfigurēto tuneļa MTU un turiet abus skaitļus atsevišķi savos pierakstos. Ja tie atšķiras apmēram par vienu galveni, jūs esat atraduši iekapsulēšanas papildu izmaksas, nevis kļūmi.

PLPMTUD, kas aprakstīts RFC 4821, pārbauda uz augšu un izmanto transporta apstiprinājumus, nevis paļaujas uz piegādātajām kļūdām. Tas palīdz ceļos, kas filtrē ICMP, bet atbalsts atšķiras atkarībā no steka un programmas. TCP plūsma var atgūties pati, kamēr UDP programma ar fiksētu datagrammas izmēru turpina neizdoties.

Izvēlieties vērtību un pierakstiet pamatojumu

Tuneļa MTU pazemināšana ir gan diagnostika, gan leģitīms labojums, kad jau zināt ceļu. Tas neaizstāj zināšanas par to, kurš ceļš un kurš atgriezeniskās saites mehānisms bija iesaistīts, jo mobilā posma vajadzībām pielāgota vērtība būs nevajadzīgi maza šķiedras savienojumā. Pierakstiet izvēlēto izmēru, pārbaudi, kas to attaisnoja, un atritināšanas soli.

IPv4 mehānisms aprakstīts RFC 1191, bet IPv6 pakešu vadlīnijas – RFC 8201; abus nosaucot, nākamais inženieris nevajadzēs no jauna atvasināt pieņēmumu. Ja pārsūtījums joprojām iestājas izvēlētajā izmērā, pārstājiet samazināt skaitli un paskatieties uz nākamo slāni. Ceļš, kas neizdodas jebkurā izmērā, nav MTU problēma.