Un singur punct final VPN prin Squid: o excepție CONNECT îngustă

Squid răspunde unei cereri CONNECT cu prima linie http_access care se potrivește, iar acea linie poate fi o respingere. Acest singur fapt explică de ce o excepție pentru un punct final VPN eșuează de obicei la prima încercare, pentru că cererea nu ajunge niciodată la permisiunea pe care cineva a adăugat-o la final. O corecție îngustă păstrează protecțiile de port existente și le învață o sursă, o destinație și un port revizuite. Tot restul de pe proxy se comportă exact ca înainte.

Cum decide Squid o cerere CONNECT

O cerere CONNECT numește un host și un port, iar Squid parcurge liniile http_access în ordine până când una dintre ele se potrivește. O respingere potrivită încheie imediat evaluarea, iar clientul primește un 403 de la proxy. De aceea poziția unei reguli contează mai mult decât formularea ei. Mutarea aceleiași linii un pas mai sus poate schimba complet rezultatul.

Protecțiile convenționale resping tot ce este în afara Safe_ports și resping CONNECT în afara SSL_ports. Acele nume sunt ACL definite în propria configurație, așa că conținutul lor vă aparține, nu protocolului. O distribuție poate permite o gamă largă de porturi ca Safe_ports și, în același timp, poate restricționa CONNECT separat. Citiți valorile reale înainte de a presupune că un port este blocat prin proiectare.

Confirmați că proxy-ul este componenta care respinge cererea. Un 403 generat de Squid nu seamănă deloc cu o alertă TLS de la serverul VPN, iar unirea celor două într-o singură problemă costă prima oră. Verificați linia din jurnalul de acces pentru cerere, pentru că înregistrează atât acțiunea, cât și regula care a produs-o.

Construiți o singură potrivire combinată în loc de trei ACL separate

Construiți excepția din trei fapte: un interval de sursă aprobat, o adresă de destinație aprobată și singurul port pe care ascultă punctul final. Două ACL separate și o potrivire combinată produc o politică foarte diferită, pentru că ceea ce este evaluat este combinația. Numiți ACL-ul combinat după ce permite, nu după metoda pe care o transportă.

Forma de mai jos folosește intervale de documentație care trebuie înlocuite cu valori revizuite. Squid nu rezervă niciunul dintre aceste nume, așa că sunt ale dumneavoastră de ales și de păstrat consecvente. Această rețetă este limitată la Squid 6 și 7, a căror configurație documentată acceptă grupul all-of. Referința actuală marchează directiva ca indisponibilă în Squid 8, așa că tratați acest lucru ca pe o rețetă legată de o versiune, nu ca pe o cale de migrare, și verificați directiva în referința propriei versiuni înainte de a o aplica.

acl pvpn_src src 192.0.2.128/25
acl pvpn_dst dst 198.51.100.77/32
acl pvpn_port port 1194
acl pvpn_ok all-of CONNECT pvpn_port pvpn_dst pvpn_src

Grupul all-of se potrivește numai când fiecare membru se potrivește, ceea ce înseamnă că sursa, destinația și portul sunt verificate pe o singură linie. Grupul nu acordă nimic de unul singur, iar o cerere care se potrivește doar cu două dintre cele trei fapte nu îl poate satisface. Această proprietate păstrează excepția îngustă atunci când cineva adaugă mai târziu o a doua poartă. Fie destinația nouă este adăugată deliberat, fie cererea revine la protecțiile originale.

Îndoiți protecțiile de port fără a le elimina

În pozițiile lor actuale, cele două linii de protecție convenționale arată astfel. De obicei stau după autentificare și înaintea liniilor de politică ce permit totul.

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

Adăugați potrivirea combinată negată la fiecare, astfel încât o excepție potrivită să supraviețuiască unei protecții care altfel ar respinge-o. Se schimbă doar liniile de protecție, și doar cu câte un termen suplimentar fiecare.

http_access deny CONNECT !SSL_ports !pvpn_ok
http_access deny !Safe_ports !pvpn_ok

Termenii de pe o linie de acces sunt combinați, așa că linia respinge acum doar cererile care eșuează atât la verificarea originală, cât și la excepție. O cerere către punctul final aprobat trece, iar orice altă cerere păstrează comportamentul vechi al portului. Aceasta este mai îngust decât adăugarea portului într-o listă SSL_ports globală, care ar permite acel port pentru orice destinație. Dacă portul este deja în acea listă, acest ACL nu îngustează nimic și permisiunea mai veche și mai largă se aplică în continuare altor destinații, așa că citiți lista reală înainte de a afirma că excepția a deschis portul. Este și reversibilă, pentru că două linii revin la forma anterioară. Referința de control al accesului documentează ordinea și protecțiile convenționale de care depinde această modificare.

Unde nu trebuie plasată excepția

Tentația este să puneți o permisiune deasupra protecțiilor și să terminați. Acea plasare sare și peste protecțiile de autentificare și de destinație locală care stau de obicei aproape de vârful unei configurații funcționale. Rezultatul nu este o excepție îngustă, ci o gaură cu un comentariu deasupra. Păstrați orice permisiune nouă în aceeași etapă revizuită ca restul politicii de clienți.

Verificați de ce mai are nevoie cererea după protecțiile de port. Un cont autentificat, o adresă de client permisă și o politică de destinație se aplică în continuare, iar excepția nu schimbă niciuna dintre ele. Dacă proxy-ul dumneavoastră lasă deja contul aprobat să ajungă la destinații arbitrare, protecția de port nu a fost niciodată controlul real.

Luați în considerare dacă punctul final este măcar TCP. O excepție CONNECT transportă fluxuri TCP, iar un profil OpenVPN care folosește UDP nu va deveni accesibil prin ea. Schimbați profilul în TCP doar dacă serverul ascultă astfel și operatorul acceptă diferența de comportament.

Verificați limita cu analizatorul și cu o cerere reală

Analizați configurația înainte de reîncărcare și țineți o a doua sesiune deschisă în timp ce faceți asta. O eroare de sintaxă la reîncărcare poate lăsa proxy-ul pe configurația veche sau poate respinge-o complet pe cea nouă. Analizatorul raportează linia respinsă, ceea ce este mai mult decât vă va spune eroarea din partea clientului.

Apoi reîncărcați și trimiteți o cerere CONNECT reală prin proxy dintr-o sursă aprobată. Rularea analizatorului vine prima, pentru că o reîncărcare cu o greșeală de tastare nu vă învață nimic despre politică.

squid -k parse
squid -k reconfigure
curl -v -p -x http://proxy.lab.internal:3128 https://vpn.lab.internal:1194/ --max-time 5

Testați trei cazuri: o sursă și un cont aprobate, o sursă neaprobată și o destinație diferită pe același port. Al treilea caz este cel care demonstrează că excepția este îngustă, pentru că exersează portul fără potrivirea destinației. Citiți jurnalul de acces pentru toate trei în loc să vă bazați pe mesajul clientului. Un CONNECT reușit stabilește un flux TCP și nimic mai mult, așa că strângerea de mână VPN rămâne un test separat.