MTU või MSS? Mida VPN-i muudatus tegelikult parandab
MTU piirab seda, mida link kannab; MSS piirab selle sees olevat TCP koormust. Piira õiget ja tea, milliseid protokolle kumbki ei kata.
Pingid õnnestuvad, suured ülekanded jäävad rippuma ja tunnel teatab end terve olevat. Keegi langetab liidese MTU-d, teine piirab MSS-i ja mõnikord kaob probleem põhjustel, mida keegi ei kirjuta. Need kaks arvu kirjeldavad erinevaid objekte, nii et vale arvu muutmine annab paranduse, mis näeb välja nagu õnn. Siin on tegevuskäik: tuvasta kiht, rakenda vastav kohandus ja seejärel katseta uuel ühendusel.
Kaks arvu, kaks objekti
MTU kuulub lingile või liidesele: see on suurim pakett, mida saab ilma tükeldamata üle anda. MSS kuulub TCP-le: see on suurim TCP koormuse hulk, mida segment võib kanda, ja see jätab välja nii TCP kui ka IP päise. Tavalises Etherneti lingis IPv4-ga annab 1500-baidine MTU tuntud 1460-baidise MSS-i. Need arvud kirjeldavad erinevaid kihte ja neid vahetatakse erinevate mehhanismidega. Neid on lihtne segi ajada, sest mõlemat mõõdetakse baitides ja mõlemad on 1500 lähedal.
Üks tuleb liidese seadena. Teine tuleb valikuna SYN-segmendi sees, mille on läbi rääkinud otsad, kes sinu liidest kunagi ei näe.
Kuhu väliskate lisakoormus maandub
VPN paneb sisemise paketi teise sisse ja välimine pakett peab mahtuma füüsilisesse teekonda. Kapselduspäised, välimine IP-päis, transpordipäis ja mis tahes autentimismärgend kulutavad baite, mida sisemine pakett kasutada ei saa. Jäta tunneliliides 1500 peale ja välimine pakett ületab regulaarselt seda, mida teekond kanda suudab. Kui bitt 'ära tükelda' on seatud, viskab ruuter selle ära ja peaks saatma tagasi ICMP-vea; kui see viga filtreeritakse, ei saa saatja sellest kunagi teada.
Seetõttu näeb tõrge välja valikuline. Väikesed päringud lõpevad ja kõik, mis segmendi täidab, takerdub, sest ära visatakse ainult suured paketid. Tunnel, mis laseb pingi läbi, ei ole tunnel, mis kannab andmeid.
MSS-i piiramine ja kus see kehtib
MSS-i piiramine kirjutab SYN-segmendis oleva väärtuse ümber, kui see läbib valitud punkti, mistõttu mõlemad otsad valivad väiksema koormuse, teadmata miks. Linuxis on see mangle-tabeli sihtmärk, mida rakendab selgesõnaline reegel, ja see peab tabama SYN-pakette soovitud suunas. Piira see tunneliliidese ja aadressivahemikuga, sest lai reegel muudab liikluse käitumist, mis kunagi tunnelisse ei satu.
Mõju on ainult TCP-le. UDP-rakendus, QUIC-sessioon ja iga protokoll, mis ehitab oma datagrammid, jäävad puutumata.
Diagnoosi fikseeritud teekonnaga
Hoia korraga ühte muutujat. Katseta paketiga, mille suuruse valid sina, ja sea lipp 'ära tükelda', et tuum teataks tulemuse, selle asemel et see peita.
Pane kirja, kus tõrge algab: tunneli sees, tunneliliidesel või füüsilisel teekonnal pärast kapseldamist. Seejärel muuda ühte arvu ja korda sama katset, mitte teistsugust. Olemasolevad ühendused säilitavad läbiräägitud MSS-i, nii et poliitika muudatus on nähtav ainult uuel ühendusel, mistõttu vahemällu salvestatud leht ei tõesta midagi kummaski suunas. Kui üks suur üleslaadimine hakkab tööle, oled õppinud selle teekonna kohta, mitte iga sellel oleva protokolli kohta.
Mida kumbki muudatus ei paranda
Liidese MTU langetamine ei muuda juba loodud sessiooni MSS-i. MSS-i piiramine ei aita UDP-voogu ega paranda teekonda, kus ICMP-vead filtreeritakse ainult ühes suunas. Iga muudatus parandab ühe probleemiklassi ja jätab ülejäänu täpselt endiseks.
Kirjuta üles, millise kohanduse sa rakendasid, kus ja milline katse näitas erinevust, sest muidu rakendab järgmine insener mõlemat ja kaotab võime öelda, milline oli oluline. Kui piirang on tõeline ja püsiv, eelista tunnel MTU-d, mis seda peegeldab, selle asemel et seda varjav piirang. Kui pead piirama, jäta reegel kitsaks ja kommenteerituks, sest seletamata mangle-reegel muutub vaikimisi püsivaks.