Самый простой способ настроить несколько поддоменов на отдельные виртуальные машины, работающие на одном хосте


1

Проблема:

Я планирую установить несколько виртуализированных гостевых компьютеров centos, rhel или ubuntu на одном хост-сервере centos (скорее всего, с использованием KVM). На каждой гостевой виртуальной машине запущен экземпляр веб-приложения + некоторые другие службы / протоколы, и каждая гостевая виртуальная машина должна быть доступна извне хоста на любом открытом порту, как если бы каждая из них представляла собой отдельную коробку DNSed.

Я (очевидно) слаб в сетевой технологии / конфигурации, поэтому я просто пытаюсь найти первые грани этой проблемы, т.е. основные подходы, которые мне нужно изучить, чтобы закрепиться на этом. Сетевой конфиг "псевдокод", если хотите. :)

Пример:

Допустим, мне принадлежит домен foo.com.

У меня есть физическая машина CentOS, DNSed как guest.foo.com.

На этом физическом хосте у меня работает три виртуальные машины. Я хочу, чтобы гостевые виртуальные машины были доступны как 1.ghest.foo.com, 2.ghest.foo.com и 3.ghest.foo.com. Гостевые виртуальные машины работают с дистрибутивами centos, rhel и ubuntu.

Каждая виртуальная машина должна отвечать на любой (локально открытый) порт, не только http-трафик, но также соединения ssh и операции протокола git :.

С чего начать, какой самый элегантный подход? Что примерно нужно, чтобы хозяин и гости, как минимум, должны быть настроены для того, чтобы это работало хорошо?

Примечание:

Я обновлю текст вопроса + комментарии, когда узнаю больше.

Ответы:


3

Если у вас нет хотя бы одного общедоступного IP-адреса для каждой виртуальной машины, вы не сможете заставить их отвечать на «любой» открытый порт (то есть вам понадобятся запросы NAT, поступающие на определенные порты публичных IP-адресов ваших хост-систем на внутренний IP-адрес виртуальной машины). Допустим, у вас есть только 1 публичный IP, например. 2.3.4.5 и это настроено на хосте. Теперь вы можете перенаправлять запросы, поступающие на порт 80, на 1 виртуальную машину, а запросы на 443 - на другую виртуальную машину и запрашивать передачу на любой другой порт на любую виртуальную машину по вашему выбору, но в целом вы будете распределять 65530 используемых портов по IP и направляя их на ваши виртуальные машины, поэтому любая конкретная виртуальная машина не может прослушивать порт, который прослушивает другая виртуальная машина.

И если у вас есть несколько общедоступных IP-адресов (по крайней мере, 1 на виртуальную машину), вы можете просто создать записи DNS для IP-адресов виртуальных машин.

В настройке с несколькими IP-адресами у вас должна быть небольшая общедоступная подсеть, например, 2.3.4.0/28. Эта сеть содержит следующие используемые IP-адреса:

  1. 2.3.4.1
  2. 2.3.4.2
  3. 2.3.4.3
  4. 2.3.4.4
  5. 2.3.4.5
  6. 2.3.4.6

2.3.4.0 - это сетевой IP-адрес, который нельзя использовать, а 2.3.4.7 - широковещательный IP-адрес для сети. Теперь в этом подходе обычно первый IP (2.3.4.1) используется в качестве шлюза для остальной вашей подсети, т.е. Ваш Интернет-провайдер или DataCenter устанавливает маршрут для 2.3.4.0/8 с 2.3.4.1 в качестве следующего перехода в своем брандмауэре / маршрутизаторе. Теперь все запросы, поступающие из Интернета на любой IP в 2.3.4.0/8, поступают на компьютер с IP 2.3.4.1. Поэтому логично было бы иметь этот IP на вашем хост-компьютере.

Теперь вы можете следовать двум подходам:

  1. Соедините сетевые интерфейсы машин виртуальных машин с интерфейсом хост-машин, имеющих IP 2.3.4.1, и предоставьте виртуальным машинам IP 2.3.4.2, 3 и 4 на своих мостовых интерфейсах.

  2. Иметь сеть только для хоста на виртуальных машинах, например. 192.168.10.0/24 с IP 192.168.10.1 на виртуальном интерфейсе хоста и 192.168.10.2-4 на интерфейсах виртуальной машины. И тогда вы можете просто получать NAT-запросы с 2.3.4.X по 192.168.10.X.

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

1.ghest.foo.com 2.3.4.2 2.ghest.foo.com 2.3.4.3 3.ghest.foo.com 2.3.4.4 и т. Д.

Надеюсь, что это проливает некоторый свет на проблему.


Понятно, так как все виртуальные машины используют одни и те же порты, их нельзя просто перенаправить через порт, но их необходимо соединить для разделения IP-адресов. Это помогло мне начать, спасибо!
Томанил

Имейте в виду, что метод моста является нетрадиционным и не рекомендуется. Лучший способ описан в пункте № 2. И в любом случае, оба метода требуют отдельных IP-адресов для каждой виртуальной машины. Хорошей охоты.
Фахад Юсуф

0

Имена хостов могут указывать куда угодно. Это уникальные глобальные IP-адреса для каждой виртуальной машины, которая вам нужна. (Убедитесь, что они у вас есть; их может быть очень сложно получить в некоторых частях мира.) Каждой виртуальной машине потребуется собственный IP-адрес, и если вы хотите получить к ним доступ из Интернета, это должны быть глобальные адреса.

Самый простой способ сделать это - использовать мостовую сеть для виртуальных машин. То, как вы это настроите, зависит в основном от внешних факторов, например, от того, устанавливаете ли вы панель управления виртуальной машиной , но это руководство даст вам основные шаги по настройке моста на вашей локальной машине, чтобы вы могли начать тестирование и стать более знакомыми с тем, как все работает.


То есть, другими словами, использование поддоменов для маршрутизации к каждой виртуальной машине через хост-систему - это полный старт?
Томанил

Вы не получаете доступ к компьютеру через имя хоста, вы получаете доступ к нему через его IP-адрес. Дело в том, что имя хоста преобразуется в IP-адрес для вас (по DNS, по вашему hostsфайлу и т. Д.).
Майкл Хэмптон

Ах, да. Таким образом, любое разрешение субдомена не произойдет, пока я не доберусь до хост-системы. Оказавшись там, виртуальные хосты Apache могут позаботиться о части уравнения http, но другой трафик, такой как ssh: и git:, не имеет куда идти, кроме фактического порта, который они уже установили на хост-машине.
Томанил
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.