MTU vai MSS? Mitä VPN-muutos todella korjaa
MTU rajaa, mitä linkki kantaa; MSS rajaa siinä olevaa TCP-hyötykuormaa. Rajaa oikea ja tiedä, mitä protokollia kumpikaan ei kata.
Pingit onnistuvat, suuret siirrot jäävät jumiin ja tunneli ilmoittaa olevansa kunnossa. Joku laskee liitännän MTU:ta, toinen rajaa MSS:ää, ja joskus ongelma katoaa syistä, joita kukaan ei kirjaa. Kaksi lukua kuvaavat eri kohteita, joten väärän muuttaminen tuottaa korjauksen, joka näyttää tuurilta. Tässä menettely: tunnista kerros, käytä vastaavaa säätöä ja testaa sitten uudella yhteydellä.
Kaksi lukua, kaksi kohdetta
MTU kuuluu linkille tai liitännälle: se on suurin paketti, joka voidaan luovuttaa jakamatta sitä. MSS kuuluu TCP:lle: se on suurin määrä TCP-hyötykuormaa, jonka segmentti voi kuljettaa, ja se jättää pois sekä TCP- että IP-otsikot. Tavallisella IPv4:ää käyttävällä Ethernet-linkillä 1500 tavun MTU antaa tutun 1460 tavun MSS:n. Nämä luvut kuvaavat eri kerroksia ja ne välitetään eri mekanismeilla. Niiden sekoittaminen on helppoa, koska molemmat mitataan tavuissa ja molemmat ovat lähellä 1500:aa.
Toinen tulee liitännän asetuksena. Toinen tulee vaihtoehtona SYN-segmentin sisällä, neuvoteltuna päiden välillä, jotka eivät koskaan näe liitäntääsi.
Mihin ulompi lisäkuorma päätyy
VPN laittaa sisemmän paketin toisen sisään, ja ulomman paketin on mahduttava fyysiseen reittiin. Kapselointiotsikot, ulompi IP-otsikko, kuljetusotsikko ja mahdollinen todennusmerkki kuluttavat tavuja, joita sisempi paketti ei voi käyttää. Jätä tunneliliitäntä 1500:aan, niin ulompi paketti ylittää säännöllisesti sen, mitä reitti kantaa. Kun 'älä pilko' -bitti on asetettu, reititin pudottaa sen ja sen pitäisi lähettää takaisin ICMP-virhe; jos virhe suodatetaan, lähettäjä ei koskaan saa tietää.
Siksi vika näyttää valikoivalta. Pienet pyynnöt valmistuvat ja kaikki, mikä täyttää segmentin, juuttuu, koska vain suuret paketit hylätään. Tunneli, joka päästää pingin läpi, ei ole tunneli, joka kuljettaa dataa.
MSS:n rajaaminen ja missä se pätee
MSS:n rajaaminen kirjoittaa SYN-segmentin arvon uudelleen, kun se ylittää valitun pisteen, jolloin molemmat päät valitsevat pienemmän hyötykuorman tietämättä miksi. Linuxissa se on mangle-taulun kohde, jota sovelletaan nimenomaisella säännöllä, ja sen täytyy osua SYN-paketteihin haluamassasi suunnassa. Rajaa se tunneliliitäntään ja osoitealueeseen, koska laaja sääntö muuttaa sellaisen liikenteen käytöstä, joka ei koskaan tule tunneliin.
Vaikutus koskee vain TCP:tä. UDP-sovellus, QUIC-istunto ja mikä tahansa protokolla, joka rakentaa omat datagramminsa, jäävät koskemattomiksi.
Diagnosoi kiinteällä reitillä
Pidä yksi muuttuja kerrallaan. Testaa paketilla, jonka koon valitset itse, ja aseta 'älä pilko' -lippu, jotta ydin raportoi tuloksen sen sijaan että piilottaisi sen.
Kirjaa, mistä vika alkaa: tunnelin sisällä, tunneliliitännässä vai fyysisellä reitillä kapseloinnin jälkeen. Muuta sitten yhtä lukua ja toista sama testi eikä toista. Olemassa olevat yhteydet säilyttävät neuvotellun MSS:n, joten käytännön muutos näkyy vain uudella yhteydellä, minkä vuoksi välimuistiin tallennettu sivu ei todista mitään kumpaankaan suuntaan. Jos yksi suuri lataus alkaa toimia, opit siitä reitistä etkä jokaisesta sen päällä olevasta protokollasta.
Mitä kukin muutos ei korjaa
Liitännän MTU:n laskeminen ei muuta jo muodostetun istunnon MSS:ää. MSS:n rajaaminen ei auta UDP-virtaa eikä korjaa reittiä, jolla ICMP-virheet suodatetaan vain yhteen suuntaan. Jokainen muutos korjaa yhden ongelmaluokan ja jättää muut täsmälleen ennalleen.
Kirjoita muistiin, minkä säädön teit, missä ja mikä testi osoitti eron, sillä muuten seuraava insinööri tekee molemmat ja menettää kyvyn sanoa, kumpi oli merkityksellinen. Jos rajoitus on todellinen ja pysyvä, suosi tunnelin MTU:ta, joka heijastaa sitä, rajoituksen sijaan, joka kätkee sen. Jos on pakko rajata, jätä sääntö rajatuksi ja kommentoiduksi, koska selittämätön mangle-sääntö muuttuu oletuksena pysyväksi.