Isang VPN endpoint sa pamamagitan ng Squid: makitid na pagbubukod sa CONNECT

Sinasagot ng Squid ang isang kahilingang CONNECT gamit ang unang linyang http_access na tumutugma, at ang linyang iyon ay maaaring isang pagtanggi. Ang nag-iisang katotohanang ito ang nagpapaliwanag kung bakit karaniwang nabibigo sa unang pagtatangka ang pagbubukod para sa isang VPN endpoint, dahil hindi kailanman naaabot ng kahilingan ang pahintulot na idinagdag ng isang tao sa dulo. Ang makitid na pagwawasto ay nagpapanatili ng umiiral na mga guwardiya ng port at nagtuturo sa kanila ng isang masusing pinagmulang, destinasyon at port. Ang lahat ng iba pa sa proxy ay kumikilos nang eksakto tulad ng dati.

Paano nagpapasya ang Squid sa isang kahilingang CONNECT

Ang isang kahilingang CONNECT ay nagpangalan ng host at port, at tinatahak ng Squid ang mga linyang http_access ayon sa pagkakasunod hanggang may isang tumugma. Ang tumutugmang pagtanggi ay agad na nagwawakas sa pagsusuri at tumatanggap ng 403 ang kliyente mula sa proxy. Kaya mas mahalaga ang posisyon ng isang tuntunin kaysa sa pananalita nito. Ang paglipat ng parehong linya nang isang hakbang pataas ay maaaring tuluyang magbago ng resulta.

Tinitanggihan ng mga karaniwang guwardiya ang lahat ng nasa labas ng Safe_ports at tinatanggihan ang CONNECT sa labas ng SSL_ports. Ang mga pangalang iyon ay ACL na tinukoy sa sarili mong konfigurasyon, kaya sa iyo ang nilalaman nito at hindi sa protokol. Maaaring payagan ng isang distribusyon ang malawak na hanay ng port bilang Safe_ports habang hiwalay na nililimitahan ang CONNECT. Basahin ang mga buhay na halaga bago ipagpalagay na ang isang port ay hinarangan ayon sa disenyo.

Tiyakin na ang proxy ang bahaging tumatanggi sa kahilingan. Ang 403 na nilikha ng Squid ay hindi talaga kamukha ng babala ng TLS mula sa server ng VPN, at ang pagsasanib ng dalawa sa isang problema ay kumakain ng unang oras. Suriin ang linya ng log ng pag-access para sa kahilingan, dahil itinatala nito ang aksyon at ang tuntuning lumikha nito.

Bumuo ng isang pinagsamang tugma sa halip na tatlong hiwalay na ACL

Buuin ang pagbubukod mula sa tatlong katotohanan: isang aprubadong saklaw ng pinagmulan, isang aprubadong address ng destinasyon at ang nag-iisang port na pinakikinggan ng endpoint. Ang dalawang hiwalay na ACL at isang pinagsamang tugma ay gumagawa ng lubos na naiibang patakaran, dahil ang pinagsama ang sinusuri. Pangalanan ang pinagsamang ACL ayon sa pinapayagan nito, hindi ayon sa paraang dala nito.

Gumagamit ang porma sa ibaba ng mga saklaw ng dokumentasyon na dapat palitan ng masusing halaga. Hindi inilalaan ng Squid ang alinman sa mga pangalang ito para sa sarili nito, kaya ikaw ang pumipili at ikaw ang nagpapanatili ng pagkakapare-pareho. Ang resipi ito ay limitado sa Squid 6 at 7, na ang dokumentadong konfigurasyon ay sumusuporta sa grupong all-of. Minarkahan ng kasalukuyang sanggunian ang mga direktibang iyon bilang hindi available sa Squid 8, kaya ituring ito bilang resiping nakatali sa bersyon at hindi landas ng paglipat, at suriin ang direktiba sa sanggunian ng sarili mong release bago ito ilapat.

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

Tumutugma lamang ang grupong all-of kapag tumugma ang bawat miyembro, ibig sabihin sinusuri sa isang linya ang pinagmulan, destinasyon at port. Wala itong ibinibigay sa sarili nito, at ang kahilingang tumutugma lamang sa dalawa sa tatlong katotohanan ay hindi ito masisiyahan. Ang katangiang iyon ay nagpapanatili ng makitid na pagbubukod kapag may nagdagdag ng pangalawang gateway sa kalaunan. Alinman sa sadyang idinagdag ang bagong destinasyon, o bumabalik ang kahilingan sa orihinal na mga guwardiya.

Ibaluktot ang mga guwardiya ng port nang hindi inaalis

Sa kanilang kasalukuyang mga posisyon, ganito ang hitsura ng dalawang karaniwang linyang guwardiya. Karaniwang nasa likod sila ng pagpapatotoo at sa harap ng mga linyang patakaran na nagpapahintulot sa lahat.

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

Idagdag sa bawat isa ang pinagsamang tugmang pinabulaanan, upang ang tumutugmang pagbubukod ay makalampas sa guwardiyang tatanggi sana rito. Ang mga linyang guwardiya lamang ang nagbabago, at isa lamang karagdagang termino bawat isa.

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

Pinagsasama ang mga termino sa isang linyang pag-access, kaya tinatanggihan na ngayon ng linya ang mga kahilingang nabibigo sa orihinal na pagsusuri at sa pagbubukod. Dumadaan ang kahilingan para sa aprubadong endpoint, at pinapanatili ng iba pang kahilingan ang lumang pag-uugali ng port. Ito ay mas makitid kaysa sa pagdaragdag ng port sa pandaigdigang listahan ng SSL_ports, na magpapahintulot sa port na iyon sa bawat destinasyon. Kung ang port ay nasa listahang iyon na, wala itong pinapakitid na anuman at ang mas lumang, mas malawak na pahintulot ay umiiral pa rin sa ibang destinasyon, kaya basahin ang buhay na listahan bago igiit na binuksan ng pagbubukod ang port. Nababalik din ito, dahil bumabalik ang dalawang linya sa dating porma. Ang sanggunian ng pagkontrol sa pag-access ay nagdodokumento ng pagkakasunod at ng mga karaniwang guwardiyang pinagbabatayan ng pagbabagong ito.

Saan hindi dapat ilagay ang pagbubukod

Ang tukso ay ilagay ang pahintulot sa ibabaw ng mga guwardiya at tapusin. Nilalaktawan din ng paglalagay na iyon ang mga proteksyon sa pagpapatotoo at lokal na destinasyon na karaniwang malapit sa tuktok ng gumaganang konfigurasyon. Hindi makitid na pagbubukod ang resulta, butas ito na may komento sa itaas. Panatilihin ang anumang bagong pahintulot sa parehong masusing yugto tulad ng iba pang patakaran ng kliyente.

Suriin kung ano pa ang kailangan ng kahilingan pagkatapos ng mga guwardiya ng port. Ang naauthentikang account, pinahintulutang address ng kliyente at patakaran ng destinasyon ay umiiral pa rin, at wala sa mga iyon ang binabago ng pagbubukod. Kung pinapayagan na ng iyong proxy ang aprubadong account na maabot ang anumang destinasyon, hindi kailanman naging tunay na kontrol ang guwardiya ng port.

Isaalang-alang kung TCP ba talaga ang endpoint. Ang pagbubukod sa CONNECT ay nagdadala ng mga daloy ng TCP, at ang profile ng OpenVPN na gumagamit ng UDP ay hindi magiging maabot sa pamamagitan nito. Palitan lamang ang profile sa TCP kung ganoon ang pinakikinggan ng server at tinatanggap ng tagapagpatakbo ang pagkakaiba sa pag-uugali.

Suriin ang hangganan gamit ang parser at isang tunay na kahilingan

I-parse ang konfigurasyon bago mag-reload, at panatilihing bukas ang pangalawang sesyon habang ginagawa iyon. Ang error sa sintaks sa oras ng pag-reload ay maaaring mag-iwan ng proxy sa lumang konfigurasyon o tuluyang tanggihan ang bago. Iniulat ng parser ang tinanggihang linya, na higit pa sa sasabihin ng error ng kliyente.

Pagkatapos ay mag-reload at magpadala ng isang tunay na CONNECT sa pamamagitan ng proxy mula sa aprubadong pinagmulan. Mauna ang pagpapatakbo ng parser, dahil ang pag-reload na may typo ay walang itinuturo tungkol sa patakaran.

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

Subukan ang tatlong kaso: aprubadong pinagmulan at account, hindi aprubadong pinagmulan, at ibang destinasyon sa parehong port. Ang ikatlong kaso ang nagpapatunay na makitid ang pagbubukod, dahil ginagamit nito ang port nang walang tugma ng destinasyon. Basahin ang log ng pag-access para sa tatlo sa halip na magtiwala sa mensahe ng kliyente. Ang matagumpay na CONNECT ay nagtatatag ng daloy ng TCP at wala nang iba pa, kaya nananatiling hiwalay na pagsubok ang pagkamay ng kamay ng VPN.