Viens VPN galapunkts caur Squid: šaurs CONNECT izņēmums

Squid uz CONNECT pieprasījumu atbild ar pirmo atbilstošo http_access rindu, un šī rinda var būt atteikums. Šis viens fakts izskaidro, kāpēc VPN galapunkta izņēmums parasti neizdodas pirmajā mēģinājumā, jo pieprasījums nekad nesasniedz atļauju, ko kāds pievienoja apakšā. Šaurs labojums saglabā esošos portu sargus un iemāca tiem vienu pārskatītu avotu, galamērķi un portu. Viss pārējais starpniekserverī darbojas tieši tāpat kā iepriekš.

Kā Squid izlemj par CONNECT pieprasījumu

CONNECT pieprasījums nosauc resursdatoru un portu, un Squid pēc kārtas iet cauri http_access rindām, līdz kāda no tām atbilst. Atbilstošs atteikums nekavējoties beidz novērtēšanu, un klients no starpniekservera saņem 403. Tāpēc noteikuma pozīcija ir svarīgāka par tā formulējumu. Tās pašas rindas pārvietošana vienu soli uz augšu var pilnībā mainīt rezultātu.

Parastie sargi atsaka visu ārpus Safe_ports un atsaka CONNECT ārpus SSL_ports. Šie nosaukumi ir ACL, kas definēti jūsu pašu konfigurācijā, tāpēc to saturs pieder jums, nevis protokolam. Distribūcija var atļaut plašu portu diapazonu kā Safe_ports un vienlaikus atsevišķi ierobežot CONNECT. Izlasiet dzīvās vērtības, pirms pieņemat, ka ports ir bloķēts pēc dizaina.

Apstipriniet, ka tieši starpniekserveris atsaka pieprasījumu. Squid ģenerētais 403 nemaz neizskatās pēc VPN servera TLS brīdinājuma, un abu apvienošana vienā problēmā izmaksā pirmo stundu. Pārbaudiet pieprasījuma piekļuves žurnāla rindu, jo tā reģistrē gan darbību, gan to izraisījušo noteikumu.

Veidojiet vienu apvienotu atbilstību trīs atsevišķu ACL vietā

Veidojiet izņēmumu no trim faktiem: apstiprināta avota diapazona, vienas apstiprinātas galamērķa adreses un vienīgā porta, kurā klausās galapunkts. Divi atsevišķi ACL un viena apvienota atbilstība dod ļoti atšķirīgu politiku, jo tiek novērtēta tieši kombinācija. Apvienoto ACL sauciet pēc tā, ko tā atļauj, nevis pēc metodes, ko tā nes.

Zemāk redzamā forma izmanto dokumentācijas diapazonus, kas jāaizstāj ar pārskatītām vērtībām. Squid nav rezervējis nevienu no šiem nosaukumiem, tāpēc tos izvēlēties un uzturēt konsekventus ir jūsu ziņā. Šī recepte ir ierobežota ar Squid 6 un 7, kuru dokumentētā konfigurācija atbalsta all-of grupu. Pašreizējā uzziņa šos norādījumus atzīmē kā Squid 8 nepieejamus, tāpēc uztveriet to kā ar versiju saistītu recepti, nevis migrācijas ceļu, un pirms piemērošanas pārbaudiet norādījumu savas versijas uzziņā.

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

All-of grupa atbilst tikai tad, kad atbilst katrs dalībnieks, tas nozīmē, ka avots, galamērķis un ports tiek pārbaudīti vienā rindā. Grupa pati par sevi neko nepiešķir, un pieprasījums, kas atbilst tikai diviem no trim faktiem, to nevar apmierināt. Šī īpašība saglabā izņēmumu šauru, kad kāds vēlāk pievieno otru vārteju. Vai nu jaunais galamērķis tiek pievienots apzināti, vai pieprasījums atgriežas pie sākotnējiem sargiem.

Salieciet portu sargus, tos nenoņemot

Savās pašreizējās pozīcijās divas parastās sarga rindas izskatās šādi. Tās parasti atrodas pēc autentifikācijas un pirms politikas rindām, kas atļauj visu.

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

Pievienojiet katrai noliegto apvienoto atbilstību, lai atbilstošs izņēmums izturētu sargu, kas citādi to noraidītu. Mainās tikai sarga rindas, un katra – tikai par vienu papildu terminu.

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

Vienas piekļuves rindas termini tiek apvienoti, tāpēc rinda tagad atsaka tikai tos pieprasījumus, kas neiztur gan sākotnējo pārbaudi, gan izņēmumu. Pieprasījums apstiprinātajam galapunktam iziet, un katrs cits pieprasījums saglabā veco porta uzvedību. Tas ir šaurāk nekā pievienot portu globālajam SSL_ports sarakstam, kas atļautu šo portu katram galamērķim. Ja ports jau ir šajā sarakstā, šis ACL neko nesašaurina, un vecākā, plašākā atļauja joprojām attiecas uz citiem galamērķiem, tāpēc izlasiet dzīvo sarakstu, pirms apgalvojat, ka izņēmums atvēra portu. Tas ir arī atgriezenisks, jo divas rindas atgriežas iepriekšējā formā. Piekļuves kontroles uzziņa dokumentē kārtību un parastos sargus, no kuriem šī izmaiņa ir atkarīga.

Kur izņēmumu nedrīkst ievietot

Kārdinājums ir uzlikt atļauju virs sargiem un pabeigt. Šāds izvietojums arī izlaiž autentifikācijas un vietējā galamērķa aizsardzības, kas parasti atrodas netālu no strādājošas konfigurācijas augšas. Rezultāts nav šaurs izņēmums, bet caurums ar komentāru virs tā. Turiet jebkuru jaunu atļauju tajā pašā pārskatītajā posmā kā pārējo klienta politiku.

Pārbaudiet, kas pieprasījumam vēl nepieciešams pēc portu sargiem. Autentificēts konts, atļauta klienta adrese un galamērķa politika joprojām ir spēkā, un izņēmums nemaina nevienu no tiem. Ja jūsu starpniekserveris jau ļauj apstiprinātajam kontam sasniegt patvaļīgus galamērķus, porta sargs nekad nav bijis īstā kontrole.

Apsveriet, vai galapunkts vispār ir TCP. CONNECT izņēmums pārnēsā TCP plūsmas, un UDP izmantojošs OpenVPN profils caur to nekļūs sasniedzams. Mainiet profilu uz TCP tikai tad, ja serveris tā klausās un operators pieņem uzvedības atšķirību.

Pārbaudiet robežu ar parsētāju un reālu pieprasījumu

Parsējiet konfigurāciju pirms pārlādes un turiet atvērtu otru sesiju, to darot. Sintakses kļūda pārlādes laikā var atstāt starpniekserveri ar veco konfigurāciju vai pilnībā noraidīt jauno. Parsētājs ziņo noraidīto rindu, kas ir vairāk, nekā pateiks klienta kļūda.

Pēc tam pārlādējiet un nosūtiet vienu reālu CONNECT pieprasījumu caur starpniekserveri no apstiprināta avota. Parsētāja palaišana nāk pirmā, jo pārlāde ar drukas kļūdu neko neiemāca par politiku.

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

Pārbaudiet trīs gadījumus: apstiprinātu avotu un kontu, neapstiprinātu avotu un citu galamērķi tajā pašā portā. Trešais gadījums pierāda, ka izņēmums ir šaurs, jo tas izmanto portu bez galamērķa atbilstības. Lasiet piekļuves žurnālu visiem trim, nevis paļaujieties uz klienta ziņojumu. Veiksmīgs CONNECT izveido TCP plūsmu un neko vairāk, tāpēc VPN roku paspiešana paliek atsevišķs tests.