Testuj routing VPN w przestrzeniach nazw bez dotykania tras hosta

Dwa laboratoria mogą modelować tę samą topologię VPN i zawodzić w zupełnie różny sposób: jedno żyje w przestrzeniach nazw sieci, drugie na własnych trasach hosta. Wersja z przestrzeniami nazw trzyma każdy interfejs, trasę i gniazdo w kontekście, który możesz usunąć, podczas gdy wersja hostowa startuje szybciej i zostawia po sobie stan. To właśnie ten resztkowy stan sprawia, że drugie laboratorium jest trudne do powtórzenia miesiąc później. Porównaj najpierw sprzątanie, bo ono decyduje, czy możesz wykonać eksperyment dwa razy.

Dwa sposoby zbudowania tego samego laboratorium i kiedy wygrywa każdy z nich

W laboratorium tras hosta dodajesz interfejs tunelu i trasy do maszyny, na której pracujesz, więc eksperyment dzieli los z twoją powłoką, menedżerem pakietów i każdym innym połączeniem. W laboratorium przestrzeni nazw każda rola dostaje własny stos interfejsów, adresów, tras i gniazd, a usunięcie przestrzeni nazw usuwa to wszystko. Żaden model nie jest bardziej poprawny, bo odpowiadają na różne pytania. Wybierz przestrzenie nazw, gdy tematem jest routing i przekazywanie, a laboratorium hostowe, gdy tematem jest to, jak integruje się jeden klient pulpitu.

Mieszanie obu to zwykły błąd: laboratorium przestrzeni nazw testowane wobec klienta działającego tylko na hoście nie dowodzi niczego o żadnym z dwóch układów. Zdecyduj, jakie pytanie zadajesz, zanim utworzysz pierwsze połączenie.

Jeden kontekst na rolę, połączony celowo

Utwórz jedną przestrzeń nazw na rolę i przenieś każdy koniec każdej pary veth do kontekstu, który go posiada. Pierwsze cztery polecenia wystarczą, by zobaczyć kształt:

ip netns add client
ip netns add gateway
ip link add veth-c type veth peer name veth-g
ip link set veth-c netns client

Daj laboratorium zakresy, które nie nakładają się na nic na hoście, i zapisz przed startem, która przestrzeń nazw posiada który adres. Działające laboratorium potrzebuje dwóch osobnych ścieżek: zewnętrznej, by punkt końcowy VPN dotarł do swojego partnera, oraz ścieżki powrotnej dla chronionego zasobu. Modeluj je jako dwie decyzje, bo laboratorium, które buduje tylko połowę wychodzącą, przechodzi test uścisku dłoni i oblewa test aplikacji.

Rola przekazywania to miejsce, w którym laboratoria stają się interesujące

Jedna rola musi przekazywać, co oznacza włączenie przekazywania wewnątrz tej przestrzeni nazw i dodanie reguły, której wymaga projekt. Stan przekazywania jest na przestrzeń nazw, więc ustawienie hosta jest nieistotne dla laboratorium, a ustawienie laboratorium nie wycieka na zewnątrz, jak opisuje dokumentacja przestrzeni nazw sieci. WireGuard dokumentuje, że interfejs i jego zewnętrzne gniazdo mogą żyć w różnych przestrzeniach nazw, co jest użytecznym trikiem i doskonałym sposobem na zmylenie samego siebie. Nie zakładaj, że przeniesienie interfejsu przenosi każdą część połączenia identycznie.

Sprawdź licznik przekazywania po pakiecie testowym, bo reguła, która nigdy nie pasowała, i reguła, która odrzuciła, wyglądają identycznie w tabeli tras. Tylko liczniki je rozdzielają.

Zapisz stan bazowy, a potem zepsuj jedną trasę

Zacznij od zapisania tego, co istnieje, z kontekstem obok każdej linii. Odczytaj przestrzenie nazw, potem trasę, którą obrałby cel testowy wewnątrz jednej z nich, potem liczniki na łączu, które ją niesie:

ip netns list
ip -n client route get 10.0.0.5
ip -n gateway -s link show veth-g

Trzecie polecenie to to, które ludzie pomijają, i tam właśnie żyją dowody: liczniki odrzuconych i błędów mówią, czy pakiet w ogóle dotarł do roli przekazywania. Zapisz te same trzy widoki po zmianie i pozwól, by dowodem był diff, a nie twoja pamięć. Potem zepsuj dokładnie jedną rzecz, albo usuwając trasę, albo dodając regułę odmowy na ścieżce przekazywania, i potwierdź przewidziany objaw: ukończony uścisk dłoni bez odpowiedzi albo błąd rozwiązywania nazwy zamiast przekroczenia czasu. Laboratorium, które pokazuje tylko sukces, uczy bardzo niewiele.

Sprzątanie jest tym, co czyni następny przebieg powtarzalnym

Trzymaj sprzątanie w granicach nazwanych zasobów, bo ogólny reset zapory lub usunięcie trasy hosta nie jest powtarzalnością, to drugi incydent. Zapisz topologię, dokładne polecenia i obserwacje, których oczekiwałeś, aby następny przebieg odtworzył ten sam błąd zamiast zgadywać, który kontekst trzymał poprzedni stan. Bez tego zapisu laboratorium jest opowieścią, a nie procedurą.

Używaj poświadczeń wygenerowanych lokalnie dla laboratorium i trzymaj konta produkcyjne z dala od współdzielonych przykładów. Następnie usuń każdą przestrzeń nazw i potwierdź, że widok hosta się nie zmienił, co jest całym powodem wyboru tego modelu. Laboratorium, którego nie możesz czysto usunąć, jest zmianą hosta z dodatkowymi krokami.