Uruchom VPN we własnej przestrzeni nazw, uruchom tam jedną aplikację, a ruch nadal wychodzi trasą hosta. Nic nie jest zepsute: przestrzeń nazw rządzi tylko procesami, które do niej wejdą, a wyciek pochodził z procesu, który nigdy nie wszedł. Interfejsy, adresy, trasy, reguły zapory i sockety to to, czym przestrzeń nazw zarządza. Pliki, konta i już działające usługi nie, i stąd bierze się większość niespodzianek.

Co posiada przestrzeń nazw i gdzie rodzi się socket

Przenieś interfejs do przestrzeni nazw, a host go traci; zbuduj w środku tunel, a host go nie zobaczy. To mechanizm VPN ograniczonego do przestrzeni nazw: urządzenie i trasy do niego żyją w kontekście, do którego docierają tylko wybrane procesy. Host zachowuje swoją domyślną trasę, więc wszystko na zewnątrz pozostaje nietknięte.

W WireGuardzie kontekst utworzenia liczy się tak samo jak bieżąca lokalizacja: socket UDP jest wiązany w przestrzeni nazw, w której utworzono interfejs, nawet po przeniesieniu urządzenia gdzie indziej. Od której tabeli routingu zależą szyfrowane pakiety, zależy od tego miejsca narodzin. Gdy socket pozostaje w kontekście bez trasy do peera, interfejs odpytuje i uścisk dłoni nigdy nie wychodzi. Sprawdź miejsce narodzin, a potem bieżącą lokalizację.

Czego przestrzeń nazw nie izoluje

Nic tutaj nie oddziela systemów plików, kont ani sekretów, i żadna z tych granic nie pojawia się dlatego, że utworzyłeś przestrzeń nazw. Konfiguracja resolvera to plik, więc proces w środku nadal może odczytać ustawienie wskazujące resolver hosta i wysłać swoje zapytanie trasą, którą to implikuje. Aplikacja, która przekazuje żądanie działającemu już brokerowi lub usłudze systemowej, angażuje proces w zupełnie innym kontekście. Oba są żądaniami, na które granica nigdy nie miała odpowiadać.

Rozwiązaniem jest plik dla każdej przestrzeni nazw w /etc/netns/<name>/resolv.conf albo bind mount przygotowanego pliku, wskazujący resolver osiągalny od wewnątrz. Edycja /etc/resolv.conf na hoście nie zmienia niczego, co widzi przestrzeń nazw.

Umiejscowienie procesów jest kontrolą

Izolacja, którą otrzymujesz, jest dokładnie izolacją procesów uruchomionych w środku. Powłoka uruchomiona przez pomocnik exec przestrzeni nazw i wszystko, co powoła, pozostaje w środku; aplikacja pulpitu uruchomiona z sesji hosta nie. Utwórz kontekst, przenieś urządzenie, a potem udowodnij obie strony:

ip netns add vpn1
ip link set wg0 netns vpn1
ip netns exec vpn1 wg show
wg show

Odczytaj pierwszy wg show od wewnątrz przestrzeni nazw, a drugi z hosta, i oczekuj, że tylko jeden z nich wylistuje peera. Jeśli oba to robią, urządzenie nigdy się nie przeniosło; jeśli żaden, trafiło gdzie indziej. Gdy programem uruchamiającym jest menedżer usług, edytować trzeba plik unit, a nie skrót na pulpicie. Unit bez ustawienia przestrzeni nazw uruchamia demona w kontekście hosta i po cichu niweczy projekt.

Testuj z kontekstu aplikacji

Uruchom kontrolę z tym samym plikiem binarnym i tym samym użytkownikiem, których używa aplikacja, wewnątrz przestrzeni nazw. Uwzględnij DNS i obie rodziny adresów, bo trasa IPv6, o której nigdy nie pomyślałeś, jest częstym wyjściem. Test z własnej powłoki dowodzi tylko, że twoja powłoka jest odizolowana.

Następnie uruchom identyczną kontrolę na hoście i potwierdź, że odpowiedzi się różnią: adres tunelu i zamierzony punkt wyjścia w środku, trasa hosta i wyjście biurowe na zewnątrz, oraz resolver po nazwie. Nazwij przestrzenie nazw według wdrożenia, a nie protokołu, żeby skrypt sprzątający nie pomylił dwóch z nich.

Przekazywanie, polityka awarii i sprzątanie

Dla bramy włącz przekazywanie świadomie i zdecyduj, co powinno się stać, gdy tunel padnie. Przestrzeń nazw nie blokuje tras, które w niej zainstalujesz, więc trasa zapasowa do hosta zostanie użyta, jeśli ją utworzysz. To decyzja polityczna i warto ją zapisać, zanim sprawdzi ją awaria.

Zapisz nazwy przestrzeni nazw, interfejsy i to, do kogo należy konfiguracja, żeby sprzątanie usuwało tylko to, co utworzyło wdrożenie. Resetowanie sieci hosta podczas wycofywania zamienia sprzątanie w awarię. Strona network_namespaces(7) jest krótka i warto ją przeczytać, zanim zaprojektujesz tę drogę.

Powiązane artykuły