OpenVPN avisa que l'MTU s'usa de manera inconsistent: què compara l'avís

Aquest avís informa d'una comparació entre les opcions dels parells, no d'un mesurament del camí entre ells. La gent el llegeix com «l'MTU és incorrecte» i canvia el número fins que la línia desapareix. Això tracta una comparació de configuració com un mesurament de xarxa, i sovint empitjora el túnel mentre fa més silenciós el registre. El primer pas útil és decidir quin d'aquests dos problemes teniu realment.

Tres condicions decideixen la resposta: què comparen els parells, si el valor és obsolet i quin símptoma existeix més enllà de l'avís.

L'avís compara opcions, no paquets

Els parells d'OpenVPN intercanvien les seves cadenes d'opcions durant l'apretada de mà i les comparen com a part de la comprovació de consistència d'opcions. Quan un costat informa d'link-mtu o tun-mtu de manera diferent de l'altre, la discrepància es registra amb tots dos valors. Aquest intercanvi no envia mai un paquet gran per veure què passa, així que l'avís descriu configuració, no capacitat. Un túnel pot transportar trànsit de mida completa i tot i així imprimir-lo, o fallar amb paquets grans i no imprimir res.

Conserveu l'avís complet amb els seus valors local i remot. La parella és l'evidència; el número solt que recordeu no ho és.

Per què link-mtu està obsolet

OpenVPN 2.6 marca link-mtu com a obsolet perquè les capçaleres variables i els xifrats negociats fan que un valor d'enllaç fix no sigui fiable. L'opció suposava una disposició de paquet que el protocol ja no garanteix, així que un perfil antic amb un link-mtu literal descriu una intenció que el codi actual no pot complir. Copiar aquest número en un perfil nou escampa una suposició obsoleta. Llegiu-lo com a part de la història del perfil antic, no com una recomanació.

La comprovació de consistència també té un valor OCC opcional lligat a tun-mtu, que canvia què es compara sense canviar què transporta la xarxa. Fixar-lo no fa que hi càpiguen paquets més grans.

Repareu el perfil abans de provar el camí

Corregiu una discrepància no intencionada a través de qui posseeix els perfils, i recordeu que un canvi al servidor afecta tots els clients. Editeu el perfil que la instància carrega realment, no una exportació que és en una carpeta de baixades. Després reconnecteu un client de prova i fixeu-vos en quin avís sobreviu. Si el missatge canvia de forma en lloc de desaparèixer, esteu comparant opcions diferents de les que penseu.

Un servidor compartit necessita que es revisi l'inventari de clients abans de moure un valor global, perquè el valor que va bé a un lloc pot trencar un altre.

Després proveu el símptoma que teniu realment

Si les transferències grans s'encallen mentre les peticions petites funcionen, mesureu la mida dels paquets contra una destinació controlada. Una sonda que fixa el bit de no fragmentar i augmenta la mida de la càrrega troba l'MTU útil del camí molt més fiablement que un ping que simplement té èxit. Incloeu l'aplicació que falla a la prova: un temps d'espera ICMP pot reflectir filtratge, i un ping petit amb èxit no diu res sobre un paquet d'aplicació de mida completa.

mssfix limita l'MSS anunciat per a les sessions TCP dins del túnel, cosa que ajuda TCP i no fa res per a una càrrega UDP interna. La fragmentació i la descàrrega tenen les seves pròpies condicions de compatibilitat. Trieu un mecanisme per al problema demostrat en lloc de canviar-ne diversos alhora per silenciar una línia del registre.

Conserveu els valors efectius amb el resultat

Anoteu els valors efectius originals i corregits al costat del resultat d'una transferència real. Aquesta parella és el que separa una opció de perfil obsoleta d'un problema d'MTU al camí que existeix independentment. Sense això, el següent lector veu un avís que ha desaparegut i assumeix que la xarxa ha canviat.

Suprimir la comprovació de consistència no reconcilia res. Elimina l'observació i deixa les dues configuracions tal com eren.