The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Руководство по настройке сети в VirtualBox (virtual virtualbox linux)


<< Предыдущая ИНДЕКС Исправить src / Печать Следующая >>
Ключевые слова: 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.

<< Предыдущая ИНДЕКС Исправить src / Печать Следующая >>

Обсуждение [ RSS ]
  • 1, Артем (??), 13:43, 03/11/2011 [ответить]  
  • +/
    Забыли упомянуть, что NAT не пробрасывает порты, по умолчанию заблокированные системой т.е. если поднять на виртуалке Apache, то через 80 порт вы до него не достучитесь.
     
  • 2, Миха (??), 06:24, 12/07/2015 [ответить]  
  • +/
    а эта концовка откуда? /etc/conf.d/net где начало?
     
  • 3, Нуржан (?), 08:57, 05/10/2015 [ответить]  
  • +/
    tap_vbox что это и от куда оно?? я просто нуб в этом и мне для ssh  нужно мост настроить
     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру