Problema OpenVPN: la negoziazione della chiave TLS non è riuscita entro 60 secondi

14

Sto configurando un server OpenVPN (versione 2.3.10) su un server Windows 2012 ma non riesco a farlo funzionare.

Il server è dietro un router e ho aperto la porta 1194 e creato una regola per inoltrare il traffico su questa porta al server.

Ecco il registro che vedo sul server quando provo a connettermi da un client:

Mon Mar 21 11:11:47 2016 XX.XX.XX.XX:57804 TLS: Initial packet from [AF_INET]XX.XX.XX.XX:57804, sid=fdf7a7ac 0264c7f3
Mon Mar 21 11:12:38 2016 XX.XX.XX.XX:55938 TLS: Initial packet from [AF_INET]XX.XX.XX.XX:55938, sid=1f242a3f e454a525
Mon Mar 21 11:12:48 2016 XX.XX.XX.XX:57804 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Mar 21 11:12:48 2016 XX.XX.XX.XX:57804 TLS Error: TLS handshake failed
Mon Mar 21 11:12:48 2016 XX.XX.XX.XX:57804 SIGUSR1[soft,tls-error] received, client-instance restarting

Dove XX.XX.XX.XX è l'ip del client. Quindi capisco da questo che almeno il client è in grado di arrivare al server, quindi non ci sono problemi di routing o firewall.

Ho seguito la descrizione fornita qui Guida facile di Windows Qualche idea?

openvpn

— vmasanas
fonte

1

Supponendo che i due lotti XX.XX.XX.XXrappresentino lo stesso indirizzo (si prega di considerare di non offuscare tali cose ), sono interessato alla modifica dei numeri di porta di origine (57804, 55938). Ciò mi suggerisce che c'è un NAT inaffidabile nel modo, il che è il caso più spesso di UDP. Stai utilizzando il trasporto UDP o TCP e, nel primo caso, puoi provare il secondo e vedere se il problema scompare?

— MadHatter,

dare vedo questo messaggio sulla console del server ho capito che almeno il client può arrivarci, quindi supponevo che il problema non fosse NAT. Sbaglio qui?

— vmasanas,

1

Non tutti i NAT sono uguali. Alcuni hanno voci di tabella di stato di breve durata, in particolare per UDP, e OpenVPN non accetterà bene le modifiche alla porta di origine. Rispondi alla domanda che ho posto e, se del caso, prova la modifica che ho suggerito.

— MadHatter,

Non sono così esperto qui, quindi puoi dirmi come verificare se sto usando UDP o TCP?

— vmasanas,

Bene, potresti provare a man openvpncercare qualcosa che controlli il protocollo. Non dimenticare di cambiarlo su client e server, se decidi di fare il test.

— MadHatter,

21

La cosa interessante è come il numero di porta cambia a metà flusso:

Lun 21 Mar 11:11:47 2016 XX.XX.XX.XX: 57804 TLS: pacchetto iniziale da [AF_INET] XX.XX.XX.XX: 57804, sid = fdf7a7ac 0264c7f3

Lun 21 Mar 11:12:38 2016 XX.XX.XX.XX: 55938 TLS: pacchetto iniziale da [AF_INET] XX.XX.XX.XX: 55938, sid = 1f242a3f e454a525

Questo mi fa pensare che, tra il client e il server, ci sia un dispositivo NAT che si comporta male, un dispositivo con voci di tabella di stato di breve durata, che sta cambiando il numero di porta di origine che si applica al flusso stabilito del client, causando al server di pensa che siano in corso due comunicazioni di breve durata, anziché una continua.

Tali dispositivi generalmente lo fanno solo con UDP, quindi ti ho consigliato di confermare che stai usando UDP e provare invece TCP. Questo hai fatto e hai scoperto che risolve il problema. Il prossimo passo è identificare il dispositivo NAT che si comporta male, colpirlo con un martello da club e sostituirlo con uno che non commette l'errore cardinale di presumere che tutte le comunicazioni UDP siano effimere; ma hai indicato che sei felice di passare a TCP come soluzione alternativa e quindi la questione è conclusa.

— Cappellaio Matto
fonte

2

+1 per il tuo occhio d'aquila!

— Diamante

@bangal perché, grazie! Gran parte del diavolo è nei dettagli, in questo settore.

— MadHatter,

Sì, lo so, ma l'ho perso e l'ho visto solo dopo che hai indicato. Era abbastanza sicuro che fosse un problema con il firewall.

— Diamante

Beh, lo è, quindi avevi ragione. E non ti picchiare, la prossima volta sembrerai più difficile!

— MadHatter,

C'è qualche vantaggio sull'uso di UDP invece di TCP? TCP sta funzionando per me ora a meno che non ci sia alcun aspetto negativo che io stia bene.

— vmasanas,

3

Questo è uno degli errori più comuni nella configurazione di Openvpn e c'è una voce FAQ per questo. Ho intenzione di citare questo qui:

Errore TLS: la negoziazione della chiave TLS non è riuscita entro 60 secondi (verificare la connettività di rete)

Uno dei problemi più comuni nella configurazione di OpenVPN è che i due demoni OpenVPN su entrambi i lati della connessione non sono in grado di stabilire una connessione TCP o UDP tra loro.

Questo è quasi il risultato di:

Un firewall perimetrale sulla rete del server sta filtrando i pacchetti OpenVPN in arrivo (per impostazione predefinita OpenVPN utilizza il numero di porta UDP o TCP 1194).

Un firewall software in esecuzione sulla stessa macchina server OpenVPN sta filtrando le connessioni in entrata sulla porta 1194. Tenere presente che molti sistemi operativi bloccheranno le connessioni in entrata per impostazione predefinita, se non diversamente configurato.

Un gateway NAT sulla rete del server non ha una regola di port forwarding per TCP / UDP 1194 all'indirizzo interno della macchina server OpenVPN.

La configurazione del client OpenVPN non ha l'indirizzo del server corretto nel suo file di configurazione. La direttiva remota nel file di configurazione del client deve puntare al server stesso o all'indirizzo IP pubblico del gateway della rete del server.

Un'altra possibile causa è che il firewall di Windows sta bloccando l'accesso per il file binario openvpn.exe. Potrebbe essere necessario inserire nella whitelist (aggiungerlo all'elenco "Eccezioni") affinché OpenVPN funzioni.

È molto probabile che qualcuno di questi stia causando lo stesso problema anche nel tuo caso. Quindi basta scorrere l'elenco uno per uno per risolverlo.

Rif: TLS Errore: la negoziazione della chiave TLS non è riuscita entro 60 secondi (verificare la connettività di rete)

— Diamante
fonte

Ho esaminato questi punti ma non sono sicuro che mi manchi qualcosa: 1. per il momento i firewall sono disattivati sia nel client che nel server, 2. lo stesso, 3. il router ha una regola di inoltro al server e vedo il traffico che appare sulla console del server, 4.client ha l'indirizzo IP corretto, 5. nessun firewall che posso dire.

— vmasanas,

Beh, onestamente non riesco a pensare ad altro al momento. A dire il vero, come è la configurazione di rete in Windows Server? Ha più gateway per caso? Il gateway predefinito è puntato sul router? Se sì, il resto che puoi testare è, come suggerito da MadHatter, testare con tcp.

— Diamante

Se qualcuno ha voglia di dare una mano, ho pubblicato (ancora un'altra) domanda di fallimento della stretta di mano TLS qui: serverfault.com/questions/867599/…

— Ola Tuvesson

Un'altra cosa da cercare è l' alta latenza tra i due host . Mi stavo solo grattando la testa ampiamente, e per qualche ragione dimenticata stavo ottenendo 6000ms + ping round trip in una direzione (da client a server), ma non viceversa. Ciò ha portato alla negoziazione chiave a richiedere più di 60 anni. Il riavvio del router fornito dal mio ISP ha risolto il problema. Probabilmente un raro caso limite, ma speriamo che aiuti qualcuno.

— s.co.tt

3

Stavo ottenendo timeout di negoziazione chiave TLS come questo. Ma nel mio caso mi sono reso conto che il collegamento remoto era un indirizzo IP locale.

La VPN sul nostro firewall pfSense era stata erroneamente inserita nell'interfaccia LAN anziché nell'interfaccia WAN, quindi la configurazione esportata era impostata per provare a connettersi all'indirizzo IP LAN del firewall - che non avrebbe mai funzionato con il client naturalmente una LAN diversa.

Penso che i principali takeaway da questo siano:

Ottenere un timeout di negoziazione chiave non significa necessariamente che sei riuscito a connetterti a qualsiasi cosa.

Quindi a questo punto può valere la pena verificare che in realtà ti stai connettendo nel posto giusto e non ci sono regole firewall che bloccano la connessione, ecc. Soprattutto se la tua configurazione è stata generata automaticamente.

Nota che ottenere un prompt di accesso non significa che sei connesso , poiché OpenVPN richiede le tue credenziali prima di provare a connetterti.
Assicurati che il tuo server VPN sia in ascolto sulla giusta interfaccia.

(Naturalmente, questo è uno dei numerosi errori di configurazione sul lato server che potrebbero verificarsi, come le regole del firewall, l'inserimento di un numero di porta errato, il mixaggio di TCP e UDP, ecc.)

— mwfearnley
fonte

1

Ho avuto lo stesso errore e nessun consiglio mi ha aiutato, tutto sembrava andare bene: IP, porte, firewall, tutto. Diventato pazzo per 2 ore.

La soluzione era quella di cambiare il protocollo da UDP a TCP nella configurazione del client (apparentemente ho disabilitato UDP di proposito molto tempo fa).

Spero che questo aiuti qualcuno :)

LE: questo ha risolto il mio problema ma non è l'approccio migliore come da commenti qui sotto. È necessario utilizzare UDP anziché TCP. Mi ha aiutato perché avevo impostazioni diverse tra il client e le configurazioni del server.

— bosch
fonte

Dovresti sapere che l'incapsulamento del TCP all'interno del TCP è molto probabile che causi problemi di prestazioni molto cattivi, a causa di entrambi gli stack TCP che cercano di competere l'uno contro l'altro.

— SEE

In effetti, funziona come una merda. Anche se non capisco quello che hai detto, la performance è molto scarsa. Dovrei passare a UDP allora?

— bosch,

2

Sì. UDP è lo standard per le implementazioni VPN, per una buona ragione. TCP ha funzionalità di correzione degli errori - la possibilità di ritrasmettere i pacchetti persi, ecc. Se incapsuli TCP all'interno di TCP e incorri nella perdita di pacchetti, entrambi gli stack TCP (il traffico "interno" e il traffico crittografato OpenVPN) prova e correggi per i pacchetti persi. Quando si incapsula TCP in UDP, questo non è un problema: solo il traffico interno riproverà.

— SEE

Grazie per il suggerimento e per le spiegazioni. Sono passato a UDP e ho tenuto d'occhio le connessioni. Inoltre, ho bisogno di leggere qualcosa in più sulle pile ...

— Bosch,

Una pagina utile che spiega perché TCP su TCP è una cattiva idea: sites.inka.de/bigred/devel/tcp-tcp.html

— mwfearnley

1

Nessuna delle soluzioni menzionate in precedenza ha funzionato. Nel mio caso, anche se il registro client mostrava lo stesso errore TLS Error: TLS key negotiation failed to occur within 60 seconds, i registri del server mostravano VERIFY ERROR: depth=0, error=CRL has expired.

Sul server, i seguenti passaggi hanno risolto il problema di connessione:

# cd <easyrsa folder>
# ./easyrsa gen-crl
above command generates new crl.pem file (in my case in pki folder)
using chown/chmod make sure 'pki/crl.pem' is readable by openvpn server (for example: chmod 640 pki/crl.pem)
# systemctl restart openvpn

— mpprdev
fonte

0

Si noti che è possibile ottenere un errore di negoziazione della chiave TLS, senza connettersi correttamente al server OpenVPN - o addirittura connettersi correttamente a nulla!

Ho modificato una configurazione VPN per connettermi a localhost, su una porta che non ascoltava nulla:

OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] costruito il 26 aprile 2018
Windows versione 6.2 (Windows 8 o successiva) 64 bit
versioni della libreria: OpenSSL 1.1.0h 27 mar 2018, LZO 2.10
TCP / UDP: conservazione dell'indirizzo remoto utilizzato di recente: [AF_INET] 127.0.0.1:12345
Collegamento UDP locale (associato): [AF_INET] [undef]: 0
Collegamento UDP remoto: [AF_INET] 127.0.0.1:12345 
Errore TLS: la negoziazione della chiave TLS non è riuscita entro 60 secondi (controlla la connettività di rete)
Errore TLS: stretta di mano TLS non riuscita
SIGUSR1 [soft, tls-error] ricevuto, riavvio del processo
...

L'errore può indurti a credere che stai parlando con un server VPN.

Potresti anche ricevere prima le credenziali, ma nulla al di fuori del tuo computer le ha effettivamente richieste.

— mwfearnley
fonte

0

Mi sono imbattuto in questo errore in AWS, dove OpenVPN è stato installato su un server con un IP pubblico, ma su un'istanza che si trovava in una sottorete privata, ovvero una sottorete che non aveva un percorso verso un gateway Internet.

Una volta distribuito OpenVPN su un server all'interno di una sottorete pubblica, tutto ha funzionato bene :)

Sulle sottoreti pubbliche / private in AWS: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html

— Zoltán
fonte

0

Ho anche riscontrato il TLS key negotiation failed to occur within 60 secondsproblema.

Dal suggerimento ufficiale, come post Diamant, ci deve essere qualcosa di sbagliato nella connessione di rete. Tuttavia, né il firewall né il NAT causano il problema.

Nel mio caso, ho prima verificato la connessione da nc -uvz xxx.xxx.xxx.xxx 1194. Il link è OK

Inoltre, molti altri client VPN all'interno della stessa LAN funzionano bene.

Da qualche parte ho notato che la connessione udp ha alcuni problemi nella risposta o nel port forward.

Quindi interrompo i client VPN in esecuzione dal più grande ip al client sospeso, ad esempio da "10.8.0.100" a "10.8.0.50".

Quindi avviare i client VPN fermati al contrario.

Scoppio! Tutti i client VPN lavorano in modo propizio.

In conclusione, esiste la possibilità TLS key negotiation failed to occur within 60 secondsche si verifichino problemi per l' avvio di più client VPN in una LAN in una sequenza errata.

— samson.wang
fonte

Non è chiaro come questo si collega al problema nella domanda originale.

— Ward - Ripristina Monica

0

Un possibile motivo è se il server richiede una versione TLS più recente di quella supportata dal client. cioè 1,2 vs 1,0.

La cosa ovvia da provare è aggiornare il client OpenVPN o modificare il lato server per accettare TLS 1.0.

— OZK
fonte