Eine TLS-Passthrough-Verbindung im NGINX-Stream-Kontext zulassen

NGINX kann ein TCP-TLS-Relay ablehnen, ohne TLS zu beenden. Die Allow-Regel gehört in stream, nicht in einen HTTP-location-Block, und prüfen Sie, welche Peer-Adresse ankommt.

Verschlüsselte Bytes weiterzuleiten, ohne je das Zertifikat zu besitzen, ist die Aufgabe eines TLS-Passthrough-Relays, und die Anordnung ist bequem und zugleich etwas verwirrend. Da nichts entschlüsselt wird, gibt es nichts HTTP-Förmiges zum Filtern, weshalb der übliche location-Block und seine Zugriffsregeln hier nichts bewirken. Die Entscheidung, die NGINX treffen kann, betrifft die Verbindung selbst: welcher Netzwerk-Peer angeklopft hat und ob dieser Peer überhaupt weitergeleitet werden soll.

Die Entscheidung gehört in stream, nicht in HTTP

Im stream-Kontext arbeitet NGINX mit TCP-Sitzungen. Er sieht die Peer-Adresse der Verbindung und kann geordnete allow- und deny-Regeln darauf anwenden, bevor ein einziges Byte das Backend erreicht. Das ist eine vollständige Zulassungsentscheidung, und sie braucht keinen privaten Schlüssel, kein Zertifikat und kein HTTP-Parsing.

MechanismWhat it decidesWhere it lives
stream allow/denyWhether this TCP peer is relayedstream server block
ssl_preread mapWhich backend a named connection goes tostream, with the preread module
HTTP location ruleWhether an HTTP request is servedhttp server block

Diese drei Zeilen ersetzen einander nie. Ein HTTP-Zugriffsdirektiv in die Datei zu kopieren, die Port 443 erwähnt, ändert nichts, weil der stream-Server den http-Kontext nie liest.

Die Verbindung zulassen, bevor sie weitergeleitet wird

Nehmen Sie eine bestehende Installation mit verfügbaren Modulen stream und stream-access an, VPN-Clients, die Quelladressen in 10.90.0.0/24 halten, und ein Backend unter 192.168.50.20:443, das bereits die vorgesehene HTTPS-Identität ausliefert.

stream {
    server {
        listen 443;

        allow 10.90.0.0/24;
        deny all;

        proxy_pass 192.168.50.20:443;
    }
}

Lesen Sie das als Fragment eines neuen Listeners, nicht als direkten Ersatz einer laufenden Konfiguration. Prüfen Sie zuerst bestehende Listener und Includes, denn ein zweiter Listener auf einem bereits belegten Port scheitert beim Reload, nicht zur Anforderungszeit.

Beachten Sie, was fehlt: kein listen ... ssl, kein Zertifikatsdirektiv. NGINX leitet den verschlüsselten Strom weiter, und das Backend beendet TLS und zeigt das Zertifikat, das der Client validiert. Ein Client, der die Allowlist nicht besteht, bekommt seine TCP-Sitzung abgelehnt, keine HTTP-403-Seite, und jedes Werkzeug, das einen Statuscode erwartet, meldet etwas Unbrauchbares.

Was die Allowlist abdeckt und was nicht

Wenn das Relay bereits Backends nach Servernamen wählt, können ssl_preread und eine Map diese Aufgabe weiter erledigen, sofern das Modul verfügbar ist. Der Name wird weiterhin vom Client geliefert, und nichts am Vorlegen eines Namens beweist, dass der Client dem VPN beigetreten ist.

Die Beispielregel deckt den gesamten stream-Listener ab. Das macht sie unpassend für einen einzigen Einstiegspunkt, der eine Mischung aus öffentlichen und reinen VPN-Seiten bedient, wo eine Ausnahme pro Name nötig wäre; getrennte Listener sind meist klarer als eine namensabhängige Richtlinie, die niemand lesen kann.

Zwei weitere Lücken sind erwähnenswert. Ein Präfix-Match sagt nichts darüber, über welche Schnittstelle das Paket ankam, und eine HTTP-Regel anderswo kann diesen Listener nicht beschränken. Beides sind Gründe, die Ingress-Richtlinie auf Host-Ebene im Blick zu behalten, statt eine allow-Zeile als die ganze Grenze zu behandeln. Schreiben Sie die Grenze als zwei Kontrollen nieder, die übereinstimmen müssen, damit eine Änderung an einer von beiden geprüft wird.

Welche Adresse sieht NGINX tatsächlich?

Ein Load Balancer, ein weiterer Proxy oder Source-NAT kann einen Vermittler vor NGINX setzen, sodass der beobachtete Peer nicht die innere Adresse des VPN-Clients ist. Untersuchen Sie den echten Pfad, bevor Sie ein Präfix wählen, denn eine Allowlist, die für die falsche Adresse geschrieben wurde, lässt entweder alle hinter dem Übersetzer durch oder niemanden.

PROXY-Protokoll und Umgang mit echter IP sind legitime Antworten, und sie dürfen nur für kompatible, ausdrücklich vertrauenswürdige Absender konfiguriert werden. Beide Mechanismen glauben dem Absender, und genau deshalb muss die Absenderliste kurz sein. Einem Identitäts-Header von irgendeinem Internet-Client zu vertrauen macht die Quellinformation nicht wieder vertrauenswürdig; es verwandelt eine korrekte Ablehnung in eine gefälschte Zulassung.

Beide Ergebnisse vor dem Reload testen

Validieren Sie die Konfiguration, laden Sie neu und testen Sie dann zweimal: eine neue erlaubte Sitzung, die funktionieren muss, und eine abgelehnte, die es nicht darf. Behalten Sie die normale Backend-Zertifikatsprüfung im erlaubten Test bei, denn ein Relay, das verbindet, aber das Backend nicht validieren kann, hat ein Problem gelöst und ein anderes geschaffen.

nginx -t
ss -tnp | grep ':443'

Prüfen Sie auch die Backend-Route und die Antwort getrennt. Die Allowlist zu bestehen beweist nur, dass NGINX die Sitzung angenommen hat; es kann ein unerreichbares Backend nicht antworten lassen und keinen Rückweg reparieren, der fehlte, bevor Sie begannen.

Ähnliche Artikel