Nuovi dettagli aggiunti alla fine di questa domanda; è possibile che mi stia concentrando sulla causa.
Ho una VPN basata su UDP OpenVPN impostata in tapmodalità (ho bisogno tapperché ho bisogno della VPN per passare i pacchetti multicast, che non sembra possibile con le tunreti) con una manciata di client su Internet. Ho riscontrato frequenti blocchi della connessione TCP sulla VPN. Cioè, stabilirò una connessione TCP (ad esempio una connessione SSH, ma altri protocolli hanno problemi simili) e ad un certo punto durante la sessione, sembra che il traffico cesserà di essere trasmesso su quella sessione TCP.
Ciò sembra essere correlato a punti in cui si verificano trasferimenti di dati di grandi dimensioni, ad esempio se eseguo un lscomando in una sessione SSH o se ho catun file di registro lungo. Alcune ricerche su Google mostrano una serie di risposte come questa precedente su Server Fault , indicando che il probabile colpevole è un problema MTU: che durante i periodi di traffico intenso, la VPN sta cercando di inviare pacchetti che vengono rilasciati da qualche parte nelle tubazioni tra il Endpoint VPN. La risposta sopra collegata suggerisce di utilizzare le seguenti impostazioni di configurazione OpenVPN per mitigare il problema:
fragment 1400
mssfix
Ciò dovrebbe limitare l'MTU utilizzato sulla VPN a 1400 byte e correggere la dimensione massima del segmento TCP per impedire la generazione di pacchetti di dimensioni maggiori. Questo sembra mitigare un po 'il problema, ma vedo ancora spesso i blocchi. Ho provato diverse dimensioni come argomenti della fragmentdirettiva: 1200, 1000, 576, tutti con risultati simili. Non riesco a pensare a nessuna strana topologia di rete tra le due estremità che potrebbe innescare un simile problema: il server VPN è in esecuzione su una macchina pfSense connessa direttamente a Internet e anche il mio client è collegato direttamente a Internet in un'altra posizione.
Un altro strano pezzo del puzzle: se eseguo l' tracepathutilità, questo sembra aiutare il problema con la banda. Un'esecuzione di esempio è simile a:
[~]$ tracepath -n 192.168.100.91
1: 192.168.100.90 0.039ms pmtu 1500
1: 192.168.100.91 40.823ms reached
1: 192.168.100.91 19.846ms reached
Resume: pmtu 1500 hops 1 back 64
L'esecuzione sopra è tra due client sulla VPN: ho avviato la traccia da 192.168.100.90alla destinazione di 192.168.100.91. Entrambi i client sono stati configurati fragment 1200; mssfix;nel tentativo di limitare l'MTU utilizzata sul collegamento. I risultati di cui sopra sembrano suggerire che è tracepathstato in grado di rilevare un MTU di percorso di 1500 byte tra i due client. Suppongo che sarebbe leggermente più piccolo a causa delle impostazioni di frammentazione specificate nella configurazione OpenVPN. Ho trovato quel risultato un po 'strano.
Ancora più strano, tuttavia: se ho una connessione TCP nello stato di stallo (ad es. Una sessione SSH con un elenco di directory bloccato nel mezzo), l' esecuzione del tracepathcomando mostrato sopra provoca il riavvio della connessione ! Non riesco a capire alcuna spiegazione ragionevole del perché questo sarebbe il caso, ma penso che questo potrebbe puntare verso una soluzione per sradicare il problema.
Qualcuno ha qualche consiglio per altre cose da provare?
Modifica: sono tornato e ho guardato un po 'di più, e ho trovato solo informazioni più confuse:
Ho impostato la connessione OpenVPN al frammento a 1400 byte, come mostrato sopra. Quindi, mi sono connesso alla VPN da Internet e ho usato Wireshark per esaminare i pacchetti UDP inviati al server VPN durante lo stallo. Nessuno era maggiore del conteggio di 1400 byte specificato, quindi la frammentazione sembra funzionare correttamente.
Per verificare che anche una MTU a 1400 byte fosse sufficiente, ho eseguito il ping al server VPN utilizzando il seguente comando (Linux):
ping <host> -s 1450 -M doQuesto (credo) invia un pacchetto di 1450 byte con la frammentazione disabilitata (almeno ho verificato che non funzionava se lo avessi impostato su un valore ovviamente troppo grande come 1600 byte). Questi sembrano funzionare bene; Ricevo risposte dall'host senza problemi.
Quindi, forse questo non è affatto un problema MTU. Sono solo confuso su cos'altro potrebbe essere!
Modifica 2: La tana del coniglio continua a diventare sempre più profonda: ora ho isolato un po 'di più il problema. Sembra essere correlato al sistema operativo esatto utilizzato dal client VPN. Ho duplicato con successo il problema su almeno tre macchine Ubuntu (versioni da 12.04 a 13.04). Posso duplicare in modo affidabile un blocco della connessione SSH in circa un minuto semplicemente cat-ing un file di registro di grandi dimensioni.
Tuttavia , se eseguo lo stesso test utilizzando una macchina CentOS 6 come client, non vedo il problema! Ho provato usando la stessa versione client OpenVPN che stavo usando sulle macchine Ubuntu. Posso catregistrare i file per ore senza vedere il blocco della connessione. Questo sembra fornire alcune intuizioni sulla causa ultima, ma non sono sicuro di quale intuizione sia.
Ho esaminato il traffico sulla VPN utilizzando Wireshark. Non sono un esperto TCP, quindi non sono sicuro di cosa fare dei dettagli cruenti, ma l'essenza è che a un certo punto, un pacchetto UDP viene eliminato a causa della larghezza di banda limitata del collegamento Internet, causando ritrasmissioni TCP all'interno il tunnel VPN. Sul client CentOS, queste ritrasmissioni avvengono correttamente e le cose procedono felici. Ad un certo punto con i client Ubuntu, tuttavia, la fine remota inizia a ritrasmettere lo stesso segmento TCP più e più volte (con il ritardo di trasmissione che aumenta tra ogni ritrasmissione). Il client invia quello che sembra un ACK TCP valido ad ogni ritrasmissione, ma l'estremità remota continua a trasmettere periodicamente lo stesso segmento TCP. Questo si estende all'infinito e la connessione si blocca. La mia domanda qui sarebbe:
- Qualcuno ha qualche consiglio su come risolvere e / o determinare la causa principale del problema TCP? È come se l'estremità remota non accettasse i messaggi ACK inviati dal client VPN.
Una differenza comune tra il nodo CentOS e le varie versioni di Ubuntu è che Ubuntu ha una versione del kernel Linux molto più recente (da 3.2 in Ubuntu 12.04 a 3.8 in 13.04). Un puntatore ad alcuni nuovi bug del kernel forse? Suppongo che se così fosse, non sarei l'unico a riscontrare il problema; Non penso che questo assomigli ad una configurazione particolarmente esotica.
tunrete dovrebbe essere possibile mediante l'esecuzione di demoni di routing multicast (come pimd ) e facendo in modo che il server OpenVPN utilizzi le--topologyopzioni impostate su "sottorete" - consultare il manuale