У меня очень конкретный вопрос, который, кажется, задавался в первую очередь, но он немного другой и, я думаю, не совсем обычный случай.
Можно ли запустить несколько внутренних (веб) серверов, работает на один хозяин, с помощью единый домен, с участием единый сертификат SSL, с помощью единый внешний IP-адрес и один внешний порт, используя прямое отображение IP-адреса источника на внутренний порт?
Подумайте об этом, как если бы вы хотите обслуживать веб-сайт www.example.com для 10 клиентов в разных местах, получая различный контент, защищенный через проверенный SSL, на основе исходного IP-адреса, с которого они подключаются, в то время как вам нужен только один фактический сервер (и один внешний IP-адрес) в качестве хоста для 10 веб-серверов и, конечно, нужен только один сертификат SSL.
Дополнительная информация и условия:
Чтобы настроить это для примера ситуации, используя Apache в качестве примера для (веб) серверов, я имел в виду следующий план (при условии, что Apache настроен и у вас есть сертификат SSL, готовый к использованию для Apache, а локальный брандмауэр отсутствует. на коробке CentOS 7 используется для простоты этого примера):
Настройте статические IP-псевдонимы для вашего сетевого интерфейса ethX в / etc / sysconfig / network-scripts / ifcfg-ethX в поле CentOS 7
IPADDR=10.0.0.1
IPADDR1=10.0.0.2
IPADDR2=10.0.0.3
... etc. etc as many IP aliases as needed
PREFIX=24
PREFIX1=24
PREFIX2=24
... etc. etc. as many prefix aliases as needed
Настройте виртуальные хосты Apache в /etc/httpd/conf.d/example.conf в поле CentOS 7
Listen 4431
Listen 4432
... etc. etc. as many Listen entries as needed
<VirtualHost 10.0.0.1:4431>
ServerName www.example.com
SSLEngine on
SSLCertificateFile /some/directory/www.example.com.crt
SSLCertificateKeyFile /some/directory/www.example.com.key
</VirtualHost>
<VirtualHost 10.0.0.2:4432>
ServerName www.example.com
SSLEngine on
SSLCertificateFile /some/directory/www.example.com.crt
SSLCertificateKeyFile /some/directory/www.example.com.key
</VirtualHost>
... etc. etc. as many VirtualHost directives as needed
Настройте исходный IP-адрес клиента для перенаправления портов в /etc/pf.conf брандмауэра OpenBSD
match out on $netw_interface from $internal_server1 nat-to $external_ip
match out on $netw_interface from $internal_server2 nat-to $external_ip
... etc. etc. as many NAT rules as needed
pass in quick log on $netw_interface proto tcp from $client1 to $external_ip port 443 rdr-to $internal_server1 port 4431
pass in quick log on $netw_interface proto tcp from $client2 to $external_ip port 443 rdr-to $internal_server2 port 4432
... etc. etc. as many port redirect rules as needed
Если правила сопоставления предназначены для NAT, $ client1 - это внешний исходный адрес клиента и так далее, $ internal_server1 - это первый виртуальный хост, прослушивающий 10.0.0.1:4431 и так далее, а $ external_ip - это IP-адрес, по которому A-запись сайта www.example.com указывает на.
Это может показаться бесполезным, но в реальной ситуации у меня может быть.
Кто-нибудь пробовал это раньше? И если да, то хорошо ли это работало и управляемо? И это каким-то образом видно клиентам?
Заранее спасибо.
Я думаю, что вы слишком усложняете задачу.
Все, что вам нужно, - это сложный обратный прокси-сервер, такой как Nginx. Он может перенаправлять запросы на несколько внутренних серверов на основе множества правил / условий, таких как исходный IP-адрес, заголовок запроса, конкретный URI и т. Д. Вы можете настроить обратный прокси-сервер, прослушивающий порт 80/443, и внутренние серверы, работающие на одном сервере на других портах или на других серверах.
Основной домен / SSL, а также различные правила должны быть настроены на обратном прокси-сервере. В зависимости от правила обратный прокси-сервер будет обслуживать запрос от определенного внутреннего сервера, и эта конфигурация никогда не будет видна конечным пользователям.