Как создать виртуальный сетевой адаптер linux

Обновлено: 06.07.2024

OpenVSwitch это программный коммутатор, специально предназначенный для работы с системами виртуализации. OpenVSwitch предоставляет куда большие возможности, по сравнению со стандартной утилитой Linux bridge-utils. Например:

Учет трафика с помощью sFlow и Netflow
Возможность создания VLAN (IEEE 802.1q)
Поддержка Openflow для управления коммутацией
Привязка виртуальных интерфейсов к конкретным физическим интерфейсам.
Поддержка зеркалирования портов
ACL
Политики QoS

Использование OpenVSwitch поможет организовать логически структурированную виртуальную сеть с возможностью тонкой настройки. Так что, по моему мнению, всем, кто знакомится или уже работает с виртуализацией KVM, использование OpenVSwitch строго рекомендуется.

Установка и начало работы

Пакет OpenVSwitch поставляется из стандартного репозитория Ubuntu/Debian, поэтому установка простая. Выполняем команду:

Для работы с сетевыми интерфейсами используется утилита ovs-vsctl. Проверим, какая версия OpenVSwitch установлена:

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

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

Добавляем к мосту сетевой интерфейс:

Теперь можно перейти к добавлению виртуальных портов:

В команде выше мы обозначили создание виртуального интерфейса test-interface, привязанного к бриджу bridgeswitch. После двойной черты, обозначающей начало новой строки, указываем тип интерфейса.

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

На этом все. Теперь, выполнив команду:

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

С виртуальным интерфейсом test-interface можно работать как с обычным физическим, то есть появляется возможность конфигурировать его на локальной машине. Это бывает полезно, когда нужно обеспечить работу сервера в нескольких вланах, используя одну сетевую карту в качестве транка. Или, например, задать серверу несколько ip адресов. Для этого создается несколько виртуальных интерфейсов и для каждого прописывается конфигурация. Но я не рекомендую это делать. Если возникнет ситуация как в примере выше, то лучше использовать возможности systemd-networkd или ip.

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

Для удаления бриджа:

Добавление VLAN

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

Создадим новый виртуальный коммутатор:

Добавляем реальную сетевую карту к виртуальному коммутатору:

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

Добавляем виртуальный сетевой интерфейс и присваиваем ему тег:

Теперь можно посмотреть конфигурацию:

Включение Netflow на виртуальном коммутаторе OpenVSwitch

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

Необходимо только указать имя виртуального коммутатора, ip адрес и порт назначения и период, через который будут отправляться данные (в секундах).

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

Чтобы прекратить отправлять данные на Netflow коллектор, достаточно очистить настройки Netflow для виртуального коммутатора:

Кстати, о том, как поднять Netflow коллектор используя стек ELK есть материал вот в этой статье.

Заключение

Здесь описан необходимый минимум для начала работы с OpenVSwitch. О непосредственной же интеграции OpenVSwitch и KVM подробно будет написано в следующей статье.

If you liked my post, feel free to subscribe to my rss feeds

This entry was written by admin and posted on 16th Май 2019 at 1:35 пп and filed under Uncategorised. Bookmark the permalink. Follow any comments here with the RSS feed for this post. Post a comment(Latest is displayed first) or leave a trackback: Trackback URL.

Знаете ли вы, что можете присвоить более чем один IP-адрес физическому сетевому интерфейсу? Эта техника очень полезна, например при работе с Apache и виртуальными хостами, так как позволяет получить доступ к одному и тому же серверу Apache с двух разных IP-адресов.

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

Процесс создания виртуального сетевого интерфейса в Linux не занимает много времени. Он включает один запуск команды ifconfig.

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

Теперь мы можем настроить новый виртуальный интерфейс на базе eth0. После выполнения команды ifconfig новый виртуальный интерфейс готов к немедленному использованию.

2.1. Отключение виртуального сетевого интерфейса

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

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

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

3.1. Debian / Ubuntu

3.1.1. Статический адрес

В Debian или Ubuntu вам необходимо отредактировать файл /etc/network/interfaces, добавив в него следующие строки:

3.1.2. Dhcp

Возможно также использовать витруальный сетевой интерфейс с DHCP. В этом случае вам необходимо добавить в /etc/network/interfaces следующую строку:

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

3.2. Redhat / Fedora / CentOS

3.2.1. Статический адрес

В Redhat, Fedora или CentOS Linux директория, отвечающая за присвоение постоянных IP-адресов - это /etc/sysconfig/network-scripts. В этой директории необходимо создать файл, соответствующий вашему новому виртуальному интерфейсу. В нашем случае этот файл будет называться ifcfg-eth0:0. Создайте этот новый файл и вставьте в него приведенные ниже строки. После перезагрузки адрес будет присвоен виртуальному интерфейсу на постоянной основе.

3.2.2. Dhcp

Когда закончите, перезапустите ваши интерфейсы:

4. Заключение

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

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

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

Виды сетевых адаптеров VirtualBox

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

NAT - этот способ используется по умолчанию. Для каждой машины создается отдельная внутренняя локальная сеть, в которой машина получает ip 10.10.0.1. Машина может связаться с интернетом, используя технологию NAT, и вы можете обратиться к машине, используя проброс портов VirtualBox, но если у вас будет две виртуальные машины, то вы уже не сможете между ними так взаимодействовать. И если из основной системы к гостевой можно обратиться, то к основной ни гостевой уже никак не получится;
Виртуальный адаптер хоста - создается виртуальный сетевой адаптер, к которому можно подключить несколько виртуальных машин, тем самым объединив их в локальную сеть. Доступа к интернету нет, но зато машины находятся в одной сети и каждая имеет свой ip адрес, теперь они могут взаимодействовать между собой. Основная система тоже доступна по ip 192.168.56.1. Машины доступны не только между собой, но и из основной системы;
Сетевой мост - при таком подключении виртуальная машина становится полноценным членом локальной сети, к которой подключена основная система. Машина использует сетевой интерфейс чтобы получить адрес у роутера и становится доступна для других устройств, как и основной компьютер по своему ip адресу.
Внутренняя сеть - почти то же самое, что и виртуальный адаптер хоста, только без возможности доступа к виртуальной сети из основной системы, доступа к интернету нет.
Универсальный драйвер - позволяет использовать драйвер из расширений VirtualBox для связи между машинами, расположенными на разных физических хостах.

Теперь рассмотрим каждый вариант настройки более подробно.

Настройка сети Virtualbox

1. Настройка сети NAT

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

Перейти на вкладку "Сеть":

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

На вкладке "Дополнительно" вы можете настроить марку устройства адаптера и MAC адрес:

Если вы собираетесь устанавливать туда в Windows, то лучше будет работать Intel PRO/1000 MT Desktop, а для Linux можно оставить AMD PCNet FAST III, так как он поддерживается всеми операционными системами.

2. Настройка сети NAT

В версии Virtualbox, начиная с 4.3 была добавлена поддержка сетей NAT, это работает очень похоже на виртуальный адаптер хоста, все машины, подключенные к одной сети могут получить доступ друг к другу, а доступ в интернет выполняется через NAT, но основная система доступа к гостевым не имеет. Чтобы настроить такое подключение нужно сначала создать сеть NAT. Для этого откройте "Файл" -> "Настройки", "Сеть". Здесь перейдите на вкладку "Сети NAT". Дальше нажмите кнопку с зеленым плюсом, чтобы создать новую сеть:

Нажмите "Ok" и закройте это окно. Дальше откройте настройки для виртуальной машины, перейдите на вкладку "Сеть" -> "Адаптер 1":

Выберите "Тип подключения" - "Сеть NAT", а "Имя" - только что созданную сеть.

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

3. Настройка адаптера виртуального хоста

Теперь задача немного интереснее - нам нужна локальная сеть virtualbox между несколькими виртуальными машинами и хостом. Для того чтобы все это заработало в Linux, нам нужно чтобы были загружены модули ядра vboxnetadp и vboxnetflt:

lsmod | grep vbox

Возможно, для их правильной работы вам придется установить пакет net-tools. Дальше нужно создать сам виртуальный адаптер. Для этого откройте меню "Файл", затем "Настройки" -> "Сеть". Затем нажмите кнопку с зеленым значком плюс, а затем "Ok", все параметры можно оставить по умолчанию. В VirtualBox 5.2 и выше интерфейс был изменен. Теперь вам нужно открыть меню "Инструменты" -> "Менеджер сетей хоста":

Теперь вернитесь к списку виртуальных машин, зайдите в настройки машины, "Сеть":

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

Для всех машин, которые вы хотите объединить в одну сеть нужно выбирать один и тот же адаптер хоста. Если вы захотите добавить машинам также доступ в интернет, просто перейдите на вкладку "Адаптер 2", включите его и настройте NAT, как описано в первом пункте.

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

Режим сетевого моста позволяет виртуальной машине выступать в роли реального сетевого устройства с отдельным ip адресом. Чтобы это настроить откройте это же меню - настойки виртуальной машины, затем "Сеть". Здесь выберите "Тип подключения" - "Сетевой мост":

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

5. Внутренняя сеть VirtualBox

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

Как видите, существует тип подключения NAT - где только интернет, Мост - где машина становится членом внешней сети, а все остальные - это настройка виртуальной сети virtualbox, где машины могут видеть друг друга.

Выводы

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

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

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

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

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

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

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

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

Как легко видеть, теперь вместо 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 (описана в <linux/netdevice.h>) — описание сетевого интерфейса. Это крупная структура, содержащая не только описание аппаратных средств, но и конфигурационные параметры сетевого интерфейса по отношению к выше лежащим протоколам (пример взят из ядра 3.09):

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

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

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

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

Создаём модуль, который будет перехватывать трафик сетевого ввода-вывода с другого, ранее существующего в системе (физического либо логического), интерфейса, и обеспечивать обработку этих потоков (файл virt.c)…

После создания интерфейса 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).

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

Возможно ли на физическом интерфейсе сделать виртуальный сетевой интерфейс с другим МАC?

лолшто?
алиас штоле?
делай я разрешаю

Нет. Ты лучше цель напиши, а путь решения тебе подскажут.

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

Я когда-то такое делал при помощи libpcap, tun/tap и мааааленькой программки на C. Могу поискать исходники.

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

Ага, вроде должно было заработать, но:
Сделал VLAN, далее у интерфейса VLAN-а стал МАК физического интерфейса eth0, поменя его с помощью hw ether для eth0.2. Итог:

eth0 Link encap:Ethernet HWaddr 00:00:DE:16:53:9A
inet addr:192.168.2.7 Bcast:192.168.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:32431599 errors:0 dropped:0 overruns:0 frame:0
TX packets:31009110 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:848102259 (808.8 Mb) TX bytes:868522648 (828.2 Mb)
Interrupt:11 Base address:0x2000

eth0.2 Link encap:Ethernet HWaddr 00:00:00:11:11:11
inet addr:192.168.2.234 Bcast:192.168.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

Но при пинговании IP на VLAN 192.168.2.234 со сторонего компьютера и просмотре arp таблицы, IP имеет мак интерфейса eth0. Что сделано не так?

> А сделать это надо для того, чтобы на шлюзе было два канала, разные IP и разные маки

создаете бридж
brctl addbr br0
создаете tap0
tunctl -t tap0
втыкаете в ваш бридж eth0 и tap0
brctl addif br0 eth0 (тут бридж получит автоматом MAC от eth0)
brctl addif br0 tap0
прописываете на br0 то, что раньше писали на eth0
на tap0 соответственно второй айпи
вместо eth0 теперь br0.

Viper> Что сделано не так?
Не, vlan не поможет. Я так кинул не подумав.

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