La sessione SSH tramite OpenVPN si interrompe / si blocca dopo alcune righe

Ho un gran numero di PC fanless identici con debian 6 (ARM). La maggior parte di questi sono collegati tramite comcast e funzionano bene. Alcuni sono collegati ai modem "WiMax" e presentano problemi di comunicazione.

In particolare: se faccio uno di questi e provo un comando come 'ps -ax', avrò indietro di circa 3 righe e la sessione verrà bloccata. Se lo lascio sedere, alla fine si chiuderà con una "sessione chiusa dal peer".

Cosa ho provato:

ssh -vvv → nessun messaggio di errore
ssh <user@host> 'command'→ questo a volte restituirà l'intero output del comando. A volte non si connette affatto.

Suggerimenti su altre cose da provare?

Ho scoperto che posso eseguire alcuni comandi con successo: es. Colpire return una dozzina di volte o più va bene. cd ~e quindi lffunziona come funziona df -h. Posso eseguire dfmolte volte con successo ma non appena provo qualcosa con più output (ad es. ls /etc) Si blocca.

Fa differenza che sto cercando di comunicare tra questi due host usando OpenVPN?

networking ip openvpn

— ethrbunny
fonte

Assicurati che il tuo MTU percorso non sia inferiore all'interfaccia MTU configurata. SSH non si frammenta quindi, con il bit DF impostato, i pacchetti vengono invece eliminati. Leggi questo per una spiegazione molto più dettagliata.

— Aaron Copley,

Ho provato a impostare MTU su tutte le interfacce su 1400 senza alcun effetto apparente. Testato con la ping -c 1 -s $((5000-28)) -M do machine-iprestituzione di 1500 - uguale alla macchina

— ethrbunny il

tracepath -n <ip>lo conferma: il 1500 è consentito per tutto il percorso.

— ethrbunny,

Perdona la mia ignoranza, ma in che modo -Taiuta in questo caso?

— Aaron Copley,

<Legge il secondo paragrafo> È un problema MTU. <Continua a leggere> Sì, problema MTU. Vedi questa discussione per una spiegazione. Non sto votando per chiudere come duplicato perché c'è un punto che l'altro thread non discute: cosa devi cambiare nella tua configurazione VPN per risolvere il problema.

— Gilles 'SO- smetti di essere malvagio' il

Risposte:

Hai i sintomi di un problema MTU : alcune connessioni TCP si bloccano, più o meno riproducibili per un determinato comando o URL ma senza un modello generale facilmente distinguibile. Un sintomo rivelatore è che le sessioni interattive di ssh funzionano bene finché non si eseguono comandi con output di grandi dimensioni. Consulta Impossibile accedere a determinati siti https su Linux tramite PPPoE per una spiegazione.

OpenVPN ha diverse opzioni relative a MTU: cerca "mtu" nel manuale. Non ho abbastanza esperienza per essere sicuro di quale opzione devi cambiare. (È anche possibile che tu possa cambiare qualcosa nella configurazione del modem Wimax.) L'opzione più probabile da cambiare è mssfix: prova a ridurre il valore fino a quando non risolve il problema. L'impostazione predefinita è 1450; qualcosa come circa 1400 potrebbe risolvere il tuo problema. Provare openvpn --fragment 1200 -mssfix; se aiuta, aumenta il valore fino a quando non inizia a rompersi.

— Gilles 'SO- smetti di essere malvagio'
fonte

Sto iniziando impostando mssfix 1200sul server e riavviando. Fin qui tutto bene. Se funziona funzionerò fino a 1300 o 1400 e vedrò cosa succede. Troppi client per modificare tutte le configurazioni remote, quindi il lato server dovrà fare.

— ethrbunny,

Ho capito che era MTU!

— Aaron Copley,

La risposta di Gilles è completamente corretta, ma c'è anche un'altra potenziale causa per questo.

Si è verificato un errore nella versione 2.3.0 di OpenVPN che disconnetteva i client durante l'invio di grandi blocchi di dati: https://community.openvpn.net/openvpn/ticket/263

Questo problema si è verificato solo quando si utilizza TCP. UDP era completamente inalterato.

— Patrick
fonte

Abbiamo avuto lo stesso problema, ed era davvero un problema di MTU. Comunque per noi il problema non era nella configurazione openVPN ma nell'interfaccia tun0.

Come l'abbiamo risolto: prima trova la dimensione massima del pacchetto che ha attraversato, con

ping <host> -s 1500 -M do

e riducendo il valore 1500 fino a quando un valore stava attraversando (per noi, 1350).

Una volta trovato il valore giusto, cambia l'interfaccia tun0 con

sudo ip link set dev tun0 mtu 1350

come è stato proposto da Sebastian qui . Dopodiché la VPN procedeva senza intoppi.

— Eino Gourdin
fonte