Как стать автором
Обновить

Настройка доступа к сети виртуальных машин Hyper-V из разных подсетей

Виртуализация
Из песочницы
Получилось так, что на днях пришлось побороться с проблемой одного из моих клиентов. Сервер клиента расположен в польском Дата-центре ATMAN. Несмотря на то, что этот Дата-центр крупный, цивилизованный и в 2013 году номинирован на звание лучшего в мире, в его работе тоже есть свои глюки, которые специалисты ATMAN объясняют спецификой построения инфраструктуры для борьбы с DDOS.
Если описывать вкратце — ATMAN распределяет дополнительные сетевые адреса из других под-сетей, что накладывает определенные ограничения на их использование. В том случае, о котором сейчас идет речь, необходимо использовать их не в качестве псевдонимов на сетевом интерфейсе рядом с основным адресом, а в качестве основных IP для виртуальных машин под управлением Hyper-V.

Я попытался найти решение аналогичной проблемы в поисковиках, но не нашел и поэтому решил написать краткую инструкцию для тех, кто может столкнуться с подобной проблемой в будущем.

В нашем примере будут использованы такие сетевые настройки:
Основной IP: ***.189.53.206/30
Дополнительный IP: ***.91.26.173/32
Сервер имеет два сетевых интерфейса, но используется только один. Все операции буду выполняться именно с ним.

image
Рис.1. Для удобства стандартные имена были изменены на LAN1 (используется для доступа к сети) и LAN2 (отключен).

image
Рис.2. Основной интерфейс настраиваем согласно предоставленным ДЦ данными.

Далее, необходимо настроить два виртуальных маршрутизатора — первый имеет тип «Внешний» с выходом во внешний мир, второй «Внутренний» для коммутации корневого сервера с виртуальным хостом. Оба виртуальных коммутатора необходимо создать в диспетчере виртуальных сетей консоли управления Hyper-V.

image
Рис.3. Для внешнего интерфейса необходимо использовать сетевую карту с доступом в интернет.

image
Рис.4. Для внутреннего виртуального коммутатора используются настройки, как показано на этом рисунке.

На этом подготовка новых сетевых интерфейсов закончена. У нас должно получиться такое:

image
Рис.5. Два дополнительных интерфейса – внешний и внутренний

При создании внешнего интерфейса произойдет разрыв всех соединений. Убедитесь в том, что у Вас есть другой доступ к серверу (IP-KVM, IPMI или непосредственно физический).
В нашем случае мне повезло и ДЦ дает IPMI по умолчанию.

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

image
Рис.6. Настройки для внутреннего виртуального коммутатора.

Дальнейшие настройки сетевых интерфейсов на корневом сервере завершены. Далее необходимо настроить службу RRAS для перенаправления трафика к виртуальным машинам и обратно.

Для реализации этого необходимо установить роль «Службы политики сети и доступа» в оснастке Диспетчера сервера. Думаю, что расписывать этот процесс нет необходимости – Вы же уже установили роль Hyper-V ранее 

image
Рис.7. Установленная роль RRAS.

После завершения установки данной роли она находится в статусе «Остановлена». По этому, ее нужно изначально настроить перед запуском.

image
Рис.8. Начальная настройка службы.

Перед Вами откроется окно мастера настройки службы. Выполняйте все действия, как показано на рисунках.

image
Рис.9. Окно мастера настройки службы.

image
Рис.10. Выбор особой конфигурации для нашего случая.

image
Рис.11. Выбираем только преобразование адресов и маршрутизацию локальной сети.

image
Рис.12. Завершающий этап настройки. Нажимаем «Готово».

image
Рис.13. Соглашаемся на предложение запустить новую службу.

После этого мы увидим в Диспетчере сервера развернутое дерево элементов этой самой службы RRAS.

image
Рис.14. Служба готова к настройке.

Для перенаправления трафика к виртуальной машине нужно создать интерфейс через который будут проходить все запросы. ПКМ на элементе «Преобразование сетевых адресов» выбираем пункт «Новый интерфейс».

image
Рис.15. Создание нового интерфейса.

В окне выбора интерфейсов нам необходимо использовать внешний сетевой интерфейс. Внутрений используется только для связи корневого сервера с виртуальными машинами.

image
Рис.16. Выбор интерфейса для преобразования сетевых адресов.

В свойствах внешнего интерфейса нам необходимо включить преобразование адресов, как показано ниже:

image
Рис.17. Включение преобразования адресов.

Далее, добавляем пул адресов, это наши дополнительные адреса запросы от которых будут перенаправляться на внутренние адреса виртуальных машин. ВАЖНО: не указывайте маску 255.255.255.255 для этих целей, работать это не будет. В нашем случае мы имеем три дополнительных адреса, маска указана /24 (особой роли это не играет).

image
Рис. 18. Заполняем данные в окне пула адресов.

Теперь необходимо зарезервировать дополнительный адрес за внутренним у виртуальной машины. Делается все это очень просто.

image
Рис.19. Резервирование адресов для виртуальных машин.

В сетевых настройках указываем данные из той подсети, в которой находится шлюз. В нашем случае внутренняя подсеть вида 192.168.0.0/24, дополнительный адрес ***.91.26.173 мы закрепили за внутренним 192.168.0.3. Настройки сети виртуальной машины выглядят таким образом:

image
Рис.20. Сетевые настройки виртуальной машины.

Если все настроено правильно, то в центре управления сетями виртуальной машины получим такой вид (машина имеет доступ к интернету). В ином случае – проверьте настройки Брендмауэра на серверах.

image
Рис.21. Центр управления сетями виртуальной машины.

Любым сервисом проверяем корректность наших глобальных настроек. Результат: запрос с виртуальной машины должен показать нам именно внешний адрес, который был зарезервирован нами ранее:

image
Рис.22. Результат теста на сайте 2ip.ru.

На виртуальной машине, для проверки перенаправления портов, трафика, мигрантов и прочего, была установлена роль IIS. С любого ПК в браузере обращаемся к данному адресу, если видим «заглушку» веб-сервера – все прошло отлично, поставленную задачу мы решили.

image
Рис.23. То, чего и добивались. Все работает.

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

Спасибо за внимание.,
Теги:hyper-vподсетинастройкавиртуализация
Хабы: Виртуализация
Всего голосов 8: ↑6 и ↓2 +4
Просмотры122.9K

Похожие публикации

Hyper Casual
1 августа 202160 500 ₽XYZ School
Школа Тест-Менеджеров, v. 2.0
14 июля 202116 000 ₽Лаборатория Качества
Факультет разработки игр
16 июня 2021180 000 ₽GeekBrains
Факультет веб-разработки
16 июня 2021270 000 ₽GeekBrains
Профессия Data Science
16 июня 2021114 000 ₽SkillFactory

Лучшие публикации за сутки