Ekran iftop odpowiada na jedno pytanie za razem: które pary hostów wymieniają bajty przez interfejs, na który go skierowałeś. Nie odpowiada, czy każda aplikacja przestrzega polityki VPN, a pusty ekran nie dowodzi, że nic nie wyciekło. Właśnie w różnicy między tymi dwoma twierdzeniami myli się większość dyskusji o testach wycieku. Co wyświetlacz naprawdę oznacza, decydują trzy warunki, a wszystkie trzy są widoczne w użytym wierszu poleceń.

Trzy warunki decydują, co oznacza ekran

Warunki to: który interfejs jest wyświetlany, co ukrywają filtr i samo narzędzie, oraz co test faktycznie wykonał. Odpowiedz na nie w tej kolejności, bo błąd w pierwszym czyni dwa pozostałe bezsensownymi.

Warunek interfejsu jest ważny, bo widok tunelu i widok fizyczny pokazują różne warstwy tego samego ruchu. Patrzenie na interfejs tunelu pokazuje przepływy wewnątrz tunelu; patrzenie na interfejs fizyczny pokazuje nośnik tunelu oraz każdy legalny ruch konfiguracyjny, sterujący lub lokalny, który dzieli to łącze. Żaden z widoków nie jest błędny i żaden nie jest całym obrazem. Nazwanie tego, na który patrzysz, to różnica między dowodem a wrażeniem.

Warunek pierwszy: który interfejs jest wyświetlany

iftop przyjmuje interfejs jawnie przez -i, a jego podręcznik opisuje zachowanie, gdy tego nie zrobisz: wybiera jeden, który może być urządzeniem wyglądającym na zewnętrzne, a nie tunelem. To ustawienie domyślne jest rozsądne dla narzędzia przepustowości i złe dla testu wycieku.

Zawsze podawaj interfejs i zapisuj go obok wyniku. Zrzut ekranu bez nazwy interfejsu nie jest powtarzalny.

Warunek drugi: co ukrywają filtr i narzędzie

iftop przyjmuje wyrażenie filtra, a przepływ, który filtr wyklucza, jest niewidoczny z powodu konstrukcji, a nie nieobecności. Narzędzie domyślnie wykonuje też odpytywanie nazw hostów, aby oznaczać adresy, i te odpytania generują własny ruch DNS, czyli ruch, którego nie zamierzałeś obserwować. -n wyłącza odpytania i czyni wyświetlacz liczbowym; ukrycie wierszy DNS później nie jest tym samym, co niegenerowanie zapytań.

Tę różnicę warto powiedzieć wprost, bo pojawia się też w innych narzędziach: tłumienie wyświetlania jakiejś aktywności nie jest tym samym, co jej zapobieganie. Jeśli odpytania DNS są częścią tego, co testujesz, uruchom test z wyłączonymi odpytaniami, aby obserwacja nie była zanieczyszczona przez obserwatora.

Warunek trzeci: co test faktycznie wykonał

Jedno zapytanie z jednej aplikacji, do jednego celu, w jednej rodzinie adresów dowodzi czegoś o tym zapytaniu. Nie dowodzi niczego o innej aplikacji, innym celu ani drugiej rodzinie adresów, a IPv6 jest rodziną najczęściej zapominaną właśnie w tego rodzaju sprawdzeniu.

Zdefiniuj więc zapytanie przed rozpoczęciem: nieszkodliwy cel, z aplikacji, która cię interesuje, w rodzinie, która cię interesuje, z tunelem w jego zatwierdzonym stanie. Następnie sprawdź stronę odbiorczą lub własną diagnostykę klienta, bo drugi koniec wie, co dotarło, w sposób, w jaki lokalny ekran nie może. Potem wykonaj zatwierdzony przypadek niedostępnego tunelu i sprawdź, czy ruch się zatrzymuje, bo o takie zachowanie wymaganiu zwykle naprawdę chodzi.

DNS zasługuje na własną obserwację. Odbiorca zapytania i trasa, którą zapytanie przebyło, to dwa fakty, a ekran przepustowości nie pokazuje żadnego z nich.

Używanie iftop jako dowodu wspierającego

Dopiero wtedy iftop dodaje wartość i dodaje ją jako potwierdzenie. sudo iftop -i wg0 -n -B -P -f "host 203.0.113.9" pokazuje, czy oczekiwany przepływ pojawia się na oczekiwanym interfejsie, z liczbami bajtów, które czynią twierdzenie o bezczynności weryfikowalnym.

Porównaj to z ss -tnp dla widoku na poziomie gniazd i ip route get dla trasy, którą wybrałoby jądro, a masz trzy obserwacje jednego zapytania zamiast jednego wrażenia o maszynie. Podręcznik iftop dokumentuje wybór interfejsu, składnię filtra i zachowanie odpytań, a to są trzy rzeczy, od których zależy test wycieku. Ekran przepustowości lokalizuje aktywność; trasa, wyjątki i zachowanie przy awarii decydują, czy ta aktywność spełnia wymaganie.

Powiązane artykuły