OpenVPN mssfix: per què un client s’atura en transferències grans

Un sol portàtil s’atura en les pujades pel túnel mentre tots els altres dispositius del mateix servidor continuen funcionant. Aquest patró apunta a un camí, no a la configuració del servidor, i és l’entrada habitual a la qüestió de mssfix. L’opció pot ajudar, però només per a les connexions TCP que realment reescriu. Conèixer-ne l’abast us evita canviar un servidor que funciona per rescatar un sol client.

Què reescriu l’opció

mssfix edita la mida màxima de segment anunciada als handshakes TCP que passen pel túnel, de manera que el costat emissor tria segments que encaixen en el pressupost encapsulat. Actua sobre el handshake, cosa que significa que una connexió oberta abans del canvi conserva el valor que va negociar.

No redueix els datagrames UDP ni fixa la MTU del túnel. Dos problemes diferents produeixen el mateix símptoma: un emissor TCP que ignora el límit del camí i un camí que descarta en silenci paquets grans de qualsevol mida. mssfix aborda el primer i no fa res pel segon.

Aquesta distinció explica els experiments decebedors. Fixar un valor més petit en un camí amb forat negre canvia la mida del segment, però no la caiguda que segueix, així que la transferència falla en un altre punt.

L’abast és TCP dins del túnel

Només es reescriu el trànsit TCP. Una sessió QUIC, un joc o una aplicació que envia datagrames UDP grans conservarà les seves pròpies mides de paquet, i si aquestes són les transferències que s’aturen, la solució pertany més aviat a la MTU del túnel o del camí. Llegiu quin protocol fa servir la transferència que falla abans d’acudir a una opció TCP, perquè la capa equivocada té la seva pròpia solució.

La direcció també importa. Un paràmetre del client afecta el trànsit que aquest client envia al túnel, mentre que el servidor cobreix els fluxos que reenvia cap als clients. Si només s’aturen les baixades entrants, el valor del costat del client no és tota la història.

El número i la paraula clau no són portables

La comunitat d’OpenVPN 2.6 accepta una paraula clau opcional després del valor. Amb mtu, el número descriu la mida del paquet exterior incloent-hi les capçaleres IP i UDP; sense ella, l’argument segueix una convenció comptable diferent. Per tant, una línia copiada entre versions no descriu el mateix pressupost de paquets. Consulteu la pàgina del manual que acompanya la compilació que realment executeu en lloc d’un tutorial per a una altra versió.

La sintaxi té aquest aspecte:

mssfix 1400 mtu

Tracteu 1400 com un marcador de posició, no com una recomanació per al vostre camí. Deriveu el valor del camí mesurat i de l’encapsulació que realment s’utilitza, i recordeu que els clients amb versions antigues o altres implementacions poden rebutjar o reinterpretar la paraula clau.

Confirmeu-ho primer en l’únic client

Mesureu el camí des de la màquina que falla abans de canviar res. Una càrrega útil que el camí pugui transportar sense fragmentació és el número que busqueu:

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

La primera prova encabeix un paquet de 1500 bytes un cop afegits els 28 bytes de capçaleres. Si falla amb un error de fragmentació i la més petita té èxit, la mida utilitzable és en algun punt entre totes dues, i la sobrecàrrega del túnel es resta de dalt.

Després repetiu la transferència que s’havia aturat, en una connexió nova, i compareu. Si el client únic millora mentre els altres queden intactes, heu trobat l’abast del problema. Si s’aturen tots els clients, el valor del costat del servidor és el que cal revisar. Cap dels dos resultats no justifica un canvi en maquinari que mai no era al camí que fallava.