înregistrare Logare
Puncte:1
avatar Server

stunnel + calmar = 1 cerere timp de 5 minute (resetarea conexiunii de odihnă de către egal)

drapel us
Mithrand1r

tl;dr;

Configurația cu stunnel pe client care se conectează la proxy squid cu autentificare certificat x509 funcționează doar pentru o cerere la 5 minute. Scenariu:

  • Calamar și stunnel configurat și pornit
  • wget configurat pentru utilizare gazdă locală ca proxy (stunnel)
  • Doar o cerere (de ex. wget https://github.com) la 5 minute (sau stunnel restart) munca rest got Resetare Conexiune de la egal la egal
  • Utilizarea conexiunii brute, de ex openssl s_client -key -cert -connect utilizarea comunicării directe cu calmarul funcționează corect

Descriere

Configurez arhitectura de stunnel instalat pe client care duce la calamar proxy cu Certificat x509 autentificare.

Configurarea clientului stunnel cu certificatul său care se leagă de calamar, apoi configurați HTTP PROXY pentru a viza punctul final stunnel la gazdă locală.

Calea de încredere este configurată corect pe fiecare parte, astfel încât atât certificatele de încredere squid de la client, cât și certificatul squid de încredere client la fiecare nivel - CA rădăcină și CA intermediară.

Configurația stunnelului:

sslVersion=TLSv1.2
output=/var/log/stunnel4/stunnel.log
[calamar-gcp]
cert = /etc/letsencrypt/live/test.internal/fullchain.pem
cheie = /etc/letsencrypt/live/test.internal/privkey.pem
CAFile = /usr/local/share/ca-certificates/root.crt
client = da
depanare=7
accept = 127.0.0.1:3128
connect = squid.internal:3128

Configurație de calmar

acl localnet src 0.0.0.1-0.255.255.255 # RFC 1122 „această” rețea (LAN)
acl localnet src 10.0.0.0/8 # RFC 1918 rețea privată locală (LAN)
acl localnet src 100.64.0.0/10 # RFC 6598 spațiu de adresă partajat (CGN)
acl localnet src 169.254.0.0/16 # RFC 3927 link-local mașini (conectate direct)
acl localnet src 172.16.0.0/12 # RFC 1918 rețea privată locală (LAN)
acl localnet src 192.168.0.0/16 # RFC 1918 rețea privată locală (LAN)
acl localnet src fc00::/7 # RFC 4193 interval de rețea privată locală
acl localnet src fe80::/10 # RFC 4291 link-local mașini (conectate direct)
acl SSL_ports portul 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # porturi neînregistrate
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT metoda CONECTARE
acl cert user_cert CN test.internal
http_access permite managerul localhost
http_access manager de refuz
http_access deny to_localhost
http_access permit cert
http_access permite localhost
http_access permit servicedesk
http_access deny all
https_port 3128 tls-cert=/etc/letsencrypt/live/squid.internal/cert.pem tls-key=/etc/letsencrypt/live/squid.internal/privkey.pem options=NO_SSLv3:NO_TLSv1:NO_TLSv1_1:NO_TLSv1_T client: =/usr/local/share/ca-certificates/root.crt cafile=/usr/local/share/ca-certificates/root.crt tls-default-ca=off
client_idle_pconn_timeout 5 minute
client_persistent_connections activat
pconn_lifetime 0
logformat squidtls %tl %ts.%03tu %6tr %>a %Ss/%03>Hs %<st %rm %ru %[un %Sh/%<a %mt "%ssl::>cert_subject"
access_log daemon:/var/log/squid/access-tls.log squidtls
cache neagă totul
cache_dir null /tmp
shutdown_lifetime 1 secundă
coredump_dir /var/cache/squid

Acum, ce se întâmplă pe client, după ce s-a configurat corect HTTPS_PROXY=localhost:3128, prima solicitare prin squid este acceptată, iar următoarea este respinsă cu Resetare Conexiune de la egal la egal. După 5 minute sau repornire stunnel următoarea cerere este tratată corect.

Jurnalele de la stunnel atunci când se întâmplă acest lucru, prima cerere este ok, a doua este respinsă:

2021.07.07 14:27:59 LOG7[0]: Serviciul [squid-gcp] a început
2021.07.07 14:27:59 LOG7[0]: Setarea opțiunilor de priză locală (FD=3)
2021.07.07 14:27:59 LOG7[0]: Opțiunea TCP_NODELAY setată pe soclul local
2021.07.07 14:27:59 LOG5[0]: Serviciul [squid-gcp] a acceptat conexiune de la 127.0.0.1:50142
2021.07.07 14:27:59 LOG6[0]: s_connect: conectare 100.112.0.62:3128
2021.07.07 14:27:59 LOG7[0]: s_connect: s_poll_wait 100.112.0.62:3128: așteptare 10 secunde
2021.07.07 14:27:59 LOG7[0]: FD=6 evenimente=0x2001 revents=0x0
2021.07.07 14:27:59 LOG7[0]: FD=11 evenimente=0x2005 revents=0x0
2021.07.07 14:27:59 LOG5[0]: s_connect: conectat 100.112.0.62:3128
2021.07.07 14:27:59 LOG5[0]: Serviciul [squid-gcp] conectat server la distanță de la 100.112.0.63:50392
2021.07.07 14:27:59 LOG7[0]: Setarea opțiunilor prizei de la distanță (FD=11)
2021.07.07 14:27:59 LOG7[0]: Opțiunea TCP_NODELAY setată pe soclul de la distanță
2021.07.07 14:27:59 LOG7[0]: descriptor de la distanță (FD=11) inițializat
2021.07.07 14:27:59 LOG6[0]: SNI: trimitere nume server: squid.internal
2021.07.07 14:27:59 LOG6[0]: Nu este necesar certificatul peer
2021.07.07 14:27:59 LOG7[0]: stare TLS (conectare): înainte de inițializarea SSL
2021.07.07 14:27:59 LOG7[0]: stare TLS (conectare): SSLv3/TLS scrie client salut
2021.07.07 14:27:59 LOG7[0]: stare TLS (conectare): SSLv3/TLS scrie client salut
2021.07.07 14:27:59 LOG7[0]: stare TLS (conectare): SSLv3/TLS citiți serverul salutare
2021.07.07 14:27:59 LOG6[0]: verificarea certificatului dezactivată
2021.07.07 14:27:59 LOG6[0]: verificarea certificatului dezactivată
2021.07.07 14:27:59 LOG6[0]: verificarea certificatului dezactivată
2021.07.07 14:27:59 LOG7[0]: stare TLS (conectare): certificat de server de citire SSLv3/TLS
2021.07.07 14:27:59 LOG6[0]: CA client: O=CA intern GCP, CN=CA rădăcină CA intern GCP
2021.07.07 14:27:59 LOG6[0]: CA client: O=GCP Intern CA, CN=GCP Intern CA Intermediar CA
2021.07.07 14:27:59 LOG7[0]: stare TLS (conectare): cerere de certificat de server de citire SSLv3/TLS
2021.07.07 14:27:59 LOG7[0]: stare TLS (conectare): server de citire SSLv3/TLS terminat
2021.07.07 14:27:59 LOG7[0]: stare TLS (conectare): certificat client de scriere SSLv3/TLS
2021.07.07 14:27:59 LOG7[0]: stare TLS (conectare): schimb de chei client de scriere SSLv3/TLS
2021.07.07 14:27:59 LOG7[0]: stare TLS (conectare): verificare certificat de scriere SSLv3/TLS
2021.07.07 14:27:59 LOG7[0]: stare TLS (conectare): specificația codului de modificare a scrierii SSLv3/TLS
2021.07.07 14:27:59 LOG7[0]: stare TLS (conectare): scrierea SSLv3/TLS terminată
2021.07.07 14:27:59 LOG7[0]: stare TLS (conectare): scrierea SSLv3/TLS terminată
2021.07.07 14:27:59 LOG7[0]: stare TLS (conectare): SSLv3/TLS citire modificare cifră spec.
2021.07.07 14:27:59 LOG7[0]: stare TLS (conectare): citire SSLv3/TLS terminată
2021.07.07 14:27:59 LOG7[0]: Reapelarea unei noi sesiuni
2021.07.07 14:27:59 LOG7[0]: certificatul peer a fost stocat în cache (2601 octeți)
2021.07.07 14:27:59 LOG6[0]: ID sesiune: 383CDD4E8AA87AC2ED148172C025D1A5ECE0A1FF114362503BCDED36B9BB44B0
2021.07.07 14:27:59 LOG7[0]: 1 conexiune client(e) solicitate
2021.07.07 14:27:59 LOG7[0]: 1 conexiune client a reușit(e)
2021.07.07 14:27:59 LOG7[0]: 0 renegociere(e) client(e) solicitate
2021.07.07 14:27:59 LOG7[0]: 0 reutilizare(i) de sesiune
2021.07.07 14:27:59 LOG6[0]: TLS conectat: sesiune nouă negociată
2021.07.07 14:27:59 LOG6[0]: suită de criptare TLSv1.2: AES256-GCM-SHA384 (criptare pe 256 de biți)
2021.07.07 14:27:59 LOG7[0]: Compresie: nul, extindere: nul
2021.07.07 14:27:59 LOG6[0]: Soclu de citire închis (soclu de citire)
2021.07.07 14:27:59 LOG7[0]: Se trimite alertă close_notify
2021.07.07 14:27:59 LOG7[0]: Alertă TLS (scriere): avertisment: închideți notificare
2021.07.07 14:27:59 LOG6[0]: SSL_shutdown a trimis cu succes alertă close_notify
2021.07.07 14:27:59 LOG7[0]: Alertă TLS (citiți): avertisment: închideți notificarea
2021.07.07 14:27:59 LOG6[0]: TLS închis (SSL_read)
2021.07.07 14:27:59 LOG7[0]: Închidere scrierea soclului trimis
2021.07.07 14:27:59 LOG5[0]: Conexiune închisă: 737 octeți trimiși către TLS, 234207 octeți trimiși către socket
2021.07.07 14:27:59 LOG7[0]: Descriptor de la distanță (FD=11) închis
2021.07.07 14:27:59 LOG7[0]: Descriptor local (FD=3) închis
2021.07.07 14:27:59 LOG7[0]: Serviciul [squid-gcp] terminat (0 rămas)
2021.07.07 14:28:01 LOG7[1]: Serviciul [squid-gcp] a început
2021.07.07 14:28:01 LOG7[1]: Setarea opțiunilor de priză locală (FD=3)
2021.07.07 14:28:01 LOG7[1]: Opțiunea TCP_NODELAY setată pe soclul local
2021.07.07 14:28:01 LOG5[1]: Serviciul [squid-gcp] a acceptat conexiune de la 127.0.0.1:50146
2021.07.07 14:28:01 LOG6[1]: s_connect: conectare 100.112.0.62:3128
2021.07.07 14:28:01 LOG7[1]: s_connect: s_poll_wait 100.112.0.62:3128: așteptare 10 secunde
2021.07.07 14:28:01 LOG7[1]: FD=6 evenimente=0x2001 revents=0x0
2021.07.07 14:28:01 LOG7[1]: FD=11 evenimente=0x2005 revents=0x0
2021.07.07 14:28:01 LOG5[1]: s_connect: conectat 100.112.0.62:3128
2021.07.07 14:28:01 LOG5[1]: Serviciul [squid-gcp] server la distanță conectat de la 100.112.0.63:50396
2021.07.07 14:28:01 LOG7[1]: Setarea opțiunilor prizei de la distanță (FD=11)
2021.07.07 14:28:01 LOG7[1]: Opțiunea TCP_NODELAY setată pe soclul de la distanță
2021.07.07 14:28:01 LOG7[1]: descriptor de la distanță (FD=11) inițializat
2021.07.07 14:28:01 LOG6[1]: SNI: trimitere nume server: squid.internal
2021.07.07 14:28:01 LOG6[1]: Nu este necesar certificatul peer
2021.07.07 14:28:01 LOG7[1]: stare TLS (conectare): înainte de inițializarea SSL
2021.07.07 14:28:01 LOG7[1]: stare TLS (conectare): client de scriere SSLv3/TLS salutare
2021.07.07 14:28:01 LOG3[1]: SSL_connect: Peer a fost deconectat brusc
2021.07.07 14:28:01 LOG5[1]: Resetarea conexiunii: 0 octeți trimiși la TLS, 0 octeți trimiși la soclu
2021.07.07 14:28:01 LOG7[1]: Descriptor de la distanță (FD=11) închis
2021.07.07 14:28:01 LOG7[1]: Descriptor local (FD=3) închis
2021.07.07 14:28:01 LOG7[1]: Serviciul [squid-gcp] finalizat (0 rămas)

pare în mod clar că prima cerere TLS a reușit, în timp ce a doua nici măcar nu este începută.

jurnalele din jurnalul de acces squid:

07/Iul/2021:14:27:59 +0000 1625668079.646 496 100.112.0.63 TCP_TUNNEL/200 234207 CONNECT github.com:443 - HIER_DIRECT -.142.0.63 -.
07/Jul/2021:14:28:01 +0000 1625668081.958 0 100.112.0.63 NONE/000 0 NONE error:transaction-end-before-headers - HIER_NONE/- - "-"

Jurnalele din cache:

2021/07/07 14:28:01 copil1| Eroare la negocierea conexiunii SSL pe FD 11: error:00000001:lib(0):func(0):reason(1) (1/-1)

PRIMĂ

Când încerc să folosesc openssl s_client și apoi GET https://github.com ca aceasta:

openssl s_client -cert /etc/letsencrypt/live/test.internal/cert.pem -key /etc/letsencrypt/live/test.internal/privkey.pem -connect squid.internal:3128

fiecare cerere are succes:

log de la calmar:

07/Jul/2021:14:33:24 +0000 1625668404.188 369 100.112.0.63 TCP_MISS/200 227308 GET https://github.com/ - HIER_DIRECT/140.112.0.63 TCP_MISS/200 227308 GET https://github.com/ - HIER_DIRECT/140.140.82.html
07/Jul/2021:14:33:50 +0000 1625668430.041 25 100.112.0.63 TCP_MISS/200 227578 GET https://github.com/ - HIER_DIRECT/140.112.0.63 TCP_MISS/200 227578 GET https://github.com/ - HIER_DIRECT/140.140.82.html"internal/CN=text/121.82.html
07/Jul/2021:14:33:55 +0000 1625668435.218 39 100.112.0.63 TCP_MISS/200 227580 GET https://github.com/ - HIER_DIRECT/140.112.0.63 TCP_MISS/200 227580 GET https://github.com/ - HIER_DIRECT/140.140.82.html"internal/CN=text/121.82.html

Îmi pierd mințile cu această problemă. Aș aprecia orice ajutor în acest sens.

498
1 + 3
Tom Yan avatar
drapel in
Tom Yan
Faceți stunnel `connect = ` la adresa:portul instanței squid? IIRC nu așa este folosit stunnel. Mai degrabă, va trebui să rulați stunnel în modul server (adică fără `client = yes`) pe gazda la distanță pe alt port, care este ceea ce stunnel `connect=`. Apoi, ceea ce merge la `accept = ` pe partea locală va fi capturat și transmis prin stunnel către partea la distanță.
0
Răspunde
Tom Yan avatar
drapel in
Tom Yan
Rețineți că ar putea fi posibil să utilizați squid ca server pentru stunnel, dar probabil că nu se potrivește pentru cazul dvs. de utilizare. Btw probabil că ar trebui să utilizați `http_port` în loc de `https_port` pentru abordarea menționată mai sus. (Ei bine, cu excepția cazului în care doriți ca `wget` să folosească proxy https... criptare dublă? Nu sunt sigur dacă `wget` acceptă de fapt proxy https așa cum o face `curl`; se pare că `https_proxy` este doar un alias pentru „http_proxy”; sau în sensul „http proxy pentru conexiunile tale https”...)
0
Răspunde
drapel us
Mithrand1r
hei @TomYan, mulțumesc pentru timpul acordat pentru a face aceste comentarii! Vreau să fac autentificare bazată pe certificat la instanța `squid`. Dacă fac o instanță de server `stunnel` pe squid și apoi `conectez` la `squid` pe gazda locală, voi avea atât certificatul sursă, cât și IP-ul potriviți localhost (vreau să fie client, atât IP-ul, cât și certificatul să apară în jurnale) de aceea Folosesc și `https_port`. Problema aici este că prima solicitare pe care am făcut-o pe computerul client este validă, în timp ce altele sunt resetate după `client hello` de către squid. Cred că este ceva în neregulă cu squid sau stunnel conf, dar nu pot găsi ce;(
0
Răspunde
Puncte:0
A. Darwin avatar Server
drapel my
A. Darwin

Solicitările reușite reușesc cu adevărat sau se blochează (poate din alte motive care nu au legătură)?

Lucrul interesant în configurația dvs. Squid este că:

client_idle_pconn_timeout 5 minute
client_persistent_connections activat
pconn_lifetime 0

Cu alte cuvinte, odată ce un client se conectează la proxy, se stabilește o conexiune persistentă și o închide după 5 minute de inactivitate.

Câteva soluții posibile:

  • dezactivarea conexiuni_persistente_client. Acest lucru înseamnă în esență că fiecare nouă strângere de mână TCP este tratată ca și cum ar fi complet nouă, ceea ce poate avea un impact general asupra performanței, dar ar trebui să vă rezolve problema

  • creșterea explicită a numărului de conexiuni simultane de la aceeași sursă IP care pot fi acceptate. Puteți face acest lucru prin configurarea unui ACL cu limitusercon maxconn 5 (sau alt număr).

  • creșterea timpului de inactivitate la ceva mult mai mare. Acest lucru are și un impact asupra performanței (menține conexiunile în funcțiune mult timp, ceea ce vă poate epuiza resursele).

Sper că te ajută.

0 + 0
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.