Создание виртуальной сети Create a virtual network

Вашей виртуальной машине потребуется виртуальная сеть, чтобы предоставить вашему компьютеру доступ к сети. Your virtual machines will need a virtual network to share a network with your computer. Создание виртуальной сети — необязательный шаг. Если виртуальную машину не требуется подключать к Интернету или сети, перейдите к шагу создания виртуальной машины Windows. Creating a virtual network is optional — if your virtual machine doesn’t need to be connected to the internet or a network, skip ahead to creating a Windows Virtual Machine.

Подключение виртуальных машин к Интернету Connect virtual machines to the internet

Hyper-V поддерживает три типа виртуальных коммутаторов: внешние, внутренние и частные. Hyper-V has three types of virtual switches — external, internal, and private. Создайте внешний коммутатор, чтобы предоставить доступ к сети вашего компьютера виртуальным машинам, работающим на нем. Create an external switch to share your computer’s network with the virtual machines running on it.

В этом упражнении выполняется создание внешнего виртуального коммутатора. This exercise walks through creating an external virtual switch. После завершения этого шага на узле Hyper-V будет виртуальный коммутатор, который сможет подключать виртуальные машины к Интернету через сетевое подключение вашего компьютера. Once completed, your Hyper-V host will have a virtual switch that can connect virtual machines to the internet through your computer’s network connection.

Создание виртуального коммутатора с помощью диспетчера Hyper-V Create a Virtual Switch with Hyper-V Manager

Откройте диспетчер Hyper-V. Open Hyper-V Manager. Чтобы сделать это быстро, нажмите кнопку или клавишу Windows и введите «Hyper-V Manager». A quick way to do this is by hitting the Windows button or key then type «Hyper-V Manager».
Если диспетчер Hyper-V найти не удается, это значит, что Hyper-V или средства управления Hyper-V отключены. If search doesn’t find Hyper-V Manager, Hyper-V or the Hyper-V management tools are not enabled. Инструкции по включению см. в разделе Включение Hyper-V. See the instructions to enable Hyper-V.

Выберите сервер в левой области или нажмите кнопку «Подключиться к серверу. » в правой области. Select the server in the left pane, or click «Connect to Server. » in the right pane.

В диспетчере Hyper-V выберите пункт Диспетчер виртуальных коммутаторов. в меню «Действия» справа. In Hyper-V Manager, select Virtual Switch Manager. from the ‘Actions’ menu on the right.

В разделе «Виртуальные коммутаторы» выберите пункт Создать виртуальный сетевой коммутатор. Under the ‘Virtual Switches’ section, select New virtual network switch.

В окне «Виртуальный коммутатор какого типа вы хотите создать?» выберите Внешний. Under ‘What type of virtual switch do you want to create?’, select External.

Нажмите кнопку Создать виртуальный коммутатор. Select the Create Virtual Switch button.

В разделе «Свойства виртуального коммутатора» назначьте ему имя, например Внешний коммутатор виртуальных машин. Under ‘Virtual Switch Properties’, give the new switch a name such as External VM Switch.

В разделе «Тип подключения» убедитесь, что выбрана Внешняя сеть. Under ‘Connection Type’, ensure that External Network has been selected.

Выберите физический сетевой адаптер для связывания с новым виртуальным коммутатором. Select the physical network card to be paired with the new virtual switch. Этот сетевой адаптер физически подключен к сети. This is the network card that is physically connected to the network.

Щелкните Применить, чтобы создать виртуальный коммутатор. Select Apply to create the virtual switch. На этом этапе, скорее всего, появится приведенное ниже сообщение. At this point you will most likely see the following message. Щелкните Да, чтобы продолжить. Click Yes to continue.

Щелкните ОК, чтобы закрыть окно диспетчера виртуальных коммутаторов. Select OK to close the Virtual Switch Manager Window.

Создание виртуального коммутатора с помощью PowerShell Create a Virtual Switch with PowerShell

Чтобы создать виртуальный коммутатор с внешним подключением с помощью PowerShell: The following steps can be used to create a virtual switch with an external connection using PowerShell.

Используйте командлет Get-NetAdapter, чтобы получить список сетевых адаптеров, подключенных к системе Windows 10. Use Get-NetAdapter to return a list of network adapters connected to the Windows 10 system.

Выберите сетевой адаптер для использования с коммутатором Hyper-V и разместите экземпляр в переменной с именем $net. Select the network adapter to use with the Hyper-V switch and place an instance in a variable named $net.

Выполните следующую команду, чтобы создать новый виртуальный коммутатор Hyper-V. Execute the following command to create the new Hyper-V virtual switch.

Виртуальная сеть на ноутбуке Virtual networking on a laptop

режим NAT. NAT networking

Механизм преобразования сетевых адресов (NAT) предоставляет виртуальной машине доступ к сети вашего компьютера путем объединения IP-адреса главного компьютера с портом через внутренний виртуальный коммутатор Hyper-V. Network Address Translation (NAT) gives a virtual machine access to your computer’s network by combining the host computer’s IP address with a port through an internal Hyper-V Virtual Switch.

У этого механизма есть ряд полезных возможностей. This has a few useful properties:

1. NAT экономит IP-адреса за счет сопоставления внешнего IP-адреса и порта с гораздо большим набором внутренних IP-адресов. NAT Conserves IP addresses by mapping an external IP address and port to a much larger set of internal IP addresses.
2. NAT позволяет нескольким виртуальным машинам размещать приложения, которым требуются одинаковые (внутренние) порты связи, сопоставляя их с уникальными внешними портами. NAT allows multiple virtual machines to host applications that require identical (internal) communication ports by mapping these to unique external ports.
3. NAT использует внутренний коммутатор. После создания внутреннего коммутатора вы можете не использовать сетевое подключение. Кроме того, за счет этого снижается нагрузка на сет компьютера. NAT uses an internal switch — creating an internal switch doesn’t cause you to use network connection and tends to interfere less with a computer’s networking.

Чтобы настроить сеть NAT и подключить ее к виртуальной машине, см. Руководство пользователя по созданию сети NAT. To set up a NAT network and connect it to a virtual machine, follow the NAT networking user guide.

Подход с использованием двух коммутаторов The two switch approach

Если вы используете Hyper-V в Windows 10 на ноутбуке и часто переключаетесь между беспроводной и проводной сетями, вы можете создать виртуальный коммутатор как для сетевой карты Ethernet, так и для карты беспроводной сети. If you’re running Windows 10 Hyper-V on a laptop and frequently switch between wireless networking and a wired network, you may want to create a virtual switch for both the ethernet and wireless network cards. В зависимости от того, как ноутбук подключается к сети, можно переключать виртуальные машины между этими коммутаторам. Depending on how the laptop connects to the network, you can change your virtual machines between these switches. Виртуальные машины не переключаются между проводными и беспроводными сетями автоматически. Virtual machines do not switch between wired and wireless automatically.

Подход, при котором задействованы два коммутатора, не поддерживают внешний виртуальный коммутатор с использованием платы беспроводных сетей. Такой подход следует использовать только для тестирования. The two switch approach does not support External vSwitch over wireless card and should be used for testing purposes only.

Виртуальный сетевой интерфейс

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

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

Идея крайне проста: канализировать трафик уже существующего сетевого интерфейса во вновь создаваемый интерфейс с совершенно другими характеристиками (имя, IP, маска, подсеть, …). Один из способов выполнения таких действий в форме модуля ядра Linux мы и обсудим (он не единственный, но другие способы мы обсудим отдельно в другой раз).

О интерфейсах в пару слов

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

Сетевой интерфейс — это то место, где:

• по каждому принятому из интерфейса пакету создаются экземпляры структуры сокетных буферов (struct sk_buff), далее созданный экземпляр структуры продвигается по стеку протоколов вверх, до его получателя в пространстве пользователя, где он и уничтожается;
• порождённые где-то на верхних уровнях протоколов пользовательского пространства исходящие экземпляры структуры struct sk_buff должны быть отправлены, а сами экземпляры структуры после этого уничтожаются (или утилизируются в пул).

На протяжении, как минимум, 5-6 последних лет, сетевые интерфейсы неизменно создавались макросом:

Здесь (детали будут понятны из примера модуля):
— sizeof_priv — размер приватной области данных интерфейса (struct net_device), которая будет создана ядром без нашего прямого участия;
— name — символьная строка — шаблон имени интерфейса;
— setup — адрес функции инициализации интерфейса;

В таком, практически неизменном, виде процесс создания интерфейса описан везде в публикациях и упоминается в обсуждениях. Но начиная с ядра 3.17 прототип макроса создания интерфейса меняется (
):

Как легко видеть, теперь вместо 3-х параметров 4, 3-й из которых — константа, определяющая порядок нумерации создаваемых интерфейсов (исходя из шаблона имени), описанная в том же файле определений:

Это первая тонкость на которую следует обратить внимание. Детальнее мы не будем углубляться в эти детали, важно было только отметить их.

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

В ядре 3.09, например, определено 39 операций в struct net_device_ops, и около 50-ти операций в ядре 3.14, но реально разрабатываемые модули реализуют только малую часть из них.

Характерно, что в таблице операций интерфейса присутствует операция передачи сокетного буфера ndo_start_xmit() в физическую среду, но вовсе нет операции приёма пакетов (сокетных буферов). Это совершенно естественно, как мы увидим вскоре: принятые пакеты (например в обработчике аппаратного прерывания IRQ) непосредственно после приёма вызовом netif_rx() (или netif_receive_skb()) тут же помещаются в очередь (ядра) принимаемых пакетов, и далее уже последовательно обрабатываются сетевым стеком. А вот выполнять функцию ndo_start_xmit() — обязательно, хотя бы, как минимум, для вызова API ядра dev_kfree_skb(), который утилизирует (уничтожает) сокетный буфер после успешной (да и безуспешной тоже) операции передачи пакета. Если этого не делать, в системе возникнет слабо выраженная утечка памяти (с каждым пакетом), которая, в конечном итоге, рано или поздно приведёт к краху системы. Это ещё одна тонкость, которую держим в уме.

Последним необходимым нам элементом является структура struct net_device (описана в
) — описание сетевого интерфейса. Это крупная структура, содержащая не только описание аппаратных средств, но и конфигурационные параметры сетевого интерфейса по отношению к выше лежащим протоколам (пример взят из ядра 3.09):

Здесь поле type, например, определяет тип аппаратного адаптера с точки зрения ARP-механизма разрешения MAC адресов (
):

Со структурой сетевого интерфейса обычно создаётся и связывается приватная структура данных (упоминавшаяся ранее), в которой пользователь может размещать произвольные собственные данные любой сложности, ассоциированные с интерфейсом. Это особо актуально, если предполагается, что драйвер может создавать несколько однотипных сетевых интерфейсов. Доступ к приватной структуре данных должен определяться исключительно специально определённой для того функцией netdev_priv(). Ниже показан возможный вид функции — это определение из ядра 3.09, но никто не даст гарантий, что в другом ядре оно радикально не поменяется:

Как легко видеть из определения, приватная структура данных дописывается непосредственно в хвост struct net_device — это обычная практика создания структур переменного размера, принятая в языке C начиная с стандарта C89 (и в C99).

Этого строительного материала нам будет достаточно для построения модуля виртуального сетевого интерфейса.

Модуль виртуального интерфейса

Здесь всё достаточно просто, но некоторых отдельных комментариев заслуживают следующие моменты:

• После создания интерфейса alloc_netdev() мы связываем его операции через таблицу crypto_net_device_ops. Здесь определены операции (поля): .ndo_open и .ndo_stop (которые вызываются при запуске и остановке интерфейса командой ifconfig up/down), .ndo_get_stats (запрос статистики интерфейса) и .ndo_start_xmit (передача пакета).
• Через приватную область данных мы сохраняем связь с родительским интерфейсом в нами определённой структуре struct priv (в файлах примеров показано несколько различных вариантов использования приватной области для связывания).
• В таблице операций нет (да и быть не может по логике) функции приёма сокетных буферов. Но вызовом netdev_rx_handler_register() (который появился только в ядре 2.6.36) мы можем добавить в очередь обработки принимаемых пакетов (для родительского интерфейса) собственную функцию-фильтр handle_frame(), которая будет вызываться для каждого приходящего с этого интерфейса пакета.
• На время добавления фильтра к очереди, нам необходимо кратковременно заблокировать доступ к очереди (иначе нас может ожидать аварийный результат). Это достигается вызовами rtnl_lock() и rtnl_unlock().
• При передаче исходящего сокетного буфера в сеть (функция start_xmit()) мы просто подменяем в структуре сокетного буфера интерфейс, через который физически должна производиться отправка.
• При приёме, наоборот, сокетные буфера, создаваемые в родительском интерфейсе, подменяются на виртуальный.

Как это работает?

Выберем любой существующий и работоспособный сетевой интерфейс (в Fedora 16 один из Ethernet интерфейсов назывался как p7p1 — это хорошая иллюстрация того, что интерфейсы могут иметь очень разнообразные имена):

Установим на него свой новый виртуальный интерфейс и конфигурируем его на IP подсеть (192.168.50.0/24), отличную от исходной подсети интерфейса p7p1:

Самый простой и быстрый способ создать ответный конец коммуникации (нам ведь нужно как-то тестировать свою работу?) для такой новой (192.168.50.2/24) подсети на другом хосте LAN, это создать алиасный IP для сетевого интерфейса этого удалённого хоста, по типу:

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

Теперь из вновь созданного виртуального интерфейса мы можем проверить прозрачность сети посылкой ICMP:

И далее создать (теперь уже наоборот, на удалённом хосте) полноценную сессию SSH к новому виртуальному интерфейсу:

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

Что дальше?

Проницательный читатель, да ещё если он внимательно читал предыдущий текст, вправе в этом месте воскликнуть: «Но ведь ваш виртуальный интерфейс не дополняет, а замещает родительский?». Да, в показанном варианте именно так: загрузка такого модуля запрещает трафик по родительскому интерфейсу, но выгрузка модуля опять восстанавливает его.

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

• В фильтрах (и приёма и передачи) анализировать поле IP-адреса в структуре сокетного буфере и производить подмену интерфейса только для IP, принадлежащего виртуальному интерфейсу.
• На приёме разделить обработку сокетных буферов, соответствующим протоколам IP и ARP, потому как структуры данных этих протоколов, естественно, отличаются (поле struct sk_buff*->protocol).

Это выглядит, возможно, сложновато в словесном описании, но в коде модуля всё достаточно просто, и добавляет не более 25 строк кода. И такой вариант приведен в архиве примеров (подкаталог virt-full, здесь этот код не приводится, чтобы не перегружать текст):

Архив кодов для продолжения экспериментирования можете взять здесь или здесь.