
У меня настроен Smart-DNS, в качестве DNS-сервера я использую dnsmasq, который всегда разрешается в IP-адрес моего сервера для заданного списка доменов.
Я хочу настроить веб-сервер или прокси-программу для прослушивания портов 80 и 443 на моем сервере. Которая затем перенаправляет все веб-запросы на внешний прокси-сервер (squid) в качестве прокси-запросов.
Возможно ли это сделать, используя такие программы, как (nginx, harproxy, squid и т. д.), как для http, так и для https трафика, без терминации ssl на сервере?
Пока что ни одна из протестированных мной конфигураций не сработала, конфигурация Haproxy.
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,
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;
}
}
Я предполагаю, что внутренняя программа, прослушивающая порты 80 и 443, должна эффективно пересылать веб-запрос http/https как прокси-запрос на внешний прокси-сервер (Squid).
Во-первых, возможно ли это сделать теоретически, используя только haproxy, squid, nginx или любую подобную программу?
Любая помощь в том, как этого добиться, будет высоко оценена. Спасибо
Обновление 1
Внешний прокси-сервер необходим для доступа к требуемым веб-сайтам. Если я вручную добавляю прокси ip:port в браузере, то все работает нормально.
Но у меня есть некоторые ограничения в некоторых приложениях, где прокси не может быть добавлен. Чтобы обойти эту проблему, я тестирую настройку, где запросы для этих конкретных доменов, dns разрешает, на мой обратный прокси, который затем должен обслуживать запросы через внешний прокси-сервер.
DNS-часть работает нормально. Она разрешается в мой IP-адрес обратного прокси для требуемых доменов. Застрял, пытаясь настроить обратный прокси (не просто nginx, открытый для любой другой программы), чтобы обслуживать запросы через внешний прокси.
Обратный прокси-сервер не имеет доступа к ssl-сертификатам для доменов. Прекращение ssl-соединения происходит после перенаправления запроса на внешний прокси-сервер.
Обновление 2
Нет возможности предоставлять сертификаты для этих доменов на обратном прокси-сервере.
Один из способов, который я могу придумать, — это настройка обратного прокси-сервера для перенаправления трафика https вместе с SNI на внешний прокси-сервер, не прерывая SSL на сервере.
Единственная машина, на которой я могу сделать какие-либо значимые изменения, находится на сервере обратного прокси. Сервер работает под управлением Ubuntu 22.04.
Единственное изменение, которое можно сделать на клиентских машинах, — это IP-адрес DNS-сервера (сервер dnsmasq).
Не предусмотрено внесение каких-либо изменений во внешний прокси-сервер (squid).
Внешний прокси-сервер принимает только соединения http-relay, Connect proxy.
Надеюсь, это прояснит вопрос.
решение1
На основе обновления 2 единственным приемлемым решением является реализация дополнительного прокси-сервера между клиентом и существующим прокси-сервером для добавления к потоку со стороны клиента префикса «CONNECT hostname».
Штопор(более традиционно используется для туннелирования ssh-соединений через веб-прокси) может это делать, но общается только со stdin/stdout и выполняется как один поток. Но запуск этого через xinetd решает эти ограничения.
Тогда у вас просто есть проблема маршрутизации трафика на хост corkscrew. Это можно сделать в iptables или через DNS.
решение2
С HAProxy это должно работать
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 Для проксирования https-трафика обеим сторонам необходим SSL-сертификат.
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;
}
}
Добавьте этот vhost в /etc/nginx/sites-available и создайте символическую ссылку на sites-enabled и перезагрузите nginx.