OpenVPN segnala un uso incoerente dell'MTU: cosa confronta l'avviso

Questo avviso riporta un confronto tra le opzioni dei peer, non una misura del percorso tra loro. Le persone lo leggono come «l'MTU è sbagliato» e cambiano il numero finché la riga non sparisce. Così un confronto di configurazione viene trattato come una misura di rete, e spesso peggiora il tunnel mentre rende il registro più silenzioso. Il primo passo utile è decidere quale di questi due problemi si ha davvero.

Tre condizioni decidono la risposta: cosa confrontano i peer, se il valore è ereditato e quale sintomo esiste oltre l'avviso.

L'avviso confronta opzioni, non pacchetti

I peer OpenVPN si scambiano le stringhe di opzioni durante l'handshake e le confrontano come parte del controllo di coerenza delle opzioni. Quando un lato riporta link-mtu o tun-mtu diversamente dall'altro, la discrepanza viene registrata con entrambi i valori. Quello scambio non invia mai un pacchetto grande per vedere cosa succede, quindi l'avviso descrive la configurazione, non la capacità. Un tunnel può trasportare traffico a dimensione piena e stamparlo comunque, oppure fallire sui pacchetti grandi e non stampare nulla.

Conservi l'avviso completo con i suoi valori locale e remoto. La coppia è la prova; il singolo numero che ricorda non lo è.

Perché link-mtu è obsoleto

OpenVPN 2.6 dichiara obsoleto link-mtu perché le intestazioni variabili e le cifrature negoziate rendono un valore di collegamento fisso inaffidabile. L'opzione presupponeva una disposizione del pacchetto che il protocollo non garantisce più, quindi un vecchio profilo con un link-mtu letterale descrive un'intenzione che il codice attuale non può rispettare. Copiare quel numero in un nuovo profilo diffonde un presupposto obsoleto. Lo legga come parte della storia del vecchio profilo, non come raccomandazione.

Il controllo di coerenza ha anche un valore OCC facoltativo legato a tun-mtu, che cambia cosa viene confrontato senza cambiare cosa trasporta la rete. Impostarlo non fa entrare pacchetti più grandi.

Ripari il profilo prima di testare il percorso

Corregga una discrepanza involontaria tramite chi possiede i profili, e ricordi che una modifica lato server riguarda ogni client. Modifichi il profilo che l'istanza carica davvero, non un export che sta in una cartella di download. Poi riconnetta un client di prova e annoti quale avviso sopravvive. Se il messaggio cambia forma invece di sparire, sta confrontando opzioni diverse da quelle che crede.

Un server condiviso richiede che il suo inventario client venga controllato prima di spostare un valore globale, perché il valore adatto a un sito può romperne un altro.

Poi provi il sintomo che si ha davvero

Se i trasferimenti grandi si bloccano mentre le richieste piccole riescono, misuri la dimensione dei pacchetti verso una destinazione controllata. Una sonda che imposta il bit «non frammentare» e aumenta la dimensione del carico trova l'MTU utilizzabile del percorso molto più affidabilmente di un ping che semplicemente riesce. Includa nel test l'applicazione che fallisce: un timeout ICMP può riflettere un filtraggio, e un piccolo ping riuscito non dice nulla su un pacchetto applicativo a dimensione piena.

mssfix limita l'MSS annunciato per le sessioni TCP dentro il tunnel, il che aiuta TCP e non fa nulla per un carico UDP interno. Frammentazione e offload hanno le proprie condizioni di compatibilità. Scelga un meccanismo per il problema dimostrato invece di cambiarne diversi insieme per far tacere una riga di registro.

Conservi i valori effettivi con l'esito

Annoti i valori effettivi originali e corretti accanto all'esito di un trasferimento reale. È questa coppia a separare un'opzione di profilo obsoleta da un problema di MTU sul percorso che esiste in modo indipendente. Senza di essa, il lettore successivo vede un avviso sparito e presume che la rete sia cambiata.

Sopprimere il controllo di coerenza non concilia nulla. Rimuove l'osservazione e lascia entrambe le configurazioni come erano.