Ключевые слова:virtual, virtualbox, linux, (найти похожие документы)
Автор: Leonid Evdokimov <[email protected]>
Date: Mon, 3 Feb 2010 17:02:14 +0000 (UTC)
Subject: Руководство по настройке сети в VirtualBox
Оригинал: http://darkk.livejournal.com/43813.html
Неоднократно я встречал вопросы людей, которые не могут по той или иной
причине правильно настроить работу с сетью в виртуальной машине
VirtualBox используя Linux в качестве HOST-машины, поэтому и
появилось это руководство.
VirtualBox-2.0.4 (я использую OSE редакцию) предоставляет следующие
возможности работы с сетью при настройке виртуального сетевого
адаптера:
* NAT
* Internal Network
* Host interface
И не смотря на то, что VirtualBox предоставляет свои скрипты для
управления этими интерфейсами (VBoxAddIf, VBoxDeleteIf и VBoxTunctl), я
рассмотрю подробнее каждый из способов в контексте интеграции его в
систему управления сетевыми интерфейса дистрибутива на примере Gentoo
-- это позволит вам более гибко сконфигурировать сетевые интерфейсы не
нарушая методы конфигурации сети принятые в вашем дистрибутиве.
NAT
NAT -- самый простой из способов подключения виртуальной машины к сети.
Виртуальная машина будет видна в реальной сети под тем же адресом, что
и HOST-машина, т.к. VirtualBox будет производить трансляцию сетевых
адресов (NAT).
Из известных проблем с NAT в VirtualBox можно отметить тот факт, что
трансляция производится только для протоколов TCP и UDP,
соответственно, банальный ping работать будет не корректно, и,
например, работы VPN основного на pptp ожидать тоже не приходится.
Еще один минус состоит в том, что нетривиально становится подключиться
к сетевым сервисам самой виртуальной машины. Как ниже написал
[info] curl_init, это возможно с помощью использования
VBoxManage, например для проброса TCP-порта host:2223 на guest:2222
нужно сделать:
$ VBoxManage setextradata guest0 "VBoxInternal/Devices/pcnet/0/LUN#0/Config/fwdname/Protocol" TCP
$ VBoxManage setextradata guest0 "VBoxInternal/Devices/pcnet/0/LUN#0/Config/fwdname/GuestPort" 2222
$ VBoxManage setextradata guest0 "VBoxInternal/Devices/pcnet/0/LUN#0/Config/fwdname/HostPort" 2223
Но мне такой способ кажется ужасным чуть менее чем полностью. К тому же
он требует перезапуска виртуальной машины для того, чтоб изменения
вступили в силу.
Резюмируя, могу порекомендовать использование NAT в VirtualBox только в
том случае, если требования к доступу к сети из виртуальной машины
ограничиваются серфингом и почтой. :)
Internal Network
Используется для взаимодействия виртуальных машин между собой и
представляет некоторое подобие виртуального сетевого коммутатора
(switch), который никак не взаимодействует с реальным миром. В
принципе, всё, что можно сделать с помощью Internal Network, может быть
реализовано и на базе Host Interface, но у данного способа есть два
преимущества (согласно руководству пользователя VirtualBox):
* Безопасность -- пакеты не проходят через сетевую подсистему
host-машины и, соответственно, их технически сложнее прослушать.
* Скорость -- ввиду того, что не эксплуатируется сетевой стек
физической машины можно достичь несколько большей
производительности.
На самом же деле безопасность мнимая -- т.к. пользователь имеющий
доступ администратора к host-машине может исследовать любой участок
памяти и, соответственно, вопрос лишь в увеличении технической
сложности прослушивания. Возможен также вариант, что для прослушивания
трафика Internal Network достаточно даже прав пользователя, который
запускает виртуальную машину.
Прирост производительности по сравнению с Host Interface мне не
известен, возможно, он исключительно теоретический.
Но с другой стороны в руководстве не упомянут еще один существенный
плюс -- простота конфигурации виртуальной сети между виртуальными
машинами.
В любом случае, данный способ не позволяет подключить виртуальную
машину к физической сети и интереса для нас более не представляет.
Host interface
"Но то все присказка была, а теперь начинается сказка".
По настоящему широкие возможности конфигурации сети дает использование
Host interface и именно с ним обычно связаны наибольшие трудности.
Сразу оговорюсь, все примеры конфигурирования сети будут приводиться в
двух вариантах: для init-скриптов Gentoo (baselayout-1) и
консольных инструментов для конфигурации сети, т.е. ifconfig, brctl,
tunctl и прочих.
Существует две типичных конфигурации сети в таком случае:
непосредственное подключение виртуальной машины к реальной сети через
мост (bridge) или использования NAT, но уже не описанными выше
средствами VirtualBox, а с использованием NAT в ядре Linux. Эти две
конфигурации мы и рассмотрим.
Для настройки tun/tap интерфейса и bridge нам потребуется tunctl и
brctl входящие в пакеты sys-apps/usermode-utilities и
net-misc/bridge-utils соответственно.
Также вместо tunctl можно использовать openvpn или VBoxTunctl,
поставляемый с VirtualBox: "VBoxTunctl is identical to tunctl from
Usermode Linux except for the name". Но init-скрипты Gentoo на
настоящий момент приспособлены для openvpn или tunctl и про
существование VBoxTunctl не знают.
Предположим, что физическая сеть у нас подключена в host-системе через
интерфейс eth0 и host interface у нас будет назван tap_vbox. Имя
tap_vbox и нужно будет использовать в качестве имени сетевого
интерфейса в VirtualBox.
Host interface и сетевой мост
Приведу выдержку из своего /etc/conf.d/net
tuntap_tap_vbox="tap"
config_tap_vbox=( "null" )
tunctl_tap_vbox="-u darkk"
config_eth0=( "null" )
depend_br0() {
need net.eth0 net.tap_vbox
}
bridge_br0="eth0 tap_vbox"
config_br0=( "dhcp" )
После чего я запускаю sudo /etc/init.d/net.br0 start, с помощью
/etc/init.d/net.br0 status убеждаюсь, что bridge запущен и работает
(это стоит сделать ввиду того, что некоторая часть инициализации может
быть запущена в фоновом режиме), и загружаю виртуальную машину. Сеть в
виртуальной машине запускается и работает.
Стоит обратить внимание на то, что интерфейс eth0 не конфигурируется, а
вместо него настраивается br0 (в данном случае, по DHCP). И то,
настройка интерфейса br0 нужна для того и только для того, чтобы
подключить host-систему к сети, подключенной к eth0.
В командной строке те же результаты достигаются примерно такой
последовательностью команд:
$ sudo ifconfig eth0 up
$ sudo tunctl -u $USER -t tap_vbox
Set 'tap_vbox' persistent and owned by uid 1000
$ sudo ifconfig tap_vbox up
$ sudo brctl addbr br0
$ sleep 1m; brctl show
$ sudo brctl addif br0 eth0
$ sudo brctl addif br0 tap_vbox
После чего сеть опять таки работает.
Уверен, вы удивлены -- зачем же сделано sleep 1m; brctl show, объясняю
выдержкой из /var/log/messages:
sudo: darkk : TTY=pts/5 ; PWD=/home/darkk ; USER=root ; COMMAND=/sbin/brctl addbr br0
rc-scripts: We only hotplug for ethernet interfaces
Такая запись появлялась в случае, если в /etc/conf.d/net уже
существовала конфигурация моста для интерфейса br0, при этом мост
удалялся через несколько секунд после запуска, что выглядело достаточно
странно.
Можно было бы просто удалить полностью информацию о br0 из
/etc/conf.d/net, но тогда появляется другой сюрприз:
sudo: darkk : TTY=pts/5 ; PWD=/home/darkk ; USER=root ; COMMAND=/sbin/brctl addbr br0
rc-scripts: Configuration not set for br0 - assuming DHCP
dhcpcd[29405]: br0: dhcpcd 4.0.2 starting
dhcpcd[29405]: br0: broadcasting for a lease
dhcpcd[29405]: br0: timed out
dhcpcd[29405]: br0: trying to use old lease in `/var/lib/dhcpcd/dhcpcd-br0.lease'
dhcpcd[29405]: br0: probing for an IPV4LL address
dhcpcd[29405]: br0: checking 169.254.215.238 is available on attached networks
dhcpcd[29405]: br0: using IPv4LL address 0.0.0.0
В итоге на время экспериментов я просто добавил в /etc/conf.d/net
строчку:
config_br0=( "null" )
и закоментировал все другие упоминания о конфигурации br0.
Если же всё настроено и должно работать, но не работает, то стоит еще
проверить настройки sysctl -a | grep ^net.bridge.bridge-nf и настройки
iptables, возможно, пакеты блокируются на этом уровне.
Для работы моста включение net.ipv4.ip_forward не требуется, если
продвинутая фильтрация пакетов на мосту вам не нужна -- все опции
net.bridge.bridge-nf* также можно отключить сбросив их в ноль.
Еще одна занимательная грабля состоит в том, что для построения моста
не получается использовать беспроводной адаптер из-за особенностей
работы wi-fi: при использовании моста MAC-адреса пакетов не меняются,
соответственно, точка доступа будет получать как пакеты с MAC-адресом
виртуальной сетевой карты так и с MAC-адресом вашей настоящей карты --
у меня есть подозрение, что при работе с wi-fi в managed режиме (при
использовании точки доступа) такая ситуация не предусмотрена, т.к.
MAC-адрес виртуальной сетевой карты должен быть предварительно
зарегистрирован на точке доступа (associated with Access Point).
За более подробной информацией рекомендую поизучать wiki проекта
aircrack-ng, например статью про утилиту aireplay-ng.
Один из способов обойти это ограничение -- настроить arp-proxy, но
работу с arp-proxy я описывать не буду. Другой способ -- использовать
NAT вместо моста, о чем и написано в следующем параграфе.
Host interface и NAT
И снова выдержка из моего /etc/conf.d/net
tuntap_tap_vbox="tap"
config_tap_vbox=( "192.168.128.1/24" )
tunctl_tap_vbox="-u darkk"
Или альтернативный путь:
$ sudo tunctl -u $USER -t tap_vbox
Set 'tap_vbox' persistent and owned by uid 1000
$ sudo ifconfig tap_vbox 192.168.128.1 up
После чего нужно настроить в виртуальной машине использование
192.168.128.1 в качестве шлюза по-умолчанию, присвоить виртуальной
машине IP-адрес (в guest-системе), например, 192.168.128.2 и настроить
NAT на host-машине по любому другому руководству.
Если другие руководства читать невыносимо лень -- можете попробовать
такие команды (но я настоятельно рекомендую всё-таки изучить
какое-нибудь другое руководство):
$ sudo sysctl net.ipv4.ip_forward=1
$ sudo iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
$ sudo iptables -t filter -I FORWARD --in-interface tap_vbox --out-interface eth0 \
--source 192.168.128.2 -j ACCEPT
$ sudo iptables -t filter -I FORWARD --in-interface eth0 --out-interface tap_vbox \
--destination 192.168.128.2 -j ACCEPT
Если же вам надо, чтобы виртуальная машина была полноправным членом
сети -- можно добавить alias на eth0 и настроить несколько более
сложный NAT, но это уже выходит за рамки данного HOWTO.
Забыли упомянуть, что NAT не пробрасывает порты, по умолчанию заблокированные системой т.е. если поднять на виртуалке Apache, то через 80 порт вы до него не достучитесь.
