OpenVPN mssfix: kial unu kliento haltas ĉe grandaj transigoj
mssfix reskribas la grandon de TCP-segmento anoncitan en la tunelo. Ĝi ne ŝanĝas UDP, kaj la valoro signifas nur tion, kion diras via versio.
Unu tekkomputilo haltas ĉe alŝutoj tra la tunelo, dum ĉiu alia aparato sur la sama servilo daŭre funkcias. Tiu ŝablono montras al unu vojo, ne al la servila agordo, kaj ĝi estas la kutima eniro al la demando pri mssfix. La opcio povas helpi, sed nur por la TCP-konektoj, kiujn ĝi efektive reskribas. Koni ĝian amplekson malhelpas vin ŝanĝi funkciantan servilon por savi unu klienton.
Kion la opcio reskribas
mssfix redaktas la maksimuman segmentan grandon anoncitan en TCP-manpremoj, kiuj pasas tra la tunelo, por ke la senda flanko elektu segmentojn, kiuj taŭgas en la enkapsuligita buĝeto. Ĝi agas sur la manpremo, kio signifas, ke konekto malfermita antaŭ la ŝanĝo konservas la valoron, pri kiu ĝi intertraktis.
Ĝi ne malgrandigas UDP-datagramojn kaj ne agordas la MTU de la tunelo. Du malsamaj problemoj produktas la saman simptomon: TCP-sendanto, kiu ignoras la vojan limon, kaj vojo, kiu silente forĵetas grandajn pakaĵojn je ajna grando. mssfix traktas la unuan kaj faras nenion por la dua.
Tiu distingo klarigas la seniluziigajn eksperimentojn. Agordi pli malgrandan valoron sur vojo kun nigra truo ŝanĝas la segmentan grandon, sed ne la sekvan forĵeton, do la transigo malsukcesas ĉe alia punkto.
La amplekso estas TCP ene de la tunelo
Nur TCP-trafiko estas reskribata. QUIC-sesio, ludo aŭ aplikaĵo, kiu sendas grandajn UDP-datagramojn, konservos siajn proprajn pakaĵgrandojn, kaj se tiuj estas la transigoj, kiuj haltas, la riparo apartenas prefere al la tunela aŭ voja MTU. Legu, kiun protokolon la malsukcesa transigo uzas, antaŭ ol atingi TCP-opcion, ĉar la malĝusta tavolo havas sian propran riparadon.
Ankaŭ direkto gravas. Klienta agordo efikas sur la trafikon, kiun tiu kliento sendas en la tunelon, dum la servilo kovras la fluojn, kiujn ĝi plusendas al klientoj. Se nur envenantaj elŝutoj haltas, la valoro ĉe la klienta flanko ne estas la tuta rakonto.
La nombro kaj la ŝlosilvorto ne estas porteblaj
La komunuma versio de OpenVPN 2.6 akceptas laŭvolan ŝlosilvorton post la valoro. Kun mtu, la nombro priskribas la eksteran pakaĵgrandon inkluzive de IP- kaj UDP-kapoj; sen ĝi, la argumento sekvas alian kalkulan konvencion. Do linio kopiita inter versioj ne priskribas la saman pakaĵbuĝeton. Kontrolu la manlibran paĝon, kiu venas kun la konstruo, kiun vi efektive rulas, anstataŭ lernilon por alia eldono.
La sintakso aspektas tiel:
mssfix 1400 mtuTraktu 1400 kiel anstataŭilon, ne kiel rekomendon por via vojo. Derivu la valoron el la mezurita vojo kaj la efektive uzata enkapsuligo, kaj memoru, ke klientoj sur pli malnovaj versioj aŭ aliaj realigoj povas malakcepti aŭ reinterpreti la ŝlosilvorton.
Konfirmu unue ĉe la sola kliento
Mezuru la vojon de la malsukcesa maŝino antaŭ ol ŝanĝi ion ajn. Utila ŝarĝo, kiun la vojo povas porti sen fragmentado, estas la nombro, kiun vi serĉas:
ping -M do -s 1472 10.8.0.1
ping -M do -s 1400 10.8.0.1La unua provo taŭgas en pakaĵon de 1500 bajtoj post kiam la 28 bajtoj da kapoj aldoniĝas. Se ĝi malsukcesas kun fragmentada eraro kaj la pli malgranda sukcesas, la uzebla grando estas ie inter ili, kaj la tunela superkosto estas subtrahata de supre.
Poste ripetu la transigon, kiu haltis, sur nova konekto, kaj komparu. Se la sola kliento pliboniĝas dum la aliaj restas netuŝitaj, vi trovis la amplekson de la problemo. Se ĉiuj klientoj haltas, la valoro ĉe la servila flanko estas la prirevizenda. Neniu el la du rezultoj pravigas ŝanĝon sur aparataro, kiu neniam estis sur la malsukcesa vojo.