Puncte:0

OCServ elimină conexiunile (OCServ 0.12.6 pe Ubuntu 20.04.03)

drapel in

Server: OCServ

ocserv 0.12.6

Compilat cu: seccomp, tcp-wrappers, oath, radius, gssapi, PAM, PKCS#11, AnyConnect
Versiunea GnuTLS: 3.6.13 (compilată cu 3.6.11)

Client: openconnect

Versiunea OpenConnect v8.10-2build1~ubuntu20.04.1~ppa1
Utilizarea GnuTLS 3.6.13. Caracteristici prezente: TPMv2, PKCS#11, simbol software RSA, simbol software HOTP, simbol software TOTP, Yubikey OATH, chei de sistem, DTLS, ESP
Protocoale acceptate: anyconnect (implicit), nc, gp, pulse

Diagrama rețelei

                   CUTIE VPS                                                                 
                |--------------------------------------------- --------------------------|  
                | altele *< ----+ |  
                | | vpn.<domeniu>.com rev proxy trecere către |  
                | |------@HA Proxy -----------| 127.0.1.1:443 |  
                | | | (SSL gestionat de ocserv) |  
                | [TCP 80 & TCP 443] | |  
inet --> IP public - > 10.10.0.5 |---> 127.0.1.1 |  
                | [udp 44443] [tcp 443] |  
                | \ | |  
                | \ @ |  
                | \------------------------------------=@ocserv ascultare pe |  
                | tcp 127.0.1.1:443 și udp 10.10.0.5:44443 |  
                |--------------------------------------------- --------------------------|  

NOTĂ:

Efectiv, cu ce mă confrunt este mai jos:

  • Mă pot conecta fără probleme
  • muncitori-izolaţi este setat sa fals în config
  • The udp-port in conf este setat la 44443 (non-443) pentru a exclude orice probleme specifice VPS pe acel port
  • DTLS este stabilit nicio problemă
  • Certificatul SSL al serverului este un certificat wildcard.
  • libpam-cap a fost dezactivat în caseta VPS în care rulează instanța ocserv, pentru a ocoli problema de blocare, așa cum s-a menționat Aici
  • Problema menționată mai jos este văzută indiferent dacă DTLS este stabilit sau nu (am setat udp-ascultă-gazdă adresa către interfața lo pentru a se asigura că pachetele UDP înregistrate pe IP-ul public NU ajung la OCServ, astfel încât DTLS NU este stabilit).
  • PROBLEMA Aparent aleatoriu, sau poate la un interval regulat, conexiunea pare să fie resetată openconnect raportare Eroare de citire SSL: conexiunea TLS a fost încheiată necorespunzător.; reconectarea. (linia numărul 191 din fișierul jurnal openconnectout_20211108.log). OCServ de la capătul serverului pare să raporteze eroarea după cum urmează (jurnalele complete sunt atașate atât pentru openconnect, cât și pentru ocserv). Chiar înainte de apariția acestei erori, jurnalele clientului openconnect arată mai multe linii de Pachetul DTLS trimis de 48 de octeți; Trimiterea DTLS a returnat 42\rNiciun lucru de făcut; dormi 27000 ms... indicând că pachetele DTLS sunt comunicate. Aceleași informații pot fi văzute și în jurnalele ocserv. Jurnalele ocserv de mai jos pot fi văzute în rândul numărul 589 al fișierului jurnal ocservout_20211108.log
ocserv[<first_worker_pid>]: worker[<username>]: <vpn_client_public_ip_address> a primit 42 de octeți (DTLS)
ocserv[<first_worker_pid>]: worker[<username>]: <vpn_client_public_ip_address> decomprimat de la 41 la 48
ocserv[<first_worker_pid>]: worker[<username>]: <vpn_client_public_ip_address> care scrie 48 octeți(i) în TUN
ocserv[<first_worker_pid>]: TLS[<3>]: ASSERT: ../../lib/buffers.c[_gnutls_io_write_flush]:696
ocserv[<first_worker_pid>]: TLS[<5>]: REC: Trimitere alertă[1|0] - Închideți notificarea
ocserv[<first_worker_pid>]: TLS[<5>]: REC[0x55f94ae54b60]: Se pregătește Packet Alert(21) cu lungime: 2 și min pad: 0
ocserv[<first_worker_pid>]: TLS[<9>]: ENC[0x55f94ae54b60]: cipher: AES-256-GCM, MAC: AEAD, Epoch: 2
ocserv[<first_worker_pid>]: TLS[<2>]: WRITE: -1 returnat de la 0x9, errno: 32
ocserv[<first_worker_pid>]: TLS[<3>]: ASSERT: ../../lib/buffers.c[errno_to_gerr]:230
ocserv[<first_worker_pid>]: TLS[<3>]: ASSERT: ../../lib/buffers.c[_gnutls_io_write_flush]:722
ocserv[<first_worker_pid>]: TLS[<3>]: ASSERT: ../../lib/record.c[_gnutls_send_tlen_int]:588
ocserv[<first_worker_pid>]: TLS[<3>]: ASSERT: ../../lib/record.c[gnutls_bye]:304
ocserv[<first_worker_pid>]: TLS[<5>]: REC[0x55f94ae54b60]: Începutul curățării epocii
ocserv[<first_worker_pid>]: TLS[<5>]: REC[0x55f94ae54b60]: Sfârșitul curățării epocii
ocserv[<first_worker_pid>]: TLS[<5>]: REC[0x55f94ae54b60]: Epoca #2 eliberată
ocserv[<first_worker_pid>]: TLS[<3>]: ASSERT: ../../lib/buffers.c[_gnutls_io_write_flush]:696
ocserv[<first_worker_pid>]: TLS[<5>]: REC: Trimitere alertă[1|0] - Închideți notificarea
ocserv[<first_worker_pid>]: TLS[<5>]: REC[0x55f94ae46800]: Se pregătește Packet Alert(21) cu lungime: 2 și min pad: 0
ocserv[<first_worker_pid>]: TLS[<9>]: ENC[0x55f94ae46800]: cipher: AES-256-GCM, MAC: AEAD, Epoch: 1
ocserv[<first_worker_pid>]: TLS[<5>]: REC[0x55f94ae46800]: Sent Packet[281474976710664] Alerta(21) în epoca 1 și lungime: 39
ocserv[<first_worker_pid>]: TLS[<5>]: REC[0x55f94ae46800]: Începutul curățării epocii
ocserv[<first_worker_pid>]: TLS[<5>]: REC[0x55f94ae46800]: Sfârșitul curățării epocii
ocserv[<first_worker_pid>]: TLS[<5>]: REC[0x55f94ae46800]: Epoca #1 eliberată
ocserv[<first_worker_pid>]: worker[<username>]: <vpn_client_public_ip_address> trimiterea mesajului „sm: worker cli stats” către secmod
ocserv[<secmod_pid>]: sec-mod: a primit cerere de la pid <first_worker_pid> și uid 65534
ocserv[<secmod_pid>]: sec-mod: cmd [size=73] sm: worker cli stats
ocserv[<first_worker_pid>]: worker[<username>]: <vpn_client_public_ip_address> a trimis statistici periodice (in: 192, out: 496) la sec-mod
ocserv[<ocserv_main_pid>]: main[<username>]:<vpn_client_public_ip_address>:47586 lucrător terminat
ocserv[<ocserv_main_pid>]: main[<username>]:<vpn_client_public_ip_address>:47586 trimitere mesaj sm: sesiune aproape de sec-mod
ocserv[<secmod_pid>]: sec-mod: cerere primită sm: sesiunea închisă
ocserv[<secmod_pid>]: sec-mod: cmd [size=40] sm: close session
ocserv[<secmod_pid>]: sec-mod: se închide temporar sesiune pentru <nume utilizator> (sesiune: <session_ID>)
ocserv[<ocserv_main_pid>]: main[<username>]:<vpn_client_public_ip_address>:47586 utilizator deconectat (motiv: eroare nespecificată, rx: 192, tx: 496)
  • A patra linie din extragerea de mai sus (linia 592 din fișierul jurnal ocservout_20211108.log) este de unde pare să provină problema.
  • INFORMAȚII: În jurul liniei 887 a fișierului jurnal ocservout_20211108.log, ignoră mesajele despre clientul care închidea prematur conexiunea, deoarece doar eu am ucis openconnect pe computerul client.
  • Probleme similare au fost observate la utilizarea OpenConnect GUI pentru Windows, precum și a aplicației pentru Android OpenConnect.

Există recomandări despre cum să ocoliți acest lucru? Aș dori să evit ca conexiunea VPN să se activeze și să se oprească frecvent.

ocservout_20211108.log (obținut prin a sudo ocserve -f -c /etc/ocserv/ocserv.conf -d 9999 > outfile.log 2>&1)

openconnectout_20211108.log (obținut prin a echo -n parola_obfuscata | sudo openconnect -b vpn.<domain>.com:443 -u obfuscated_username --passwd-on-stdin -vvv --dump-http-traffic > outfile.log 2>&1 )

NOTĂ Informațiile sensibile din fișierele jurnal de mai sus au fost REDACTATE/OBFUSCATE

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.