Një pikë fundore VPN përmes Squid: një përjashtim i ngushtë CONNECT
Lejoni një burim të miratuar të arrijë një portë VPN në portën 1194 përmes Squid, mbani rojet globale të portave dhe provoni se asgjë tjetër nuk u hap.
Squid i përgjigjet një kërkese CONNECT me rreshtin e parë http_access që përputhet, dhe ai rresht mund të jetë një refuzim. Ky fakt i vetëm shpjegon pse një përjashtim për një pikë fundore VPN dështon zakonisht në përpjekjen e parë, sepse kërkesa nuk arrin kurrë te leja që dikush shtoi në fund. Një korrigjim i ngushtë mban rojet ekzistuese të portave dhe u mëson atyre një burim, një destinacion dhe një portë të rishikuar. Gjithçka tjetër në proxy sillet saktësisht si më parë.
Si vendos Squid për një kërkesë CONNECT
Një kërkesë CONNECT emërton një host dhe një portë, dhe Squid kalon nëpër rreshtat http_access me radhë derisa njëri prej tyre përputhet. Një refuzim përputhës e përfundon menjëherë vlerësimin dhe klienti merr 403 nga proxy. Prandaj pozicioni i një rregulli ka më shumë rëndësi se formulimi i tij. Zhvendosja e të njëjtit rresht një shkallë më lart mund ta ndryshojë rezultatin plotësisht.
Rojet konvencionale refuzojnë gjithçka jashtë Safe_ports dhe refuzojnë CONNECT jashtë SSL_ports. Këta emra janë ACL të përcaktuara në konfigurimin tuaj, kështu që përmbajtja e tyre është e juaja dhe jo e protokollit. Një distribucion mund të lejojë një gamë të gjerë portash si Safe_ports duke kufizuar CONNECT veçmas. Lexoni vlerat e gjalla përpara se të supozoni se një portë është bllokuar sipas dizajnit.
Konfirmoni se proxy është komponenti që e refuzon kërkesën. Një 403 i gjeneruar nga Squid nuk i ngjan aspak një alarmi TLS nga serveri VPN, dhe bashkimi i të dyjave në një problem të vetëm kushton orën e parë. Kontrolloni rreshtin e regjistrit të aksesit për kërkesën, sepse regjistron si veprimin ashtu edhe rregullin që e prodhoi.
Ndërtoni një përputhje të kombinuar në vend të tre ACL-ve të lira
Ndërtoni përjashtimin nga tre fakte: një interval burimi i miratuar, një adresë destinacioni e miratuar dhe e vetmja portë ku dëgjon pika fundore. Dy ACL të lira dhe një përputhje e kombinuar prodhojnë një politikë shumë të ndryshme, sepse ajo që vlerësohet është kombinimi. Emërtoni ACL-në e kombinuar sipas asaj që lejon, jo sipas metodës që mbart.
Forma më poshtë përdor intervale dokumentacioni që duhet të zëvendësohen me vlera të rishikuara. Squid nuk rezervon asnjë nga këta emra për vete, kështu që ata janë tuajt për t'i zgjedhur dhe tuajt për t'i mbajtur konsistentë. Ky recetë është i kufizuar në Squid 6 dhe 7, konfigurimi i dokumentuar i të cilëve mbështet grupin all-of. Referenca aktuale i shënon ato direktiva si të padisponueshme në Squid 8, prandaj trajtojeni këtë si një recetë të lidhur me versionin dhe jo si një rrugë migrimi, dhe kontrolloni direktivën në referencën e versionit tuaj përpara se ta zbatoni.
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_srcGrupi all-of përputhet vetëm kur përputhet çdo anëtar, që do të thotë se burimi, destinacioni dhe porta kontrollohen në një rresht të vetëm. Grupi nuk jep asgjë më vete, dhe një kërkesë që përputhet vetëm me dy nga tre faktet nuk mund ta plotësojë atë. Kjo veti e mban përjashtimin të ngushtë kur dikush shton më vonë një portë të dytë. Ose destinacioni i ri shtohet me qëllim, ose kërkesa kthehet te rojet origjinale.
Përkulni rojet e portave pa i hequr ato
Në pozicionet e tyre aktuale, dy rreshtat konvencionalë të rojeve duken kështu. Zakonisht qëndrojnë pas vërtetimit dhe përpara rreshtave të politikës që lejojnë gjithçka.
http_access deny !Safe_ports
http_access deny CONNECT !SSL_portsShtoni përputhjen e kombinuar të mohuar në secilin, në mënyrë që një përjashtim përputhës t'i mbijetojë një roje që përndryshe do ta refuzonte. Ndryshojnë vetëm rreshtat e rojeve, dhe secili vetëm me një term shtesë.
http_access deny CONNECT !SSL_ports !pvpn_ok
http_access deny !Safe_ports !pvpn_okTermat në një rresht aksesi kombinohen, kështu që rreshti tani refuzon vetëm kërkesat që dështojnë si në kontrollin origjinal ashtu edhe në përjashtim. Kërkesa për pikën fundore të miratuar kalon, dhe çdo kërkesë tjetër mban sjelljen e vjetër të portës. Kjo është më e ngushtë sesa shtimi i portës në një listë globale SSL_ports, që do ta lejonte atë portë për çdo destinacion. Nëse porta është tashmë në atë listë, kjo ACL nuk ngushton asgjë dhe leja më e vjetër dhe më e gjerë vazhdon të zbatohet për destinacione të tjera, prandaj lexoni listën e gjallë përpara se të pohonisni se përjashtimi e hapi portën. Është gjithashtu e kthyeshme, sepse dy rreshta kthehen në formën e tyre të mëparshme. Referenca e kontrollit të aksesit dokumenton rendin dhe rojet konvencionale nga të cilat varet ky ndryshim.
Ku përjashtimi nuk duhet të vendoset
Tundimi është të vendosni një leje mbi rojet dhe të mbaroni. Ai vendosje anashkalon gjithashtu mbrojtjet e vërtetimit dhe të destinacionit lokal që zakonisht qëndrojnë pranë majës së një konfigurimi që funksionon. Rezultati nuk është një përjashtim i ngushtë, është një vrimë me një koment sipër. Mbani çdo leje të re në të njëjtën fazë të rishikuar si pjesa tjetër e politikës së klientëve.
Kontrolloni çfarë i nevojitet ende kërkesës pas rojeve të portave. Një llogari e vërtetuar, një adresë klienti e lejuar dhe një politikë destinacioni vazhdojnë të zbatohen, dhe përjashtimi nuk ndryshon asnjërën prej tyre. Nëse proxy juaj tashmë lejon llogarinë e miratuar të arrijë destinacione arbitrare, roja e portës nuk ishte kurrë kontrolli i vërtetë.
Mendoni nëse pika fundore është fare TCP. Një përjashtim CONNECT mbart rrjedha TCP, dhe një profil OpenVPN që përdor UDP nuk do të bëhet i arritshëm përmes tij. Ndryshoni profilin në TCP vetëm nëse serveri dëgjon kështu dhe operatori e pranon ndryshimin e sjelljes.
Kontrolloni kufirin me analizuesin dhe një kërkesë të vërtetë
Analizoni konfigurimin përpara ringarkimit dhe mbani një sesion të dytë të hapur ndërsa e bëni këtë. Një gabim sintakse gjatë ringarkimit mund ta lërë proxy në konfigurimin e vjetër ose ta refuzojë plotësisht të riun. Analizuesi raporton rreshtin e refuzuar, që është më shumë sesa do t'ju thotë gabimi i klientit.
Më pas ringarkoni dhe dërgoni një CONNECT të vërtetë përmes proxy nga një burim i miratuar. Ekzekutimi i analizuesit vjen i pari, sepse një ringarkim me gabim shtypi nuk ju mëson asgjë për politikën.
squid -k parse
squid -k reconfigure
curl -v -p -x http://proxy.lab.internal:3128 https://vpn.lab.internal:1194/ --max-time 5Provoni tre raste: një burim dhe llogari të miratuar, një burim të pamiratuar dhe një destinacion të ndryshëm në të njëjtën portë. Rasti i tretë është ai që provon se përjashtimi është i ngushtë, sepse ushtron portën pa përputhjen e destinacionit. Lexoni regjistrin e aksesit për të tre, në vend që t'i besoni mesazhit të klientit. Një CONNECT i suksesshëm vendos një rrjedhë TCP dhe asgjë më shumë, prandaj shtrëngimi i duarve i VPN mbetet një test i veçantë.