W dzisiejszych środowiskach chmurowych i kontenerowych wirtualizacja sieci stała się nieodzownym elementem infrastruktury IT. System Linux oferuje bogaty zestaw narzędzi wbudowanych bezpośrednio w jądro, które pozwalają na tworzenie zaawansowanych topologii sieciowych bez konieczności stosowania dedykowanego sprzętu sieciowego.

Mostek sieciowy (bridge) to wirtualny przełącznik L2 działający w przestrzeni jądra, który potrafi uczyć się adresów MAC i podejmować decyzje o przekazywaniu ramek na podstawie tablicy forwardingowej. W przeciwieństwie do przełączników fizycznych, mostek Linux jest w pełni programowalny i może być zarządzany przez narzędzia takie jak iproute2, bridge czy brctl.

Pary VETH (Virtual Ethernet) to wirtualne kable łączące dwa interfejsy w różnych przestrzeniach nazw. Są one fundamentalne dla izolacji sieciowej w kontenerach i maszynach wirtualnych. Każda para VETH działa jak przewód z dwoma końcami: ramka wysłana na jednym końcu pojawia się na drugim.

Docker rozszerza te mechanizmy o warstwę zarządzania sieciami, oferując gotowe sterowniki sieciowe takie jak bridge, host, overlay i macvlan. Najpopularniejszym trybem jest mostek docker0, który automatycznie tworzy prywatną podsieć dla kontenerów i konfiguruje reguły iptables do translacji adresów.

Zrozumienie tych mechanizmów jest kluczowe dla każdego administratora pracującego z kontenerami, ponieważ pozwala na świadome projektowanie architektury sieciowej, debugowanie problemów z łącznością oraz optymalizację wydajności.

Pierwszym celem jest zrozumienie, w jaki sposób Linux implementuje funkcje przełącznika warstwy 2 bezpośrednio w jądrze systemu. Większość administratorów zna pojęcie przełącznika sieciowego jako urządzenia fizycznego, ale mało kto zdaje sobie sprawę, że to samo można zrealizować w czystym oprogramowaniu z wydajnością bliską sprzętowej.

Drugim celem jest praktyczna umiejętność konfiguracji mostka za pomocą poleceń takich jak ip link add type bridge oraz bridge fdb add. Uczestnik powinien być w stanie samodzielnie zbudować wirtualną sieć składającą się z wielu przestrzeni nazw połączonych mostkiem.

Trzeci cel to opanowanie koncepcji VETH i network namespaces. Uczestnik nauczy się tworzyć izolowane stosy sieciowe i łączyć je kablami wirtualnymi na różne sposoby: bezpośrednio, przez mostek, a także z użyciem trasowania.

Czwarty cel to dogłębna znajomość sieci Docker. Uczestnik przeanalizuje strukturę mostka docker0, reguły iptables tworzone automatycznie przez Dockera, oraz zrozumie różnice pomiędzy poszczególnymi trybami sieciowymi.

Piąty cel to mechanizm -p w Dockerze, który jest najczęściej używanym, a jednocześnie najmniej rozumianym aspektem sieci kontenerowej. Zrozumienie DNAT i masquerade pozwoli uczestnikowi na samodzielne debugowanie problemów z dostępem do usług w kontenerach.

Ostatni cel to praktyczne debugowanie. Uczestnik pozna narzędzia takie jak tcpdump do przechwytywania pakietów, nsenter do wchodzenia do przestrzeni nazw procesu, oraz bridge do przeglądania tablicy FDB.

Agenda została zaplanowana w taki sposób, aby stopniowo budować wiedzę od podstaw teoretycznych do zaawansowanych koncepcji praktycznych. Pierwsza część wykładu (slajdy 4-12) poświęcona jest ewolucji sieci komputerowych i mostkowi Linux. Zrozumienie tych fundamentów jest niezbędne do dalszej nauki.

Druga część (slajdy 13-20) wprowadza pary VETH i przestrzenie nazw sieciowych. To kluczowe koncepcje dla zrozumienia izolacji w kontenerach. Uczestnik nauczy się tworzyć odizolowane środowiska sieciowe i łączyć je na różne sposoby.

Trzecia część (slajdy 21-30) koncentruje się na sieciach Docker. Przeanalizujemy wszystkie tryby sieciowe, od całkowitej izolacji (none) przez współdzielenie stosu (host) po domyślny mostek (bridge). Szczególna uwaga poświęcona jest adresacji IP i komunikacji pomiędzy kontenerami.

Czwarta część (slajdy 31-38) to dogłębna analiza mechanizmu publikowania portów. Uczestnik dowie się, co dokładnie dzieje się w iptables po wykonaniu docker run -p.

Piąta część (slajdy 39-44) to laboratorium, w którym uczestnicy ręcznie odtworzą to, co Docker robi automatycznie. To kluczowy moment warsztatu, ponieważ pozwala na zrozumienie, a nie tylko mechaniczne używanie narzędzi.

Ostatnia część (slajdy 45-50) to troubleshooting i podsumowanie. Uczestnik otrzyma zestaw narzędzi i technik do samodzielnego rozwiązywania problemów sieciowych, a także ściągawkę z najważniejszymi poleceniami.

przełączniki fizyczne wykorzystują wyspecjalizowane układy ASIC (Application-Specific Integrated Circuit) do przetwarzania ramek z szybkością linii. Każdy port przełącznika ma dedykowany bufor, a decyzje forwardingowe podejmowane są w czasie rzeczywistym na podstawie odczytu nagłówków ramek. Proces uczenia się adresów MAC polega na analizie adresów źródłowych w przychodzących ramkach i zapisywaniu ich w tablicy FDB z przypisaniem do numeru portu.

W mostku Linux cała ta funkcjonalność jest zaimplementowana w kodzie jądra (net/bridge/) i wykorzystuje ogólny mechanizm sieciowy Netlink. Mostek rejestruje się jako wirtualne urządzenie sieciowe i może agregować dowolną liczbę interfejsów fizycznych lub wirtualnych. Każda ramka przychodząca na którykolwiek z portów jest analizowana przez kod mostka.

SDN wprowadza rewolucję poprzez oddzielenie płaszczyzny sterowania (control plane) od płaszczyzny danych (data plane). W modelu OpenFlow kontroler SDN może dynamicznie zarządzać tablicami przepływów na przełączniku, co umożliwia programowalne zarządzanie ruchem sieciowym. Mostek Linux nie implementuje OpenFlow natywnie, ale może być rozszerzony przez Open vSwitch.

W kontekcie wirtualizacji centrów danych mostek Linux jest często używany jako prosty, wydajny przełącznik wirtualny dla maszyn wirtualnych (KVM, QEMU) i kontenerów (Docker, LXC). Jego zaletą jest zerowy koszt licencyjny, pełna integracja z jądrem oraz możliwość zarządzania standardowymi narzędziami.

W praktyce mostek Linux znajduje zastosowanie tam, gdzie potrzebna jest prosta łączność L2 pomiędzy wirtualnymi interfejsami. Dla bardziej zaawansowanych funkcji sieciowych (VXLAN, tunelowanie, QoS) stosuje się Open vSwitch, który oferuje bogatszy zestaw funkcji kosztem większego skomplikowania.

Koncepcja SDN narodziła się na Uniwersytecie Stanforda jako projekt Ethane, a następnie została rozwinięta w protokół OpenFlow. Głównym założeniem było uczynienie sieci programowalną, tak jak programowalne są serwery. W modelu tradycyjnym każdy przełącznik podejmuje samodzielne decyzje na podstawie rozproszonych protokołów (STP, OSPF, BGP). W SDN decyzje są scentralizowane w kontrolerze.

Linux, jako system uniwersalny, oferuje wiele mechanizmów programowalnego przetwarzania pakietów. Traffic Control (tc) pozwala na definiowanie kolejek i dyscyplin dla poszczególnych interfejsów. Można tworzyć złożone hierarchie klasyfikacji ruchu z użyciem filtrów na podstawie adresów, portów, a nawet głębokiej inspekcji pakietów.

eBPF (Extended Berkeley Packet Filter) to przełomowa technologia, która pozwala na uruchamianie sandboxowanych programów w jądrze Linux bez konieczności pisania modułów jądra. Programy eBPF mogą być podpięte do punktów zaczepienia w stosie sieciowym, takich jak wejście pakietu (XDP), gniazdo, czy funkcja jądra. Dzięki temu można implementować własną logikę przetwarzania pakietów z wydajnością bliską natywnej.

Open vSwitch (OVS) to implementacja rozproszonego wirtualnego przełącznika wielowarstwowego, która obsługuje protokół OpenFlow i jest kompatybilna z SDN. OVS jest często używany w środowiskach chmurowych (OpenStack, OpenNebula) do realizacji zaawansowanych funkcji sieciowych, takich jak tunelowanie VXLAN, GRE, czy izolacja dzierżawców.

VRF (Virtual Routing and Forwarding) to mechanizm pozwalający na utrzymanie wielu niezależnych tablic routingu na jednym hoście. Każda VRF ma własną tablicę routingu, własny zestaw interfejsów i własne reguły forwardingowe. Jest to odpowiednik technologii MPLS L3VPN, ale zaimplementowany w przestrzeni użytkownika przy użyciu standardowych narzędzi Linux.

Moduł bridge został dodany do jądra Linux w wersji 2.4 i od tego czasu jest stale rozwijany. Implementacja znajduje się w katalogu net/bridge/ źródła jądra. Mostek jest zarejestrowany jako wirtualne urządzenie sieciowe i może być konfigurowany za pomocą standardowych narzędzi z rodziny iproute2.

Wewnętrzna architektura mostka opiera się na tablicy haszującej przechowującej wpisy FDB. Każdy wpis zawiera adres MAC, identyfikator portu (interfejsu), znacznik czasu ostatniego odświeżenia oraz flagi (np. czy wpis jest stały czy dynamiczny). Tablica jest przeszukiwana przy każdej ramce, która nie jest przeznaczona dla samego mostka.

Mostek obsługuje trzy typy portów: porty członkowskie (member ports), port macierzysty (bridge master) oraz porty specjalne (np. port STP). Każdy interfejs dodany do mostka traci swoją niezależną konfigurację IP na rzecz interfejsu mostka. Adres IP mostka staje się adresem IP całej sieci wirtualnej.

Jedną z kluczowych cech mostka jest obsługa STP (Spanning Tree Protocol) zgodnie z IEEE 802.1D. STP zapobiega powstawaniu pętli w sieci poprzez blokowanie nadmiarowych portów. W mostku Linux STP jest domyślnie wyłączony, co w środowiskach kontenerowych zazwyczaj nie stanowi problemu, ponieważ topologie są z założenia acykliczne.

Od jądra 3.8 mostek obsługuje filtrowanie VLAN (802.1Q), co pozwala na tworzenie wirtualnych sieci w ramach jednego mostka. Funkcja ta jest szczególnie przydatna w środowiskach chmurowych, gdzie wymagana jest izolacja pomiędzy różnymi dzierżawcami na wspólnej infrastrukturze.

Polecenie ip link add name br0 type bridge tworzy nowe wirtualne urządzenie sieciowe typu bridge. W jądrze proces ten obejmuje alokację struktury net_device, inicjalizację tablicy FDB, utworzenie kolejki transmisyjnej oraz rejestrację urządzenia w systemie Netlink, co umożliwia zarządzanie mostkiem przez narzędzia przestrzeni użytkownika.

Po utworzeniu mostka należy go podnieść do stanu UP za pomocą ip link set br0 up. Bez tego mostek nie będzie przetwarzał ramek. Stan interfejsu można sprawdzić poleceniem ip link show br0, które wyświetli m.in. adres MAC mostka, MTU, stan oraz flagi.

Dodanie interfejsu do mostka za pomocą ip link set eth0 master br0 powoduje, że interfejs eth0 staje się portem członkowskim mostka. Od tego momentu eth0 przestaje być samodzielnym interfejsem L3 i działa wyłącznie na poziomie L2 w ramach mostka. Adres IP przypisany do eth0 przestaje być widoczny.

Starsze narzędzie brctl (bridge control) pochodzi z pakietu bridge-utils i było standardem w starszych dystrybucjach. Polecenia takie jak brctl addbr, brctl addif, brctl delif są intuicyjne, ale nie oferują wszystkich możliwości, jakie daje nowsze iproute2. Ponadto brctl jest uważane za przestarzałe w wielu nowoczesnych dystrybucjach Linux.

Usunięcie interfejsu z mostka wykonuje się poleceniem ip link set eth0 nomaster. Usunięcie całego mostka wymaga uprzedniego usunięcia wszystkich portów członkowskich, a następnie wywołania ip link delete br0 type bridge. W przypadku brctl odpowiada temu brctl delbr br0.

Tablica FDB jest podstawową strukturą danych mostka. Każdy wpis zawiera adres MAC (48 bitów), identyfikator portu wyjściowego (dev), znacznik czasu ostatniego odświeżenia (aging timer) oraz flagę określającą typ wpisu: dynamiczny (uczony automatycznie), statyczny (dodany ręcznie) lub trwały (permanent). Domyślny czas życia wpisu dynamicznego to 300 sekund.

Proces uczenia działa następująco: gdy mostek otrzymuje ramkę na porcie P, odczytuje adres MAC źródłowy (SA) z nagłówka Ethernet. Jeśli SA nie istnieje w tablicy FDB, tworzony jest nowy wpis z adresem MAC, przypisaniem do portu P oraz bieżącym znacznikiem czasu. Jeśli wpis już istnieje, jest odświeżany.

Decyzja o przekazaniu ramki (forwarding) podejmowana jest na podstawie adresu MAC docelowego (DA). Jeśli DA znajduje się w tablicy FDB, ramka jest wysyłana tylko na port przypisany do tego adresu (unicast forwarding). Jeśli DA nie istnieje, ramka jest rozgłaszana na wszystkie porty poza portem źródłowym (flooding). Ramki broadcast (FF:FF:FF:FF:FF:FF) są zawsze rozgłaszane.

Polecenie bridge fdb show wyświetla całą tablicę FDB. Można ograniczyć wyniki do konkretnego mostka flagą br br0. W systemach z wieloma mostkami polecenie to jest nieocenione przy debugowaniu problemów z łącznością, pozwala bowiem sprawdzić, czy mostek nauczył się adresu MAC danego interfejsu.

Statyczne wpisy FDB są używane, gdy chcemy wymusić określoną ścieżkę dla ruchu do danego adresu MAC, na przykład w przypadku równoważenia obciążenia lub integracji z zewnętrznymi przełącznikami. Wpisy statyczne nie podlegają starzeniu i nie są usuwane automatycznie.

Algorytm forwardingu w mostku Linux jest zaimplementowany w funkcji br_handle_frame_finish w pliku net/bridge/br_forward.c. Gdy ramka dociera do tej funkcji, mostek najpierw sprawdza, czy docelowy adres MAC jest adresem samego mostka (np. adres MAC interfejsu br0). Jeśli tak, ramka jest kierowana do stosu IP, co umożliwia komunikację z samym hostem.

Jeśli docelowy adres MAC nie należy do mostka, rozpoczyna się proces forwardingu. Mostek przeszukuje tablicę FDB w poszukiwaniu wpisu pasującego do docelowego adresu MAC. Wyszukiwanie odbywa się w czasie O(1) dzięki zastosowaniu tablicy haszującej z 256 koszykami (dla adresów MAC o długości 48 bitów).

Znalezienie wpisu w FDB skutkuje przekazaniem ramki na port wskazany w tym wpisie, pod warunkiem że port ten różni się od portu źródłowego. Jeśli port źródłowy i docelowy są takie same, ramka jest odrzucana, co zapobiega cyrkulacji ruchu w obrębie jednego portu.

Brak wpisu w FDB powoduje flooding: ramka jest wysyłana na wszystkie porty członkowskie z wyjątkiem portu, na którym przyszła. Flooding jest kosztowny, ale konieczny do utrzymania łączności, gdy mostek nie zna jeszcze lokalizacji docelowego MAC. W sieciach o dużym ruchu flooding może prowadzić do znacznego obciążenia.

Warto zauważyć, że mostek Linux obsługuje również przekazywanie ramek z użyciem VLAN. Jeśli na moście skonfigurowano filtrowanie VLAN, ramka jest forwardowana tylko do tych portów, które należą do tej samej sieci VLAN. Mechanizm ten implementuje standard IEEE 802.1Q w jądrze systemu.

W przypadku maszyn wirtualnych KVM/QEMU mostek jest najczęściej używany w konfiguracji macvtap lub bridge. W trybie mostka fizycznego interfejs hosta (np. eth0) jest dodawany do mostka br0, a maszyny wirtualne podłączają się przez interfejsy tap. Dzięki temu maszyny wirtualne są widoczne w tej samej podsieci co host, bez translacji adresów.

Interfejsy TAP (Terminal Access Point) to wirtualne urządzenia sieciowe działające w warstwie L2. W przeciwieństwie do TUN (działających w L3), TAP obsługuje pełne ramki Ethernet. QEMU tworzy interfejs TAP dla każdej maszyny wirtualnej i przypisuje go do mostka. Nazwy interfejsów TAP mają zwykle postać vnet0, vnet1 itd.

Docker używa mostka jako domyślnego sterownika sieciowego. Podczas instalacji Docker tworzy mostek docker0 z domyślną podsiecią 172.17.0.0/16. Każdy nowo utworzony kontener otrzymuje parę VETH: jeden koniec (eth0 w kontenerze) znajduje się w przestrzeni nazw kontenera, drugi (vethXXXXX) jest podłączony do mostka docker0.

Zaletą używania mostka w wirtualizacji jest pełna transparentność L2: maszyny wirtualne i kontenery mogą komunikować się bezpośrednio ze sobą i z hostem, o ile znajdują się w tej samej domenie broadcastowej. Ponadto mostek nie wymaga konfiguracji trasowania IP, co upraszcza zarządzanie.

W środowiskach produkcyjnych często stosuje się zaawansowaną konfigurację z wieloma mostkami, każdy dla innej sieci VLAN, co pozwala na izolację ruchu pomiędzy różnymi grupami maszyn wirtualnych lub kontenerów bez użycia dodatkowych firewalli.

Narzędzie ip z pakietu iproute2 jest obecnie standardowym narzędziem do konfiguracji sieci w Linux. Zastąpiło ono starsze narzędzia takie jak ifconfig, route i brctl. Główną zaletą iproute2 jest ujednolicony interfejs do zarządzania wszystkimi aspektami sieci: interfejsami, adresami, routingiem, tunelami i mostkami.

Polecenie ip link add name br0 type bridge tworzy mostek, ale nie jest to jedyny sposób. Można również użyć ip link add name br0 type bridge vlan_filtering 1, aby od razu włączyć filtrowanie VLAN. Dodatkowe parametry to m.in. ageing_time (czas starzenia wpisów FDB), group_fwd_mask (maska forwardowania grup) i stp_state (stan STP).

Narzędzie bridge (część iproute2) służy do szczegółowego zarządzania mostkiem. Polecenie bridge fdb show wyświetla tablicę FDB. bridge fdb add i bridge fdb del pozwalają na ręczne modyfikowanie wpisów. bridge link zarządza właściwościami portów, takimi jak hairpin mode (pozwala na przekazywanie ramek z powrotem na ten sam port).

Starszy pakiet bridge-utils zawiera narzędzie brctl, które jest prostsze, ale mniej elastyczne. Polecenia takie jak brctl show, brctl showmacs br0, brctl setpathcost br0 1 100 są nadal używane w starszych dokumentacjach i skryptach. W nowych instalacjach zaleca się jednak używanie iproute2.

Do diagnostyki mostka przydatne jest polecenie ip link show master br0, które wyświetla wszystkie interfejsy podłączone do mostka, oraz bridge monitor, które na bieżąco pokazuje zmiany w tablicy FDB i stan portów.

MAC flapping to sytuacja, w której mostek wielokrotnie zmienić przypisanie tego samego adresu MAC do różnych portów w krótkim czasie. Jest to zazwyczaj oznaka pętli w sieci: ramki z tym samym adresem MAC źródłowym docierają na różne porty mostka, co zmusza go do ciągłej aktualizacji tablicy FDB. Każda taka zmiana jest rejestrowana w logach jądra, widocznych przez dmesg.

Zapętlenie ramek (broadcast storm) występuje, gdy w sieci istnieje cykl, w którym ramki broadcast są nieustannie przekazywane między mostkami. W skrajnych przypadkach może to doprowadzić do całkowitego paraliżu sieci z powodu 100% wykorzystania CPU przez procesy obsługi przerwan sieciowych. Rozwiązaniem jest włączenie STP (Spanning Tree Protocol), które blokuje nadmiarowe porty, przerywając cykl.

STP w mostku Linux jest domyślnie wyłączony, ponieważ w typowych konfiguracjach wirtualizacyjnych topologia jest acykliczna (drzewiasta). Jednak w przypadku połączenia mostka Linux z fizycznym przełącznikiem obsługującym STP, albo przy łączeniu wielu mostków między sobą, włączenie STP jest konieczne, aby uniknąć pętli.

Brak łączności między portami mostka może wynikać z kilku przyczyn: interfejs może nie być poprawnie dodany do mostka (sprawdź ip link show master br0), adresacja IP może być nieprawidłowa (mostek wymaga adresu IP tylko na interfejsie br0, nie na portach członkowskich), lub reguły firewalla (iptables) mogą blokować ruch między portami mostka.

Hairpin mode to specjalna konfiguracja portu mostka, która pozwala na przekazywanie ramek z powrotem na ten sam port, z którego przyszły. Jest to potrzebne w przypadku niektórych konfiguracji NAT i wirtualnych AP WiFi. Włącza się je poleceniem bridge link set dev veth0 hairpin on. Domyślnie hairpin mode jest wyłączone, co jest zgodne z zachowaniem fizycznego przełącznika.

Implementacja VETH w jądrze Linux znajduje się w pliku drivers/net/veth.c. Jest to stosunkowo prosty sterownik, który tworzy dwa urządzenia sieciowe i łączy je kolejką pierścieniową (ring buffer). Gdy ramka jest wysyłana na jedno urządzenie, sterownik bezpośrednio przekazuje ją do kolejki odbiorczej drugiego urządzenia, z pominięciem całego stosu sieciowego nadawcy.

Para VETH jest tworzona atomowo: polecenie ip link add veth0 type veth peer name veth1 tworzy oba interfejsy jednocześnie. Nie można utworzyć pojedynczego interfejsu VETH w izolacji - zawsze powstaje para. Po utworzeniu oba interfejsy znajdują się w domyślnej przestrzeni nazw (root namespace).

Po przeniesieniu jednego końca pary do innej przestrzeni nazw (poleceniem ip link set veth1 netns ns1), interfejs znika z przestrzeni root i staje się dostępny tylko w docelowej przestrzeni nazw. Para VETH działa wtedy jako wirtualny kabel łączący dwie odizolowane przestrzenie nazw.

VETH jest używany przez Docker do każdego kontenera w trybie bridge. Docker tworzy parę VETH, umieszcza jeden koniec w przestrzeni nazw kontenera (jako eth0), a drugi podłącza do mostka docker0. Cały ruch kontenera przechodzi przez te parę VETH, co zapewnia pełną izolację sieciową między kontenerami na poziomie L2.

Ograniczeniem VETH jest to, że nie można go użyć do połączenia dwóch interfejsów w tej samej przestrzeni nazw (nie miałoby to sensu, ponieważ interfejsy mogłyby komunikować się bezpośrednio). Ponadto VETH nie obsługuje multicastu w sposób efektywny - każda ramka multicast jest kopiowana do wszystkich par VETH w systemie.

Polecenie ip link add veth0 type veth peer name veth1 tworzy dwa nowe interfejsy sieciowe. W jądrze Linux proces ten obejmuje alokację dwóch struktur net_device, utworzenie kolejki transmisyjnej (tx_ring) dla każdego z nich oraz połączenie kolejek w pętle: tx_queue veth0 jest połączona z rx_queue veth1 i vice versa. Parametr peer name jest obowiązkowy - nie można utworzyć niepełnej pary.

Po utworzeniu oba interfejsy są w stanie DOWN i nie mają przypisanego adresu IP. Przed przeniesieniem do innej przestrzeni nazw można opcjonalnie ustawia adres MAC za pomocą ip link set dev veth0 address 00:11:22:33:44:55. Jeśli nie ustawimy adresu MAC, jądro wygeneruje go automatycznie na podstawie prefiksu producenta i losowej wartości.

Przeniesienie interfejsu do innej przestrzeni nazw poleceniem ip link set veth1 netns ns1 jest operacją niewidoczną dla użytkownika: interfejs znika z listy ip link show w przestrzeni root i pojawia się dopiero po wykonaniu ip netns exec ns1 ip link show. Po przeniesieniu interfejs traci swoją konfigurację IP i adres MAC (zostaje zachowany tylko typ).

Aby skonfigurować adresację IP w docelowej przestrzeni nazw, używamy ip netns exec ns1 ip addr add 192.168.100.1/24 dev veth1. Polecenie ip netns exec uruchamia dowolne polecenie w kontekcie wybranej przestrzeni nazw sieciowej. W tym przypadku konfigurujemy adres IP i podnosimy interfejs do stanu UP.

Po poprawnej konfiguracji obu końców pary VETH, komunikacja między przestrzeniami nazw (root i ns1) jest możliwa za pomocą standardowego ping. Ramki ICMP Echo Request wysłane z veth0 trafiają na veth1 przez wirtualne połączenie, a Echo Reply wraca tą samą drogą. Cały proces odbywa się bez udziału fizycznego sprzętu sieciowego.

Network namespace jest jednym z ośmiu typów przestrzeni nazw w Linux (obok mnt, pid, uts, ipc, user, cgroup, time). Zostało wprowadzone w jądrze 2.6.24 i jest podstawą izolacji sieciowej w kontenerach. Każda przestrzeń nazw sieciowa ma własną instancję protokołów TCP/IP, gniazd, interfejsów i reguł firewalla.

Główną zaletą netns jest możliwość tworzenia całkowicie odizolowanych środowisk sieciowych na jednym hoście fizycznym. Dwa procesy w różnych przestrzeniach nazw nie mogą komunikować się przez sieć, chyba że zostaną połączone przez VETH, mostek lub inny mechanizm. To właśnie ta izolacja jest fundamentem bezpieczeństwa w kontenerach.

Domyślnie wszystkie procesy w systemie znajdują się w root network namespace (domyślna przestrzeń nazw). Docker tworzy nową przestrzeń nazw dla każdego kontenera i umieszcza w niej proces kontenera. Dzięki temu kontener ma własny interfejs eth0, własną tablicę routingu i własne reguły iptables, co symuluje działanie niezależnego hosta.

Izolacja netns nie jest całkowita - pewne operacje sieciowe, takie jak multicast na poziomie jądra czy niektóre operacje na gniazdach raw, mogą mieć efekty globalne. Ponadto przestrzenie nazw nie izolują zasobów takich jak MTU interfejsów fizycznych czy konfiguracja mostka - te są globalne dla całego systemu.

Do zarządzania przestrzeniami nazw sieciowych służy narzędzie ip netns, które oferuje komendy add, del, exec, list, monitor i pids. Istnieje również możliwość zarządzania netns przez pliki w /var/run/netns/ (wiązanie przestrzeni nazw z deskryptorem pliku).

Polecenie ip netns add red tworzy nową przestrzeń nazw sieciową o nazwie red. Wewnętrznie tworzony jest plik w /var/run/netns/red, który służy jako punkt montowania dla przestrzeni nazw. Gdy proces jest przypisany do tej przestrzeni nazw, widzi tylko interfejsy i konfigurację sieciową należącą do red.

Po utworzeniu przestrzeń nazw zawiera tylko interfejs pętli zwrotnej (lo), który jest domyślnie w stanie DOWN. Aby sieć w przestrzeni nazw działała, należy podnieść interfejs lo: ip netns exec red ip link set lo up. Bez tego lokalne gniazda TCP/UDP w przestrzeni nazw nie będą działać.

Polecenie ip netns exec red <komenda> uruchamia podaną komendę w kontekcie przestrzeni nazw red. Jest to realizowane przez wywołanie systemowe setns(), które zmienia przestrzeń nazw bieżącego wątku na docelową. Po zakończeniu komendy wątek wraca do oryginalnej przestrzeni nazw.

Dla wygody można uruchomić powłokę bash w przestrzeni nazw: ip netns exec red bash. Wszystkie polecenia wykonane w tej powłoce będą działać w kontekcie przestrzeni red. Aby wyjść, należy użyć exit lub Ctrl+D. Jest to bardzo przydatne podczas debugowania i konfiguracji.

Usunięcie przestrzeni nazw poleceniem ip netns del red powoduje zamknięcie wszystkich gniazd i usunięcie wszystkich interfejsów wirtualnych w tej przestrzeni. Interfejsy fizyczne nie mogą być jednak usunięte - jeśli fizyczny interfejs został przeniesiony do netns, najpierw trzeba go przenieść z powrotem do root netns.

Bezpośrednie połączenie dwóch przestrzeni nazw przez parę VETH jest najprostszym sposobem na umożliwienie komunikacji między odizolowanymi stosami sieciowymi. Schemat ten symuluje połączenie dwóch hostów kablem krosowanym (crossover cable). Każda przestrzeń nazw ma własny interfejs z adresem IP w tej samej podsieci.

W przedstawionym przykładzie tworzymy dwie przestrzenie nazw: ns1 i ns2. Para VETH (veth1-veth2) jest tworzona w root netns, a następnie każdy koniec jest przenoszony do innej przestrzeni. Po przeniesieniu interfejsy znikają z root netns i stają się dostępne tylko w docelowych przestrzeniach.

Konfiguracja adresacji IP odbywa się już w docelowych przestrzeniach nazw. Adresy 10.0.0.1/24 i 10.0.0.2/24 należy do tej samej podsieci /24, co pozwala na bezpośrednią komunikację bez routingu. Po podniesieniu interfejsów do stanu UP (ip link set veth1 up), ping z ns1 do ns2 powinien działać.

Warto zauważyć, że w takiej konfiguracji nie ma żadnego urządzenia pośredniego (mostka, routera). Komunikacja odbywa się bezpośrednio między dwoma interfejsami VETH, które są ze sobą połączone wirtualnym kablem. Jest to odpowiednik sieci typu point-to-point.

Ograniczeniem tego rozwiązania jest skomplikowanie przy większej liczbie przestrzeni nazw. Połączenie trzech przestrzeni (mesh) wymagałoby trzech par VETH odpowiednio skonfigurowanych, co szybko staje się niepraktyczne. W takich przypadkach stosuje się mostek, który łączy wiele przestrzeni w jedną sieć L2.

łączenie przestrzeni nazw przez mostek to najczęściej stosowana topologia w środowiskach kontenerowych. Mostek działa jako wirtualny przełącznik L2, do którego podłączone są wszystkie przestrzenie nazw (kontenery). Umożliwia to komunikację między dowolną parą przestrzeni nazw w tej samej podsieci L2.

W przykładzie tworzymy mostek br0 oraz dwie przestrzenie nazw: ns1 i ns2. Dla każdej przestrzeni tworzymy dedykowaną parę VETH (veth1-veth1-br dla ns1, veth2-veth2-br dla ns2). Jeden koniec każdej pary (veth1-br, veth2-br) jest dodawany do mostka jako port członkowski, drugi koniec trafia do przestrzeni nazw.

Interfejsy po stronie mostka (veth1-br, veth2-br) muszą być podniesione (ip link set up), aby mostek mógł przetwarzać ramki. Interfejsy w przestrzeniach nazw również muszą być podniesione i skonfigurowane z adresami IP z tej samej podsieci, np. 192.168.1.1/24 dla ns1 i 192.168.1.2/24 dla ns2.

Po skonfigurowaniu mostek uczy się, który adres MAC jest dostępny na którym porcie. Gdy ns1 pinguje ns2, ramka ICMP Echo Request kieruje się z veth1 (ns1) do veth1-br (mostek), mostek sprawdza tablicę FDB dla docelowego MAC, znajduje wpis veth2-br i przekazuje ramkę na veth2-br, skąd trafia do veth2 (ns2).

Zaletą topologii z mostkiem jest skalowalność: dodanie trzeciej, czwartej czy setnej przestrzeni nazw wymaga tylko utworzenia nowej pary VETH i dodania jej końca do mostka. Nie ma potrzeby tworzenia połączen bezpośrednich między każdą parą przestrzeni. Jest to dokładnie ta sama koncepcja, której używa Docker z mostkiem docker0.

Weryfikacja izolacji sieciowej jest kluczowym elementem testowania poprawności konfiguracji. W pierwszym kroku testujemy łączność między przestrzeniami nazw: ping z ns1 do ns2 powinien działać, ponieważ obie przestrzenie są w tej samej podsieci i połączone przez mostek. Opcja -c 3 ogranicza liczbę pakietów do trzech.

Następnie sprawdzamy, że root network namespace (domyślna przestrzeń) nie ma dostępu do interfejsów w przestrzeniach ns1 i ns2. Polecenie ping 192.168.1.1 wykonane w root netns powinno zwrócić błąd Network is unreachable, ponieważ adres 192.168.1.1 jest skonfigurowany na interfejsie veth1, który znajduje się w przestrzeni ns1 i nie jest widoczny z root netns.

Podgląd tablicy routingu w przestrzeni nazw (ip netns exec ns1 ip route show) powinien pokazać trase lokalną do podsieci 192.168.1.0/24 przez interfejs veth1. W przestrzeni ns1 trasa domyślna może być nieobecna, chyba że została skonfigurowana ręcznie lub przez DHCP.

Tablica FDB mostka (bridge fdb show br br0) powinna zawierać dwa dynamiczne wpisy: adresy MAC interfejsów veth1 i veth2 (veth1-br i veth2-br w terminologii mostka). Jeśli ping z ns1 do ns2 został wykonany, mostek nauczył się adresu MAC veth2 (docelowego) i wyświetli go w tablicy.

Monitorowanie ruchu na moście za pomocą tcpdump pozwala na podgląd ramek przechodzących przez mostek w czasie rzeczywistym. Flaga -i br0 wskazuje interfejs mostka, -n wyłącza rozwiązywanie nazw, icmp filtruje tylko pakiety ICMP. Jest to doskonałe narzędzie do debugowania problemów z łącznością, ponieważ pokazuje, czy ramki docierają do mostka.

Głównym zastosowaniem VETH i netns w praktyce jest izolacja sieciowa kontenerów. Docker, jako najpopularniejsze narzędzie konteneryzacyjne, opiera się w całości na tych mechanizmach jądra Linux. Każdy kontener Docker to proces uruchomiony w zestawie przestrzeni nazw (mnt, pid, net, uts, ipc), z których sieciowa (netns) zapewnia izolację stosu TCP/IP.

Systemd-nspawn, alternatywa dla Dockera, również używa netns do izolacji. Polecenie systemd-nspawn --private-network tworzy nową przestrzeń nazw sieciową dla kontenera. Można również łączyć kontenery systemd-nspawn z siecią hosta przez pary VETH i mostek.

W testowaniu sieci, VETH i netns pozwalają na odtworzenie złożonych topologii na jednym hoście. Można stworzyć wirtualny router (z netns i włąconym ip_forward), kilka sieci L2 (mostki) i hosty w każdej sieci (netns z VETH do mostków). Całość działa w pamięci RAM, bez potrzeby fizycznych urządzeń sieciowych.

Sandboxing sieciowy jest ważny z punktu widzenia bezpieczeństwa. Aplikacja uruchomiona w izolowanej przestrzeni nazw nie ma dostępu do interfejsów sieciowych hosta ani do innych przestrzeni nazw. Nawet jeśli aplikacja zostanie skompromitowana, atakujący nie będzie mógł wykonać skanowania sieci ani przechwycić ruchu sieciowego hosta.

OpenStack Neutron, warstwa sieciowa platformy chmurowej OpenStack, wykorzystuje netns do izolacji sieci wirtualnych (tenant networks). Każda sieć wirtualna jest realizowana jako mostek Linux lub OVS w dedykowanej przestrzeni nazw, co zapewnia izolację między dzierżawcami chmury. VETH są używane do łączenia przestrzeni nazw z mostkami.

Docker używa wbudowanych mechanizmów jądra Linux (network namespaces, VETH, mostki, iptables) do realizacji swoich sterowników sieciowych. Każdy sterownik to inna kombinacja tych mechanizmów, dostosowana do konkretnego przypadku użycia. Zrozumienie tych sterowników jest kluczowe dla poprawnego projektowania architektury kontenerowej.

Wyboru sterownika dokonuje się przy uruchamianiu kontenera flagą --network lub --net. Na przykład docker run --network=host nginx uruchomi kontener w trybie host. Domyślnym sterownikiem jest bridge, który jest automatycznie wybierany, gdy nie podano flagi --network.

Sterownik none zapewnia najwyższy poziom izolacji sieciowej. Kontener ma własną przestrzeń nazw, ale zawiera ona tylko interfejs pętli (lo). Nie ma żadnego połączenia z siecią zewnętrzną ani z innymi kontenerami. Jest to używane dla kontenerów wykonujących zadania offline, takie jak przetwarzanie danych, obliczenia naukowe itp.

Sterownik host eliminuje izolację sieciową: kontener współdzieli przestrzeń nazw z hostem. Oznacza to, że kontener widzi wszystkie interfejsy hosta i może nasłuchiwać na dowolnych portach bez mapowania. Jest to najszybszy tryb (brak pośrednictwa mostka), ale najmniej bezpieczny, ponieważ kontener ma pełny dostęp do stosu sieciowego hosta.

Sterownik overlay jest używany w klastrach Docker Swarm i Kubernetes do tworzenia wirtualnych sieci rozciągających się na wiele hostów fizycznych. Wykorzystuje tunelowanie VXLAN, które enkapsuluje ramki L2 w pakiety UDP i przesyła przez sieć IP. Dzięki temu kontenery na różnych hostach mogą komunikować się tak, jakby były w tej samej sieci L2.

Tryb none jest odpowiednikiem utworzenia przestrzeni nazw sieciowej (ip netns add) i niełączenia jej z żadnym interfejsem poza pętlą zwrotną. Docker tworzy nową przestrzeń nazw, ale nie tworzy pary VETH, nie podłącza jej do mostka i nie przypisuje adresu IP. Kontener ma własną, całkowicie pustą przestrzeń sieciową.

W trybie none kontener nie ma dostępu do Internetu, ani nie może komunikować się z innymi kontenerami. Jest to użyteczne w scenariuszach bezpieczeństwa, gdzie aplikacja nie potrzebuje dostępu do sieci, a chcemy uniknąć ryzyka wycieku danych lub ataku z zewnątrz.

Przykładowe zastosowania: kontenery wykonujące obliczenia kryptograficzne, przetwarzanie wrażliwych danych, testy jednostkowe offline, kompilacja kodu w izolowanym środowisku, czy narzędzia do analizy bezpieczeństwa, które nie powinny komunikować się z siecią.

W trybie none interfejs lo jest domyślnie w stanie DOWN. Jeśli aplikacja w kontenerze wymaga komunikacji przez localhost, należy ręcznie podnieść interfejs lo za pomocą ip link set lo up lub dodać odpowiednią komendę do Dockerfile (RUN).

Mimo braku dostępu do sieci zewnętrznej, kontener w trybie none nadal może używać gniazd Unixowych do komunikacji z procesami na hoście (jeśli woluminy są współdzielone). Sieć TCP/IP jest całkowicie wyłączona, ale IPC (Inter-Process Communication) przez gniazda Unix może działać.

Tryb host jest implementowany przez pominicie tworzenia nowej przestrzeni nazw sieciowej dla kontenera. Zamiast tego Docker ustawia flage CLONE_NEWNET na false podczas wywołania systemowego clone() lub unshare(). W efekcie kontener działa w root network namespace, czyli tej samej przestrzeni nazw co host.

Główną zaletą trybu host jest wydajność. Ponieważ nie ma pośrednictwa mostka ani reguł iptables dla mapowania portów, ruch sieciowy trafia bezpośrednio do procesu w kontenerze bez żadnej dodatkowej translacji. Opóźnienia sieciowe są minimalne, a przepustowość maksymalna (ograniczona tylko przez fizyczny interfejs).

Wady trybu host to przede wszystkim brak izolacji. Dwa kontenery w trybie host nie mogą nasłuchiwać na tym samym porcie (konflikt portów). Ponadto kontener ma dostęp do wszystkich interfejsów sieciowych hosta, co może stanowić zagrożenie bezpieczeństwa w przypadku skompromitowania aplikacji.

Tryb host jest zalecany dla aplikacji wymagających maksymalnej wydajności sieciowej, takich jak serwery proxy o wysokim obciążeniu, serwery gier, aplikacje czasu rzeczywistego, czy narzędzia monitorujące sieć (np. tcpdump uruchomione w kontenerze).

W trybie host flagi -p (publish) i -P (publish-all) są ignorowane, ponieważ mapowanie portów nie ma sensu - aplikacja w kontenerze może bezpośrednio nasłuchiwać na porcie hosta. Docker wyświetli ostrzeżenie, jeśli spróbujemy użyć -p z --network host.

Podczas instalacji Docker demon tworzy mostek docker0 z adresem IP zwykle 172.17.0.1/16. Mostek ten służy jako brama domyślna dla wszystkich kontenerów w domyślnej sieci bridge. Docker konfiguruje również reguły iptables do masquerady, umożliwiające kontenerom dostęp do Internetu przez adres IP hosta.

Każdy kontener uruchomiony bez flagi --network otrzymuje nową przestrzeń nazw sieciową. Docker tworzy dla niego parę VETH: jeden koniec (nazwa losowa, np. vethła4b5c) jest podłączany do mostka docker0, drugi koniec (eth0) trafia do przestrzeni nazw kontenera. Kontener otrzymuje adres IP z puli mostka docker0 przez wbudowany serwer DHCP.

Kontenery w domyślnej sieci bridge mogą komunikować się ze sobą poprzez adresy IP, ale nie przez nazwy hostów (brak wbudowanego DNS). Aby kontenery mogły komunikować się przez nazwy, należy utworzyć zdefiniowaną przez użytkownika sieć bridge (user-defined bridge) z włąconym DNS.

Mostek docker0 zapewnia izolację na poziomie L2: kontenery widzą tylko własny interfejs eth0 i mostek. Nie widzą interfejsów fizycznych hosta ani innych kontenerów w innych sieciach. Ruch między kontenerami w tej samej sieci bridge odbywa się bezpośrednio przez mostek, bez translacji NAT.

Ograniczeniem domyślnego mostka jest to, że nie zapewnia on izolacji między kontenerami na poziomie portów - każdy kontener może próbować połączyć się z dowolnym portem innego kontenera w tej samej sieci. Dla większego bezpieczeństwa zaleca się używanie sieci zdefiniowanych przez użytkownika z opcją --internal.

Mostek docker0 ma domyślnie przypisany adres IP z zakresu 172.17.0.1/16. Adres ten staje się bramą domyślną dla wszystkich kontenerów w tej sieci. Gdy kontener wysyła pakiet do Internetu (np. 8.8.8.8), ramka trafia na mostek docker0, następnie jest przekazywana do stosu IP hosta, gdzie podlega routingowi.

Docker dodaje regułe MASQUERADE w łańcuchu POSTROUTING tabeli nat iptables. Reguła ta powoduje, że wszystkie pakiety wychodzące z podsieci 172.17.0.0/16 na zewnątrz (poza te podsieć) są poddawane translacji SNAT na adres IP interfejsu zewnętrznego hosta. Dzięki temu kontenery mogą łączyć się z Internetem, mimo że mają prywatne adresy IP.

Docker dynamicznie zarządza regułami iptables. Przy każdym uruchomieniu lub zatrzymaniu kontenera Docker aktualizuje reguły w łańcuchach DOCKER, DOCKER-ISOLATION i POSTROUTING, aby zapewnić poprawną izolację i routing. Ręczna modyfikacja tych reguł może być nadpisywana przez Docker.

Polecenie bridge link show master docker0 wyświetla wszystkie interfejsy VETH podłączone do mostka docker0. Każdy interfejs o nazwie vethXXXX to jeden koniec pary VETH prowadzącej do kontenera. Drugi koniec (eth0) znajduje się w przestrzeni nazw kontenera i nie jest widoczny z poziomu hosta.

Konfiguracja mostka docker0 może być modyfikowana przez plik /etc/docker/daemon.json, na przykład można zmieniać adresację IP (bip), MTU, mostek (bridge) na własny, czy wyłączyć iptables. Po zmianie konfiguracji należy zrestartować demon Dockera.

Komunikacja między kontenerami w tej samej sieci bridge odbywa się w następujący sposób: kontener A wysyła ramkę Ethernet z adresem MAC kontenera B jako docelowym. Ramka trafia przez parę VETH na mostek docker0. Mostek sprawdza tablicę FDB, znajduje port veth drugiego kontenera i przekazuje ramkę bezpośrednio, bez wychodzenia na zewnętrzny interfejs hosta.

Ponieważ mostek docker0 działa w przestrzeni jądra, a oba interfejsy VETH są podłączone do tego samego mostka, ramki są przekazywane w całości w pamięci RAM, bez konieczności przechodzenia przez fizyczny interfejs sieciowy. Opóźnienia są rzędu mikrosekund (zazwyczaj poniżej 0.2 ms).

Aby sprawdzić adres IP kontenera, używamy docker inspect <nazwa> | grep IPAddress. Adresy IP są przydzielane z puli mostka docker0 przez wbudowany serwer DHCP w demonie Dockera. Docker gwarantuje, że każdy kontener otrzymuje unikalny adres IP w ramach sieci.

W domyślnej sieci bridge kontenery nie mogą komunikować się przez nazwy hostów. Aby połączyć się z web1, kontener web2 musi znać adres IP web1. Docker oferuje wbudowany DNS w sieciach zdefiniowanych przez użytkownika, gdzie nazwa kontenera jest automatycznie rejestrowana i rozwiązywana.

Izolacja między kontenerami w domyślnej sieci bridge jest ograniczona: każdy kontener może połączyć się z dowolnym portem innego kontenera. Jeśli wymagana jest większa izolacja (np. zaufany serwer www i niezaufana baza danych), należy umieścić je w osobnych sieciach zdefiniowanych przez użytkownika i połączyć tylko niezbędne porty.

Polecenie docker network ls wyświetla wszystkie sieci dostępne w systemie Docker. Domyślnie Docker tworzy trzy sieci: bridge (mostek docker0), host (tryb współdzielenia stosu) i none (brak sieci). Każda sieć ma unikalne ID, nazwę, sterownik (driver) i zasięg (scope: local lub swarm).

Nową sieć tworzymy poleceniem docker network create. Możemy określić sterownik (--driver), podsieć (--subnet), bramę (--gateway), zakres adresów IP (--ip-range) oraz wiele innych opcji. Dla sterownika bridge można również włączyć izolację (--internal) i komunikację przez nazwy (--enable-ipv6).

Polecenie docker network inspect wyświetla szczegółowe informacje o sieci: konfigurację IPAM (pula adresów, brama), listę podłączonych kontenerów z ich adresami IP, opcje sterownika (np. com.docker.network.bridge.name - nazwa mostka w systemie Linux).

Kontener może być podłączony do jednej lub wielu sieci. Przy uruchamianiu kontenera flagą --network określamy główną sieć. Dodatkowe sieci można podłączyć dynamicznie poleceniem docker network connect mynet kontener. Odłączenie sieci odbywa się przez docker network disconnect.

Usunięcie sieci wykonuje się poleceniem docker network rm mynet. Przed usunięciem należy odłączyć wszystkie kontenery od tej sieci. Nie można usunąć domyślnych sieci (bridge, host, none) - Docker nie pozwala na to ze względów bezpieczeństwa.

Najważniejszą zaletą sieci zdefiniowanych przez użytkownika jest wbudowany DNS. Docker uruchamia wewnętrzny serwer DNS (127.0.0.11 w każdym kontenerze), który automatycznie rejestruje nazwy kontenerów w sieci. Gdy kontener A chce połączyć się z kontenerem B, wystarczy użyć nazwy B jako adresu, np. curl http://web:80.

W sieci user-defined bridge izolacja między kontenerami jest domyślnie wyłączona (flaga --icc=false), co oznacza, że kontenery nie mogą komunikować się ze sobą, chyba że zostanie to jawnie dozwolone. Jest to przeciwieństwo domyślnego mostka docker0, gdzie --icc=true (kontenery mogą się swobodnie komunikować).

Tworzenie sieci user-defined bridge odbywa się przez docker network create mynet. Docker tworzy nowy mostek Linux w systemie (nazwa zwykle zaczyna się od br-) i konfiguruje go z domyślną podsiecią. Można również określić własną podsieć flagą --subnet, co jest przydatne przy integracji z istniejącą infrastrukturą.

Kontenery w sieci user-defined mogą być dynamicznie odłączane i podłączane bez restartu. Jest to szczególnie przydatne w scenariuszach typu blue-green deployment, gdzie nowa wersja aplikacji jest uruchamiana obok starej, a następnie ruch jest przekierowywany przez zmianę sieci.

W sieci user-defined bridge można skonfigurować opcje takie jak --internal (brak dostępu do zewnętrznej sieci), --enable-ipv6 (włączenie IPv6), czy --ipam-driver (własny sterownik IPAM). Te opcje nie są dostępne dla domyślnego mostka docker0.

Kontener z wieloma sieciami ma w każdej sieci osobny interfejs eth0, eth1 itd., każdy z własnym adresem IP. Docker zarządza routingiem między sieciami: gdy kontener w sieci frontend chce komunikować się z kontenerem w sieci backend, pakiet jest kierowany przez stos IP kontenera, który musi mieć włącone ip_forward.

Wielosieciowość jest często używana w architekturze mikroserwisów. Na przykład serwer proxy (nginx) jest podłączony do sieci frontend (dostępnej z Internetu) i sieci backend (prywatnej, dostępnej tylko dla wewnętrznych usług). Kontenery backendu nie mają dostępu do sieci frontend, co zapewnia warstwe bezpieczeństwa.

Docker nie pozwala na podłączenie kontenera do wielu sieci, jeśli mają one nakładające się podsieci. Każda sieć musi mieć unikalną podsieć IP, ponieważ kontener nie może mieć dwóch interfejsów w tej samej podsieci (powodowałoby to problemy z routingiem i ARP).

Zarządzanie wieloma sieciami odbywa się przez docker network connect <sieć> <kontener>. Kontener może być podłączony do dodatkowej sieci w dowolnym momencie, bez restartu. Odłączenie sieci: docker network disconnect <sieć> <kontener>.

Wielosieciowość ma wpływ na routing pakietów w kontenerze. Jeśli kontener ma dwa interfejsy z trasami domyślnymi, tylko jedna trasa domyślna jest aktywna (ta z niżsą metryką). Ruch wychodzący na zewnątrz obu sieci może być nieprzewidywalny, dlatego zaleca się staranne projektowanie topologii i jawne definiowanie tras.

Domyślny mostek docker0 został zaprojektowany jako proste rozwiązanie do szybkiego uruchamiania kontenerów. Nie oferuje on zaawansowanych funkcji sieciowych, które są potrzebne w środowiskach produkcyjnych. Najwikszym ograniczeniem jest brak wbudowanego DNS - kontenery muszą znać adresy IP innych kontenerów, co jest niepraktyczne przy dynamicznym skalowaniu.

Izolacja między kontenerami w docker0 jest minimalna. Flaga --icc (inter-container communication) nie może być zmieniona dla domyślnego mostka bez restartu demona Dockera. Domyślnie --icc=true, co oznacza, że każdy kontener może połączyć się z dowolnym portem innego kontenera, co stanowi potencjalne ryzyko bezpieczeństwa.

Brak możliwości dynamicznego dołączania kontenera do sieci oznacza, że aby zmienić przynależność sieciową kontenera, trzeba go zatrzymać i uruchomić ponownie z odpowiednią flagą --network. W środowiskach produkcyjnych, gdzie wymagana jest ciągłość działania, jest to niedopuszczalne.

Globalna konfiguracja mostka docker0 oznacza, że zmiana parametrów (np. podsieci, MTU) wpływa na wszystkie kontenery w tej sieci. Jeśli różne aplikacje wymagają różnych konfiguracji sieciowych, nie ma możliwości ich rozdzielenia w ramach jednego mostka docker0.

Z tych powodów Docker zaleca używanie sieci zdefiniowanych przez użytkownika (user-defined bridge) dla wszystkich środowisk produkcyjnych. Sieci te oferują DNS, lepszą izolację, dynamiczne zarządzanie i pełną kontrolę nad konfiguracją adresacji IP.

Mechanizm -p jest jednym z najczęściej używanych, a jednocześnie najmniej rozumianych aspektów sieci Docker. Wielu użytkowników myli, że Docker po prostu przekierowuje ruch z portu hosta na port kontenera, ale w rzeczywistości dzieje się o wiele więcej: Docker tworzy reguły DNAT w iptables, które modyfikują docelowy adres IP i port w pakiecie.

Podstawowa składnia to -p <port_hosta>:<port_kontenera>. Docker nasłuchuje na porcie hosta (domyślnie na wszystkich interfejsach 0.0.0.0) i przekierowuje ruch do odpowiedniego kontenera. Port hosta może być inny niż port kontenera (np. -p 8080:80 mapuje port 8080 hosta na port 80 kontenera).

Opcjonalnie można ograniczyć nasłuchiwanie do konkretnego adresu IP hosta: -p 127.0.0.1:8080:80 sprawia, że port jest dostępny tylko z localhosta, a nie z sieci zewnętrznej. Jest to przydatne dla usług administracyjnych, które nie powinny być publicznie dostępne.

Domyślnie -p tworzy reguły dla protokołu TCP. Aby opublikować port UDP, należy dodać /udp: -p 8080:80/udp. Można również publikować zarówno TCP, jak i UDP, podając flage wielokrotnie lub używając zakresu portów: -p 8000-8010:8000-8010.

W przypadku użycia --network host flaga -p jest ignorowana, ponieważ kontener ma bezpośredni dostęp do interfejsów hosta i nie potrzebuje mapowania portów. Docker wyświetli ostrzeżenie, ale kontener uruchomi się bez opublikowanych portów.

DNAT (Destination NAT) to mechanizm iptables, który modyfikuje docelowy adres IP i/lub port w pakiecie. Gdy pakiet przychodzi na interfejs hosta z zewnątrz, jego docelowy adres IP to adres hosta (np. 192.168.1.10), a docelowy port to opublikowany port (np. 8080). DNAT zmienia te wartości na adres IP kontenera (np. 172.17.0.2) i port wewnętrzny (np. 80).

Docker dodaje reguły DNAT w łańcuchu PREROUTING tabeli nat, ale nie bezpośrednio. Zamiast tego tworzy łańcuch DOCKER w tabeli nat i dodaje do niego reguły DNAT. W PREROUTING znajduje się reguła odsyłająca do DOCKER: -j DOCKER. Dzięki temu Docker może zarządzać swoimi regułami niezależnie od reguł użytkownika.

Kolejność reguł w iptables ma znaczenie. Jeśli użytkownik doda regułę PREROUTING przed regułami Dockera, może ona przechwycić ruch przeznaczony dla kontenera. Dlatego ważne jest, aby reguły Dockera były pierwsze w łańcuchu PREROUTING, co Docker zapewnia poprzez dodawanie swoich reguł na początku łańcucha.

Dodatkowo Docker dodaje reguły ACCEPT w łańcuchu FORWARD, aby umożliwia forwarding pakietów z zewnętrznych interfejsów do mostka docker0. Bez tych reguł domyślna polityka DROP w łańcuchu FORWARD zablokowałaby ruch przychodzący z zewnątrz do kontenerów.

Wszystkie te reguły są widoczne po wykonaniu iptables-save lub iptables -t nat -L -n --line-numbers. Zrozumienie struktury tych reguł jest kluczowe dla debugowania problemów z dostępem do usług w kontenerach.

Analiza pierwszej reguły: jest to reguła DNAT w łańcuchu DOCKER tabeli nat. Mówi ona: dla pakietów TCP przychodzących na interfejs inny niż docker0 (czyli z zewnątrz), których docelowy port to 8080, zmien docelowy adres IP na 172.17.0.2, a docelowy port na 80. Warunek ADDRTYPE match dst-type LOCAL zapewnia, że reguła działa tylko dla pakietów adresowanych do lokalnego hosta.

Druga reguła to ACCEPT w łańcuchu DOCKER tabeli filter. Pozwala ona na forwarding pakietów TCP z dowolnego interfejsu (poza docker0) na interfejs docker0 z docelowym adresem IP kontenera 172.17.0.2 na porcie 80. Bez tej reguły domyślna polityka FORWARD (DROP) zablokowałaby ruch.

Po DNAT pakiet ma zmodyfikowany docelowy adres IP. Gdy pakiet dociera do mostka docker0, mostek sprawdza tablicę FDB i przekazuje ramkę na odpowiedni interfejs VETH prowadzący do kontenera. W kontenerze stos IP odbiera pakiet z adresem docelowym 172.17.0.2:80, co odpowiada nasłuchującemu procesowi nginx.

W odpowiedzi kontener wysyła pakiet z adresem źródłowym 172.17.0.2:80. Ten pakiet przechodzi przez mostek docker0 i trafia do stosu IP hosta. W łańcuchu POSTROUTING zachodzi masquerada (SNAT), która zmienić źródłowy adres na adres interfejsu zewnętrznego hosta, aby odpowiedź mogła wrócić do klienta.

Dzięki temu cały mechanizm jest transparentny dla użytkownika: klient łączy się z hostem:8080, a odpowiedź wraca do klienta, bez wiedzy o tym, że wewnątrz działa kontener z przekierowaniem portów.

Demon Dockera uruchamia wewnętrzny komponent o nazwie Docker Proxy (docker-proxy), który jest odpowiedzialny za implementacje publikowania portów w starszych wersjach. W nowszych wersjach (od Dockera 20.10) domyślnie używane są reguły iptables zamiast dockera-proxy, ale opcja --userland-proxy jest nadal dostępna dla zachowania wstecznej kompatybilności.

Docker używa mechanizmu Netlink do monitorowania zdarzeń w systemie. Gdy kontener jest uruchamiany, Docker wywołuje funkcje jądra do tworzenia interfejsów VETH, mostków i reguł iptables. Operacje te są wykonywane atomowo: jeśli która z nich się nie powiedzie, cała operacja uruchomienia kontenera jest przerywana.

Wszystkie reguły iptables są przechowywane w łańcuchach DOCKER (tabela nat i filter) oraz DOCKER-USER (tabela filter). Docker nigdy nie modyfikuje reguł w łańcuchu DOCKER-USER - jest on przeznaczony dla własnych reguł administratora systemu, które są sprawdzane przed regułami Dockera.

Jeśli chcemy całkowicie wyłączyć zarządzanie iptables przez Docker, możemy ustawia w pliku /etc/docker/daemon.json opcje "iptables": false. Wówczas Docker nie będzie tworzyć żadnych reguł, a my będziemy musieli ręcznie skonfigurować iptables dla publikowania portów i masquerady.

Od Dockera 20.10 dostępna jest również opcja "ip6tables": true do zarządzania regułami IPv6. Docker może zarządzać zarówno iptables (IPv4), jak i ip6tables (IPv6) jednocześnie, z zachowaniem symetrycznych reguł dla obu protokołów.

Polecenie iptables -t nat -L DOCKER -n --line-numbers wyświetla reguły DNAT w łańcuchu DOCKER tabeli nat. Opcja -n wyłącza rozwiązywanie nazw (szybsze wyświetlanie), a --line-numbers pokazuje numery linii, co ułatwia późniejsze modyfikowanie reguł. W łańcuchu tym znajdują się reguły dla każdego opublikowanego portu.

Polecenie iptables -L DOCKER -n --line-numbers wyświetla reguły ACCEPT w łańcuchu DOCKER tabeli filter. Te reguły zezwalają na forwarding pakietów z zewnętrznych interfejsów do kontenerów. Dla każdego kontenera z opublikowanymi portami istnieje osobna reguła ACCEPT.

Polecenie iptables -t nat -L POSTROUTING -n wyświetla reguły masquerady, które są odpowiedzialne za SNAT ruchu wychodzącego z kontenerów. Zazwyczaj jest jedna reguła MASQUERADE dla podsieci mostka docker0 (172.17.0.0/16) oraz opcjonalne reguły dla sieci user-defined.

Polecenie iptables-save wyświetla całą konfigurację iptables w formacie, który można załadować za pomocą iptables-restore. Jest to najdokładniejszy sposób na podgląd wszystkich reguł, łącznie z tymi, które nie są widoczne w poszczególnych łańcuchach (np. reguły w INPUT, FORWARD, OUTPUT).

Dla IPv6 używamy analogicznych polecen: ip6tables -t nat -L DOCKER -n. Docker tworzy symetryczne reguły dla IPv6, jeśli w konfiguracji włączono ip6tables i w systemie dostępne jest IPv6.

W tabeli nat łańcuch DOCKER jest wywoływany z PREROUTING i OUTPUT. Reguła w PREROUTING odsyła pakiety do łańcucha DOCKER przed podjeciem decyzji routingu, co jest kluczowe dla DNAT - musimy zmienić docelowy adres IP przed routingiem, aby pakiet został przekazany do kontenera, a nie do lokalnego procesu hosta.

W tabeli filter łańcuch DOCKER jest wywoływany z FORWARD. Docker dodaje reguły ACCEPT, które zezwalają na forwarding pakietów z zewnętrznych interfejsów do kontenerów. Domyślna polityka FORWARD to zazwyczaj DROP (w systemach z włąconym firewallem), wiec bez tych reguł ruch do kontenerów byłby blokowany.

System izolacji DOCKER-ISOLATION zapobiega komunikacji między kontenerami w różnych sieciach. Jest to dodatkowy łańcuch wywoływany z FORWARD, który sprawdza, czy pakiet nie próbuje przejść z jednej sieci Docker do drugiej bez odpowiedniego zezwolenia.

W łańcuchu DOCKER-USER administrator może dodawać własne reguły, które będą sprawdzane przed regułami Dockera. Na przykład, jeżeli chcemy zablokować cały ruch przychodzący do kontenerów z wyjątkiem konkretnych adresów IP, dodajemy odpowiednie reguły DROP na początku łańcucha DOCKER-USER.

Kolejność reguł w łańcuchu DOCKER (tabela nat) jest zgodna z kolejnością uruchamiania kontenerów. Każda reguła DNAT ma warunek, który sprawdza docelowy port TCP/UDP oraz interfejs przychodzący. Reguły są sprawdzane od góry do dołu, wiec pierwsze dopasowanie wygrywa.

Gdy określamy adres IP w flagach -p, Docker tworzy regułę DNAT z dodatkowym warunkiem na docelowy adres IP. W przykładzie -p 127.0.0.1:8080:80 reguła DNAT będzie pasować tylko do pakietów, których docelowym adresem IP jest 127.0.0.1 (localhost). Oznacza to, że tylko procesy na hoście mogą łączyć się z tym portem, a ruch z zewnętrznych interfejsów sieciowych zostanie odrzucony.

Jeśli określimy adres IP interfejsu wewnętrznego (np. 10.0.0.1), usługa będzie dostępna tylko z sieci wewnętrznej, ale nie z Internetu. Jest to często używane w architekturze z wieloma interfejsami: jeden interfejs jest publiczny, a drugi wewnętrzny. Usługi backendowe publikujemy tylko na wewnętrznym interfejsie.

W regule DNAT warunek na docelowy adres IP pojawia się przed warunkiem na port. Polecenie iptables -t nat -L DOCKER -n pokaże regułe z adresem IP w kolumnie destination. Jeśli adres nie jest określony, kolumna destination zawiera 0.0.0.0/0 (dopasowuje wszystkie adresy).

Docker nie tworzy automatycznie reguł w łańcuchu INPUT, co oznacza, że niezależnie od ograniczenia IP w DNAT, lokalne procesy na hoście mogą łączyć się z publikowanym portem przez localhost. Aby ograniczyć również dostęp lokalny, należy dodać własne reguły do łańcucha DOCKER-USER lub skonfigurować firewall systemowy.

W praktyce ograniczenie do konkretnego adresu IP jest używane dla usług takich jak serwery baz danych (Redis, PostgreSQL), interfejsy administracyjne (phpMyAdmin, Adminer) czy serwery metryk (Prometheus, Grafana), które nie powinny być wystawione na publiczny Internet.

Flaga -p (lub --publish) wymaga jawnego określenia mapowania portów. Składnia to -p hostPort:containerPort z opcjonalnym adresem IP hosta i protokołem. Użytkownik ma pełną kontrolę nad tym, które porty są publikowane i na jakich portach hosta są dostępne. Jest to zalecane w środowiskach produkcyjnych.

Flaga -P (lub --publish-all) publikuje automatycznie wszystkie porty zadeklarowane w Dockerfile instrukcją EXPOSE. Dla każdego portu z EXPOSE Docker przydziela losowy port z zakresu 32768-60999 na interfejsie 0.0.0.0 hosta. Mapowanie można sprawdzić poleceniem docker port <kontener>.

-P jest przydatny w środowiskach deweloperskich, gdzie wiele kontenerów jest uruchamianych na jednym hoście i chcemy uniknąć konfliktów portów. Każdy kontener otrzymuje unikalne porty zewnętrzne niezależnie od wewnętrznych portów aplikacji.

W przypadku użycia -P, Docker tworzy reguły DNAT analogicznie jak dla -p, ale z losowym portem hosta. Reguły iptables będą zawierać DNAT z portem hosta przydzielonym losowo. Jest to mniej przewidywalne, ale wygodne podczas szybkiego testowania.

W środowiskach produkcyjnych zaleca się używanie -p z jawnie określonymi portami, co ułatwia zarządzanie regułami firewalla, monitorowanie ruchu i konfigurację równoważenia obciążenia. -P jest używane głównie w developmentcie i podczas demonstracji.

Laboratorium jest zaprojektowane tak, aby uczestnik mógł krok po kroku odtworzyć identyczną konfigurację sieciową, jaką Docker tworzy automatycznie dla kontenera w trybie bridge. Zrozumienie każdego kroku pozwoli na wiadome debugowanie problemów sieciowych w środowisku kontenerowym.

Uczestnik będzie pracować na systemie Linux z zainstalowanymi narzędziami iproute2 (ip, bridge), iptables i opcjonalnie tcpdump. Wszystkie polecenia wymagają uprawnień root (sudo). Środowisko może być maszyną wirtualną, kontenerem uprzywilejowanym lub fizycznym hostem Linux.

Topologia laboratorium będzie składać się z dwóch przestrzeni nazw (ns1, ns2) połączonych przez mostek br0. Każda przestrzeń będzie miała interfejs VETH z adresem IP w podsieci 192.168.100.0/24. Mostek otrzyma adres 192.168.100.1/24, symulując bramę docker0.

Po skonfigurowaniu podstawowej łączności, dodamy reguły iptables DNAT, aby opublikować port z jednej przestrzeni nazw na porcie hosta, tak jak robi to Docker z flagą -p. Na koniec sprawdzimy poprawność działania za pomocą narzędzi diagnostycznych.

Wszystkie polecenia będą wykonywane w terminalu z uprawnieniami root. Uczestnik powinien mieć otwarty edytor tekstu do notowania wyników i ewentualnych błędów. Po zakończeniu laboratorium wszystkie zasoby zostaną posprzątane (usunięte przestrzenie nazw, mostek i pary VETH).

W pierwszym kroku tworzymy dwie przestrzenie nazw sieciowych: ns1 i ns2. Polecenie sudo ip netns add ns1 tworzy nową przestrzeń nazw o nazwie ns1. W systemie pojawia się plik /var/run/netns/ns1, który jest punktem montowania dla przestrzeni nazw. Każda przestrzeń początkowo zawiera tylko interfejs pętli zwrotnej (lo) w stanie DOWN.

Następnie tworzymy mostek sieciowy br0. Mostek ten będzie pełnił role wirtualnego przełącznika L2, do którego podłączymy obie przestrzenie nazw. Adres IP 192.168.100.1/24 przypisany do br0 będzie bramą domyślną dla przestrzeni nazw, analogicznie jak docker0 z adresem 172.17.0.1/16.

Stan mostka można sprawdzić poleceniem ip link show br0. Powinien być w stanie UP (flaga UP w wynikach). Adres IP mostka jest widoczny po ip addr show br0. Mostek jest gotowy do przyjmowania portów członkowskich.

W tej chwili przestrzenie nazw nie mają jeszcze żadnego interfejsu poza lo. Próba pingowania czegokolwiek z ns1 zakończy się błędem, ponieważ nie ma trasy do sieci zewnętrznej. Interfejs lo w ns1 można podnieść dla testów lokalnych: sudo ip netns exec ns1 ip link set lo up.

Lista wszystkich przestrzeni nazw jest dostępna przez sudo ip netns list. W środowisku laboratoryjnym mogą istnieć inne przestrzenie nazw utworzone przez Docker (jeżeli jest zainstalowany). Nasze przestrzenie ns1 i ns2 powinny być widoczne.

W drugim kroku tworzymy pary VETH. Dla każdej przestrzeni nazw potrzebujemy osobnej pary. Para veth1-veth1-br jest przeznaczona dla ns1: veth1 trafi do przestrzeni ns1, a veth1-br zostanie podłączony do mostka br0. Analogicznie veth2-veth2-br dla ns2.

Polecenie sudo ip link add veth1 type veth peer name veth1-br tworzy dwa interfejsy. Po utworzeniu oba znajdują się w root network namespace. Następnie veth1-br jest dodawany do mostka za pomocą ip link set veth1-br master br0, a veth1 jest przenoszony do ns1 za pomocą ip link set veth1 netns ns1.

Ważne jest, aby przed przeniesieniem do przestrzeni nazw nie konfigurować adresów IP na interfejsie, ponieważ zostaną one utracone podczas przenoszenia. Konfiguracja adresacji powinna odbywać się już w docelowej przestrzeni nazw.

Interfejsy po stronie mostka (veth1-br, veth2-br) muszą być podniesione do stanu UP, ale nie przypisujemy im adresów IP - działają wyłącznie na poziomie L2. Ich zadaniem jest przekazywanie ramek między mostkiem a parą VETH.

Stan interfejsów można sprawdzić poleceniem ip link show master br0, które pokaże wszystkie interfejsy podłączone do mostka. Po podniesieniu interfejsów mostek powinien je widzieć jako porty członkowskie w stanie UP.

Trzeci krok to konfiguracja adresów IP w przestrzeniach nazw. Używamy polecenia sudo ip netns exec ns1 ... do wykonania polecen w kontekcie przestrzeni nazw ns1. Interfejsowi veth1 w ns1 przypisujemy adres 192.168.100.2/24, a veth2 w ns2 adres 192.168.100.3/24.

Po przypisaniu adresu należy podnieść interfejs do stanu UP: ip link set veth1 up. Bez tego interfejs nie będzie przetwarzał pakietów. Dodatkowo warto podnieść interfejs lo (petla zwrotna), co umożliwi komunikację wewnętrzną w przestrzeni nazw (np. localhost).

Sprawdzenie poprawności konfiguracji: ip netns exec ns1 ip addr show veth1 powinno pokazać adres 192.168.100.2/24 na interfejsie veth1 w stanie UP. Analogicznie dla ns2. Mostek br0 ma adres 192.168.100.1/24, który będzie bramą domyślną dla obu przestrzeni.

W tym momencie tablica routingu w ns1 (ip netns exec ns1 ip route show) powinna zawierać trase do podsieci 192.168.100.0/24 przez interfejs veth1. Nie ma jeszcze trasy domyślnej - dodamy ją, jeśli przestrzenie mają mieć dostęp do Internetu przez mostek.

Adresacja IP w laboratorium (192.168.100.0/24) jest celowo inna niż domyślna podsieć Docker (172.17.0.0/16), aby uniknąć konfliktów, jeśli Docker jest zainstalowany na tym samym hoście. W środowisku produkcyjnym można użyć dowolnej prywatnej podsieci.

Po skonfigurowaniu adresacji IP już łączność między przestrzeniami nazw powinna działać. Ping z ns1 (192.168.100.2) do ns2 (192.168.100.3) powinien zwrócić odpowiedzi z czasem rzędu dziesiętnych części milisekundy, co potwierdza, że ramki przechodzą przez mostek w pamięci RAM bez opóźnień sieci fizycznej.

Mostek pełni role bramy: ping z ns1 do adresu mostka (192.168.100.1) również powinien działać. Oznacza to, że mostek jest osiągalny jako brama domyślna. Jeśli skonfigurujemy trase domyślną w ns1 (ip route add default via 192.168.100.1), przestrzeń będzie mogła łączyć się z siecią zewnętrzną.

Izolacja polega na tym, że root network namespace nie ma bezpośredniego dostępu do interfejsów w ns1 i ns2. Ping z hosta do 192.168.100.2 powinien zwrócić błąd Network is unreachable, ponieważ adres 192.168.100.2 znajduje się w przestrzeni ns1 i nie jest widoczny z root netns.

Widoczność mostka br0 z root netns jest możliwa, ponieważ mostek znajduje się w root netns. Można pingować adres mostka (192.168.100.1) z hosta, ale nie adresy interfejsów veth w przestrzeniach nazw. To właśnie zapewnia izolację sieciową kontenerów.

Do monitorowania ruchu na moście używamy sudo tcpdump -i br0 -n icmp. Powinien pokazać pakiety ICMP Echo Request i Echo Reply przechodzące przez mostek podczas pingowania między przestrzeniami. Jest to doskonałe narzędzie do weryfikacji, czy mostek prawidłowo przekazuje ramki.

W pitym kroku symulujemy mechanizm -p z Dockera: publikujemy port 80 z przestrzeni ns1 na porcie 8080 hosta. W kontenerze ns1 uruchamiamy prosty serwer HTTP (może to być python -m http.server, nginx, lub netcat). Następnie ręcznie dodajemy reguły iptables, które Docker dodałby automatycznie.

Reguła DNAT: iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 192.168.100.2:80. Mówi ona: wszystkie pakiety TCP przychodzące na port 8080 hosta mają mieć zmieniony docelowy adres IP na 192.168.100.2 i docelowy port na 80. To dokładnie to samo, co robi Docker z -p 8080:80.

Reguła FORWARD: iptables -A FORWARD -p tcp -d 192.168.100.2 --dport 80 -j ACCEPT. Zezwala na forwarding pakietów do kontenera. Domyślna polityka FORWARD to DROP, więc bez tej reguły pakiety po DNAT zostałyby odrzucone przy próbie przekazania do interfejsu mostka.

Po dodaniu reguł, curl http://localhost:8080 z hosta powinien pokazać odpowiedź z serwera HTTP uruchomionego w ns1. Jest to analogiczne do docker run -p 8080:80 nginx, ale wykonane ręcznie, krok po kroku.

Po zakończeniu testu usuwamy reguły: iptables -t nat -D PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 192.168.100.2:80 i iptables -D FORWARD -p tcp -d 192.168.100.2 --dport 80 -j ACCEPT. Kończymy również proces serwera w ns1.

Spanning Tree Protocol (STP) zgodny z IEEE 802.1D jest zaimplementowany w mostku Linux i może być włącony dla każdego mostka niezależnie. STP zapobiega powstawaniu pętli w sieci Ethernet poprzez blokowanie nadmiarowych portów. Algorytm STP wybiera jeden mostek główny (root bridge) i blokuje porty, które tworzyłyby cykl.

W mostku Linux STP jest domyślnie wyłączony, ponieważ w typowych konfiguracjach wirtualizacyjnych (mostek z kontenerami) topologia jest drzewiasta. Jednakże, gdy mostek Linux jest połączony z fizycznym przełącznikiem obsługującym STP, a istnieją redundantne połączenia, włączenie STP jest niezbędne.

Objawy pętli w mostku: wysokie obciążenie CPU (kernel processing), broadcast storm (ramki broadcast rozchodzą się w nieskończoność), MAC flapping (ten sam adres MAC pojawia się na różnych portach). W skrajnych przypadkach sieć może stać się niedostępna.

Polecenie bridge link show pokazuje stan STP dla każdego portu mostka. W kolumnie stp_state wartość 0 oznacza STP wyłączone, 1 - STP włącone. Dodatkowo bridge -d link show pokazuje szczegółowe informacje o stanie każdego portu: role (Root, Designated, Alternate, Backup) i stan (Forwarding, Listening, Learning, Blocking, Disabled).

Czas konwergencji STP w mostku Linux wynosi domyślnie 30 sekund (MAX_AGE + FORWARD_DELAY), co może być zbyt długie w środowiskach wirtualizacyjnych. Można go skrócić przez zmianę parametrów mostka: bridge link set dev veth1-br max_age 6 i bridge link set dev veth1-br forward_delay 4.

Najczęstszym błędem przy pracy z VETH jest zapomnienie o podniesieniu interfejsu do stanu UP. Po utworzeniu pary i przeniesieniu do przestrzeni nazw, interfejs jest w stanie DOWN. Bez jawnego wywołania ip link set veth1 up (w kontekcie przestrzeni nazw), interfejs nie będzie przetwarzał pakietów, a ping zwróci błąd Network is unreachable.

Drugim częstym błędem jest przypisanie adresu IP do interfejsu przed przeniesieniem go do docelowej przestrzeni nazw. Adres IP jest tracony podczas przenoszenia, ponieważ konfiguracja interfejsu jest resetowana. Należy najpierw przenieść interfejs, a następnie skonfigurować adresację już w docelowej przestrzeni.

Problemy z mostkiem: interfejs veth1-br musi być dodany do mostka za pomocą ip link set veth1-br master br0, a następnie podniesiony. Bez tego mostek nie będzie widział interfejsu jako portu członkowskiego, co można sprawdzić poleceniem ip link show master br0.

Pomylenie interfejsów VETH między przestrzeniami nazw prowadzi do trudnych do zdiagnozowania problemów. Zaleca się stosowanie czytelnych nazw: veth1 dla ns1, veth1-br dla strony mostka ns1, veth2 dla ns2, veth2-br dla strony mostka ns2. Nazwy powinny jednoznacznie wskazywać, która przestrzeń do której pary należy.

Do debugowania problemów z VETH używamy: ip netns exec ns1 ip link show (sprawdzenie interfejsów w przestrzeni), ip link show master br0 (sprawdzenie portów mostka), bridge fdb show br br0 (sprawdzenie tablicy FDB), tcpdump -i veth1-br (nasłuch na interfejsie mostka).

Problem bind: address already in use występuje, gdy port hosta, który chcemy opublikować, jest już zajęty przez inny proces (np. inny kontener, serwer WWW na hoście, lub wcześniejszy kontener, który nie został poprawnie zatrzymany). Rozwiązaniem jest znalezienie procesu zajmującego port (netstat -tulpn, lsof -i) i zatrzymanie go, lub użycie innego portu hosta.

Drugim częstym problemem jest nieprawidłowa kolejność reguł w łańcuchu PREROUTING. Jeśli inna reguła (np. REDIRECT, DNAT ustawiona ręcznie) znajduje się przed regułami Dockera, może przechwycić ruch przeznaczony dla kontenera. W takim przypadku reguła Dockera nigdy nie zostanie dopasowana, a ruch nie trafi do kontenera.

Docker dodaje swoje reguły na początku łańcucha PREROUTING, ale tylko podczas restartu demona (dockerd). Reguły dodane ręcznie przez administratora po restarcie Dockera mogą znaleźć się przed regułami Dockera, blokując je. Rozwiązaniem jest dodawanie własnych reguł do łańcucha DOCKER-USER, który jest sprawdzany przed DOCKER.

Problem z masqueradą: kontener może łączyć się z Internetem, ale odpowiedzi nie wracają. Jest to zazwyczaj spowodowane brakiem reguły MASQUERADE lub nieprawidłową konfiguracją routingu na hoście. Sprawdzenie: iptables -t nat -L POSTROUTING -n -v powinno pokazać regułę MASQUERADE dla podsieci Docker.

Problem z izolację: kontenery w różnych sieciach mogą komunikować się między sobą, co stanowi zagrożenie bezpieczeństwa. Docker dodaje reguły w łańcuchu DOCKER-ISOLATION, które blokują taką komunikację. Jeśli reguły te są nieprawidłowe lub brakuje ich, izolacja nie działa. Sprawdzenie: iptables -L DOCKER-ISOLATION -n -v.

tcpdump to podstawowe narzędzie do przechwytywania i analizy ruchu sieciowego. Przy debugowaniu mostka używamy tcpdump -i br0 -n do podglądu wszystkich ramek przechodzących przez mostek. Flaga -n wyłącza rozwiązywanie nazw DNS, co przyspiesza wyświetlanie. Można filtrować po protokole (icmp, tcp, udp), adresie IP (host 192.168.100.2) lub porcie (port 80).

iproute2 to zestaw narzędzi do konfiguracji sieci. Polecenia ip link, ip addr, ip route, ip netns są niezastąpione przy diagnostyce. Szczególnie przydatne: ip netns exec ns1 ip addr show (sprawdzenie interfejsów w przestrzeni), ip route show (tablica routingu), ip link show master br0 (porty mostka).

bridge to narzędzie do zarządzania mostkiem. Polecenie bridge fdb show wyświetla tablicę FDB, co pozwala sprawdzić, czy mostek nauczył się adresów MAC. bridge link show pokazuje stan portów, łącznie z STP. bridge monitor pokazuje zmiany w czasie rzeczywistym.

nsenter pozwala na wejście do przestrzeni nazw dowolnego procesu w systemie. Jest to szczególnie przydatne, gdy chcemy zbadaa konfigurację sieciową działającego kontenera Docker bez używania docker exec. Składnia: nsenter -t PID -n ip addr show, gdzie PID to numer procesu kontenera (można go znaleźć przez docker inspect).

docker inspect wyświetla szczegółową konfigurację kontenera w formacie JSON. Można je filtrować przez grep lub jq: docker inspect web1 | jq '.[].NetworkSettings.IPAddress'. Zawiera informacje o adresie IP, sieciach, portach, dNS, gateway, mostku i regułach iptables.

Wirtualizacja sieci w Linux opiera się na trzech filarach: bridge (przełącznik L2), VETH (kabel wirtualny) i network namespaces (izolacja). Zrozumienie tych trzech mechanizmów pozwala na wiadome zarządzanie siecią kontenerową bez traktowania Dockera jako czarnej skrzynki.

Mostek Linux jest implementacją przełącznika L2 w jądrze, która potrafi uczyć się adresów MAC i przekazywać ramki na odpowiednie porty. Może obsługiwać STP do zapobiegania pętlom i filtrowanie VLAN do izolacji ruchu. Jest używany zarówno przez KVM/QEMU, jak i Docker.

Pary VETH są wirtualnymi kablami, które łączą dwie przestrzenie nazw. Jeden koniec pary jest w kontenerze (eth0), drugi w mostku hosta (vethXXXXX). Ramka wysłana na jednym koncu pojawia się na drugim, co umożliwia komunikację między kontenerem a hostem.

Network namespaces zapewniają izolację stosu sieciowego. Każdy kontener Docker działa we własnej przestrzeni nazw, co oznacza, że ma własne interfejsy, tablicę routingu, reguły iptables i gniazda. Dwa kontenery nie mogą komunikować się bezpośrednio, chyba że zostaną połączone przez mostek lub sieć overlay.

Docker automatyzuje tworzenie tych mechanizmów: demon Dockera tworzy mostek docker0, pary VETH dla każdego kontenera, przestrzenie nazw sieciowe, oraz zarządza regułami iptables dla NAT i publikowania portów. Zrozumienie tego, co dzieje się pod maską, pozwala na efektywne debugowanie i projektowanie architektury kontenerowej.

Powyższa ściąga zawiera wszystkie najważniejsze polecenia omówione podczas prezentacji. Mostek (bridge): ip link add type bridge do tworzenia, ip link set master do dodawania interfejsów, bridge fdb show do podglądu tablicy FDB. Pamiętaj, że mostek wymaga adresu IP tylko na interfejsie br0, a interfejsy członkowskie nie mają adresów L3.

VETH: para tworzona przez ip link add type veth peer. Jeden koniec można przenieść do przestrzeni nazw (ip link set netns), drugi podłączyć do mostka (ip link set master). VETH działa jak wirtualny kabel - dane wysłane na jednym koncu pojawiają się na drugim. Bez podniesienia interfejsu (ip link set up) nie przetwarza pakietów.

Network namespace: tworzone przez ip netns add, usuwane przez ip netns del. Polecenia w przestrzeni nazw wykonujemy przez ip netns exec. Każda przestrzeń ma własne interfejsy, routing, iptables. Interfejs lo jest domyślnie DOWN - trzeba go podnieść. Po usunięciu netns wszystkie interfejsy wirtualne w niej są usuwane.

Docker: najczęściej używane polecenia to docker run z -p lub --network, docker network create/ls/inspect. Pamiętaj, że domyślny mostek docker0 ma ograniczenia (brak DNS, słaba izolacja) - w produkcji używaj user-defined bridge. Reguły iptables Dockera są w łańcuchach DOCKER (nat i filter) oraz DOCKER-USER dla własnych reguł.

Diagnostyka: iptables -t nat -L DOCKER do podglądu DNAT, tcpdump -i br0 do monitorowania ruchu na moście, nsenter -t PID -n do wejścia w przestrzeń nazw procesu (przydatne, gdy docker exec nie działa). Pamiętaj o sudo dla wszystkich poleceń wymagających uprawnień root.