Ét VPN-endepunkt gennem Squid: en snæver CONNECT-undtagelse

Squid besvarer en CONNECT-anmodning med den første http_access-linje, der matcher, og den linje kan være en afvisning. Denne ene kendsgerning forklarer, hvorfor en undtagelse for et VPN-endepunkt normalt fejler i første forsøg, fordi anmodningen aldrig når den tilladelse, som nogen tilføjede nederst. En snæver rettelse beholder de eksisterende portvagter og lærer dem om én gennemgået kilde, destination og port. Alt andet på proxien opfører sig præcis som før.

Sådan afgør Squid en CONNECT-anmodning

En CONNECT-anmodning angiver et værtsnavn og en port, og Squid gennemgår http_access-linjerne i rækkefølge, indtil en af dem matcher. En matchende afvisning afslutter evalueringen med det samme, og klienten får en 403 fra proxien. Derfor betyder en regels placering mere end dens formulering. At flytte samme linje et trin op kan ændre resultatet fuldstændigt.

De sædvanlige vagter afviser alt uden for Safe_ports og afviser CONNECT uden for SSL_ports. Disse navne er ACL'er, der er defineret i din egen konfiguration, så deres indhold tilhører dig og ikke protokollen. En distribution kan tillade en bred vifte af porte som Safe_ports og samtidig begrænse CONNECT særskilt. Læs de levende værdier, før du antager, at en port er blokeret efter design.

Bekræft, at det er proxien, der afviser anmodningen. En 403 fra Squid ligner slet ikke en TLS-advarsel fra VPN-serveren, og at slå de to sammen til ét problem koster den første time. Kontroller accesslog-linjen for anmodningen, fordi den registrerer både handlingen og den regel, der frembragte den.

Byg ét kombineret match i stedet for tre løse ACL'er

Byg undtagelsen ud fra tre fakta: et godkendt kildeområde, én godkendt destinationsadresse og den eneste port, endepunktet lytter på. To løse ACL'er og ét kombineret match giver en helt anden politik, fordi det er kombinationen, der evalueres. Navngiv den kombinerede ACL efter hvad den tillader, ikke efter den metode, den bærer.

Formen nedenfor bruger dokumentationsområder, som skal erstattes med gennemgåede værdier. Squid reserverer ingen af disse navne, så de er dine at vælge og dine at holde konsistente. Denne opskrift er afgrænset til Squid 6 og 7, hvis dokumenterede konfiguration understøtter all-of-gruppen. Den aktuelle reference markerer disse direktiver som utilgængelige i Squid 8, så betragt dette som en versionsafgrænset opskrift frem for en migreringsvej, og kontroller direktivet mod din egen udgivelses reference, før du anvender 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 matcher kun, når hvert medlem matcher, hvilket betyder, at kilde, destination og port kontrolleres på én linje. Gruppen giver intet i sig selv, og en anmodning, der kun matcher to af de tre fakta, kan ikke opfylde den. Den egenskab holder undtagelsen snæver, når nogen senere tilføjer en anden gateway. Enten tilføjes den nye destination bevidst, eller også falder anmodningen tilbage til de oprindelige vagter.

Bøj portvagterne uden at fjerne dem

På deres nuværende placeringer ser de to sædvanlige vagtlinjer sådan ud. De står normalt efter godkendelse og før de politiske linjer, der tillader alt.

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

Tilføj det negerede kombinerede match til hver af dem, så en matchende undtagelse overlever en vagt, der ellers ville afvise den. Kun vagtlinjerne ændres, og kun med ét ekstra led hver.

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

Led på én adgangslinje kombineres, så linjen afviser nu kun anmodninger, der fejler både den oprindelige kontrol og undtagelsen. En anmodning til det godkendte endepunkt går igennem, og enhver anden anmodning beholder den gamle portadfærd. Dette er snævrere end at tilføje porten til en global SSL_ports-liste, hvilket ville tillade den port til enhver destination. Hvis porten allerede findes på den liste, indsnævrer denne ACL intet, og den ældre, bredere tilladelse gælder stadig for andre destinationer, så læs den levende liste, før du hævder, at undtagelsen åbnede porten. Den er også reversibel, fordi to linjer går tilbage til deres tidligere form. Referencen for adgangskontrol dokumenterer den rækkefølge og de sædvanlige vagter, som denne ændring afhænger af.

Hvor undtagelsen ikke må placeres

Fristelsen er at sætte en tilladelse over vagterne og være færdig. Den placering springer også de godkendelses- og lokaldestinationsbeskyttelser over, som normalt står nær toppen af en fungerende konfiguration. Resultatet er ikke en snæver undtagelse, det er et hul med en kommentar over sig. Hold enhver ny tilladelse på samme gennemgåede trin som resten af klientpolitikken.

Kontroller, hvad anmodningen stadig har brug for efter portvagterne. En godkendt konto, en tilladt klientadresse og en destinationspolitik gælder stadig, og undtagelsen ændrer ingen af dem. Hvis din proxy allerede lader den godkendte konto nå vilkårlige destinationer, var portvagten aldrig den egentlige kontrol.

Overvej, om endepunktet overhovedet er TCP. En CONNECT-undtagelse bærer TCP-strømme, og en OpenVPN-profil, der bruger UDP, bliver ikke tilgængelig gennem den. Skift kun profilen til TCP, hvis serveren lytter sådan, og operatøren accepterer forskellen i adfærd.

Kontroller grænsen med parseren og en rigtig anmodning

Pars konfigurationen, før du genindlæser, og hold en ekstra session åben, mens du gør det. En syntaksfejl ved genindlæsning kan efterlade proxien på den gamle konfiguration eller afvise den nye helt. Parseren rapporterer den afviste linje, hvilket er mere, end klientfejlen fortæller dig.

Genindlæs derefter, og send én rigtig CONNECT gennem proxien fra en godkendt kilde. Parserkørslen kommer først, fordi en genindlæsning med en slåfejl ikke lærer dig noget 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 tilfælde: en godkendt kilde og konto, en ikke-godkendt kilde og en anden destination på samme port. Det tredje tilfælde er det, der beviser, at undtagelsen er snæver, fordi det udøver porten uden destinationsmatchet. Læs accessloggen for alle tre i stedet for at stole på klientmeddelelsen. En vellykket CONNECT etablerer en TCP-strøm og intet mere, så VPN-håndtrykket forbliver en separat test.