Предположения

Если я вас правильно понимаю, вы действительно хотите, чтобы nginx прослушивал один IP-адрес и комбинацию TCP-порта (например, listen 10.0.0.1:443), а затем, в зависимости от характеристик входящего трафика TCP-потока, перенаправлял его на один из 3 разных IP-адресов. адреса.

Вы явно не упоминаете, как вы ожидаете, что он будет различать 3 разных домена, но я предполагаю, что вы предполагаете, что это всего лишь TLS, и вы должны захотеть использовать какой-то механизм TLS SNI (указание имени сервера) для доменная дифференциация.

Я считаю, что документация по потокам, представленная на http://nginx.org/docs/, является достаточно авторитетной и исчерпывающей для модулей. на кону (я перечисляю все это здесь, поскольку, по-видимому, еще нет центрального места для перекрестных ссылок, например, пока нет ссылок из модуля "ядра потока" на подмодули (и docs/stream/ просто перенаправляет обратно docs/), что действительно довольно сбивает с толку, поскольку такие вещи, как http://nginx.org/r/upstream, задокументированы только для применения к http, без любое упоминание о применимости к stream, даже если в конце директивы примерно одинаковы):

• http://nginx.org/docs/stream/ngx_stream_core_module.html
• http://nginx.org/docs/stream/ngx_stream_access_module.html
• http://nginx.org/docs/stream/ngx_stream_limit_conn_module.html
• http://nginx.org/docs/stream/ngx_stream_proxy_module.html
• http://nginx.org/docs/stream/ngx_stream_ssl_module.html
• http://nginx.org/docs/stream/ngx_stream_upstream_module.html

Отвечать

Обратите внимание, что каждая директива nginx из каждого модуля имеет ограниченное количество применимых Context.

Таким образом, к сожалению, здесь просто нет директивы для отслеживания SNI!

Напротив, фактически задокументировано в stream_core, что, цитируя, "Different servers must listen on different address:port pairs.", как вы могли заметить, это также противоречит тому, как listen работает в более распространенном http_core, и является довольно недвусмысленной ссылкой на тот факт, что в настоящее время для listen в stream не реализована поддержка SNI.

Обсуждение

В качестве предмета обсуждения и предложения по разрешению проблемы предположение, что трафик OpenVPN - это просто TLS с отслеживаемым SNI, также не обязательно верно (но я не слишком знаком с OpenSSL или SNI):

• Учтите, что даже если сегодня SNI пассивно отслеживается, это явно противоречит обещанию TLS обеспечивать безопасность соединения и, как таковое, может измениться в будущей версии TLS.

• Для обсуждения, если OpenVPN просто использует соединение TLS, и если он НЕ использует TLS для аутентификации пользователей с помощью пользовательских сертификатов (что значительно усложнит задачу для MitM потока, но все еще несут данные аутентификации все время), то теоретически если бы nginx действительно имел поддержку SNI около listen в stream, то вы, возможно, смогли бы активно MitM это с nginx (поскольку proxy_ssl уже поддерживается в stream_proxy).

Что наиболее важно, я считаю, что OpenVPN лучше всего запускать по собственному протоколу на основе UDP, и в этом случае вы можете использовать один и тот же IP-адрес и номер порта для одного экземпляра https на основе TCP и другого для OpenVPN на основе UDP. без конфликта.

В конце концов, вы можете спросить, для чего же тогда модуль stream был бы полезен? Я считаю, что его целевой аудиторией будет (0) балансировка нагрузки HTTP/2 с несколькими upstream серверами на основе hash IP-адреса клиента, например, и / или (1), более простой и протокольно- независимая замена для stunnel.

Теперь это возможно с добавлением модуля ngx_stream_ssl_preread, добавленного в Nginx 1.11.5. и модуль ngx_stream_map, добавленный в 1.11.2.

Это позволяет Nginx читать TLS Client Hello и решать на основе расширения SNI, какой бэкэнд использовать.

stream {

    map $ssl_preread_server_name $name {
        vpn1.app.com vpn1_backend;
        vpn2.app.com vpn2_backend;
        https.app.com https_backend;
        default https_default_backend;
    }

    upstream vpn1_backend {
        server 10.0.0.3:443;
    }

    upstream vpn2_backend {
        server 10.0.0.4:443;
    }

    upstream https_backend {
        server 10.0.0.5:443;
    }

    upstream https_default_backend {
        server 127.0.0.1:443;
    }

    server {
        listen 10.0.0.1:443;
        proxy_pass $name;
        ssl_preread on;
    }
}

Как упоминал @Lochnair, вы можете использовать модуль ngx_stream_map и переменная $ server_addr для решения этой проблемы. Вот мой пример.

Мой IP-адрес хоста 192.168.168.22, и я использую keepalived, привязанные 2 виртуальных IP-адреса к eth0.

$sudo ip a
...
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 5c:f3:fc:b9:f0:84 brd ff:ff:ff:ff:ff:ff
inet 192.168.168.22/24 brd 192.168.168.255 scope global eth0
   valid_lft forever preferred_lft forever
inet 192.168.168.238/32 scope global eth0
   valid_lft forever preferred_lft forever
inet 192.168.168.239/32 scope global eth0
   valid_lft forever preferred_lft forever

$nginx -v
nginx version: nginx/1.13.2

$cat /etc/nginx/nginx.conf
...
stream {
    upstream pod53{
        server 10.1.5.3:3306;
    }
    upstream pod54{
        server 10.1.5.4:3306;
    }

    map $server_addr $x {
        192.168.168.238 pod53;
        192.168.168.239 pod54;
    }
    server {
        listen 3306;
        proxy_pass $x;
    }
}

Таким образом, я могу посещать разные службы MySQL с одним и тем же портом 3306 через разные VIP-адреса. Точно так же, как посещение другой службы HTTP с тем же портом через другой server_name.

192.168.168.238 -> 10.1.5.3
192.168.168.239 -> 10.1.5.4