Współczesna inżynieria systemów operacyjnych i sieci komputerowych przeszła fundamentalną ewolucję od fizycznych urządzeń przełączających do środowisk w pełni zdefiniowanych programowo (SDN – Software-Defined Networking). Jądro systemu Linux udostępnia kompletną, wysoce zoptymalizowaną infrastrukturę wirtualizacji warstwy łącza danych (L2) oraz warstwy sieciowej (L3), która eliminuje konieczność stosowania dedykowanych urządzeń sprzętowych w architekturze mikrousług i wirtualizacji serwerów.

Kluczowym elementem tej architektury jest moduł programowego przełącznika sieciowego (Linux bridge, sterownik bridge.ko), zaimplementowany bezpośrednio w podsystemie sieciowym jądra (katalog net/bridge/). Mostek ten emuluje funkcjonalność wieloportowego przełącznika Ethernet, realizując uczenie się adresów MAC (ang. MAC learning), zarządzanie bazą przekazywania ramek (FDB – Forwarding Database), obsługę protokołów drzewa rozpinającego (STP wg IEEE 802.1D oraz RSTP wg IEEE 802.1w) oraz znakowanie ramek tagami VLAN (standard IEEE 802.1Q). Umożliwia to łączenie zarówno fizycznych kart sieciowych (NIC), jak i urządzeń czysto wirtualnych w spójną domenę rozgłoszeniową.

Do łączenia odizolowanych środowisk wykonawczych jądro wykorzystuje wirtualne pary interfejsów Ethernet (ang. Virtual Ethernet – VETH, moduł drivers/net/veth.c). Działają one na zasadzie dwukierunkowej rury w pamięci operacyjnej: pakiet wprowadzony do jednego interfejsu pojawia się natychmiast na drugim końcu pary. W połączeniu z przestrzeniami nazw sieci (ang. network namespaces, mechanizm CLONE_NEWNET zdefiniowany w podsystemie net_namespace), administratorzy uzyskują możliwość tworzenia w pełni autonomicznych stosów sieciowych z własnymi interfejsami, tablicami routingu, gniazdami sieciowymi i regułami zapory ogniowej Netfilter.

Środowisko Docker oraz orkiestrator Kubernetes (poprzez specyfikację Container Network Interface – CNI) wykorzystują powyższe prymitywy jądra do budowy gotowych architektur sieciowych. Podczas warsztatu zbadamy nie tylko standardowy mostek docker0 i translację portów przez mechanizm DNAT w iptables, lecz także wysokowydajne sterowniki alternatywne, takie jak Macvlan, Ipvlan, sieci nakładkowe VXLAN (RFC 7348) oraz nowoczesne implementacje eBPF wykorzystywane w projektach Cilium i Calico.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.
VLAN (Virtual LAN) – logiczna sieć wirtualna wydzielona znacznikiem IEEE 802.1Q.
DNAT (Destination NAT) – translacja adresu docelowego stosowana przy publikowaniu portów kontenerów.

Przydatne łącza: Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Nadrzędnym celem niniejszego modułu dydaktycznego jest wykształcenie u uczestników głębokiego, inżynierskiego zrozumienia procesów zachodzących w podsystemie sieciowym jądra Linuksa podczas wirtualizacji i konteneryzacji. Wielu administratorów traktuje sieć w Dockerze jako nieprzejrzystą „czarną skrzynkę”, co prowadzi do poważnych błędów konfiguracyjnych, problemów z bezpieczeństwem oraz bezradności podczas awarii produkcyjnych.

W ramach szkolenia uczestnik prześledzi pełną ścieżkę pakietu sieciowego: od aplikacji w przestrzeni użytkownika (user space), przez gniazdo sieciowe w odizolowanej przestrzeni netns, wirtualny interfejs VETH, tablicę FDB mostka jądra, aż po reguły zapory sieciowej Netfilter (iptables/nftables) i fizyczny interfejs sieciowy wychodzący do sieci lokalnej LAN.

Uczestnik zdobędzie praktyczne umiejętności manualnego odtworzenia pełnej topologii sieciowej Dockera bez użycia samego demona Dockera. Samodzielne zestawienie mostka, wykreowanie przestrzeni nazw, podłączenie wirtualnego okablowania VETH, konfiguracja adresacji IP, uruchomienie routingu i translacji adresów DNAT pozwala zrozumieć, że konteneryzacja jest w istocie zręcznym złożeniem elementarnych mechanizmów jądra Linuksa.

Dodatkowo warsztat przygotowuje do pracy w środowiskach wielowęzłowych (klastry Kubernetes), gdzie tradycyjny mostek bywa zastępowany przez wtyczki CNI korzystające z trasowania BGP (Project Calico), enkapsulacji VXLAN (Flannel) lub programowalnych filtrów pakietowych eBPF (Cilium), które drastycznie podnoszą wydajność i skalowalność komunikacji międzykontenerowej.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
VLAN (Virtual LAN) – logiczna sieć wirtualna wydzielona znacznikiem IEEE 802.1Q.
DNAT (Destination NAT) – translacja adresu docelowego stosowana przy publikowaniu portów kontenerów.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Program prezentacji został podzielony na pięć spójnych modułów tematycznych, które łączą rygorystyczne podstawy akademickiej teorii teleinformatycznej z wymogami współczesnej praktyki administratorskiej w środowiskach produkcyjnych.

W Części I badamy fundamenty przełączania pakietów w pamięci operacyjnej serwera. Poznajemy specyfikę implementacji mostka sieciowego w kodzie jądra, analizujemy strukturę tablicy przekazywania (FDB), mechanizm wygaszania wpisów (aging) oraz algorytm podejmowania decyzji o forwardingu i floodingu, w tym ograniczenia wynikające z zasady split horizon i konieczność aktywacji trybu hairpin.

W Części II wprowadzamy wirtualne okablowanie (VETH) oraz przestrzenie nazw (network namespaces). Omawiamy zaawansowane sterowniki sieciowe jądra Linuksa, w tym obsługę standardu VLAN IEEE 802.1Q oraz sterowniki Macvlan i Ipvlan, które pozwalają na bezpośrednie podłączanie kontenerów do sieci fizycznej z pominięciem narzutu mostka programowego.

W Części III i IV dekonstruujemy architekturę sieciową platformy Docker. Przechodzimy od pojedynczego mostka docker0 do zaawansowanych sieci nakładkowych (Overlay) opartych na enkapsulacji VXLAN (RFC 7348) oraz protokole EVPN/BGP. Analizujemy szczegółowo mechanizm publikowania portów, badając powiązania między demonem dockerd, zręcznymi regułami DNAT w podsystemie Netfilter a pomocniczym procesem docker-proxy.

Część V wieńczy szkolenie pełnym ćwiczeniem laboratoryjnym zrealizowanym w czystym wierszu poleceń Linuksa, analizą mechanizmów zapobiegania pętlom (STP), przeglądem wtyczek CNI wykorzystywanych w Kubernetes (Flannel, Calico, Cilium) oraz praktycznym zestawieniem poleceń diagnostycznych w postaci kompendium inżynierskiego.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.
VLAN (Virtual LAN) – logiczna sieć wirtualna wydzielona znacznikiem IEEE 802.1Q.
DNAT (Destination NAT) – translacja adresu docelowego stosowana przy publikowaniu portów kontenerów.

Przydatne łącza: Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Klasyczny przełącznik sieciowy warstwy 2 (L2) opiera swoją architekturę na wysoce wyspecjalizowanych układach scalonych o dedykowanym przeznaczeniu (ASIC – Application-Specific Integrated Circuit) oraz pamięciach skojarzeniowych TCAM (Ternary Content-Addressable Memory). Układy te pozwalają na podejmowanie decyzji o przekazaniu ramki Ethernet w czasie liczonym w nanosekundach, realizując przełączanie z pełną prędkością łącza (tzw. wire-speed switching). Każdy port fizyczny dysponuje dedykowanymi buforami pamięci FIFO, a tablica adresów MAC jest bezpośrednio zintegrowana ze strukturami sprzętowymi.

Mimo niezrównanej wydajności, architektura sprzętowa wykazuje zasadnicze ograniczenia w nowoczesnych centrach danych: jest statyczna, wymaga fizycznego okablowania, a rekonfiguracja portów pod potrzeby dynamicznie migrujących maszyn wirtualnych lub kontenerów zajmuje zbyt dużo czasu. Wraz ze wzrostem gęstości upakowania środowisk wirtualnych pojawiła się konieczność przeniesienia funkcji przełącznika L2 bezpośrednio do wnętrza systemu operacyjnego serwera fizycznego.

Mostek wirtualny w Linuksie (Linux bridge) realizuje dokładnie te same funkcje logiczne co przełącznik sprzętowy, lecz czyni to w oprogramowaniu działającym w przestrzeni jądra (kernel space). Pakiety sieciowe są reprezentowane przez struktury sk_buff alokowane w pamięci RAM, a tablica FDB to tablica haszująca indeksowana adresami MAC. Choć narzut przełączania kontekstu i kolejkowania w pamięci RAM generuje nieco wyższe opóźnienia niż układy ASIC, to elastyczność programowa jest bezkonkurencyjna. Mostek wirtualny można powołać do życia w ułamku milisekundy za pomocą jednego wywołania systemowego Netlink, dynamicznie przypinając do niego interfejsy kontenerów i maszyn wirtualnych.

W ten sposób powstał fundament pod koncepcję sieci definiowanych programowo (SDN). Współczesne serwery stają się miniaturowymi węzłami przełączającymi, w których ruch między kontenerami na tym samym hoście nigdy nie opuszcza pamięci operacyjnej RAM, osiągając przepustowości rzędu kilkudziesięciu gigabitów na sekundę przy zerowym zużyciu fizycznych portów przełącznika zewnętrznego.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.
Docker bridge – domyślna sieć kontenerów z NAT i wirtualnym mostem docker0.

Przydatne łącza: Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra).

Koncepcja sieci definiowanych programowo (SDN) narodziła się na Uniwersytecie Stanforda jako projekt badawczy Ethane, a następnie została sformalizowana w protokole OpenFlow przez organizację Open Networking Foundation (ONF). Tradycyjne urządzenia sieciowe łączyły płaszczyznę sterowania (procesor zarządzający protokołami OSPF, BGP, STP) z płaszczyzną danych (sprzętowe ASIC) w jednej obudowie. SDN zrewolucjonizowało tę architekturę, centralizując inteligencję w zewnętrznym kontrolerze programowym i redukując węzły sieciowe do szybkich elementów wykonawczych.

System Linux od wielu lat dostarczał komponenty, które idealnie wpisują się w model SDN. Podsystem netlink stanowi uniwersalny protokół komunikacji pomiędzy procesami przestrzeni użytkownika (np. demonami zarządzającymi, takimi jak dockerd, kubelet czy OVS Controller) a strukturami jądra odpowiedzialnymi za przełączanie danych. Dzięki Netlink narzędzia administracyjne mogą asynchronicznie modyfikować tablice routingu (FIB), reguły mostka (FDB) oraz parametry interfejsów w ułamkach sekund.

Prawdziwym przełomem w linuksowej płaszczyźnie danych stały się technologie Open vSwitch (OVS) oraz eBPF (Extended Berkeley Packet Filter). OVS umożliwia tworzenie zaawansowanych sieci nakładkowych w środowiskach takich jak OpenStack czy VMware, wspierając tunele Geneve, GRE i VXLAN oraz protokół OpenFlow. Z kolei eBPF wraz z technologią XDP pozwala na wstrzykiwanie bezpiecznego kodu bajtowego bezpośrednio do jądra, wykonując operacje filtrowania i routingu wprost na pierścieniu odbiorczym (RX ring) karty sieciowej, co pozwala na przetwarzanie dziesiątek milionów pakietów na sekundę na pojedynczym rdzeniu procesora.

Dzięki temu ekosystem Linuksa stał się wiodącą platformą dla współczesnych architektur telekomunikacyjnych, wirtualizacji funkcji sieciowych (NFV – Network Functions Virtualization) oraz nowoczesnych systemów orkiestracji chmurowej.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.
Docker bridge – domyślna sieć kontenerów z NAT i wirtualnym mostem docker0.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Implementacja mostka sieciowego w Linuksie została wprowadzona już w serii jądra 2.4 i od tego czasu podlega ciągłej optymalizacji pod kątem skalowalności wielordzeniowej (SMP) oraz minimalizacji narzutu pamięciowego. W architekturze jądra mostek jest rejestrowany jako standardowe urządzenie sieciowe (struktura net_device), ale w odróżnieniu od klasycznych kart sieciowych posiada wewnętrzną listę portów podrzędnych (ang. slave interfaces lub bridge ports).

Gdy interfejs fizyczny lub wirtualny (np. eth0 lub veth0) zostaje dodany do mostka, jego tryb pracy ulega zasadniczej zmianie: interfejs przestaje bezpośrednio przekazywać pakiety do lokalnego stosu L3 jądra (chyba że ruch jest kierowany do mostka). Zamiast tego funkcja odbiorcza sterownika sieciowego (netif_receive_skb) wykrywa przypisanie do mostka i przekazuje wskaźnik do struktury sk_buff bezpośrednio do procedury br_handle_frame.

Warto podkreślić, że mostek Linuksa realizuje pełne wsparcie dla standardu IEEE 802.1Q za pośrednictwem podsystemu VLAN filtering. Włączenie parametru vlan_filtering 1 na mostku przekształca go w zaawansowany przełącznik zarządzalny (ang. VLAN-aware bridge). Każdy port może mieć przypisany identyfikator PVID (Port VLAN ID) dla ramek nieoznakowanych (untagged) oraz listę dozwolonych identyfikatorów VLAN dla ramek znakowanych (tagged), co eliminuje konieczność tworzenia osobnych mostków dla każdego identyfikatora VLAN w systemie.

Dodatkowym atutem mostka Linuksa jest integracja z podsystemem ebtables oraz modułem br_netfilter, który pozwala na inspekcję i filtrowanie przepływających przez mostek ramek L2 za pomocą tradycyjnych łańcuchów iptables/nftables. Choć mechanizm ten bywa przydatny w zaporach mostkujących (bridging firewall), w środowiskach kontenerowych wymaga starannej konfiguracji, aby nie obniżać wydajności forwardingu.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
VLAN (Virtual LAN) – logiczna sieć wirtualna wydzielona znacznikiem IEEE 802.1Q.

Przydatne łącza: Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Procedura tworzenia mostka w Linuksie odzwierciedla logikę budowy fizycznej sieci komputerowej. Polecenie ip link add name br0 type bridge tworzy wirtualną jednostkę przełączającą. W strukturach jądra alokowana jest struktura net_bridge powiązana z nowym interfejsem nadrzędnym (master). Na tym etapie mostek jest pusty i wyłączony.

Kluczową operacją jest dołączenie portów członkowskich za pomocą dyrektywy master br0. W tym momencie jądro modyfikuje flagi interfejsu podrzędnego, ustawiając flagę IFF_SLAVE oraz wskaźnik rx_handler na funkcję obsługi mostka br_handle_frame. Od tej chwili interfejs podrzędny traci autonomię w warstwie L3 – wszelkie próby przypisania do niego adresu IP zakończą się konfliktami trasowania lub całkowitym brakiem odpowiedzi na pakiety ARP.

Interfejs mostka (br0) pełni podwójną rolę architektoniczną:

• Z punktu widzenia warstwy L2 jest on nadrzędnym węzłem logicznym zarządzającym portami podrzędnymi;
• Z punktu widzenia warstwy L3 jest wirtualną kartą sieciową hosta podłączoną do wewnętrznego portu przełącznika. To na nim konfiguruje się adres IP, maskę podsieci oraz ewentualne reguły routingu. W ten sposób host może komunikować się ze wszystkimi urządzeniami i kontenerami podłączonymi do mostka, pełniąc dla nich rolę domyślnej bramy (default gateway).

Różnica technologiczna między nowoczesnym narzędziem ip link a historycznym brctl ma fundamentalne znaczenie. Narzędzie brctl komunikowało się z jądrem przez synchroniczny interfejs ioctl, który nie pozwalał na atomowe operacje i był podatny na blokady w środowiskach o dużej liczbie interfejsów. Pakiet iproute2 opiera się w całości na asynchronicznym protokole Netlink (rodzina NETLINK_ROUTE), co gwarantuje wysoką wydajność, bezpieczeństwo wątkowe oraz możliwość precyzyjnego monitorowania zdarzeń w czasie rzeczywistym.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.
Docker bridge – domyślna sieć kontenerów z NAT i wirtualnym mostem docker0.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Tablica FDB (Forwarding Database) stanowi serce decyzyjne przełącznika warstwy 2. W jądrze Linuksa FDB jest zaimplementowana jako wysoce zoptymalizowana tablica haszująca (struktura net_bridge_fdb_entry powiązana z haszowaniem RCU – Read-Copy-Update). Pozwala to na bezblokadowe przeszukiwanie tablicy przez wiele rdzeni procesora jednocześnie podczas odbierania pakietów z dużą częstotliwością.

Każdy wpis w tablicy FDB przechowuje kluczowe atrybuty:

• Adres sprzętowy MAC (48 bitów / 6 bajtów);
• Identyfikator portu składowego (interfejs podrzędny dev);
• Znacznik czasu ostatniej aktywności (używany przez proces wygaszania br_fdb_cleanup);
• Flagi stanu: is_local (oznacza adres należący do samego mostka lub jego interfejsu), is_static (wpis wprowadzony ręcznie, niepodlegający wygaszaniu) oraz is_dynamic (wpis nauczony z ruchu przychodzącego).

Gdy stacja robocza lub kontener wysyła pierwszą ramkę Ethernet, mostek rejestruje jej adres źródłowy w FDB. Jeśli stacja milczy przez czas określony parametrem ageing_time (wyrażanym w setkach sekund, gdzie wartość domyślna 30000 w strukturze jądra odpowiada 300 sekundom), wpis zostaje automatycznie usunięty z pamięci. Zabezpiecza to tablicę przed przepełnieniem w przypadku odłączenia urządzenia lub migracji maszyny wirtualnej na inny port.

Warto zwrócić uwagę na wpisy oznaczone jako permanent. Są to adresy MAC przypisane bezpośrednio do fizycznych lub wirtualnych interfejsów mostka. Mostek nigdy nie usuwa tych wpisów i wie, że ramki skierowane na te adresy muszą zostać przekazane w górę stosu do lokalnego procesora hosta, a nie transmitowane na zewnątrz przez żaden z portów członkowskich.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
VLAN (Virtual LAN) – logiczna sieć wirtualna wydzielona znacznikiem IEEE 802.1Q.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Procedura forwardingu w mostku Linuksa jest zaimplementowana w funkcji br_handle_frame_finish w module net/bridge/br_input.c. Jest to kluczowy punkt ścieżki przetwarzania pakietu L2, w którym jądro decyduje o dalszych losach bufora sk_buff. Właściwe przekazywanie ramki realizują funkcje pomocnicze br_forward oraz br_flood z modułu net/bridge/br_forward.c.

Jeśli docelowy adres MAC ramki jest adresem unicastowym i znajduje się w tablicy FDB, mostek wywołuje funkcję br_forward, która kieruje wskaźnik pakietu do kolejki nadawczej właściwego interfejsu docelowego. Dzięki temu pozostałe porty mostka nie są obciążane niepotrzebnym ruchem, co drastycznie redukuje domenę kolizyjną i zapobiega podsłuchiwaniu pakietów przez inne interfejsy.

W sytuacji, gdy docelowy adres MAC nie występuje w FDB (tzw. unknown unicast), mostek zmuszony jest zastosować procedurę zalewania (ang. flooding) za pośrednictwem funkcji br_flood. Ramka jest klonowana i transmitowana na wszystkie porty należące do mostka, z wyjątkiem portu źródłowego. Gdy stacja docelowa odpowie na ramkę, mostek natychmiast uczy się jej adresu MAC z nagłówka odpowiedzi i kolejne pakiety są już przesyłane w trybie unicast.

Szczególnym zagadnieniem w wirtualizacji sieci jest zasada split horizon. Standardowo przełącznik nigdy nie transmituje odebranej ramki z powrotem na interfejs, z którego przyszła. Jednak w zaawansowanych środowiskach (np. gdy interfejs stanowi tunel, agregację VEPA lub gdy kontener wysyła pakiet do własnego opublikowanego adresu za pośrednictwem mostka), zachowanie to uniemożliwia łączność. Włączenie flagi hairpin on (nazywanej w specyfikacji IEEE trybem Reflective Relay wg standardu 802.1Qbg) jawnie zezwala mostkowi na zawrócenie ramki na port źródłowy, co jest niezbędne m.in. przy obsłudze tzw. hairpin NAT w środowisku Docker.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.
Docker bridge – domyślna sieć kontenerów z NAT i wirtualnym mostem docker0.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Rola mostka sieciowego w architekturze współczesnych centrów danych jest nie do przecenienia. Niezależnie od tego, czy wdrażamy hiperwizor maszyn wirtualnych KVM zarządzany przez libvirt, czy platformę kontenerową Docker lub containerd, to właśnie Linux bridge odpowiada za zapewnienie łączności w warstwie łącza danych (L2).

W przypadku wirtualizacji KVM/QEMU interfejs TAP działa w warstwie 2 jako urządzenie znakowe udostępniane przez jądro w /dev/net/tun. Gdy proces QEMU symuluje wysłanie ramki przez maszynę wirtualną, zapisuje dane do deskryptora pliku TAP. Jądro Linuksa odbiera te dane dokładnie tak, jakby nadeszły z fizycznej karty sieciowej, i przekazuje je do mostka br0. Dzięki temu maszyna wirtualna uzyskuje własny, w pełni unikalny adres MAC i jest widoczna w fizycznej sieci LAN jako niezależny komputer podłączony do tego samego przełącznika sprzętowego co host.

Dla środowisk kontenerowych mostek pełni rolę wewnętrznego przełącznika izolującego. W odróżnieniu od maszyn KVM, kontenery Docker standardowo nie są wpinane do mostka z kartą fizyczną, lecz do prywatnego mostka docker0. Komunikacja ze światem zewnętrznym jest realizowana za pośrednictwem routingu L3 oraz translacji adresów źródłowych (SNAT / MASQUERADE) na fizycznym interfejsie serwera.

Warto jednak znać ograniczenia mostka programowego. Każda ramka przechodząca przez bridge musi zostać przetworzona przez procedury jądra, co generuje narzut CPU i pamięci podręcznej. Dlatego w architekturach telekomunikacyjnych (np. 5G Core, NFV) oraz bazach danych o wysokiej przepustowości stosuje się technologie alternatywne: Macvlan (eliminujący mostek na rzecz wirtualnych pod-interfejsów MAC), Ipvlan (współdzielący adres MAC i przełączający w L3) oraz SR-IOV (Single Root I/O Virtualization), gdzie fizyczna karta sieciowa sprzętowo udostępnia niezależne wirtualne funkcje (VF – Virtual Functions) z pominięciem stosu jądra hosta.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
VLAN (Virtual LAN) – logiczna sieć wirtualna wydzielona znacznikiem IEEE 802.1Q.

Przydatne łącza: Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Zarządzanie mostkiem w systemie Linux przeszło istotną transformację architektoniczną. Historyczny pakiet bridge-utils, rozwijany przez wiele lat jako podstawowe narzędzie administratorskie (polecenie brctl), korzystał z archaicznego mechanizmu wywołań ioctl na gniazdach sieciowych (SIOCBRADDBR, SIOCBRDELBR, SIOCBRADDIF). Mechanizm ten był synchroniczny, nie udostępniał precyzyjnych kodów błędów i nie pozwalał na atomową manipulację zaawansowanymi parametrami mostka.

Obecnie bezwzględnym standardem w dystrybucjach produkcyjnych jest podsystem iproute2, a w szczególności dwa wyspecjalizowane polecenia:

• ip link: służy do zarządzania cyklem życia samego urządzenia sieciowego (tworzenie, usuwanie, zmiana stanu UP/DOWN, przypisywanie do nadrzędnego mostka za pomocą parametru master);
• bridge: dedykowane narzędzie wchodzące w skład pakietu iproute2, komunikujące się z jądrem za pośrednictwem gniazda NETLINK_ROUTE. Pozwala ono na precyzyjną kontrolę tablicy FDB (bridge fdb), podgląd stanu portów (bridge link), zarządzanie drzewem rozpinającym STP oraz konfigurację zaawansowanego filtrowania VLAN (bridge vlan).

Dzięki poleceniu bridge link show administrator może sprawdzić nie tylko to, które porty należą do danego mostka, lecz także zbadać ich zaawansowane flagi operacyjne: state (stan portu w STP: disabled, listening, learning, forwarding, blocking), priority, cost, a także status trybów hairpin, guard (ochrona przed nieautoryzowanymi pakietami BPDU) oraz root_block.

Migracja ze skryptów wykorzystujących brctl na polecenia ip link i bridge jest wymogiem nowoczesnego zarządzania serwerami Linuksa, gwarantującym pełną zgodność z systemami automatyzacji (np. systemd-networkd, Netplan, NetworkManager) oraz stabilność pod dużym obciążeniem.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VLAN (Virtual LAN) – logiczna sieć wirtualna wydzielona znacznikiem IEEE 802.1Q.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Diagnostyka mostka sieciowego w Linuksie wymaga rzetelnej wiedzy o mechanizmach przełączania ramek Ethernet oraz wzajemnych zależnościach między warstwą łącza danych (L2) a warstwą sieciową (L3). W złożonych środowiskach serwerowych najpoważniejszym zagrożeniem są pętle warstwy 2 (ang. bridging loops). Ze względu na brak pola TTL (Time-To-Live) w nagłówku Ethernet, zduplikowana ramka rozgłoszeniowa krąży w pętli w nieskończoność, wywołując burzę rozgłoszeniową (ang. broadcast storm), która natychmiast wysyca przepustowość pamięci i zawiesza obsługę przerwań sieciowych procesora.

Zjawiskiem bezpośrednio towarzyszącym pętlom jest tzw. MAC flapping (trzepotanie adresów MAC). Polega ono na tym, że ten sam źródłowy adres MAC pojawia się w ułamkach milisekund na różnych portach mostka. Mostek nieustannie nadpisuje wpis w tablicy FDB, co jądro odnotowuje w logach systemowych (dmesg). Do diagnozowania tego zjawiska w czasie rzeczywistym służy narzędzie bridge monitor fdb, które wyświetla każde przesunięcie adresu sprzętowego między portami.

Drugim częstym źródłem problemów w heterogenicznych sieciach jest niedopasowanie jednostki MTU (Maximum Transmission Unit). Mostek w Linuksie przyjmuje jako własne MTU najmniejszą wartość spośród wszystkich przypisanych portów składowych. Jeśli do mostka o MTU 1500 zostanie dołączony interfejs wirtualny o MTU 1450 (np. tunel VPN lub interfejs sieci nakładkowej), MTU całego mostka zostanie natychmiast zredukowane. W efekcie pakiety o standardowym rozmiarze 1500 bajtów nie mieszczące się w obniżonym MTU zostaną po cichu odrzucone, co objawia się pozornie nielogicznym zachowaniem: polecenie ping (wysyłające małe pakiety) działa bez zarzutu, podczas gdy transfery HTTP czy sesje SSH ulegają natychmiastowemu zawieszeniu.

Nie można również pominąć modułu jądra br_netfilter. Gdy moduł ten jest załadowany, ramki L2 przechodzące przez mostek są poddawane inspekcji przez reguły iptables tabeli filter (łańcuch FORWARD). Jeśli domyślna polityka łańcucha FORWARD to DROP, cały ruch na mostku zostanie zablokowany. Rozwiązaniem jest jawne zezwolenie na ruch w regułach zapory lub wyłączenie przekazywania ruchu mostkowanego do iptables za pomocą parametru jądra sysctl -w net.bridge.bridge-nf-call-iptables=0.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.
Docker bridge – domyślna sieć kontenerów z NAT i wirtualnym mostem docker0.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Sterownik wirtualnych par Ethernet (VETH) stanowi fundamentalny budulec współczesnej wirtualizacji kontenerowej w systemie Linux. Został wprowadzony do jądra, aby umożliwić bezkolizyjne i wysoce wydajne przesyłanie pakietów warstwy 2 pomiędzy niezależnymi przestrzeniami nazw sieci (network namespaces), które z definicji nie współdzielą żadnych struktur sieciowych.

Z punktu widzenia implementacji w kodzie jądra (drivers/net/veth.c), każde urządzenie VETH jest instancją standardowej struktury net_device. Podczas wywołania funkcji nadawczej veth_xmit jądro pobiera wskaźnik do struktury bufora pakietu sk_buff, weryfikuje stan urządzenia partnerskiego (peer) i bezpośrednio wywołuje funkcję odbiorczą netif_rx na interfejsie partnerskim. Oznacza to, że komunikacja nie wymaga fizycznego sterownika sprzętowego, kolejek DMA ani buforów na kartach sieciowych.

Co istotne, urządzenia VETH są zawsze tworzone parami i nie mogą istnieć pojedynczo. Usunięcie jednego z interfejsów (lub zniszczenie przestrzeni nazw, w której się znajduje) skutkuje natychmiastowym i automatycznym usunięciem drugiego końca pary przez jądro systemu operacyjnego. Zapewnia to integralność pamięci i zapobiega powstawaniu interfejsów osieroconych.

Warto również zauważyć, że urządzenia VETH domyślnie wykorzystują zaawansowane mechanizmy akceleracji programowej jądra, takie jak sprzętowe odciążanie sum kontrolnych (ang. checksum offloading – flaga NETIF_F_HW_CSUM) oraz agregację segmentów TCP (TSO/GSO – TCP/Generic Segmentation Offload). Dzięki temu transfer danych między kontenerami na tym samym hoście osiąga przepustowości przekraczające 40–50 Gb/s, będąc ograniczonym niemal wyłącznie taktowaniem pamięci RAM i rdzeni procesora.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Składnia polecenia tworzenia wirtualnej pary interfejsów w pakiecie iproute2 precyzyjnie oddaje symetrię tego rozwiązania: ip link add <nazwa_A> type veth peer name <nazwa_B>. Administrator ma pełną dowolność w nazewnictwie obu końców pary, przy czym maksymalna długość nazwy interfejsu w Linuksie wynosi 15 znaków (stała IFNAMSIZ - 1 w nagłówku linux/if.h).

Po wykreowaniu interfejsów znajdują się one w stanie administracyjnym DOWN. Aby mogły przesyłać pakiety, oba końce muszą zostać podniesione za pomocą polecenia ip link set dev <nazwa> up. Jeśli chociaż jeden z interfejsów pozostaje w stanie DOWN, jądro nie zezwoli na przekazanie ramek, a próba wysłania pakietu zakończy się błędem Network is down.

Jednym z najczęstszych wyzwań w zarządzaniu dużymi środowiskami kontenerowymi (gdzie istnieją setki interfejsów o losowych nazwach generowanych przez Dockera, np. veth4a9b1c2) jest ustalenie, który interfejs na hoście łączy się z konkretnym interfejsem eth0 wewnątrz danego kontenera. Standardowy podgląd ip link show nie wyświetla bezpośrednio nazwy interfejsu partnerskiego, jeśli został on przeniesiony do innej przestrzeni nazw.

Do rozwiązania tego problemu służą dwa zaawansowane narzędzia diagnostyczne:

• Polecenie ip -d link show veth-host: flaga -d (details) wyświetla atrybuty sterownika, w tym parametr veth z numerem indeksu urządzenia partnerskiego (np. peer_ifindex 18);
• Narzędzie ethtool -S <interfejs>: odczytuje statystyki sterownika dostarczane przez funkcję veth_get_ethtool_stats, zwracając zmienną peer_ifindex.

Wiedząc, że interfejs partnerski ma indeks np. 18, administrator może wejść do przestrzeni kontenera i sprawdzić, który interfejs posiada ifindex równy 18. Pozwala to na bezbłędne mapowanie topologii sieciowej w skryptach orkiestracji i narzędziach monitorujących.

Wyjaśnienie skrótów i pojęć:
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.
Docker bridge – domyślna sieć kontenerów z NAT i wirtualnym mostem docker0.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Przestrzenie nazw (namespaces) stanowią fundament lekkiej wirtualizacji w systemie Linux, na której opierają się silniki kontenerowe Docker, Podman, LXC oraz środowiska uruchomieniowe Kubernetes (containerd, CRI-O). O ile inne przestrzenie nazw (takie jak PID, Mount, IPC, UTS czy User) izolują odpowiednio drzewa procesów, punkty montowania systemów plików czy nazwy hostów, o tyle przestrzeń sieciowa (Network Namespace) odpowiada za wirtualizację całego podsystemu sieciowego.

W architekturze jądra Linuksa każda struktura procesu (struct task_struct) przechowuje wskaźnik do struktury nsproxy, która z kolei wskazuje na dedykowaną strukturę net (zdefiniowaną w include/net/net_namespace.h). Wszystkie globalne tablice sieciowe jądra – tablica routingu IPv4 i IPv6, tablica haszująca gniazd TCP (tcp_hashinfo), tablica conntrack oraz reguły Netfilter – są sparametryzowane wskaźnikiem na odpowiednią strukturę struct net.

W momencie tworzenia nowej przestrzeni nazw sieci jądro inicjalizuje całkowicie czysty stos sieciowy. Jedynym interfejsem obecnym w nowej przestrzeni jest wirtualny interfejs pętli zwrotnej lo, który początkowo znajduje się w stanie administracyjnym DOWN. Żadne fizyczne karty sieciowe serwera nie są w niej widoczne. Co więcej, procesy działające w odrębnych przestrzeniach nazw nie mogą przesyłać między sobą pakietów przez standardowe gniazda sieciowe, dopóki administrator nie połączy tych przestrzeni wirtualnym okablowaniem (np. parą VETH).

W systemie plików reprezentacja przestrzeni nazw jest dostępna w wirtualnym systemie plików procfs pod ścieżką /proc/<PID>/ns/net w postaci specjalnego łącza symbolicznego. Dopóki jakikolwiek proces posiada otwarty deskryptor do tego pliku (lub dopóki plik jest zamontowany w /var/run/netns/), jądro utrzymuje daną przestrzeń sieciową przy życiu, nawet jeśli nie wykonuje się w niej żaden proces użytkownika.

Wyjaśnienie skrótów i pojęć:
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
Docker bridge – domyślna sieć kontenerów z NAT i wirtualnym mostem docker0.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Zarządzanie nazwanymi przestrzeniami sieciowymi w systemie Linux opiera się na konwencji wprowadzonej przez pakiet iproute2. Wykonanie polecenia ip netns add <nazwa> realizuje sekwencję precyzyjnych operacji systemowych: jądro tworzy nową strukturę net za pomocą wywołania unshare(CLONE_NEWNET), a następnie narzędzie ip montuje deskryptor tej przestrzeni w punkcie /var/run/netns/<nazwa> za pomocą mechanizmu bind mount (mount --bind /proc/self/ns/net /var/run/netns/<nazwa>).

Dzięki temu zabiegowi przestrzeń nazw uzyskuje trwałą reprezentację w systemie plików i nie znika po zakończeniu procesu, który ją powołał. Polecenie ip netns list po prostu odczytuje zawartość katalogu /var/run/netns/, prezentując nazwy wszystkich aktywnych przestrzeni powiązanych z tym mechanizmem.

Polecenie ip netns exec <nazwa> <polecenie> otwiera plik w /var/run/netns/<nazwa> i wykonuje wywołanie systemowe setns(fd, CLONE_NEWNET). W tym momencie bieżący wątek procesu zostaje przełączony do docelowej przestrzeni sieciowej, po czym następuje wywołanie execve() z zadanym programem (np. ping, ss, nginx czy bash). Wszystkie operacje sieciowe wykonywane przez ten program będą operować wyłącznie na odizolowanym stosie wybranej przestrzeni.

Warto pamiętać o narzędziu nsenter (wchodzącym w skład pakietu util-linux). W odróżnieniu od ip netns, narzędzie nsenter potrafi podłączyć się do przestrzeni sieciowej dowolnego procesu w systemie na podstawie jego identyfikatora PID (np. nsenter -t <PID> -n <polecenie>). Jest to niezwykle przydatne podczas analizy kontenerów Docker lub podów Kubernetes, które standardowo nie tworzą wpisów w katalogu /var/run/netns/, lecz opierają się na anonimowych przestrzeniach nazw powiązanych bezpośrednio z procesem kontenera.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.
Docker bridge – domyślna sieć kontenerów z NAT i wirtualnym mostem docker0.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Bezpośrednie połączenie dwóch przestrzeni nazw sieci za pomocą pary VETH jest najprostszą, a zarazem najbardziej elegancką topologią wirtualną typu punkt-punkt (Point-to-Point). Odpowiada ona sytuacji, w której łączymy dwie fizyczne stacje robocze bezpośrednim kablem krosowym Ethernet bez użycia żadnego pośredniczącego przełącznika ani koncentratora.

Kluczowym momentem procedury konfiguracyjnej jest wykonanie polecenia ip link set <interfejs> netns <przestrzeń>. W tym momencie jądro Linuksa dokonuje migracji struktury net_device z domyślnej przestrzeni hosta (init_net) do wskazanej struktury net. Z perspektywy hosta interfejs natychmiast znika z wyników polecenia ip link show, pojawiając się jednocześnie wewnątrz wyznaczonej przestrzeni netns. Co istotne, wszelkie adresy IP przypisane uprzednio do tego interfejsu zostają skasowane podczas migracji między przestrzeniami, a sam interfejs zostaje przełączony w stan DOWN.

Zastosowanie maski /30 (lub nowoczesnej /31 zgodnej z RFC 3021 dla połączeń punkt-punkt) pozwala na oszczędne i logiczne zagospodarowanie puli adresowej. W takiej konfiguracji interfejs veth-red (10.0.0.1) oraz veth-blue (10.0.0.2) znajdują się w tej samej podsieci IP, dzięki czemu jądro automatycznie tworzy bezpośrednią trasę link-local w tablicy routingu każdej z przestrzeni.

Gdy proces w przestrzeni red generuje pakiet ICMP Echo Request pod adres 10.0.0.2, jądro wykonuje zapytanie ARP na interfejsie veth-red. Pakiet ARP natychmiast pojawia się na interfejsie veth-blue w przestrzeni blue, która odpowiada swoim wirtualnym adresem MAC. Po uzyskaniu wpisu ARP pakiet ICMP przepływa przez pamięć operacyjną, generując natychmiastową odpowiedź Echo Reply z minimalnym opóźnieniem (często rzędu 0,02 ms).

Wyjaśnienie skrótów i pojęć:
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.
Docker bridge – domyślna sieć kontenerów z NAT i wirtualnym mostem docker0.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Topologia gwiazdy z centralnym programowym mostkiem warstwy 2 (Linux bridge) stanowi klasyczny i najbardziej uniwersalny wzorzec architektoniczny wirtualizacji sieciowej. Dokładnie ten mechanizm został zaimplementowany w silniku Docker jako domyślny sterownik bridge oraz w klasycznych wtyczkach CNI środowiska Kubernetes (np. wtyczka bridge konsorcjum CNI).

W tej architekturze host pełni rolę wirtualnej szafy krosowej. W pamięci jądra powoływany jest mostek br0, który pełni funkcję centralnego przełącznika L2. Każda nowo tworzona przestrzeń nazw (kontener) otrzymuje dedykowaną parę VETH. Jeden koniec pary zostaje wciągnięty do przestrzeni kontenera i zazwyczaj przemianowany na standardową nazwę eth0, natomiast drugi koniec pozostaje w przestrzeni hosta i zostaje przypięty do mostka jako port podrzędny (slave) za pomocą dyrektywy master br0.

Taka konstrukcja niesie ze sobą kolosalne korzyści architektoniczne:

• Wspólna domena rozgłoszeniowa L2: wszystkie kontenery znajdują się w tej samej podsieci logicznej (w przykładzie 192.168.10.0/24), dzięki czemu mogą komunikować się bezpośrednio ze sobą za pośrednictwem ramek Ethernet przekazywanych przez mostek, bez angażowania reguł routingu hosta;
• Rola bramy domyślnej (Default Gateway): interfejs mostka br0 posiada adres IP (192.168.10.1). Kontenery konfigurują ten adres jako swoją bramę domyślną. W ten sposób ruch kierowany poza lokalną podsieć kontenerów trafia bezpośrednio do stosu L3 jądra hosta;
• Skalowalność i prostota: dodanie kolejnego kontenera wymaga jedynie wykreowania nowej pary VETH i wpięcia jej do istniejącego mostka, bez konieczności modyfikacji konfiguracji pozostałych działających już kontenerów.

W kolejnych częściach szkolenia przeanalizujemy, w jaki sposób jądro hosta, dysponując adresem bramy na mostku oraz włączonym mechanizmem forwardingu pakietów, pośredniczy w wymianie ruchu między kontenerami a zewnętrzną siecią Internet za pośrednictwem translacji NAT.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.
Docker bridge – domyślna sieć kontenerów z NAT i wirtualnym mostem docker0.

Przydatne łącza: Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra).

Weryfikacja poprawności wdrożenia izolacji sieciowej jest kluczowym etapem audytu bezpieczeństwa środowiska wirtualnego. Aby upewnić się, że wdrożone przestrzenie nazw realizują założenia projektowe, inżynier sieciowy przeprowadza testy w trzech niezależnych wymiarach: komunikacji wewnętrznej L2, separacji gniazd L4 oraz łączności zewnętrznej L3.

Najbardziej spektakularnym dowodem pełnej separacji stosu sieciowego jest możliwość uruchomienia usług sieciowych nasłuchujących na identycznych numerach portów transportowych TCP/UDP w różnych przestrzeniach nazw na tej samej maszynie fizycznej. W tradycyjnym środowisku linuksowym próba uruchomienia drugiego procesu na porcie 80 kończy się natychmiastowym błędem systemowym EADDRINUSE (Address already in use). W architekturze z przestrzeniami netns każda przestrzeń posiada własną tablicę deskryptorów gniazd, co pozwala na uruchomienie setek odizolowanych serwerów WWW na porcie 80 bez jakichkolwiek konfliktów.

Aby stacje w przestrzeniach wirtualnych mogły komunikować się ze światem zewnętrznym (np. pobierać pakiety z Internetu), konieczne jest spełnienie dwóch fundamentalnych warunków w systemie operacyjnym hosta:

1. Aktywacja forwardingu IP: jądro Linuksa domyślnie działa jako stacja końcowa (host) i odrzuca pakiety, których docelowy adres IP nie jest przypisany do żadnego z lokalnych interfejsów. Ustawienie parametru sysctl net.ipv4.ip_forward=1 przełącza jądro w tryb routera programowego, zezwalając na przekazywanie pakietów pomiędzy interfejsem mostka br0 a fizyczną kartą sieciową (np. eth0);
2. Translacja adresów źródłowych (SNAT / MASQUERADE): adresy IP przydzielone do kontenerów (np. z puli prywatnej 192.168.10.0/24 wg RFC 1918) nie są trasowalne w sieci publicznej ani w zewnętrznej infrastrukturze przedsiębiorstwa. Reguła MASQUERADE w łańcuchu POSTROUTING tabeli nat podmienia źródłowy adres IP pakietu wychodzącego na publiczny adres IP hosta, rejestrując połączenie w tablicy conntrack.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.
Docker bridge – domyślna sieć kontenerów z NAT i wirtualnym mostem docker0.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

W zaawansowanej inżynierii sieciowej wybór odpowiedniego sterownika wirtualizacji interfejsu determinuje zarówno wydajność systemu, jak i architekturę bezpieczeństwa. Choć klasyczny Linux bridge połączony z parami VETH jest rozwiązaniem najbardziej uniwersalnym, wprowadza on podwójne przetwarzanie ramki Ethernet oraz narzut tablicy FDB i modułu br_netfilter. W środowiskach o ekstremalnych wymaganiach przepustowości (np. klastry baz danych, przetwarzanie strumieniowe wideo, systemy telekomunikacyjne NFV) jądro Linuksa oferuje sterowniki bezpośrednie: Macvlan oraz Ipvlan.

Podstawową zaletą sterownika Macvlan jest możliwość nadania każdemu kontenerowi całkowicie niezależnego, unikalnego adresu sprzętowego MAC, powiązanego z jednym fizycznym interfejsem nadrzędnym (np. eth0). Karta sieciowa hosta zostaje przełączona w tryb promiscuous (lub korzysta z filtrów unicast MAC na poziomie sprzętowym NIC). Kontener staje się bezpośrednim uczestnikiem fizycznej sieci LAN: może pobierać adres z fizycznego serwera DHCP i nie wymaga żadnego mostka ani translacji NAT na hoście. Macvlan udostępnia cztery tryby pracy: bridge (komunikacja L2 w pamięci jądra), vepa (zgodny z IEEE 802.1Qbg, wymuszający inspekcję ruchu na zewnętrznym przełączniku sprzętowym), private (pełna izolacja kontenerów od siebie) oraz passthru (dedykacja interfejsu fizycznego wyłącznie do jednej przestrzeni).

Z kolei sterownik Ipvlan został zaprojektowany z myślą o środowiskach, w których przełączniki fizyczne nakładają rygorystyczne limity na liczbę dozwolonych adresów MAC na porcie (tzw. port security) lub w chmurach publicznych, gdzie dostawca zabrania stosowania wielu adresów MAC na jednej maszynie wirtualnej. Ipvlan sprawia, że wszystkie wirtualne interfejsy współdzielą dokładnie ten sam adres MAC fizycznej karty sieciowej hosta, różniąc się wyłącznie adresami IP.

W trybie Ipvlan L2 jądro analizuje nagłówek ARP/IP i przekazuje ramkę do właściwej przestrzeni nazw. W trybie Ipvlan L3 stos sieciowy działa jak zoptymalizowany router jądra: ramki Ethernet nie zawierają zapytań ARP, a ruch jest trasowany bezpośrednio w warstwie 3, co eliminuje burze rozgłoszeniowe i zapewnia najwyższą możliwą wydajność przesyłania pakietów w architekturach mikrousług.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
VLAN (Virtual LAN) – logiczna sieć wirtualna wydzielona znacznikiem IEEE 802.1Q.

Przydatne łącza: Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Architektura sieciowa platformy Docker przeszła istotną ewolucję. We wczesnych wersjach silnika Docker (do wersji 1.6) cała konfiguracja sieciowa była bezpośrednio zaszyta w kodzie demona i ograniczała się do prostego zarządzania mostkiem docker0. W wersji 1.7 inżynierowie Dockera dokonali gruntownego refaktoringu, wydzielając podsystem sieciowy do niezależnego, otwartego projektu libnetwork, napisanego w języku Go.

Biblioteka libnetwork sformalizowała architekturę sieci kontenerowych za pomocą specyfikacji CNM (Container Network Model). W modelu tym wprowadzono rygorystyczny podział ról:

• Sandbox: odpowiada za izolację interfejsów, tablic routingu i reguł zapory ogniowej. W Linuksie reprezentuje go linuksowa przestrzeń nazw sieci (network namespace);
• Endpoint: stanowi abstrakcję wirtualnej karty sieciowej. Endpoint może być w danym momencie przypisany do dokładnie jednego Sandboxa oraz dokładnie jednej Sieci, odpowiadając za translację adresacji i zabezpieczenia portu;
• Network: reprezentuje logiczną podsieć składającą się z wielu endpointów, które mogą wymieniać między sobą pakiety. Siecią może być lokalny mostek linuksowy (Linux bridge), logiczny segment VLAN 802.1Q lub rozproszona sieć nakładkowa VXLAN rozciągająca się na setki serwerów fizycznych.

Dzięki architekturze opartej na sterownikach (ang. pluggable drivers), Docker pozwala na transparentną zmianę technologii sieciowej bez jakichkolwiek modyfikacji w kodzie uruchamianej aplikacji. Ten sam obraz kontenera może zostać uruchomiony w trybie pełnej izolacji (none), współdzielić porty z serwerem bazowym (host), komunikować się przez lokalny mostek (bridge), czy stać się częścią globalnej sieci rozproszonej w klastrze Docker Swarm (overlay).

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.
VLAN (Virtual LAN) – logiczna sieć wirtualna wydzielona znacznikiem IEEE 802.1Q.

Przydatne łącza: Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Tryb sieciowy none (aktywowany za pomocą flagi --network none lub --net=none) jest najbardziej restrykcyjnym trybem uruchomieniowym w środowisku Docker. Z inżynierskiego punktu widzenia demon Docker tworzy dla kontenera nową, autonomiczną przestrzeń nazw sieci (network namespace), lecz nie przypina do niej żadnych interfejsów zewnętrznych ani wirtualnych par VETH.

Jedynym interfejsem obecnym w przestrzeni kontenera jest wirtualny interfejs pętli zwrotnej (lo), który Docker automatycznie podnosi do stanu administracyjnego UP i przypisuje mu standardowy adres 127.0.0.1/8 oraz ::1/128. Oznacza to, że procesy wewnątrz kontenera mogą komunikować się wyłącznie ze sobą w ramach gniazd lokalnych (Unix domain sockets lub lokalne porty TCP/UDP 127.0.0.1).

Kontener działający w trybie none posiada całkowicie pustą tablicę routingu: brak w niej jakiejkolwiek trasy domyślnej (default gateway), a próba nawiązania połączenia z jakimkolwiek zewnętrznym adresem IP kończy się natychmiastowym błędem systemowym ENETUNREACH (Network is unreachable) wygenerowanym na poziomie jądra bez wysyłania jakichkolwiek pakietów.

W inżynierii cyberbezpieczeństwa tryb ten implementuje wzorzec cyfrowego odizolowania (air-gapped container). Wykorzystuje się go powszechnie w potokach CI/CD do podpisywania kodu źródłowego kluczami prywatnymi, kompresji i szyfrowania wrażliwych kopii zapasowych baz danych czy wstępnej analizy próbek złośliwego oprogramowania w środowiskach typu Sandbox, gdzie fizyczna niemożność wysłania pakietu poza przestrzeń kontenera stanowi najpewniejszą gwarancję szczelności systemu.

Wyjaśnienie skrótów i pojęć:
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
Docker bridge – domyślna sieć kontenerów z NAT i wirtualnym mostem docker0.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Tryb sieciowy host (definiowany za pomocą flagi --network host lub --net=host) reprezentuje skrajne podejście optymalizacyjne. W tym trybie silnik Docker całkowicie rezygnuje z tworzenia nowej przestrzeni nazw sieci (CLONE_NEWNET). Procesy kontenera są uruchamiane bezpośrednio w głównej przestrzeni sieciowej hosta (init_net), współdzieląc z nim wszystkie interfejsy fizyczne, wirtualne, tablice routingu, reguły zapory oraz tablice deskryptorów gniazd.

Z punktu widzenia wydajnościowego jest to rozwiązanie bezkonkurencyjne. Pakiety sieciowe przychodzące na fizyczną kartę sieciową serwera trafiają bezpośrednio do bufora aplikacji w kontenerze, bez pośrednictwa mostka docker0, wirtualnych par Ethernet (VETH) oraz reguł translacji DNAT w podsystemie Netfilter. Eliminuje to narzut związany z przełączaniem kontekstów pamięciowych i alokacją struktur sk_buff, co czyni ten tryb idealnym wyborem dla aplikacji o skrajnych wymaganiach przepustowości (np. brokery komunikatów Kafka, klastry Elasticsearch, serwery DNS dużej skali czy systemy telekonferencyjne WebRTC).

Ceną za tę wydajność jest jednak całkowita rezygnacja z izolacji warstwy L3/L4. Wszystkie porty otwierane przez proces w kontenerze są natychmiast bindowane na interfejsach hosta. Oznacza to, że flaga publikowania portów -p <host_port>:<container_port> staje się bezużyteczna i jest ignorowana przez Dockera z ostrzeżeniem. Jeśli na serwerze uruchomimy dwa kontenery Nginx w trybie host, drugi proces ulegnie awarii z powodu błędu bind: address already in use.

Z perspektywy bezpieczeństwa tryb host niesie ze sobą istotne ryzyko. Jeżeli kontener zostanie uruchomiony z uprawnieniami roota lub dodatkowymi uprawnieniami Linuksa (np. CAP_NET_ADMIN, CAP_NET_RAW), uzyskuje możliwość rekonfiguracji tras routingu hosta, kasowania interfejsów sieciowych, modyfikowania globalnych reguł iptables, a nawet podsłuchiwania ruchu innych procesów serwera w trybie promiscuous.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
DNAT (Destination NAT) – translacja adresu docelowego stosowana przy publikowaniu portów kontenerów.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Domyślny sterownik mostka (bridge) w Dockerze reprezentuje najbardziej rozpowszechniony wzorzec sieciowy pojedynczego węzła. Zapewnia on doskonały kompromis pomiędzy elastycznością konfiguracyjną, pełną separacją środowisk uruchomieniowych a łatwością wdrożenia. Każdy nowo uruchamiany kontener, o ile administrator jawnie nie wskaże innej sieci flagą --network, staje się węzłem w prywatnej podsieci mostka docker0.

Połączenie między kontenerem a mostkiem realizuje omówiona w poprzednich modułach para wirtualnych interfejsów VETH. W momencie uruchomienia kontenera demon Docker wykonuje sekwencję niskopoziomowych operacji:

• Inicjalizuje nową przestrzeń nazw sieci dla kontenera (reprezentowaną przez deskryptor w przestrzeni jądra);
• Wywołuje API Netlink w celu stworzenia pary VETH (np. vethXXXXXXXX na hoście oraz końcówki tymczasowej);
• Przenosi jeden koniec pary do przestrzeni kontenera, zmienia jego nazwę systemową na standardową eth0, nadaje wyliczony adres IP z puli mostka i podnosi interfejs oraz interfejs pętli zwrotnej lo;
• Drugi koniec (który na hoście zachowuje unikalną, wygenerowaną nazwę rozpoczynającą się od prefiksu veth) podłącza do mostka docker0 dyrektywą master docker0 i podnosi do stanu UP;
• Wpisuje do tablicy routingu kontenera trasę domyślną default via 172.17.0.1 dev eth0.

Dzięki temu kontener staje się pełnoprawnym urządzeniem w wirtualnej podsieci Ethernet. Kontenery podłączone do docker0 mogą przesyłać między sobą ramki L2 bezpośrednio przez mostek, natomiast ich ruch na zewnątrz hosta jest transparentnie maskowany przez reguły zapory ogniowej Netfilter.

Warto dodać, że parametry pracy mostka docker0 można weryfikować w wirtualnym systemie plików sysfs pod ścieżką /sys/class/net/docker0/bridge/. Znajdują się tam parametry sterujące czasem wygaszania wpisów w tablicy FDB (ageing_time), obsługa protokołu drzewa rozpinającego STP (domyślnie stp_state 0 z racji prostej topologii gwiazdy) oraz parametry multicast snooping. Taka organizacja gwarantuje wysoką przepustowość przesyłania pakietów przy minimalnym narzucie obliczeniowym.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.
Docker bridge – domyślna sieć kontenerów z NAT i wirtualnym mostem docker0.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Mostek docker0 jest tworzony automatycznie przy pierwszym uruchomieniu usługi dockerd. Demon Dockera sprawdza dostępne podsieci prywatne w oparciu o specyfikację RFC 1918 i standardowo wybiera pulę 172.17.0.0/16. Adres 172.17.0.1 zostaje przypisany do samego urządzenia mostka, stając się domyślną bramą sieciową dla wszystkich uruchamianych kontenerów.

Jednym z najczęstszych problemów wdrożeniowych w sieciach korporacyjnych jest kolizja adresacji. Jeśli wewnętrzna sieć LAN przedsiębiorstwa (lub firmowy tunel VPN) korzysta z zakresu 172.17.0.0/16, stacje robocze i serwery po zainstalowaniu Dockera tracą łączność z firmowymi zasobami. Dzieje się tak, ponieważ jądro Linuksa preferuje trasę lokalną (directly connected route) na interfejsie docker0 nad trasami zewnętrznymi przez fizyczną bramę.

Profesjonalnym rozwiązaniem tego problemu jest jawna rekonfiguracja parametrów mostka za pomocą pliku konfiguracyjnego /etc/docker/daemon.json. Dyrektywa bip (Bridge IP) pozwala na wskazanie całkowicie bezpiecznej, bezkolizyjnej puli adresowej (np. 192.168.200.1/24 lub 10.240.0.1/24). Po zrestartowaniu demona (systemctl restart docker), Docker automatycznie niszczy stary mostek i tworzy nowy z zadaną adresacją.

Warto także zwrócić uwagę na parametr mtu. Jeśli host łączy się z Internetem przez łącze PPPoE (MTU 1492) lub tunel VPN z enkapsulacją (np. WireGuard, IPsec, VXLAN o MTU 1420), ustawienie odpowiednio niższego MTU w daemon.json zapobiega problemom z fragmentacją pakietów TCP i cichym zrywaniem sesji SSL/TLS wewnątrz kontenerów.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.
Docker bridge – domyślna sieć kontenerów z NAT i wirtualnym mostem docker0.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

W standardowej konfiguracji silnika Docker komunikacja pomiędzy kontenerami podłączonymi do tego samego mostka odbywa się w czystej warstwie łącza danych (L2). Pakiety wysyłane z kontenera c1 do kontenera c2 trafiają przez wirtualny interfejs VETH do mostka docker0 w pamięci RAM, a stamtąd na podstawie tablicy FDB bezpośrednio do interfejsu drugiego kontenera. Ruch ten nie wymaga routingu L3 ani translacji NAT na poziomie hosta.

Z punktu widzenia bezpieczeństwa sieciowego takie zachowanie może stanowić istotne zagrożenie w środowiskach współdzielonych (ang. multi-tenant). W sytuacji, gdy jeden z kontenerów zostanie przełamany przez intruza, napastnik uzyskuje możliwość swobodnego skanowania portów (port scanning) i atakowania pozostałych kontenerów pracujących na tym samym mostku.

Aby temu zapobiec, specyfikacja Dockera udostępnia mechanizm ICC (Inter-Container Communication). Po skonfigurowaniu w daemon.json opcji "icc": false, demon Docker modyfikuje reguły w tabeli filter podsystemu Netfilter. Zamiast domyślnej akceptacji pakietów przesyłanych wewnątrz mostka, instalowana jest reguła blokująca:

iptables -A FORWARD -i docker0 -o docker0 -j DROP

W rezultacie kontenery zostają całkowicie od siebie odizolowane w warstwie logicznej: każdy kontener zachowuje możliwość wysyłania ruchu do Internetu oraz odbierania połączeń na swoich opublikowanych portach, lecz żadna bezpośrednia wymiana pakietów między kontenerami nie jest możliwa. W nowoczesnych architekturach zaleca się jednak realizację separacji poprzez tworzenie niezależnych sieci definiowanych przez użytkownika (user-defined networks) zamiast manipulacji globalną flagą ICC na mostku domyślnym.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.
Docker bridge – domyślna sieć kontenerów z NAT i wirtualnym mostem docker0.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Interfejs wiersza poleceń rodziny docker network stanowi kompleksowe narzędzie orkiestracji wirtualnych sieci w środowisku Docker. Umożliwia ono administratorom dynamiczne powoływanie do życia nowych podsieci, modyfikację trasowania, inspekcję adresacji oraz zarządzanie punktami końcowymi (endpoints) bez konieczności restartowania demona Dockera ani maszyn bazowych.

Podczas tworzenia nowej sieci za pomocą docker network create, Docker alokuje nową podsieć w swoim wewnętrznym module IPAM (IP Address Management). Administrator może precyzyjnie kontrolować parametry podsieci za pomocą flag --subnet, --gateway, --ip-range (ograniczenie zakresu puli dynamicznej) oraz --aux-address (rezerwacja statycznych adresów IP). W strukturach jądra Linuksa powoływany jest wówczas nowy mostek sieciowy o unikalnej nazwie rozpoczynającej się prefiksem br-, po którym następuje 12 pierwszych znaków skrótu SHA256 identyfikatora sieci (np. br-4a5f8e9c1d20).

Niezwykle potężną funkcją jest polecenie docker network connect. Pozwala ono na podłączenie działającego kontenera do nowej sieci w czasie rzeczywistym. W procedurze tej demon Docker tworzy w jądrze nową parę interfejsów VETH, wprowadza jeden koniec do istniejącej przestrzeni nazw (Sandbox) kontenera pod kolejną nazwą (np. eth1), przydziela adres IP z nowej podsieci, a drugi koniec wpina do odpowiedniego mostka sieciowego. Aplikacja w kontenerze zyskuje natychmiast łączność z kolejnym segmentem sieci bez przerywania pracy bieżących procesów.

Z kolei inspekcja docker network inspect <sieć> udostępnia kompletny zrzut stanu w formacie JSON, prezentując dokładną konfigurację sterownika, parametry IPAM, listę wszystkich podłączonych kontenerów wraz z ich adresami IPv4, IPv6 i adresami MAC, a także specyficzne opcje sterownika (driver options), co stanowi nieocenioną pomoc w procesach automatyzacji i audytu infrastruktury.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.
Docker bridge – domyślna sieć kontenerów z NAT i wirtualnym mostem docker0.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Koncepcja sieci zdefiniowanych przez użytkownika (user-defined networks) stanowi jeden z najważniejszych filarów nowoczesnej orkiestracji aplikacji w środowisku Docker. Rozwiązuje ona fundamentalny problem domyślnego mostka docker0, w którym wszystkie uruchamiane kontenery trafiały do jednej, wspólnej przestrzeni adresowej, uniemożliwiając logiczną separację mikroserwisów i utrudniając automatyzację.

Najważniejszą innowacją wprowadzoną w sieciach użytkownika jest wbudowany serwer DNS (ang. embedded DNS resolver). W momencie powołania kontenera w sieci zdefiniowanej przez użytkownika, demon Docker wpisuje do pliku /etc/resolv.conf kontenera adres serwera nazw nameserver 127.0.0.11. Pod tym adresem jądro (za pośrednictwem dedykowanych reguł iptables przekierowujących ruch na losowy port przestrzeni użytkownika) udostępnia instancję lokalnego resolvera DNS zarządzanego przez libnetwork.

Mechanizm ten umożliwia automatyczne wykrywanie usług (Service Discovery). Gdy aplikacja frontendowa próbuje połączyć się z bazą danych pod nazwą db-cluster, lokalny serwer DNS Dockera dynamicznie odpowiada aktualnym adresem IP kontenera o tej nazwie. Co więcej, w przypadku uruchomienia wielu kontenerów o tym samym aliasie sieciowym (network alias), DNS Dockera realizuje prosty mechanizm równoważenia obciążenia Round-Robin, zwracając listę adresów IP w zmiennej kolejności.

Drugą fundamentalną zaletą jest izolacja domyślna. Mostki definiowane przez użytkownika posiadają w podsystemie Netfilter automatycznie generowane reguły w łańcuchu DOCKER-ISOLATION-STAGE-1 oraz DOCKER-ISOLATION-STAGE-2. Reguły te gwarantują, że żaden pakiet z sieci np. frontend-net nie przedostanie się do sieci backend-net, chyba że dany kontener zostanie jawnie podłączony do obu tych sieci jednocześnie.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.
Docker bridge – domyślna sieć kontenerów z NAT i wirtualnym mostem docker0.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Wraz z przejściem z pojedynczego serwera do rozproszonych klastrów kontenerowych (takich jak Docker Swarm, Nomad czy Kubernetes) pojawia się wyzwanie komunikacji wielowęzłowej (ang. multi-host networking). W takim scenariuszu lokalny mostek linuksowy nie jest wystarczający, ponieważ jego domena L2 kończy się na pamięci RAM danego hosta.

Odpowiedzią na to wyzwanie jest sieć nakładkowa (Overlay Network) zaimplementowana w sterowniku overlay. Technologia ta opiera się na standardzie RFC 7348 – VXLAN (Virtual eXtensible Local Area Network). Mechanizm VXLAN tworzy wirtualny interfejs tunelowy VTEP (VXLAN Tunnel Endpoint). Gdy kontener wysyła ramkę Ethernet do innego kontenera zlokalizowanego na odległym serwerze, interfejs VTEP pobiera całą ramkę L2, dokłada nagłówek VXLAN zawierający 24-bitowy identyfikator VNI (co pozwala na utworzenie do 16 milionów niezależnych sieci wirtualnych) i enkapsuluje całość w standardowy datagram UDP kierowany na port 4789 węzła docelowego.

Do zarządzania dystrybucją informacji o lokalizacji poszczególnych kontenerów i ich adresów MAC niezbędna jest inteligentna płaszczyzna sterowania (Control Plane). W ekosystemie Docker Swarm zadanie to realizuje wewnętrzny, szyfrowany protokół Gossip (rozproszony rejestr stanu). Z kolei w zaawansowanych sieciach operatorskich i centrach danych standardem stało się połączenie VXLAN z protokołem EVPN / BGP (Ethernet VPN z protokołem Border Gateway Protocol, zdefiniowane w RFC 7432 oraz RFC 8365). W tym modelu węzły sieciowe wymieniają informacje o dostępnych trasach i adresach MAC za pośrednictwem protokołu BGP, eliminując konieczność zalewania sieci zapytaniami rozgłoszeniowymi (flood-and-learn).

Gdy natomiast celem inżyniera jest ominięcie jakiejkolwiek enkapsulacji tunelowej ze względów wydajnościowych, sterowniki macvlan oraz ipvlan pozwalają na wpięcie kontenera bezpośrednio do fizycznej infrastruktury przełączników fabrycznych lub segmentów VLAN 802.1Q.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VLAN (Virtual LAN) – logiczna sieć wirtualna wydzielona znacznikiem IEEE 802.1Q.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Podsumowując analizę podstawowych architektur sieciowych Dockera, należy jednoznacznie sformułować regułę inżynierską: w profesjonalnych środowiskach produkcyjnych używanie domyślnego mostka docker0 jest poważnym błędem architektonicznym. Mostek docker0 powstał jako rozwiązanie ułatwiające natychmiastowe rozpoczęcie pracy z Dockerem (tzw. out-of-the-box experience), lecz posiada wady, które dyskwalifikują go z zastosowań korporacyjnych.

Podstawowym mankamentem jest brak automatycznego rozpoznawania nazw (Service Discovery) przez wbudowany serwer DNS. Kontenery podłączone do docker0 muszą odwoływać się do siebie po surowych adresach IP, które są przydzielane dynamicznie w kolejności startu kontenerów. W efekcie jakikolwiek restart usługi (np. kontenera bazy danych) powoduje zmianę jego adresu IP i zerwanie łączności ze wszystkimi powiązanymi mikroserwisami. Historyczny mechanizm --link, który dopisywał statyczne wpisy do pliku /etc/hosts, jest oficjalnie uznany za przestarzały (deprecated), nie radzi sobie z restartami i nie skaluje się poza pojedynczy węzeł.

Drugim istotnym czynnikiem jest bezpieczeństwo. W mostku docker0 wszystkie kontenery współdzielą tę samą domenę rozgłoszeniową. Jeśli na jednym serwerze hostujemy publiczny serwer WWW oraz wrażliwą wewnętrzną bazę danych, umieszczenie ich na wspólnym mostku docker0 sprawia, że skompromitowany serwer WWW może bez przeszkód monitorować ruch rozgłoszeniowy i atakować bazę danych. W sieciach definiowanych przez użytkownika możemy przypisać frontend do sieci dmz-net, bazę danych do data-net, a backendową aplikację pośredniczącą podłączyć do obu tych sieci, uzyskując wzorcową architekturę strefową.

Z tych względów nowoczesne wzorce wdrożeniowe (w tym narzędzia Docker Compose, Docker Swarm i orkiestratory chmurowe) automatycznie tworzą dedykowane sieci zdefiniowane przez użytkownika dla każdej wdrażanej aplikacji, całkowicie izolując ją od pozostałych procesów w systemie operacyjnym.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.
Docker bridge – domyślna sieć kontenerów z NAT i wirtualnym mostem docker0.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Mechanizm publikowania portów (ang. port publishing) za pomocą flagi -p lub --publish stanowi najpowszechniejszy sposób udostępniania usług kontenerowych dla użytkowników zewnętrznych oraz innych systemów w sieci LAN i WAN. Mimo pozornej prostoty składni -p <port_hosta>:<port_kontenera>, pod maską systemu operacyjnego uruchamiany jest wysoce wyrafinowany podsystem translacji adresów i przekazywania gniazd.

Gdy administrator wydaje polecenie uruchomienia serwera Nginx z opcją -p 8080:80, kontener otrzymuje swój prywatny adres IP na mostku docker0 (np. 172.17.0.2). Proces Nginx wewnątrz kontenera nasłuchuje na standardowym porcie 80. Sam adres 172.17.0.2 jest jednak adresem prywatnym, całkowicie niewidocznym i nieroutowalnym w zewnętrznej sieci przedsiębiorstwa. Aby umożliwić dostęp z zewnątrz, demon Docker musi przekierować pakiety trafiające na port 8080 hosta fizycznego bezpośrednio do kontenera.

Aby zapewnić bezbłędną obsługę ruchu ze wszystkich możliwych źródeł, Docker stosuje architekturę hybrydową opartą na dwóch niezależnych filarach:

1. Filtracja i translacja w jądrze (Netfilter / iptables): dla pakietów napływających z fizycznych kart sieciowych (interfejsy eth0, ens3 itp.) podsystem jądra dokonuje superszybkiej translacji docelowego adresu sieciowego (DNAT) w łańcuchu PREROUTING, kierując pakiety bezpośrednio na wirtualny port mostka w pamięci RAM bez angażowania procesów przestrzeni użytkownika;
2. Demon pośredniczący docker-proxy: w przestrzeni użytkownika demon Dockera uruchamia dedykowany proces pomocniczy docker-proxy dla każdego opublikowanego portu. Proces ten binuje się do zadanego portu na hoście. Choć w nowoczesnych wersjach jądra większość ruchu lokalnego jest również obsługiwana przez reguły iptables w łańcuchu OUTPUT, docker-proxy stanowi mechanizm asekuracyjny gwarantujący łączność w sytuacjach nietypowych oraz przy wyłączonym routingu pętli w jądrze.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
DNAT (Destination NAT) – translacja adresu docelowego stosowana przy publikowaniu portów kontenerów.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Zrozumienie działania mechanizmu DNAT (Destination Network Address Translation) w podsystemie Netfilter jądra Linuksa jest kluczem do opanowania zaawansowanej administracji sieciami kontenerowymi. Cały proces opiera się na precyzyjnym grafie przepływu pakietu przez łańcuchy i tabele zapory sieciowej.

Gdy zewnętrzny klient wysyła żądanie HTTP, pakiet dociera do fizycznego interfejsu serwera (np. eth0). Pierwszym punktem kontrolnym w jądrze jest łańcuch PREROUTING w tabeli nat. Docker umieszcza w nim regułę przekierowującą pakiety niepochodzące z mostka docker0 do dedykowanego łańcucha o nazwie DOCKER:

-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER

W łańcuchu DOCKER następuje właściwa reguła docelowa DNAT: -j DNAT --to-destination 172.17.0.2:80. W tym momencie jądro atomowo modyfikuje nagłówek IP, podmieniając adres docelowy hosta na prywatny adres kontenera, oraz nagłówek TCP, zmieniając port docelowy z 8080 na 80. Jednocześnie podsystem śledzenia połączeń (conntrack) rejestruje tę transakcję w swojej pamięci, aby automatycznie odwrócić translację dla pakietów powrotnych.

Zmieniony pakiet trafia do silnika routingu jądra. Ponieważ jego nowy adres docelowy (172.17.0.2) nie należy do samego hosta, lecz do podsieci mostka docker0, pakiet nie jest kierowany do łańcucha INPUT, lecz do łańcucha FORWARD. W tabeli filter łańcucha FORWARD Docker wstawia regułę akceptującą pakiety skierowane do mostka docker0 i portu kontenera:

-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o docker0 -j DOCKER

W rezultacie pakiet zostaje bez przeszkód przekazany przez mostek do właściwej pary VETH i dociera do serwera Nginx w kontenerze.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
DNAT (Destination NAT) – translacja adresu docelowego stosowana przy publikowaniu portów kontenerów.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Praktyczna analiza działania polecenia docker run -d -p 8080:80 nginx na poziomie jądra Linuksa pozwala zaobserwować ścisłą współpracę trzech kluczowych komponentów: demona dockerd, podsystemu iptables oraz modułu śledzenia stanów conntrack.

Zbadajmy szczegółowo wygenerowane reguły:

1. Reguła DNAT w tabeli nat: określa, że każdy przychodzący pakiet protokołu TCP skierowany na port 8080 dowolnego interfejsu hosta zostaje poddany translacji docelowej na adres 172.17.0.2:80. Reguła ta dotyczy wyłącznie pierwszego pakietu inicjującego połączenie (pakiet z flagą SYN). Gdy pierwszy pakiet przejdzie przez tabelę nat, podsystem conntrack tworzy wpis w swojej tablicy sesji i automatycznie aplikuje tę samą translację do wszystkich kolejnych pakietów w ramach tego strumienia TCP;
2. Reguła ACCEPT w tabeli filter: sam fakt wykonania translacji adresu w tabeli nat nie oznacza jeszcze, że pakiet zostanie przepuszczony przez zaporę sieciową hosta. Standardowa polityka łańcucha FORWARD na serwerach produkcyjnych to DROP. Dlatego Docker automatycznie dodaje jawną regułę zezwalającą w łańcuchu DOCKER tabeli filter: zezwól na ruch TCP kierowany do adresu 172.17.0.2 na port 80;
3. Reguła MASQUERADE w tabeli nat (POSTROUTING): jest to mechanizm translacji adresu źródłowego (SNAT). Gwarantuje on, że gdy kontener generuje odpowiedź na zapytanie zewnętrzne, a także gdy kontener sam inicjuje połączenie wychodzące do Internetu (np. pobierając pakiety z repozytorium), jego prywatny adres IP zostaje podmieniony na publiczny adres IP hosta.

Dzięki takiej trójstopniowej konstrukcji administrator uzyskuje pełną przezroczystość komunikacji: aplikacja w kontenerze nie musi wiedzieć nic o zewnętrznym adresie IP serwera, a klient zewnętrzny nie ma pojęcia o prywatnej strukturze sieciowej kontenera.

Wyjaśnienie skrótów i pojęć:
DNAT (Destination NAT) – translacja adresu docelowego stosowana przy publikowaniu portów kontenerów.
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Automatyczne zarządzanie zaporą sieciową przez demona Dockera stanowi miecz obosieczny. Z jednej strony uwalnia programistów i administratorów od mozolnego pisania niskopoziomowych reguł translacji adresów dla setek dynamicznie tworzonych kontenerów. Z drugiej strony wprowadza zjawisko, które jest jednym z najczęstszych źródeł incydentów bezpieczeństwa w środowiskach linuksowych: całkowite ominięcie standardowych mechanizmów zapory ogniowej hosta, takich jak UFW (Uncomplicated Firewall w systemach Ubuntu/Debian) czy Firewalld (w systemach RHEL/CentOS/Rocky Linux).

Przyczyną tego zachowania jest kolejność przetwarzania pakietów w architekturze Netfilter. Kiedy pakiet dociera do serwera, najpierw trafia do łańcucha PREROUTING w tabeli nat, gdzie reguły Dockera wykonują translację DNAT. W efekcie docelowy adres IP pakietu przestaje być adresem hosta, a staje się adresem kontenera (np. 172.17.0.2). Oznacza to, że pakiet nigdy nie trafia do łańcucha INPUT, w którym narzędzie UFW standardowo aplikuje reguły blokujące dla portów hosta!

Pakiet zostaje przekierowany bezpośrednio do łańcucha FORWARD. W łańcuchu FORWARD Docker umieszcza swój łańcuch DOCKER przed łańcuchami UFW (takimi jak ufw-user-forward). Ponieważ reguła Dockera w łańcuchu DOCKER bezwarunkowo akceptuje ruch z celem -j ACCEPT, pakiet zostaje natychmiast przepuszczony do kontenera, zanim jakakolwiek reguła UFW zdąży go przeanalizować.

Wielu nieświadomych administratorów przekonało się o tym w bolesny sposób, gdy po wykonaniu polecenia ufw deny 3306 baza danych MySQL uruchomiona w kontenerze z opcją -p 3306:3306 pozostała w pełni otwarta na ataki z całego globalnego Internetu. W kolejnych slajdach omówimy oficjalną, rekomendowaną przez inżynierów metodę zabezpieczania takich konfiguracji za pomocą łańcucha DOCKER-USER.

Wyjaśnienie skrótów i pojęć:
DNAT (Destination NAT) – translacja adresu docelowego stosowana przy publikowaniu portów kontenerów.
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Biegła inspekcja reguł podsystemu Netfilter jest podstawową umiejętnością każdego inżyniera utrzymującego środowiska kontenerowe. Narzędzie iptables z odpowiednimi flagami pozwala na natychmiastowe zidentyfikowanie przyczyn braku łączności, wąskich gardeł wydajnościowych oraz luk w konfiguracji zapory sieciowej.

Zawsze zaleca się stosowanie flagi -n (numeric) w połączeniu z flagą -v (verbose) oraz -L (list): iptables -nvL. Pominięcie flagi -n zmusza program do prób rozwiązywania każdego adresu IP i numeru portu na nazwy domenowe (reverse DNS), co w przypadku braku odpowiedzi serwera DNS zawiesza działanie terminala na kilkadziesiąt sekund. Z kolei flaga -v udostępnia kluczowe metadane:

• Licznik pakietów (pkts): pozwala sprawdzić, czy jakikolwiek pakiet w ogóle dopasował się do danej reguły;
• Licznik wolumenu danych (bytes): wskazuje ilość przesłanych danych w bajtach;
• Interfejsy źródłowe i docelowe (in / out): precyzują, na których urządzeniach sieciowych (np. eth0 czy docker0) reguła jest ewaluowana.

Niezwykle cennym uzupełnieniem polecenia iptables jest narzędzie conntrack (wchodzące w skład pakietu conntrack-tools). Podczas gdy iptables prezentuje statyczną listę reguł, conntrack -L odpytuje jądro o dynamiczny stan tablicy śledzenia połączeń. Wyświetla ono dokładne stany asocjacji TCP (SYN_SENT, ESTABLISHED, TIME_WAIT), krotki adresowe pakietów pierwotnych oraz odpowiadające im krotki pakietów przetłumaczonych przez DNAT/SNAT.

W przypadku nowoczesnych dystrybucji Linuksa korzystających z podsystemu nftables jako backendu (np. Debian 11/12, Ubuntu 22.04/24.04), polecenia iptables są transparentnie mapowane przez warstwę translacji iptables-nft. Administrator może również dokonać bezpośredniej inspekcji reguł za pomocą natywnego polecenia nft list ruleset.

Wyjaśnienie skrótów i pojęć:
DNAT (Destination NAT) – translacja adresu docelowego stosowana przy publikowaniu portów kontenerów.
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Architektura łańcuchów zapory ogniowej w środowisku Docker została zaprojektowana w sposób modularny, aby rozdzielić automatyczne operacje demona od polityk bezpieczeństwa definiowanych przez administratora systemu operacyjnego. Zrozumienie relacji między łańcuchami FORWARD, DOCKER-USER oraz DOCKER jest kluczowe dla poprawnego zabezpieczenia serwera.

W tabeli filter łańcuch FORWARD jest skonfigurowany w następującej sekwencji:

Chain FORWARD (policy DROP)
target         prot opt source       destination
DOCKER-USER    all  --  0.0.0.0/0    0.0.0.0/0
DOCKER-ISOLATION-STAGE-1 all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT         all  --  0.0.0.0/0    0.0.0.0/0    ctstate RELATED,ESTABLISHED
DOCKER         all  --  0.0.0.0/0    0.0.0.0/0
ACCEPT         all  --  0.0.0.0/0    0.0.0.0/0    (ruch z mostka na zewnątrz)

Zwróćmy uwagę na pozycję łańcucha DOCKER-USER: znajduje się on na samej górze łańcucha FORWARD, przed wszystkimi regułami wygenerowanymi przez Dockera. Oznacza to, że każdy pakiet zmierzający do jakiegokolwiek kontenera (niezależnie od tego, czy port został opublikowany opcją -p, czy nie) musi najpierw przejść przez reguły zdefiniowane w DOCKER-USER.

Domyślnie łańcuch DOCKER-USER zawiera jedynie regułę powrotu RETURN, która przekazuje ewaluację pakietu do kolejnych reguł Dockera. Jeśli jednak administrator umieści w nim regułę odrzucającą (DROP lub REJECT), pakiet zostanie zablokowany natychmiast i nigdy nie dotrze do łańcucha DOCKER. Co najważniejsze, demon Dockera podczas restartu, aktualizacji sieci czy uruchamiania nowych kontenerów nigdy nie usuwa ani nie modyfikuje wpisów w łańcuchu DOCKER-USER. Stanowi on jedyny stabilny, udokumentowany i zalecany przez twórców Dockera mechanizm implementacji zewnętrznych polityk bezpieczeństwa sieciowego.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
DNAT (Destination NAT) – translacja adresu docelowego stosowana przy publikowaniu portów kontenerów.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Precyzyjna kontrola adresów IP, do których dowiązywane są publikowane porty kontenerów, stanowi fundament twardnienia środowisk produkcyjnych (ang. security hardening). Domyślne zachowanie Dockera, polegające na przypisywaniu portu do adresu uniwersalnego 0.0.0.0 (oraz [::] dla IPv6), jest wygodne w fazie prototypowania, lecz skrajnie niebezpieczne w środowiskach serwerowych podłączonych do sieci publicznej.

Gdy w opcji -p określimy jawny adres IP hosta, np. -p 127.0.0.1:8080:80, Docker generuje regułę DNAT z dodatkowym, restrykcyjnym warunkiem dopasowania docelowego adresu IP:

-A DOCKER -d 127.0.0.1/32 ! -i docker0 -p tcp -m tcp --dport 8080 -j DNAT --to-destination 172.17.0.2:80

Oznacza to, że pakiet przychodzący z fizycznego interfejsu eth0 (posiadającego publiczny adres IP) nie spełni warunku -d 127.0.0.1 i reguła DNAT nie zostanie dla niego zaaplikowana. Pakiet zostanie przekazany do standardowego łańcucha INPUT hosta i odrzucony przez lokalną zaporę ogniową.

Jest to wzorzec architektoniczny o kluczowym znaczeniu przy wdrażaniu wielowarstwowych aplikacji webowych. W takim modelu kontenery aplikacji backendowych oraz bazy danych bindowane są wyłącznie do adresu 127.0.0.1. Jedyną usługą wystawioną na interfejs publiczny 0.0.0.0:443 jest serwer Reverse Proxy (np. Nginx, HAProxy lub Envoy), który po zakończeniu sesji TLS i walidacji nagłówków HTTP bezpiecznie przekazuje żądania do lokalnego portu 127.0.0.1:8080.

Jeśli natomiast konieczne jest udostępnienie usługi dla wąskiego grona administratorów bez dedykowanego reverse proxy, idealnym rozwiązaniem jest dodanie reguły w łańcuchu DOCKER-USER. Przykładowo, polecenie iptables -I DOCKER-USER -i eth0 ! -s 10.0.0.0/8 -j DROP natychmiast odetnie wszelki ruch do wszystkich kontenerów pochodzący spoza firmowej sieci korporacyjnej.

Wyjaśnienie skrótów i pojęć:
DNAT (Destination NAT) – translacja adresu docelowego stosowana przy publikowaniu portów kontenerów.
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Wielu początkujących adeptów konteneryzacji myli rolę instrukcji EXPOSE w pliku Dockerfile z rzeczywistym publikowaniem portów w systemie operacyjnym hosta. Należy wyraźnie podkreślić: umieszczenie dyrektywy EXPOSE 80/tcp w kodzie obrazu nie powoduje wygenerowania żadnych reguł w iptables ani nie otwiera portu na zewnątrz. Jest to wyłącznie informacja metadanych w nagłówku obrazu (format OCI/Docker), informująca ludzi i narzędzia automatyzacji, na których portach aplikacja w kontenerze standardowo oczekuje na połączenia.

Jedynym mechanizmem, który bezpośrednio korzysta z metadanych EXPOSE, jest flaga -P (wielka litera P, synonim --publish-all). Po jej podaniu demon Docker odczytuje listę portów zadeklarowanych w obrazie przez instrukcję EXPOSE i dla każdego z nich wykonuje procedurę automatycznej alokacji portu hosta.

Port hosta jest wybierany pseudolosowo z tzw. puli portów ulotnych (ang. ephemeral ports), zdefiniowanej w parametrze jądra Linuksa /proc/sys/net/ipv4/ip_local_port_range (standardowo zakres od 32768 do 60999). Przykładowo, kontener serwera Nginx deklarujący EXPOSE 80 może po wykonaniu docker run -d -P nginx zostać opublikowany na porcie 32769. Aktualne przypisanie należy każdorazowo sprawdzić poleceniem docker port <kontener>.

Flaga -P jest niezwykle przydatna w środowiskach testowych oraz w systemach automatycznego testowania integracyjnego (gdzie równolegle uruchamia się dziesiątki instancji tego samego kontenera i nie wolno dopuścić do kolizji portów hosta). W środowiskach produkcyjnych stosuje się jednak wyłącznie flagę -p, która zapewnia pełną deterministyczność numeracji portów oraz stabilność konfiguracji zewnętrznych systemów równoważenia obciążenia i zapór sieciowych.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.
Docker bridge – domyślna sieć kontenerów z NAT i wirtualnym mostem docker0.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Ćwiczenie laboratoryjne zostało zaprojektowane zgodnie z akademicką zasadą nauki przez dekonstrukcję (learning by deconstruction). Zamiast ograniczać się do wydawania wysokopoziomowych poleceń Dockera, uczestnik wciela się w rolę twórcy silnika kontenerowego i odtwarza krok po kroku wszystkie operacje, które demon dockerd wykonuje w przestrzeni jądra podczas uruchamiania kontenera z siecią typu bridge.

Taki model warsztatu posiada fundamentalną wartość edukacyjną i diagnostyczną. Administrator, który własnoręcznie połączy dwie przestrzenie nazw kablem VETH, zepnie je mostkiem br0, uruchomi forwarding w sysctl i napisze reguły DNAT w iptables, przestaje postrzegać sieć Dockera jako nieprzeniknioną magię. W sytuacji rzeczywistej awarii produkcyjnej inżynier ten potrafi bezbłędnie zlokalizować, na którym etapie nastąpiło przerwanie łączności: czy zawiódł stan interfejsu, czy tablica FDB mostka, czy brak trasy powrotnej, czy błąd w dopasowaniu reguły Netfilter.

Środowisko laboratoryjne opiera się wyłącznie na standardowych komponentach dostępnych w każdej nowoczesnej dystrybucji Linuksa (Ubuntu, Debian, RHEL, AlmaLinux, Arch). Nie wymaga instalacji żadnego zewnętrznego oprogramowania wirtualizacyjnego. Wszystkie tworzone obiekty (przestrzenie ns1/ns2, mostek br0, pary interfejsów VETH) istnieją wyłącznie w pamięci operacyjnej i mogą zostać w każdej chwili bez śladu usunięte jednym poleceniem lub poprzez zwykły restart systemu.

Zaleca się realizację ćwiczenia w dwóch oknach terminala: w pierwszym wykonujemy polecenia konfiguracyjne, natomiast w drugim uruchamiamy narzędzie tcpdump -i any -n lub bridge monitor fdb, aby w czasie rzeczywistym obserwować zachowanie jądra Linuksa w odpowiedzi na wprowadzane zmiany.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
DNAT (Destination NAT) – translacja adresu docelowego stosowana przy publikowaniu portów kontenerów.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

W pierwszym kroku naszego laboratorium tworzymy fundamenty topologii sieciowej. Polecenia sudo ip netns add ns1 oraz sudo ip netns add ns2 wywołują w jądrze alokację dwóch niezależnych struktur sieciowych (struct net). W tym momencie przestrzenie ns1 i ns2 są całkowicie puste i odizolowane od świata zewnętrznego oraz od siebie nawzajem. Posiadają jedynie wyłączony interfejs pętli zwrotnej lo.

Następnie powołujemy do życia centralny punkt węzłowy naszej wirtualnej sieci LAN: wirtualny mostek sieciowy br0. Wykonanie polecenia sudo ip link add name br0 type bridge tworzy w głównej przestrzeni hosta (init_net) programowy przełącznik warstwy 2. Mostek ten będzie pełnił dokładnie taką samą rolę, jaką w standardowym środowisku kontenerowym pełni domyślny mostek docker0.

Kluczowym elementem konfiguracji mostka jest nadanie mu adresu IP w warstwie L3: 192.168.100.1/24. Adres ten zdefiniuje podsieć wirtualną dla naszych przyszłych kontenerów i posłuży im jako adres bramy domyślnej (default gateway). Na tym etapie do mostka nie jest jeszcze podłączony żaden port podrzędny (slave), dlatego w statystykach jądra interfejs br0 może zgłaszać stan NO-CARRIER. Jest to zachowanie w pełni poprawne – mostek przejdzie w stan LOWER_UP w momencie, gdy podłączymy do niego pierwszy aktywny interfejs wirtualny w kolejnym kroku laboratorium.

Warto zwrócić uwagę na czystość i elegancję tego podejścia: w zaledwie czterech poleceniach wiersza poleceń powołaliśmy do życia dwa niezależne komputery wirtualne oraz dedykowany przełącznik sieciowy z funkcją routingu, bez alokacji megabajtów pamięci dyskowej i bez uruchamiania ciężkich procesów wirtualizacji sprzętowej.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.
Docker bridge – domyślna sieć kontenerów z NAT i wirtualnym mostem docker0.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

W drugim kroku ćwiczenia laboratoryjnego przystępujemy do fizycznego – w sensie wirtualnym – okablowania naszej infrastruktury. Mostek br0 powołany w kroku pierwszym jest na razie pustym przełącznikiem, a przestrzenie ns1 i ns2 nie posiadają żadnych urządzeń zewnętrznych. Do ich połączenia wykorzystujemy dwie wirtualne pary interfejsów Ethernet (VETH).

Zwróćmy uwagę na precyzyjną metodykę nazewnictwa: dla pierwszej przestrzeni tworzymy parę veth1 oraz veth1-br. Końcówka veth1 zostaje za pomocą polecenia ip link set veth1 netns ns1 wprowadzona do przestrzeni wirtualnego kontenera. W tym momencie następuje atomowa zmiana przestrzeni jądra: interfejs znika z widoku głównego hosta i staje się widoczny wyłącznie wewnątrz ns1.

Druga końcówka pary, czyli veth1-br, pozostaje w przestrzeni hosta i zostaje przypięta do mostka br0 za pomocą klauzuli master br0. Dokładnie tę samą procedurę powtarzamy dla przestrzeni ns2 z parą veth2 i veth2-br. W ten sposób powstaje klasyczna topologia gwiazdy (wzorzec L2 star topology).

Bardzo ważnym detalem technicznym jest podniesienie interfejsów po stronie hosta: ip link set dev veth1-br up. Urządzenia VETH po utworzeniu znajdują się w stanie DOWN. Dopóki oba końce danej pary nie zostaną podniesione do stanu UP, jądro nie pozwoli na transmisję żadnych ramek Ethernet. Wykonanie polecenia bridge link show pozwala administratorowi zweryfikować, że oba porty (veth1-br i veth2-br) są poprawnie zarejestrowane w mostku br0 i znajdują się w stanie przekazywania (forwarding state).

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.
Docker bridge – domyślna sieć kontenerów z NAT i wirtualnym mostem docker0.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

W trzecim etapie laboratorium przystępujemy do konfiguracji warstwy sieciowej (L3) wewnątrz wykreowanych przestrzeni nazw. W tym celu korzystamy ze składni ip -n <nazwa_przestrzeni>, która jest zwięzłym i eleganckim odpowiednikiem polecenia ip netns exec <nazwa_przestrzeni> ip ....

Procedura konfiguracji każdego wirtualnego kontenera obejmuje cztery krytyczne operacje inżynierskie:

1. Przypisanie adresu IP z maską podsieci: nadajemy odpowiednio 192.168.100.11/24 w ns1 oraz 192.168.100.12/24 w ns2. Jądro Linuksa natychmiast generuje w lokalnej tablicy routingu trasę do podsieci bezpośrednio połączonej (192.168.100.0/24 dev vethX proto kernel scope link);
2. Podniesienie interfejsu sieciowego: zmiana stanu na UP sprawia, że interfejs weryfikuje obecność partnera po drugiej stronie kabla wirtualnego VETH i przechodzi w stan operacyjny LOWER_UP;
3. Podniesienie interfejsu pętli zwrotnej (lo): jest to krok, o którym niezwykle często zapominają początkujący administratorzy. W nowej przestrzeni nazw interfejs lo jest domyślnie wyłączony. Jego podniesienie jest bezwzględnie wymagane, aby procesy lokalne mogły komunikować się po adresie 127.0.0.1 oraz przez gniazda IPC;
4. Definicja bramy domyślnej (Default Gateway): polecenie route add default via 192.168.100.1 dev vethX informuje stos sieciowy przestrzeni, że wszelkie pakiety skierowane pod adresy nienależące do lokalnej podsieci (np. zapytania do publicznych serwerów DNS czy stron WWW) muszą zostać wysłane na wirtualny port mostka br0.

W tym momencie obie przestrzenie posiadają kompletną, w pełni funkcjonalną konfigurację sieciową L2/L3, odpowiadającą stanowi kontenera Docker zaraz po zakończeniu procedury inicjalizacji przez bibliotekę libnetwork.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.
Docker bridge – domyślna sieć kontenerów z NAT i wirtualnym mostem docker0.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

W czwartym kroku laboratorium przeprowadzamy pełną walidację funkcjonowania naszego stosu wirtualnego. Pierwszy test – wysłanie zapytań ICMP z ns1 pod adres 192.168.100.12 (ns2) – testuje czyste przełączanie w warstwie 2. Ramka Ethernet generowana przez ns1 zawiera zapytanie ARP typu broadcast (Who has 192.168.100.12? Tell 192.168.100.11).

Zapytanie ARP trafia przez interfejs veth1-br do mostka br0. Mostek, rejestrując źródłowy adres MAC w tablicy FDB, wykonuje flooding ramki na port veth2-br. Przestrzeń ns2 odbiera pakiet, odpowiada swoim adresem MAC, co mostek natychmiast odnotowuje w FDB. Od tego momentu wszystkie pakiety ICMP Echo Request i Reply są przesyłane w trybie unicast. Administrator może podejrzeć te wpisy, wykonując polecenie bridge fdb show br br0.

Kolejnym kluczowym etapem jest wyprowadzenie ruchu z wirtualnej sieci do globalnego Internetu. Samodzielny mostek L2 nie potrafi przesyłać pakietów poza swoją domenę rozgłoszeniową. Aby umożliwić kontenerom wyjście na świat, realizujemy dwie fundamentalne konfiguracje routera linuksowego:

1. Włączenie przekazywania pakietów w jądrze: sysctl -w net.ipv4.ip_forward=1. Bez tej flagi jądro Linuksa traktuje pakiety przychodzące z mostka z obcym adresem docelowym jako błędne i bezpowrotnie je odrzuca;
2. Translacja adresów źródłowych (SNAT/MASQUERADE): prywatna podsieć 192.168.100.0/24 nie jest routowalna w zewnętrznej sieci. Reguła iptables -t nat -A POSTROUTING -s 192.168.100.0/24 ! -o br0 -j MASQUERADE podmienia adres źródłowy każdego pakietu opuszczającego mostek na adres fizycznej karty hosta.

Po wykonaniu tych dwóch kroków przestrzeń ns1 zyskuje pełny, stabilny dostęp do globalnego Internetu, co potwierdza udany ping pod publiczny adres serwera Cloudflare 1.1.1.1.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.
Docker bridge – domyślna sieć kontenerów z NAT i wirtualnym mostem docker0.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

W piątym, wieńczącym kroku naszego warsztatu laboratoryjnego dokonujemy pełnej, manualnej rekonstrukcji flagi publikowania portów Dockera: -p 8080:80. W tym celu uruchamiamy w przestrzeni ns1 prosty serwer HTTP w języku Python, który nasłuchuje na standardowym porcie 80. Serwer ten działa w odizolowanym środowisku i nie ma żadnego bezpośredniego kontaktu z portami maszyny fizycznej.

Następnie wcielamy się w rolę demona Dockera i wprowadzamy do podsystemu Netfilter dwie kluczowe reguły zapory sieciowej:

1. Translacja DNAT w tabeli nat: polecenie iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 192.168.100.11:80 przechwytuje każdy pakiet TCP przychodzący na port 8080 hosta i w locie zamienia jego docelowy adres IP na 192.168.100.11, a port docelowy na 80;
2. Autoryzacja przepływu w tabeli filter: polecenie iptables -A FORWARD -p tcp -d 192.168.100.11 --dport 80 -j ACCEPT gwarantuje, że pakiet po dokonaniu translacji adresowej nie zostanie zablokowany przez domyślną politykę łańcucha FORWARD, lecz bezpiecznie przepuszczony na interfejs mostka br0.

Gdy zewnętrzny komputer w sieci LAN wysyła żądanie HTTP pod adres hosta http://192.168.1.100:8080, pakiet trafia na kartę eth0, zostaje przetłumaczony przez DNAT, przekierowany przez mostek br0 do kabla veth1-br i odebrany przez serwer Pythona na interfejsie veth1 wewnątrz ns1. Odpowiedź serwera wraca przez mostek, gdzie moduł conntrack odwraca translację (zamieniając adres źródłowy z powrotem na 192.168.1.100:8080) i pakiet dociera do klienta.

W ten sposób udowodniliśmy, że zaawansowana sieć kontenerowa platformy Docker nie wymaga żadnych tajemniczych sterowników zewnętrznych – jest ona w stu procentach oparta na genialnej kompozycji elementarnych klocków jądra Linuksa: mostków L2, wirtualnych par VETH, przestrzeni nazw sieci oraz elastycznych łańcuchów podsystemu Netfilter.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
DNAT (Destination NAT) – translacja adresu docelowego stosowana przy publikowaniu portów kontenerów.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Protokół drzewa rozpinającego – STP (Spanning Tree Protocol), zdefiniowany pierwotnie w standardzie IEEE 802.1D oraz zaktualizowany do szybkiego protokołu RSTP (Rapid Spanning Tree Protocol wg IEEE 802.1w), stanowi fundamentalny mechanizm stabilizujący sieci warstwy 2. W architekturze Ethernet brak jest mechanizmu wygaszania ramek (odpowiednika pola TTL z nagłówka IP). W efekcie, jeśli między przełącznikami powstaną dwie niezależne ścieżki transmisyjne, pojedyncza ramka rozgłoszeniowa (np. zapytanie ARP) jest bez końca powielana i przesyłana w pętli, paraliżując całą infrastrukturę sieciową w ułamku sekundy.

Implementacja mostka w jądrze Linuksa zawiera pełne wsparcie dla protokołu STP. Po aktywowaniu flagi stp_state 1, mostek zaczyna periodycznie generować i przetwarzać specjalne ramki kontrolne BPDU (Bridge Protocol Data Units), wysyłane na zarezerwowany adres multicastowy 01:80:C2:00:00:00. W toku wymiany komunikatów węzły sieciowe wybierają mostek główny (Root Bridge), obliczają najkrótsze ścieżki i przełączają redundantne porty w stan blokowania (Blocking / Discarding).

Port przechodzący w stan roboczy musi przebyć ściśle zdefiniowaną sekwencję stanów: od Listening (nasłuchiwanie BPDU), przez Learning (uczenie się adresów MAC bez przekazywania danych), aż po Forwarding (pełne przekazywanie ruchu). Standardowy czas trwania tego procesu w klasycznym 802.1D wynosi aż 30–50 sekund.

Z tego powodu silnik Docker oraz wtyczki CNI standardowo wyłączają obsługę STP na swoich wirtualnych mostkach (stp_state 0). W środowisku kontenerowym topologia ma charakter ściśle promienisty (gwiazda), gdzie każdy kabel VETH łączy się wyłącznie z jednym odizolowanym kontenerem, co z definicji wyklucza powstanie pętli L2. Wyłączenie STP pozwala na natychmiastowe przejście wirtualnego portu w stan FORWARDING w ułamku milisekundy, co umożliwia kontenerom błyskawiczne rozpoczęcie komunikacji sieciowej tuż po uruchomieniu.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.
Docker bridge – domyślna sieć kontenerów z NAT i wirtualnym mostem docker0.

Przydatne łącza: Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra).

Wirtualne pary interfejsów Ethernet (VETH) są mechanizmem niezwykle eleganckim i niezawodnym, lecz ich konfiguracja na poziomie wiersza poleceń wymaga rygorystycznego przestrzegania określonych reguł jądra Linuksa. Zrozumienie przyczyn typowych problemów pozwala zaoszczędzić godziny żmudnej diagnostyki w warunkach laboratoryjnych i produkcyjnych.

Najbardziej powszechnym błędem popełnianym przez początkujących inżynierów jest próba konfiguracji adresacji IP przed przeniesieniem interfejsu do docelowej przestrzeni nazw. W architekturze Linuksa wywołanie systemowe SIOCSIFNETNS (odpowiadające poleceniu ip link set dev <veth> netns <ns>) powoduje całkowite wyczyszczenie stanu interfejsu. Jądro usuwa wszystkie przypisane adresy IPv4 i IPv6, kasuje powiązane reguły routingu, a sam interfejs przestawia w stan administracyjny DOWN. Prawidłowa procedura zawsze zakłada najpierw migrację interfejsu do przestrzeni docelowej, a dopiero w kolejnym kroku nadanie adresu IP i jego aktywację.

Kolejną pułapką jest kwestia interfejsu pętli zwrotnej lo. Podczas tworzenia nowej przestrzeni nazw sieci (ip netns add), jądro Linuksa powołuje do życia nowy interfejs lo, lecz celowo pozostawia go w stanie wyłączonym (DOWN). Wiele popularnych bibliotek programistycznych i serwerów bazodanowych (np. PostgreSQL, Redis, Node.js) przy próbie uruchomienia wykonuje testowe połączenie z adresem 127.0.0.1 lub odpytuje gniazdo lokalne. Jeśli interfejs lo nie zostanie jawnie podniesiony poleceniem ip link set dev lo up, proces aplikacji natychmiast ulega awarii, generując mylące komunikaty o braku zasobów sieciowych.

Warto również pamiętać o zasadzie czystości warstwy 2 mostka. Jeśli końcówka pary VETH (np. veth1-br) została podłączona do mostka za pomocą dyrektywy master br0, nie wolno przypisywać do niej żadnego adresu IP. Przypisanie adresu do interfejsu podrzędnego mostka powoduje, że pakiety przychodzące są przechwytywane przez procedury mostka, podczas gdy pakiety wychodzące próbują omijać mostek, co skutkuje całkowicie asymetrycznym trasowaniem i zrywaniem połączeń TCP.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.
Docker bridge – domyślna sieć kontenerów z NAT i wirtualnym mostem docker0.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Jednym z najbardziej fascynujących i złożonych zagadnień w inżynierii sieci kontenerowych jest problem tzw. pętli zwrotnej NAT, w literaturze sieciowej określanej jako Hairpin NAT (lub NAT Loopback / Reflective Relay). Zrozumienie tego zjawiska pozwala rozwiązać zagadkę, dlaczego aplikacje w kontenerach często nie mogą połączyć się z usługami sąsiednimi, gdy odwołują się do nich za pośrednictwem zewnętrznej domeny publicznej lub publicznego adresu IP serwera.

Przeanalizujmy scenariusz awarii bez mechanizmu Hairpin NAT:

1. Kontener A (172.17.0.2) wysyła pakiet TCP SYN pod publiczny adres hosta 198.51.100.1:8080, gdzie opublikowana jest usługa kontenera B (172.17.0.3:80);
2. Pakiet trafia na mostek docker0, a stamtąd do reguły DNAT w jądrze hosta. Reguła DNAT podmienia adres docelowy na 172.17.0.3:80, lecz pozostawia adres źródłowy nienaruszony (nadal 172.17.0.2);
3. Pakiet zostaje przekazany przez mostek do kontenera B;
4. Kontener B generuje odpowiedź TCP SYN-ACK. Ponieważ adres źródłowy żądania (172.17.0.2) znajduje się w tej samej lokalnej podsieci mostka, kontener B wysyła odpowiedź bezpośrednio przez mostek do kontenera A, całkowicie omijając mechanizm conntrack hosta;
5. Kontener A odbiera pakiet SYN-ACK pochodzący z adresu 172.17.0.3:80. Ponieważ kontener A wysyłał żądanie pod adres 198.51.100.1:8080, jego stos sieciowy natychmiast odrzuca tę odpowiedź (pakiet RST), uznając ją za niezamówioną i niespójną. Połączenie ulega zawieszeniu.

Aby rozwiązać ten problem, Docker stosuje dwa skoordynowane mechanizmy. Po pierwsze, na wszystkich portach VETH podłączonych do mostka włącza flagę hairpin on za pośrednictwem wywołania Netlink (bridge link set dev vethX hairpin on), zezwalając mostkowi na zawrócenie ramki na ten sam interfejs. Po drugie, w łańcuchu POSTROUTING tabeli nat instaluje regułę maskarady zwrotnej:

-A POSTROUTING -s 172.17.0.0/16 -d 172.17.0.0/16 -j MASQUERADE

Reguła ta podmienia adres źródłowy pakietu z adresu Kontenera A na adres mostka (172.17.0.1). Dzięki temu Kontener B odsyła odpowiedź do bramy mostka, host może odwrócić translację DNAT/SNAT i przesłać spójny pakiet z powrotem do Kontenera A, gwarantując bezbłędne nawiązanie sesji TCP.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
DNAT (Destination NAT) – translacja adresu docelowego stosowana przy publikowaniu portów kontenerów.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Skuteczna diagnostyka zaawansowanych problemów sieciowych w środowiskach wirtualnych wymaga posługiwania się wyspecjalizowanym zestawem narzędzi inżynierskich. W odróżnieniu od sieci fizycznych, gdzie inżynier może wpiąć analizator sprzętowy (np. agregator TAP lub port lustrzany SPAN na przełączniku), w środowisku Linuksa cały ruch odbywa się wewnątrz struktur pamięci RAM jądra.

Podstawowym instrumentem analitycznym pozostaje tcpdump (oparty na bibliotece libpcap). Wirtualizacja sieci daje administratorowi unikalną przewagę: tcpdump może zostać uruchomiony bezpośrednio na interfejsie mostka (-i br0), na konkretnym wirtualnym kablu (-i veth1-br) lub na pseudourządzeniu any (-i any), które przechwytuje pakiety na wszystkich interfejsach systemowych jednocześnie. Pozwala to na precyzyjne zaobserwowanie momentu, w którym pakiet ulega translacji DNAT lub zostaje po cichu odrzucony przez zaporę.

Niezwykle potężną techniką jest wykorzystanie narzędzia nsenter. W środowiskach produkcyjnych kontenery ze względów bezpieczeństwa często budowane są w oparciu o obrazy minimalne (distroless, scratch, minimalne alpine), pozbawione powłoki bash, narzędzi sieciowych (ip, curl, ping) czy menedżera pakietów. Próba wykonania docker exec -it kontener sh kończy się wówczas błędem. Za pomocą polecenia:

nsenter -t <PID_kontenera> -n <polecenie_z_hosta>

inżynier może wykonać bogaty zestaw narzędzi diagnostycznych zainstalowanych na hoście bazowym (np. tcpdump, ss, mtr, ethtool) wewnątrz odizolowanej przestrzeni sieciowej kontenera bez konieczności modyfikowania jego obrazu.

Najnowocześniejszym trendem w diagnostyce jądra stały się narzędzia oparte na technologii eBPF, takie jak pwru (Packet Where aRe yoU) rozwijany przez zespół Cilium i dostępny w serwisie github.com/cilium/pwru (narzędzie nie wchodzi w skład standardowych repozytoriów dystrybucji, wymaga pobrania gotowego wydania albo zbudowania ze źródeł). Program ten śledzi drogę konkretnego pakietu sieciowego przez wszystkie wewnętrzne funkcje jądra Linuksa (np. ip_rcv, nf_hook_slow, br_handle_frame), wskazując z dokładnością do linii kodu jądra, która reguła zapory lub funkcja podsystemu sieciowego zdecydowała o odrzuceniu pakietu (packet drop).

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
DNAT (Destination NAT) – translacja adresu docelowego stosowana przy publikowaniu portów kontenerów.

Przydatne łącza: Docker – sterowniki sieci; Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Niniejszy wykład podsumowuje ewolucję mechanizmów wirtualizacji sieciowej: od elementarnych prymitywów jądra Linuksa, przez architekturę kontenerów pojedynczego hosta w środowisku Docker, aż po zaawansowane systemy orkiestracji wielowęzłowej w standardzie CNI (Container Network Interface).

W tradycyjnym podejściu Dockera dominował model mostkowany ze statyczną translacją adresów: każdy host zarządzał własną prywatną podsiecią 172.17.0.0/16, a komunikacja między serwerami wymagała publikowania portów flagą -p i translacji DNAT/SNAT. W architekturze wielkich klastrów kontenerowych (Kubernetes) model ten okazał się zbyt skomplikowany i mało wydajny. Architekci Kubernetes sformułowali rewolucyjną regułę sieciową: każdy Pod w klastrze posiada własny, unikalny adres IP i może komunikować się z dowolnym innym Podem na dowolnym węźle bez użycia translacji NAT.

Zadanie realizacji tej reguły powierzono wymiennym wtyczkom sieciowym zgodnym ze specyfikacją CNI. W zależności od wymagań środowiska produkcyjnego inżynierowie wybierają odpowiednią implementację:

• Flannel: lekka i stabilna wtyczka CNI, idealna dla mniejszych klastrów. Najczęściej wykorzystuje omówioną wcześniej enkapsulację tunelową VXLAN (RFC 7348 na porcie UDP 4789) lub tryb host-gw, który konfiguruje statyczne trasy routingu między węzłami w tej samej domenie L2;
• Project Calico: potężne rozwiązanie klasy enterprise, które rezygnuje z narzutu enkapsulacji tunelowej na rzecz czystego routingu IP warstwy 3. Każdy węzeł klastra uruchamia zoptymalizowany demon routingu BGP (Border Gateway Protocol) oparty na projekcie Bird, anonsując podsieci swoich lokalnych podów do fizycznych routerów sieci szkieletowej (ToR – Top of Rack);
• Cilium: reprezentuje najnowocześniejszą generację wirtualizacji sieciowej. Cilium całkowicie eliminuje tradycyjne, ociężałe tablice iptables i moduł conntrack na rzecz dynamicznie kompilowanego kodu eBPF (Extended Berkeley Packet Filter). Pakiety są przetwarzane i trasowane bezpośrednio na poziomie sterownika karty sieciowej (XDP) lub gniazd TCP, co redukuje opóźnienia do minimum, podnosi przepustowość oraz udostępnia bezprecedensowe możliwości monitoringu ruchu warstwy 7 (HTTP, gRPC, DNS) za pośrednictwem platformy Hubble.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
VLAN (Virtual LAN) – logiczna sieć wirtualna wydzielona znacznikiem IEEE 802.1Q.
DNAT (Destination NAT) – translacja adresu docelowego stosowana przy publikowaniu portów kontenerów.

Przydatne łącza: Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra); IEEE 802.1Q (VLAN).

Przedstawione kompendium poleceń (Cheat Sheet) stanowi syntetyczne podsumowanie całego aparatu narzędziowego omówionego podczas niniejszego kursu. Zgromadzono w nim najważniejsze komendy systemu Linux, które każdy inżynier DevOps, architekt chmurowy oraz administrator infrastruktury sieciowej powinien mieć w podręcznym zasobniku narzędziowym.

Warto pamiętać o kluczowych regułach inżynierskich rządzących konfiguracją tych komponentów:

• Mostek sieciowy (bridge): tworzony poleceniem ip link add type bridge. Wszelkie adresy IP przypisujemy wyłącznie do samego mostka (br0), nigdy do portów składowych (slave interfaces). Porty dodane do mostka tracą własną tożsamość L3 i działają w czystej warstwie L2;
• Pary VETH: działają symetrycznie jak wirtualny kabel krosowy w pamięci operacyjnej. Usunięcie jednego końca pary natychmiast niszczy drugi koniec. Przeniesienie interfejsu do innej przestrzeni (ip link set netns) kasuje jego adresację i wyłącza urządzenie (stan DOWN) – konfigurację adresową należy przeprowadzić dopiero po migracji;
• Przestrzenie nazw (network namespaces): gwarantują pełną separację stosu sieciowego. Należy bezwzględnie pamiętać o ręcznym podniesieniu interfejsu pętli zwrotnej lo, bez którego większość aplikacji serwerowych nie jest w stanie zainicjalizować lokalnych gniazd IPC/TCP;
• Sieci Docker: w środowiskach produkcyjnych bezwzględnie unikamy domyślnego mostka docker0 ze względu na brak wbudowanego serwera DNS (127.0.0.11) oraz brak separacji L2 między projektami. Tworzymy dedykowane sieci za pomocą docker network create --driver bridge;
• Filtracja i zapora: w systemach z demonem Docker własne reguły zapory sieciowej wprowadzamy wyłącznie do dedykowanego łańcucha DOCKER-USER w tabeli filter. Wszelkie modyfikacje łańcucha DOCKER zostaną bezpowrotnie nadpisane przez silnik kontenerowy przy kolejnym starcie kontenera;
• Diagnostyka inżynierska: połączenie narzędzi iproute2, bridge monitor fdb, tcpdump, conntrack oraz nsenter pozwala na bezbłędne zdiagnozowanie i usunięcie każdej awarii wirtualnego stosu sieciowego bez konieczności restartowania usług ani maszyn fizycznych.

Wyjaśnienie skrótów i pojęć:
Bridge (most) – wirtualny przełącznik warstwy drugiej w jądrze Linux.
VETH (Virtual Ethernet) – para wirtualnych interfejsów połączonych tunelem punkt-punkt.
Network namespace – izolowana instancja stosu sieciowego w jądrze Linux.
DNAT (Destination NAT) – translacja adresu docelowego stosowana przy publikowaniu portów kontenerów.

Przydatne łącza: Linux bridge (dokumentacja); Linux bridge (dokumentacja jądra).