Ich versuche, per SNI-Proxy auf ein Subnetz auf einem Router zuzugreifen und dabei die Quell-IP beizubehalten.
Hintergrund: Ich habe einen Router, der DNAT verwendet, um Portweiterleitungen für viele Anwendungsports durchzuführen, und er ist mit einem Subnetz (tatsächlich über ein VPN) mit verschiedenen Backends verbunden. Für Protokolle, die NICHT über etwas wie HTTP-Host oder TLS-SNI verfügen, das je nach Anforderung an verschiedene IPs weitergeleitet werden kann, verwende ich einfach DNAT mit TCP-Portfilter, und das funktioniert gut.
Für TLS verwende ichSNIProxyum die eingehenden Verbindungen basierend auf TLS SNI an verschiedene Server zu multiplexen. Das funktioniert ziemlich gut, aber SINProxy sendet die TLS-Pakete vom Router selbst und verwirft dabei die Quelladressen. Dadurch werden einige Backend-Dienste unterbrochen, die auf die Quell-IP angewiesen sind.
Daher frage ich mich, ob es für Netfilter möglich ist, den Datenverkehr mit TLS SNI (optional mit externen Modulen) zu filtern und ihn mit DNAT weiterzuleiten (anstatt ihn einfach zu löschen). Wenn das nicht möglich ist, gibt es Alternativen?
Übrigens möchte ich auf meinem Router kein vollständiges HTTP (oder irgendwelche L5-Server) bereitstellen, weil:
- Ich muss den Datenverkehr entschlüsseln und per Proxy an das Backend weiterleiten. Das ist ein enormer Aufwand.
- Aufgrund der Komplexität der Verwaltung möchte ich keine TLS-Zertifikate auf Routern bereitstellen.
Vielen Dank im Voraus für jede hilfreiche Antwort.
Antwort1
Theoretisch -j NFQUEUEkönnte man sich vorstellen, so etwas zu tun, indem man den Userspace das erste Paket ändern lässt und NAT ausführt. In der Praxis ist das jedoch nicht möglich, da man eine vollständige ClientHello-Nachricht mit SNI-Erweiterung erhalten haben muss, um die neue Zieladresse zu erraten. Da das erste TCP-Paket leer sein wird oder bei UDP DTLS ohnehin einige Runden benötigt, ist es dann zu spät, um einen Fluss per NAT zu verarbeiten, der jetzt von conntrack verwaltet wird.
Sie benötigen einen Proxy. Der Proxy kann jedoch transparent gemacht werden, oder Sie können das PROXY-Protokoll mit Backend-Anwendungen verwenden, die es unterstützen (diese müssen jedoch die gemeinsame Verwendung des PROXY-Protokolls und TLS unterstützen).
Zum Beispiel haproxykann das Ausführen auf dem Gateway entweder: Es ist das Projekt, das diePROXY-Protokoll, und es kann auch Linux verwendenProxyserverZiel für transparentes (sowohl mit Quelle als auch mit Ziel transparentes) Proxying.
Hier ist ein Link, den ich zu einem GitHub-Gist gefunden habe, der beide Optionen bietet:Nutzen Sie HAProxy, um Anfragen transparent an Webdienste weiterzuleiten, die durch den Hostnamen identifiziert werden. Hier sind ein paar Zeilen zur transparenten Proxy-Konfiguration, die zusammen mit dem Linux-Kernel verwendet werden sollProxyserverDokumentation (auch im gleichen Sinne):
Die HAProxy-Serverkonfiguration würde wie folgt aussehen. Sie funktioniert sowohl im TCP- als auch im HTTP-Modus.
server app1-tls 192.0.2.10:3001 source * usesrc client weight 0
Antwort2
Daher frage ich mich, ob es für Netfilter möglich ist, den Datenverkehr mithilfe von TLS SNI zu filtern (optional mit externen Modulen).
Dies ist nicht möglich. NAT muss ab dem ersten Paket der Verbindung erfolgen, also dem TCP SYN, das den TCP-Handshake initiiert. Der SNI befindet sich jedoch nur im ClientHello des TLS-Handshakes, das erst nach Abschluss des TCP-Handshakes gesendet wird. Mit anderen Worten: Die für NAT erforderlichen Informationen sind zum Zeitpunkt des Bedarfs noch nicht verfügbar.
Wenn das nicht möglich ist, gibt es Alternativen?
haproxy kann die TCP-Verbindung beenden und dann die Daten basierend auf dem SNI im ClientHello weiterleiten – ohne TLS am Proxy zu beenden. Es kann dann die ursprüngliche Quell-IP des Clients innerhalb der TCP-Verbindung unter Verwendung des PROXY-Protokolls weiterleiten (im Grunde ein Header am Anfang der weitergeleiteten Verbindung). Wenn der Upstream-Server das PROXY-Protokoll selbst nicht versteht, kann man Software wie verwendenmmproxyum die Verbindung von Haproxy per SNAT so zu konfigurieren, dass die ursprüngliche Quell-IP angezeigt wird.