Ein VPN-Endpunkt durch Squid: eine enge CONNECT-Ausnahme

Squid beantwortet eine CONNECT-Anfrage mit der ersten passenden http_access-Zeile, und diese Zeile kann eine Ablehnung sein. Diese eine Tatsache erklärt, warum eine Ausnahme für einen VPN-Endpunkt beim ersten Versuch meist scheitert, weil die Anfrage nie die Erlaubnis erreicht, die jemand unten hinzugefügt hat. Eine enge Korrektur behält die bestehenden Port-Wächter bei und lehrt sie eine geprüfte Quelle, ein Ziel und einen Port. Alles andere auf dem Proxy verhält sich genau wie zuvor.

Wie Squid eine CONNECT-Anfrage entscheidet

Eine CONNECT-Anfrage nennt einen Host und einen Port, und Squid geht die http_access-Zeilen der Reihe nach durch, bis eine davon passt. Eine passende Ablehnung beendet die Auswertung sofort, und der Client erhält vom Proxy eine 403. Deshalb zählt die Position einer Regel mehr als ihr Wortlaut. Dieselbe Zeile eine Stufe nach oben zu verschieben kann das Ergebnis völlig verändern.

Die üblichen Wächter lehnen alles außerhalb von Safe_ports ab und lehnen CONNECT außerhalb von SSL_ports ab. Diese Namen sind ACLs aus Ihrer eigenen Konfiguration, ihr Inhalt gehört also Ihnen und nicht dem Protokoll. Eine Distribution kann einen weiten Portbereich als Safe_ports erlauben und CONNECT trotzdem separat einschränken. Lesen Sie die aktuellen Werte, bevor Sie annehmen, ein Port sei konstruktionsbedingt gesperrt.

Bestätigen Sie, dass der Proxy die Komponente ist, die die Anfrage ablehnt. Eine von Squid erzeugte 403 sieht ganz anders aus als eine TLS-Warnung des VPN-Servers, und beide zu einem Problem zu verschmelzen kostet die erste Stunde. Prüfen Sie die Access-Log-Zeile der Anfrage, denn sie hält sowohl die Aktion als auch die Regel fest, die sie erzeugt hat.

Bauen Sie einen kombinierten Treffer statt drei loser ACLs

Bauen Sie die Ausnahme aus drei Tatsachen: einem freigegebenen Quellbereich, einer freigegebenen Zieladresse und dem einzigen Port, auf dem der Endpunkt lauscht. Zwei lose ACLs und ein kombinierter Treffer ergeben eine ganz andere Richtlinie, denn ausgewertet wird die Kombination. Benennen Sie die kombinierte ACL nach dem, was sie erlaubt, und nicht nach der Methode, die sie trägt.

Die Form unten verwendet Dokumentationsbereiche, die durch geprüfte Werte ersetzt werden müssen. Squid reserviert keinen dieser Namen, sie sind also Ihre Wahl und Ihre Aufgabe, sie konsistent zu halten. Dieses Rezept ist auf Squid 6 und 7 begrenzt, deren dokumentierte Konfiguration die all-of-Gruppe unterstützt. Die aktuelle Referenz kennzeichnet diese Direktiven in Squid 8 als nicht verfügbar, behandeln Sie dies also als versionsgebundenes Rezept und nicht als Migrationspfad, und prüfen Sie die Direktive vor der Anwendung in der Referenz Ihrer eigenen Version.

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-Gruppe passt nur, wenn jedes Mitglied passt, das heißt Quelle, Ziel und Port werden in einer Zeile geprüft. Die Gruppe gewährt für sich genommen nichts, und eine Anfrage, die nur zwei der drei Tatsachen erfüllt, kann sie nicht erfüllen. Diese Eigenschaft hält die Ausnahme eng, wenn jemand später ein zweites Gateway hinzufügt. Entweder wird das neue Ziel bewusst ergänzt, oder die Anfrage fällt auf die ursprünglichen Wächter zurück.

Biegen Sie die Port-Wächter, ohne sie zu entfernen

An ihren bestehenden Positionen sehen die beiden üblichen Wächterzeilen so aus. Sie stehen meist nach der Authentifizierung und vor den Richtlinienzeilen, die alles erlauben.

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

Fügen Sie jeder von ihnen den negierten kombinierten Treffer hinzu, damit eine passende Ausnahme einen Wächter übersteht, der sie sonst ablehnen würde. Geändert werden nur die Wächterzeilen, und zwar jeweils um genau einen zusätzlichen Term.

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

Terme auf einer Zugriffszeile werden kombiniert, die Zeile lehnt jetzt also nur Anfragen ab, die sowohl die ursprüngliche Prüfung als auch die Ausnahme verfehlen. Eine Anfrage an den freigegebenen Endpunkt kommt durch, und jede andere Anfrage behält das alte Portverhalten. Das ist enger als das Hinzufügen des Ports zu einer globalen SSL_ports-Liste, was diesen Port für jedes Ziel erlauben würde. Steht der Port bereits auf dieser Liste, verengt diese ACL nichts, und die ältere, weitere Erlaubnis gilt weiterhin für andere Ziele, also lesen Sie die aktuelle Liste, bevor Sie behaupten, die Ausnahme habe den Port geöffnet. Sie ist außerdem umkehrbar, denn zwei Zeilen kehren in ihre frühere Form zurück. Die Referenz zur Zugriffskontrolle dokumentiert die Reihenfolge und die üblichen Wächter, auf denen diese Änderung beruht.

Wo die Ausnahme nicht stehen darf

Die Versuchung ist, eine Erlaubnis über die Wächter zu setzen und fertig zu sein. Diese Platzierung überspringt auch die Authentifizierungs- und Lokalziel-Schutzmaßnahmen, die in einer funktionierenden Konfiguration meist nahe der Spitze stehen. Das Ergebnis ist keine enge Ausnahme, sondern ein Loch mit einem Kommentar darüber. Halten Sie jede neue Erlaubnis auf derselben geprüften Stufe wie den Rest der Client-Richtlinie.

Prüfen Sie, was die Anfrage nach den Port-Wächtern noch braucht. Ein authentifiziertes Konto, eine erlaubte Client-Adresse und eine Zielrichtlinie gelten weiterhin, und die Ausnahme ändert nichts davon. Wenn Ihr Proxy dem freigegebenen Konto bereits beliebige Ziele erlaubt, war der Port-Wächter nie die eigentliche Kontrolle.

Überlegen Sie, ob der Endpunkt überhaupt TCP ist. Eine CONNECT-Ausnahme trägt TCP-Ströme, und ein OpenVPN-Profil mit UDP wird darüber nicht erreichbar. Stellen Sie das Profil nur dann auf TCP um, wenn der Server so lauscht und der Betreiber den Verhaltensunterschied akzeptiert.

Prüfen Sie die Grenze mit dem Parser und einer echten Anfrage

Parsen Sie die Konfiguration vor dem Neuladen und halten Sie dabei eine zweite Sitzung offen. Ein Syntaxfehler beim Neuladen kann den Proxy auf der alten Konfiguration belassen oder die neue rundweg ablehnen. Der Parser meldet die abgelehnte Zeile, was mehr ist, als der Clientfehler Ihnen sagt.

Laden Sie dann neu und senden Sie eine echte CONNECT-Anfrage von einer freigegebenen Quelle durch den Proxy. Der Parserlauf kommt zuerst, denn ein Neuladen mit einem Tippfehler lehrt Sie nichts über die Richtlinie.

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

Testen Sie drei Fälle: eine freigegebene Quelle und ein Konto, eine nicht freigegebene Quelle und ein anderes Ziel auf demselben Port. Der dritte Fall belegt, dass die Ausnahme eng ist, denn er übt den Port ohne den Zielabgleich aus. Lesen Sie für alle drei das Access-Log, statt der Clientmeldung zu vertrauen. Ein erfolgreiches CONNECT baut einen TCP-Strom auf und nichts weiter, der VPN-Handshake bleibt also ein eigener Test.