Squid vastab CONNECT-päringule esimese http_access-reaga, mis sobib, ja see rida võib olla keeldumine. See üks tõsiasi selgitab, miks VPN-i lõpp-punkti erand tavaliselt esimesel katsel ebaõnnestub, sest päring ei jõua kunagi loani, mille keegi lõppu lisas. Kitsas parandus säilitab olemasolevad pordikaitsed ja õpetab neile ühe ülevaadatud allika, sihtkoha ja pordi. Kõik muu puhverserveril käitub täpselt nagu enne.

Kuidas Squid CONNECT-päringu üle otsustab

CONNECT-päring nimetab hosti ja pordi ning Squid läbib http_access-read järjest, kuni üks neist sobib. Sobiv keeldumine lõpetab hindamise kohe ja klient saab puhverserverilt 403. Seetõttu on reegli asukoht tähtsam kui selle sõnastus. Sama rea ühe sammu võrra ülespoole liigutamine võib tulemuse täielikult muuta.

Tavapärased kaitsed keelavad kõik väljaspool Safe_ports ja keelavad CONNECT-i väljaspool SSL_ports. Need nimed on ACL-id, mis on määratletud teie enda konfiguratsioonis, seega kuulub nende sisu teile, mitte protokollile. Distributsioon võib lubada laia portide vahemikku Safe_portsina, piirates samal ajal CONNECT-i eraldi. Lugege tegelikke väärtusi enne, kui eeldate, et port on konstruktsiooni tõttu blokeeritud.

Kinnitage, et just puhverserver keeldub päringust. Squidi loodud 403 ei sarnane sugugi VPN-serveri TLS-hoiatusega ja kahe üheks probleemiks liitmine maksab esimese tunni. Kontrollige päringu juurdepääsulogi rida, sest see registreerib nii toimingu kui ka selle tekitanud reegli.

Ehitage üks kombineeritud vaste kolme eraldi ACL-i asemel

Ehitage erand kolmest faktist: heakskiidetud allika vahemik, üks heakskiidetud sihtaadress ja ainus port, millel lõpp-punkt kuulab. Kaks eraldi ACL-i ja üks kombineeritud vaste annavad väga erineva poliitika, sest hinnatakse just kombinatsiooni. Nimetage kombineeritud ACL selle järgi, mida see lubab, mitte meetodi järgi, mida see kannab.

Allpool olev vorm kasutab dokumentatsiooni vahemikke, mis tuleb asendada ülevaadatud väärtustega. Squid ei reserveeri ühtegi neist nimedest, seega on need teie valida ja teie hoida järjepidevana. See retsept on piiratud Squidiga 6 ja 7, mille dokumenteeritud konfiguratsioon toetab all-of-gruppi. Praegune viide märgib need direktiivid Squidis 8 kättesaamatuks, seega käsitlege seda versioonipõhise retseptina, mitte migratsiooniteena, ja kontrollige direktiivi enne rakendamist oma versiooni viites.

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-grupp sobib ainult siis, kui sobib iga liige, mis tähendab, et allikas, sihtkoht ja port kontrollitakse ühel real. Grupp iseenesest ei anna midagi ja päring, mis sobib vaid kahe kolmest faktist, ei saa seda rahuldada. See omadus hoiab erandi kitsana, kui keegi hiljem lisab teise lüüsi. Kas uus sihtkoht lisatakse teadlikult või langeb päring tagasi algsetele kaitsetele.

Painutage pordikaitsed ilma neid eemaldamata

Oma praegustes positsioonides näevad kaks tavapärast kaitserida välja nii. Tavaliselt asuvad need pärast autentimist ja enne poliitikaridu, mis lubavad kõike.

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

Lisage kummalegi eitatud kombineeritud vaste, et sobiv erand jääks ellu kaitsest, mis muidu selle keelaks. Muutuvad ainult kaitseread ja ainult ühe lisatermini võrra kummalgi.

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

Ühe juurdepääsurea terminid kombineeritakse, seega keelab rida nüüd ainult päringud, mis ebaõnnestuvad nii algses kontrollis kui ka erandis. Heakskiidetud lõpp-punkti päring läheb läbi ja iga teine päring säilitab vana pordikäitumise. See on kitsam kui pordi lisamine üldisesse SSL_ports-loendisse, mis lubaks seda porti igale sihtkohale. Kui port on selles loendis juba olemas, ei kitsenda see ACL midagi ja vanem, laiem luba kehtib endiselt teiste sihtkohtade suhtes, seega lugege tegelikku loendit enne, kui väidate, et erand avas pordi. See on ka pööratav, sest kaks rida lähevad tagasi oma varasemale kujule. Juurdepääsukontrolli viide dokumenteerib järjekorra ja tavapärased kaitsed, millest see muudatus sõltub.

Kuhu erandit paigutada ei tohi

Kiusatus on panna luba kaitsete kohale ja lõpetada. See paigutus jätab vahele ka autentimise ja kohaliku sihtkoha kaitse, mis tavaliselt asuvad töötava konfiguratsiooni ülaosas. Tulemus ei ole kitsas erand, vaid auk, mille kohal on kommentaar. Hoidke iga uus luba samas ülevaadatud etapis nagu ülejäänud kliendipoliitika.

Kontrollige, mida päring pärast pordikaitsmeid veel vajab. Autenditud konto, lubatud kliendi aadress ja sihtkohapoliitika kehtivad endiselt ning erand ei muuda neist ühtegi. Kui teie puhverserver lubab heakskiidetud kontol juba jõuda suvalistesse sihtkohtadesse, ei olnud pordikaitse kunagi tegelik kontroll.

Mõelge, kas lõpp-punkt on üldse TCP. CONNECT-erand kannab TCP-vooge ja UDP-d kasutav OpenVPN-profiil ei muutu selle kaudu kättesaadavaks. Muutke profiil TCP-ks ainult siis, kui server kuulab nii ja operaator aktsepteerib käitumise erinevust.

Kontrollige piiri parseri ja tegeliku päringuga

Parsige konfiguratsioon enne uuesti laadimist ja hoidke selle ajal teist sessiooni avatuna. Süntaksiviga uuesti laadimisel võib jätta puhverserveri vana konfiguratsiooni peale või uue täielikult tagasi lükata. Parser teatab tagasilükatud rea, mis on rohkem, kui kliendiviga teile ütleb.

Seejärel laadige uuesti ja saatke üks tegelik CONNECT päring läbi puhverserveri heakskiidetud allikast. Parseri käivitamine tuleb esimesena, sest trükiveaga uuesti laadimine ei õpeta teile poliitika kohta midagi.

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

Testige kolme juhtumit: heakskiidetud allikas ja konto, heakskiitmata allikas ning teine sihtkoht samal pordil. Kolmas juhtum tõestab, et erand on kitsas, sest see kasutab porti ilma sihtkoha vasteta. Lugege juurdepääsulogi kõigi kolme jaoks, selle asemel et usaldada kliendi sõnumit. Õnnestunud CONNECT loob TCP-void ja mitte midagi enamat, seega jääb VPN-i kätlus eraldi testiks.

Seotud artiklid