MTU aŭ MSS? Kion ŝanĝo de VPN efektive riparas

Pingoj sukcesas, grandaj transigoj haltas, kaj la tunelo raportas sin sana. Iu malaltigas la MTU de la interfaco, alia limigas MSS, kaj foje la problemo malaperas pro kialoj, kiujn neniu registras. La du nombroj priskribas malsamajn objektojn, do ŝanĝi la malĝustan produktas riparon, kiu aspektas kiel bonŝanco. Jen la proceduro: identigu la tavolon, apliku la konforman alĝustigon, poste testu per nova konekto.

Du nombroj, du objektoj

MTU apartenas al ligilo aŭ interfaco: ĝi estas la plej granda paketo, kiun oni povas transdoni sen dividi ĝin. MSS apartenas al TCP: ĝi estas la plej granda kvanto de TCP-ŝarĝo, kiun segmento povas porti, kaj ĝi ekskludas kaj la TCP- kaj la IP-kapojn. Sur ordinara Ethernet-ligilo kun IPv4, MTU de 1500 bajtoj donas la konatan MSS de 1460 bajtoj. Tiuj nombroj priskribas malsamajn tavolojn kaj estas interŝanĝataj per malsamaj mekanismoj. Konfuzi ilin estas facile, ĉar ambaŭ mezuriĝas en bajtoj kaj ambaŭ situas apud 1500.

Unu alvenas kiel interfaca agordo. La alia alvenas kiel opcio ene de SYN-segmento, intertraktata inter finpunktoj, kiuj neniam vidas vian interfacon.

Kie surteriĝas la ekstera superŝarĝo

VPN metas la internan paketon en alian, kaj la ekstera paketo devas taŭgi por la fizika vojo. Enkapsuligaj kapoj, la ekstera IP-kapo, la transporta kapo kaj iu ajn aŭtentiga etikedo ĉiuj konsumas bajtojn, kiujn la interna paketo ne povas uzi. Lasu la tunelan interfacon je 1500 kaj la ekstera paketo rutine superas tion, kion la vojo povas porti. Kun la bito 'ne dispartigu' agordita, la enkursigilo forĵetas ĝin kaj devus resendi ICMP-eraron; se tiu eraro estas filtrita, la sendinto neniam ekscias.

Tial la paneo aspektas selekta. Etaj petoj finiĝas kaj ĉio, kio plenigas segmenton, haltas, ĉar nur la grandaj paketoj estas forĵetataj. Tunelo, kiu pasigas pingon, ne estas tunelo, kiu portas datumojn.

Limigado de MSS, kaj kie ĝi validas

Limigado de MSS reskribas la valoron en la SYN-segmento dum ĝi trapasas elektitan punkton, igante ambaŭ finpunktojn elekti pli malgrandan ŝarĝon, sen ke iu el ili scias kial. En Linux ĝi estas celo de la tabelo mangle aplikata per eksplicita regulo, kaj ĝi devas trafi SYN-paketojn en la direkto, kiun vi celas. Limigu ĝin al la tunela interfaco kaj la adresa intervalo, ĉar larĝa regulo ŝanĝas la konduton de trafiko, kiu neniam eniras la tunelon.

La efiko estas nur por TCP. UDP-a aplikaĵo, QUIC-sesio kaj iu ajn protokolo, kiu konstruas siajn proprajn datagramojn, restas netuŝitaj.

Diagnozu per fiksa vojo

Tenu unu variablon samtempe. Testu per paketo, kies grandecon vi elektas, kaj agordu la flagon 'ne dispartigu', por ke la kerno raportu la rezulton anstataŭ kaŝi ĝin.

Registru, kie la paneo komenciĝas: ene de la tunelo, ĉe la tunela interfaco aŭ sur la fizika vojo post enkapsuligo. Poste ŝanĝu unu nombron kaj ripetu la saman teston anstataŭ alian. Ekzistantaj konektoj konservas la MSS, pri kiu ili interkonsentis, do ŝanĝo de politiko videblas nur en nova konekto, kaj tial kaŝmemorita paĝo pruvas nenion en iu ajn direkto. Se unu granda alŝuto komencas funkcii, vi lernis pri tiu vojo kaj ne pri ĉiu protokolo sur ĝi.

Kion ĉiu ŝanĝo ne riparas

Malaltigi la MTU de la interfaco ne ŝanĝas la MSS de sesio jam establita. Limigado de MSS ne helpas UDP-flukon kaj ne riparas vojon, kie ICMP-eraroj filtriĝas nur en unu direkto. Ĉiu ŝanĝo riparas unu klason de problemoj kaj lasas la ceterajn precize kiel ili estis.

Notu, kiun alĝustigon vi aplikis, kie, kaj kiu testo montris la diferencon, ĉar alie la sekva inĝeniero aplikas ambaŭ kaj perdas la kapablon diri, kiu gravis. Se la limigo estas reala kaj permanenta, preferu tunelan MTU, kiu spegulas ĝin, ol limigadon, kiu kaŝas ĝin. Se vi devas limigi, lasu la regulon limigita kaj komentita, ĉar neklarigita mangle-regulo fariĝas permanenta defaŭlte.