Jeden koncový bod VPN přes Squid: úzká výjimka pro CONNECT

Squid odpovídá na požadavek CONNECT prvním řádkem http_access, který odpovídá, a tím řádkem může být odmítnutí. Tento jediný fakt vysvětluje, proč výjimka pro koncový bod VPN obvykle selže na první pokus, protože požadavek se nikdy nedostane k povolení, které někdo přidal na konec. Úzká oprava zachovává stávající ochrany portů a učí je o jednom prověřeném zdroji, cíli a portu. Všechno ostatní na proxy se chová přesně jako dřív.

Jak Squid rozhoduje o požadavku CONNECT

Požadavek CONNECT uvádí hostitele a port a Squid prochází řádky http_access v pořadí, dokud některý neodpovídá. Odpovídající odmítnutí okamžitě ukončí vyhodnocení a klient dostane od proxy 403. Proto je umístění pravidla důležitější než jeho formulace. Posunutí stejného řádku o krok výš může výsledek zcela změnit.

Běžné ochrany odmítají vše mimo Safe_ports a odmítají CONNECT mimo SSL_ports. Tato jména jsou ACL definované ve vaší vlastní konfiguraci, takže jejich obsah patří vám, ne protokolu. Distribuce může povolit široký rozsah portů jako Safe_ports a přitom omezovat CONNECT zvlášť. Přečtěte si živé hodnoty, než budete předpokládat, že port je zablokovaný záměrně.

Ověřte, že požadavek odmítá právě proxy. 403 vygenerovaný Squidem nevypadá vůbec jako upozornění TLS z VPN serveru a sloučení obou do jednoho problému stojí první hodinu. Zkontrolujte řádek přístupového logu pro daný požadavek, protože zaznamenává jak akci, tak pravidlo, které ji vyvolalo.

Postavte jedno kombinované porovnání místo tří volných ACL

Výjimku postavte ze tří faktů: schváleného rozsahu zdroje, jedné schválené adresy cíle a jediného portu, na kterém koncový bod naslouchá. Dvě volné ACL a jedno kombinované porovnání vytvářejí velmi odlišnou politiku, protože se vyhodnocuje právě kombinace. Kombinovanou ACL pojmenujte podle toho, co povoluje, ne podle metody, kterou nese.

Níže uvedený tvar používá dokumentační rozsahy, které je nutné nahradit prověřenými hodnotami. Squid si žádné z těchto jmen nevyhrazuje, takže je vybíráte vy a vy je také udržujete konzistentní. Tento recept je omezen na Squid 6 a 7, jejichž dokumentovaná konfigurace podporuje skupinu all-of. Současná referenční příručka označuje tyto direktivy jako nedostupné v Squid 8, takže to berte jako recept vázaný na verzi, nikoli jako cestu migrace, a před použitím direktivu ověřte v referenční příručce své vlastní verze.

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 odpovídá jen tehdy, když odpovídá každý člen, což znamená, že zdroj, cíl a port se kontrolují na jednom řádku. Skupina sama o sobě nic neuděluje a požadavek odpovídající jen dvěma ze tří faktů ji nemůže splnit. Tato vlastnost udržuje výjimku úzkou, když někdo později přidá druhou bránu. Buď se nový cíl přidá záměrně, nebo se požadavek vrátí k původním ochranám.

Ohněte ochrany portů, aniž byste je odstranili

Na svých stávajících pozicích vypadají dva běžné ochranné řádky takto. Obvykle stojí po autentizaci a před řádky politiky, které povolují cokoli.

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

Přidejte negované kombinované porovnání ke každému z nich, aby odpovídající výjimka přežila ochranu, která by ji jinak odmítla. Mění se pouze ochranné řádky, a to jen o jeden další člen u každého.

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

Členy na jednom přístupovém řádku se kombinují, takže řádek nyní odmítá jen požadavky, které selžou jak v původní kontrole, tak ve výjimce. Požadavek na schválený koncový bod projde a každý další požadavek si zachová staré chování portu. To je užší než přidání portu do globálního seznamu SSL_ports, což by ten port povolilo každému cíli. Pokud port v tomto seznamu už je, tato ACL nic nezužuje a starší, širší povolení platí i pro jiné cíle, takže si přečtěte živý seznam, než budete tvrdit, že výjimka port otevřela. Je také vratné, protože dva řádky se vracejí do dřívější podoby. Referenční příručka řízení přístupu dokumentuje pořadí a běžné ochrany, na nichž tato změna závisí.

Kam se výjimka nesmí umístit

Pokušením je dát povolení nad ochrany a skončit. Takové umístění také přeskakuje ochrany autentizace a lokálního cíle, které obvykle stojí blízko vrcholu funkční konfigurace. Výsledkem není úzká výjimka, ale díra s komentářem nad sebou. Jakékoli nové povolení držte ve stejné prověřené fázi jako zbytek politiky klientů.

Zkontrolujte, co požadavek po ochranách portů ještě potřebuje. Autentizovaný účet, povolená adresa klienta i politika cíle stále platí a výjimka nemění nic z toho. Pokud váš proxy už schválenému účtu dovoluje dosáhnout libovolných cílů, ochrana portu nikdy nebyla skutečnou kontrolou.

Zvažte, zda je koncový bod vůbec TCP. Výjimka CONNECT přenáší TCP toky a profil OpenVPN, který používá UDP, se přes ni nedostane. Změňte profil na TCP jen tehdy, pokud server takto naslouchá a operátor přijímá rozdíl v chování.

Ověřte hranici parserem a skutečným požadavkem

Před načtením konfiguraci naparsujte a během toho mějte otevřenou druhou relaci. Syntaktická chyba při načítání může nechat proxy na staré konfiguraci nebo novou úplně odmítnout. Parser nahlásí odmítnutý řádek, což je víc, než vám řekne chyba klienta.

Potom znovu načtěte a pošlete jeden skutečný CONNECT přes proxy ze schváleného zdroje. Spuštění parseru přichází první, protože načtení s překlepem vás o politice nic 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 tři případy: schválený zdroj a účet, neschválený zdroj a jiný cíl na stejném portu. Třetí případ dokazuje, že výjimka je úzká, protože procvičuje port bez shody cíle. Čtěte přístupový log u všech tří, místo abyste věřili zprávě klienta. Úspěšný CONNECT vytvoří TCP tok a nic víc, takže handshake VPN zůstává samostatným testem.