Эксперты в подборе IT-оборудования
Виртуальная сетевая карта - это программный сетевой интерфейс, который операционная система показывает и обслуживает так же, как настоящую плату в слоте, хотя никакого железа за ним нет. У неё есть имя, MAC-адрес, IP-настройки и драйвер, её видно в списке адаптеров, но физического порта, куда воткнуть кабель, не существует.
Чаще всего с виртуальными адаптерами сталкиваются в двух ситуациях. Первая - осознанная: разворачивают виртуальные машины, и каждой нужен сетевой интерфейс. Вторая - неожиданная: в списке сетевых подключений появляются устройства, которых там раньше не было, а Windows вдруг сообщает, что вы «подключены с помощью виртуального сетевого адаптера». Разберём оба случая.
Физическая сетевая карта - это плата с контроллером и разъёмом. Она принимает электрические или оптические сигналы, собирает из них кадры и отдаёт их операционной системе. MAC-адрес зашит производителем - подробно о том, как работает сетевая карта, разобрано отдельно.
Виртуальная карта делает то же самое, но её «провод» - это программный канал внутри хоста. Драйвер создаёт интерфейс, система видит обычный сетевой адаптер, а трафик уходит не в кабель, а в другой программный компонент: виртуальный коммутатор, туннель VPN, ядро гипервизора. MAC-адрес такой карте назначается - гипервизором из своего диапазона или вручную администратором.
Отсюда практические следствия:
Путаница встречается часто, поэтому стоит развести понятия сразу.
VLAN (стандарт 802.1Q) - это способ логически разделить одну физическую сеть на несколько независимых. Работает за счёт тега в заголовке кадра: коммутатор смотрит на номер VLAN и не пропускает трафик между разными номерами.
Виртуальная сеть гипервизора - это программный коммутатор внутри хоста, к которому подключаются виртуальные адаптеры машин. В Hyper-V он называется виртуальным коммутатором, в VMware ESXi - стандартным или распределённым коммутатором, в Linux это мост (bridge) или Open vSwitch.
Связь между ними есть: виртуальному адаптеру можно назначить номер VLAN, и тогда его трафик уйдёт в физическую сеть с тегом. Но одно не заменяет другое. Виртуальная карта подключается к виртуальному коммутатору, а VLAN - это разметка трафика, которая может применяться и в физической сети без всякой виртуализации.
Самый частый повод искать информацию про виртуальные адаптеры - обнаружить их у себя и не понять, откуда они взялись. Ниже - те, что встречаются чаще всего.
| Что видно в системе | Откуда взялся | Трогать? |
|---|---|---|
| Microsoft Wi-Fi Direct Virtual Adapter | Wi-Fi Direct: Miracast, «Проецирование на этот компьютер», беспроводной дисплей | Не удалять. Если функция не нужна, отключить её в параметрах проецирования |
| Microsoft Hosted Network Virtual Adapter | Раздача Wi-Fi с компьютера (мобильный хот-спот, старый механизм netsh wlan hostednetwork) | Не удалять, само появляется и исчезает |
| TAP-Windows Adapter V9 | OpenVPN и всё, что на нём построено | Нужен, пока пользуетесь этим VPN |
| PANGP Virtual Ethernet Adapter | Корпоративный VPN Palo Alto GlobalProtect | Ставится вместе с клиентом, удалять только вместе с ним |
| vEthernet (…) | Hyper-V, а также WSL2, Docker Desktop и «Песочница Windows» - они включают Hyper-V | Удаление ломает виртуальные машины и WSL |
| VMware Network Adapter VMnet1 / VMnet8 | VMware Workstation: сеть «только для хоста» и NAT | Ставится вместе с VMware |
| VirtualBox Host-Only Ethernet Adapter | VirtualBox | Ставится вместе с VirtualBox |
| WAN Miniport (IP, IPv6, PPPoE, L2TP, IKEv2, SSTP, PPTP) | Штатные компоненты Windows для VPN- и модемных подключений | Не трогать, это часть системы |
| Teredo Tunneling Pseudo-Interface, 6to4, IP-HTTPS | Механизмы туннелирования IPv6 в Windows | Не трогать |
Виртуальный адаптер появляется вместе с программой, которая его создала, и уходит вместе с ней. Удалять его отдельно через диспетчер устройств почти всегда бессмысленно: при следующем запуске программы или перезагрузке он вернётся. Если адаптер мешает, отключать надо не его, а функцию или программу-источник.
Есть и обратная ситуация, о которой стоит знать: если вы видите виртуальный адаптер, а никакого VPN, гипервизора и виртуальных машин у вас нет - это повод разобраться, что за программа его поставила.
Формулировка, которую Windows выдаёт при диагностике сети, звучит примерно так: «вы подключены с помощью виртуального сетевого адаптера, который не удаётся проверить». Пугает она сильнее, чем стоит.
Смысл сообщения простой: система видит, что трафик идёт не напрямую через физическую карту, а через программный интерфейс, и потому не может провести обычные проверки соединения. Типичные причины:
Само по себе сообщение неисправностью не является. Оно становится проблемой, только если интернет действительно не работает. Тогда порядок разбора такой: посмотреть список адаптеров и понять, какой из них активен; отключить VPN и проверить, вернулась ли связь; убедиться, что маршрут по умолчанию ведёт через нужный интерфейс. Крайняя мера - сброс сетевых настроек в параметрах Windows, после которого адаптеры переустановятся; но это заодно снесёт настройки VPN и статические IP, так что применять её стоит осознанно.
Полный список интерфейсов, включая скрытые, выводит одна команда PowerShell:
Get-NetAdapter -IncludeHidden | Select-Object Name, InterfaceDescription, Status, Virtual
Колонка Virtual сразу отвечает на главный вопрос: True - интерфейс программный, False - за ним настоящая плата. Это быстрее, чем щёлкать по диспетчеру устройств, и показывает то, что в графическом интерфейсе спрятано.
Если привычнее мышью: devmgmt.msc, меню «Вид» → «Показать скрытые устройства», раздел «Сетевые адаптеры». Без включения скрытых устройств половина виртуальных адаптеров не отображается.
Создать виртуальный адаптер в Windows отдельной кнопкой нельзя - он появляется вместе с ролью или программой. Штатный путь - компонент Hyper-V: включить его в «Программах и компонентах», затем создать виртуальный коммутатор через «Диспетчер виртуальных коммутаторов» или командой:
New-VMSwitch -Name "LabSwitch" -SwitchType Internal
После этого в системе появится интерфейс vEthernet (LabSwitch), с которым можно работать как с обычным адаптером. Список уже созданных коммутаторов показывает Get-VMSwitch. Обе команды требуют PowerShell, запущенного от администратора, - без этого выйдет отказ в доступе.
Здесь интерфейсы создаются штатными средствами ядра. Всё, что создаёт или меняет интерфейсы, требует root - через sudo или из-под пользователя root. Посмотреть текущие можно и без прав:
ip -br link show
Создать мост, к которому будут подключаться виртуальные машины:
ip link add br0 type bridge
ip link set br0 up
Создать TAP-интерфейс - именно такие использует QEMU/KVM для подключения машин к сети:
ip tuntap add dev tap0 mode tap
ip link set tap0 up
Создать пустышку для тестов, когда нужен интерфейс с адресом, но без реального трафика:
ip link add dummy0 type dummy
ip link set dummy0 up
Важный нюанс: всё созданное этими командами живёт до перезагрузки. Чтобы конфигурация сохранилась, её описывают в средстве управления сетью конкретного дистрибутива - NetworkManager (nmcli), systemd-networkd или netplan.
Отдельного разговора заслуживают TAP- и TUN-интерфейсы - именно они чаще всего и оказываются тем самым непонятным адаптером в списке.
Это два типа виртуальных интерфейсов, которые операционная система отдаёт обычной программе. Разница между ними в том, на каком уровне программа получает трафик.
В Windows под это ставится драйвер TAP-Windows Adapter V9, который тянет за собой OpenVPN и производные от него клиенты. В Linux оба типа создаются штатно, командой ip tuntap, без установки чего-либо дополнительного.
Практический вывод: если TAP-адаптер остался в системе после удалённого VPN-клиента, он безвреден, но его можно убрать вместе с драйвером через «Программы и компоненты». А вот если такого адаптера нет, а VPN его требует - переустановка клиента обычно возвращает драйвер на место.
Виртуальная карта сама по себе бесполезна - она должна к чему-то подключаться. Этим «чем-то» и служит виртуальный коммутатор. В Hyper-V у него три типа, и от выбора зависит вся изоляция:
| Тип | Кто с кем видится | Когда нужен |
|---|---|---|
| Внешний (External) | Виртуальные машины, хост и физическая сеть | Обычный случай: машинам нужен выход наружу |
| Внутренний (Internal) | Виртуальные машины и хост, но не физическая сеть | Лаборатория, тестовый контур с доступом с хоста |
| Частный (Private) | Только виртуальные машины между собой | Полностью изолированный стенд, разбор вредоносного ПО |
В VMware и VirtualBox названия другие, а логика та же: мост в физическую сеть, сеть «только для хоста» и изолированная внутренняя сеть, плюс отдельно режим NAT.
Это и есть основной механизм безопасности на данном уровне: изоляция задаётся типом коммутатора, а не настройками самой виртуальной карты. Дальше к нему добавляются номера VLAN, ограничение скорости на порт и защита от подмены MAC-адреса - в Hyper-V это отдельные свойства адаптера виртуальной машины.
Виртуальные карты бывают двух типов, и разница между ними ощутима.
Эмулированные притворяются реальной моделью сетевой платы прошлых лет, чтобы гостевая система опознала их своим встроенным драйвером. В Hyper-V такой адаптер назывался Legacy Network Adapter, в VMware ему соответствует эмуляция E1000. Работает без дополнительных драйверов, но медленно: каждый кадр проходит через эмуляцию регистров несуществующего железа.
Синтетические (паравиртуальные) не притворяются ничем. Гостевая система знает, что работает под гипервизором, и общается с ним напрямую через специальный драйвер: VMXNET3 в VMware, virtio-net в KVM и Proxmox, синтетический адаптер в Hyper-V. Скорость в разы выше, нагрузка на процессор ниже.
Практическое правило: везде, где гостевая ОС поддерживает синтетический драйвер, надо брать его. Эмулированный оставляют для двух случаев - старая гостевая система без нужных драйверов и загрузка по сети до установки ОС, когда синтетический драйвер ещё неоткуда взять.
Отдельная деталь про MAC-адреса. У виртуальной карты он назначается, а не зашит, и по первым трём байтам обычно видно, чей это адаптер: 00:15:5D - Hyper-V, 00:0C:29 и 00:50:56 - VMware, 08:00:27 - VirtualBox, 52:54:00 - QEMU/KVM. Приём выручает, когда в сети обнаружилось неизвестное устройство и надо быстро понять, откуда оно.
На сервере вопрос ставится иначе: не «что это за адаптер», а «выдержит ли сеть нагрузку от десятка машин через один физический порт».
Физические порты никуда не деваются. Весь трафик виртуальных машин рано или поздно упирается в карту хоста. Гипервизорному узлу обычно дают минимум два порта: один под управление, другой под продуктивный трафик, - и объединяют их в группу для отказоустойчивости. Как устроена сама плата и на что смотреть при выборе, разобрано в статье про сетевой адаптер.
Обработка трафика стоит процессорного времени. Виртуальный коммутатор - это код, который выполняется на хосте. На гигабите это незаметно, на 10 Гбит/с и выше - вполне. Отсюда механизмы разгрузки: VMQ распределяет обработку очередей по ядрам, а SR-IOV подключает виртуальную машину к физической карте почти напрямую, минуя виртуальный коммутатор.
У SR-IOV есть цена. Машина, подключённая через него, теряет часть возможностей гипервизора: живая миграция и снимки состояния работают с ограничениями, а сам режим должен поддерживаться и картой, и материнской платой, и BIOS. Поэтому его включают точечно, под конкретные требовательные задачи, а не по умолчанию.
Планировать сеть надо вместе с остальными ресурсами. Сколько машин на узел, сколько им нужно полосы, хватит ли портов - это часть общего расчёта, как и процессор с памятью. Смежные материалы: планирование ресурсов для виртуальных машин и виртуальные сети VXLAN и VMware NSX, если сеть перерастает один узел.
Несколько ситуаций, в которых виртуальные интерфейсы создают проблемы, а причина неочевидна.
Пропал интернет после включения Hyper-V. При создании внешнего коммутатора физический адаптер отдаётся ему, а хост получает связь уже через vEthernet. Если на физической карте были прописаны статические настройки, они не переносятся - их надо задать заново на виртуальном интерфейсе.
Трафик уходит не туда. Когда активны несколько интерфейсов сразу, система выбирает маршрут по метрике. VPN-адаптер часто ставит себе приоритет выше физического, и весь трафик уходит в туннель. Лечится метрикой интерфейса или настройками split tunneling в клиенте VPN.
Скорость ниже ожидаемой. Первое, что стоит проверить, - тип адаптера у виртуальной машины. Если стоит эмулированный вместо синтетического, потолок будет заметно ниже возможностей железа.
Дубли MAC-адресов. Возникают при клонировании виртуальных машин, если MAC был задан статически: две машины с одинаковым адресом в одной сети работать нормально не будут. Лечится переводом адаптера в динамический режим или ручной сменой адреса.
Отдельно от программы, которая его создала, - обычно нет смысла: он вернётся после перезагрузки или следующего запуска. Правильный путь - удалить или отключить источник: VPN-клиент, компонент Hyper-V, VMware, VirtualBox.
Гипервизоры допускают несколько штук на машину, конкретный предел зависит от платформы и типа адаптера. Больше двух-четырёх нужно редко - обычно чтобы развести управление, продуктив и резервное копирование.
Небольшие накладные расходы есть всегда: обработкой занимается процессор хоста. На гигабитных скоростях разница незаметна, на десяти гигабитах и выше - становится ощутимой, и тогда включают механизмы разгрузки.
Нет. Это часть гипервизора или операционной системы, отдельно она не лицензируется.
Карта принадлежит машине - это её сетевой интерфейс. Коммутатор принадлежит хосту и соединяет между собой карты разных машин. Одна карта подключается к одному коммутатору, к одному коммутатору подключается много карт.
Скорость линка у программного интерфейса условна: физического канала нет, и система показывает либо значение по умолчанию, либо скорость, унаследованную от коммутатора. Ориентироваться на это число не стоит - реальную пропускную способность определяет физическая карта хоста и загрузка процессора.
Да, в настройках адаптера виртуальной машины. Делают это, когда MAC привязан к лицензии программы или к резервированию адреса на DHCP-сервере. Главное - не забыть сменить его при клонировании машины, иначе в сети окажутся два одинаковых адреса.
В Windows - командой Get-NetAdapter -IncludeHidden, колонка Virtual. В Linux у виртуальных интерфейсов нет каталога устройства на шине: ls -l /sys/class/net/ покажет, что у них в пути нет devices/pci.
Виртуальных адаптеров можно создать сколько угодно, а вот физические порты на узле виртуализации заканчиваются быстро, и добавлять их потом дороже, чем заложить сразу. Если подбираете платформу под гипервизор, посмотрите готовые конфигурации в разделе сервер для виртуальных машин или напишите нам - рассчитаем количество портов и сетевых карт под ваше число машин.
ITTELO, 11+ лет на рынке серверов.
Телефон: +7 (800) 551-80-12
Почта: info@ittelo.ru
