OpenVPN mssfix: varför en klient fastnar vid stora överföringar

En enda laptop fastnar vid uppladdningar genom tunneln medan varje annan enhet på samma server fortsätter att fungera. Det mönstret pekar på en väg, inte på serverkonfigurationen, och det är den vanliga ingången till mssfix-frågan. Alternativet kan hjälpa, men bara för de TCP-anslutningar det faktiskt skriver om. Att känna till dess räckvidd hindrar dig från att ändra en fungerande server för att rädda en klient.

Vad alternativet skriver om

mssfix redigerar den maximala segmentstorleken som annonseras i TCP-handskakningar som passerar genom tunneln, så att sändande sida väljer segment som ryms i den inkapslade budgeten. Det verkar på handskakningen, vilket innebär att en anslutning som öppnades före ändringen behåller det förhandlade värdet.

Det krymper inte UDP-datagram och ställer inte in tunnelns MTU. Två olika problem ger samma symptom: en TCP-sändare som ignorerar väggränsen, och en väg som tyst släpper stora paket i vilken storlek som helst. mssfix åtgärdar det första och gör ingenting för det andra.

Den skillnaden förklarar de besvikna experimenten. Att sätta ett mindre värde på en väg med svart hål ändrar segmentstorleken men inte släppet som följer, så överföringen misslyckas på en annan punkt.

Räckvidden är TCP inne i tunneln

Bara TCP-trafik skrivs om. En QUIC-session, ett spel eller ett program som skickar stora UDP-datagram behåller sina egna paketstorlekar, och om det är de överföringarna som fastnar, hör rättelsen snarare hemma vid tunnelns eller vägens MTU. Läs vilket protokoll den misslyckade överföringen använder innan du griper efter ett TCP-alternativ, för det felaktiga lagret har sin egen rättelse.

Riktningen spelar också roll. En klientinställning påverkar trafiken som den klienten skickar in i tunneln, medan servern täcker de flöden den vidarebefordrar mot klienterna. Om bara inkommande nedladdningar fastnar är värdet på klientsidan inte hela historien.

Talet och nyckelordet är inte portabla

Community-versionen av OpenVPN 2.6 accepterar ett valfritt nyckelord efter värdet. Med mtu beskriver talet den yttre paketstorleken inklusive IP- och UDP-huvuden; utan det följer argumentet en annan redovisningskonvention. En rad som kopieras mellan versioner beskriver därför inte samma paketbudget. Se manualsidan som följer med det bygge du faktiskt kör, i stället för en handledning för en annan utgåva.

Syntaxen ser ut så här:

mssfix 1400 mtu

Behandla 1400 som en platshållare, inte som en rekommendation för din väg. Härled värdet från den uppmätta vägen och den inkapsling som faktiskt används, och kom ihåg att klienter på äldre versioner eller andra implementationer kan avvisa eller tolka nyckelordet annorlunda.

Bekräfta först på den enda klienten

Mät vägen från den felande maskinen innan du ändrar något. En nyttolast som vägen kan bära utan fragmentering är talet du letar efter:

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

Den första sonden ryms i ett paket på 1500 byte när de 28 byte huvudena läggs till. Om den misslyckas med ett fragmenteringsfel och den mindre lyckas, ligger den användbara storleken någonstans däremellan, och tunnelns overhead dras av uppifrån.

Upprepa sedan överföringen som fastnade, på en ny anslutning, och jämför. Om den enda klienten förbättras medan de andra är orörda, har du hittat problemets räckvidd. Om alla klienter fastnar är värdet på serversidan det som behöver ses över. Ingen av de två resultaten rättfärdigar en ändring på hårdvara som aldrig var på den felande vägen.