Egyetlen VPN-végpont a Squiden át: szűk CONNECT-kivétel

A Squid egy CONNECT-kérést az első egyező http_access-sorral válaszol meg, és ez a sor lehet elutasítás. Ez az egyetlen tény magyarázza, miért szokott egy VPN-végpont kivétele első próbára megbukni, mert a kérés soha nem ér el az alul valaki által hozzáadott engedélyig. Egy szűk javítás megtartja a meglévő portőröket, és megtanítja nekik egyetlen átvizsgált forrást, célt és portot. A proxy minden más viselkedése pontosan olyan marad, mint korábban.

Hogyan dönt a Squid egy CONNECT-kérésről

Egy CONNECT-kérés egy hosztot és egy portot nevez meg, a Squid pedig sorban halad a http_access-sorokon, amíg valamelyik egyezik. Az egyező elutasítás azonnal lezárja az értékelést, és a kliens 403-at kap a proxytól. Ezért egy szabály helye többet számít, mint a megfogalmazása. Ugyanazon sor egy lépéssel feljebb mozgatása teljesen megváltoztathatja az eredményt.

A hagyományos őrök elutasítanak mindent a Safe_ports-on kívül, és elutasítják a CONNECT-et az SSL_ports-on kívül. Ezek a nevek a saját konfigurációjában definiált ACL-ek, tehát a tartalmuk Önhöz tartozik, nem a protokollhoz. Egy disztribúció széles porttartományt engedélyezhet Safe_ports-ként, miközben a CONNECT-et külön korlátozza. Olvassa el az élő értékeket, mielőtt feltételezi, hogy egy port tervezés szerint blokkolt.

Erősítse meg, hogy a proxy az az összetevő, amely elutasítja a kérést. A Squid által előállított 403 semmiben sem hasonlít a VPN-kiszolgáló TLS-figyelmeztetésére, és a kettő egyetlen problémába olvasztása az első órát viszi el. Ellenőrizze a kérés hozzáférési naplósorát, mert az rögzíti a műveletet és az azt előállító szabályt is.

Egyetlen kombinált egyezést építsen három laza ACL helyett

A kivételt három tényből építse fel: egy jóváhagyott forrástartományból, egy jóváhagyott célcímből és abból az egyetlen portból, amelyen a végpont figyel. Két laza ACL és egy kombinált egyezés nagyon eltérő szabályzatot ad, mert a kombinációt értékeli a rendszer. A kombinált ACL-t arról nevezze el, amit engedélyez, nem arról a metódusról, amelyet hordoz.

Az alábbi forma dokumentációs tartományokat használ, amelyeket átvizsgált értékekkel kell helyettesíteni. A Squid egyiket sem tartja fenn a maga számára, tehát Ön választja ki és Ön tartja őket következetesen. Ez a recept a Squid 6-ra és 7-re korlátozódik, amelyek dokumentált konfigurációja támogatja az all-of csoportot. A jelenlegi referencia ezeket az utasításokat a Squid 8-ban elérhetetlennek jelöli, ezért kezelje ezt verzióhoz kötött receptként, nem áttelepítési útvonalként, és az alkalmazás előtt ellenőrizze az utasítást a saját kiadása referenciájában.

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

Az all-of csoport csak akkor egyezik, ha minden tag egyezik, ami azt jelenti, hogy a forrást, a célt és a portot egyetlen sorban ellenőrzi. A csoport önmagában semmit nem ad, és egy kérés, amely a három tény közül csak kettővel egyezik, nem tudja kielégíteni. Ez a tulajdonság tartja szűken a kivételt, amikor valaki később második átjárót ad hozzá. Vagy szándékosan kerül be az új cél, vagy a kérés visszaesik az eredeti őrökre.

Hajlítsa meg a portőröket anélkül, hogy eltávolítaná őket

Jelenlegi helyükön a két hagyományos őrsor így néz ki. Általában a hitelesítés után és az mindent engedélyező szabályzatsorok előtt állnak.

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

Adja hozzá mindegyikhez a tagadott kombinált egyezést, hogy az egyező kivétel túléljen egy őrt, amely egyébként elutasítaná. Csak az őrsorok változnak, és mindegyik csak egyetlen további taggal.

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

Egy hozzáférési sor tagjai összeadódnak, ezért a sor most csak azokat a kéréseket utasítja el, amelyek az eredeti ellenőrzésen és a kivételen is elbuknak. A jóváhagyott végpontra irányuló kérés átmegy, minden más kérés pedig megtartja a régi portviselkedést. Ez szűkebb annál, mintha a portot egy globális SSL_ports listához adná, ami minden cél számára engedélyezné azt a portot. Ha a port már szerepel azon a listán, ez az ACL semmit nem szűkít, és a régebbi, szélesebb engedély továbbra is érvényes más célokra, ezért olvassa el az élő listát, mielőtt azt állítaná, hogy a kivétel megnyitotta a portot. Visszafordítható is, mert két sor visszatér korábbi formájába. A hozzáférés-vezérlési referencia dokumentálja azt a sorrendet és azokat a hagyományos őröket, amelyektől ez a változtatás függ.

Ahová a kivételt nem szabad tenni

A kísértés az, hogy az őrök fölé tegyen egy engedélyt, és kész. Ez az elhelyezés kihagyja a hitelesítési és helyi célvédelmi intézkedéseket is, amelyek általában egy működő konfiguráció teteje közelében vannak. Az eredmény nem szűk kivétel, hanem egy lyuk felette kommenttel. Minden új engedélyt ugyanabban az átvizsgált szakaszban tartson, mint a kliensszabályzat többi részét.

Ellenőrizze, mire van még szüksége a kérésnek a portőrök után. Egy hitelesített fiók, egy engedélyezett klienscím és egy cél-szabályzat továbbra is érvényes, és a kivétel egyiken sem változtat. Ha a proxyja már engedi a jóváhagyott fióknak, hogy tetszőleges célokat érjen el, a portőr soha nem volt az igazi ellenőrzés.

Gondolja át, hogy a végpont egyáltalán TCP-e. A CONNECT-kivétel TCP-folyamokat szállít, és egy UDP-t használó OpenVPN-profil nem válik elérhetővé rajta keresztül. Csak akkor állítsa a profilt TCP-re, ha a kiszolgáló így figyel, és az üzemeltető elfogadja a viselkedésbeli különbséget.

Ellenőrizze a határt az elemzővel és egy valódi kéréssel

Az újratöltés előtt elemezze a konfigurációt, és közben tartson nyitva egy második munkamenetet. Az újratöltéskor fellépő szintaktikai hiba a proxyot a régi konfiguráción hagyhatja, vagy az újat teljesen elutasíthatja. Az elemző jelenti az elutasított sort, ami több annál, amit a klienshiba mondani fog.

Ezután töltse újra, és küldjön egy valódi CONNECT-et a proxyn keresztül egy jóváhagyott forrásból. Az elemző futtatása jön először, mert az elgépeléssel végzett újratöltés semmit nem tanít a szabályzatról.

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

Három esetet teszteljen: jóváhagyott forrás és fiók, nem jóváhagyott forrás, és egy másik cél ugyanazon a porton. A harmadik eset bizonyítja, hogy a kivétel szűk, mert a portot a célegyezés nélkül gyakorolja. Mindháromhoz olvassa el a hozzáférési naplót, ahelyett hogy a kliens üzenetében bízna. Egy sikeres CONNECT TCP-folyamot hoz létre és semmi többet, így a VPN-kézfogás továbbra is külön teszt.