Jeden koncový bod VPN cez Squid: úzka výnimka pre CONNECT

Squid odpovedá na požiadavku CONNECT prvým riadkom http_access, ktorý sedí, a tým riadkom môže byť odmietnutie. Tento jediný fakt vysvetľuje, prečo výnimka pre koncový bod VPN zvyčajne zlyhá na prvý pokus, pretože požiadavka sa nikdy nedostane k povoleniu, ktoré niekto pridal na konci. Úzka oprava zachováva existujúce ochrany portov a učí ich jeden preverený zdroj, cieľ a port. Všetko ostatné na proxy sa správa presne ako predtým.

Ako Squid rozhoduje o požiadavke CONNECT

Požiadavka CONNECT uvádza hostiteľa a port a Squid prechádza riadkami http_access v poradí, kým jeden z nich nesedí. Zhodné odmietnutie okamžite ukončí vyhodnotenie a klient dostane od proxy 403. Preto je umiestnenie pravidla dôležitejšie než jeho formulácia. Posunutie toho istého riadku o krok vyššie môže výsledok úplne zmeniť.

Bežné ochrany odmietajú všetko mimo Safe_ports a odmietajú CONNECT mimo SSL_ports. Tieto názvy sú ACL definované vo vašej vlastnej konfigurácii, takže ich obsah patrí vám, nie protokolu. Distribúcia môže povoliť široký rozsah portov ako Safe_ports a pritom obmedzovať CONNECT osobitne. Prečítajte si živé hodnoty, skôr než budete predpokladať, že port je zablokovaný zámerne.

Overte, že požiadavku odmieta práve proxy. 403 vygenerovaná Squidom sa vôbec nepodobá na upozornenie TLS z VPN servera a zlúčenie oboch do jedného problému stojí prvú hodinu. Skontrolujte riadok prístupového logu pre požiadavku, pretože zaznamenáva aj akciu, aj pravidlo, ktoré ju vyvolalo.

Postavte jedno kombinované porovnanie namiesto troch voľných ACL

Výnimku postavte z troch faktov: schváleného rozsahu zdroja, jednej schválenej adresy cieľa a jediného portu, na ktorom koncový bod počúva. Dve voľné ACL a jedno kombinované porovnanie vytvárajú veľmi odlišnú politiku, pretože sa vyhodnocuje práve kombinácia. Kombinovanú ACL pomenujte podľa toho, čo povoľuje, nie podľa metódy, ktorú nesie.

Nižšie uvedený tvar používa dokumentačné rozsahy, ktoré treba nahradiť preverenými hodnotami. Squid si žiadny z týchto názvov nevyhradzuje, takže ich vyberáte vy a vy ich udržiavate konzistentné. Tento recept je obmedzený na Squid 6 a 7, ktorých dokumentovaná konfigurácia podporuje skupinu all-of. Súčasná referenčná príručka označuje tieto direktívy ako nedostupné v Squide 8, takže to berte ako recept viazaný na verziu, nie ako cestu migrácie, a pred použitím direktívu overte v referenčnej príručke svojej vlastnej verzie.

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

Skupina all-of sedí len vtedy, keď sedí každý člen, čo znamená, že zdroj, cieľ a port sa kontrolujú na jednom riadku. Skupina sama o sebe nič neudeľuje a požiadavka, ktorá sedí len s dvoma z troch faktov, ju nemôže splniť. Táto vlastnosť udržiava výnimku úzku, keď niekto neskôr pridá druhú bránu. Buď sa nový cieľ pridá zámerne, alebo sa požiadavka vráti k pôvodným ochranám.

Ohnite ochrany portov bez toho, aby ste ich odstránili

Na svojich súčasných pozíciách vyzerajú dva bežné ochranné riadky takto. Zvyčajne stoja po autentifikácii a pred riadkami politiky, ktoré dovoľujú čokoľvek.

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

Pridajte k každému negované kombinované porovnanie, aby zhodná výnimka prežila ochranu, ktorá by ju inak odmietla. Menia sa iba ochranné riadky, a to len o jeden ďalší člen každý.

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

Členy na jednom prístupovom riadku sa kombinujú, takže riadok teraz odmieta len požiadavky, ktoré zlyhajú v pôvodnej kontrole aj vo výnimke. Požiadavka na schválený koncový bod prejde a každá ďalšia požiadavka si zachová staré správanie portu. Toto je užšie než pridanie portu do globálneho zoznamu SSL_ports, čo by ten port povolilo každému cieľu. Ak port už v tomto zozname je, táto ACL nič nezužuje a staršie, širšie povolenie stále platí pre iné ciele, takže si prečítajte živý zoznam, skôr než budete tvrdiť, že výnimka port otvorila. Je aj vratné, pretože dva riadky sa vracajú do predchádzajúcej podoby. Referenčná príručka riadenia prístupu dokumentuje poradie a bežné ochrany, na ktorých táto zmena závisí.

Kam sa výnimka nesmie umiestniť

Pokušením je dať povolenie nad ochrany a skončiť. Také umiestnenie preskakuje aj ochrany autentifikácie a lokálneho cieľa, ktoré zvyčajne stoja blízko vrcholu fungujúcej konfigurácie. Výsledkom nie je úzka výnimka, ale diera s komentárom nad sebou. Každé nové povolenie držte v tej istej preverenej fáze ako zvyšok politiky klientov.

Skontrolujte, čo požiadavka po ochranách portov ešte potrebuje. Autentifikovaný účet, povolená adresa klienta aj politika cieľa stále platia a výnimka nemení nič z toho. Ak váš proxy už schválenému účtu dovoľuje dosiahnuť ľubovoľné ciele, ochrana portu nikdy nebola skutočnou kontrolou.

Zvážte, či je koncový bod vôbec TCP. Výnimka CONNECT prenáša toky TCP a profil OpenVPN, ktorý používa UDP, sa cez ňu nedostane. Zmeňte profil na TCP len vtedy, ak server takto počúva a operátor prijíma rozdiel v správaní.

Overte hranicu parserom a skutočnou požiadavkou

Pred načítaním konfiguráciu naparsujte a počas toho majte otvorenú druhú reláciu. Syntaktická chyba pri načítaní môže nechať proxy na starej konfigurácii alebo novú úplne odmietnuť. Parser nahlási odmietnutý riadok, čo je viac, než vám povie chyba klienta.

Potom znova načítajte a pošlite jednu skutočnú CONNECT cez proxy zo schváleného zdroja. Spustenie parsera prichádza prvé, pretože načítanie s preklepom vás o politike nič nenaučí.

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

Otestujte tri prípady: schválený zdroj a účet, neschválený zdroj a iný cieľ na tom istom porte. Tretí prípad dokazuje, že výnimka je úzka, pretože precvičuje port bez zhody cieľa. Čítajte prístupový log pre všetky tri, namiesto toho, aby ste verili správe klienta. Úspešný CONNECT vytvorí tok TCP a nič viac, takže handshake VPN zostáva samostatným testom.