Виртуальные машины VirtualBox очень часто используются для тестирования различного программного обеспечения и его взаимодействия между собой. Обычно, таким программам необходим доступ к интернету. Время от времени возникает необходимость протестировать работу программ по сети или даже создать небольшую тестовую лабораторию из виртуальных машин.
В этой инструкции мы рассмотрим как выполняется настройка сети VirtualBox различными способами. Вы узнаете как объединить машины в одну локальную сеть, как дать им доступ к интернету и как связать их с основной системой. Но сначала поговорим о том, как может работать сеть.
Виды сетевых адаптеров VirtualBox
Существует несколько способов как настроить сеть в virtualbox, и каждый из них подходит для лучше для решения одной задачи и меньше для другой. Рассмотрим основные:
Теперь рассмотрим каждый вариант настройки более подробно.
Настройка сети Virtualbox
1. Настройка сети NAT
Здесь почти нет о чем говорить. Получение доступа к сети через NAT включено по умолчанию. Проброс портов я рассматривал в отдельной статье. Но если вы раньше отключали сетевые адаптеры, то чтобы включить NAT обратно достаточно открыть настройки нужной машины:
Перейти на вкладку «Сеть»:
Выбрать один из адаптеров. К виртуальной машине можно подключить несколько адаптеров и это очень удобно, так как вы можете комбинировать вместе адаптер виртуального хоста и NAT чтобы получить преимущества обоих режимов. Дальше вам нужно выбрать пункт «NAT» в списке «Тип подключения».
На вкладке «Дополнительно» вы можете настроить марку устройства адаптера и MAC адрес:
Если вы собираетесь устанавливать туда в Windows, то лучше будет работать Intel PRO/1000 MT Desktop, а для Linux можно оставить AMD PCNet FAST III, так как он поддерживается всеми операционными системами.
2. Настройка сети NAT
Теперь все машины, подключенные к этой сети, будут доступны друг другу, как в VMWare.
3. Настройка адаптера виртуального хоста
Нажмите кнопку «Создать», затем, в появившемся адаптере, напротив пункта DHCP установите галочку «Включен».
Теперь вернитесь к списку виртуальных машин, зайдите в настройки машины, «Сеть»:
Для всех машин, которые вы хотите объединить в одну сеть нужно выбирать один и тот же адаптер хоста. Если вы захотите добавить машинам также доступ в интернет, просто перейдите на вкладку «Адаптер 2», включите его и настройте NAT, как описано в первом пункте.
4. Настройка сетевого моста VirtualBox
В поле «Имя» вам необходимо выбрать сетевой интерфейс, который будет использоваться для связи с внешним миром. Минус такого способа в том, что внешние компьютеры смогут получить доступ к виртуальной машине, а это не очень хорошо с точки зрения безопасности.
5. Внутренняя сеть VirtualBox
Выводы
В этой небольшой статье мы рассмотрели как выполняется настройка сети VirtualBox, как видите, это не так уж сложно, как может показаться на первый взгляд, несмотря на операционную систему, которую вы используете. В большинстве случаев достаточно сети NAT, но иногда может понадобиться виртуальный адаптер хоста, все же остальные режимы используются намного реже.
Задаём виртуальной машине IP по MAC без использования DHCP
В статье рассказывается о использовании скриптов для CentOS и Windows XP, которые устанавливают IP в соответствии с MAC сетевого интерфейса VM, а также о сложностях управления сетевым интерфейсом в Windows
Система, которую мы разрабатываем, очень активно работает с виртуальными машинами. Когда ядру системы требуется очередная машина, копируется шаблонный образ, и запускается эта копия. Таким образом, одновременно может работать очень много копий по сути одной и той же машины.
Конечно, в момент запуска каждая виртуальная машина идентична шаблонной. В том числе наследуются и установленные параметры сети. Все виртуальные машины работают в одной подсети, а значит, они не должны пользоваться тем статическим IP, который достался им от шаблонной машины — иначе будут возникать конфликты. То есть каждая машина должна получить собственный IP. Казалось бы, решение очень простое — использовать DHCP сервер и динамические IP.
Спойлер: собственно, самое интересное — в пунктах 3) и 5), остальное — для тех, кто захочет увидеть всю картину.
1. Для чего нам нужны виртуальные машины
Наш проект, Nerrvana, выполняет функциональные тесты сайтов в разных браузерах. Тесты эти работают со специальным фреймворком для функционального тестирования — Selenium, который позволяет эмулировать действия пользователя в брaузере (клики по элементам, движения мышью, ввод символов, чтение текста), делать скриншоты страниц и некоторые другие вещи. Тест сайта представляет собой последовательность действий, которые мог бы сделать на сайте пользователь, и проверок, что результат этих действий — точно такой, как ожидается. Например, простейший тест — логин на сайт. Необходимо открыть страницу логина, ввести логин, пароль, нажать «Ввод», и убедиться, что мы залогинены — скажем, увидев стандартное приветствие. Все знают, что браузеры могут совершенно по-разному отображать и работать с одной и той же страницей, и поэтому имеет смысл выполнить одинаковые тесты в наиболее популярных браузерах. Как уже говорилось, именно этой работой и занимается наша система.
Тесты в выбранных браузерах выполняются одновременно и совершенно независимо друг от друга. Выполнение теста в одном из браузеров мы назвали спеком (speck). То есть, допустим, если я хочу выполнить тест логина на браузерах IE 8 и FF 3.6, наша система сделает два независимых спека — выполнит код тестов с использованием выбранных браузеров. Не сильно вдаваясь в подробности, скажу, что для работы каждого спека мы создаём как минимум две виртуальные машины. Одна машина, «хаб», будет заниматься собственно выполнением тестов — там есть Java и PHP, на которых должны быть написаны тесты. На второй машине, «тестере», работает Selenium RC и нужный браузер. Через Selenium RC происходит взаимодействие между тестами и браузером. После выполнения каждого спека виртуальные машины, на которых он работал, уничтожаются.
Так как одновременно работающих тестов может быть много, и каждый может использовать несколько спеков, виртуальных машин тоже может работать относительно много — 50, к примеру.
2. Проблема одинаковых статических адресов при запуске нескольких клонов VM
Для каждого типа виртуальных машин имеется шаблонный образ. Когда ядру системы требуется очередная машина, этот образ копируется, и запускается копия образа — сам образ остаётся неизменным. Таким образом, одновременно может работать очень много копий по сути одной и той же машины.
И тут появляется некоторая проблема. Естественно, в момент запуска каждая виртуальная машина абсолютно идентична шаблонной — ведь все данные хранятся в образе, в который нельзя внести изменений. В том числе наследуются и установленные параметры сети. Так как все виртуальные машины работают в одной подсети, совершенно очевидно, что они не должны пользоваться тем статическим IP, который достался им от шаблонной машины — иначе будут возникать конфликты адресов. То есть каждая машина должна динамически получить собственный IP. Казалось бы, решение очень простое — использовать DHCP сервер, который и выдаст каждой машине уникальный адрес.
Однако, не всё так просто. Дело в том, что ядро системы активно взаимодействует с виртуальными машинами. Оно должно проделать просто кучу работы с ними: например, убедиться, что виртуальные машины успешно стартовали, запустить Selenium RC на тестере, загрузить на хаб и выполнить сами тесты, следить за их выполнением, а потом получить обратно результаты (скриншоты, логи и т.д.). Работа ведётся через ssh. Т.е. ядро системы, как ни крути, должно знать IP-адреса машин, которые только что были запущены по её требованию.
Мы видели два подхода к решению задачи: 1) После того, как виртуальная машина поднялась, она получает случайный адрес от DHCP, и затем каким-то образом регистрирует себя в базе — т.е. указывает, что я — машина такого-то типа, получила от DHCP такой-то адрес. 2) Каким-то образом ядро даёт понять виртуальной машине, какой адрес ей следует использовать, т.е. соответствие IP — виртуальная машина имеется ещё до запуска машины.
Первый вариант казался нам довольно сложным по нескольким причинам. Этот вариант делал VM слишком независимыми от ядра, появлялась лишняя связь — от виртуальной машины к базе, появлялись сложности с сопоставлением запрошенных и зарегистрированных VM, и некоторые проблемы, связанные с архитектурой ядра. Второй вариант нам нравился куда больше, потому что ядро сразу получало полный контроль над VM, а не оказывалось в подвешенном состоянии в ожидании, пока VM сама зарегистрируется.
3. Кодируем IP в MAC
Как же воздействовать на ещё не запущенную машину, чтобы сообщить ей будущий ip-адрес? Мы нашли такой способ: при запуске виртуальной машины можно задать MAC-адрес виртуальной сетевой плате. А сама виртуальная машина может в любой момент его узнать. То есть MAC можно использовать как носитель информации о IP (или о чём-нибудь ещё).
Осталось заставить машину получить нужный IP, соответствующий её MAC. Это опять-таки можно сделать двумя способами.
4. Выделение IP по MAC: DHCP
Первый способ довольно очевиден. Мы запустим DHCP сервер, который будет настроен так, чтобы выдавать IP по MAC-адресу в соответствии с описанным способом кодирования.
Сценарий работы будет выглядеть так: 1) Ядру требуется VM. 2) Ядро просматривает пул IP-адресов, выбирает первый незанятый IP (например, 10.4.0.15), и преобразует его в MAC (00:16:3E:04:00:0F) 4) Ядро копирует шаблонный образ VM нужного типа, подготавливает файл конфигурации VM (в котором указывает в том числе и полученный MAC) 5) Ядро запускает VM 6) VM обращается к DHCP за адресом, тот сверяется с таблицей соответствия MAC/IP, и выдаёт IP 10.4.0.15. 7) Ядро в это время периодически пингует 10.4.0.15, и, получив ответ, начинает работать с виртуальной машиной (конечно, предварительно дождавшись старта sshd)
— требуется DHCP сервер — если мы переедем в другую подсеть или получим другой пул IP-адресов, придётся менять конфигурацию не только ядра, но и DHCP + используется стандартный подход к получению IP
5. Выделение IP по MAC: скрипт mac2ip
Второй способ менее очевиден и требует некоторой дополнительной работы. Он заключается в том, что VM при старте выполнит специальный скрипт, который получит MAC, преобразует его в IP, и назначит сетевой плате. Сценарий работы, таким образом, будет практически таким же — изменится только пункт 6. Он будет выглядеть так:
6) VM вычисляет свой IP на основании своего MAC, и устанавливает его перед стартом интерфейса.
+ не требуется дополнительное звено в виде DHCP и хранения там таблицы соответствия MAC-IP. — для каждой ОС потребуется свой скрипт mac2ip
Мы реализовали именно этот вариант. Мы работаем с виртуальными машинами с CentOS 5.6 и Windows XP PRO SP3, и поэтому нам нужно было два скрипта mac2ip — для каждой из систем. Рассмотрим оба скрипта.
a) Linux
И заставляем запускаться этот скрипт до запуска network.
b) Windows
Та же самая работа в Windows XP делается куда более заумными путями. Возможно, со временем найдётся более эффективный способ преобразования MAC в IP.
Первая проблема, с которой я столкнулся — это невозможность относительно лёгкими путями изменить адрес интерфейса ДО его включения. Таким образом, шаблонная VM должна иметь выключенный по умолчанию «сетевое подключение», иначе две одновременно запущенные копии Windows сразу после запуска попробуют использовать один и тот же адрес (он статический, т.к. для VM мы не используем DHCP).
Для манипуляций с устройствами используется утилита devcon. Вот как это выглядит:
Добавляем этот скрипт в автозагрузку — например, так (требуется перезагрузка):
Таким образом, после выполнения этих скриптов виртуальная машина получит заданный ядром адрес, и будет готова к работе. Ядро узнает об этом по заработавшему пингу к этому адресу.
Возможно, эта схема добавит наглядности (по клику — полный размер в новом окне):
6. Замечания
Используемый нами способ — со скриптом mac2ip в автозагрузке — оказался довольно медленным в Win XP. Во всяком случае, текущая его реализация делает свою работу 10-15 секунд. При этом время, которое уходит от старта виртуальной машины до начала выполнения скрипта mac2ip, составляет 15-20 секунд.
Однако мы не спешим перейти на использование первого способа (DHCP с привязкой IP к MAC), потому что:
— во-первых, VM у нас завершаются не штатным для них способом (т.е. centos/windows не выполняют завершение работы), а выполнением virsh destroy для VM (всё равно, что питание выдернуть). Это позволяет экономить много времени, а целостность использованной VM нас всё равно не интересует — она будет немедленно удалена после использования. Так вот, арендованный VM адрес не будет в этом случае освобождён сразу, а будет освобождён по истечении default-lease-time DHCP. Это значит, что мы не сможем сразу же запустить VM с таким же MAC (и таким же IP). Вряд ли установка default-lease-time слишком маленьким (секунды) — хорошая идея. Более реальный вариант — изучение и использование OMAPI/omshell, и с их помощью удалять ненужные записи DHCP сразу после остановки VM.
— во-вторых, для Linux получение адреса от DHCP будет происходить медленнее, чем текущий вариант с назначением статического адреса.
— в третьих — конечно, обнаружатся и другие подводные камни.
Так что относительно медленная работа текущей версии скрипта в Windows — недостаточная причина для того, чтобы перейти на использовать варинанта с DHCP.
Идеальным решением было бы ускорение работы скрипта mac2ip для Windows. Буду рад советам — поскольку это мой первый опыт в управлении сетевым интерфейсом windows из скриптов, то, возможно, уже имеется велосипед.
Update: Во-первых, The_Kf открыл глаза на банальный способ получения MAC на выключенном интерфейсе с помощью ipconfig. Во-вторых, gribozavr провёл эксперимент, который показал, что заботиться о lease-time арендованного IP вообще не надо, потому что при привязке IP к MAC DHCP выдаст IP в любом случае машине с тем же MAC, даже ели аренда не истекла. Также он указал на stateless autoconfiguration из IPv6. В-третьих, при общении с akshakirov я внезапно понял, почему сразу более пристально не смотрели в сторону DHCP.
Update 2: в-четвёртых, amarao предложил использовать xenstore для передачи IP в VM. В гостевой Linux-машине для этого просто надо установить xenstore-utils, однако для винды, возможно, потребуется написать утилиту для чтения из xenstore.
Более 5480 заметок о виртуализации, виртуальных машинах VMware, Microsoft и Xen, а также Kubernetes
VM Guru / News / Как изменить IP-адрес VMware vCenter: переподключение хостов ESXi и перенастройка Update Manager + Auto Deploy.
Как изменить IP-адрес VMware vCenter: переподключение хостов ESXi и перенастройка Update Manager + Auto Deploy.
1. Поменяйте IP-адрес сервера vCenter и переприсоедините его к домену Active Directory.
2. После этого произойдут следующие вещи:
3. Для переприсоединения хоста ESXi к серверу vCenter вы можете удалить его из окружения vCenter и добавить повторно через vSphere Client, но этот способ приведет к потере данных о производительности хоста, что не очень хорошо. Поэтому нужно сделать так:
За более подробной информацией обращайтесь к KB 1001493.
где = новый IP vCenter Server, а = 80. Параметры и
— учетная запись администратора vCenter.
Если все прошло нормально, вывод будет выглядеть подобным образом:
Далее запускаем C:\Windows\ SysWOW64\obcad32.exe на сервере Update Manager. Там переходим на вкладку «System DSN» и нажимаем кнопку Configure. Идем до конца мастера по шагам и успешно проходим тест:
Пробуем запустить службу VMware vSphere Update Manager Service и получаем ошибку:
There was an error connecting to VMware vSphere Update Manager – [vc5:443]. Fault.HostNotReacable.summary
Поэтому переходим в папку C:\Program Files (x86)\VMware\Infrastructure Update Manager и открываем файл vci-integrity.xml, где в секции вводим новый IP-адрес vCenter.
Теперь перезапускаем VMware vSphere Update Manager Service и включаем VMware vSphere Update Manger Extension в vSphere Client. После этого все должно заработать.
Более подробная информация в KB 101322.
5. Переходим к vSphere Auto Deploy. Открываем файл:
c:\ProgramData\VMware\VMware vCenter Auto Deploy\vmconfig-autodeploy.xml
где меняем старый адрес vCenter на новый IP.
Из этой же папки, из командной строки выполняем команду:
параметры вбиваем те же, что и на шаге 4, за исключением последнего:
= c:\ProgramData\VMware\VMware vCenter Auto Deploy\vmconfig-autodeploy.xml
Включаем Auto Deploy Plug-in в vSphere Client. Более подробная информация в KB 2000988.
На этом все. Источник данной заметки.
Чтобы оставлять комментарии, вы должны быть зарегистрированы на сайте.
Оригинал: VirtualBox Networking Автор: Robin Catling Дата публикации: май 2012 г. Перевод: Семененко В. Дата перевода: 5 октября 2012 г.
Сетевые настройки VirtualBox
Для начала установите любую версию виртуальной машины VirtualBox, начиная с 3.0. И вы найдете в ней примерно одинаковые возможности по сравнению с теми, что описываются в данной статье.
В зависимости от потребностей, может понадобиться создание нескольких сетевых интерфейсов разных типов. Или же нескольких устройств одного типа, но с разными настройками. Это может потребоваться для использования на виртуальной машине как физических, так и виртуальных сетевых адаптеров. Все зависит от того, какие из них подключены.
Для моего web-сервера с запущенным на нем CMS WordPress дела обстоят несколько сложнее, поэтому идем дальше. Вкладка «Тип адаптера» отвечает за настройку виртуального аппаратного обеспечения. VirtualBox прекрасно справляется с ролью связующего звена между программной сетевой платой и тем физическим интерфейсом, который установлен на реальной машине (хосте). Откройте ссылку «Дополнительно» и вам будут доступны расширенные возможности сетевого адаптера. В этой статье я детально опишу все настройки в порядке их следования, начиная с установки типа адаптера.
Тип адаптера (Adapter Type)
Виртуальная машина VirtualBox имеет встроенную программную эмуляцию большинства наиболее распространенных типов сетевых карт, под которые созданы драйвера и протоколы. Карта PCnet-FAST III является выбором по умолчанию, однако в своей практике я часто выбираю Intel PRO/1000MT. Я поступаю так, если мне необходима наилучшая совместимость с «железом» от Intel, которое установлено на моем компьютере. Если у вас возникнут проблемы в настройке сетевого соединения, можно попробовать изменить тип адаптера, выбрав другой. Для наиболее древнего оборудования подойдет сетевая карта PCnet-FAST II.
Режим (Mode)
Довольно странно звучащий «Неразборчивый режим» (Promiscuous Mode) обычно применяется для работы VM в качестве виртуального маршрутизатора в локальных сетях; как сетевой мост или же хост. В этом режиме порт виртуальной машины способен принимать любые пакеты, отправляемые для других операционных систем; и даже для хоста. То есть, принимаются сетевые пакеты, предназначенные не только для этого адаптера, но и для других сетевых устройств. В 99% случаев обычным пользователям «Неразборчивый режим» не нужен. Он используется сетевыми администраторами для диагностики проблем, возникающих в сети.
MAC адрес (MAC Address)
Галочка напротив надписи «Кабель подключен» выполняет ту же роль, что и подключение или отключение физического кабеля в реальности. Эта настройка отвечает за подключение виртуального сетевого адаптера к сети. Не стоит путать ее с другой более важной настройкой «Включить сетевой адаптер», которая включает или выключает сам адаптер на виртуальной машине.
Кнопка «Проброс портов» открывает диалоговое окно, в котором производится настройка правил поведения трафика на конкретном адаптере; каким образом будет перемещаться трафик определенного типа между хостом и гостевой виртуальной машиной. Эти правила применяются к сетевым моделям, которые будут рассмотрены немного позже. Сами сетевые модели определяются на вкладке «Тип подключения». Эта настройка является наиболее сложным моментом в установке соединений в VirtualBox. Она доставила мне наибольшие проблемы в экспериментах.
«Подводные камни»
Типы подключения к сети
В VirtualBox имеются четыре готовые модели для подключения к сети:
Трансляция сетевых адресов (NAT)
Протокол NAT позволяет гостевой операционной системе выходить в Интернет, используя при этом частный IP, который не доступен со стороны внешней сети или же для всех машин локальной физической сети. Такая сетевая настройка позволяет посещать web-страницы, скачивать файлы, просматривать электронную почту. И все это, используя гостевую операционную систему. Однако извне невозможно напрямую соединиться с такой системой, если она использует NAT.
Принцип трансляции сетевых адресов заключается в следующем. Когда гостевая ОС отправляет пакеты на конкретный адрес удаленной машины в сети, сервис NAT, работающий под VirtualBox, перехватывает эти пакеты, извлекает из них сегменты, содержащие в себе адрес пункта отправки (IP-адрес гостевой операционной системы) и производит их замену на IP-адрес машины-хоста. Затем заново упаковывает их и отправляет по указанному адресу.
Например, в вашей домашней локальной сети хост и другие физические сетевые устройства имеют адреса в диапазоне, начинающемся с 192.168.х.х. В VirtualBox адаптеры, работающие по протоколу NAT, имеют IP-адреса в диапазоне, начинающемся с 10.0.2.1 и заканчивающемся 10.0.2.24. Такой диапазон называется под-сетью. Как правило, этот диапазон не используется для присвоения адресов устройствам в основной сети, поэтому такая система недоступна извне, со стороны хоста. Гостевая ОС может выполнять обновление программного обеспечения и web-серфинг, но остается невидимой для остальных «участников».
В руководстве VirtualBox этот момент описан более подробно:
«В режиме NAT гостевому сетевому интерфейсу присваивается по умолчанию IPv4 адрес из диапазона 10.0.х.0/24, где х обозначает конкретный адрес NAT-интерфейса, определяемый по формуле +2. Таким образом, х будет равен 2, если имеется только один активный NAT-интерфейс. В этом случае, гостевая операционная система получает IP-адрес 10.0.2.15, сетевому шлюзу назначается адрес 10.0.2.2, серверу имен (DNS) назначается адрес 10.0.2.3.» (Oracle Corporation, 2012, Глава 9).
Протокол NAT полезен в том случае, когда нет разницы в том, какие IP-адреса будут использовать гостевые ОС на виртуальной машине, поскольку все они будут уникальными. Однако, если потребуется настроить перенаправление сетевого трафика, или же расширить функциональность гостевой ОС, развернув на ней web-сервер (к примеру), то необходимы дополнительные настройки. В режиме NAT также недоступны такие возможности, как предоставление общего доступа к папкам и файлам.
Сетевой мост (Bridged)
В соединении типа «Сетевой мост» виртуальная машина работает также, как и все остальные компьютеры в сети. В этом случае адаптер выступает в роли моста между виртуальной и физической сетями. Со стороны внешней сети имеется возможность напрямую соединяться с гостевой операционной системой.
Адаптер в режиме «Сетевой мост» подключается, минуя хост, к устройству, которое распределяет IP-адреса внутри локальной сети для всех физических сетевых карт. VirtualBox соединяется с одной из установленных сетевых карт и передает пакеты через нее напрямую; получается работа моста, по которому передаются данные. Как правило, адаптер в модели «Сетевой мост» получает стандартный адрес из диапазона 192.168.х.х от роутера. Поэтому виртуальная машина в сети выглядит так, как будто это обычное физическое устройство, неотличимое от остальных.
На хосте могут быть активными одновременно несколько сетевых устройств; например, на моем ноутбуке имеется проводное подключение (называемое eth0 ) и беспроводное подключение (называемое wlan0 ). Поле «Имя» позволяет выбрать, какой из сетевых интерфейсов вы бы хотели использовать в качестве моста на VirtualBox.
Поэтому моему хосту назначен роутером IP-адрес 192.168.0.2. Виртуальной машине в режиме «Сетевой мост» присвоен адрес 192.168.2.6. При этом не имеет значения тот факт, что VirtualBox передает и получает трафик как бы «сквозь» хост, минуя его. В результате получается, что виртуальная машина становится просто еще одним компьютером в локальной сети. Если я пересчитаю свой компьютер и три виртуальные машины (VM), работающие в режиме «Сетевой мост», то у меня получиться четыре компьютера в физической локальной сети.
Протокол NAT полезен, потому что он защищает гостевые операционные системы со стороны Интернет. Но для того, чтобы получить доступ к ним извне (а на некоторых ОС у меня имеются установленные web-сервера), потребуется дополнительная настройка для перенаправления трафика. Тип подключения «Сетевой мост» позволяет получить доступ к ним, но системы в этом случае становятся незащищенными.
Если ваше сетевое устройство доступа (это может быть маршрутизатор, сетевой коммутатор или же настройки, предоставленные Интернет-провайдером) позволяет предоставлять только один IP-адрес для сетевого интерфейса, возможно, вам не удастся настроить «Сетевой мост».
Виртуальный адаптер хоста (Host-only)
Как правило, хост имеет свой собственный сетевой адрес, который используется для выхода в Интернет. Обычно это 192.168.0.101. В режиме «Виртуальный адаптер хоста» машина-хост также выступает в роли роутера VirtualBox и обладает IP-адресом по умолчанию 192.168.56.1. Создается внутренняя локальная сеть, обслуживающая все гостевые операционные системы, настроенные для режима «Виртуальный адаптер хоста» и видимые для остальной части физической сети. Адаптер vboxnet0 использует адреса из диапазона, начинающегося с 192.168.56.101. Но при желании можно изменить адрес по умолчанию.
Подобно адаптеру в режиме «Сетевой мост», в режиме «Виртуальный адаптер хоста» используются разные диапазоны адресов. Можно легко настроить гостевые системы для получения IP-адресов, используя для этого встроенный DHCP-сервер виртуальной машины VirtualBox.
В дополнение нужно сказать, что в режиме «Виртуальный адаптер хоста» созданная им сеть не имеет внешнего шлюза для выхода в Интернет, как для хоста, так и для гостевых операционных систем. Он работает только как обычный сетевой коммутатор, соединяя между собой хост и гостевые системы. Поэтому адаптер в режиме «Виртуальный адаптер хоста» не предоставляет гостевым машинам выход в Интернет; vboxnet0 по умолчанию не имеет шлюза. Дополнительные возможности для этого адаптера значительно упрощают настройку сети между хостом и гостевыми ОС, однако все же отсутствует внешний доступ или перенаправление портов. Поэтому может потребоваться второй адаптер в режиме «Виртуальный адаптер хоста» или «Сетевой мост», который подключается к гостевой операционной системе для получения полного доступа к ней.
Внутренняя сеть (Internal Network)
Если на практике вам потребуется настроить взаимосвязь между несколькими гостевыми операционными системами, работающими на одном хосте и могущими сообщаться только между собой, тогда можно воспользоваться режимом «Внутренняя сеть». Конечно, для этой цели можно использовать режим «Сетевой мост», но режим «Внутренняя сеть» обладает большей безопасностью. В режиме «Сетевой мост» все пакеты отправляются и получаются через адаптер физической сети, установленный на машине-хосте. В этом случае весь трафик может быть перехвачен (например, путем установки сниффера пакетов на машине-хосте).
Доступ к гостевой операционной системе
Во-первых, мне нужен доступ в Интернет из гостевой системы для установки обновлений, скачивания пакетов и других подобных задач. Мне также необходим доступ к Сети с машины-хоста. Но мне не нужно, чтобы сервер был доступен из внешней сети.
Оставляю выбранным по умолчанию сетевой адаптер в режиме NAT. Это позволит гостевым системам выходить в Интернет через настроенное соединение хоста, на котором установлены эти машины. Гостевые системы не видны извне в локальной сети; я также не имею доступа к любой из гостевых систем со стороны хоста; аналогично, гостевые системы не могут взаимодействовать между собой.
Настройка виртуального адаптера хоста
По умолчанию, адаптер vboxnet0 динамически получает IP адрес во время сессии подключения от DHCP-сервера. Для моего виртуального web-сервера WordPress необходимо, чтобы он имел статический IP-адрес. Поэтому на вкладке «DHCP сервер» я убрал галочку с надписи «Включить сервер». Таким образом, DHCP-сервер у меня отключен.
Добавление виртуального адаптера хоста
Я собираюсь добавить еще один сетевой адаптер (в режиме «Виртуальный адаптер хоста») к гостевой машине, что позволит создать самодостаточную частную виртуальную сеть. Эта сеть будет состоять только из хоста и любой гостевой операционной машины, настроенной в режиме «Виртуальный адаптер хоста».
Настройка гостевой системы
Мне необходимо, чтобы гостевой виртуальный сервер имел статический IP-адрес в сети, работающей в режиме «Виртуальный адаптер хоста». Иначе адрес сервера будет меняться от сессии до сессии, каждый раз при подключении. Я буду вынужден снова и снова решать задачу настройки, чтобы соединиться с хостом. Поэтому захожу в гостевую систему, открываю в ней терминал и ввожу в нем две следующие команды:
Однако, эти настройки являются временными. Если я произведу перезагрузку системы, все они бесследно пропадут. Для того, чтобы установить их постоянными, нужно добавить (используя учетную запись root) в файл /etc/network/interfaces следующие строки:
Присвоение имен
Так как я не слишком «дружу» с числами и IP-адресами, то для себя я всегда использую имена для гостевых систем вместо присвоения им IP-адресов. Для этого я редактирую файл /etc/hosts на машине-хосте и добавляю туда ссылки. Таким образом, я могу просматривать запущенные гостевые системы по их именам.
В файл /etc/hosts я добавляю строку:
Если я добавляю еще несколько гостевых систем с сеть, то мне достаточно отредактировать этот файл и дописать нужное количество строк. Благодаря такому приему я легко могу обратиться к любой из этих систем.
Альтернативный маршрут
Эксперты сетевых технологий могут заметить, что в моей конфигурации существует альтернативный маршрут для доступа к виртуальному серверу.
Используя адаптер по умолчанию, работающий по протоколу NAT, можно запустить дополнительную конфигурацию, которая позволит мне получить доступ к виртуальному серверу с хоста, не используя при этом сетевую настройку «Виртуальный адаптер хоста».
Используя панель настроек «Сетевой адаптер» в гостевой операционной системе, можно настроить проброс портов в виртуальной машине VirtualBox. Для этого переходим к настройкам адаптера NAT (кнопка внизу окна) для настройки перенаправления портов. При нажатии на нее откроется диалоговое окно, в котором настраиваются правила проброса для данного сетевого адаптера и гостевой системы.
Не мудрствуя лукаво, я назвал эти правила Apache и TCP, соответственно; оба используют TCP-протокол. Если говорить о привязке номеров портов, то порт 8888 на хосте перенаправляет трафик на гостевую систему для сервера Apache; порт 2222 на хосте перенаправляет трафик на порт 22, расположенный на гостевой операционной системе; такая настройка предоставляет мне доступ к гостевой системе для управления ее службами. Любой другой трафик будет отклонен виртуальной машиной, как не подпадающий под правила.
Это означает, что любые другие гостевые системы, которые я запущу на виртуальной машине, не смогут соединиться с виртуальным сервером, так как просто не существует сетевого маршрута под NAT.
