Eitt VPN-endepunkt gjennom Squid: eit smalt CONNECT-unntak

Squid svarar på ein CONNECT-førespurnad med den første http_access-linja som passar, og den linja kan vere ei avvising. Denne einskilde kjensgjerninga forklarer kvifor eit unntak for eit VPN-endepunkt vanlegvis feilar på første forsøk, fordi førespurnaden aldri når løyvet nokon la til nedst. Ei smal retting held på dei eksisterande portvaktane og lærer dei om éin gjennomgått kjelde, destinasjon og port. Alt anna på proxyen oppfører seg nøyaktig som før.

Korleis Squid avgjer ein CONNECT-førespurnad

Ein CONNECT-førespurnad namngir ein vert og ein port, og Squid går gjennom http_access-linjene i rekkjefølgje til ei av dei passar. Ei passande avvising avsluttar vurderinga med ein gong, og klienten får 403 frå proxyen. Difor tyder plasseringa av ei regel meir enn formuleringa. Å flytte same linje eitt hakk opp kan endre resultatet fullstendig.

Dei vanlege vaktane avviser alt utanfor Safe_ports og avviser CONNECT utanfor SSL_ports. Desse namna er ACL-ar som er definerte i din eigen konfigurasjon, så innhaldet høyrer til deg og ikkje protokollen. Ein distribusjon kan tillate eit breitt spekter av portar som Safe_ports og samstundes avgrense CONNECT separat. Les dei levande verdiane før du går ut frå at ein port er blokkert av design.

Stadfest at det er proxyen som avviser førespurnaden. Ein 403 frå Squid liknar slett ikkje på ei TLS-åtvaring frå VPN-tenaren, og å slå dei to saman til eitt problem kostar den første timen. Sjekk tilgangslogglinja for førespurnaden, fordi ho registrerer både handlinga og regelen som skapte ho.

Bygg eitt kombinert treff i staden for tre lause ACL-ar

Bygg unntaket frå tre fakta: eit godkjent kjeldeområde, éi godkjend destinasjonsadresse og den einaste porten endepunktet lyttar på. To lause ACL-ar og eitt kombinert treff gjev ein heilt annan politikk, fordi det er kombinasjonen som vert vurdert. Gi den kombinerte ACL-en namn etter kva han tillét, ikkje etter metoden han ber.

Forma nedanfor nyttar dokumentasjonsområde som må erstattast med gjennomgåtte verdiar. Squid reserverer ingen av desse namna, så dei er dine å velje og dine å halde konsistente. Denne oppskrifta er avgrensa til Squid 6 og 7, der den dokumenterte konfigurasjonen støttar all-of-gruppa. Den gjeldande referansen merkjer desse direktiva som utilgjengelege i Squid 8, så handsam dette som ei versjonsbunden oppskrift og ikkje ein migrasjonsveg, og kontroller direktivet mot referansen for din eigen utgiving før du brukar det.

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

All-of-gruppa passar berre når kvart medlem passar, noko som tyder at kjelde, destinasjon og port vert kontrollerte på éi linje. Gruppa gjev ingenting i seg sjølv, og ein førespurnad som berre passar med to av dei tre fakta kan ikkje oppfylle ho. Den eigenskapen held unntaket smalt når nokon seinare legg til ein annan gateway. Anten vert den nye destinasjonen lagd til med vilje, eller så fell førespurnaden tilbake til dei opphavlege vaktane.

Bøy portvaktane utan å fjerne dei

På sine noverande plasseringar ser dei to vanlege vaktlinjene slik ut. Dei står vanlegvis etter autentisering og før politikklinjene som tillét alt.

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

Legg det fornekta kombinerte treffet til i kvar av dei, slik at eit passande unntak overlever ei vakt som elles ville avvist det. Berre vaktlinjene vert endra, og berre med eitt ekstra ledd kvar.

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

Ledd på éi tilgangslinje vert kombinerte, så linja avviser no berre førespurnader som feilar både den opphavlege kontrollen og unntaket. Ein førespurnad til det godkjende endepunktet går gjennom, og alle andre førespurnader held på den gamle portåtferda. Dette er smalare enn å leggje porten til ei global SSL_ports-liste, som ville tillate den porten til kvar destinasjon. Står porten allereie på den lista, innsnevrar denne ACL-en ingenting, og den eldre, breiare løyvinga gjeld framleis for andre destinasjonar, så les den levande lista før du hevdar at unntaket opna porten. Ho er òg reversibel, fordi to linjer går tilbake til si tidlegare form. Referansen for tilgangskontroll dokumenterer rekkjefølgja og dei vanlege vaktane som denne endringa er avhengig av.

Kvar unntaket ikkje må plasserast

Freistinga er å setje eit løyve over vaktane og vere ferdig. Den plasseringa hoppar òg over autentiserings- og lokaldestinasjonsvernet som vanlegvis står nær toppen av ein fungerande konfigurasjon. Resultatet er ikkje eit smalt unntak, det er eit hol med ein kommentar over. Hald eitkvart nytt løyve på same gjennomgåtte trinn som resten av klientpolitikken.

Sjekk kva førespurnaden framleis treng etter portvaktane. Ein autentisert konto, ei tillaten klientadresse og ein destinasjonspolitikk gjeld framleis, og unntaket endrar ingen av dei. Viss proxyen din allereie lèt den godkjende kontoen nå vilkårlege destinasjonar, var portvakta aldri den eigentlege kontrollen.

Vurder om endepunktet i det heile er TCP. Eit CONNECT-unntak ber TCP-straumar, og ein OpenVPN-profil som nyttar UDP vert ikkje tilgjengeleg gjennom det. Endre profilen til TCP berre viss tenaren lyttar slik og operatøren godtek skilnaden i åtferd.

Sjekk grensa med parsaren og ein ekte førespurnad

Pars konfigurasjonen før du lastar inn på nytt, og hald ei ekstra økt open medan du gjer det. Ein syntaksfeil ved innlasting kan la proxyen stå på den gamle konfigurasjonen eller avvise den nye heilt. Parsaren rapporterer den avviste linja, som er meir enn klientfeilen fortel deg.

Last deretter inn på nytt og send éin ekte CONNECT gjennom proxyen frå ei godkjend kjelde. Parserens køyring kjem først, fordi ei innlasting med skrivefeil lærer deg ingenting om politikken.

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

Test tre tilfelle: ei godkjend kjelde og konto, ei ikkje-godkjend kjelde, og ein annan destinasjon på same port. Det tredje tilfellet er det som provar at unntaket er smalt, fordi det utøver porten utan destinasjonstreffet. Les tilgangsloggen for alle tre i staden for å stole på klientmeldinga. Ein vellukka CONNECT etablerer ein TCP-straum og ikkje noko meir, så VPN-handtrykket blir verande ein separat test.