Azure File Sync – panaceum na Ransomware

Ataki ransomware są coraz częstsze i warto pomyśleć o jakiejś formie kolejnego miejsca na backupy, które będzie naszym zabezpieczeniem na wypadek ataku tego typu. Azure File Sync wraz z obsługą snapshotów może nam ten problem rozwiązać. Szczególnie że od strony użytkownika/administratora jest to bardzo przyjemne rozwiązanie.

Azure File Sync – czym jest

Azure File Sync najprościej mówiąc jest to OneDrive do zastosowań profesjonalnych. Dowolny zasób serwerowy lub klastrowy synchronizujemy z zasobem chmurowym (Storage account w Azure), a dokładniej to mała usługa windowsowa pilnuje żeby wszystko było synchronizowane.

To gdzie są moje dane?

Mamy dwie opcje. Albo wszystkie dane są lokalnie i dodatkowo w Azure, albo ustawiamy że lokalnie trzymamy tylko najświeższe pliki, a te mniej używane leżą tylko w Azure i są dociągane gdy ktoś się do nich odwoła (dokładnie tak samo jak robi to OneDrive).

Przypadki użycia

1. Mam mały zasób na backupy, a backupów coraz więcej

Niech pierwszy rzuci kamieniem ten, któremu nigdy nie skończyło się miejsce 😉

Kupujemy dyski, szacujemy na parę lat do przodu ile tych backupów będzie na naszym klastrze na backupy, po czym rzeczywistość tworzy swoją własną matematykę i nic się nie zgadza. No ale kto powiedział że wszystkie backupy muszą być lokalnie? Jak będzie awaria to potrzebujemy tylko aktualnych, a nie tych z zeszłego miesiąca. A jak potrzebujemy z zeszłego miesiąca, to tylko jakiś mały wycinek a nie wszystkie, więc możemy poczekać żeby się dociągnęły z chmury.

Cloud Tiering

Cloud Tiering example

W swoich środowiskach ustawiłem na początek żeby lokalnie były trzymane tylko pliki z ostatnich 14 dni. Starsze kopie leżą tylko w chmurze. Dzięki temu zależnie jak długo trzymamy w różnych środowiskach kopie, odzyskujemy od kilku do kilkudziesięciu procent przestrzeni.

Na zasobie widzimy oczywiście wszystkie, tylko analogicznie jak w przypadku OneDrive, pliki które są tylko w chmurze lokalnie mają tylko metadate, a zawartość dociągnie się w przypadku dostępu do takiego pliku. Na przykład możemy spokojnie uruchomić odtwarzanie backupy bazy danych (który jest już tylko w chmurze), będzie on tylko trochę wolniejszy bo plik będzie strumieniowany przez internet.

2. Ransomware – chronić się kto może

W obecnych czasach ataki typu ransomware są największą zmorą wszystkich. Widziałem już takie środowiska gdzie wszystko zostało zaszyfrowane, łącznie z tym że zatrzymany został klaster MSSQL i zaszyfrowane wszystkie jego pliki.

Jedną z dróg minimalizacji zagrożenia jest minimalizowanie uprawnień osób które zajmują się takim środowiskiem, ale i tak nie zastąpi to dobrego backupy. Najlepiej takiego który w razie ataku nie zostanie zaszyfrowany, albo mamy kopię backupu, albo jeszcze kopię kopii backupu.

Azure File Sahre Snapshots

Świetnym rozwiązaniem wydaje się Azure File Sync. Wszystkie pliki automatycznie synchronizowane są z chmurą, a po stronie Azure dodatkowo konfigurujemy (np. codzienne) snapshoty. One są za darmo w przypadku backupów, bo tylko modyfikacje plików by nas kosztowały. W przypadku gdy ktoś nam zaszyfruje backupy, to poleci to synchronizacją do Azure, ale po stronie Azure mamy snapshoty które pozwalają nam dostać się do wersji plików przed szyfrowaniem.

Dostęp do zasobów po awarii

To jest prawdziwa wisienka na torcie. Nawet jak stracimy całe DC, całą firmę, wybuchnie pół planety (ale nie te pół z rejonem Azure gdzie trzymamy pliki), to zasób File Share który utworzyliśmy na naszym Storage Account, podpinamy jedną komendą jako zamapowany dysk gdziekolwiek. Tak, gdziekolwiek gdzie mamy dostęp do internetu, możemy nawet na własnym laptopie, jeżeli jest wystarczająco duży i ciężki.

Map Azure File Share as disk

W praktyce plan po takim najgorszym kataklizmie to postawienie najszybszych maszynek w Azure, w tym samym regionie gdzie nasze kopie, a następnie ich szybkie odtwarzanie w lokalnej Azurowej sieci.

Koszty

Same składowanie plików w Azure za darmo nie jest, musimy założyć Storage Account, utworzyć File Share, zdecydować na jakim poziomie HA i szybkości będziemy bazować.

Microsoft dodatkowo nie ułatwia szacowania, licząc użycie na podstawie swoich własnych metryk, których nie jesteśmy w stanie zmierzyć we własnym środowisku. Jedyna opcja to skonfigurowanie środowiska Proof of Concept i rozpoczęcia synchronizacji z mniejszym wolumenem danych. W ten sposób możemy poznać mniej więcej jakie to będą koszty.

Problemy

Nie ma róży bez kolców. Jeżeli w ogóle rozważamy taki mechanizm zabezpieczenia, to pewnie dlatego że mamy środowisko onprem, tzn. wszystkie serwery leżą w jakiejś kolokacji, albo u kogoś pod biurkiem?

1. Łącze internetowe, punkty wymiany ruchu, trasy

Potrzebujemy łącza, szybkiego, stabilnego, działającego. Nawet nie tylko łącza, potrzebujemy krótkiej trasy do regionu Azure który wybierzemy. Ale i to nie daje nam gwarancji, bo po drodze są operatorzy węzłów wymiany ruchu, a oni nie lubią jak im ktoś nagle zapycha sieć. Przekonałem się o tym boleśnie przy pierwszym lockdownie, gdy nagle okazało się, że za węzłem we Frankfurcie, w drodze do jednego z regionów Azure, ktoś mnie zaczął blokować do 200 Mbps. Równiutko 200 Mbps, jak od linijki. Przy produkcyjnym ruchu było to trochę mało. Ale na trasy BGP wpływu nie mamy.

Zasada pierwsza, wybieramy region który jest najbliżej. Aktualnie to region Azure we Frankfurcie, ale i tu coś lub ktoś potrafi nas przyblokować, aktualnie do 400-600 Mbps, mimo bezpośredniego wpięcia obu serwerowni (źródłowej i docelowej) bezpośrednio we Frankfurcie.

Jest na to obejście, możemy wykupić sobie Express Route i spiąć się bezpośrednio z Azure, powinno być szybciej. Nie testowałem, na razie przyjmuję te limity które spotkałem i zobaczymy co przyniesie przyszłość.

2. Ilość danych, szybkość dysków

Backupy robimy zwykle na dyski które szybko zapisują sekwencyjnie. No ale niektóre pliki są małe, więc podpadają bardziej pod kategorię dużej ilości operacji z małymi plikami. O ile zapis na klaster backupowy zwykle poleci przez jakiś cache SSD, więc będzie szybko, to synchronizacja może już z niego nie skorzystać.

No i się na tym przejechałem gdy okazało się, że odczytanie wszystkich plików przez komponent odpowiedzialny za synchronizację jest wolniejsze niż szybkość wpadania nowych plików…

Niecałe 40 mln plików backupów, 20 TB. Z tego 30 procent wymieniało się w ciągu tygodnia na świeże pliki, a Azure twierdził że potrzebuje na wstępną synchronizację 2 miesięcy.

Azure File sync initial upload

Tyle że ja po 3 tygodniach nie miałem już tych plików z którymi zaczynałem… Rozwiązania? Wymieniamy dyski w macierzy na szybsze, albo musimy zrezygnować z części plików, albo podzielić zasób na kilka klastrów plikowych i osobno je synchronizować.

Podsumowanie

Jak widać każda technologia, obojętnie jak kolorowa zaprezentowana przez marketing, ma swoje kruczki i widzę tajemną do zdobycia. Ale nie można się zrażać, ze wszystkich dostępnych chmurowych zasobów na backup backupów, to jest najlepsze rozwiązanie. Nie ma innego, które w razie awarii będzie tak łatwe do podpięcia i użycia.

Markdown i Obsidian – dokumentowanie na miarę 21 wieku

Markdown to sposób zapisu/formatowania plików tekstowych, które przez swoją charakterystykę generują dokumenty nadające się do publikacji. Nie jest potrzebny żaden edytor tekstu typu Word. Do tej pory najczęściej spotykałem takie pliki na GitHubie, nie mając świadomości czym są pod spodem (bo wyglądają jak normalny, sformatowany tekst).

Markdown i Obsidian

Obsidian, to tzw. pandemiczny edytor (napisany w czasach pierwszych lockdownów). Nie ma nawet jeszcze stabilnej wersji 1.0, a już coraz częściej się o nim słyszy i moje pierwsze próby wykorzystania wygenerowały dużo wow.

Poza tym że Obsidian pozwala pisać tekst, co możemy robić nawet w zwykłym notatniku, to pozwala od razy na podgląd plików, tagowanie, linkowanie notatek (bo to notatki piszemy i łączymy w całość linkami).

Pisząc jeden dokument, tak naprawdę piszemy wiele notatek i na jednej stronie linkujemy je tworząc jeden spójny dokument. Nad każdą notatką pracuje się osobno, nie ma więc problemu by skupiać się tylko nad konkretnymi wątkami w oderwaniu od całości, a całość robi się automatycznie. To są składowe które czynią Markdown i Obsidian doskonałym połaczeniem.

Wersjonowanie – GitHub i OneDrive

Praca nad pojedynczymi notatkami powoduje od razu myśli, a może by wersjonować dokumentację na poziomie atomowym, a nie całości? Szczególnie że Obisidian to zwykła aplikacja która operuje na lokalnie trzymanych plikach tekstowych. Możemy jed modyfikować w Obsidiania, ale nic nie stoi na przeszkodzie żeby robić to w dowolnie innym edytorze (VSCode, Notepad). No to lecimy dalej, OneDrive i GitHub.

Z zebranych przeze mnie dobrych praktyk, co nie było łatwe bo ile osób tyle różnych zastosowań Obsidiana (jednak większość ludzi korzysta z niego do pisania bieżących notatek, czasami pisania prac naukowych). Pomysł jest żeby dokumenty trzymać na OneDrive.

OneDrive

OneDrive w darmowej wersji (wystarczy założyć konto) udostępnia 5 GB przestrzeni. Na pliki tekstowe i może trochę grafik jest to więcej niż potrzeba. OneDrive świetnie się synchronizuje, możemy mieć dostęp do plików z wielu lokalizacji, czy to przez witrynę internetową czy to ze smarfona. Dodatkowo mamy domyślne backupy, tj. Microsoft automatycznie przechowuje kilka ostatnich wersji każdego pliku, oraz 30 dni po jego skasowaniu. Na wypadek przypadkowego skasowania pliku lub zaszyfrowania przez Ransomware – jesteśmy w stanie przywrócić poprawną wersje plików.

GitHub

Drugim składnikiem który mi naszedł na myśl, to GitHub. Od już jakiegoś czasu darmowe konto GitHuba umożliwia tworzenie prywatnych repozytoriów. Nic nie stoi na przeszkodzie by trzymać dodatkowo wszystko w repo na GitHubie i automatycznie robić commity. Do tego stopnia automatycznie żeby zrobić zadanie w task schedulerze które co kilka minut będzie dokonywało synchronizacji.

To nam daje kolejną opcję, możemy pliki modyfikować bezpośrednio na GitHubie, albo możemy mieć repo GitHuba na wszystkich komputerach z których korzystamy (np. gdy nie chcemy mieć wszędzie podpiętego OneDrive).

Przykład własny – notatki z konfiguracji repo na GitHubie

Jako przykład zacząłem sobie spisywać notatki z konfiguracji synchronizacji przykładowego Vaulta Obsidiana z GitHubem. Po lewej mamy wszystkie notatki, które mogą być rozrzucone po strukturze katalogów, dodane pliki graficzne, a w środku notatka która łączy wszystkie pozostałe.

Praktyczne wykorzystanie Obsidiana do spisania na przyszłość jak konfigurowałem repozytorium GitHuba
Praktyczne wykorzystanie Obsidiana do spisania na przyszłość jak konfigurowałem repozytorium GitHuba

Po prawej w tym samym oknie wyświetliłem widok docelowy dokumentu, tam gdzie treści notatek zostały włączone do ostatecznego dokumentu.

Ostateczne gotowy projekt dokumentacji możemy wyeksportować do PDFa.

Podsumowanie

Ok, wymaga to przyswojenia trochę wiedzy jak tworzyć dokumenty typu Markdown, na razie najwięcej z tego korzystają studenci, bo zastępuje im Latexa, ale sama prostota edycji i linkowanie między sobą poszczególnych części przedstawia się bardzo obiecująco.

Zachęcam do wypróbowania, do celów prywatnych i freelancerskich jest darmowy – Obsidian.MD

IaaC – automatyzacja udostępniania maszyn wirtualnych na Hyper-V (Hyper-V IaaC cz. 2)

Powershell jest wystarczającym narzędziem umożliwiającym wykonanie wielu czynności. Świetnie to obrazuje projekt MSLab (wcześniej WSLab – stąd często przemiennie może pojawiać się jedna z nazw), dzięki któremu można stawiać szybkie rozwiązania PoC. Zachęcam do zapoznania się z tym projektem, szczególnie w przypadku budowy rozwiązań PoC. A to w takich przypadkach najczęściej zdarza się, że trzeba szybko wszystko postawić od zera, chociaż może nie tylko w takich przypadkach…

Poszedłem jednak trochę pod prąd, ponieważ wziąłem powyższy kod i wywaliłem to co mi się nie przydaje, dodałem to czego mi brakowało i teraz z powodzeniem stosuję również na produkcji stawiając setki maszyn wirtualnych.

Dlaczego tak? Mam pewność że skrypt się nagle nie zmieni, nie zniknie, mam zachowaną lokalnie taką wersję która dobrze działa w moim środowisku. A Czasami coś się hardokoduje w skrypcie żeby nie mnożyć parametrów które dla każdej maszyny są takie same, a utrudniają czytelność konfiguracji IaaC.

Ale od początku. Co uzyskamy za pomocą MSLab?

  1. Spreparujemy obraz systemu (VHDX), łącznie z wgraniem poprawek zabezpieczeń.
  2. Korzystając z powyższego obrazu i konfiguracji IaaC, utworzymy maszyny wirtualne i wstrzykniemy im wszystko co potrzebne do instalacji nienadzorowanej (włącznie z dodaniem do domeny!).

Przygotowanie obrazów systemów

Zaczynamy od pobrania paczki skryptów https://aka.ms/mslab/download i rozpakowujemy je do C:\WSLab.

Pobieramy również https://github.com/microsoft/MSLab/blob/master/Tools/DownloadLatestCUs.ps1 i zapisujemy do C:\WSLab.

Pobranie poprawek z Windows Update

Zaczynamy od skryptu DownloadLatestCUs.ps1, który uruchamiamy i wskazujemy by pobrał poprawki Cumulative Updates do katalogu C:\WSLab\UpdateRollup

Zależnie jakie docelowo systemy operacyjne chcemy stawiać, wskazujemy odpowiednie numery systemów. Dzięki temu spreparujemy obraz który będzie posiadał w sobie główne poprawki zabezpieczeń (odpada ręczne instalowanie i restartowanie systemu post factum – o ile będziemy utrzymywali dosyć świeży obraz startowy).

Windows Server 2016 LTSC to 1607, Windows Server 2019 LTSC to 1809. Szczegóły który numer co oznacza znajdziemy w https://docs.microsoft.com/pl-pl/windows-server/get-started/windows-server-release-info

Przygotowanie obrazów systemów

Pora na przygotowanie obrazu systemu. W swoich środowiskach korzystam z Windows Server 2019 Standard GUI, oraz Windows Server 2019 Datacenter CORE.
Żeby takie obrazy przygotować wpierw uruchamiamy skrypt (będąc w katalogu C:\WSLab) który pobierze wszystkie potrzebne komponenty do utworzenia obrazu systemu:

Następnie uruchamiamy już ostateczny skrypt przygotowujący obraz systemu:

W trakcie wykonywania podajemy namiary na obraz ISO systemu operacyjnego, katalog gdzie pobraliśmy najnowsze Cumulative Updates do systemu, oraz wskazujemy wersję systemu który ma zostać przygotowany:
– 2019 GUI Standard (1809)
– 2019 CORE Datacenter (1809)

Dysk C: ustawiamy na rozmiar 64 GB.

Obrazy systemów zapisałem pod nazwami:
– Win2019_GUI_Standard_2021_02.vhdx
– Win2019_CORE_Datacenter_2021_02.vhdx

IaaC – Infrastructure as a Code

Bardzo modne ostatnio hasło. Do tej pory tworzenie maszyn wirtualnych na Hyper-V nie było za dobrze zagospodarowane. Był Virtual Machine Manager, który jednak w moich środowiskach powodował problemy wydajnościowe więc z niego zrezygnowałem, można posiłkować się Vagrantem – ale nie przekonał mnie żeby korzystać z niego na produkcji.

Rozwiązanie w pełni oparte na Powershellu ma dla mnie tę ogromną zaletę, że do wszystkiego co się po drodze dzieje mamy wgląd. Wystarczy dowolny edytor tekstu i możemy po kolei prześledzić jakie komendy są wykonywane, a jak potrzebujemy to wykorzystać je również w innych miejscach.

Przygotowanie sieci wirtualnej

Zanim wystartujemy z tworzeniem maszyn wirtualnych, musimy utworzyć dla nich wirtualną sieć do której będziemy je podpinać. Na potrzeby budowania środowiska PoC tworzę sieć typu internal, dzięki czemu wszystkie maszyny wirtualne są odizolowane od świata zewnętrznego, zachowując jednak dostęp do Internetu. Do maszyn dostęp jest tylko z hosta Hyper-V.

Tworzenie sieci opisałem w https://takietam.eu/konfiguracja-sieci-hyper-v-dla-srodowisk-poc-win10

Tworzymy pierwszą maszynę – kontroler domeny

W każdym środowisku zwykle trzeba wystartować od domeny. MSLab potrafi to zrobić za nas, ale w większości przypadków wolę mieć większą kontrolę nad tym co się dzieje. Dlatego pierwsza maszyna jaką wdrożę, będzie ta przeznaczona na kontroler domeny.

Przygotowujemy plik LabConfig.ps1 o zawartości:

We wszystkich przykładach korzystam ze swojej zmodyfikowanej wersji https://github.com/lukaszherman/WsLab/blob/main/POC_local_hyperv.ps1

Azure DevOps Library backup

Na dzisiaj w Azure nie mamy natywnego sposobu na backupowanie zasobów typu Library w Azure DevOps.
Jak temu zaradzić?

Instalacja AZ CLI

Rozwiązaniem stosowanym przeze mnie jest wykorzystanie powershella i modułu AZ.
Niestety komendy którymi się posługuję są obecnie w wersji 'preview’, tj. mogą się kiedyś zmienić i działać inaczej lub przyjmować inne parametry.

W pierwszej kolejności instalujemy u siebie odpowiedni moduł powershella:

Następnie uwierzytelniamy się w Azure naszym kontem:

Wylistowanie Library

Pierwsze co zróbmy to sprawdźmy jakie pozycje mamy w Library. Do tego potrzebujemy znać nazwę naszej organizacji i projektu. Odczytujemy to logując się do https://dev.azure.com

Następnie po wejściu w Azure DevOps w lewym menu wybieramy organizację a w prawym oknie mamy projekty.

Główna strona Azure DevOps - wybór organizacji i projektu
Główna strona Azure DevOps – wybór organizacji i projektu

Za pomocą komendy poniżej listujemy wszystkie pozycje w Library:

Azure DevOps Library list

Mam zasadę, że dla każdej aplikacji (razy ilość środowisk) mam osobne ustawienia dla IISa, SQLa i samej aplikacji. Trzymam konfiguracje wszystkich aplikacji, których dystrybucja odbywa się z użyciem Continous Deployment obsługiwanym przez Azure.

Dla kilkunastu aplikacji lista robi się już długa.

Pobranie pojedynczych ustawień

Jeżeli potrzebujemy pobrać ustawienia tylko dla jednego elementu z Library, to potrzebujemy jego numeru ID, który uzyskaliśmy wyżej. Np. dla ID 6 ustawienia pobierzemy za pomocą polecenia:

Wynikiem tego polecenia będzie wynik w formacie JSON który możemy zapisać w formie pliku – to jest nasz backup.
Uwaga. Jeżeli wartość była oznaczone jako 'Secret’, nie wyciągniemy jej wartości. Warto mieć to na względzie i wszelkie hasła i tokeny trzymać w niezależnym i bezpiecznym miejscu.

Pobranie wszystkich ustawień i zapis do plików

Jak mamy kilka pozycji w Library to możemy skorzystać z polecania powyżej i ręcznie wyciągać wartości dla wszystkich ustawień. Jeżeli jest ich więcej, lepiej jest przeiterować się pętlą po wszystkich pozycjach i zapisać je do plików.

A co z odtwarzaniem?

Na razie nie miałem czasu do tego usiąść. Backupy do tej pory potrzebowałem tylko na zasadzie „A co było tam ustawione miesiąc temu, że teraz nie działa?”.

Znalazłem, że ktoś już napisał skrypt odtwarzający wpisy z Library, ale jako wejście przyjmuje plik CSV, a nie JSON (prawie na pewno da się zastosować bez zmian, tylko trzeba przetransponować JSONa na CSV):

https://www.powershellgallery.com/packages/Posh-AzureDevOps/1.0.7/Content/modules%5CLibraries%5CImport-AzDoVariableGroupVariables.psm1

https://github.com/ravensorb/Posh-AzureDevOps

Szybka instalacja kontrolera domeny Active Directory

Czasami na szybko potrzebujemy postawić maszynę wirtualną i skonfigurować na niej domenę. Całkiem sporo klikania które da się uprościć.

Nawet jak nie robimy tego na szybko, a ze względów na plan Disaster Recovery potrzebujemy mieć wszystko opisane jako kod, poniższe komendy mogą się przydać.

Na początku potrzebujemy postawić najprostszą możliwą maszynę wirtualną, np. Windows Server 2019 w wersji Core. Zwykle takiego typu maszynom ustawiam 2 procesory i kilka GB pamięci przydzielanej dynamicznie (w praktyce zwykle taka maszyna zużywa w okolicach 1 GB. Następnie uruchamiamy:

Instalacja wymaganych komponentów

Konfiguracja Active Directory

W czasie instalacji musimy tylko podać hasło do odzyskiwania domeny i po paru chwilach wszystko gotowe.

Warto zadbać żeby kontroler domeny miał stały adres IP, ponieważ wszystkie maszyny dołączane do domeny powinny korzystać z DNS zainstalowanego na kontrolerze domeny.

Weryfikację instalacji możemy wykonać komendą:

Konfiguracja sieci Hyper-V dla środowiska PoC (Hyper-V IaaC cz. 1)

Budując kolejne środowisko Proof of Concept (PoC) stanąłem przed wyzwaniem by był ono uniezależnione od wszystkich innych maszyn wirtualnych. To co udało się osiągnąć, to również szybki sposób na budowanie kolejnych sieci bez ryzyka, że wyczerpiemy pulę adresów IP w lokalnej sieci (często na 24 bitach, a jak zaczniemy się bawić w kontenery albo inne automaty to się okazuje, że to nie problem wysycić taki zapas adresów).

Punkt wejścia to posiadanie systemy Windows 10 Pro z zainstalowanym Hyper-V. Na Windows Server możemy zrobić to samo, ale w tym przypadku stawiam wszystko na systemie klienckim.

Konfiguracja switcha

Wpierw tworzymy switch typu internal. Takie rozwiązanie umożliwi nam bezproblemową komunikację wew. tworzonego środowiska, dostęp z wewnątrz do Internetu, oraz dostęp z hosta do usług które budujemy w warstwie wirtualizacji.

Zaczynamy od utworzenie switcha, np. o nazwie PocSwitchTest:

Konfiguracja NAT

Następnie żeby zapewnić komunikację o której wspomniałem wyżej, konfigurujemy zakres sieci (w gratisie mamy DHCP i DNS) i rezerwujemy pierwszy adres sieci dla naszego hosta – którym jest lokalny komputer z Hyper-V:

W tym przypadku zrobiłem sieć 192.168.123.0/24, ale to może być dowolna inna byle nie kolidowała z naszą fizyczną i innymi wirtualnymi sieciami.

Tworzenie switcha nie zrywa żadnego połączenia, można to robić łącząc się zdalnie do danej maszyny.

Gdybyśmy chcieli posprzątać, to dwie komendy (zakładając że do utworzonego switcha nic nie podłączyliśmy).

Podsumowanie

Tworząc maszyny wirtualne przypinamy je do utworzonego switcha i cieszymy się działającą siecią (jedna z innych sieci o nazwie PocSwitch i adresacji 192.168.0.0/24).

I widok z wewnątrz utworzonej maszyny wirtualnej (maszyna ma dwa adresy IP .110 i .111, brama wskazuje na adres .1 przypisany do maszyny-hosta):