Настройка nat windows server 2016

Обновлено: 06.07.2024

Долгое время Hyper-V не имел возможности организации NAT собственными средствами, что в ряде случаев сильно ограничивало сетевые возможности гипервизора. Особенно остро это чувствовалось в лабораторных и тестовых средах, которые требовалось отделить от локальной сети, обеспечив при этом выход в интернет. С введением поддержки контейнеров потребность в сетях NAT только возросла, что сделало закономерным добавление функции преобразования сетевых адресов в гипервизор. Более подробно о настройке и особенностях применения NAT в Hyper-V мы расскажем в данной статье.

Создание сетей NAT возможно в Windows Server 2016, Hyper-V Server 2016 и более поздних версиях, а также Windows 10. На одном гипервизоре может быть создана только одна сеть NAT. Также обратите внимание, что в отличие от средств настольной виртуализации, таких как VMWare Workstation или VirtualBox, служба NAT в Hyper-V не предоставляет дополнительных сетевых служб, таких как DHCP или DNS, поэтому сетевые настройки виртуальным машинам вам придется назначить самостоятельно.

Также настройка NAT производится исключительно в консоли PowerShell и недоступна в графическом интерфейсе, однако это не представляет никаких сложностей.

Подключимся к нужному нам гипервизору, перейдем в командную строку и запустим консоль PowerShell:

Цвет консоли при этом не изменится, останется черным, но в начале строки приглашения появятся буквы PS.

Теперь создадим новый виртуальный коммутатор с типом сети Внутренняя:

где VM_NAT - имя нашего виртуального коммутатора, которое можно задать произвольно.

При создании сети данного типа автоматически создается виртуальный сетевой адаптер на хосте, поэтому просмотрим список адаптеров командой:

Из полученной информации нам нужно выяснить и запомнить индекс сетевого интерфейса, в нашем случае 16. Следующим шагом мы настроим на нем шлюз. Перед этим следует определиться с адресацией будущей сети NAT, выделив ей свою подсеть и указав адрес шлюза. В нашем случае это будут 192.168.192.0/24 и 192.168.192.1, теперь можно настраивать шлюз:

Где IPAddress - адрес шлюза, PrefixLength - префикс сети, префикс 24 соответствует маске 255.255.255.0, InterfaceIndex - индекс интерфейса, для которого мы выполняем настройку.

Ну и наконец создадим NAT:

где Name - имя нашей сети NAT, в нашем случае vNAT, задается на ваше усмотрение, InternalIPInterfaceAddressPrefix - внутренняя сеть NAT.

Теперь можно вернуться в оснастку управления Hyper-V, в Диспетчере виртуальных коммутаторов у нас появится новая сеть - VM-NAT.

Чтобы ее использовать, просто укажите этот коммутатор в настройках виртуальной машины:

Также вам потребуется выполнить ручную настройку сети внутри виртуальной машины, ей нужно выдать адрес и указать шлюз из внутренней сети NAT, а также любые доступные DNS:

Просмотреть существующие сети NAT, напоминаем, она должна быть только одна, можно командой:

Для удаления используйте:

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

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

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

Связанный с коммутатором виртуальный сетевой адаптер будет удален автоматически.

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

В случае, например с VirtualBox вопрос решается подключением виртуальной машины к сети с типом NAT, но как же быть с Hyper-V, в нем нельзя подключить виртуальный свитч к сети NAT.

Ответ очевиден — нужно подключить свитч к внутренней сети, и с него трафик натить через физический порт. Сделать это совсем не сложно.

Ниже я расскажу как можно настроить NAT на Windows Server 2016 через PowerShell, а так же как можно настроить NAT на более старых версиях ОС Windows, через RRAS (к слову и на Windows Server 2016, через RRAS то же можно делать).

Начнем с более предпочтительного и простого способа - через PowerShell, но он для Windows 2016 и Windows 10 (к слову эти же команды должны работать и на более старых версях Windows, при условии, что будет установлен PowerShell 5, но я не проверял, кто проверит, отпишитесь в комментариях).

Теперь опишу способ, как можно сделать NAT, который работает практически на всех версиях винды (на 2003, 2008, 2012 и 2016 соответсвенно), будем делать NAT через RRAS.

Сперва нужно поставить роль RAS, для этого заходим в диспетчер сервера, жмем управление и выбираем — добавить роли и компоненты.

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

В службах ролей удаленного доступа, выбираем маршрутизация,

и добавляем необходимые компоненты.

После завершения установки, перезагружаем сервер, возвращаемся в диспетчер сервера и выбираем: средства — маршрутизация и удаленный доступ.

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

На втором шаге мастера настройки сервера маршрутизации и удаленного доступа, выбираем - преобразование сетевых адресов (NAT).

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

На этом настройка NAT на Windows Server 2016 закончена, вернемся в консоль управления RRAS, развернем наш сервер, перейдем в IPv4, и зайдем в преобразование сетевых адресов.

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

А для внешнего так:

Здесь же можно сделать проброс портов, например, сделаю проброс ssh до виртуальной машины. Заходим в службы и порты и жмем добавить,

Здесь указываем понятное имя службы, входящий порт (порт по которому нужно ломиться на сервер), адрес сервера к которому пробрасываем порт, и порт сервера.

Установка и базовая настройка маршрутизации NAT, в Windows Server 2012-2016

Предварительно, сделайте настройку всех Ваших сетевых адаптеров.

Установка роли «Удалённый доступ»

Открываем диспетчер устройств, и заходим в «Добавить роли и компоненты».

Жмём «Далее», на памятке мастера.

В выборе типа установки, нас интересует «Установка ролей и компонентов».
Жмём «Далее».

Выбор целевого сервера.

Выбираем нужный сервер, или виртуальный жёсткий диск.
Жмём «Далее».

Выбор ролей сервера.

Выбираем «Удалённый доступ».
Жмём «Далее».

Выбор компонентов.

Если нужно, что то дополнительно, выбираем и жмём «Далее».

Информативное окно об удалённом доступе.

Выбор служб ролей.

Появляется окно, с компонентами необходимыми для маршрутизации.
Жмём «Добавить компоненты».

Информативное окно, о роли устанавливаемого веб сервера, который необходим для работы маршрутизации.
Жмём «Далее».

Подтверждение установки компонентов.

Начинается процесс установки.
Ждём завершения, и жмём «Закрыть».

Настройка маршрутизации и удалённого доступа

В области уведомлений диспетчера сервера, находим раздел «Средства».
Кликаем по нему, и заходим в раздел «Маршрутизация и удалённый доступ».

В открывшейся консоли, кликаем правой кнопкой мышки на нашем сервере, и в выдающем меню жмём на «Настроить и включить маршрутизацию и удалённый доступ».

Конфигурация.

Выбираем "Преобразование сетевых адресов NAT".
Жмём «Далее».

Подключение к интернету на основе NAT.

Выбираем первый вариант, а в списке интерфейсов, тот который имеет подключение к интернету.
Жмём «Далее».

Службы преобразования имён и адресов.

Так же, выбираем первый вариант «Включить базовые службы».
Жмём «Далее».

Назначение диапазонов адресов.

Система, исходя из подключения вашего сетевого адаптера, определяет диапазон адресов, которым будет обеспечена поддержка маршрутизации.
Жмём «Далее».

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

Сегодня мы рассмотрели тему: "Настройка NAT в Windows server 2012-2016". Добавили необходимую роль, установили нужные компоненты, и сделали базовую настройку.

Надеюсь статья была вам полезна. До встречи в новых статьях.

Видео на тему "Настройка NAT в Windows server 2012":

Видео на тему "Настройка NAT в Windows server 2016":

Понравилась статья?
Напиши Комментарий, и Поделись с Друзьями!

WMZ-кошелёк = Z667041230317
WMR-кошелёк = R571680308266 ✔ Для вас важна анонимность и безопасность в сети Internet?
✔ Вы боитесь доверять сторонним VPN сервисам из-за утечки информации?
✔ Вам нужен VPN, где гарантированно не ведутся логи?
✔ Хотите иметь возможность делиться VPN со своими близкими и друзьями?
✅ Лучшим решением будет - Персональный VPN-Cервер , работающий только для Вас.

* В зависимости от хостинг-провайдера и параметров самого сервера, ежемесячная оплата сервера, может быть дешевле, чем покупка многих платных vpn-клиентов (от 100 руб в месяц).

* При покупке платных vpn-клиентов, Вам предоставляют возможность одновременного использования максимум 5 устройств-клиентов, иногда даже с ограниченным трафиком. В случае с Персональным VPN-сервером, количество устройств-клиентов зависит от Вашего желания, и ограничивается только ресурсами самого сервера.

* Так как многие Vpn-сервисы в какой-либо форме производят сбор данных о своих пользователях, Персональный Vpn-сервер – это ещё и защита от утечек информации.

- Если у Вас уже есть работающий VDS или выделенный сервер (отвечающий необходимым параметрам), то стоимость настройки составит - всего 500 руб.

Windows 10 Hyper-V разрешает использовать для виртуальной сети собственное преобразование сетевых адресов (NAT).

В этом руководство рассматриваются следующие темы:

Создание сети NAT
Подключение существующей виртуальной машины к новой сети
Проверка правильности подключения виртуальной машины

Юбилейное обновление Windows 10 или более поздняя версия
Hyper-V включен (инструкции см. здесь)

Примечание. Сейчас можно создать только одну сеть NAT для узла. Дополнительные сведения о реализации, возможностях и ограничениях NAT для Windows (WinNAT) см. в блоге, посвященном возможностям и ограничениям WinNAT.

Обзор NAT

NAT предоставляет виртуальной машине доступ к сетевым ресурсам с помощью IP-адреса и порта главного компьютера через внутренний виртуальный коммутатор Hyper-V.

Преобразования сетевых адресов (NAT) — это сетевой режим, предназначенный для экономии IP-адресов за счет сопоставления внешнего IP-адреса и порта с гораздо большим набором внутренних IP-адресов. По сути, NAT использует таблицу потоков для маршрутизации трафика с внешнего IP-адреса (адреса узла) и номера порта на правильный внутренний IP-адрес, связанный с конечной точкой в сети (виртуальной машиной, компьютером, контейнером и т. д.).

Кроме того, NAT позволяет нескольким виртуальным машинам размещать приложения, которым требуются одинаковые (внутренние) порты связи, сопоставляя их с уникальными внешними портами.

По всем этим причинам NAT часто применяется в технологии контейнеров (см. статью Сетевые подключения контейнеров).

Создание виртуальной сети NAT

Давайте рассмотрим настройку новой сети NAT.

Откройте консоль PowerShell от имени администратора.

Создайте внутренний коммутатор.

Найдите индекс интерфейса созданного виртуального коммутатора.

Этот индекс интерфейса можно определить, выполнив команду Get-NetAdapter

Выходные данные должны иметь следующий вид:

Внутренний коммутатор будет иметь такое имя, как vEthernet (SwitchName) , и описание интерфейса Hyper-V Virtual Ethernet Adapter . Запишите его ifIndex для использования на следующем шаге.

Настройте шлюз NAT с помощью New-NetIPAddress.

Ниже приведена общая команда:

Чтобы настроить шлюз, вам потребуется некоторая информация о сети:

IPAddress — "NAT Gateway IP" задает IP-адрес шлюза NAT в формате IPv4 или IPv6.
Общая форма имеет вид a.b.c.1 (например, 172.16.0.1). Хотя последняя позиция необязательно должна быть равна 1, обычно используется именно это значение (в зависимости от длины префикса).

Общий IP-адрес шлюза имеет значение 192.168.0.1.

PrefixLength — "NAT Subnet Prefix Length" определяет размер локальной подсети NAT (маску подсети). Длина префикса подсети является целым числом от 0 до 32.

Значение 0 соответствует всему Интернету, а значение 32 — всего одному IP-адресу. Обычно используются значения в диапазоне от 24 до 12 в зависимости от того, сколько IP-адресов необходимо подключить к NAT.

Общее значение PrefixLength равно 24. Это маска подсети 255.255.255.0.

InterfaceIndex: ifIndex — это индекс интерфейса виртуального коммутатора, который вы определили на предыдущем шаге.

Выполните следующую команду, чтобы создать шлюз NAT:

Настройте сеть NAT с помощью New-NetNat.

Ниже приведена общая команда:

Чтобы настроить шлюз, потребуется указать информацию о сети и шлюзе NAT:

Name — NATOutsideName описывает имя сети NAT. Оно используется для удаления сети NAT.

InternalIPInterfaceAddressPrefix — "NAT subnet prefix" задает описанные ранее префикс IP-адреса шлюза NAT и длину префикса подсети NAT.

Общая форма имеет вид a.b.c.0/NAT Subnet Prefix Length.

Учитывая приведенные выше данные, для этого примера мы используем 192.168.0.0/24.

В рамках данного примера выполните следующую команду для настройки сети NAT:

Поздравляем! Теперь у вас есть виртуальная сеть NAT. Чтобы добавить виртуальную машину в сеть NAT, выполните эти инструкции.

Соединение с виртуальной машиной

Чтобы подключить виртуальную машину к новой сети NAT, подключите внутренний коммутатор, созданный на первом шаге в разделе Настройка сети NAT, к виртуальной машине с помощью меню параметров виртуальной машины.

Так как служба WinNAT сама по себе не выделяет и не назначает IP-адреса конечным точкам (например, виртуальной машины), вам потребуется сделать это вручную в виртуальной машине, т. е. задать IP-адреса в диапазоне внутреннего префикса NAT, задать IP-адрес шлюза по умолчанию, указать данные DNS-сервера. Единственной оговоркой является наличие подключения конечной точки к контейнеру. В этом случае служба HNS выделяет и использует службу HCS для назначения IP-адреса, IP-адреса шлюза и сведений о DNS непосредственно контейнеру.

Пример конфигурации. Подключение виртуальных машин и контейнеров к сети NAT

Чтобы подключить несколько виртуальных машин и контейнеров к одной сети NAT, необходимо убедиться, что внутренний префикс подсети NAT имеет размер, достаточный для охвата диапазонов IP-адресов, назначенных различными приложениями или службами (например, Docker для Windows и компонент контейнеров Windows — HNS). Для этого потребуется назначить IP-адреса на уровне приложения, а также выполнить сетевую настройку или настройку вручную силами администратора, исключив повторное использование существующих назначений IP-адресов в том же узле.

Docker для Windows (для виртуальных машин Linux) и компонент контейнеров Windows

Приведенное ниже решение позволит Docker для Windows (виртуальным машинам Linux с контейнерами Linux) и компоненту контейнеров Windows совместно использовать общий экземпляр WinNAT с помощью отдельных внутренних коммутаторов vSwitch. Будет работать подключение между контейнерами Linux и Windows.

Пользователь подключил виртуальные машины к сети NAT через внутренний коммутатор vSwitch с именем VMNAT и теперь хочет установить компонент "Контейнеры Windows" с подсистемой Dосker.

Docker или HNS назначит IP-адреса контейнерам Windows, а администратор назначит IP-адреса виртуальным машинам из разностного набора.

Пользователь установил компонент "Контейнеры Windows" с работающей подсистемой Docker и хочет подключить виртуальные машины к сети NAT.

В итоге вы должны получить два внутренних коммутатора виртуальных машин и один общий для них коммутатор NetNat.

Несколько приложений, использующих одну систему NAT

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

В качестве примера мы рассмотрим сосуществование Docker 4 Windows — Docker Beta — Linux VM и компонента контейнеров Windows на одном узле. Эта процедура может быть изменена.

C:> net stop docker

Stop Docker4Windows MobyLinux VM

PS C:> Get-ContainerNetwork | Remove-ContainerNetwork -force.

PS C:> Get-NetNat | Remove-NetNat.
Позволяет удалить все ранее существовавшие сети контейнера (т. е. удаляется vSwitch, NetNat и выполняется очистка).

New-ContainerNetwork -Name nat -Mode NAT –subnetprefix 10.0.76.0/24 (эта подсеть используется для компонента контейнеров Windows) Создает внутренний vSwitch с именем nat.
Позволяет создать сеть NAT с именем "nat" и префиксом IP-адреса 10.0.76.0/24.

Remove-NetNAT
Позволяет удалить сети NAT с именами nat и DockerNAT (сохраняя внутренние коммутаторы Vswitch).

New-NetNat -Name DockerNAT -InternalIPInterfaceAddressPrefix 10.0.0.0/17 (создает более крупную сеть NAT для совместного использования D4W и контейнерами)
Позволяет создать сеть NAT с именем DockerNAT и увеличенным префиксом 10.0.0.0/17.

Run Docker4Windows (MobyLinux.ps1)
Позволяет создать внутренний vSwitch DockerNAT.
Позволяет создать сеть NAT с именем DockerNAT и префиксом 10.0.75.0/24.

Net start docker
Docker использует пользовательскую сеть NAT по умолчанию для подключения к контейнерам Windows.

В конце вы должны получить два внутренних коммутатора vSwitch — один с именем DockerNAT, другой с именем nat. При выполнении Get-NetNat выводится только одна подтвержденная сеть NAT (10.0.0.0/17). IP-адреса для контейнеров Windows назначаются сетевой службой узлов Windows (HNS) (HNS) из подсети 10.0.76.0/24. В соответствии с имеющимся сценарием MobyLinux.ps1 IP-адреса для Docker 4 Windows назначаются из подсети 10.0.75.0/24.

Диагностика

Несколько сетей NAT не поддерживается.

В этом руководстве предполагается, что других NAT на узле нет. Приложениям или службам необходимо использовать NAT, и они могут создать ее в процессе установки. Поскольку Windows (WinNAT) поддерживает только один внутренний префикс подсети NAT, при попытке создать несколько NAT система переходит в неизвестное состояние.

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

Если NAT уже существует, удалите ее.

Убедитесь, что для приложения или компонента (например, для контейнеров Windows) имеется всего один "внутренний" vmSwitch. Запишите имя vSwitch.

Проверьте, есть ли частные IP-адреса (например, IP-адрес шлюза NAT по умолчанию обычно имеет значение x.y.z.1) старого NAT, по-прежнему назначенные адаптеру.

Если используется старый частный IP-адрес, удалите его.

Перезагрузите операционную систему перед выполнением последующих команд ( Restart-Computer )

В прошлом году мы рассказывали о Storage Spaces Direct — программно-определяемом хранилище в Windows Server 2016. Сегодня поговорим еще об одной новинке Microsoft, на этот раз из области программно-определяемых сетей (SDN). Network Controller — это служба управления сетевой инфраструктурой в Windows Server 2016.

Откуда пошли виртуальные сети?

VLAN. Первые виртуальные сети появились в 1998 году. Это были локальные виртуальные сети VLAN, работающие по протоколу IEEE 802.1Q. Технология позволяет разделять одну L2-сеть на множество логических L2-сетей. Но VLAN имеет ограничение, которое оказалось существенным с ростом количества сетей: максимальное количество соединений на одной L2-сети — 4096. Для его преодоления производители начали разрабатывать новые протоколы с большей масштабируемостью, например: IEEE 802.1ad и IEEE 802.1ah. Мы не будем останавливаться на них подробно и пойдем дальше.

VXLAN, STT и NVGRE. В 2011 году компании VMware, Arista и Cisco выпускают протокол VXLAN, позволяющий создавать до 16 миллионов логических L2-сегментов в одной сети. Параллельно с ними Microsoft создает протокол NVGRE похожей спецификации, который начинает развиваться в Windows Server 2012. Компания Nicira предлагает протокол STT. Вопрос с ограниченной масштабируемостью решен, можно создавать сколь угодно много сетей. С ростом сетей инфраструктура становится сложной в управлении, и появляется необходимость централизованной консоли для настройки виртуального и физического оборудования. Так возникает концепция программно-определяемых сетей (SDN) с централизованным управлением сетевой инфраструктурой.

SDN. Подход к управлению сетью при помощи унифицированных программных средств. Одной их первых технологию SDN представила компания Nicira. После покупки Nicira компания VMware создает продукт VMware NSX, используя протокол VXLAN.

В 2013 году Microsoft предлагает свою версию программно-определяемой сети в редакции Windows Server 2012R2 на базе протокола NVGRE. У протокола NVGRE было несколько недостатков:

управление виртуальными сетями в Windows Server 2012R2 осуществлялось только через Virtual Machine Manager (VMM). Он был точкой хранения всех конфигураций виртуальной инфраструктуры и единой точкой отказа.
производители оборудования в качестве основного протокола использовали VXLAN, и лишь немногие внедрили поддержку NVGRE.

Windows Server 2016: Network Controller

Network Controller — единая точка управления и мониторинга для всех физических и виртуальных сетей домeна. С помощью него настраивается IP-подсети, VLAN, маршрутизаторы и межсетевые экраны. NС хранит информацию о топологии сети, балансирует трафик и задает правила NAT.

Глоссарий

Virtual Network Management — служба управления виртуализованными сетями.
Software Load Balancer Management — служба балансировки трафика и правил NAT.
Firewall Management — служба настройки межсетевых экранов и листов контроля доступа к ВМ.
RAS Gateway Management — служба организации VPN-туннелей.
iDNS — служба создания виртуальных DNS-серверов.

Backend Network (provider addresses, PA) — сеть с провайдерскими адресами. Здесь создаются виртуальные туннели и проходит трафик.
Management Network — сеть управления, через нее проходит трафик между компонентами SDN.
VM network (customer addresses, CA) — виртуализованная сеть, к которой подключены виртуальные машины.
Transit Network — транзитная сеть. По ней идет обмен трафиком между BGP и SLB Multiplexer/Gateway. По транзитной сети публикуются маршруты на BGP.

Azure VFP Switch Extension — расширение свитча Hyper-V. Добавляет виртуальному свитчу функционал L3-коммутатора. Включает в себя distributed load balancer(DLB) и Distributed firewall (DFW).
Distributed load balancer — балансировщик трафика.
Distributed firewall — межсетевой экран, отвечает за выполнение правил доступа к ВМ.
Distributed router (vSwitch) — виртуальный маршрутизатор.
NC Host Agent — получает от NC информацию о виртуальных сетях и правилах Firewall.
SLB Host Agent — получает от NC правила балансировки.

SLB multiplexer (MUX) — виртуальные машины Windows Server с ролью Software Load Balancing. На них содержится информация о правилах балансировки трафика. MUX публикуют маршруты на BGP и обрабатывают входящие пакеты.
Gateway — виртуальный шлюз.

В целом принцип архитектуры Network Controller такой: узлы контроллера размещаются на отдельных ВМ, а службы маршрутизации, балансировки трафика и межсетевого экрана — на серверах виртуализации.

Архитектура Network Controller.

Network Controller создан на базе программного коммутатора Open vSwitch. Этот коммутатор также используется в программно-определяемых сетях VMWare NSX и OpenStack Neutron. Он поддерживает протокол управления OVSDB (Open vSwitch Database), отвечающий за обмен информацией между сетевым оборудованием.

Разберем, как работает Network Controller. Серверы, виртуальные машины, виртуальные коммутаторы гипервизоров регистрируются в NC. После регистрации и настройки серверы устанавливают соединение с Network Controller и получают от него всю необходимую информацию о сетях виртуальных машин, правилах балансировки и VPN-туннелях.

Виртуальные сети на хостах подключены к виртуальному коммутатору Hyper-V с расширением Azure VFP Switch Extension. Через него происходит управление виртуальными портами, к которым подключены ВМ:

включение и отключение портов;
управление полосой пропускания в обе стороны;
назначение приоритетов пакетам по классам (COS);
назначение целей: ведение статистики и управление ACL на портах виртуального коммутатора.

Службы Network Controller

Разберем подробно, какие службы входят в Network Controller и чем они управляют.

Virtual Network Management. Это служба создания виртуальных сетей и управления ими. Она управляет виртуальными коммутаторами Hyper-V и виртуальными сетевыми адаптерами на виртуальных машинах. Virtual Network Management содержит настройки виртуальной сети, которые применяются другими службами Network Controller.

Firewall Management. Эта служба упрощает организацию межсетевого экранирования: не нужно настраивать межсетевые экраны на каждой ВМ вручную и запоминать конфигурации. Network Controller хранит все настройки Access Control Lists (ACL) для виртуальных машин и сетей. Distributed Firewall на хостах запрашивает у него информацию и применяет правила к нужным сетям и виртуальным машинам. Настройка на стороне виртуальных машин не требуется.

Ниже схема принципа работы межсетевого экранирования в Network Controller. На ней Northbound – интерфейс, через который производится управление Network Controller с использованием REST API. Southbound служит для связи с сетевыми устройствами, SLB-мультиплексорами, шлюзами и серверами, для сетевого обнаружения и других служб. Шлюзы определяют, для какой виртуальной сети требуется построить туннели. Затем они пересылают пришедшие пакеты по туннелю на серверы с виртуальными машинами, подключенными к нужной виртуальной сети.

Так устроена служба межсетевого экранирования в Network Controller.

Software Load Balancer Management. Служба работает на уровне виртуализованных сетей и балансирует трафик на уровне L4. Балансировка трафика происходит с помощью служебных виртуальных машин SLB Multiplexer (MUX) и BGP-маршрутизаторов. На один NC можно сделать 8 MUX. От Network Controller MUX получают правила маршрутизации. Мультиплексоры анонсируют маршруты /32 для каждого VIP через BGP-маршрутизаторы.

Пример

На BGP-маршрутизатор приходит пакет для определенного виртуального IP-адреса.
BGP-маршрутизатор проверяет, какой у пакета следующий узел. В данном случае это MUX.
По таблицам правил балансировки, полученным от Network Controller, MUX определяет назначение пакета: виртуализованную сеть, хост и виртуальную машину.
Далее MUX формирует VXLAN пакет и отправляет его хосту в сеть Backend.
Хост принимает пакет и передает это виртуальному коммутатору (vSwitch), который определяет виртуальную машину для получения пакета.
Пакет декапсулируется, анализируется и отправляется виртуальной машине.
Виртуальная машина обрабатывает пакет. Адрес отправителя не изменяется после прохождения пакета через MUX. Поэтому виртуальная машина не видит за ним MUX балансировщика и считывает, что пакет пришел напрямую из интернета. Такая балансировка называется прозрачной (transparent load balancing).
ВМ посылает ответ.
Виртуальный коммутатор на хосте определяет, что это ответ на пакет, пришедший с балансировщика, и отправляет его обратно в Интернет. Причем не по той же цепочке, а переписывает адрес отправителя на IP балансировщика и отправляет его сразу в Интернет. Данный подход называется Direct Server Return (DSR). Это значительно ускоряет процесс обработки пакетов.

Балансировка трафика в Network Controller.

В Windows Server 2016 правила NAT теперь также задаются через Software Load Balancer Management. Network Controller знает, для какой сети организован NAT. MUX содержит информацию о хостах и виртуальных машинах, подключенных к сети, для которой организуется NAT.
NAT в Network Controller реализован путем балансировки трафика для группы из одного хоста. На данный момент поддерживается балансировка только TCP- и UDP-трафика.

RAS Gateway Manager. Эта служба создания VPN-туннелей для связи облачной инфраструктуры с физической. В Network Controller можно строить VPN любым удобным способом:

через IPsec, который теперь работает и с IKEv1, и с IKEv2;
создавать SSTP-туннели;
создавать GRE-туннели.

Служба создания VPN-туннелей RAG Gateway Management.

iDNS: Internal DNS. Служба позволяет создавать виртуальные DNS-сервера. На данный момент существует как реализация концепции и поддерживает работу только с одной DNS-зоной, что неудобно для клиентов. Мультитенантный режим будет добавлен в следующей редакции Windows Server 2016.

Рассмотрим, как работает служба iDNS. Организуется DNS-зона, в которой будут создаваться клиентские зоны. Настраивается Network Controller: указывается обслуживаемая DNS-зона и вышестоящие DNS-серверы, которые будут обрабатывать запросы, приходящие от клиентов.
После настройки iDNS Network Controller распространяет информацию по хостам. Служба iDNS proxy на хостах обрабатывает DNS-запросы от клиентов. Работает это так:

Клиент посылает запрос на разрешение имени.
iDNS-proxy смотрит, обслуживает ли он запросы, исходящие из данной виртуальной сети. Это определяется по первичному DNS-суффиксу у сетевого адаптера. Он должен совпадать с зоной, обслуживаемой iDNS. Если iDNS-proxy обслуживает запросы из этой сети, то отправляет запрос вышестоящему DNS-серверу.
DNS-сервер проверяет, относится ли запрос к внутренним зонам. Если клиент пытается разрешить внутреннее имя, то DNS-сервер его обрабатывает. Если нет – отправляет запрос дальше.

Принцип работы службы iDNS в Network Controller.

Пример

Есть виртуальная сеть, для которой доступна служба iDNS. При подключении виртуальных машин к этой сети, в корневой зоне DNS, указанной при настройке, будет создана зона с именем, совпадающим с ID виртуальной сети. В этой зоне будут создаваться А-записи для виртуальных машин.

А-записи виртуальных машин в службе iDNS.

Все, о чем мы подробно рассказали выше, — это службы Network Controller, которые вошли в официальный релиз Windows Server 2016. Нам также удалось протестировать службы, вошедшие в Technical Preview, но изъятые из релиза. Одна из таких служб — Canary Network Diagnostics для мониторинга производительности сети, сбора статистики по работе физического и виртуального сетевого оборудования и обнаружения ошибок. Дополнения должны войти в релиз Windows Server 2016R2, и о них мы поговорим в будущем.

В следующей части мы расскажем, как развернуть Network Controller и о некоторых интересных «подводных камнях», которые мы обнаружили в ходе тестирования.

Читайте также: