Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.



25.09.2020

Konferencja PIKE 2020 „Nowy...

Liderzy branży telekomunikacji i mediów o nowych wyzwaniach i przyszłości branży w...
24.09.2020

Microsoft ogłosił harmonogram...

Ta chwila prędzej czy później musiała nadejść – Microsoft ogłosił harmonogram porzucania...
24.09.2020

Nowe mobilne jabłka

Premiera iOS-a 14
24.09.2020

Kompleksowa ochrona

Kaspersky 2021
24.09.2020

Kolejny zielony robot

Android 11
24.09.2020

Mobilne bezpieczeństwo

ESET Mobile Security 6.0
24.09.2020

QNAP

QNAP wprowadził na rynek serwery NAS serii TS-x32PXU przeznaczone do montażu w szafie...
24.09.2020

Wytrzymałe SSD

WD My Passport
24.09.2020

Laptopy dla biznesu

MSI Summit

Wirtualizacja sieci w Linuksie

Data publikacji: 16-07-2020 Autor: Grzegorz Kuczyński

Wirtualizacja warstwy trzeciej (L3) wśród wielu producentów urządzeń sieciowych często oferowana jest pod nazwą Virtual Routing and Forwarding (VRF). Linux funkcję tę implementuje w ramach mechanizmu przestrzeni nazw.

 

Namespaces zostały dodane do jądra systemu Linux już w 2013 roku i stały się podwalinami wielu popularnych rozwiązań wirtualizacji systemowej, np. Dockera czy Kubernetes, oraz sieciowych, jak choćby Open vSwitch. Jednak przestrzenie nazw to mechanizm o znacznie szerszym zastosowaniu niż tylko sama sieć. W zasadzie dotyczy kluczowych kategorii zasobów, które należy poddać separacji przy tworzeniu wirtualizacji na poziomie systemu. Zaliczamy do nich identyfikację (nazwę) hosta UTS, komunikację międzyprocesową IPC, przestrzeń procesów PID, sieć oraz ID użytkowników i grup. W niniejszym tekście skupimy się tylko na jednej z powyższych kategorii, jaką są sieciowe przestrzenie nazw. Zaprezentowane zostaną sposoby użycia i zastosowania z perspektywy administracji systemu.

 

> NETWORK NAMESPACES


Pojedyncza przestrzeń nazw dla sieci tworzy w zasadzie wirtualny host. Posiada oddzielną tablicę routingu, reguły routingu, zaporę L2 i L3 (ebtables, iptables), traffic control i wszystko, co związane jest z obsługą protokołów IPv4 i IPv6. Ponadto możemy dla konkretnego procesu przypisać oddzielną sieciową przestrzeń nazw, a co za tym idzie – możemy w niej uruchamiać usługi sieciowe. Oczywiście przy bardziej złożonych usługach zdecydowanie lepszym rozwiązaniem będzie konteneryzacja. Mimo to znajomość mechanizmu network namespaces (netns) może nam wielokrotnie pomóc podczas rozwiązywania problemów z siecią w różnego rodzaju kontenerach działających w systemach Linux.

 

> PODSTAWOWE POLECENIA

 

W systemie Linux niemal każdy mechanizm jądra jest kontrolowany za pomocą narzędzi CLI. W tym przypadku posłuży nam ip z pakietu iproute2. Za jego pomocą możemy tworzyć nowe przestrzenie sieci i zarządzać nimi. Dla przykładu wydajmy kilka prostych poleceń.

 


Możemy zauważyć, że w nowo powstałej przestrzeni sieciowej znajduje się tylko interfejs lo, w dodatku wyłączony. Nie ma w nim żadnych reguł dla routingu, jest zupełnie nieskonfigurowany, chociaż dziedziczy on pewne ustawienia z głównej przestrzeni sieciowej. Dzieje się tak głównie dlatego, że nowy network namespace tworzony jest za pomocą funkcji systemowej clone(), a jej działanie polega na dziedziczeniu od procesu nadrzędnego. Jeżeli po utworzeniu testowej przestrzeni sprawdzimy w niej wartość sieciowego parametru jądra net.ipv4.ip_forward, to okaże się, że jest on taki sam, jak w systemie gospodarza. Co ciekawe, możemy go niezależnie zmienić:

 


Zmiana ta nie będzie jednak obowiązywać po restarcie systemu. Aby miał stały charakter, musimy ją zapisać w pliku konfiguracyjnym. Ale tu pojawia się pewien problem – skoro przestrzeń sieciowa dotyczy tylko sieci, a nie dysku, to gdzie taki plik należy utworzyć? Rozwiązano to już podczas projektowania przestrzeni nazw jądra Linux. W tym celu utworzono pewną zasadę – jeżeli stworzymy netns o nazwie test, to pliki konfiguracyjne znajdujące się w katalogu /etc/netns/test/ „przykrywają” te z katalogu /etc/. Bardzo łatwo to zobrazować – plik sysctl.conf znajdujący się w głównej przestrzeni oraz plik z przestrzeni test są w rzeczywistości tym samym plikiem:

 


W celu utworzenia oddzielnego pliku konfiguracyjnego dla naszej przestrzeni musimy wykonać poniższe kroki:

 


Teraz możemy dokonać w nim zmian, zresetować przestrzeń testową i załadować zmiany ze specjalnie przygotowanego dla niej pliku konfiguracyjnego:

 


Przy okazji warto również dodać, że każda przestrzeń sieciowa dysponuje oddzielnym katalogiem /proc/net oraz /sys/class/net z ustawieniami sieciowymi:

 


> PRZYDATNE POLECENIA


Wykonywanie poleceń w oddzielnej przestrzeni za pomocą polecenia ip netns exec doskonale sprawdza się w skryptach służących do automatyzacji zadań, jednak do testowania czasami wygodniej robić to w pełni interaktywnie. Jak już wcześniej wspominaliśmy, w przestrzeni sieciowej możemy wykonywać procesy, więc może to być oddzielna powłoka shell:

 


Teraz, gdy został już uruchomiony proces w naszej testowej przestrzeni sieciowej, można podejrzeć go w oddzielnym terminalu:

 


Niestety, metoda ta działa tylko wtedy, gdy mamy do czynienia z przestrzenią nazw utworzoną za pomocą narzędzia ip, nie zaś funkcji systemowych w kodzie jakiegoś programu. Warto przy tej okazji wspomnieć o poleceniu nsenter, które pobiera ID ze wskazanego procesu określonej przestrzeni nazw i pozwala wykonać w niej zadane polecenie. Przykładowo jeżeli wiemy, że proces bash PID 10168 jest w oddzielnej netns i chcemy zajrzeć do środka, możemy wykonać poniższe polecenie.

 


Polecenie to przydaje się głównie, gdy mamy do czynienia z jakimiś kontenerami i chcemy dowiedzieć się czegoś więcej o ich działaniu.

 

> TESTOWANIE

 

Już na samym początku tego tekstu porównaliśmy linuksowy network namespaces do VRF. Mimo iż jest ono częściowo uzasadnione, to jednak nie do końca trafne. VRF oferuje bowiem tylko oddzielną tablicę routingu, podczas gdy przestrzenie nazw dla sieci oferują kompletny stos sieciowy. Ponadto linuksowy VFR można zagnieździć w netns, wykorzystamy ten fakt w naszym pierwszym przykładzie na rys. 1.
Aby odtworzyć ten schemat, musimy dowiedzieć się, w jaki sposób łączyć ze sobą oddzielne przestrzenie sieciowe. Służą do tego wirtualne interfejsy Ethernet (veth), które tworzy się w parach. Pomiędzy nimi tworzony jest wirtualny tunel umożliwiający przekazywanie pakietów. Na schemacie widzimy, że potrzebne są trzy przestrzenie i cztery wirtualne połączenia.

 

[...]

 

Autor zawodowo zajmuje się informatyką. Jest członkiem społeczności open source, prowadzi blog nt. systemu GNU/Linux.

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"