OpenVPN mssfix: waarom een enkele klient vasval tydens groot oordragte

Een skootrekenaar val vas op oplaai deur die tonnel terwyl elke ander toestel op dieselfde bediener aanhou werk. Daardie patroon wys na een pad, nie na die bedienerkonfigurasie nie, en dit is die gewone ingang tot die mssfix-vraag. Die opsie kan help, maar net vir die TCP-verbindings wat dit werklik herskryf. Om die omvang daarvan te ken, keer dat jy ’n werkende bediener verander om een klient te red.

Wat die opsie herskryf

mssfix wysig die maksimum segmentgrootte wat in TCP-handdrukke wat deur die tonnel gaan, aangekondig word, sodat die senderkant segmente kies wat in die ingekapselde begroting pas. Dit werk op die handdruk, wat beteken dat ’n verbinding wat voor die verandering oopgemaak is, die waarde behou wat dit onderhandel het.

Dit verklein nie UDP-datagramme nie, en dit stel nie die tonnel-MTU nie. Twee verskillende probleme veroorsaak dieselfde simptoom: ’n TCP-sender wat die padlimiet ignoreer, en ’n pad wat groot pakkette van enige grootte stilweg laat val. mssfix pak die eerste aan en doen niks vir die tweede nie.

Daardie onderskeid verduidelik die teleurstellende eksperimente. Om ’n kleiner waarde op ’n swartgat-pad te stel, verander die segmentgrootte maar nie die val wat daarop volg nie, so die oordrag misluk op ’n ander punt.

Omvang is TCP binne die tonnel

Net TCP-verkeer word herskryf. ’n QUIC-sessie, ’n speletjie of ’n toepassing wat groot UDP-datagramme stuur, behou sy eie pakketgroottes, en as dit die oordragte is wat vasval, hoort die oplossing eerder by die tonnel- of pad-MTU. Lees watter protokol die mislukte oordrag gebruik voordat jy na ’n TCP-opsie gryp, want die verkeerde laag het sy eie oplossing.

Rigting maak ook saak. ’n Klientinstelling beïnvloed die verkeer wat daardie klient in die tonnel instuur, terwyl die bediener die strome dek wat hy na kliente aanstuur. As slegs inkomende aflaaie vasval, is die klientkant-waarde nie die hele storie nie.

Die nommer en die sleutelwoord is nie oordraagbaar nie

Die gemeenskapsweergawe van OpenVPN 2.6 aanvaar ’n opsionele sleutelwoord ná die waarde. Met mtu beskryf die nommer die buitenste pakketgrootte insluitend IP- en UDP-opskrifte; daarsonder volg die argument ’n ander rekeningkundige konvensie. ’n Reël wat tussen weergawes gekopieer word, beskryf dus nie dieselfde pakketbegroting nie. Kyk in die handleidingsblad wat saam met die bou val wat jy werklik gebruik, eerder as na ’n tutoriaal vir ’n ander uitgawe.

Die sintaksis lyk so:

mssfix 1400 mtu

Behandel 1400 as ’n plekhouer, nie as ’n aanbeveling vir jou pad nie. Lei die waarde af uit die gemete pad en die inkapseling wat werklik gebruik word, en onthou dat kliente op ouer weergawes of ander implementasies die sleutelwoord kan verwerp of anders kan interpreteer.

Bevestig eers op die een klient

Meet die pad vanaf die mislukte masjien voordat jy iets verander. ’n Lading wat die pad sonder fragmentering kan dra, is die nommer waarna jy soek:

ping -M do -s 1472 10.8.0.1
ping -M do -s 1400 10.8.0.1

Die eerste toets pas ’n pakket van 1500 grepe in sodra die 28 grepe opskrifte bygevoeg word. As dit met ’n fragmenteringsfout misluk en die kleiner een slaag, lê die bruikbare grootte êrens tussen hulle, en die tonnel-oorhoof kom van bo af.

Herhaal dan die oordrag wat vasgeval het, op ’n nuwe verbinding, en vergelyk. As die enkele klient verbeter terwyl ander onaangeraak bly, het jy die omvang van die probleem gevind. As elke klient vasval, is die bedienerkant-waarde die een om na te gaan. Nie een van die twee uitslae regverdig ’n verandering op hardeware wat nooit in die mislukte pad was nie.