Ich habe ein Smart-DNS-Setup und verwende dnsmasq als DNS-Server, der für eine bestimmte Liste von Domänen immer die IP-Adresse meines Servers auflöst.
Ich möchte entweder einen Webserver oder ein Proxyprogramm so konfigurieren, dass es auf Port 80 und 443 auf meinem Server lauscht. Dieses leitet dann alle Webanforderungen als Proxyanforderungen an einen externen Proxyserver (Squid) weiter.
Wäre es möglich, dies mit Programmen wie (nginx, harproxy, squid usw.) sowohl für HTTP- als auch für HTTPS-Verkehr zu tun, ohne SSL-Terminierung auf dem Server?
Bisher hat keine der von mir getesteten Konfigurationen funktioniert, Haproxy-Konfiguration.
frontend https_front
bind *:443
mode tcp
default_backend squid_backend_https
backend squid_backend_https
mode tcp
server squid_proxy 111.22.32.11:3323
Nginx-Konfiguration,
stream {
upstream ssl_backend {
server 111.22.32.11:3323;
}
server {
listen 443;
proxy_protocol on;
tcp_nodelay on;
proxy_pass ssl_backend;
ssl_preread on;
proxy_ssl_protocols TLSV1 TLSv1.2 TLSv1.3;
proxy_ssl_ciphers 'HIGH:!aNULL:!MD5';
proxy_ssl on;
proxy_ssl_server_name on;
#proxy_next_upstream on;
proxy_ssl_verify off;
}
}
Ich gehe davon aus, dass das Backend-Programm, das auf 80 und 443 lauscht, die http/https-Webanforderung effektiv als Proxyanforderung an den externen Proxyserver (Squid) weiterleiten sollte.
Erstens: Ist dies theoretisch möglich, wenn man nur Haproxy, Squid, Nginx oder ein ähnliches Programm verwendet?
Für jede Hilfe, wie dies erreicht werden kann, wäre ich sehr dankbar. Danke
Aktualisierung 1
Der externe Proxyserver wird benötigt, um auf die gewünschten Websites zuzugreifen. Wenn ich den Proxy-IP:Port manuell im Browser hinzufüge, funktioniert es einwandfrei.
Bei manchen Anwendungen habe ich jedoch Einschränkungen, da der Proxy nicht hinzugefügt werden kann. Um dieses Problem zu umgehen, teste ich ein Setup, bei dem die Anfragen für diese spezifischen Domänen vom DNS an meinen Reverse-Proxy weitergeleitet werden, der die Anfragen dann über den externen Proxy-Server bedienen muss.
Der DNS-Teil funktioniert einwandfrei. Er wird für die erforderlichen Domänen in meine Reverse-Proxy-IP aufgelöst. Ich komme nicht weiter beim Versuch, den Reverse-Proxy (nicht nur nginx, offen für jedes andere Programm) so zu konfigurieren, dass die Anfragen über den externen Proxy bedient werden.
Der Reverse-Proxy hat keinen Zugriff auf SSL-Zertifikate für die Domänen. Die SSL-Beendigung erfolgt, nachdem die Anfrage an den externen Proxy-Server weitergeleitet wurde.
Aktualisierung 2
Es besteht nicht die Möglichkeit, auf dem Reverseproxy Zertifikate für diese Domänen bereitzustellen.
Eine Möglichkeit, die mir einfällt, ist die Konfiguration des Reverse-Proxys, um den https-Verkehr zusammen mit SNI an den externen Proxy umzuleiten, ohne das SSL auf dem Server zu beenden.
Die einzige Maschine, auf der ich sinnvolle Änderungen vornehmen kann, ist der Reverse-Proxy-Server. Auf dem Server läuft Ubuntu 22.04.
Die einzige Änderung, die auf den Client-Rechnern vorgenommen werden kann, ist die IP des DNS-Servers (DNSMASQ-Server).
Es besteht keine Möglichkeit, Änderungen am externen Proxy (Squid) vorzunehmen.
Der externe Proxy akzeptiert nur HTTP-Relay und Connect-Proxy-Verbindungen.
Hoffe, das macht die Frage etwas klarer.
Antwort1
Basierend auf Update 2 besteht die einzige praktikable Lösung darin, einen zusätzlichen Proxy zwischen dem Client und dem vorhandenen Proxy zu implementieren, um dem Stream von der Clientseite das Präfix „CONNECT-Hostname“ zuzuweisen.
Korkenzieher(traditioneller zum Tunneln von SSH-Verbindungen über einen Webproxy verwendet) kann das, kommuniziert aber nur mit stdin/stdout und wird als einzelner Thread ausgeführt. Die Ausführung über xinetd löst diese Einschränkungen jedoch.
Dann müssen Sie nur noch den Datenverkehr zum Corkscrew-Host umleiten. Dies könnte in iptables oder über DNS erfolgen.
Antwort2
Mit HAProxy sollte dies funktionieren
global
log /dev/log local0
log /dev/log local1 notice
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
stats timeout 30s
user haproxy
group haproxy
daemon
ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
ssl-default-bind-options prefer-client-ciphers no-sslv3 no-tlsv10 no-tlsv11 no-tlsv12 no-tls-tickets
ssl-default-server-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
ssl-default-server-options no-sslv3 no-tlsv10 no-tlsv11 no-tlsv12 no-tls-tickets
defaults
log global
mode http
option httplog
option dontlognull
timeout connect 5000
timeout client 50000
timeout server 50000
frontend http-in
bind *:80
default_backend your_backend
frontend https-in
bind *:443 ssl crt /etc/haproxy/certs/ alpn h2,http/1.1 # Specify path to your SSL certificates
default_backend your_backend
backend your_backend
server backend-server1 192.168.1.10:80 # Replace with the IP and port of your backend server
Nginx: Um HTTPS-Verkehr weiterleiten zu können, benötigen beide Seiten ein SSL-Zertifikat.
server {
listen 80;
server_name yourdomain.com;
location / {
proxy_pass http://your_backend_server;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
server {
listen 443 ssl;
server_name yourdomain.com;
ssl_certificate /path/to/your/certificate.crt;
ssl_certificate_key /path/to/your/private.key;
location / {
proxy_pass https://your_backend_server;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
Fügen Sie diesen virtuellen Host zu /etc/nginx/sites-available hinzu, erstellen Sie einen symbolischen Link zu sites-enabled und laden Sie nginx neu.