En enda VPN-slutpunkt genom Squid: ett smalt CONNECT-undantag

Squid svarar på en CONNECT-begäran med den första http_access-rad som matchar, och den raden kan vara en avvisning. Detta enda faktum förklarar varför ett undantag för en VPN-slutpunkt oftast misslyckas vid första försöket, eftersom begäran aldrig når det tillstånd som någon lade till längst ner. En smal rättelse behåller de befintliga portvakterna och lär dem en granskad källa, destination och port. Allt annat på proxyn beter sig precis som tidigare.

Hur Squid avgör en CONNECT-begäran

En CONNECT-begäran namnger en värd och en port, och Squid går igenom http_access-raderna i ordning tills en av dem matchar. En matchande avvisning avslutar utvärderingen omedelbart och klienten får 403 från proxyn. Därför spelar en regels placering större roll än dess formulering. Att flytta samma rad ett steg upp kan ändra resultatet helt.

De vanliga vakterna avvisar allt utanför Safe_ports och avvisar CONNECT utanför SSL_ports. Dessa namn är ACL:er som definieras i din egen konfiguration, så innehållet tillhör dig och inte protokollet. En distribution kan tillåta ett brett portintervall som Safe_ports och samtidigt begränsa CONNECT separat. Läs de levande värdena innan du antar att en port är blockerad av design.

Bekräfta att det är proxyn som avvisar begäran. En 403 från Squid liknar inte alls en TLS-varning från VPN-servern, och att slå ihop de två till ett problem kostar den första timmen. Kontrollera åtkomstloggens rad för begäran, eftersom den registrerar både åtgärden och regeln som skapade den.

Bygg en kombinerad träff i stället för tre lösa ACL:er

Bygg undantaget av tre fakta: ett godkänt källområde, en godkänd destinationsadress och den enda port som slutpunkten lyssnar på. Två lösa ACL:er och en kombinerad träff ger en helt annan policy, eftersom det är kombinationen som utvärderas. Namnge den kombinerade ACL:n efter vad den tillåter, inte efter metoden den bär.

Formen nedan använder dokumentationsintervall som måste ersättas med granskade värden. Squid reserverar inget av dessa namn, så det är ditt att välja dem och ditt att hålla dem konsekventa. Detta recept är begränsat till Squid 6 och 7, vars dokumenterade konfiguration stöder all-of-gruppen. Nuvarande referens markerar dessa direktiv som otillgängliga i Squid 8, så behandla detta som ett versionsbundet recept och inte som en migreringsväg, och kontrollera direktivet mot referensen för din egen utgåva innan du använder 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 matchar bara när varje medlem matchar, vilket betyder att källa, destination och port kontrolleras på en enda rad. Gruppen ger ingenting i sig själv, och en begäran som bara matchar två av de tre fakta kan inte uppfylla den. Den egenskapen håller undantaget smalt när någon senare lägger till en andra gateway. Antingen läggs den nya destinationen till medvetet, eller så faller begäran tillbaka på de ursprungliga vakterna.

Böj portvakterna utan att ta bort dem

På sina nuvarande platser ser de två vanliga vaktraderna ut så här. De står vanligtvis efter autentisering och före de policyrader som tillåter allt.

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

Lägg till den negerade kombinerade träffen i var och en, så att ett matchande undantag överlever en vakt som annars skulle avvisa det. Bara vaktraderna ändras, och bara med ett extra led var.

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

Led på en åtkomstrad kombineras, så raden avvisar nu bara begäranden som misslyckas både den ursprungliga kontrollen och undantaget. En begäran till den godkända slutpunkten går igenom, och alla andra begäranden behåller det gamla portbeteendet. Detta är smalare än att lägga porten till en global SSL_ports-lista, vilket skulle tillåta den porten för varje destination. Om porten redan finns på den listan minskar denna ACL ingenting och det äldre, bredare tillståndet gäller fortfarande för andra destinationer, så läs den levande listan innan du hävdar att undantaget öppnade porten. Det är också reversibelt, eftersom två rader går tillbaka till sin tidigare form. Referensen för åtkomstkontroll dokumenterar den ordning och de vanliga vakter som denna ändring bygger på.

Var undantaget inte får placeras

Frestelsen är att sätta ett tillstånd ovanför vakterna och vara klar. Den placeringen hoppar också över autentiserings- och lokaldestinationsskydden som vanligtvis står nära toppen av en fungerande konfiguration. Resultatet är inte ett smalt undantag, det är ett hål med en kommentar ovanför. Håll varje nytt tillstånd i samma granskade steg som resten av klientpolicyn.

Kontrollera vad begäran fortfarande behöver efter portvakterna. Ett autentiserat konto, en tillåten klientadress och en destinationspolicy gäller fortfarande, och undantaget ändrar inget av dem. Om din proxy redan låter det godkända kontot nå godtyckliga destinationer var portvakten aldrig den egentliga kontrollen.

Överväg om slutpunkten ens är TCP. Ett CONNECT-undantag bär TCP-strömmar, och en OpenVPN-profil som använder UDP blir inte nåbar genom det. Ändra profilen till TCP bara om servern lyssnar så och operatören accepterar skillnaden i beteende.

Kontrollera gränsen med parsern och en riktig begäran

Parsa konfigurationen innan du laddar om, och håll en extra session öppen medan du gör det. Ett syntaxfel vid omladdningen kan lämna proxyn på den gamla konfigurationen eller avvisa den nya helt. Parsern rapporterar den avvisade raden, vilket är mer än klientfelet berättar.

Ladda sedan om och skicka en riktig CONNECT genom proxyn från en godkänd källa. Parser körs först, eftersom en omladdning med ett skrivfel inte lär dig något om policyn.

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

Testa tre fall: en godkänd källa och ett konto, en icke godkänd källa och en annan destination på samma port. Det tredje fallet är det som bevisar att undantaget är smalt, eftersom det utövar porten utan destinationsmatchningen. Läs åtkomstloggen för alla tre i stället för att lita på klientmeddelandet. En lyckad CONNECT upprättar en TCP-ström och inget mer, så VPN-handskakningen förblir ett separat test.