Получилось так, что на днях пришлось побороться с проблемой одного из моих клиентов. Сервер клиента расположен в польском Дата-центре ATMAN. Несмотря на то, что этот Дата-центр крупный, цивилизованный и в 2013 году номинирован на звание лучшего в мире, в его работе тоже есть свои глюки, которые специалисты ATMAN объясняют спецификой построения инфраструктуры для борьбы с DDOS.
Если описывать вкратце — ATMAN распределяет дополнительные сетевые адреса из других под-сетей, что накладывает определенные ограничения на их использование. В том случае, о котором сейчас идет речь, необходимо использовать их не в качестве псевдонимов на сетевом интерфейсе рядом с основным адресом, а в качестве основных IP для виртуальных машин под управлением Hyper-V.
Я попытался найти решение аналогичной проблемы в поисковиках, но не нашел и поэтому решил написать краткую инструкцию для тех, кто может столкнуться с подобной проблемой в будущем.
В нашем примере будут использованы такие сетевые настройки:
Основной IP: ***.189.53.206/30
Дополнительный IP: ***.91.26.173/32
Сервер имеет два сетевых интерфейса, но используется только один. Все операции буду выполняться именно с ним.
Рис.1. Для удобства стандартные имена были изменены на LAN1 (используется для доступа к сети) и LAN2 (отключен).
Рис.2. Основной интерфейс настраиваем согласно предоставленным ДЦ данными.
Далее, необходимо настроить два виртуальных маршрутизатора — первый имеет тип «Внешний» с выходом во внешний мир, второй «Внутренний» для коммутации корневого сервера с виртуальным хостом. Оба виртуальных коммутатора необходимо создать в диспетчере виртуальных сетей консоли управления Hyper-V.
Рис.3. Для внешнего интерфейса необходимо использовать сетевую карту с доступом в интернет.
Рис.4. Для внутреннего виртуального коммутатора используются настройки, как показано на этом рисунке.
На этом подготовка новых сетевых интерфейсов закончена. У нас должно получиться такое:
Рис.5. Два дополнительных интерфейса – внешний и внутренний
При создании внешнего интерфейса произойдет разрыв всех соединений. Убедитесь в том, что у Вас есть другой доступ к серверу (IP-KVM, IPMI или непосредственно физический).
В нашем случае мне повезло и ДЦ дает IPMI по умолчанию.
В настройках внутреннего интерфейса (Internal) укажите настройки схожие с теми, что используются тут, в нашем случае это 192.168.0.1. Этот интерфейс на физическом сервере будет выступать в роли шлюза для виртуальных машин.
Рис.6. Настройки для внутреннего виртуального коммутатора.
Дальнейшие настройки сетевых интерфейсов на корневом сервере завершены. Далее необходимо настроить службу RRAS для перенаправления трафика к виртуальным машинам и обратно.
Для реализации этого необходимо установить роль «Службы политики сети и доступа» в оснастке Диспетчера сервера. Думаю, что расписывать этот процесс нет необходимости – Вы же уже установили роль Hyper-V ранее
Рис.7. Установленная роль RRAS.
После завершения установки данной роли она находится в статусе «Остановлена». По этому, ее нужно изначально настроить перед запуском.
Рис.8. Начальная настройка службы.
Перед Вами откроется окно мастера настройки службы. Выполняйте все действия, как показано на рисунках.
Рис.9. Окно мастера настройки службы.
Рис.10. Выбор особой конфигурации для нашего случая.
Рис.11. Выбираем только преобразование адресов и маршрутизацию локальной сети.
Рис.12. Завершающий этап настройки. Нажимаем «Готово».
Рис.13. Соглашаемся на предложение запустить новую службу.
После этого мы увидим в Диспетчере сервера развернутое дерево элементов этой самой службы RRAS.
Рис.14. Служба готова к настройке.
Для перенаправления трафика к виртуальной машине нужно создать интерфейс через который будут проходить все запросы. ПКМ на элементе «Преобразование сетевых адресов» выбираем пункт «Новый интерфейс».
Рис.15. Создание нового интерфейса.
В окне выбора интерфейсов нам необходимо использовать внешний сетевой интерфейс. Внутрений используется только для связи корневого сервера с виртуальными машинами.
Рис.16. Выбор интерфейса для преобразования сетевых адресов.
В свойствах внешнего интерфейса нам необходимо включить преобразование адресов, как показано ниже:
Рис.17. Включение преобразования адресов.
Далее, добавляем пул адресов, это наши дополнительные адреса запросы от которых будут перенаправляться на внутренние адреса виртуальных машин. ВАЖНО: не указывайте маску 255.255.255.255 для этих целей, работать это не будет. В нашем случае мы имеем три дополнительных адреса, маска указана /24 (особой роли это не играет).
Рис. 18. Заполняем данные в окне пула адресов.
Теперь необходимо зарезервировать дополнительный адрес за внутренним у виртуальной машины. Делается все это очень просто.
Рис.19. Резервирование адресов для виртуальных машин.
В сетевых настройках указываем данные из той подсети, в которой находится шлюз. В нашем случае внутренняя подсеть вида 192.168.0.0/24, дополнительный адрес ***.91.26.173 мы закрепили за внутренним 192.168.0.3. Настройки сети виртуальной машины выглядят таким образом:
Рис.20. Сетевые настройки виртуальной машины.
Если все настроено правильно, то в центре управления сетями виртуальной машины получим такой вид (машина имеет доступ к интернету). В ином случае – проверьте настройки Брендмауэра на серверах.
Рис.21. Центр управления сетями виртуальной машины.
Любым сервисом проверяем корректность наших глобальных настроек. Результат: запрос с виртуальной машины должен показать нам именно внешний адрес, который был зарезервирован нами ранее:
Рис.22. Результат теста на сайте 2ip.ru.
На виртуальной машине, для проверки перенаправления портов, трафика, мигрантов и прочего, была установлена роль IIS. С любого ПК в браузере обращаемся к данному адресу, если видим «заглушку» веб-сервера – все прошло отлично, поставленную задачу мы решили.
Рис.23. То, чего и добивались. Все работает.
Таким образом, мы можем использовать множество разных подсетей на одном физическом сервере. С той лишь разницей, что для разных внутренних подсетей необходимо будет создавать отдельные виртуальные коммутаторы.
Спасибо за внимание.,
Автор: slayer83
