Dwa VPN-y na jednej maszynie z Linuksem: testuj każdy osobno, bez mieszania wyników

Dwie zielone ikony połączenia wyglądają jak porównanie i zwykle są przypadkiem. Jeśli żądanie testowe mogło skorzystać z któregokolwiek z dwóch tuneli, wynik opisuje w najlepszym razie jeden z nich, a w najgorszym żaden. Nadaj każdemu obserwacji kontekst sieciowy, zamierzony cel i oczekiwanie zapisane przed uruchomieniem testu. Na samodzielnie zarządzanej maszynie z Linuksem nazwane sieciowe przestrzenie nazw to najtańszy sposób kupienia tego rozdzielenia.

Dwie zielone lampki to nie porównanie

Przestrzeń nazw rozdziela tablice routingu, interfejsy i stan stosu sieciowego, więc żądanie rozpoczęte w jednej nie może po cichu pożyczyć tunelu drugiej. Czego nie rozdziela, to procesor, fizyczne łącze wstępujące lub usługa rozwiązywania nazw działająca na hoście. Właśnie w tej ostatniej luce większość takich testów zawodzi, zanim ktokolwiek to zauważy. Zapytanie, które opuszcza przestrzeń nazw i pyta resolver hosta, zwraca odpowiedź bez żadnego związku z testowanym tunelem.

Ta procedura zakłada dwie już przygotowane i zatwierdzone przestrzenie nazw testowych z działającą łącznością zewnętrzną i obsługiwanymi klientami. Nie tworzy niczego, niczego nie rejestruje i nie zastępuje żadnej konfiguracji. Osobne maszyny wirtualne pozostają uczciwym wyborem, gdy klient potrzebuje pełnej sesji pulpitu albo odmawia działania poza nią.

Ustal oczekiwanie przed pierwszym uruchomieniem

Dla każdego kontekstu zdecyduj, jak wygląda sukces: resolver, nazwa usługi, oczekiwany adres i zachowanie wymagane po zerwaniu tunelu. Trzymaj te planowane wartości w ich własnej kolumnie, bo zapis, który miesza plan i obserwację, jest fikcją z sygnaturą czasu. Lista kontrolna poniżej to kształt, którego zapis potrzebuje, a każdy wiersz musi być wypełnialny przed pierwszym połączeniem.

Okablowanie resolvera zasługuje na własny wiersz w tym zapisie, bo to pole najczęściej kłamie. Pliki związane z przestrzenią nazw, takie jak /etc/netns/vpn-a/resolv.conf pojawiają się na swoich zwykłych ścieżkach, gdy polecenie działa wewnątrz przestrzeni nazw, jak opisuje dokumentacja iproute2 dotycząca przestrzeni nazw, ale konfiguracja przełączania usługi nazw i każdy lokalny resolver, który uruchamia, nadal mogą ściągnąć zapytanie z powrotem do hosta.

Jeden tunel na raz, drugi odłączony

Podłącz A przez jego istniejącego właściciela, podczas gdy B pozostaje wyłączony, a następnie sprawdź politykę, trasy i wybraną ścieżkę z kontekstu administracyjnego. Trzy z poniższych poleceń czytają stan; tylko ostatnie kontaktuje się z usługą nazw i żadne z nich nie wysyła żądania aplikacji.

sudo ip -n vpn-a -4 rule show
sudo ip -n vpn-a -4 route show table all
sudo ip -n vpn-a -4 route get 10.55.10.20
sudo ip netns exec vpn-a getent ahostsv4 svc-a.lab.internal

Wyszukanie trasy odpowiada na hipotetyczne pytanie o cel, więc nie może pokazać, że usługa przyjmuje ruch. Trzymaj te dwa rodzaje dowodów w osobnych kolumnach, bo zdrowa trasa obok odrzuconego połączenia to realny i częsty wynik. Następnie wyślij jedno nieszkodliwe autoryzowane żądanie prawdziwą aplikacją, uruchomioną w kontekście A jako jej zwykły użytkownik bez uprawnień, z nienaruszonym sprawdzaniem certyfikatów i uwierzytelnianiem aplikacji, i zapisz wynik wraz z adresem źródłowym, który widziała usługa. Odłącz A przez jego właściciela i powtórz całą linię bazową dla B, notując każdą zmianę konfiguracji, bo inaczej obie linie bazowe przestaną być porównywalne.

Oba włączone, potem po jednym wyłączane

Stan ustalony to łatwa część. Przy obu tunelach połączonych powtórz wyszukanie i żądanie aplikacji dla każdego kontekstu, potem zerwij jeden tunel i sprawdź drugi. Połącz ponownie w odwrotnej kolejności, gdy sama kolejność łączenia jest pytaniem.

sudo ip netns exec vpn-a tcpdump -ni any port 443 -c 5
sudo ip netns exec vpn-b getent ahostsv4 svc-b.lab.internal
sudo ip -n vpn-b -4 route get 10.55.20.20

Przechwycenie rozstrzyga spory, których wynik aplikacji nie rozstrzygnie: pokazuje, czy żądanie wyszło przez interfejs, którego oczekiwałeś, czy przez coś zupełnie innego. Dla każdego przejścia zapisz działanie właściciela, sygnaturę czasu, wynik trasy, wynik nazwy i wynik aplikacji. Następnie sprawdź wymóg bezpiecznego zamknięcia w obrębie dotkniętej przestrzeni nazw, bo izolacja nie jest wyłącznikiem awaryjnym. Przestrzeń nazw trzyma dwa tunele osobno; nie powstrzymuje żadnego z nich przed przenoszeniem ruchu, gdy jego profil mówi, że ruch musi się zatrzymać.

Co ten zapis może, a czego nie może twierdzić

Zaliczenie dowodzi tych obserwacji dla tego układu, na tym hoście, w tym czasie. Nie mówi nic o dwóch klientach dzielących jedną tablicę routingu pulpitu ani o przepustowości, gdy oba tunele niosą obciążenie. To osobne pytania z osobnymi testami, a porównanie jest tylko tak dobre, jak kontekst dołączony do każdego wiersza.

Trzymaj niepowodzenia w zapisie obok sukcesów, oznaczając, który tunel był wtedy włączony. Czysta strona, która ukrywa stan w chwili pomiaru, jest gorsza niż brzydka, która go pokazuje. To, co czyni zapis użytecznym ponownie później, to kontekst, a nie wynik punktowy.

Dwa tunele na jednej maszynie można porównać uczciwie, ale tylko w tylu kontekstach, ile naprawdę kontrolowałeś. Wszystko ponad to jest życzeniem z zieloną ikoną obok.