OpenVPN: Come mitigare i problemi di MTU del percorso in base al cliente?

Abbiamo dozzine di dispositivi integrati installati presso i clienti, tutti che chiamano a casa il nostro servizio OpenVPN. Funziona bene in generale, ma alcuni dei nostri clienti hanno gravi problemi MTU percorso. La nostra influenza sui clienti per riparare le loro reti è limitata, quindi abbiamo bisogno di OpenVPN per gestirli. In breve, la mia domanda è:

Come posso mitigare le MTU a basso percorso di alcuni client in base al client, ovvero senza utilizzare le impostazioni globali che soddisfano il caso peggiore per tutti i client

Si noti che il nostro caso peggiore è piuttosto negativo: il percorso MTU 576, elimina tutti i frammenti, non si frammenta da solo, non onora DF-bit. Capisci perché preferirei non risolvere questo problema a livello globale.

La manpage OpenVPN offre una serie di opzioni relative a MTU, in particolare --link-mtu, --tun-mtu, --fragment and --mssfix. Ma dice anche

--link-mtu [...] È meglio non impostare questo parametro se non sai cosa stai facendo.

--tun-mtu [...] È meglio usare le opzioni --fragment e / o --mssfix per gestire i problemi di dimensionamento di MTU.

Così ho iniziato a sperimentare --fragmente --mssfixpresto ho dovuto rendermi conto che almeno il primo deve essere impostato non solo sul lato client, ma anche sul lato server . Ho quindi esaminato la configurazione per client sul lato server tramite --client-config-dirma dice

Le seguenti opzioni sono legali in un contesto specifico del client: --push, --push-reset, --iroute, --ifconfig-push e --config.

Nessuna menzione delle opzioni MTU!

Quindi, ecco le mie domande più specifiche:

Perché esattamente sono link-mtue tun-mtuscoraggiati? Quali sono i potenziali problemi con queste opzioni? Nota che sono abbastanza a mio agio con il munging dell'intestazione IP di basso livello.
Quali delle opzioni link-mtu tun-mtu fragment mssfixdevono essere replicate sul lato server per funzionare?
In quale delle opzioni è link-mtu tun-mtu fragment mssfixpossibile utilizzare client-config-dir?
Nel caso in cui tutte e quattro le opzioni debbano essere speculari sul lato server e non possano essere utilizzate all'interno client-config-dir: esistono alternative per combattere MTU a basso percorso per client?

Appunti:

Parti delle mie domande sono già state poste 5 anni fa qui , ma all'epoca non hanno ricevuto risposta, quindi ho il coraggio di duplicarle.
Il server OpenVPN è attualmente 2.2.1 su Ubuntu 12.04. Stiamo preparando un aggiornamento alla 2.3.2 su Ubuntu 14.04
I client OpenVPN sono 2.2.1 su Debian 7.6
Sono felice di determinare manualmente il percorso MTU di un cliente
Attualmente non possiamo testare molto sul lato server. Ma stiamo costruendo un banco di prova separato completo, dovrebbe essere pronto presto.

Sono grato per qualsiasi consiglio utile.

ip openvpn mtu ip-fragmentation

— Nils Toedtmann
fonte

576? Cara gawd. Non vedo un MTU così basso dai tempi del dialup. Sta andando su un antico collegamento seriale?

— Michael Hampton

Potresti eseguire due server OpenVPN? Forse potresti eseguire entrambi i server sullo stesso indirizzo IP pubblico e utilizzare il port forwarding (o una politica di routing) per indirizzare i client a un altro server OpenVPN a seconda che si trovino su una rete problematica nota o meno (come determinato da un elenco di client Indirizzi IP).

— Kasperd,

@MichaelHampton mi chiedevo anche io. È> 600kbit / se RTT ~ 30ms, non mi sembra un seriale antico. Dato che hanno altre impostazioni stupide (ad esempio, non rispondono a DF con "frammentazione necessaria"), immagino che sia solo un'altra. Abbiamo detto loro, ma non ho ancora avuto risposta.

— Nils Toedtmann,

@kasperd idea interessante. Potrei eseguire più istanze del server OpenVPN. Dovrebbe avere forse 3 o 4, per diverse gamme MTU. Il NAT per client sul lato server non funzionerebbe (non riesco a prevedere gli indirizzi IP dinamici del client pubblico), ma dovrei comunque modificare la configurazione del client per le impostazioni MTU (corretta?), Quindi configurerei semplicemente la diversa porta direttamente nel client. - Ma sarebbe un incubo di manutenzione che preferirei evitare!

— Nils Toedtmann,

@NilsToedtmann Quali criteri useresti per rilevare quali clienti sono interessati? Un altro approccio potrebbe essere quello di eseguire uno script sul server dopo che un client si è connesso. Lo script può provare a eseguire il ping dell'indirizzo IP del client con dimensioni dei pacchetti variabili per capire quale funziona e quale no. Quindi può inserire iptablesregole per ridurre l'MSS su tutti i pacchetti SYN ao da quell'indirizzo IP client.

— Kasperd,

Ho risolto il problema sul lato client aggiungendo l'opzione mssfix 1300al file di configurazione.

Dalla pagina man di openvpn:

--mssfix max
    Announce to TCP sessions running over the tunnel that they should limit their send packet sizes such that after OpenVPN has encapsulated them, the resulting UDP packet size that OpenVPN sends to its peer will not exceed max bytes.

L'idea originale per la mia soluzione è venuta da personalvpn.org

— Oz123
fonte

Quindi mssfixpuò essere impostato solo sul lato client? Bene, questo è almeno qualcosa. Tuttavia, non aiuta con i pacchetti UDP (motivo per cui ero interessato alle altre opzioni, ma almeno le fragmentimpostazioni consigliate devono essere impostate anche sul lato server)

— Nils Toedtmann,

mssfix può essere aggiunto sia sul server che sul client. Tuttavia, nella negoziazione verrà utilizzato il valore più piccolo

— Ahmed,

Data la mancanza di risposte, sto pubblicando ora una soluzione non molto elegante, ma semplice: eseguire un'altra istanza OpenVPN su TCP per "client non validi"

proto tcp

e abbassa TCP MSS sul client, ad es

iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o ${OUT_DEV} -j TCPMSS --set-mss ${PATH-MTU-MINUS-40}

Un vantaggio di questa soluzione è che ogni client può impostare il proprio MSS.

Questo è certamente TCP-over-TCP, ma dovrebbe funzionare abbastanza bene in molti scenari .

Nota che sono ancora soluzioni molto interessate che non richiedono proto tcpe le segnerò come risposta valida se soddisfano più o meno i miei requisiti indicati.

— Nils Toedtmann
fonte