EVE-NG

При тес­тирова­нии средств безопас­ности, а так­же при обу­чении пер­сонала сце­нари­ям атак и защиты сетевой инфраструк­туры не обой­тись без средств вир­туали­зации. Час­то для это­го изоб­рета­ют велоси­пед, соору­жая жут­кое наг­ромож­дение из вир­туаль­ных машин и все­воз­можно­го соф­та. Мы же пой­дем иным путем: нас­тро­им плат­форму эму­ляции на базе EVE-NG и соз­дадим на ее осно­ве уни­вер­саль­ный мас­шта­биру­емый кибер­полигон, поз­воля­ющий отта­чивать свои навыки сетеви­кам и безопас­никам.

Идея поп­робовать сов­ремен­ную плат­форму эму­ляции воз­никла, ког­да я наб­людал за работой коман­ды инже­неров кибер­безопас­ности. Они час­то занима­ются изу­чени­ем, раз­верты­вани­ем, интегра­цией и тес­тирова­нием раз­ных про­дук­тов. Вен­доров и решений — огромное количес­тво, но зна­читель­ная их часть вра­щает­ся вок­руг защиты одних и тех же клю­чевых сис­тем, некой стан­дар­тной кор­поратив­ной инфраструк­туры: рабочих стан­ций, сер­веров AD, фай­ловых шар, поч­товых сер­веров, веб‑сер­веров, сер­веров баз дан­ных. Так­же в любой инфраструк­туре при­сутс­тву­ет некая стан­дар­тная иерар­хия групп поль­зовате­лей, сетевая сег­мента­ция, набор ПО и сетевое обо­рудо­вание в виде ком­мутато­ров, мар­шру­тиза­торов, фай­рво­лов.

За­дачи по интегра­ции, как пра­вило, тоже типич­ные: нас­тро­ить авто­риза­цию через AD/Radius, под­ружить с поч­той, рас­катать аген­тов, соб­рать клас­тер, подать зер­калиро­ван­ный тра­фик, отправ­лять ана­лити­кам логи или флоу. Прак­тика показы­вает, что без стан­дарти­зиро­ван­ного под­хода каж­дый инже­нер со вре­менем нагоро­дит себе подоб­ную инфраструк­туру, и каж­дый — со сво­им блек‑дже­ком. В резуль­тате получа­ется целый зоопарк по‑раз­ному скон­фигури­рован­ных вир­туалок, на которых кру­тит­ся непонят­но что. Прос­то взять и быс­тро заюзать такие ВМ дру­гой член коман­ды, ско­рее все­го, не смо­жет.

По­мимо раз­бро­сан­ных на раз­ных ESXi-хос­тах «лич­ных» ВМ, для тес­тирова­ния фай­рво­лов, запус­ка мал­вари и про­чих задач тре­буют­ся сег­менти­рован­ные сети, поэто­му в такой инфраструк­туре порой встре­чают­ся еще и порт‑груп­пы. Они необ­ходимы толь­ко для лабора­тории, но по фак­ту ходят в интернет через про­дак­шен‑инфраструк­туру. Пос­ле уволь­нения инже­нера подоб­ные вир­туал­ки прос­то уби­вают­ся вмес­те со всем «накоп­ленным опы­том». Короче говоря, такой под­ход казал­ся мне сов­сем не эффектив­ным, тем более в нем не исполь­зуют­ся некото­рые фичи и гиб­кость VMware. Я решил стан­дарти­зиро­вать про­цесс, а заод­но про­тес­тировать плат­форму эму­ляции.

ВЫБОР ПЛАТФОРМЫ

Под наши нуж­ды была выб­рана плат­форма EVE-NG Community Edition — это форк извес­тно­го UNetLab, который боль­ше не под­держи­вает­ся. Дан­ное решение очень любят сетеви­ки, и дей­стви­тель­но есть за что. Ты толь­ко пос­мотри на при­меры сетевых тополо­гий с клас­терами и BGP!

Од­нако она соз­дана не толь­ко для сетеви­ков: воз­можнос­ти ее исполь­зования прак­тичес­ки без­гра­нич­ны, они зависят исклю­читель­но от фан­тазии и име­ющих­ся зна­ний. Для работы нам тре­бовал­ся веб‑интерфейс, а у кон­курен­тов он при­сутс­тво­вал на момент выбора толь­ко в GNS3, да и то в бете. Обо всех фичах EVE-NG, вклю­чая вер­сию Professional и Learning Center, в которых есть Docker и под­дер­жка клас­териза­ции, ты можешь про­читать на офи­циаль­ном сай­те, я же рас­ска­жу о клю­чевых воз­можнос­тях.

• QEMU/KVM. В дан­ной связ­ке QEMU выс­тупа­ет в роли эму­лято­ра железа, он дос­таточ­но гибок и может запус­кать код, написан­ный для одной архи­тек­туры про­цес­сора, на дру­гой (ARM на x86 или PPC на ARM). KVM же, в свою оче­редь, поз­воля­ет дос­тигать высокой про­изво­дитель­нос­ти бла­года­ря вир­туали­зации с аппа­рат­ной под­дер­жкой, такой как Intel VT-x и AMD-V.
• IOU/IOL и Dynamips. Под­дер­жка ста­рень­ких, но впол­не рабочих ком­мутато­ров и мар­шру­тиза­торов Cisco.
• Оп­тимиза­ция памяти UKSM в ядре. При одновре­мен­ном исполь­зовании одно­образных ВМ поз­воля­ет дедуп­лициро­вать память и тем самым сущес­твен­но сни­зить рас­ход RAM.
• Пол­ноцен­ный веб‑интерфейс на HTML5.
• Мно­гополь­зователь­ский режим для одновре­мен­ной работы раз­личных вир­туаль­ных лабора­торий.
• Вза­имо­дей­ствие с «нас­тоящей» сетью.

УСТАНОВКА

Мы раз­верну­ли «Еву» на железе (bare metal). Для такого типа уста­нов­ки предъ­явля­ются сле­дующие сис­темные тре­бова­ния: ЦПУ — Intel Xeon CPU supporting Intel® VT-x with Extended Page Tables (EPT), ОС — Ubuntu Server 16.04.4 LTS x64.

Все осталь­ное зависит от пред­полага­емой наг­рузки: тут чем боль­ше, тем луч­ше, осо­бен­но это каса­ется ОЗУ. Если тебя сму­тила ста­рая вер­сия ОС, то не пережи­вай, она будет под­держи­вать­ся до 2024 года. Замечу, что Community-вер­сия обновля­ется не так час­то, как Professional, в которой для уста­нов­ки на железо тре­бует­ся уже 18.04 LTS. Если же ты весь такой в обла­ках, то имей в виду, что EVE-NG офи­циаль­но под­держи­вает GCP.

INFO

Зна­ешь ли ты, что в GCP (Azure, Яндексе) новый поль­зователь может по­лучить 300 дол­ларов в виде бес­плат­ных кре­дитов для тес­тирова­ния сер­висов, нап­ример для запус­ка ВМ? И что, помимо это­го, в GCP есть «вытес­няемые ВМ»? Это такие вир­туал­ки, которые сто­ят в 3–4 раза дешев­ле обыч­ных, но живут мак­симум 24 часа или мень­ше: если обла­ку пот­ребу­ются ресур­сы, которые занима­ет эта ВМ, оно ее грох­нет.

К сожале­нию, полити­ка Google изме­нилась, и бес­плат­ные кре­диты нель­зя тра­тить на вытес­няемые ВМ, но, если вдруг ког­да‑нибудь тебе пот­ребу­ется 128 RAM в обла­ке и задеше­во, ты зна­ешь, что делать! 😉

Мы же сей­час с тобой рас­смот­рим вари­ант быс­тро­го зна­комс­тва с плат­формой, раз­вернув ее на ноут­буке с VMware Workstation. Под­держи­вает­ся толь­ко VMware, вклю­чая Player и ESXi. Но в любом слу­чае сле­дует понимать, что вло­жен­ная (nested) вир­туали­зация (это ког­да вир­туал­ка работа­ет внут­ри дру­гой вир­туал­ки) может пло­хо вли­ять на про­изво­дитель­ность. Так­же твой ЦПУ дол­жен под­держи­вать тех­нологии аппа­рат­ной вир­туали­зации, такие как Intel VT-x и AMD-V. Не забудь про­верить, вклю­чены ли они в BIOS.

Ин­терес­но, что про под­дер­жку AMD в Community-вер­сии офи­циаль­но не сооб­щает­ся, а вот в докумен­тации к Professional про­изво­дите­ли уже написа­ли, что под­держи­вают пос­ледние вер­сии про­цес­соров. Как бы то ни было, я раз­вернул Community-вер­сию на про­цес­соре AMD Ryzen 5 4600H без каких‑либо проб­лем.

Ес­ли ты исполь­зуешь в качес­тве хос­товой ОС Windows, тебе сле­дует пом­нить кое‑что о роли Hyper-V, в час­тнос­ти в Windows 10. Вот что об этом написа­но на сай­те Microsoft:

We introduced a number of features that utilize the Windows Hypervisior. These include security enhancements like Windows Defender Credential Guard, Windows Defender Application Guard, and Virtualization Based Security as well as developer features like Windows Containers and WSL 2.

По­мимо самой ОС и ее фич, эту служ­бу может исполь­зовать еще и Docker Desktop. Из‑за это­го до вер­сии 15.5 вклю­читель­но VMware Workstation (как и VirtualBox) вооб­ще не работа­ла на хос­те с вклю­чен­ной ролью Hyper-V. Кол­лабора­ция Microsoft и VMware поз­волила все же сде­лать интегра­цию Workstation с WHP через API, бла­года­ря чему появи­лось ра­бочее решение. Но, к сожале­нию, помимо того, что такая связ­ка ста­ла мед­ленней работать, име­ется глав­ное огра­ниче­ние, а имен­но — фун­кции Intel VT-x / AMD-V недос­тупны для гос­тевых ВМ. Служ­ба Hyper-V экс­клю­зив­но исполь­зует VT-x, огра­ничи­вая к нему дос­туп дру­гим гипер­визорам.

По­это­му, если на тво­ем хос­те вклю­чена роль Hyper-V, про­ана­лизи­руй, для чего она исполь­зует­ся, и при воз­можнос­ти отклю­чи ее. Если это невоз­можно, исполь­зуй дру­гой ПК, сер­вер или обла­ко.

Я рекомен­дую кач­нуть сра­зу кни­гу рецеп­тов EVE-NG в фор­мате PDF. В ней содер­жится исчерпы­вающее руководс­тво по все­му про­екту, от А до Я.

Итак, для быс­тро­го раз­верты­вания мы ска­чаем ZIP-архив с OVF-обра­зом, рас­паку­ем архив и двой­ным щел­чком мыши по EVE-COMM-VM.ovf импорти­руем его в Workstation.

От­кро­ем свой­ства, добавим при необ­ходимос­ти памяти и про­цес­соров. Убе­дись, что у тебя сто­ит галоч­ка Virtualize Intel VT-x/EPT or AMD-V/RVI в груп­пе нас­тро­ек Virtualization engine. Без нее EVE-NG будет заг­ружать­ся сама, мож­но откры­вать и соз­давать лабора­тории, но ВМ внут­ри лабора­тории запус­кать­ся не будут.

Для наг­ляднос­ти мы выберем режим Bridgedу сетево­го адап­тера, тем самым наши ВМ внут­ри лабора­тории ста­нут дос­тупны нап­рямую в локаль­ной сети.

РАБОТА С ПЛАТФОРМОЙ

За­пус­каем EVE-VM в Workstation. Пос­ле успешной заг­рузки ты получишь приг­лашение на ввод пароля.

Ло­гиним­ся, исполь­зуя стан­дар­тную учет­ку root/eve для кон­соли.

Да­лее отве­чаем на стан­дар­тные воп­росы по нас­трой­ке ОС, такие как:

• New root password;
• Hostname;
• DNS domain name;
• DHCP/Static IP address;
• NTP Server;
• Proxy Server configuration.

Пос­ле отве­та на пос­ледний воп­рос сис­тема авто­мати­чес­ки перезаг­рузит­ся. По завер­шении перезаг­рузки откры­ваем веб‑интерфейс по IP-адре­су, ука­зан­ному в кон­соли ВМ, и логиним­ся, исполь­зуя учет­ку admin/eve.

По боль­шей час­ти вся работа с плат­формой выпол­няет­ся через веб‑интерфейс. По SSH под­клю­чать­ся к «Еве» при­ходит­ся лишь изредка, нап­ример для под­готов­ки обра­зов. Сущес­тву­ет два вари­анта под­клю­чения к монито­ру ВМ: через натив­ные при­ложе­ния или кон­соль HTML5. При выборе натив­ной кон­соли на ПК, с которо­го открыт веб‑интерфейс, дол­жны быть уста­нов­лены при­ложе­ния для уда­лен­ного дос­тупа и Wireshark. Набор соф­та раз­нится в зависи­мос­ти от ОС, а так­же тре­бует­ся некото­рый тюнинг реес­тра, поэто­му рекомен­дует­ся исполь­зовать Windows/Linux/Apple Client Side Integration Pack, содер­жащий все необ­ходимое, вклю­чая скрип­ты для кон­фигура­ции.

При исполь­зовании же кон­соли HTML5 все управле­ние ведет­ся пол­ностью через бра­узер. Кон­соль работа­ет на Apache Guacamole, как во мно­гих сов­ремен­ных вен­дорных лабора­тори­ях.

Пос­ле логина мы попада­ем в некий фай­ловый менед­жер, где у нас хра­нят­ся фай­лы лабора­торий. Сна­чала я покажу тебе готовую кор­поратив­ную лабора­торию, а потом мы соз­дадим для при­мера свою. Отме­чу лишь, что для луч­шего визу­аль­ного отоб­ражения мно­гие соеди­нения на этой схе­ме были изме­нены или вов­се уда­лены.

По сво­ей сути файл лабора­тории — это кон­фиг в фор­мате XML, опи­сыва­ющий кон­фигура­цию нод, их рас­положе­ние на поле, соеди­нения и про­чее. Ноды — это объ­екты ВМ, которые могут быть обра­зами IOL/Dynamips/QEMU. Лабы мож­но кло­ниро­вать, экспор­тировать и импорти­ровать пря­мо через веб‑интерфейс.

При откры­тии лабора­тории демонс­три­рует­ся вид тополо­гии, чем‑то похожий на Visio. На этой тополо­гии добав­ляют­ся и соеди­няют­ся меж­ду собой ноды. Сле­ва в меню находит­ся все, что необ­ходимо для работы, ноды мож­но запус­кать сра­зу все, а мож­но выбороч­но.

В отли­чие от Visio, при щел­чке по знач­ку откры­вает­ся уда­лен­ное под­клю­чение к ноде.

Каж­дая нода име­ет свои стан­дар­тные нас­трой­ки ВМ, такие как образ, с которо­го выпол­няет­ся заг­рузка, количес­тво CPU, RAM, Ethernet-пор­тов, аргу­мен­ты для гипер­визора и дру­гое.

СЕТИ

В «Еве» два глав­ных вида сетей: мост и интерфейс управле­ния. В основном тебе при­дет­ся щел­кать мышью на нодах и выбирать пор­ты источни­ка и наз­начения. Это как раз одна из при­чин, по которым сетеви­кам так нра­вит­ся «Ева»: в ESXi, нап­ример, для «чис­тых» соеди­нений point-to-point тре­бует­ся соз­давать отдель­ный vSwitch и порт‑груп­пу, что отни­мает кучу вре­мени и сил.

Сеть в режиме мос­та дей­ству­ет как неуп­равля­емый ком­мутатор. Она под­держи­вает переда­чу помечен­ных пакетов dot1q. Это может быть необ­ходимо, ког­да нам нуж­но соеди­нить мно­жес­тво узлов в плос­кую (dot1q) сеть без исполь­зования обра­за сетево­го устрой­ства. Получит­ся пол­ностью изо­лиро­ван­ная вир­туаль­ная сеть.

Вто­рой вари­ант сети называ­ется «сеть управле­ния» с име­нами Cloud0/Pnet0. Этот интерфейс нас­тро­ен в режиме мос­та с пер­вым сетевым адап­тером сер­вера. Бла­года­ря это­му ты можешь сде­лать ноды дос­тупны­ми нап­рямую по сети, они будут находить­ся в том же сетевом сег­менте, что и интерфейс управле­ния, и могут вза­имо­дей­ство­вать с дру­гими внеш­ними сетями.

Ос­таль­ные интерфей­сы Cloud* мож­но свя­зать со вто­рым и выше пор­том Ethernet для под­клю­чения к дру­гой сети или к устрой­ству. Нас­тра­ивать на них IP-адрес не тре­бует­ся. Они будут дей­ство­вать как чис­тый мост меж­ду тво­им внеш­ним соеди­нени­ем и лабора­тор­ной нодой.

ОБРАЗЫ

«Ева» пос­тавля­ется без обра­зов, на бор­ту име­ется толь­ко Virtual PC с базовой сетевой фун­кци­ональ­ностью.

Спи­сок под­держи­ваемых обра­зов на сай­те не всег­да акту­аль­ный, об этом нап­рямую говорит­ся в докумен­тации. Из‑за лицен­зион­ных огра­ниче­ний авто­ры про­екта не могут вык­ладывать у себя на сай­те пря­мые ссыл­ки на обра­зы, но на прак­тике любой образ мож­но най­ти на тор­рентах. А если ты работа­ешь в интегра­торе, так это вооб­ще не проб­лема.

Образы Dynamips/IOL

С обра­зами сетевых устрой­ств Dynamips/IOL поч­ти ничего делать не нуж­но, кро­ме вы­ясне­ния зна­чения IDLE PC и соз­дания фай­ла лицен­зии. К сожале­нию, не все фун­кции этих сетевых устрой­ств под­держи­вают­ся. Их кон­фиги хра­нят­ся в отдель­ном мес­те, в меню startup-configs и в NVRAM, а не в самом фай­ле обра­за. NVRAM исполь­зует­ся как пос­тоян­ное хра­нили­ще с воз­можностью записи для началь­ной кон­фигура­ции. В про­цес­се заг­рузки нода всег­да будет про­верять NVRAM на наличие сох­ранен­ной кон­фигура­ции.

Про­цесс заг­рузки таких обра­зов изоб­ражен на сле­дующей схе­ме и в целом понятен без допол­нитель­ных пояс­нений.

Образы QEMU/KVM

Все осталь­ные сис­темы будут работать в виде QEMU-обра­зов. Осо­бен­ность работы этих обра­зов в «Еве» зак­люча­ется в том, что сна­чала соз­дает­ся некий базовый образ, а при запус­ке и работе ВМ все изме­нения пишут­ся в отдель­ный файл. Это мож­но рас­ценивать как сво­его рода снап­шоты, при­вязан­ные к отдель­ным поль­зовате­лям.

Та­кой механизм очень удо­бен при груп­повом обу­чении, ког­да нес­коль­ко инже­неров дела­ют парал­лель­но одну лабора­тор­ную работу: изме­нение нас­тро­ек в обра­зе у одно­го поль­зовате­ля никак не вли­яет на осталь­ных. Если образ стал нерабо­тос­пособ­ным вследс­твие неп­равиль­ных нас­тро­ек и на поиск проб­лемы нет вре­мени, мож­но нажать кноп­ку Wipe (Wipe all nodes), и образ в лабора­тории у кон­крет­ного поль­зовате­ля вер­нется к сос­тоянию базово­го.

По­мимо про­чего, такая схе­ма так­же реша­ет проб­лему лицен­зирова­ния — нуж­на толь­ко одна лицен­зия. Парамет­ры, к которым при­вязы­вают­ся лицен­зии, не меня­ются, как это про­исхо­дит, нап­ример, при кло­ниро­вании в ESXi.

Круп­ные вен­доры обыч­но пре­дос­тавля­ют нес­коль­ко вари­антов обра­зов сво­их ВМ: VMware, KVM, Hyper-V. Но если готово­го обра­за нет, его мож­но соз­дать или скон­верти­ровать из име­юще­гося.

Конвертация образа

Для кон­верта­ции обра­за необ­ходимо исполь­зовать кон­соль­ную ути­литу qemu-img, уже уста­нов­ленную в «Еве». Толь­ко имей в виду, что qemu-img и /opt/qemu/bin/qemu-img — раз­ных вер­сий, поэто­му исполь­зуй пол­ный путь, как ука­зано в докумен­тации.

Нап­ример, эта коман­да кон­верти­рует образ VMware в образ QEMU:

$ /opt/qemu/bin/qemu-img convert -f vmdk -O qcow2 image.vmdk image.qcow2

Ос­таль­ные фор­маты и аргу­мен­ты для кон­верта­ции смот­ри в таб­лице:

QCOW2 (KVM, Xen)

qcow2

QED (KVM)

qed

raw

raw

VDI (VirtualBox)

vdi

VHD (Hyper-V)

vpc

VMDK (VMware)

vmdk

Создание своего образа

При соз­дании сво­его обра­за сле­дует руководс­тво­вать­ся пра­вила­ми име­нова­ния папок и обра­зов дис­ка, так как сис­тема к ним чувс­тви­тель­на.

Кор­невая дирек­тория для обра­зов — /opt/unetlab/addons/qemu/. В качес­тве при­мера рас­смот­рим соз­дание сво­его обра­за на базе дис­три­бути­ва Kali Linux. Для это­го ска­чаем уста­новоч­ный образ kali-linux-2021.2-installer-netinst-amd64.iso.

1. Соз­дай дирек­торию на сер­вере «Евы»:
2. $ mkdir /opt/unetlab/addons/qemu/linux-kali/
3. Пе­рене­си уста­новоч­ный образ kali-linux-2021.2-installer-netinst-amd64.iso на сер­вер «Евы» в пап­ку /opt/unetlab/addons/qemu/linux-kali/.
4. Пе­реиме­нуй уста­новоч­ный образ в cdrom.iso:
5. $ mv kali-linux-2021.2-installer-netinst-amd64.iso cdrom.iso
6. На­ходясь в той же пап­ке, соз­дай новый файл дис­ка HDD. В при­мере ука­зан раз­мер 30 Гбайт — ты можешь задать любой:
7. $ /opt/qemu/bin/qemu-img create -f qcow2 virtioa.qcow2 30G
8. Соз­дай или открой лабора­торию через веб‑интерфейс, добавь новую ноду, под­клю­чив ее к сети, если необ­ходимо наличие интерне­та для уста­нов­ки.
9. За­пус­ти ноду, открой ее и про­дол­жай про­цесс уста­нов­ки как обыч­но.
10. Пос­ле завер­шения уста­нов­ки перезаг­рузись и вык­лючи ноду изнутри стан­дар­тны­ми средс­тва­ми ОС, пос­ле чего уда­ли файл cdrom.iso.

Ес­ли ты пос­мотришь на раз­мер фай­ла /opt/unetlab/addons/qemu/linux-kali/virtioa.qcow2, то уви­дишь, что он не изме­нил­ся и остался пус­тым.

Это про­изош­ло потому, что все изме­нения в про­цес­се работы ноды записы­вают­ся в отдель­ный файл по пути /opt/unetlab/tmp/PodID/UUID/NodeID. Если ты сде­лал изме­нения внут­ри ноды, уста­новил софт или залил фай­лы и хочешь эти изме­нения внес­ти в базовый образ, то сде­лать это мож­но спо­собом, опи­сан­ным ниже.

Внесение изменений в базовый образ

1. Вык­лючи ноду изнутри стан­дар­тны­ми средс­тва­ми ОС, в веб‑интерфей­се «Евы» щел­кни пра­вой кноп­кой мыши на ноде. В круг­лых скоб­ках ты уви­дишь чис­ло. Это Node ID, запиши его — в нашем при­мере это 2.

1. Сле­ва в меню открой пункт Lab Detailsи запиши ID, в этом при­мере — 6393e2df-501f-405c-b602-2e9a080f72f1.

1. Зак­рой лабу и перей­ди в Management/User Management. Най­ди сво­его поль­зовате­ля и запиши его зна­чение POD. У адми­на это зна­чение по умол­чанию 0.
2. Пе­рей­ди по пути /opt/unetlab/tmp/PodID/UUID/NodeID, под­ста­вив свои зна­чения:
3. $ cd /opt/unetlab/tmp/0/6393e2df-501f-405c-b602-2e9a080f72f1/2/
4. Как видишь, файл дис­ка с изме­нени­ями в этой пап­ке занима­ет 3,1 Гбайт.

1. Вы­пол­ни коман­ду, ука­зав имя фай­ла дис­ка:
2. $ /opt/qemu/bin/qemu-img commit virtioa.qcow2

Ес­ли все прош­ло успешно, ты получишь сооб­щение Image comitted. Про­верив фай­лы, ты смо­жешь убе­дить­ся, что изме­нения из вре­мен­ной пап­ки пере­еха­ли в базовый образ.

Те­перь при вклю­чении ноды linux-kali любым из поль­зовате­лей будет заг­ружать­ся файл базово­го обра­за дис­ка. Это была инс­трук­ция из офи­циаль­ной докумен­тации, но на прак­тике ее исполь­зование вызыва­ло проб­лемы, которые я опи­шу далее.

Порт открыт, и име­ется под­робная информа­ция о хос­те. Про­верять сетевую связ­ность с VPC2 и VPC3 мы не ста­нем, они нам нуж­ны лишь для мас­совки, что­бы показать, как мож­но добить­ся пос­тро­ения сети L2 (в которой боль­ше двух узлов), исполь­зуя объ­ект network и эму­ляцию сетево­го обо­рудо­вания.