VirtualBox и тегированный траффик

Posted: 2012-11-02 in IT, Networks, Software
Метки:, ,

Добрый день, приветствую читателей моего скромного блога. Если вам когда-либо доводилось работать с виртуальными машинами VirtualBox, то вы наверняка настраивали и сеть для ВМ. Чаще всего используются следующие три варианта — NAT (самое простое в настройке, если нужен «просто инет внтури»), Bridge (cетевой мост) и intnet (внутренняя сеть между ВМ и только). Но обычно порты при этом работают в access-режиме, то есть без всяких тегов. Заметка же посвящена именно прохождению тегированного траффика. Если интересны мои изыскания на этот счет — радости просим. …

Прежде всего скажем, когда нам вообще может понадобиться такое зверское извращение, как тегированный траффик внутри ВМ. Первое — это тестовые стенды для сетевиков-затейников :D. Второе — если надо запустить кривой софт, который должен работать сразу с несколькими сетями и по немаршрутизируемым протоколам (да, местами такое извращение всё ещё живо и даже пытается шевелиться). Самый простой путь — направлять в ВМ траффик без тегов. Но для этого надо будет для каждого проброшенного внутрь влана занять один сетевой интерфейс ВМ, создать влан в хостовой системе, сбриджить их, и так для каждого влана. Скриптится это так себе, конфиг сильно усложнен, изнутри ВМ управлять проброшенными вланами становится невозможно, да и к тому же для Виртуалбокса больше 4-х интерфейсов на одну ВМ просто так не сделать. Поэтому мы будем пытаться пробрасывать транк внутрь ВМ «как есть».
Схема стенда такая:

То есть средствами VirtualBox делаем bridge между виртуальной сетевухой ВМ и физическим интерфейсом. Для быстрой смены настроек и конфигурирования вланов я наваял вот такой скриптик:

#!/bin/sh

if='eth0';
d='5';

modprobe 8021q

vconfig add $if 2
vconfig add $if 4095
vconfig add $if 4094
vconfig add $if 3777
vconfig add $if 4
vconfig add $if 666
vconfig add $if 3805
vconfig add $if 3540
vconfig add $if 3541
vconfig add $if 2400

ifconfig $if inet 10.1.1.$d/24
ifconfig $if.2 inet 10.0.2.$d/24
ifconfig $if.4094 inet 10.40.94.$d/24
ifconfig $if.3777 inet 10.37.77.$d/24
ifconfig $if.4 inet 10.0.4.$d/24
ifconfig $if.666 inet 10.6.66.$d/24
ifconfig $if.3805 inet 10.38.05.$d/24
ifconfig $if.3540 inet 10.35.40.$d/24
ifconfig $if.3541 inet 10.35.41.$d/24
ifconfig $if.2400 inet 10.24.0.$d/24 up

Идея проста — вторая и третья цифра строятся из номера влана, а последняя — одна на машину. То есть правим параметры в начале (имя основного интерфейса и последний номер для назначаемых IP), копируем скрипт по машинам и запускаем. На хосте я использую Fedora 17, на VM1 — столь понравившуюся мне для ВМ TinyCore. Про VM2 мы поговорим позже. На федоре (как и вообще на большинстве линуксов) данный скрипт должен сработать сразу и без затей. А вот на TinyCore, в силу её чрезвычайной компактности, поддержка vlan сделана отдельным пакетом (vlan.tcz), который надо поставить и ребутнуться. После добавления модуля прописываем наш скрипт в /opt, если надо — прописываем в загрузку, и сохраняем командой backup.

Теперь клонируем VM1 в VM2, присоединяем VM2 к тому же Host-eth0 как бридж, и проверяем ping-ом, что траффик между виртуалками ходит как через адреса собственно eth0 (нетегированный native-vlan), так и на тегированные сабинтерфейсы.

Потом я выполнил этот скрипт на основной системе (не забываем менять параметр d в скрипте на новой машине, чтобы адреса не пересекались), и обнаруживаем странный баг: В том время, как обычный нетегированный траффик без проблем ходит между ВМ и хостом в любых направлениях, тегированный траффик без проблем ходит только между ВМ. А вот между ВМ и хостом тегированный траффик ходит только в одну сторону — от ВМ к хосту. А обратно — фиг. Является ли это багом виртуалбокса или же результатом неполной настройки основной системы или VirtulBox — пока не выяснил.

Однако даже возможность сделать изолированный транк VM1==VM2 уже вполне годная вещь, и я решил наконец-таки взяться за каку давно откладываемую в долгий ящик вещь — попробовать настроить VLAN-ы на Шindoшs.

Фу-у-х…
Небольшое замечание. Дальше будет много букв, матюгов и картинок. Если вам надо сразу суть — сообщаю: настройка вланов на виндовс — это полный пиздец. Я категорически не рекомендую поднимать вланы на виндовс, если она установлена на реальном железе, и втройне этого не рекомендую делать удаленно, если конечно у вас нет IP-KVM-доступа к машине. Для 3-4 подсетей — честно, проще либо поставить сетевухи, либо на основную машину вкатить линукс, на нем сделать сабинтерфесы, и уже эти сабинтерфейсы сбриджить с интерфейсами ВМ, в которой и будет запущена виндовс. Работать будет лучше, честно 🙂

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

Первым делом гасим ВМ с виндовс (на снапшотим, а именно выключаем), и в свойствах сетевого интерфейса указываем, что эмулируемый тип сетевухи — [Intel PRO/1000 MT Server (82545EM)], иначе виндовс не прицепит нужные драйверы и вланов не будет. Теперь надо скачать хитрожопые дрова с сайта интела, откуда-то отсюда. Получим вот такие файлы:

[Amin@AminCave WindowsVLAN]$ ls -lh
итого 107M
-rw-r--r--. 1 root root 50M Окт 16 00:37 IntelPROWinXP_32_v17.3.exe
-rw-r--r--. 1 root root 58M Окт 16 00:38 IntelPROWinXP_64_v17.3.exe

Впечатлились размером ? Нет ?! Ну тогда вот вам для сведения:

root@TinyCore2:~# df -h | grep -v loop
Filesystem                Size      Used Available Use% Mounted on
rootfs                   80.6M     17.3M     63.4M  21% /
tmpfs                    44.8M         0     44.8M   0% /dev/shm
/dev/sda1               144.3M     40.5M    103.8M  28% /mnt/sda

Да-да, проморгайтесь. Виндовый _драйвер_ под интеловскую сетевуху весит почти в три раза больше, чем TinyCore целиком, с ядром, шеллом, продвинутым роутингом, вланами, файерволом, кроном, сервером DNS/DHCP/TFTP и прочими мелкими плюшками типа grep/vi/mc/top. Пока вы это читали, драйвер я так понимаю у вас уже скачался, а следовательно можно продолжить экзекуцию. Для начала ставим минимум — только драйвер:

Выбрать SNMP Agent можете, но у меня оно сразу выдало вот такую дружественную багу:

Вспомнив, как вообще M$ реализует сетевые протоколы, знакомиться с «Microsoft SNMP Service» как-то сразу расхотелось, и потому я на него забил. Драйвер к счастью поставился без проблем, просит ребута, ребутимся…
И с перекошенным от ненависти фейсом радостно обнаруживаем, что после того, как был заменен стандартный драйвер от M$, все сетевые настройки улетели в теплые края. В случае удалёнки — это 100% потеря управления, так что если вы это запланируете делать на сервере — убедитесь, что в него воткнута IP-KVM консоль или есть кто-то, кто сможет хотя бы базовые настройки восстановить локально. Для создания вланов тут надо открыть свойства сетевой карты в диспетчере устройств, зайти на нужную вкладку и начать добавлять VLAN-ы:

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

Но ! По умолчанию создаются тегированные интерфейсы. Чтобы сделать натив-влан, его надо отдельно добавить:

Почему он у них с VLAN-iD = 0 — без понятия. Но это имена сетевых карт в устройствах. А вот имена сетевых интерфейсов определенно вас порадуют, особенно когда вланов много:

Ну а поскольку виндовс — это дружественная к пользователю автоконфигурируемая система, то она вам и сеть сразу попытается настроить:

Ясен хер, с такой настройкой ничего работать не будет. Но и это ещё пол-беды. Консоль у виндовс — убогая до невозможности, с фиксированной шириной, без масштабирования и переноса строк, из-за чего в cmd.exe совершенно не видно полного имени сетевой карты. Но самый писк и дружественность — это что в графическом интерфейсе иначе, как методом тыка и матюгов, нормально различить интерфейсы (понять, кто в каком влане, а кто — основная сетевая карта, которую вообще ни в коем случае нельзя трогать) — невозможно. Так что сбрасываем вывод команды `ipconfig /all` в текстовый файлик и читаем его внимательно:

Настройка протокола IP для Windows

        Имя компьютера  . . . . . . . . . : testxp
        Основной DNS-суффикс  . . . . . . :
        Тип узла. . . . . . . . . . . . . : неизвестный
        IP-маршрутизация включена . . . . : нет
        WINS-прокси включен . . . . . . . : нет

Подключение по локальной сети 3 - Ethernet адаптер:

        DNS-суффикс этого подключения . . :
        Описание  . . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection - VLAN : VLAN2
        Физический адрес. . . . . . . . . : 08-00-27-9A-C9-0A
        Dhcp включен. . . . . . . . . . . : да
        Автонастройка включена  . . . . . : да
        IP-адрес автонастройки. . . . . . : 169.254.155.21
        Маска подсети . . . . . . . . . . : 255.255.0.0
        Основной шлюз . . . . . . . . . . :

Подключение по локальной сети 4 - Ethernet адаптер:

        DNS-суффикс этого подключения . . :
        Описание  . . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection - VLAN : Trash-VLAN_4094
        Физический адрес. . . . . . . . . : 08-00-27-9A-C9-0A
        Dhcp включен. . . . . . . . . . . : да
        Автонастройка включена  . . . . . : да
        IP-адрес автонастройки. . . . . . : 169.254.87.87
        Маска подсети . . . . . . . . . . : 255.255.0.0
        Основной шлюз . . . . . . . . . . :

Подключение по локальной сети 5 - Ethernet адаптер:

        DNS-суффикс этого подключения . . :
        Описание  . . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection - VLAN : Amin-test-VLAN_#3777
        Физический адрес. . . . . . . . . : 08-00-27-9A-C9-0A
        Dhcp включен. . . . . . . . . . . : да
        Автонастройка включена  . . . . . : да
        IP-адрес автонастройки. . . . . . : 169.254.198.17
        Маска подсети . . . . . . . . . . : 255.255.0.0
        Основной шлюз . . . . . . . . . . :

Подключение по локальной сети 6 - Ethernet адаптер:

        DNS-суффикс этого подключения . . :
        Описание  . . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection - VLAN : VideoNet_VLAN4
        Физический адрес. . . . . . . . . : 08-00-27-9A-C9-0A
        Dhcp включен. . . . . . . . . . . : да
        Автонастройка включена  . . . . . : да
        IP-адрес автонастройки. . . . . . : 169.254.43.183
        Маска подсети . . . . . . . . . . : 255.255.0.0
        Основной шлюз . . . . . . . . . . :

Подключение по локальной сети 7 - Ethernet адаптер:

        DNS-суффикс этого подключения . . :
        Описание  . . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection - VLAN : NetBEUI_CashMachines_VLAN666
        Физический адрес. . . . . . . . . : 08-00-27-9A-C9-0A
        Dhcp включен. . . . . . . . . . . : да
        Автонастройка включена  . . . . . : да
        IP-адрес автонастройки. . . . . . : 169.254.213.166
        Маска подсети . . . . . . . . . . : 255.255.0.0
        Основной шлюз . . . . . . . . . . :

Подключение по локальной сети 8 - Ethernet адаптер:

        DNS-суффикс этого подключения . . :
        Описание  . . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection - VLAN : Fukushima_Devices_VLAN3805
        Физический адрес. . . . . . . . . : 08-00-27-9A-C9-0A
        Dhcp включен. . . . . . . . . . . : да
        Автонастройка включена  . . . . . : да
        IP-адрес автонастройки. . . . . . : 169.254.253.218
        Маска подсети . . . . . . . . . . : 255.255.0.0
        Основной шлюз . . . . . . . . . . :

Подключение по локальной сети 9 - Ethernet адаптер:

        DNS-суффикс этого подключения . . :
        Описание  . . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection - VLAN : PtP-L2-VPN-Filial1_VID3540
        Физический адрес. . . . . . . . . : 08-00-27-9A-C9-0A
        Dhcp включен. . . . . . . . . . . : да
        Автонастройка включена  . . . . . : да
        IP-адрес автонастройки. . . . . . : 169.254.23.185
        Маска подсети . . . . . . . . . . : 255.255.0.0
        Основной шлюз . . . . . . . . . . :

Подключение по локальной сети 10 - Ethernet адаптер:

        DNS-суффикс этого подключения . . :
        Описание  . . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection - VLAN : PtP-L2-VPN-Filial2_VID3541
        Физический адрес. . . . . . . . . : 08-00-27-9A-C9-0A
        Dhcp включен. . . . . . . . . . . : да
        Автонастройка включена  . . . . . : да
        IP-адрес автонастройки. . . . . . : 169.254.77.117
        Маска подсети . . . . . . . . . . : 255.255.0.0
        Основной шлюз . . . . . . . . . . :

Подключение по локальной сети 11 - Ethernet адаптер:

        DNS-суффикс этого подключения . . :
        Описание  . . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection - VLAN : Corporate_WiFi_VID2400
        Физический адрес. . . . . . . . . : 08-00-27-9A-C9-0A
        Dhcp включен. . . . . . . . . . . : да
        Автонастройка включена  . . . . . : да
        IP-адрес автонастройки. . . . . . : 169.254.132.228
        Маска подсети . . . . . . . . . . : 255.255.0.0

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

Обратите внимание, что у основной сетевой карты протокол TCP/IP ВЫКЛЮЧЕН, но включен «Intel Advanced Network Service», а у вланов (в том числе нативного) наоборот. Включить TCP/IP на основной карте вы конечно можете, но после этого работать ничего не будет %) После этого настраиваем наши сетевые интерфейсы (*vlan*) как обычные сетевухи — IP/Mask, GW, DNS.

Соединяем нашу VM2 (теперь уже с виндовс) бриджем с eth0 хостовой системы, также, как и VM1 (с TinyCore). Проверяем — траффик между VM1 и VM2 должен ходить в обе стороны по любому из вланов, а сниффер на Host-eth0 должен видеть тегированный траффик. Что касается взаимодействия с вланами на хосте — то от него внутрь ВМ тегированный траффик также не проходит. Это я буду ковырять позже.

Важное замечание — если вы смените Intel-овскую сетевую плату на плату другого производителя, поменяете модель платы или просто переткнете плату в другой слот — виндовс вполне может «обнаружить новое устройство», и настройки ваших вланов, ясен цезий, не сохранит. Вообще. В принципе, в ошметках реестра конечно поискать можно — но это вовсе не то занятие, которым хочется заниматься в пятницу вечером :D. Это вам не «подходящий к концу своего жизненного цикла» линукс, и даже не *BSD, тут вы правкой одной строки в скрипте точно не отмахаетесь.

Ну и создать влан на влане тут нельзя, так что дважды тегированный траффик не разобрать, пичалька 😀 😀 :D.

На этом я жечь заканчиваю, всем добра и счастья.

Ценный коммент от Karman (касается проброса транка виндовс-виндовс между гостем и хостом): https://aminux.wordpress.com/2015/11/19/microsoft-remember-zombies/#comment-1367

Реклама
- комментарии
  1. anonymous:

    snippets writes:пиздец! меня забанили и это только потому, что я назвал вещи своими именами! браво, Opera, так держать! разрабы Opera жопорукие рукожопы, а Шпаньков их прихвостень, которому попу не вытерли. а где же свобода слова? где толерантность и плюрализм? конечно, легче банить, чем признать распиженность разрабов. модеры my.opera.com такие же придурки. неужно, баня мой акк, они так ничего и не поняли? инет большой, собрать целевую аудиторию против Opera — как не фиг делать. короче, раз они продолжают пиздеть на счет безопасности и безглючности Opera, то со своей стороны я им обещаю DDoS'ы и червей.

  2. Aminux:

    Ну а я здесь причём ? Я к разработчикам Оперы никакого отношения не имею.