înregistrare Logare
Puncte:1
DrTeeth avatar Server

Resetarea conexiunii OpenVPN la fiecare 2 minute

drapel vn
DrTeeth

Am un server OpenVPN care rulează pe Ubuntu în AWS și folosesc Tunnelblick pe macOS pentru a mă conecta la el. Nu am nicio problemă să mă conectez la alte servere VPN, dar acesta pare să expire/resetează la fiecare 2 minute.

Profilul meu OVPN:

client
dev tun
proto udp
telecomandă ............... 1194
rezoluție-reîncercare infinit
nobind
utilizator nimeni
grup fără grup
cheie-persiste
persist-tun
server remote-cert-tls
cifrul AES-256-CBC
verbul 3
cifrul AES-128-CBC
auth SHA256
direcția cheii 1
<ca>
-----ÎNCEPE CERTIFICAT-----
...
-----CERTIFICAT FINAL-----
</ca>
<cert>
Certificat:
    Date:
        Versiune: 3 (0x2)
...
-----ÎNCEPE CERTIFICAT-----
...
-----CERTIFICAT FINAL-----
</cert>
<cheie>
-----BEGIN CHEIE PRIVATĂ-----
...
-----SCHEARE CHEIE PRIVATA-----
</key>
<tls-auth>
#
# Cheie statică OpenVPN de 2048 de biți
#
-----BEGIN OpenVPN Cheie statică V1-----
...
-----END Tasta statică OpenVPN V1-----
</tls-auth>

La conectare, serverul împinge următoarele setări:

PUSH: S-a primit mesaj de control: „PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 8.8.8.8,route 172.16.0.0 255.255.240.0,route 172.16.16.0 255.16.16.0 255.16.16.0 255.405.25.25.25. 172.16.144.0 255.255.240.0, ruta 10.8.0.1, topologie net30, ping 10, ping-repornire 120, ifconfig 10.8.0.6 10.8.0.5, peer-id 1, cipher AES-256

(rețineți în mod specific ping 10, ping-repornire 120)

Creșterea nivelului de jurnal pe client, se pare că conexiunea trimite pachete de date:

2021-09-03 11:31:21.848620 UDP WRITE [62] la [AF_INET]...:1194: P_ACK_V1 kid=0 pid=[ #13 ] [ 6 ]
2021-09-03 11:31:21.848768 UDP WRITE [130] la [AF_INET]...:1194: P_DATA_V2 kid=0 DATA len=129
2021-09-03 11:31:21.848856 UDP WRITE [226] la [AF_INET]...:1194: P_DATA_V2 kid=0 DATA len=225

Cu toate acestea, conexiunea încetează întotdeauna după aproximativ 2 minute. Jurnalul clientului arată:

2021-09-03 11:40:26.121900 [cc-vpn] Timeout de inactivitate (--ping-restart), repornind
2021-09-03 11:40:26.122379 SIGUSR1[soft,ping-restart] primit, repornirea procesului
2021-09-03 11:40:26.122504 MANAGEMENT: >STATE:1630683626,RECONNECTING,ping-restart,,,,,
2021-09-03 11:40:26.448969 MANAGEMENT: „Reține eliberarea” CMD

Nu există nimic în jurnalul serverului, în afară de repornirea conexiunii.

Timeout-ul de 2 minute are sens având în vedere ping-repornire 120 setarea a fost împinsă către client, dar nu sunt clar de ce crede că a fost inactiv. Ce îmi lipsește? Există o setare pe client care împiedică trimiterea corectă a ping-ului către server?

În mod specific, adăugarea ping/ping-restart la configurația clientului nu pare să ajute (presupun că oricum ar fi suprascris de serverul PUSH).

Cum pot depana acest lucru și să-mi dau seama de ce conexiunea nu este menținută vie?

1076
1 + 2
Nikita Kipriyanov avatar
drapel za
Nikita Kipriyanov
S-ar putea să aveți doi clienți care folosesc aceeași pereche de certificat/chei și rulează simultan?
1
Răspunde
DrTeeth avatar
drapel vn
DrTeeth
Da. Asta e. Am dat peste câteva alte răspunsuri care sugerau asta, dar nu am putut găsi celălalt client și știam că nu aveam unul care rulează. Se pare că altcineva avea un container vechi rulând în fundal care încă îl folosea. Mai bine încă, ambii clienți au încercat să se reconecteze de fiecare dată când au fost deconectați, așa că doar se luptau pentru conexiune. Mi-aș dori ca mesajul de eroare să fie mai bun... nu este chiar „timeout de inactivitate”... @NikitaKipriyanov Dacă doriți să scrieți acest lucru ca răspuns, voi fi bucuros să vă acord meritul. Altfel îmi voi scrie prostia mea.
0
Răspunde
Puncte:1
Nikita Kipriyanov avatar Server
drapel za
Nikita Kipriyanov

Acesta este adesea semnul că există mai mulți clienți care folosesc această pereche cheie/certificat:

  • (1) se autentifică
  • (2) autentifică; serverul vede același certificat, așa că crede că tocmai a fost înlocuită conexiunea și (1) nu va mai primi ping-uri de menținere
  • (1) ratează niște ping-uri, decide că conexiunea a încetat și se reconecta, acum (2) nu va primi ping-uri
  • (2) ratează niște ping-uri, decide că conexiunea a încetat și se reconecta, acum (1) nu va primi ping-uri

Vezi ce se întâmplă și, de asemenea, este clar cum se stabilește timeout-ul de inactivitate ping-repornire este implicat aici.

Pentru ca acest lucru să nu se întâmple, trebuie să vă gestionați cu atenție CA VPN. În special:

  • Urmăriți unde sunt instalate cheile și cine este responsabil de dispozitivul pe care este instalată fiecare cheie. Aveți o modalitate de a contacta pe oricine care are chei VPN active (de exemplu, înregistrați numărul de telefon, e-mailul, etc., puteți configura OpenSSL, astfel încât acesta să solicite acele date în timpul emiterii certificatului și să înregistreze acele date direct în certificate și index CA) .
  • Nu utilizați niciodată aceeași cheie/cert de mai multe ori; nu puneți niciodată cheie/cert șabloane; dacă clonați un sistem, ștergeți cheile acolo. Cheile trebuie întotdeauna generate și certificate eliberate din nou de fiecare dată când sistemul este dislocat.
  • Dacă un utilizator solicită (o altă) cheie/cert în timp ce are unul activ, trebuie să explice de ce.Este posibil să fi pierdut date vechi deoarece sistemul de operare a fost reinstalat și au uitat să salveze configurația VPN; sau pur și simplu ar putea avea nevoie să aibă VPN pe un computer suplimentar. Sau orice. Evaluând explicația lor, fie tu mai întâi revoca cheie veche înainte de a emite alta sau emite o cheie cu un alt CN pentru a evita o ciocnire.
  • Educați-vă utilizatorii să vă anunțe întotdeauna cheia/certul lor nu mai este folosit (este pierdut sau motivul eliberării sale), astfel încât să îl puteți revoca. Și atunci trebuie să-l revocați.
  • Foarte important, educați utilizatorii să ugent vă anunță dacă bănuiesc că cheia/certul a fost furat, caz în care trebuie să îl revocați imediat.

Acestea sunt părți ale unui proces numit „securitate în rețea”. VPN nu ar putea fi sigură fără o anumită disciplină, indiferent cât de perfectă este software-ul și criptografia de ultimă oră pe care o folosește.

0 + 4
DrTeeth avatar
drapel vn
DrTeeth
Mi-aș dori foarte mult ca clientul sau serverul să aibă un mesaj de eroare mai bun - nu este cu adevărat un „timeout de inactivitate”, ci mai degrabă doi clienți care încearcă să fure conexiunea activă unul de la celălalt. Acestea fiind spuse, acesta a fost răspunsul pentru mine - altcineva folosea profilul pe o mașină pe care niciunul dintre noi nu o mai folosea cu adevărat și a rămas încercând să se conecteze/reconecteze în timp ce eu încercam să fac același lucru.
0
Răspunde
Nikita Kipriyanov avatar
drapel za
Nikita Kipriyanov
Serverul nu a putut să facă asta. Raportează doar ceea ce vede: un client se conectează în mod repetat și din nou. Nu poate asocia cu ușurință încercările ulterioare de conectare și decide „aceștia sunt doi clienți care se confruntă cu același certificat”. Fiecare nouă autentificare vine de la o nouă pereche (adresă, port), așa că, deși ar putea exista o *informație*, aceștia *ar putea* să fie doar doi clienți, nu există o modalitate fiabilă de a determina asta. Am văzut cazuri în care această perspectivă a fost greșită. Nimeni nu vrea ca mesajele de eroare ale serverului să fie *înșelătoare*, așa că mai bine să rămână așa cum sunt.
0
Răspunde
DrTeeth avatar
drapel vn
DrTeeth
Încă nu sunt convins că serverul nu a putut face ceva. Clientul A se conectează. Clientul B se conectează apoi, ceea ce face ca conexiunea Clientului A să nu mai fie validă deoarece folosește același certificat. Doar serverul știe că a invalidat o conexiune deoarece un alt client s-a conectat. În acel moment, serverul ar putea a) să arunce un mesaj în propriul său fișier jurnal (nu am văzut niciunul), b) să trimită un mesaj către unul sau ambii clienți că mai mulți clienți încearcă să folosească același certificat (similar cu DNS static mesaje de conflict folosind același IP), c) ține evidența IP-urilor și trimite un mesaj unui client care se reconecta
0
Răspunde
DrTeeth avatar
drapel vn
DrTeeth
Dar înțeleg că aceasta este o decizie de proiectare din partea OpenVPN, deci în afara domeniului de aplicare a acesteia. Doar... poate dacă un dezvoltator OpenVPN se plictisește într-o noapte citind aceste comentarii...?
0
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.