Назад | Перейти на главную страницу

Несколько поддоменов, указывающих на один и тот же общедоступный IP-адрес и порт

Я хотел бы объяснить сценарий, который мы задаем вопросом:

у нас есть домен:

  • www.example.com

и следующие поддомены:

  • forum.example.com
  • portal.example.com
  • crm.example.com

и следующие приложения, размещенные на отдельных серверах:

  • Форум - IP-адрес сервера: 1.1.1.1, порт: 1010
  • портал - IP-адрес сервера: 2.2.2.2, порт: 2020
  • crm - IP-адрес сервера: 3.3.3.3, порт: 3030

все серверы работают за брандмауэром

с другой стороны, у нас есть только один публичный IP-адрес:

10.10.10.10

поэтому, чтобы связать локальные серверы с общедоступным IP-адресом, мы можем создать записи виртуального хостинга в брандмауэре и создать общедоступные порты следующим образом:

  • 10.10.10.10:1010 будет указывать на 1.1.1.1:1010
  • 10.10.10.10:2020 будет указывать на 2.2.2.2:2020
  • 10.10.10.10:3030 будет указывать на 3.3.3.3:3030

Затем мы настроим следующую запись A NAME в ЗОНЕ DNS:

  • www.example.com - 10.10.10.10

так что пойти в Форум приложение, пользователь должен ввести:

  • www.example.com:1010

и так далее:

  • www.example.com:2020 для портал
  • www.example.com:3030 для crm

теперь вместо номера порта мы хотели бы использовать поддомен, например, если пользователь хочет перейти на форум, он просто наберет:

  • Форум.example.com

и то же самое для других приложений.

Возможно ли это сделать без покупки новых общедоступных IP-адресов для каждого приложения?

Простите за длинный пост. Спасибо

Я так понимаю, ваши различные приложения доступны через HTTP / HTTPS. В этом случае у вас есть несколько распространенных вариантов.

  • Пусть ваш веб-сервер проксирует остальные три поддомена (www также является поддоменом) для сервисов.
  • Установите прокси HTTP / HTTPS для прокси всех поддоменов (а также домена).

Вы можете начать с одного варианта, а позже перейти к другому. Некоторые контейнеры приложений имеют плагины для веб-серверов, которые добавляют заголовки прокси, специфичные для контейнера.

Если вы используете HTTPS. вам потребуется альтернативное имя субъекта для каждого домена в сертификате. Кроме того, вы можете использовать SNI во внешнем интерфейсе (веб-сервер или прокси), чтобы предоставить клиенту правильный сертификат (только для клиентов с поддержкой SNI).