Ena končna točka VPN skozi Squid: ozka izjema CONNECT

Squid na zahtevo CONNECT odgovori s prvo vrstico http_access, ki se ujema, in ta vrstica je lahko zavrnitev. To eno dejstvo pojasnjuje, zakaj izjema za končno točko VPN običajno spodleti že v prvem poskusu, ker zahteva nikoli ne doseže dovoljenja, ki ga je nekdo dodal na koncu. Ozka poprava ohrani obstoječe stražarje vrat in jih nauči enega pregledanega vira, cilja in vrat. Vse drugo na posredniku se obnaša natanko kot prej.

Kako Squid odloči o zahtevi CONNECT

Zahteva CONNECT navede gostitelja in vrata, Squid pa po vrsti prehaja vrstice http_access, dokler se ena od njih ne ujame. Ujemajoča zavrnitev takoj konča ocenjevanje in odjemalec prejme 403 od posrednika. Zato je položaj pravila pomembnejši od njegovega besedila. Premik iste vrstice za eno stopnjo višje lahko rezultat povsem spremeni.

Običajni stražarji zavrnejo vse izven Safe_ports in zavrnejo CONNECT izven SSL_ports. Ta imena so ACL, definirane v vaši lastni konfiguraciji, zato njihova vsebina pripada vam in ne protokolu. Distribucija lahko dovoli širok razpon vrat kot Safe_ports, medtem ko CONNECT omejuje ločeno. Preberite žive vrednosti, preden domnevate, da so vrata blokirana po zasnovi.

Potrdite, da zahtevo zavrača prav posrednik. 403, ki ga ustvari Squid, nič ne spominja na opozorilo TLS s strežnika VPN, in združitev obeh v eno težavo stane prvo uro. Preverite vrstico dnevnika dostopa za zahtevo, ker beleži tako dejanje kot pravilo, ki ga je povzročilo.

Zgradite eno sestavljeno ujemanje namesto treh ohlapnih ACL

Izjemo zgradite iz treh dejstev: odobrenega razpona vira, enega odobrenega naslova cilja in edinih vrat, na katerih posluša končna točka. Dve ohlapni ACL in eno sestavljeno ujemanje dajo zelo drugačno politiko, ker se ocenjuje prav kombinacija. Sestavljeno ACL poimenujte po tem, kar dovoljuje, ne po metodi, ki jo nosi.

Spodnja oblika uporablja dokumentacijske razpone, ki jih je treba nadomestiti s pregledanimi vrednostmi. Squid si nobenega od teh imen ne pridrži, zato jih izberete vi in jih vi ohranjate dosledne. Ta recept je omejen na Squid 6 in 7, katerih dokumentirana konfiguracija podpira skupino all-of. Trenutni priročnik te direktive označuje kot nedosegljive v Squidu 8, zato to obravnavajte kot recept, vezan na različico, in ne kot pot migracije, ter direktivo pred uporabo preverite v priročniku svoje različice.

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 se ujema le, ko se ujema vsak član, kar pomeni, da se vir, cilj in vrata preverjajo v eni vrstici. Skupina sama po sebi ničesar ne podeli, zahteva, ki se ujema le z dvema od treh dejstev, pa je ne more zadovoljiti. Ta lastnost ohranja izjemo ozko, ko nekdo pozneje doda druga vrata. Ali se novi cilj doda namerno, ali pa se zahteva vrne k prvotnim stražarjem.

Upognite stražarje vrat, ne da bi jih odstranili

Na svojih sedanji položajih sta obe običajni stražarski vrstici videti takole. Ponavadi stojita po overjanju in pred vrsticami politike, ki dovolijo vse.

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

Vsaki dodajte zanikano sestavljeno ujemanje, da ujemajoča izjema preživi stražarja, ki bi jo sicer zavrnil. Spremenita se le stražarski vrstici, in to le za po en dodatni člen vsaka.

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

Členi v eni dostopni vrstici se združijo, zato vrstica zdaj zavrne le zahteve, ki spodletijo tako pri prvotnem preverjanju kot pri izjemi. Zahteva do odobrene končne točke gre skozi, vsaka druga zahteva pa ohrani staro vedenje vrat. To je ožje od dodajanja vrat na globalni seznam SSL_ports, kar bi ta vrata dovolilo vsakemu cilju. Če so vrata že na tem seznamu, ta ACL ničesar ne zoži in starejše, širše dovoljenje še vedno velja za druge cilje, zato preberite živi seznam, preden trdite, da je izjema odprla vrata. Prav tako je povratno, ker se dve vrstici vrneta v prejšnjo obliko. Priročnik za nadzor dostopa dokumentira vrstni red in običajne stražarje, od katerih je ta sprememba odvisna.

Kjer izjeme ne smete postaviti

Skušnjava je, da bi dovoljenje postavili nad stražarje in končali. Taka postavitev preskoči tudi zaščiti overjanja in lokalnega cilja, ki običajno stojita blizu vrha delujoče konfiguracije. Rezultat ni ozka izjema, ampak luknja s komentarjem nad seboj. Vsako novo dovoljenje držite na isti pregledani stopnji kot preostanek politike odjemalcev.

Preverite, kaj zahteva po stražarjih vrat še potrebuje. Overjen račun, dovoljen naslov odjemalca in politika cilja še vedno veljajo, izjema pa ne spremeni nobenega od njih. Če vaš posrednik že dovoli odobrenemu računu doseči poljubne cilje, stražar vrat nikoli ni bil prava kontrola.

Premislite, ali je končna točka sploh TCP. Izjema CONNECT prenaša tokove TCP, profil OpenVPN, ki uporablja UDP, pa skoznjo ne bo dosegljiv. Profil spremenite v TCP le, če strežnik tako posluša in operater sprejme razliko v vedenju.

Preverite mejo z razčlenjevalnikom in resnično zahtevo

Konfiguracijo razčlenite pred ponovnim nalaganjem in medtem imejte odprto drugo sejo. Skladenjska napaka pri nalaganju lahko posrednik pusti na stari konfiguraciji ali novo povsem zavrne. Razčlenjevalnik sporoči zavrnjeno vrstico, kar je več, kot vam bo povedala napaka odjemalca.

Nato znova naložite in pošljite eno resnično zahtevo CONNECT skozi posrednik iz odobrenega vira. Zagon razčlenjevalnika pride prvi, ker vas ponovno nalaganje s tipkarsko napako o politiki nič ne nauči.

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

Preizkusite tri primere: odobren vir in račun, neodobren vir in drug cilj na istih vratih. Tretji primer dokazuje, da je izjema ozka, ker preizkuša vrata brez ujemanja cilja. Dnevnik dostopa preberite za vse tri, namesto da bi zaupali sporočilu odjemalca. Uspešen CONNECT vzpostavi tok TCP in nič več, zato rokovanje VPN ostaja ločen preizkus.