Tri agordoj ĉe Linux-kliento ĉiuj sonas kiel „faru la pakaĵojn pli malgrandaj“, kaj ili agas ĉe malsamaj tavoloj. La MTU de la interfaco limigas ĉiun pakaĵon, kiun la aparato sendas. MTU de itinero limigas pakaĵojn, kiuj uzas tiun itineron, kio ofte estas tio, kion vi efektive volas por unu VPN-celo. La TCP MSS-limigo ŝanĝas tion, pri kio interkonsentas la du finoj, kaj ĝi faras nenion por UDP.

Tri reguliloj, kiuj aspektas kiel la sama butono

Metu ilin unu apud la alia antaŭ ol elekti, ĉar elekti la malĝustan vicon klarigas plejparton de la konsiloj, kiuj ne funkcias:

ControlScopeWhat it cannot fix
Interface MTUEvery packet the device sendsNothing, but it over-constrains unrelated traffic
Route MTUPackets using that routeA send that the lookup never routes there
MSS clampTCP handshake on that pathUDP payload sizes and ICMP

Malaltigi la Ethernet-MTU por la tuta maŝino estas la maldelikata versio de ĉi tiu riparo. Ĝi funkcias, kaj ĝi ankaŭ punas ĉiun alian aplikaĵon sur la gastiganto, inkluzive tiujn, kies vojoj estis bonaj. Valoro laŭ itinero esprimas la saman intencon sen la flanka kosto.

La komparo validas nur por trafiko, kiun la gastiganto mem generas. Plusendi pakaĵon por alia kliento implicas ties propran vojon kaj la eksteran buĝeton de la tunelo, kaj itinera metriko sur ĉi tiu gastiganto ne atingas trans tiun limon.

Ligu la buĝeton al la itinero, kiu gajnas la serĉon

Ilustra IPv4-itinera rikordo aspektas tiel:

ip -4 route get 10.60.0.20
ip -4 route add 10.60.0.0/16 dev tun-office src 10.90.0.2 mtu 1380

Legu la rikordon kiel priskribon de intenco, ne kiel valoron por alglui. La prefikso, aparato kaj preferata fonto devas kongrui kun la reala agordo, kaj la nombro devas veni el pruvoj pri la enkapsuligita vojo, ne el bloga afiŝo. La itinera MTU limigas la internan IP-pakaĵon, kio ne samas kiel TCP-utilŝarĝo de 1380 bajtoj aŭ ĉifrita ekstera pakaĵo de 1380 bajtoj.

Rigardu, kie la serĉo efektive solviĝas, antaŭ ol aldoni ion ajn. Gastiganto kun politikaj reguloj povas enkursigi donitan celon tra alia tabelo ol main, kaj metriko, kiu ekzistas nur en main , estas nevidebla por tiu peto. Komparu ip -4 route show table all kun la respondo de ip route get, inkluzive la kuntekston de marko aŭ nomspaco, kiam la reguloj uzas ilin. Se la du malkongruas, la tabelo, kiu respondis, estas tiu, kiu bezonas la metrikon, ne tiu, kiu aspektas pli ordema.

mtu ne estas mtu lock

Defaŭlte la kerno ankoraŭ povas ĝisdatigi la MTU de la vojo el ICMP-retroigo, por kio estas la malkovro de voja MTU. Aldoni lock haltigas tion. Ĝi estas alia decido, ne pli forta maniero konservi la saman nombron, kaj por IPv4 ĝi ŝanĝas la dokumentitan traktadon de la bito „ne fragmentigu“.

Ŝlosado estas racia, kiam vi mezuris la vojon kaj volas, ke la valoro restu fiksa sendepende de tio, kio alvenas. Ĝi estas malbona defaŭlto, kiam la reto sendas legitiman grandan retroigon, ĉar la kerno ne plu povas adaptiĝi kaj la fiasko translokiĝas al alia simptomo.

Se ICMP estas filtrita ie sur la vojo, neniu itinera agordo riparas tion. La riparo apartenas al la filtrilo, kaj pli malgranda MTU estas provizora solvo, kiu kaŝas la veran difekton ĝis la sekva voja ŝanĝo.

Tunela programaro aldonas proprajn grandregulilojn

OpenVPN- mssfix ĝustigas la TCP-segmentgrandon por sia dokumentita UDP-tunela kazo. Ĝi agas sur la TCP-interparolo, do ĝi ne estas alia literumo de la itinera MTU de la operaciumo, kaj ĝi ne povas helpi UDP-servon, kiu ignoras la interkonsenton.

Ne staku itineran MTU-on, ŝanĝon de interfaĉa MTU kaj MSS-limigon en unu ŝanĝfenestro. Se la problemo malaperas, vi ne scios, kiu gravis, kaj tiuj, kiujn vi tenas, limigos trafikon dum jaroj sen kialo, kiun iu memoras.

Faru ĝin reigebla, poste pruvu ĝin

La vera posedanto de la itinero decidas, ĉu la ŝanĝo supervivos rekonon. VPN-kliento, kiu instalas la itineron dinamike, kutime rekonstruos ĝin sen via metriko, kaj manala ip route add tiam aspektas kiel riparo, kiu fiaskis unu tagon poste. Metu la valoron en la agordon de la administranto, kaj se vi bezonas provizoran eksperimenton, unue notu la originan itineron.

Testu per nova konekto, kiu plenumas la operacion, kiu blokiĝis, poste konfirmu, ke la celata privata itinero ankoraŭ gajnas kaj ke nerilataj celoj ne ŝanĝiĝis. Rekonektu la tunelon kaj relegu la itineron, ĉar valoro, kiu malaperas ĉe rekonekto, ne estas riparo.

Se la pruvoj ne subtenas la ŝanĝon, forigu la anstataŭigon per ĝia administranto kaj restarigu la originajn atributojn de la itinero anstataŭ forigi la itineron. Poste notu, kion vi mezuris kaj sur kiu vojo, por ke la sekva persono povu distingi veran plibonigon de eksperimento, kiu restis funkcianta.

Rilataj artikoloj