Ett VPN-endepunkt gjennom Squid: et smalt CONNECT-unntak

Squid svarer på en CONNECT-forespørsel med den første http_access-linjen som passer, og den linjen kan være en avvisning. Denne ene kjensgjerningen forklarer hvorfor et unntak for et VPN-endepunkt vanligvis feiler på første forsøk, fordi forespørselen aldri når tillatelsen noen la til nederst. En smal rettelse beholder de eksisterende portvaktene og lærer dem om én gjennomgått kilde, destinasjon og port. Alt annet på proxyen oppfører seg nøyaktig som før.

Hvordan Squid avgjør en CONNECT-forespørsel

En CONNECT-forespørsel navngir en vert og en port, og Squid går gjennom http_access-linjene i rekkefølge til en av dem passer. En passende avvisning avslutter vurderingen umiddelbart, og klienten får 403 fra proxyen. Derfor betyr plasseringen av en regel mer enn formuleringen. Å flytte samme linje ett hakk opp kan endre resultatet fullstendig.

De vanlige vaktene avviser alt utenfor Safe_ports og avviser CONNECT utenfor SSL_ports. Disse navnene er ACL-er som er definert i din egen konfigurasjon, så innholdet tilhører deg og ikke protokollen. En distribusjon kan tillate et bredt spekter av porter som Safe_ports og samtidig begrense CONNECT separat. Les de levende verdiene før du antar at en port er blokkert av design.

Bekreft at det er proxyen som avviser forespørselen. En 403 fra Squid ligner ikke i det hele tatt på en TLS-advarsel fra VPN-serveren, og å slå de to sammen til ett problem koster den første timen. Sjekk tilgangslogglinjen for forespørselen, fordi den registrerer både handlingen og regelen som skapte den.

Bygg én kombinert treff i stedet for tre løse ACL-er

Bygg unntaket fra tre fakta: et godkjent kildeområde, én godkjent destinasjonsadresse og den eneste porten endepunktet lytter på. To løse ACL-er og én kombinert treff gir en helt annen policy, fordi det er kombinasjonen som vurderes. Gi den kombinerte ACL-en navn etter hva den tillater, ikke etter metoden den bærer.

Formen nedenfor bruker dokumentasjonsområder som må erstattes med gjennomgåtte verdier. Squid reserverer ingen av disse navnene, så de er dine å velge og dine å holde konsistente. Denne oppskriften er avgrenset til Squid 6 og 7, hvis dokumenterte konfigurasjon støtter all-of-gruppen. Den gjeldende referansen markerer disse direktivene som utilgjengelige i Squid 8, så behandl dette som en versjonsbundet oppskrift og ikke en migreringsvei, og kontroller direktivet mot referansen for din egen utgivelse før du bruker 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-gruppen passer bare når hvert medlem passer, noe som betyr at kilde, destinasjon og port kontrolleres på én linje. Gruppen gir ingenting i seg selv, og en forespørsel som bare passer med to av de tre fakta kan ikke oppfylle den. Den egenskapen holder unntaket smalt når noen senere legger til en annen gateway. Enten legges den nye destinasjonen til med vilje, eller så faller forespørselen tilbake til de opprinnelige vaktene.

Bøy portvaktene uten å fjerne dem

På sine nåværende plasseringer ser de to vanlige vaktlinjene slik ut. De står vanligvis etter autentisering og før policylinjene som tillater alt.

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

Legg det negerte kombinerte treffet til i hver av dem, slik at et passende unntak overlever en vakt som ellers ville avvist det. Bare vaktlinjene endres, og bare med ett ekstra ledd hver.

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

Ledd på én tilgangslinje kombineres, så linjen avviser nå bare forespørsler som feiler både den opprinnelige kontrollen og unntaket. En forespørsel til det godkjente endepunktet går gjennom, og alle andre forespørsler beholder den gamle portoppførselen. Dette er smalere enn å legge porten til en global SSL_ports-liste, som ville tillatt den porten til enhver destinasjon. Hvis porten allerede står på den listen, innsnevrer denne ACL-en ingenting, og den eldre, bredere tillatelsen gjelder fortsatt for andre destinasjoner, så les den levende listen før du hevder at unntaket åpnet porten. Den er også reversibel, fordi to linjer går tilbake til sin tidligere form. Referansen for tilgangskontroll dokumenterer rekkefølgen og de vanlige vaktene som denne endringen er avhengig av.

Hvor unntaket ikke må plasseres

Fristelsen er å sette en tillatelse over vaktene og være ferdig. Den plasseringen hopper også over autentiserings- og lokaldestinasjonsvernet som vanligvis står nær toppen av en fungerende konfigurasjon. Resultatet er ikke et smalt unntak, det er et hull med en kommentar over. Hold enhver ny tillatelse på samme gjennomgåtte trinn som resten av klientpolicyen.

Sjekk hva forespørselen fortsatt trenger etter portvaktene. En autentisert konto, en tillatt klientadresse og en destinasjonspolicy gjelder fortsatt, og unntaket endrer ingen av dem. Hvis proxyen din allerede lar den godkjente kontoen nå vilkårlige destinasjoner, var portvakten aldri den egentlige kontrollen.

Vurder om endepunktet i det hele tatt er TCP. Et CONNECT-unntak bærer TCP-strømmer, og en OpenVPN-profil som bruker UDP blir ikke tilgjengelig gjennom den. Endre profilen til TCP bare hvis serveren lytter slik og operatøren godtar forskjellen i oppførsel.

Sjekk grensen med parseren og en ekte forespørsel

Parse konfigurasjonen før du laster inn på nytt, og hold en ekstra økt åpen mens du gjør det. En syntaksfeil ved innlasting kan la proxyen stå på den gamle konfigurasjonen eller avvise den nye helt. Parseren rapporterer den avviste linjen, som er mer enn klientfeilen forteller deg.

Last deretter inn på nytt og send én ekte CONNECT gjennom proxyen fra en godkjent kilde. Parserens kjøring kommer først, fordi en innlasting med skrivefeil ikke lærer deg noe om policyen.

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 tilfeller: en godkjent kilde og konto, en ikke-godkjent kilde, og en annen destinasjon på samme port. Det tredje tilfellet er det som beviser at unntaket er smalt, fordi det utøver porten uten destinasjonstreffet. Les tilgangsloggen for alle tre i stedet for å stole på klientmeldingen. En vellykket CONNECT etablerer en TCP-strøm og ikke noe mer, så VPN-håndtrykket forblir en separat test.