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

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

Получилось так, что на днях пришлось побороться с проблемой одного из моих клиентов. Сервер клиента расположен в польском Дата-центре 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. То, чего и добивались. Все работает.


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

Спасибо за внимание.,

Настройка сетевых интерфейсов виртуальных машин в VirtualBox

VirtualBox позволяет виртуальным машинам использовать сетевые подключения хостовой системы, а также создавать виртуальные сети для виртуальных машин.

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

Процедура настройки сетевых интерфейсов хорошо описана в фирменной инструкции пользователя Oracle VM VirtualBox® на английском языке.

Для каждой виртуальной машины можно эмулировать до 4-х сетевых адаптеров. Каждый из сетевых адаптеров может работать в одном из 6 режимов:

• Не подключен. В данном режиме адаптер присутствует в гостевой системе, но ведет себя так, как будто сетевой кабель в него не включен.
• NAT. В данном режиме адаптер использует сетевые настройки основной системы при взаимодействии с сетью физического узла и прочими внешними сетями. Сетевая подсистема VirtualBox транслирует IP-трафик с исходным IP-адресом виртуальной машины в трафик с исходным адресом сетевого адаптера хостовой системы (трансляция сетевых адресов, Network Address Translation). Реализация NAT в VirtualBox имеет определенные ограничения, связанные с поддержкой протокола ICMP, широковещательного UDP -трафика и технологий виртуальных частных сетей. Этот режим используется по умолчанию.
• Сетевой мост. В данном режиме сетевой адаптер ВМ подключается к сетевому адаптеру хостовой системы и обрабатывает сетевые пакеты непосредственно в обход сетевого стека хостовой системы ( адаптер хостовой системы работает с адаптером ВМ в режиме моста ).
• Внутренняя сеть. Сетевые адаптеры Виртуальных машин объединяются между собой в изолированный сегмент сети.
• Виртуальный адаптер хоста. Сеть объединяющая в данный сегмент хостовую систему и виртуальные машины, включенные в данный сегмент. Для этого режима VirtualBox создает в хостовой системе программный сетевой интерфейс и устанавливает на нем IP-адрес.
• Универсальный драйвер. Пользователь сам выбирает драйвер сетевого адаптера, который может быть входит в состав VirtualBox или загружается с пакетом дополнений к VirtualBox. На данный момент существует 2 драйвера реализующих 2 режима работы виртуального адаптера:
• UDP Туннель. Режим для связи виртуальных машин, запущенных на различных хостах. Работает над существующей сетевой инфраструктурой.
• VDE (Виртуальный Распределенный Ethernet). Этот режим может быть использован для подключения распределенных виртуальных машин к Виртуальному коммутатору Ethernet на Linux или FreeBSD хостах.

Для каждого из 4-х сетевых адаптеров виртуальной машины можно выбрать один из 5 драйверов эмулирующих реальные сетевые адаптеры различных производителей оборудования или драйвер Virtio-net, являющийся частью open-source KVM проекта. Драйвер Virtio-net позволяет избежать сложности эмуляции сетевого оборудования и позволяет повысить производительность сети. Linux ядро гостевой системы версии 2.6.25 и старше может поддерживать Virtio-net адаптер. Для гостевых систем на Windows 2000, XP и Vista драйвер для адаптера Virtio-net можно скачать с сайта KVM проекта.

Драйвер сетевого адаптера Intel PRO/1000 T Srver (82543GC) входит в состав дистрибутива Windows XP и в гостевой OS Windows XP не требуется дополнительная установка драйверов.

Включение vRSS на виртуальном сетевом адаптере

• 
  09/05/2018
• Чтение занимает 2 мин

В этой статье

Применяется к: Windows Server (Semi-Annual Channel), Windows Server 2016Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

Для виртуальных RSS-каналов ( vRSS ) требуется ( Поддержка очередь виртуальной машины VMQ ) из физического адаптера.Virtual RSS (vRSS) requires Virtual Machine Queue (VMQ) support from the physical adapter. Если функция VMQ отключена или не поддерживается, виртуальное масштабирование на стороне приема отключено.If VMQ is disabled or is not supported then Virtual Receive-side scaling is disabled.

Дополнительные сведения см. в разделе Планирование использования vRSS.For more information, see Plan the Use of vRSS.

Включение vRSS на виртуальной машинеEnable vRSS on a VM

Используйте следующие процедуры для включения vRSS с помощью Windows PowerShell или Device Manager.Use the following procedures to enable vRSS by using either Windows PowerShell or Device Manager.

• Диспетчер устройствDevice Manager
• Windows PowerShellWindows PowerShell

Диспетчер устройствDevice Manager

Эту процедуру можно использовать для включения vRSS с помощью Device Manager.You can use this procedure to enable vRSS by using Device Manager.

Примечание

Первый шаг в этой процедуре относится к виртуальным машинам под Windows 10 или Windows Server 2016.The first step in this procedure is specific to VMs that are running Windows 10 or Windows Server 2016. Если виртуальная машина работает под управлением другой операционной системы, можно открыть Device Manager, сначала откройте панель управления, а затем найдите и откройте Device Manager.If your VM is running a different operating system, you can open Device Manager by first opening Control Panel, then locating and opening Device Manager.

1. На панели задач виртуальной машины в поле введите текст для поискавведите устройство.On the VM taskbar, in Type here to search, type device.

2. В результатах поиска щелкните Device Manager.In the search results, click Device Manager.

3. В Device Manager щелкните, чтобы развернуть Сетевые адаптеры.In Device Manager, click to expand Network adapters.

4. Щелкните правой кнопкой мыши сетевой адаптер, который нужно настроить, и выберите пункт Свойства.Right-click the network adapter you want to configure, and then click Properties.

   Откроется диалоговое окно Свойства сетевого адаптера.The network adapter Properties dialog box opens.

5. В окне Свойствасетевого адаптера перейдите на вкладку Дополнительно .In network adapter Properties, click the Advanced tab.

6. В свойствепрокрутите вниз до и щелкните масштабирование на стороне приема.In Property, scroll down to and click Receive-side scaling.

7. Убедитесь, что выбран параметр в поле значение включено.Ensure that the selection in Value is Enabled.

8. Нажмите кнопку ОК.Click OK.

Примечание

На вкладке Дополнительно некоторые сетевые адаптеры также отображают число очередей RSS, которые поддерживаются адаптером.On the Advanced tab, some network adapters also display the number of RSS queues that are supported by the adapter.

Windows PowerShellWindows PowerShell

Используйте следующую процедуру, чтобы включить vRSS с помощью Windows PowerShell.Use the following procedure to enable vRSS by using Windows PowerShell.

1. На виртуальной машине откройте Windows PowerShell.On the virtual machine, open Windows PowerShell.

2. Введите следующую команду, убедившись, что значение адаптернаме для параметра -Name заменяется именем сетевого адаптера, который требуется настроить, и нажмите клавишу ВВОД.Type the following command, ensuring that you replace the AdapterName value for the -Name parameter with the name of the network adapter that you want to configure, and then press ENTER.

   Enable-NetAdapterRSS -Name "AdapterName"
   

   Совет

   Кроме того, для включения vRSS можно использовать следующую команду.Alternately, you can use the following command to enable vRSS.

   Set-NetAdapterRSS -Name "AdapterName" -Enabled $True
   

Дополнительные сведения см. в разделе команды Windows PowerShell для RSS и vRSS.For more information, see Windows PowerShell Commands for RSS and vRSS.

Wmware workstation настройка сети в виртуальных машинах

Всем привет, сегодня хочу продолжить тему по настройке домашней виртуальной инфраструктуры на Wmware workstation. И сегодня мы рассмотрим как производится настройка сети Wmware workstation, для виртуальных машин. Какие виды сети там бывают и для чего каждый вид используется, понимание данных догматов, очень сильно расширит ваши возможности в плане применения данного гипервизора.

И так в предыдущий раз мы с вами создали виртуальную машину и установили на нее  операционную систему. Теперь предположим, что вы создаете еще одну виртуальную машину и хотите организовать домен Active Directory, но для этого нужно настроить сеть Wmware workstation. Рассмотрим где это делается и какие есть веды сети.

Виды сетей Wmware workstation

И так какие виды сетей бывают в данном виде виртуализации:

• Мост > подключение непосредственно к физической сети. bridge как его еще называют объединяет несколько портов в виртуальный коммутатор, по сути вы увидите в виртуалке ваш сетевой интерфейс.
• NAT > по сути создается несколько отдельных сетевых интерфейсов, через которые ваша виртуальная машина получает интернет, физический адаптер натирует виртуальный адаптер.
• Только для узла > частная сеть только с узлом, это по сути закрытая локальная сеть которую настраивает Wmware workstation, между физическим компьютером и виртуальной машиной.
• Другое. указать виртуальную сеть > по сути закрытая изолированная сеть
• Сегмент локальной сети > изолированная сеть, создаваемая вами лично, трафик бегает только между виртуалками.

Как настроить сеть

Для этого заходим в параметры виртуальной машины и выбираете новый или существующий сетевой адаптер. По умолчанию стоит NAT, в данной настройке встроенный сервер DHCP, выдает вам внутренний ip адрес. Так же при установке VMware, у вас на физическом хосте создается два сетевых виртуальных интерфейса, через которые и проксируется трафик.

Вот настройки network интерфейса vm машинке:

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

• ip адрес 192.168.145.1, как видите они из одного сегмента 145. Что позволяет вам получать интернет в виртуалке.

Настройки NAT можно посмотреть Правка > Редактор виртуальной сети

В данном редакторе можно задать и посмотреть параметры NAT

Щелкаем Параметры NAT, тут видно шлюз 192.168.145.2, при желании его можно заменить на нужный вам. Обратите внимание можно даже пробрасывать порты в нужную машинку.

посмотреть параметры DNS. По умолчанию задаются автоматически, но можно задать и вручную.

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

Давайте сделаем трассировку из нашей vm и посмотрим прохождение трафика. Как видите первым хопом идет шлюз, а дальше уже шлюз физического интерфейса, куда трафик попадает через тот виртуальный интерфейс с ip 192.168.145.1.

Режим моста

Вот параметры моего сетевого адаптера на физическом компьютере, как видите ip адрес 192.168.0.77 и шлюз 192.168.0.1

А вот настройки сети на виртуальной машине Wmware workstation 192.168.0.11 и с таким же основным шлюзом. Из чего можно сделать вывод, что настройка сети, произведена в одном сегменте и если бы у меня еще был ноутбук подключенный через WiFi, то я бы с него имел доступ на прямую к виртуальной машине, так как они были бы в одной локальной сети. Единственной, что все бы шло через физический адаптер компьютера где настроена виртуализация.

Только для узла

Продолжаем сетевые настройки VMWare Workstation и устанавливаем значение Только для узла. И так теперь ваша virtual machine получает ip адрес из локальной сети в которой только она и ваш физический компьютер.

На фихическом хосте.

Другое: указать виртуальную сеть

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

Сегмент локальной сети

Изолированная сеть, трафик между виртуальными машинами бегает внутри виртуального коммутатора и никуда более. Создается очень просто в настройках виртуалки. Жмем Сегменты локальной сети > Добавить. Задаем имя у меня пусть это будет как название сайта pyatilistnik.org.

Теперь выбираем созданный сегмент, подойдет для доменов active directory например.

Итог

Как видите Wmware workstation в данный момент 12 версия, очень мощный инструмент для организации различного уровня сложности и задачи сетей, думаю сценарии вы придумаете сами.

Материал сайта pyatilistnik.org

Настройка сетевого моста в VirtualBox

Использованный мною, на момент написания статьи, релиз VirtualBox 3.1.6 rev59331. Скачать «машинку» можно с сайта SUN (ныне Oracle VM VirtualBox)
Как установить эту систему виртуализации описывать не буду, разберётся даже новичок.

Самое интересное даже не в установке самой желаемой OS. Процесс установки гостевой системы прост и не требует от пользователя дополнительных усилий. При создании виртуальной машины необходимо выбрать тип устанавливаемой гостевой системы, определить количество выделяемой ей оперативной памяти и создать виртуальный диск фиксированного размера или динамически расширяющийся по мере его заполнения в гостевой системе. Дальнейший процесс установки происходит так же, как и в других платформах виртуализации. Настройки можно изменить после установки гостевой OS, нажав Свойства для выделенной Виртуальной машины.

 
Все нюансы настроек подробно мне встречались в разных статьях, кроме настройки сети. Жмём в правом окне СЕТЬ. Открывается следующее окно. Здесь можно настроить четыре сетевых адаптера.
 

Что касается NAT, то здесь всё предельно ясно и настраивается автоматом. Ваш виртуальный компьютер оказывается за виртуальным шлюзом. В инет попадает сразу. Правда есть парочка НО… 🙂 Первое но… провайдер раздаёт инет с использованием MAC- адресов и фиксированными IP… конфликт. Второе но… в локальной сети(если она есть) машину не видно… можно правда подключится к локалке через VPN … если есть VPN сервер. :))) На крайний случай подойдёт RDP.

С настройкой внутренней сети проблем тоже не возникло. Запустилась сразу. О назначении писать не буду, каждый сам решит зачем она ему.
 
Больше всего пришлось повозится с настройкой Сетевого Моста! С чего начать. Есть ещё и альтернативный способ настройки сетевого моста для виртуальной машины в VirtualBox.
После установки VirtualBox в Сетевых подключениях появился виртуальный сетевой адаптер. На следующем снимке он выделен.

Правда скрин более позднего состояния, а именно после объединения интерфейсов в сетевой мост, но лень разъединять было, сори.

Но прежде чем объединять реальный сетевой адаптер и виртуальный, нужно настроить виртуальный.
Для этого заходим в окне VirtualBox: Файл-Настройки.

Выделяем сетевой адаптер и жмём отвёртку(настройка).

Забиваем IP адрес отличный от реального, из другой подсети.
У реального сетевого адаптера 192.168.16.103, маска 255.255.255.0 У виртуального, например 10.0.1.1, маска 255.255.255.0
 

Адрес указанный здесь сразу пропишется в сетевых настройках виртуального сетевого адаптера основной OS. Проверить можно в Окне Сетевые подключения, нажав на свойства для соответствующего подключения. Пробывал напрямую вбивать, потом при запуске гостевой OS выскакивает ошибка сетевого адаптера.

Теперь осталось совсем чуть-чуть.

Объединяем физический и виртуальный сетевые адаптеры в Сетевой мост. Для этого заходим в сетевые подключения, выделяем соответствующие сетевые адаптеры с помощью CTRL, жмём правой клавишей мыши, выбираем пункт создания сетевого моста. Малость ждём и вуаля! Сетевой мост и значок Сетевого шлюза появились. Проверяем наличия интернета на основной машине, обязательно должен быть. Дальше запускаем виртуальную машину и настраиваем там сетевой адаптер. Так как у меня в сети стоит DHCP сервер, ставим автоматически получаемые настройки. Хотите вручную настроить, адрес должен быть из той же подсети, что и у физического адаптера!
Ну вроде всё. Проверяем наличие инета.

Как видите всё получилось. Сетевые ресурсы подключаем как в обычной OS.
 

Компьютер QWE-PC — виртуальный. В принципе при настройки VirtualBox сложностей не возникало, всё интуитивно понятно, плюс всплывающие подсказки. Удачи! 🙂

Hyper v сетевой адаптер нет подключения

В этой статье, мы рассмотрим пример организации подключения к Интернету на виртуальной машине Hyper-V. Хостовая ОС (это ОС сервера Hyper-V) может быть подключена к интернету через физический адаптер или беспроводное подключение Wi-Fi.

Итак, предполагаем, что вы уже создали виртуальную машину Hyper-V и теперь нам нужно настроить виртуальный коммутатор, к которому она будет подключена. Есть три типа виртуальных коммутаторов Hyper-V:

1. External (внешний): – этот коммутатор используется для подключения виртуальных машин к внешней сети и Интернету. Хост и виртуальная машина при этом находятся в одной сети. Если хост имеет несколько сетевых адаптеров, то для виртуальных машин можно настроить несколько сетей.
2. Internal (внутренний): – этот тип коммутатора используется для создания внутреннего сетевого соединения только между виртуальными машинами и гипервизором Hyper-V.
3. Private (частный): — данный тип коммутатора используется для создания сетевого соединения только между виртуальными машинами.

Проводное подключение к Интернету

Создадим виртуальный коммутатор. Мы будем использовать его для подключения к физическому сетевому адаптеру Ethernet сервера Hyper-V. Откройте консоль управления Hyper-V. В меню действий выберите пункт Virtual Switch Manager.

В качестве типа коммутатора выберите External и нажмите кнопку Create Virtual Switch.

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

Затем откройте настройки ВМ, которой вы хотите предоставить доступ в Интернет. В разделе Network Adapter выберите, что данная ВМ подключена к созданному нами ранее виртуальному коммутатору.

В моем случае я подключен к интернету через широкополосное соединение. Найдите это подключение в панели управления хоста Hyper-V и откройте его свойства. Перейдите на вкладку Sharing в секции Internet Connection Sharing выберите опцию Allow Other Network Users to Connect Through This Computer’s Internet Connection. В выпадающем списке выберите ваш виртуальный коммутатор, созданный ранее. Сохраните изменения.

Теперь в вашей виртуальной машине должен появится доступ в интернет.

Настройка доступа в Интеренет через WiFi подключение

В том случае, если вы подключаетесь к Интернету через беспроводное WiFi подключение, доступ гостевой ОС виртуальной машины к Интернету настраивается по аналогии.

С помощью консоли Hyper-V Manager создайте новый внешний виртуальный коммутатор. В качестве внешней сети для виртуального коммутатора выберите свой WiFi адаптер (у меня это Intel Centrino Wireless-N 1030).

Теперь в свойствах ВМ укажите, что она подключена к Интернету через данный коммутатор.

В том случае, если точка доступа, к которой вы подключаетесь работает как сервер DHCP, то виртуальная машина должно получить от сервера DHCP динамический IP адрес (он будет отличатся от адреса, полученным хостовой ОС). Теперь вы можете пользоваться подключением к интернету внутри ВМ.

Одним из вариантов организации внешнего подключения является NAT (см статью Как настроить NAT в Hyper-V 2016).

Технический блог специалистов ООО»Интерфейс»

• Главная
• Настраиваем сеть в Hyper-V.

Настраиваем сеть в Hyper-V.

• Автор: Уваров А.С.
• 21.01.2014

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

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

За настройку сетей в Hyper-V отвечает Диспетчер виртуальных коммутаторов, если мы откроем его, то увидим следующую картину:

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

Внешняя сеть

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

Как мы уже писали, основу виртуальной сети составляет виртуальный коммутатор. При создании внешней сети, Hyper-V создает виртуальный коммутатор, к которому через виртуальные сетевые адаптеры (vNIC) подключаются как виртуальные машины, так и хост. Физический адаптер отключается от хоста и по сути становится физическим портом виртуального коммутатора, через который он подключается к внешней сети.

В этом нетрудно убедиться, после создания внешней сети на хосте появляется Адаптер Ethernet для виртуальной сети Hyper-V, на который переносятся все настройки с физического адаптера.

А в свойствах физического адаптера остался только Расширяемый виртуальный сетевой коммутатор в Hyper-V.

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

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

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

Внутренняя сеть

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

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

Внутренняя сеть c NAT

Данная возможность появилась начиная с Windows Server 2016, Hyper-V Server 2016 и Windows 10. Подробнее читайте в нашей статье: Настраиваем сеть NAT в Hyper-V

Частная сеть

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

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

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

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

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

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

Архитектура Hyper-V

«Виртуальные сети» (сокращенно: «ВС») в Hyper-V называют виртуальными коммутаторами, к которым подключаются не только сетевые интерфейсы ВМ, но и физические сетевые интерфейсы сервера.

Существуют 3 вида «ВС». Схематично они представлены на рисунке ниже.

Майкрософт сравнительно недавно предусмотрела в «Windows Server 2008 R2» создание ВС «External» с изоляцией от хостовой системы. Осуществляется процесс просто. Следует убрать отметку из графы «Allow management operating system to share this network adapter».

При этом отключаются все ранее созданные подключения, и параметры прописываются для новой ВМ.

Необходимо отметить, что в Hyper-V имеется поддержка VLAN (IEEE 802.1Q).

После настройки коммутаторов, достаточно в свойствах ВМ установить отметку «Enable VLAN Identification» и указать VLAN ID.

Приятной новинкой, внедренной специалистами из Майкрософт в Виндовс Server 2008 R2, является поддержка виртуальных очередей VMQ.

Это сделало возможным перенаправление на процессор сетевого адаптера значительной доли нагрузки на обработку пакетов, которые направляются на ВМ с хостовой ОС. Сетевой адаптер с поддержкой VMQ может сам производить обработку пакетов и далее сохранять информацию в памяти ВМ.

Процедура настройки

Сложности с Hyper-V при настройке сети на виртуальной машине в основном вызваны недопониманием принципов реализации ее функционирования.

Многие хорошо знакомы с работой на «Виртуал Сервер» или «Microsoft’s Virtual PC» и привыкли к тому, что они функционируют как простые программы Виндовс.

Иными словами, приложения располагаются поверх Windows и процессы обмена данными с оборудованием осуществляются посредством ОС. Однако в Hyper-V все работает кардинально по противоположному принципу и в результате ВМ обеспечиваются прямым доступом к оборудованию сервера, то есть, минуя родительскую ОС.

Это обстоятельство накладывает некоторые нюансы на процедуру настройки доступа к сети ВМ Hyper-V из сетей.

Рассмотрим процесс на конкретном примере со следующими сетевыми параметрами: главный IP-адрес: ___.189.53.206/30; доп.адрес: ___.91.26.173/32; сервер с 2-мя интерфейсами (при этом задействован лишь 1-ый, а 2-ой отключен).

Далее всю процедуру исполняем только с LAN1.

Теперь можно приступить к настройке 2-х ВМ:

1-ая ВМ получит связь с внешним миром через сетевую карту с доступом во всемирную патину, а 2-ая послужит как коммутатор корневого сервера с виртуальным хостом.

Чтобы создать эти ВМ потребуется войти в главную консоль управления Hyper-V, запустить диспетчер виртуальных сетей.

Установить отметки, как показано на скриншоте выше для создания 1-ой ВМ. Далее создать 2-ую, как изображено на рисунке ниже.

Подготовительные мероприятия на этом этапе завершены, но перед тем как настраивать сети, следует убедиться, что все исполнено корректно. От этого зависит успешность процедуры в целом.

Важное отступление: Во время создания 1-го ВМ будут разорваны все подключения, поэтому рекомендуется предусмотреть дополнительное соединение с сервером, например, IPMI, IP-KVM либо прямой физический доступ.

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

В параметрах коммутатора (2-ой ВМ) указать IP-адрес. В результате этот ВМ на физическом сервере станет работать как шлюз.

Уже можно констатировать приятный факт, что ввод параметров сетевых интерфейсов на корневом сервере окончен.

Затем надо произвести настройки «RRAS», чтобы обеспечить перенаправление трафика к ВМ и обратно. С этой целью в меню «Диспетчера сервера» потребуется присвоить роль для «Службы политики сети и доступа».

По умолчанию она «Остановлена» и следует ее настроить.

Отобразится мастер, указания которого требуется пошагово исполнить.

Установить отметку в графу «Особая конфигурация».

Поставить галочки в два поля, как сделано на иллюстрации выше.

Клацнуть «Готово».

Кликнуть «Запустить службу». Далее проверить корректность выполненной работы через меню диспетчера.

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

Клацнуть строчку «Новый интерфейс» и применить внешний интерфейс.

Войти в закладку «Преобразование сетевых адресов (NAT)» и поставить галочки в графах, указанных на следующем скриншоте:

Перейти в закладку «Пул адресов» и указать доп. адреса. От них запросы станут поступать на внутренние адреса ВМ.

Далее еще рекомендуется добавить резервный для внутреннего адреса ВМ, как показано на рисунке ниже.

В свойствах ввести параметры сети где расположен шлюз.

В результате ВМ получила выход во всемирную паутину. Чтобы удостовериться в этом, достаточно заглянуть в меню «Центра управления сетями и общим доступом».

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

Еще убедиться в правильности можно через любой интернет-сервис.

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

А если требуется настроить сети на Линуксе, которая запущена под Hyper-V?

Многие сталкиваются с проблемой во время установки Ubuntu на ВМ Майкрософт Hyper-V. Сложность заключается в том, что Линукс просто иногда не способен при этом увидеть сетевую карту. Очевидно, что сеть в таком случае функционировать не будет.

Сложность может быть устранена следующей «уловкой»: в Параметрах ВМ указать одну из «древних» сетевых карт. ОС такую картуувидит сразу, то есть возникшая сложность устраниться быстро.

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

Заключение

Отдельные пользователи пренебрегают этапом настроек по «Преобразованию сетевых адресов (NAT)», который описан в инструкции выше. Однако этот механизм обеспечивает доступ ВМ к сети через объединение IP основной электронно-вычислительной машины с портом через внутренний коммутатор Hyper-V. В итоге приобретаются несколько следующих преимуществ:

1. Применяется внутренний коммутатор, что понижает загрузку сета электронно-вычислительной машины;
2. Несколько ВМ могут размещать программы, требующие внутренние порты связи, просто соотнося их с индивидуальными внешними интерфейсами;
3. Экономятся IP по причине сопоставления внешнего IP и порта со значительно увеличенным перечнем внутренних IP.

Рекомендуем к прочтению

Сетевые адаптеры виртуальных машин

— драйверы для Windows

• 20.04.2017
• 2 минуты на чтение

В этой статье

Сетевой адаптер виртуальной машины (ВМ) представлен в гостевой операционной системе, которая работает в дочернем разделе Hyper-V.

Примечание В Hyper-V дочерний раздел также известен как виртуальная машина.

Сетевой адаптер виртуальной машины поддерживает следующие типы виртуализации:

• Сетевой адаптер виртуальной машины может быть синтетической виртуализацией сетевого адаптера ( синтетический сетевой адаптер ). В этом случае клиент сетевой виртуальной службы (NetVSC), работающий на виртуальной машине, предоставляет этот виртуальный сетевой адаптер. NetVSC пересылает пакеты к расширяемому порту коммутатора и от него по шине виртуальной машины (VMBus).

• Сетевой адаптер виртуальной машины может быть эмулированной виртуализацией физического сетевого адаптера ( эмулированный сетевой адаптер ). В этом случае сетевой адаптер виртуальной машины имитирует сетевой адаптер Intel и использует аппаратную эмуляцию для пересылки пакетов в порт расширяемого коммутатора и обратно.

На следующем рисунке показан интерфейс между сетевыми адаптерами виртуальной машины и расширяемым коммутатором NDIS 6.40 (Windows Server 2012 R2) и более поздних версий.

На следующем рисунке показан интерфейс между сетевыми адаптерами виртуальной машины и расширяемым коммутатором для NDIS 6.30 (Windows Server 2012).

Когда пользователь запускает виртуальную машину Hyper-V, выполняются следующие шаги:

1. Граница протокола расширяемого коммутатора выдает запрос набора идентификаторов объектов (OID) OID_SWITCH_PORT_CREATE в стеке расширяемого драйвера коммутатора. Этот запрос OID уведомляет базовые расширяемые расширения коммутатора о том, что порт создается для виртуальной машины.

2. Граница протокола расширяемого коммутатора выдает запрос набора OID OID_SWITCH_NIC_CREATE в стеке расширяемого драйвера коммутатора.Этот запрос OID уведомляет базовые расширяемые расширения коммутатора о том, что сетевое соединение для сетевого адаптера виртуальной машины создается для порта виртуальной машины, который был создан ранее.

3. Когда сетевые стеки работают и привязаны к сетевому адаптеру виртуальной машины, граница протокола расширяемого коммутатора выдает запрос набора OID OID_SWITCH_NIC_CONNECT вниз по стеку расширяемого драйвера коммутатора. Этот запрос OID уведомляет базовые расширяемые расширения коммутатора о том, что сетевое соединение для сетевого адаптера виртуальной машины подключено и работает.На этом этапе расширение может проверять, вводить и пересылать пакеты на порт, который подключен к сетевому адаптеру виртуальной машины.

Когда пользователь останавливает виртуальную машину Hyper-V, выполняются следующие действия:

1. Граница протокола расширяемого коммутатора выдает запрос набора OID OID_SWITCH_NIC_DISCONNECT вниз по стеку расширяемого драйвера коммутатора. Этот запрос OID уведомляет базовые расширяемые расширения коммутатора о том, что соединение с сетевым адаптером виртуальной машины разрывается.

2. После завершения всего пакетного трафика и запросов OID, нацеленных на сетевое соединение, граница протокола расширяемого коммутатора выдает запрос набора OID OID_SWITCH_NIC_DELETE вниз по стеку расширяемого драйвера коммутатора. Этот запрос OID уведомляет базовые расширяемые расширения коммутатора о том, что подключение к сетевому адаптеру виртуальной машины было корректно разорвано и удалено.

3. Граница протокола расширяемого коммутатора выдает запрос набора OID OID_SWITCH_PORT_TEARDOWN вниз по стеку расширяемого драйвера коммутатора.Этот запрос OID уведомляет базовые расширяемые расширения коммутатора о том, что порт, который использовался для подключения сетевого адаптера виртуальной машины, отключается.

4. Граница протокола расширяемого коммутатора выдает запрос набора OID OID_SWITCH_PORT_DELETE вниз по стеку расширяемого драйвера коммутатора. Этот запрос OID уведомляет базовые расширяемые расширения коммутатора о том, что порт виртуальной машины отключен и удален.

Как включить сеть в Kali Linux Virtual Box?

H Чтобы включить сеть в Kali Linux Virtual Box , я привел эти простые советы и уловки, потому что некоторые пользователи спрашивают об этом, потому что по умолчанию некоторые из Virtual Box при попытке подключиться к Интернету могут это не может.

Если вы хотите увидеть учебник , как установить Kali Linux в Virtual Box , вы можете просмотреть здесь

Пошаговое включение сети в Kali Linux:

Это предварительный просмотр моего IP-адреса прежде чем я внесу некоторые изменения.

1. Откройте свой Kali Linux Virtual Box следующим образом. Щелкните «Устройства» , меню и выберите « Сетевые адаптеры ».

2. Теперь откроется новое окно для настройки Kali Linux Virtual Box .

3. По умолчанию сетевой адаптер подключен к NAT . Вам нужно изменить его на мостовой адаптер.

4. На следующем шаге вам нужно выбрать, к какому интерфейсу сети вы хотите подключиться. Если в вашей сети интерфейс имеет более одного (например: 2 порта LAN , 1 беспроводной и т. Д.), Он будет отображаться здесь. Просто выберите, к какому интерфейсу сети вы хотите подключиться. Поскольку к Интернету подключена моя карта wireless , я выбираю адаптер wireless network .

5. После внесения изменений я получаю IP-адрес непосредственно из сети , а не через адаптер Virtual Box . Вот результат.

Примечания:

Ваша беспроводная сеть по умолчанию сеть не может использоваться, пока вы используете Virtual Box . Если вы хотите использовать wireless network в своем Virtual Box , вы можете использовать usb-карту wireless , тогда виртуальная машина сможет ее обнаружить.

Надеюсь, вы нашли ее полезной 🙂

Поделитесь этой статьей, если сочли ее полезной:

Общие сведения о виртуальной сети в VMware Workstation 9

Введение

На мой взгляд, VMware Workstation — это лучшая и идеальная платформа для виртуализации рабочих столов на локальном ноутбуке или настольном компьютере с Windows или Linux. Это связано с тем, что Workstation предлагает наибольшую зрелость и функциональность из всех настольных гипервизоров. Workstation имеет надежный диспетчер моментальных снимков, самый большой список поддерживаемых гостевых операционных систем, удаленное управление / контроль виртуальных машин с помощью нового WSX (см. Мою статью — Управление виртуальными машинами VMware Workstation удаленно с помощью WSX), возможность подключения к vSphere в центре обработки данных для управления виртуальными машинами и импорт / экспорт и, наконец, наиболее зрелые виртуальные сети.В этой статье я сосредоточусь на том, как виртуальная сеть работает в VMware Workstation и что нового связано с виртуальной сетью в Workstation версии 9.

Введение в виртуальную сеть в VMware Workstation

Это виртуальная сеть, созданная VMware Workstation, которая соединяет ваши виртуальные машины с физической сетью. Как правило, самое важное, для чего требуется физическое подключение к сети, — это подключить виртуальную машину к локальной сети, а затем к Интернету.В конце концов, как и ваш настольный компьютер или ноутбук, вашим виртуальным машинам необходим доступ в Интернет, например, для просмотра веб-страниц или проверки электронной почты. Виртуальным машинам также необходим доступ к корпоративным приложениям, работающим в локальной сети.

По умолчанию VMware Workstation предлагает 3 типа виртуальных сетей — NAT, мостовые и только для хоста. Доступ в Интернет, как описано выше, осуществляется с типом сети виртуальной машины по умолчанию — NAT (каждая из них более подробно обсуждается ниже).

Вот как ломаются три виртуальные сети по умолчанию и с какой «сетью виртуальных машин» они связаны.

Три типа виртуальных сетей на рабочей станции, по умолчанию:

• Мост = VMnet0
• NAT = VMnet8
• Только хост = VMnet1

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

Рисунок 1: VMware Workstation 9 Редактор виртуальной сети

Дополнительные примечания:

• Виртуальный DHCP-сервер обслуживает NAT и сети только для хоста
• Вы можете создавать свои собственные сети VMnet
• Виртуальные сетевые адаптеры есть в каждой ВМ, при необходимости можно добавить несколько

Имейте в виду, что все это «по умолчанию», потому что все это настраивается вами.Например, вы можете изменить мостовую сеть на другую виртуальную сеть или просто удалить ее полностью (если вы это сделаете, помните, что опция Restore Default — ваш друг, потому что она может быстро вернуть все к тому, как было при установке Workstation. ).

Общие сведения о сетях NAT VMware Workstation

С помощью NAT или трансляции сетевых адресов виртуальная машина получит IP-адрес от встроенного DHCP-сервера VMware Workstation. Диапазон IP-адресов по умолчанию для сети NAT — 192.168.75.0 с маской подсети 255.255.255.0 (класс C) (которая полностью настраивается вами). IP-адрес, назначенный вашей виртуальной машине, которая находится в сети NAT, преобразуется в IP-адрес, назначенный физическому сетевому адаптеру рабочей станции, когда виртуальной машине с NAT необходимо взаимодействовать с общедоступной сетью (которая может быть локальной сетью компании, если вы подключены к локальной сети или Интернету, скажем, если вы находитесь в кафе).

Рисунок 2

Главное ограничение, о котором вам нужно знать, — это то, что вы можете настроить NAT только для одной сети (это то же самое для мостовой сети).

Рисунок 3

Можно иметь входящие подключения NAT к виртуальной машине, но вы должны настроить их вручную в редакторе виртуальной сети рабочей станции в разделе Настройки NAT . Как вы видите ниже, я хотел иметь возможность подключаться к виртуальной машине в сети NAT, входящей, используя RDP (удаленный рабочий стол), поэтому я открыл порт на хосте рабочей станции под 3390 (увеличен с 3389 или RDP) на RDP. на виртуальной машине внутри сети NAT (порт 3389). Для этого мне нужно было знать IP-адрес виртуальной машины в сети NAT, назначенный через DHCP-сервер рабочей станции.

Рисунок 4

Общие сведения о мостовых сетях VMware Workstation

Для моих виртуальных машин, работающих на рабочей станции, вместо NAT по умолчанию я обычно предпочитаю настраивать их с использованием сети Bridged . В мостовой сети виртуальная машина находится в той же сети, что и хост (ваш компьютер или ноутбук, на котором работает рабочая станция). Вы можете представить себе виртуальные машины с мостовыми соединениями, подключенными к большому виртуальному мосту вместе с вашим хост-компьютером.Это означает, что ваши виртуальные машины просто собираются запросить другой IP-адрес у DHCP-сервера вашей компании (скажем, если вы находитесь в корпоративной сети), и они будут в той же сети, что и ваш хост-компьютер. Другими словами, виртуальные машины с мостовыми сетевыми соединениями ничем не отличаются от любых других физических серверов в сети (к лучшему или к худшему). Хорошая сторона этого заключается в том, что вы можете подключаться к ним по RDP или подключаться к ним любым другим способом, чем другой физический сервер. Обратной стороной является то, что у них нет сетевой защиты, поэтому вам нужно помнить, что этим виртуальным машинам потребуется защита от вредоносных программ, и вы должны включить их брандмауэр и т. Д.

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

Рисунок 5

Общие сведения о сетях VMware Workstation только для хоста

Третий тип виртуальной сети в Workstation работает, как описано.Виртуальная сеть «только хост» подключает виртуальную машину к «только хосту». Другими словами, виртуальная машина может связываться только с хостом, на котором работает VMware Workstation, но у нее нет доступа к сети LAN, нет доступа к Интернету и нет связи с другими виртуальными машинами, которые работают на том же хосте под Workstation.

Виртуальные машины, работающие с опцией сети только для хоста, получат IP-адрес от DHCP-сервера рабочей станции из другой области, чем сеть NAT. По умолчанию только виртуальные машины будут получать IP-адреса от 192.168.56.0 / 24, которая будет использоваться для связи только с хостом, который также будет использовать IP-адрес из этой подсети для связи. Таким образом, сетевой трафик виртуальной машины не транслируется с помощью NAT.

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

Общие сведения о частных сетях VMware Workstation

Однако вместо «только хоста» для тестирования виртуальных машин и клиент-серверных приложений я обычно выбираю полностью частную сеть.В прошлом это можно было сделать с помощью опции Добавить сеть и создания полностью частной пользовательской сети.

В этой настраиваемой сети (скажем, вы выбрали VMnet2) у вас есть возможность:

• Подключать или НЕ подключать к хосту
• Предоставлять или НЕ предоставлять IP-адресацию DHCP

Допустим, вы выбрали НЕ подключать его к хосту и НЕ предоставлять IP-адресацию DHCP, тогда у вас есть полностью частная сеть, в которой любая виртуальная машина не может взаимодействовать ни с чем другим, кроме любой другой виртуальной машины, которую вы можете разместить там. .Подключив 2+ виртуальных машины к новой настраиваемой частной сети, которую вы создали, у вас есть виртуальная сетевая лаборатория, где вы можете делать все, что захотите (например, тестировать Windows Active Directory или Exchange, которые используют те же IP-адреса и доменные имена, что и ваши производственные серверы).

Имейте в виду, что если вы решите не предоставлять DHCP, вы должны либо предоставить свой собственный DHCP-сервер для виртуальной сети, либо назначить статические IP-адреса всем виртуальным машинам в сети.

Новым в VMware Workstation 9 является возможность создания сегментов локальной сети .Эти сегменты LAN похожи на настраиваемую сеть, которую вы создали бы, если бы в ней не было подключения к хосту и если бы в ней не было служб DHCP с рабочей станции.

Преимущество этих сегментов локальной сети состоит в том, что вы можете создавать столько, сколько захотите (вы не ограничены нумерацией Workstation VMnet 0-9).

LAN Segments — отличное решение, которое позволяет вам создавать столько виртуальных частных сетей для практически неограниченного числа применений (см. Мои примеры на рисунке 6).

Рисунок 6

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

Рисунок 7

Последней расширенной сетевой опцией в Workstation 9 является возможность регулировать входящую и исходящую пропускную способность сети, а также возможность генерировать собственный MAC-адрес Ethernet.

Рисунок 8

В целом, виртуальная сеть Workstation 9 является наиболее продвинутой из всех, что я когда-либо видел, учитывая несколько вариантов виртуальных сетей, встроенный DHCP-сервер и новую опцию LAN Segments для создания виртуальных частных лабораторных сред.

Просмотры сообщений:
21 210

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

Использование поиска Intel.com

Вы можете легко выполнить поиск по всему сайту Intel.com несколькими способами.

• Имя бренда:
  
  Core i9
  
• Номер документа:
  
  123456
  
• Кодовое имя:
  
  Kaby Lake
  
• Специальные операторы:
  
  «Ледяное озеро», Лед И Озеро, Лед ИЛИ Озеро, Лед *
  

Быстрые ссылки

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

Получение виртуальной машины для доступа к режиму монитора Wi-Fi

В нашей статье о переводе интерфейса WLAN Wi-Fi в режим мониторинга, чтобы вы могли прослушивать пакеты Wi-Fi и устранять неполадки в сетях WLAN, мы сказали, что если вы используете Windows, у вас проблемы. Мы указали, что одним из вариантов решения этой проблемы является запуск Linux как виртуальной машины, но что виртуальная машина не может получить доступ к интерфейсу Wi-Fi напрямую, поскольку все технологии виртуализации соединяют сетевой адаптер, поэтому они рассматриваются как проводные соединения.

Если вы смотрите на L3 и выше, это не проблема. Но если вам нужно прослушивать Wi-Fi L1 и L2 для данных о производительности радиосвязи, уровней мощности и т. Д., Это проблема.

В статье также предполагалось, что есть выход, если вы используете внешний USB-адаптер Wi-Fi, поддерживающий режим монитора. В этой статье объясняется, как я это делаю.

Во-первых, вам нужен адаптер подходящего типа. Сейчас их много, но вы должны убедиться, что адаптер позволяет перевести его в режим монитора.Я использую адаптер Alpha Networks 802.11 b / g / n AWUS036NHA, который вы можете легко получить на Amazon. Они делают ряд переходников.

Во-вторых, вам нужно настроить виртуальную машину — в моем случае Kali Linux настроен в Virtual Box. Все бесплатно.

В-третьих, когда виртуальная машина Kali Linux выключена, я подключаю беспроводной USB-адаптер к USB-порту своего компьютера. Затем в Virtual Box я добавляю беспроводной USB-адаптер (считая его назначением адаптера) к Kali VM.

Сначала нам нужно изменить настройки ВМ:

Затем в диалоге настроек:

1. Выберите USB
2. Выберите Включить контроллер USB и выберите правильную версию USB (моя система допускает только USB 1.1, если вы попробуете другие, и ваша виртуальная машина не загрузится, используйте это)
3. Щелкните «+», чтобы добавить одно из USB-устройств.
4. Выберите беспроводной USB из списка (мой был показан как Atheros)
5. Нажмите ОК

Теперь запустите виртуальную машину и войдите в систему.

Это немного странно, но, несмотря на то, что вы назначили беспроводной адаптер USB в настройках выше, вам все равно нужно «включить».

Это делается в VirtualBox из меню устройства, когда система запущена и работает:

Если вам нравится работать в полноэкранном режиме, как это делаю я, это меню находится в начальной части экрана VirtualBox:

Как показано в обоих методах, убедитесь, что выбран беспроводной USB-адаптер.

Отлично! Теперь мы можем перевести адаптер в режим монитора. Есть несколько способов сделать это (вы можете увидеть нашу статью о вариантах выбора здесь), но мы собираемся сделать это следующим образом (см. Снимок экрана ниже):

Сначала проверьте наличие адаптера с помощью команды ifconfig.

 ifconfig 

Second переведите интерфейс в режим монитора с помощью следующих команд:

 sudo ip link set wlan0 вниз 

 sudo iw wlan0 установить монитор нет 

 sudo набор IP-ссылок wlan0 вверх 

На этом этапе у вас должен быть установлен Wireshark, и мы можем запустить его.

Вы должны увидеть интерфейс wlan0 в списке интерфейсов.

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

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

Я выбрал канал 11 и теперь просто щелкаю плавник синей акулы, чтобы начать съемку:

Вы узнаете, что действительно захватываете трафик Wi-Fi, когда увидите кадры маяка, ACK, запрос на отправку, очистку для отправки и все эти типы пакетов WLAN.

Кроме того, если вы посмотрите на один из пакетов, вы увидите заголовки Radio Tap и 802.11 Radio, которые содержат важную информацию о производительности L1, такую ​​как уровни сигнала и шума, скорости передачи данных и многое другое.

И последнее. Чтобы вернуть интерфейс в нормальный управляемый режим, используйте следующие команды:

 sudo ip link set wlan0 вниз 

 sudo iw wlan0 установить управляемый тип 

Надеемся, вы найдете это полезным.

Istio / виртуальных машин в многосетевых сетях

В этом примере представлены инструкции по интеграции виртуальной машины или голого металлического хоста в
многосетевой Istio mesh, развернутый на Kubernetes с использованием шлюзов.Этот подход
не требует подключения к VPN или прямого доступа к сети между виртуальной машиной,
голый металл и кластеры.

Предварительные требования

• Один или несколько кластеров Kubernetes с версиями: 1.16, 1.17, 1.18.

• Виртуальные машины (ВМ) должны иметь IP-соединение с входными шлюзами в сети.

• Сервисы в кластере должны быть доступны через шлюз Ingress.

Этапы установки

Установка состоит из подготовки сетки к расширению, а также установки и настройки каждой виртуальной машины.

Подготовка вашей среды

При расширении возможностей ячеистой сети Istio для виртуальных машин в нескольких сетях (где виртуальная машина находится в сети, где трафик не может напрямую маршрутизироваться к модулям в кластере Kubernetes), нам необходимо воспользоваться преимуществами Istio возможности разделения горизонта DNS.

Прежде чем мы начнем, вам следует подготовить виртуальную машину и подключить ее к плоскости управления Istio через шлюз Ingress. Эти шаги подробно описаны в разделе Установка: Установка: Установка виртуальной машины.

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

Вы должны изменить инструкции по настройке виртуальной машины в соответствии с предложениями в этом разделе!

1. Когда мы создаем ресурс IstioOperator , нам нужно указать, какие сети мы ожидаем и как с ними обращаться
2. При создании сопроводительного файла .env нам нужно указать, к какой сети принадлежит виртуальная машина
3. Мы необходимо создать ресурс шлюза , чтобы разрешить трафик приложений от виртуальной машины к элементам рабочей нагрузки, работающим в сетке.

Установка плоскости управления Istio

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

1. Укажите ожидаемые сети в сетке, включая vm-network

     $ cat <./vmintegration.yaml
   apiVersion: install.istio.io/v1alpha1
   вид: IstioOperator
   спецификации:
     ценности:
       Глобальный:
         meshExpansion:
           включен: правда
         multiCluster:
           clusterName: куб-кластер
         сеть: основная сеть
         meshNetworks:
           основная сеть:
             конечные точки:
             - из реестра: kube-cluster
             шлюзы:
             - registerServiceName: istio-ingressgateway.istio-system.svc.cluster.local
               порт: 443
   
   EOF
     

2. Установить с включенными функциями виртуальной машины:

     $ istioctl install -f./vmintegration.yaml
     

Укажите сеть для виртуальной машины sidecar

Следуя руководству по установке виртуальной машины для создания файла sidecar.env , нам нужно настроить установку, добавив следующую запись:

  
  $ echo "ISTIO_META_NETWORK = vm-network" >> sidecar.env
  
 
 Создание шлюза для трафика приложений 
 Последним шагом является создание ресурса  Gateway , который позволяет трафику приложений от виртуальных машин правильно маршрутизироваться.
  
  API-версия: Networking.istio.io/v1alpha3
вид: Шлюз
метаданные:
  имя: шлюз с поддержкой кластера
  пространство имен: istio-system
спецификации:
  селектор:
    istio: ingressgateway
  серверы:
  - порт:
      номер: 443
      имя: tls
      протокол: TLS
    tls:
      режим: AUTO_PASSTHROUGH
    хосты:
    - "*.местный"
  
 
 Применение этого шлюза направит любой трафик от виртуальной машины, предназначенной для рабочих нагрузок в сетке, работающей на  * .local 
 На этом этапе вы можете продолжить работу с документацией по настройке виртуальной машины.
 Проверить настройку 
 После настройки машина может получить доступ к службам, работающим в кластере Kubernetes
 или на других виртуальных машинах. Когда служба на виртуальной машине пытается получить доступ к службе в сети, работающей на Kubernetes, конечные точки (то есть IP-адреса) для этих служб будут входным шлюзом в кластере Kubernetes. Чтобы убедиться в этом, выполните на виртуальной машине следующую команду (при условии, что у вас есть служба с именем  httpbin  в кластере Kubernetes):
  
  $ curl -v localhost: 15000 / кластеры | grep httpbin
  
 
 Это должно показать конечные точки для  httpbin , которые указывают на входной шлюз, аналогично этому:
  
  исходящий | 8000 || httpbin.default.svc.cluster.local :: 34.72.46.113: 443 :: cx_active :: 1
исходящий | 8000 || httpbin.default.svc.cluster.local :: 34.72.46.113: 443 :: cx_connect_fail :: 0
исходящий | 8000 || httpbin.default.svc.cluster.local :: 34.72.46.113: 443 :: cx_total :: 1
исходящий | 8000 || httpbin.default.svc.cluster.local :: 34.72.46.113: 443 :: rq_active :: 0
  
 
 IP  34.72.46.113  в данном случае является общедоступной конечной точкой входного шлюза.
 Отправлять запросы от рабочих нагрузок виртуальных машин к сервисам Kubernetes 
 На этом этапе мы должны иметь возможность отправлять трафик на  httpbin.default.svc.cluster.local  и получите ответ от сервера. Возможно, вам придется настроить DNS в  / etc / hosts  для сопоставления доменного имени  httpbin.default.svc.cluster.local  с IP-адресом, поскольку IP-адрес не будет разрешен. В этом случае IP-адрес должен быть IP-адресом, который маршрутизируется на локальный дополнительный компонент Istio Proxy. Вы можете использовать IP-адрес из переменной  ISTIO_SERVICE_CIDR  в файле  cluster.env , который вы создали в документации по настройке виртуальной машины.
  
  $ curl -v httpbin.default.svc.cluster.local: 8000 / заголовков
  
 
 Запуск служб на добавленной виртуальной машине 
 Настройка HTTP-сервера на экземпляре виртуальной машины для обслуживания HTTP-трафика через порт 8080:
  $ python -m SimpleHTTPServer 8080
  
 Обратите внимание, что вам может потребоваться открыть брандмауэры, чтобы получить доступ к порту 8080 на вашей виртуальной машине
 Добавить службы виртуальной машины в сетку
 Добавить службу в кластер Kubernetes в пространство имен (в этом примере   ), где вы предпочитаете хранить ресурсы (например,  Service ,  ServiceEntry ,  WorkloadEntry ,  ServiceAccount ) с помощью служб VM:
  $ cat << EOF | kubectl -n  применить -f -
apiVersion: v1
вид: Сервис
метаданные:
  имя: облако-vm
  ярлыки:
    приложение: облако-vm
спецификации:
  порты:
  - порт: 8080
    имя: http-vm
    targetPort: 8080
  селектор:
    приложение: облако-vm
EOF
  
 Наконец, создайте рабочую нагрузку с внешним IP-адресом виртуальной машины (замените  VM_IP  на IP-адрес вашей виртуальной машины):
  $ cat << EOF | kubectl -n  применить -f -
apiVersion: сеть.istio.io/v1beta1
kind: WorkloadEntry
метаданные:
  имя: "облако-vm"
  пространство имен: ""
спецификации:
  адрес: "$ {VM_IP}"
  ярлыки:
    приложение: облако-vm
  serviceAccount: ""
EOF
  
 Разверните под, на котором запущена служба  sleep  в кластере Kubernetes, и дождитесь, пока он будет готов:
 Zip
  $ kubectl apply -f @ samples / sleep / sleep.yaml @
$ kubectl получить модуль
ИМЯ ГОТОВ СОСТОЯНИЕ ВОЗРАСТ ВОЗРАСТ
sleep-88ddbcfdd-rm42k 2/2 Выполняется 0 1 с
...
  
 Отправить запрос от службы  sleep  на модуле в службу HTTP виртуальной машины:
  $ kubectl exec -it sleep-88ddbcfdd-rm42k -c sleep - curl cloud-vm. $ {VM_NAMESPACE} .svc.cluster.local: 8080
  
 Вы должны увидеть что-то похожее на результат ниже.
 
  
No related posts.