Een VPN-eindpunt deur Squid: 'n nou CONNECT-uitsondering

Squid beantwoord 'n CONNECT-versoek met die eerste http_access-reël wat pas, en daardie reël kan 'n weiering wees. Hierdie enkele feit verduidelik waarom 'n uitsondering vir 'n VPN-eindpunt gewoonlik met die eerste poging misluk, want die versoek bereik nooit die toelating wat iemand onderaan bygevoeg het nie. 'n Nou regstelling behou die bestaande poortwagte en leer hulle van een nagegane bron, bestemming en poort. Alles anders op die proxy gedra hom presies soos voorheen.

Hoe Squid oor 'n CONNECT-versoek besluit

’n CONNECT-versoek noem ’n gasheer en ’n poort, en Squid loop die http_access-reëls in volgorde deur totdat een daarvan pas. ’n Passende weiering beëindig die evaluering onmiddellik en die kliënt ontvang ’n 403 van die proxy. Daarom maak die posisie van ’n reël meer saak as die bewoording daarvan. Om dieselfde reël een stap op te skuif kan die uitkoms heeltemal verander.

Die konvensionele wagte weier alles buite Safe_ports en weier CONNECT buite SSL_ports. Daardie name is ACL's wat in jou eie konfigurasie gedefinieer word, so die inhoud daarvan behoort aan jou en nie aan die protokol nie. ’n Distribusie kan ’n wye reeks poorte as Safe_ports toelaat terwyl CONNECT afsonderlik beperk word. Lees die lewendige waardes voordat jy aanneem dat ’n poort per ontwerp geblokkeer is.

Bevestig dat die proxy die komponent is wat die versoek weier. ’n 403 wat deur Squid gegenereer word, lyk niks soos ’n TLS-waarskuwing van die VPN-bediener nie, en om die twee in een probleem saam te voeg kos die eerste uur. Kyk na die toegangslogreël vir die versoek, want dit teken beide die aksie en die reël wat dit veroorsaak het aan.

Bou een gekombineerde passing in plaas van drie los ACL's

Bou die uitsondering uit drie feite: ’n goedgekeurde bronreeks, een goedgekeurde bestemmingsadres en die enkele poort waarop die eindpunt luister. Twee los ACL's en een gekombineerde passing lewer baie verskillende beleid, want dit is die kombinasie wat geëvalueer word. Noem die gekombineerde ACL volgens wat dit toelaat, nie volgens die metode wat dit dra nie.

Die vorm hieronder gebruik dokumentasiereekse wat met nagegane waardes vervang moet word. Squid reserveer nie een van hierdie name nie, so dit is joune om te kies en joune om konsekwent te hou. Hierdie resep is beperk tot Squid 6 en 7, wie se gedokumenteerde konfigurasie die all-of-groep ondersteun. Die huidige verwysing merk daardie direktiewe as onbeskikbaar in Squid 8, so behandel dit as ’n weergawegebonde resep eerder as ’n migrasiepad, en kontroleer die direktief teen jou eie weergawe se verwysing voordat jy dit toepas.

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

Die all-of-groep pas net wanneer elke lid pas, wat beteken dat bron, bestemming en poort op een reël nagegaan word. Die groep verleen op sigself niks, en ’n versoek wat net twee van die drie feite pas, kan dit nie bevredig nie. Daardie eienskap hou die uitsondering nou wanneer iemand later ’n tweede gateway byvoeg. Óf die nuwe bestemming word doelbewus bygevoeg, óf die versoek val terug op die oorspronklike wagte.

Buig die poortwagte sonder om hulle te verwyder

Op hul bestaande posisies lyk die twee konvensionele waglyne so. Hulle sit gewoonlik ná verifikasie en voor die beleidslyne wat enigiets toelaat.

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

Voeg die ontkende gekombineerde passing by elkeen, sodat ’n passende uitsondering ’n wag oorleef wat dit andersins sou weier. Net die waglyne verander, en net met een ekstra term elk.

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

Terme op een toegangsreël word gekombineer, so die reël weier nou net versoeke wat beide die oorspronklike kontrole en die uitsondering faal. ’n Versoek vir die goedgekeurde eindpunt gaan deur, en elke ander versoek behou die ou poortgedrag. Dit is nouer as om die poort by ’n globale SSL_ports-lys te voeg, wat daardie poort na elke bestemming sou toelaat. As die poort reeds in daardie lys voorkom, vernou hierdie ACL niks en geld die ouer, wyer toestemming steeds vir ander bestemmings, so lees die lewendige lys voordat jy beweer die uitsondering het die poort oopgemaak. Dit is ook keerbaar, want twee lyne gaan terug na hul vorige vorm. Die toegangsbeheerverwysing dokumenteer die ordening en die konvensionele wagte waarvan hierdie verandering afhang.

Waar die uitsondering nie geplaas mag word nie

Die versoeking is om ’n toelating bo die wagte te plaas en klaar te wees. Daardie plasing slaan ook die verifikasie- en plaaslike-bestemmingsbeskermings oor wat gewoonlik naby die bokant van ’n werkende konfigurasie sit. Die resultaat is nie ’n nou uitsondering nie, dit is ’n gat met ’n opmerking daarbo. Hou enige nuwe toelating op dieselfde nagegane stadium as die res van die kliëntbeleid.

Kontroleer wat die versoek nog ná die poortwagte nodig het. ’n Geverifieerde rekening, ’n toegelate kliëntadres en ’n bestemmingsbeleid geld steeds, en die uitsondering verander nie een daarvan nie. As jou proxy die goedgekeurde rekening reeds na willekeurige bestemmings laat gaan, was die poortwag nooit die regte beheer nie.

Oorweeg of die eindpunt hoegenaamd TCP is. ’n CONNECT-uitsondering dra TCP-strome, en ’n OpenVPN-profiel wat UDP gebruik, sal nie daardeur bereikbaar word nie. Verander die profiel net na TCP as die bediener so luister en die operateur die verskil in gedrag aanvaar.

Kontroleer die grens met die ontleder en ’n werklike versoek

Ontleed die konfigurasie voordat jy herlaai, en hou ’n tweede sessie oop terwyl jy dit doen. ’n Sintaksfout tydens herlaai kan die proxy op die ou konfigurasie laat of die nuwe een heeltemal weier. Die ontleder rapporteer die verworpe reël, wat meer is as wat die kliëntfout jou sal vertel.

Herlaai dan en stuur een werklike CONNECT deur die proxy vanaf ’n goedgekeurde bron. Die ontlederloop kom eerste, want ’n herlaai met ’n tikfout leer jou niks oor die beleid nie.

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

Toets drie gevalle: ’n goedgekeurde bron en rekening, ’n nie-goedgekeurde bron, en ’n ander bestemming op dieselfde poort. Die derde geval is die een wat bewys die uitsondering is nou, want dit oefen die poort sonder die bestemmingspassing. Lees die toegangslog vir al drie eerder as om die kliëntboodskap te vertrou. ’n Suksesvolle CONNECT vestig ’n TCP-stroom en niks meer nie, so die VPN-handdruk bly ’n aparte toets.