WireGuard w przestrzeni nazw sieci: dlaczego gniazdo zostało z tyłu

Interfejs jest wymieniony w przestrzeni nazw, której chciałeś, aplikacja jest do niego przypisana, a mimo to ruch tunelu nigdy się nie pojawia. To sygnatura urządzenia WireGuard w jądrze Linux utworzonego w jednej przestrzeni nazw i przeniesionego do innej: interfejs się przeniósł, a jego zaszyfrowane gniazdo UDP nie. Oba muszą być we właściwym miejscu, zanim wewnętrzny ruch będzie miał znaczenie. Sprawdzenie jest szybkie, gdy już wiesz, że trzeba patrzeć na dwa konteksty, a nie jeden.

Objaw: właściwa przestrzeń nazw, brak pakietów

Wewnątrz przestrzeni nazw tunel wygląda zdrowo. Urządzenie istnieje, adresy są przypisane, a konfiguracja peera jest obecna. Na zewnątrz oczekiwana wymiana UDP nigdy nie pojawia się na interfejsie, który obserwowałeś, a druga strona zgłasza, że nie było uścisku dłoni.

Powód jest taki, że wewnętrzne pakiety aplikacji docierają do przeniesionego urządzenia, a urządzenie próbuje je wysłać przez gniazdo należące do innego kontekstu sieciowego. Trasa bazowa, której używa, i każda reguła zapory, która jej dotyczy, to te w przestrzeni nazw, w której utworzono urządzenie.

To nie usterka przenoszenia ani błędna konfiguracja peera. Tak działa implementacja jądra, a dokumentacja przestrzeni nazw WireGuard wprost opisuje regułę tworzenia.

Dlaczego gniazdo ma miejsce narodzin

Urządzenie WireGuard ma jedno gniazdo UDP dla swojego zaszyfrowanego transportu, a gniazdo to jest otwierane w przestrzeni nazw, w której urządzenie jest tworzone. Przeniesienie interfejsu poleceniem łącza przenosi widoczne urządzenie, ale pozostawia transport tam, gdzie się zaczął. Wtedy dwa obiekty mają różnych właścicieli.

Konsekwencję łatwo przeoczyć, ponieważ obie połowy są sprawdzane w różnych miejscach. Trasa wewnętrzna jest ustalana w przestrzeni nazw, w której działa aplikacja, a trasa zewnętrzna jest ustalana tam, gdzie mieszka gniazdo. Sprawdzenie tylko jednej daje pewny, ale błędny wniosek. Sprawdzenie obu zwykle kończy dochodzenie w jednym przebiegu.

Utwórz je tam, gdzie chcesz gniazdo

Rozwiązaniem jest utworzenie urządzenia wewnątrz docelowej przestrzeni nazw, a nie utworzenie go na zewnątrz i przeniesienie. Zakładając, że zatwierdzona przestrzeń nazw już istnieje, a nazwa jest nieużywana:

ip netns exec vpn-apps ip link add wg-demo type wireguard
ip netns exec vpn-apps wg show

Teraz zarówno interfejs, jak i jego gniazdo należą do tego kontekstu, więc trasa bazowa i obowiązujące reguły filtrowania to te skonfigurowane tam. Jeśli projekt wymaga strony jawnej gdzie indziej, najpierw umieść interfejs bazowy w przestrzeni nazw, a potem utwórz tunel. Kolejność jest częścią projektu, a nie szczegółem implementacji.

Traktuj je jako polecenia administracji siecią, nie jako przepis. Tworzą urządzenie i pokazują stan; klucze, peery, adresy i trasy nadal muszą pochodzić z zatwierdzonej konfiguracji, a istniejącego interfejsu produkcyjnego nigdy nie należy podstawiać do przykładu.

Czytaj obie strony ścieżki

Gdy urządzenie jest we właściwym miejscu, zweryfikuj obie decyzje osobno. Zacznij od wyszukania wewnętrznego z kontekstu aplikacji, a następnie sprawdź ścieżkę zewnętrzną z kontekstu, który posiada gniazdo:

ip netns exec vpn-apps ip route get 10.30.0.9
ip netns exec vpn-apps wg show
tcpdump -ni any udp port 51820

Jeśli wyszukanie wewnętrzne rozwiązuje się przez tunel, a przechwycenie zewnętrzne pokazuje zaszyfrowaną wymianę, obie połowy się zgadzają. Jeśli przechwycenie jest puste, gniazdo jest jeszcze gdzie indziej albo trasa bazowa w jego przestrzeni nazw nie dociera do punktu końcowego.

Jeszcze jedno sprawdzenie należy do zapisu: jak urządzenie jest tworzone po restarcie. Menedżer, który odtwarza interfejs z innym kontekstem tworzenia, zmienia miejsce narodzin gniazda. Ręczne przeniesienie, które zadziałało raz, nie jest dowodem w sprawie zarządzanej ścieżki.