Дополнительные советы по Virtualbox и Vagrant для сетей VLAN, PXE и Hostonly
Первоначально это было сделано для отдельных машин, работающих за интерфейсом NAT. Позже была добавлена поддержка hostonly-network, что открыло возможность одновременного общения нескольких хостов по частной сети.
Но что, если настройка сети производства намного сложнее, чем эта? В этом посте я собираюсь объяснить, как воспроизвести следующую сетевую настройку в бродячей установке:
Настройка сети
HOST | | eth2 eth2 (NAT) (NAT) | | [ Gateway ] [ Mgmt Host] [Servers1,2] br10 br10 eth3 br0 (eth0.10, (eth0.10, (eth0 eth1.10) eth1.10) eth1) vboxnet0 vboxnet0 vboxnet1 vboxnet1
Это довольно типичная производственная установка:
- он действует как входящий / исходящий межсетевой экран, прокси-сервер squid, nginx и т. д.
- у него есть два рабочих интерфейса eth0, eth1, которые VLAN-ed (ID 10) и соединены вместе
- подключен к шлюзу для внутри и снаружи трафика
- содержит все необходимые инструменты для управления серверами, dhcp, tftpboot и т.д ..
- все серверы устанавливаются через хост mgmt
- server1 будет установлен только через PXE
- server2 не будет подключен диск и будет загружаться из сети каждый раз
Подготовка базовой коробки
Почти все базовые блоки предполагают, что интерфейс DHCP для интерфейса NAT находится на интерфейсе eth0. Перемещение интерфейса NAT на eth2 требует, чтобы вы изменили / etc / network / interfaces, чтобы указать, что dhcp выполняется на eth2, а eth0, eth1 не являются dhcp. В противном случае загрузка будет очень медленной, ожидая таймаута, что приведет к отсутствию IP-адресов.
Мы использовали Veewee для добавления другого сценария postinstall, чтобы изменить файл / etc / network / interfaces в нужное нам состояние. В результате ‘squeeze64’
sed -i -e "s/eth0/eth2/" /etc/network/interfaces
Hostonly сети в Вагранте
В то время как Vagrant поддерживает сетевые соединения только для хоста , он предполагает, что ему необходимо назначить интерфейсу IP-адрес. В нашем случае интерфейсы eth0, eth1 не получают IP-адрес, только мост получает IP-адрес.
Также, используя встроенную в vagrant поддержку hostonly для сетей, мы обнаружили, что она изменила порядок интерфейсов: кажется, что она динамически удаляет все интерфейсы хоста и воссоздает их.
- добавление наших интерфейсов hostonly к нашей «базовой коробке» с помощью команд VBoxManage
- экспортировать его с помощью подкоманды vagrant basebox export
И, таким образом, создать бродячую коробку ‘gateway.box’ и ‘manager.box’.
IFTYPE="virtio" VBoxManage modifyvm squeeze64 --nic1 hostonly VBoxManage modifyvm squeeze64 --nic2 hostonly VBoxManage modifyvm squeeze64 --nic3 nat VBoxManage modifyvm squeeze64 --nic4 none VBoxManage modifyvm squeeze64 --macaddress1 auto VBoxManage modifyvm squeeze64 --macaddress2 auto VBoxManage modifyvm squeeze64 --macaddress3 auto VBoxManage modifyvm squeeze64 --nictype1 $IFTYPE VBoxManage modifyvm squeeze64 --nictype2 $IFTYPE VBoxManage modifyvm squeeze64 --nictype3 $IFTYPE VBoxManage modifyvm squeeze64 --cableconnected2 off VBoxManage controlvm squeeze64 setlinkstate2 off VBoxManage modifyvm squeeze64 --hostonlyadapter1 vboxnet0 VBoxManage modifyvm squeeze64 --hostonlyadapter2 vboxnet0 rm squeeze64.box bundle exec vagrant basebox export squeeze64 mv squeeze64.box boxes/manager.box bundle exec vagrant box remove 'manager' bundle exec vagrant box add 'manager' 'boxes/manager.box
Для управляющего узла:
IFTYPE="virtio" VBoxManage modifyvm squeeze64 --nic1 hostonly VBoxManage modifyvm squeeze64 --nic2 hostonly VBoxManage modifyvm squeeze64 --nic3 nat VBoxManage modifyvm squeeze64 --nic4 hostonly VBoxManage modifyvm squeeze64 --macaddress1 auto VBoxManage modifyvm squeeze64 --macaddress2 auto VBoxManage modifyvm squeeze64 --macaddress3 auto VBoxManage modifyvm squeeze64 --macaddress4 auto VBoxManage modifyvm squeeze64 --nictype1 $IFTYPE VBoxManage modifyvm squeeze64 --nictype2 $IFTYPE VBoxManage modifyvm squeeze64 --nictype3 $IFTYPE VBoxManage modifyvm squeeze64 --nictype4 $IFTYPE VBoxManage modifyvm squeeze64 --cableconnected2 off VBoxManage controlvm squeeze64 setlinkstate2 off VBoxManage modifyvm squeeze64 --hostonlyadapter1 vboxnet0 VBoxManage modifyvm squeeze64 --hostonlyadapter2 vboxnet0 VBoxManage modifyvm squeeze64 --hostonlyadapter4 vboxnet1 mv squeeze64.box manager.box bundle exec vagrant box remove 'manager' bundle exec vagrant basebox export squeeze64 mv squeeze64.box boxes/manager.box bundle exec vagrant box add 'manager' 'boxes/manager.box'
Адаптация Vagrant для использования eth2 для NAT
Не указав сеть hostonly в Vagrantfile, сохранил порядок и имена интерфейсов сетей hostonly без изменений. Но по умолчанию vagrant предполагает, что ему нужно установить сопоставление ssh-порта NAT на eth0. Чтобы указать на eth2, вы можете указать адаптер, явно добавив отображение ssh portforwarding в Vagrantfile.
config.vm.forward_port("ssh",22,2222, true,:adapter => 2>)
Поддержка VLAN в Virtualbox
Я ожидал, что VLAN будет работать из коробки с Virtualbox, но это не так.
По какой-то причине и шлюз, и менеджер не могли общаться друг с другом. Я бы увидел, что пакеты приходят с обеих сторон на интерфейсах, но это просто не будет работать.
После некоторых поисков я нашел этот пост на VLAN Stripping в Virtualbox и его исследованиях .
Оказывается, поставщики сетевых драйверов Intel Pro, предоставляемые Virtualbox, удаляют теги VLAN. В блоге предлагается изменить типы интерфейса на более старый AMD PCNet Fast III. Это действительно сработало.
Но при больших всплесках сетевого трафика я столкнулся с предупреждением ядра NETDEV Watchdog: eth0: Тайм-аут передачи .
К счастью, в сетевой документации для Virtualbox есть третий вариант : драйверы virtio. Сначала я подумал, что это невозможно использовать, потому что я работал на Mac, но virtio являются драйверами внутри гостевой ОС, а не на хосте.
Вот почему в приведенных выше модификациях коробки мы устанавливаем nictype в virtio
VBoxManage modifyvm squeeze64 --nictype1 virtio
Соединение в Virtualbox
Много раз, воссоздавая vms, я заметил, что иногда мост не работает. Когда я посмотрел в графическом интерфейсе VirtualBox, я заметил, что иногда virtualbox указывает, что активное сетевое соединение находится на eth0 в шлюзе и на eth1 в диспетчере. Чтобы подделать поведение и иметь их обоих на тех же интерфейсах, я отключил кабель на eth1.
VBoxManage modifyvm squeeze64 --cableconnected2 off VBoxManage controlvm squeeze64 setlinkstate2 off
Теперь мостовые сетевые интерфейсы всегда могут видеть друг друга.
PXE загрузка в Virtualbox
Если вы хотите использовать pxe-загрузку в virtualbox, обязательно установите пакет расширений. Это будет включать в себя функциональность загрузки PXE.
$ VBoxManage list extpacks Extension Packs: 1 Pack no. 0: Oracle VM VirtualBox Extension Pack Version: 4.1.4 Revision: 74291 Description: USB 2.0 Host Controller, VirtualBox RDP, PXE ROM with E1000 support. VRDE Module: VBoxVRDP Usable: true Why unusable:
Более подробную информацию можно найти в документации Virtualbox
Создание pxe-boot basebox
Для server1 и server2 мы хотим, чтобы они загружались с узла менеджера. Это означает, что мы хотим иметь пустой диск, но с включенной сетевой загрузкой.
VBoxManage modifyvm pxe-server1 --boot4 net
Veewee пока не способен сделать это, но вот команды, которые мы использовали для создания пустого базового блока сетевой загрузки.
VMPATH="/"$(VBoxManage list systemproperties|grep "^Default"| cut -d '/' -f 2-)"/pxe/" DISKPATH="/"$VMPATH/"/pxe.vdi" VBoxManage unregistervm pxe --delete rm -rf "$VMPATH" VBoxManage createvm --name pxe --ostype Debian_64 --register VBoxManage storagectl 'pxe' --name 'IDE Controller' --add ide VBoxManage storagectl 'pxe' --name 'SATA Controller' --add sata --hostiocache off --sataportcount 1 VBoxManage createhd --filename "$DISKPATH" --size 20000 --format VDI VBoxManage storageattach 'pxe' --storagectl 'SATA Controller' --port 0 --device 0 --type hdd --medium "$DISKPATH"
Загрузка PXE на сервер1
Теперь, когда у нас есть базовый ящик загрузки pxe, мы можем начать изменять его следующим образом:
- исправить macaddress, чтобы мы могли поместить их в dhcp
- создать необходимые интерфейсы только для хоста
Поскольку первая загрузка pxe занимает много времени, мы увеличили время ожидания ssh в Vagrantfile
config.ssh.timeout = 1000000 config.ssh.max_tries = 50
Опять же драйвер virtio используется
IF_TYPE=virtio VBoxManage unregistervm pxe-server1 --delete VBoxManage clonevm pxe --name pxe-server1 --register VBoxManage modifyvm pxe-server1 --memory 256 --ostype Debian_64 VBoxManage modifyvm pxe-server1 --nic1 hostonly VBoxManage modifyvm pxe-server1 --nic2 hostonly VBoxManage modifyvm pxe-server1 --nic3 nat VBoxManage modifyvm pxe-server1 --nic4 none VBoxManage modifyvm pxe-server1 --macaddress1 080027BA2DAE VBoxManage modifyvm pxe-server1 --macaddress2 080027BE8E74 VBoxManage modifyvm pxe-server1 --macaddress3 auto VBoxManage modifyvm pxe-server1 --macaddress4 auto VBoxManage modifyvm pxe-server1 --nictype1 $IF_TYPE VBoxManage modifyvm pxe-server1 --nictype2 $IF_TYPE VBoxManage modifyvm pxe-server1 --nictype3 $IF_TYPE VBoxManage modifyvm pxe-server1 --nictype4 $IF_TYPE VBoxManage modifyvm pxe-server1 --cableconnected2 off VBoxManage controlvm pxe-server1 setlinkstate2 off VBoxManage modifyvm pxe-server1 --cableconnected3 off VBoxManage controlvm pxe-server1 setlinkstate3 off VBoxManage modifyvm pxe-server1 --hostonlyadapter1 vboxnet1 VBoxManage modifyvm pxe-server1 --hostonlyadapter2 vboxnet1 VBoxManage modifyvm pxe-server1 --boot4 net rm boxes/pxe-server1.box bundle exec vagrant box remove 'server1' bundle exec vagrant basebox export pxe-server1 mv 'pxe-server1.box' boxes/ bundle exec vagrant box add 'server1' 'boxes/pxe-server1.box'
Исправление mac-адреса моста
Несмотря на то, что мы можем управлять mac-адресом через физические интерфейсы, macaddress моста назначается случайным образом.
auto br0 iface br0 inet dhcp bridge_ports eth0 bridge_maxage 12 bridge_hello 2 bridge_fd 6 bridge_stp on post-up ip link set br0 address 08:00:27:ba:2d:ae
PXE boot для server2
Основное отличие от server1 заключается в том, что server2 всегда загружается из памяти.
Vagrant basebox export ожидает, что диск будет там. Поэтому мы должны назначить его один, даже если он нам не нужен.
Мы также обнаружили, что внутренняя поддержка pxe ограничена, использование ipxe.org позволило нам загружаться со многими специальными параметрами pxe.
Это заставило нас поместить загрузочный код ipxe на первый диск.
VBoxManage convertfromraw ../ipxe/ipxe.usb "$DISKPATH"
И замените диск на него, чтобы он воспроизводился с помощью vagrant export
Полный сценарий создания выглядит следующим образом
VMPATH="/"$(VBoxManage list systemproperties|grep "^Default"| cut -d '/' -f 2-)"/pxe-server2/" DISKPATH="$VMPATH/pxe-server2.vdi" VBoxManage storageattach 'pxe-server2' --storagectl 'SATA Controller' --port 0 --device 0 --medium none VBoxManage closemedium disk "$DISKPATH" --delete VBoxManage unregistervm pxe-server2 --delete rm -rf "$VMPATH" VBoxManage clonevm pxe --name pxe-server2 --register VBoxManage modifyvm pxe-server2 --memory 1024 --ostype Debian_64 VBoxManage modifyvm pxe-server2 --nic1 hostonly VBoxManage modifyvm pxe-server2 --nic2 hostonly VBoxManage modifyvm pxe-server2 --nic3 nat VBoxManage modifyvm pxe-server2 --nic4 none VBoxManage modifyvm pxe-server2 --macaddress1 080027C5DAB8 VBoxManage modifyvm pxe-server2 --macaddress2 0800274020F8 VBoxManage modifyvm pxe-server2 --macaddress3 auto VBoxManage modifyvm pxe-server2 --macaddress4 auto VBoxManage modifyvm pxe-server2 --nictype1 virtio VBoxManage modifyvm pxe-server2 --nictype2 virtio VBoxManage modifyvm pxe-server2 --nictype3 virtio VBoxManage modifyvm pxe-server2 --nictype4 virtio VBoxManage modifyvm pxe-server2 --cableconnected2 off VBoxManage controlvm pxe-server2 setlinkstate2 off VBoxManage modifyvm pxe-server2 --cableconnected3 off VBoxManage controlvm pxe-server2 setlinkstate3 off VBoxManage modifyvm pxe-server2 --hostonlyadapter1 vboxnet1 VBoxManage modifyvm pxe-server2 --hostonlyadapter2 vboxnet1 VBoxManage modifyvm pxe-server2 --boot4 net rm "$DISKPATH" VBoxManage storageattach 'pxe-server2' --storagectl 'SATA Controller' --port 0 --device 0 --medium none VBoxManage closemedium disk "$DISKPATH" --delete VBoxManage convertfromraw ../ipxe/ipxe.usb "$DISKPATH" VBoxManage storageattach 'pxe-server2' --storagectl 'SATA Controller' --type hdd --port 1 --device 0 --medium "$DISKPATH" rm boxes/pxe-server2.box bundle exec vagrant box remove 'server2' bundle exec vagrant basebox export pxe-server2 mv 'pxe-server2.box' boxes/ bundle exec vagrant box add 'server2' 'boxes/pxe-server2.box'
Направляйте ssh в бродячую виртуальную машину через Hostonly IF
Вместо того, чтобы сопоставлять порты с сервером server1 или server2 через NAT, мы сочли полезным поместить интерфейс нашего хоста в сеть hostonly. Это позволило подключиться к сервисам на сервере1, сервере2, например.
VBoxManage hostonlyif ipconfig vboxnet1 --ip 172.168.0.1
А затем настройте, например, свойства ssh сервера server2 следующим образом:
config.ssh.host = "172.168.0.22" config.ssh.port = 22
Вывод:
Чтобы это заработало, нужно немного помассировать, но это возможно:
- по возможности используйте драйвер virtio
- использовать ipxe для загрузки сложных настроек pxe
- использовать hostonly сети для прямого доступа к услугам
Virtualbox+VLAN
Поднял машинку на Virtualbox внутри машины сеть настроил на работу с VLAN. Но, не работает. Хост машина с VLAN работает. Поддерживает ли Virtualbox для Windows VLAN?
petav ★★★★★
13.04.11 20:52:27 MSK
Видимо настроен bridge? Что именно не работает, как проверяли? Тегирование пакетов это не задача VirtualBox’a, а, как я понимаю драйвера сетевой карты.
zolden ★★★★★
( 13.04.11 23:34:10 MSK )
Ответ на: комментарий от zolden 13.04.11 23:34:10 MSK
Да bridge! Нашел в инететинфу что драйвера карт Интел которые имулируютcz virtualbox не могут работать с VLAN и нужно использовать pcnet. Использую ситуация не изменилась. Проверяли так на хост машине (windows) подключались к VLAN все работает. Затем к VLAN подключались на виртуальной машине (zeroshell) пинги не ходят.
petav ★★★★★
( 14.04.11 00:04:39 MSK ) автор топика
Ответ на: комментарий от petav 14.04.11 00:04:39 MSK
Не совсем понятна задача и исходные условия. Как я это понимаю: у вас сделан VLAN интерфейс на хосте. Через него настроен мост гостя. И при этом ничего не работает. Т.е. со свича до хоста у вас идёт транк из которого вам нужен конкретный VLAN. Так? Сам ни разу не пробовал, но если использовать hybrid, а не trunk, то VLAN интерфейс на хосте идейно не нужен будет. Ну, и, если дальше теоритезировать, то мост сделанный на VLAN интерфейсе не требует настройки VLAN в госте, пакеты же и так в этом VLAN’е ходят.
zolden ★★★★★
( 14.04.11 00:34:54 MSK )
Ответ на: комментарий от zolden 14.04.11 00:34:54 MSK
Поясню: 1) Есть switch 2) В switch воткнут провайдер 3) В switch воткнуть компьютер Windows одним кабелем 4) На компьютере Windows bridge к VirtualBox+Маршрутизатор 4) В switch воткнуто еще 10 компьютеров 5) На switch создаю VLAN из порта на котором провайдер и порта к Windows. Порт провайдера untag, порт Windows tag 6) В виртуальной машине поднимаю VLAN.
Так вот если VLAN поднять на Windows то все работает (для проверки настройки хаба делаю), а если на Маршрутизаторе то нет.
petav ★★★★★
( 14.04.11 00:46:24 MSK ) автор топика
Ответ на: комментарий от petav 14.04.11 00:46:24 MSK
На виртуальной машине tcpdump видит ВЛАН теги или нет ?
Tok ★★
( 14.04.11 08:13:49 MSK )
Ответ на: комментарий от Tok 14.04.11 08:13:49 MSK
>На виртуальной машине tcpdump видит ВЛАН теги или нет ?
а как их там различить.
petav ★★★★★
( 14.04.11 12:48:45 MSK ) автор топика
Ответ на: комментарий от petav 14.04.11 12:48:45 MSK
tcpdump -i eth0 vlan Tok ★★
( 14.04.11 12:55:51 MSK )
Ответ на: комментарий от petav 14.04.11 12:48:45 MSK
root@xxxxx:/home/tok# tcpdump -i eth0 vlan -q -ttt -n -c 50 tcpdump: WARNING: eth0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 000000 vlan 5, p 0, IP 194.xxx.xxx.xx.22 > 194.xxx.xxx.xx.44204: tcp 240 000336 vlan 5, p 0, IP 194.xxx.xxx.xxx.22 > 194.xxx.xxx.xx.44204: tcp 112 000147 vlan 22, p 0, IP 91.198.101.35.25 > 194.xxx.xxx.xxx.49183: tcp 0 000016 vlan 22, p 0, IP 96.44.177.18.1868 > 194.xxx.xxx.xxx.3128: tcp 36 000086 vlan 22, p 0, IP 194.xxx.xxx.xx.3128 > 96.44.177.18.1868: tcp 0 000036 vlan 22, p 0, IP 60.248.16.57.25 > 194.xxx.xxx.xxx.57790: tcp 0 000184 vlan 22, p 0, IP 194.xxx.xxx.xxx.42377 > 46.45.155.2.25: tcp 36 000158 vlan 22, p 0, IP 118.168.141.165.1640 > 194.xxx.xxx.xx.3128: tcp 37 000358 vlan 4, p 0, IP 10.10.4.1.4214 > 178.162.248.79.80: tcp 0 000058 vlan 22, p 0, IP 194.xx.xx.xx.4214 > 178.162.248.79.80: tcp 0 000094 vlan 500, p 0, arp who-has 109.87.240.113 tell 109.87.240.254
Tok ★★
( 14.04.11 13:04:18 MSK )
Ответ на: комментарий от Tok 14.04.11 13:04:18 MSK
спасибо. Сейчас страшно с VLAN играть удаленно нахожусь. Спасибо за наводку! Доберусь до места проверю.
petav ★★★★★
( 14.04.11 13:25:15 MSK ) автор топика
Ответ на: комментарий от petav 14.04.11 13:25:15 MSK
И как в итоге разрешилось/не_разрешилось?
У меня тоже проблема. С интелами: пакеты уходят из ВМ нетегированными. С pcnet вроде получше — пакеты тегируются, только вот, возвращаясь от хоста к ВМ становятся нетегированными.
nixtrian ★
( 03.05.11 09:36:35 MSK )
Ответ на: комментарий от nixtrian 03.05.11 09:36:35 MSK
В итоге
VirtualBox было временным решением, не стал морочится, когда понял в чем дело
Как настроить VLAN’ы на виртуальной машине?
Исходные данные:
Физический сервер на Win2012 R2, с встроенным в материнку гигабитным сетевым адаптером Realtek. Сервер подключен к тегированному (802.1q) порту управляемого L3 коммутатора. На сервере при помощи утилиты Realtek Ethernet Diagnostic Utility на основе одного физического сетевого адаптера подняты четыре виртуальных Vlan’а (каждый в разной подсети). В результате физический сервер является членом всех четырех vlan’ов, и ко всем имеет прямой доступ одновременно.
Необходимо:
На физическом сервере с помощью Vbox или Vmware поднять виртуальный сервер на Ubuntu 14.04 Server и настроить его таким образом, чтобы он (виртуальный сервер) имел постоянный доступ одновременно ко всем vlan’ам физической локальной сети (как и физический сервер).
Кто-нибудь сталкивался с этим, как осуществить?
- Вопрос задан более трёх лет назад
- 3045 просмотров
Amin ‘s Blog
Добрый день, приветствую читателей моего скромного блога. Если вам когда-либо доводилось работать с виртуальными машинами 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.
На этом я жечь заканчиваю, всем добра и счастья.