Коротко — два процесса не могут одновременно слушать один и тот же IP:порт. Варианты решения зависят от того, что вам доступно:
Вариант A — у вас можно добавить несколько IP на NIC (лучше всего)
- Назначьте второй (или дополнительные) публичные IP на сетевой интерфейс Windows (через GUI или netsh).
Пример:
netsh interface ipv4 add address "Ethernet" 192.0.2.10 255.255.255.0
- Привяжите каждый сервис к своему IP:443.
- В IIS: в Site → Bindings добавьте привязку HTTPS и укажите конкретный IP (не All unassigned).
- Другой сервис (RRAS/SSTP или кастомный) настройте так, чтобы он слушал на другом IP.
- Если оба сервиса используют http.sys/SSL (IIS и SSTP/RRAS используют http.sys), убедитесь, что SSL‑привязки (netsh http add sslcert ipport=...) заданы для соответствующих IP, чтобы не было конфликта сертификатов.
Вариант B — если нельзя выделить дополнительные IP
- Поставьте TCP/HTTPS прокси на порт 443 (он один принимает соединения) и проксируйте дальше по клиентскому IP/интерфейсу:
- Рекомендуемые инструменты: HAProxy, nginx (stream), Caddy, либо IIS ARR (работает на HTTP уровне, по hostname).
- Пример для HAProxy (TCP, маршрутизация по IP клиента):
frontend ft_https
bind *:443
tcp-request inspect-delay 5s
use_backend be_from_1 if { src 1.1.1.1 }
default_backend be_other
backend be_from_1
server srv1 127.0.0.1:4444
backend be_other
server srv2 127.0.0.1:5555
- Пример nginx stream (пасс‑рутовка по src):
stream {
map $remote_addr $up {
default backend_default;
1.1.1.1 backend1;
}
upstream backend1 { server 127.0.0.1:4444; }
upstream backend_default { server 127.0.0.1:5555; }
server {
listen 443;
proxy_pass $up;
}
}
- Прокси может работать на TCP‑уровне (прозрачная передача TLS) или на HTTP (терминирует TLS и роутит по хосту/SNI/URL).
Вариант C — netsh portproxy (только простое однонаправленное переадресование)
- Можно сделать проброс порта на другой порт на той же машине:
netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=443 connectaddress=127.0.0.1 connectport=4444
Но это одно правило без условия по src и требует, чтобы порт 443 слушал только portproxy (он «перехватывает» слушание). Нельзя задать условие по IP источника.
Вариант D — низкоуровневые перехватчики/WFP
- Для гибкой маршрутизации по source IP можно писать/использовать драйверы на базе WFP или юзерланговые инструменты вроде WinDivert, но это более сложные и рискованные варианты.
Специально по RRAS + IIS:
- Если вы хотите, чтобы RRAS (SSTP) и IIS «одновременно» использовали 443, то самый надёжный путь — дать им разные IP и сделать соответствующие SSL‑биндэнги (netsh http add sslcert ipport=IP:443 …). Если разных IP нет — один из них должен быть прокси/терминатором, который направляет трафик дальше (см. HAProxy/nginx).
- RRAS/SSTP и IIS оба используют HTTP.SYS, поэтому конфликты по ip:port/SSL будут возникать, если оба пытаются зарегистрировать один и тот же ip:port.
Резюме / рекомендации
- Если можно — выделите второй IP и просто привяжите сервисы к разным IP:443.
- Если нельзя — поставьте на сервер лёгкий TCP‑прокси (HAProxy/nginx/Caddy) на 443 и маршрутизируйте по src IP / SNI / hostname к бэкендам (127.0.0.1:4444 и т.д.).
- netsh portproxy — простой, но не позволяет условий по источнику.
- RRAS+IIS на одном IP:порт без прокси обычно невозможно из‑за http.sys/SSL‑блокировок.
Если хотите, могу:
- Привести подробную инструкцию по добавлению IP и настройке IIS/SSL (netsh) для вашей версии Windows, или
- Подготовить пример конфигурации HAProxy/nginx для конкретных IP/портов/правил.