Eén VPN-eindpunt via Squid: een smalle CONNECT-uitzondering

Squid beantwoordt een CONNECT-verzoek met de eerste http_access-regel die overeenkomt, en die regel kan een weigering zijn. Dit enkele feit verklaart waarom een uitzondering voor een VPN-eindpunt meestal bij de eerste poging mislukt, omdat het verzoek nooit de toestemming bereikt die iemand onderaan heeft toegevoegd. Een smalle correctie behoudt de bestaande poortwachters en leert ze één beoordeelde bron, bestemming en poort. Al het andere op de proxy gedraagt zich precies zoals voorheen.

Hoe Squid een CONNECT-verzoek beslist

Een CONNECT-verzoek noemt een host en een poort, en Squid loopt de http_access-regels in volgorde langs tot een ervan overeenkomt. Een passende weigering beëindigt de evaluatie onmiddellijk en de client ontvangt een 403 van de proxy. Daarom is de positie van een regel belangrijker dan de formulering. Dezelfde regel één stap omhoog verplaatsen kan het resultaat volledig veranderen.

De conventionele wachters weigeren alles buiten Safe_ports en weigeren CONNECT buiten SSL_ports. Die namen zijn ACL's die in je eigen configuratie zijn gedefinieerd, dus de inhoud is van jou en niet van het protocol. Een distributie kan een breed poortbereik als Safe_ports toestaan en CONNECT apart beperken. Lees de live waarden voordat je aanneemt dat een poort ontworpen is om geblokkeerd te zijn.

Bevestig dat de proxy het onderdeel is dat het verzoek weigert. Een 403 van Squid lijkt totaal niet op een TLS-waarschuwing van de VPN-server, en beide tot één probleem samensmelten kost het eerste uur. Controleer de accesslogregel van het verzoek, want die legt zowel de actie als de regel vast die hem veroorzaakte.

Bouw één gecombineerde overeenkomst in plaats van drie losse ACL's

Bouw de uitzondering uit drie feiten: een goedgekeurd bronbereik, één goedgekeurd bestemmingsadres en de enige poort waarop het eindpunt luistert. Twee losse ACL's en één gecombineerde overeenkomst leveren een heel ander beleid op, omdat de combinatie wordt geëvalueerd. Noem de gecombineerde ACL naar wat hij toestaat, niet naar de methode die hij draagt.

De vorm hieronder gebruikt documentatiebereiken die door beoordeelde waarden moeten worden vervangen. Squid reserveert geen van deze namen, dus ze zijn van jou om te kiezen en van jou om consistent te houden. Dit recept is beperkt tot Squid 6 en 7, waarvan de gedocumenteerde configuratie de all-of-groep ondersteunt. De huidige referentie markeert die richtlijnen als niet beschikbaar in Squid 8, dus behandel dit als een versiegebonden recept en niet als een migratiepad, en controleer de richtlijn in de referentie van je eigen release voordat je hem toepast.

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

De all-of-groep komt alleen overeen wanneer elk lid overeenkomt, wat betekent dat bron, bestemming en poort op één regel worden gecontroleerd. De groep geeft zelf niets en een verzoek dat slechts met twee van de drie feiten overeenkomt, kan hem niet vervullen. Die eigenschap houdt de uitzondering smal wanneer iemand later een tweede gateway toevoegt. Ofwel de nieuwe bestemming wordt bewust toegevoegd, ofwel het verzoek valt terug op de oorspronkelijke wachters.

Buig de poortwachters zonder ze te verwijderen

Op hun huidige posities zien de twee conventionele wachtregels er zo uit. Ze staan meestal na de authenticatie en vóór de beleidsregels die alles toestaan.

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

Voeg aan elk de ontkende gecombineerde overeenkomst toe, zodat een passende uitzondering een wachter overleeft die hem anders zou weigeren. Alleen de wachtregels veranderen, en elk met slechts één extra term.

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

Termen op één accessregel worden gecombineerd, dus de regel weigert nu alleen verzoeken die zowel de oorspronkelijke controle als de uitzondering falen. Een verzoek voor het goedgekeurde eindpunt komt door, en elk ander verzoek behoudt het oude poortgedrag. Dit is smaller dan de poort aan een globale SSL_ports-lijst toevoegen, wat die poort voor elke bestemming zou toestaan. Staat de poort al op die lijst, dan vernauwt deze ACL niets en blijft de oudere, bredere toestemming gelden voor andere bestemmingen, dus lees de live lijst voordat je beweert dat de uitzondering de poort heeft geopend. Het is ook omkeerbaar, omdat twee regels teruggaan naar hun vorige vorm. De referentie voor toegangscontrole documenteert de volgorde en de conventionele wachters waarvan deze wijziging afhangt.

Waar de uitzondering niet mag staan

De verleiding is een toestemming boven de wachters te zetten en klaar te zijn. Die plaatsing slaat ook de authenticatie- en lokaalbestemmingsbescherming over die meestal boven aan een werkende configuratie staan. Het resultaat is geen smalle uitzondering, het is een gat met een opmerking erboven. Houd elke nieuwe toestemming in dezelfde beoordeelde fase als de rest van het clientbeleid.

Controleer wat het verzoek na de poortwachters nog nodig heeft. Een geauthenticeerd account, een toegestaan clientadres en een bestemmingsbeleid gelden nog steeds, en de uitzondering verandert geen daarvan. Als je proxy het goedgekeurde account al willekeurige bestemmingen laat bereiken, was de poortwachter nooit de echte controle.

Overweeg of het eindpunt überhaupt TCP is. Een CONNECT-uitzondering draagt TCP-stromen, en een OpenVPN-profiel dat UDP gebruikt, wordt er niet bereikbaar door. Wijzig het profiel alleen naar TCP als de server zo luistert en de beheerder het verschil in gedrag accepteert.

Controleer de grens met de parser en een echt verzoek

Parseer de configuratie voordat je herlaadt, en houd een tweede sessie open terwijl je dat doet. Een syntaxisfout bij het herladen kan de proxy op de oude configuratie laten of de nieuwe botweg weigeren. De parser meldt de geweigerde regel, wat meer is dan de clientfout je vertelt.

Herlaad daarna en stuur één echt CONNECT-verzoek via de proxy vanaf een goedgekeurde bron. De parserrun komt eerst, want een herlaad met een typefout leert je niets over het beleid.

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

Test drie gevallen: een goedgekeurde bron en account, een niet-goedgekeurde bron, en een andere bestemming op dezelfde poort. Het derde geval bewijst dat de uitzondering smal is, omdat het de poort zonder de bestemmingsovereenkomst uitoefent. Lees de accesslog voor alle drie in plaats van het clientbericht te vertrouwen. Een geslaagde CONNECT brengt een TCP-stroom tot stand en niets meer, dus de VPN-handshake blijft een aparte test.