Traceroute w systemie Linux: sprawdź, gdzie połączenie jest blokowane, zanim obwinisz serwer

Gdy strona internetowa lub serwer przestaje odpowiadać, pierwszym odruchem często jest obwinianie maszyny zdalnej. Ale nie zawsze to ona jest winowajcą. Przyczyną awarii może być sieć lokalna, router, filtrowanie między dwoma dostawcami, zapora sieciowa lub po prostu ścieżka sieciowa, która skręca w niewłaściwym kierunku.

Trasa Jego celem jest właśnie zbadanie ścieżki, jaką przebyły Twoje pakiety. Nie dostarcza absolutnej prawdy, ale pomaga wiedzieć, od czego zacząć rozwiązywanie problemów przed ponownym uruchomieniem usługi, która o to nie prosiła.

Tux, administrator Linuksa, analizuje ścieżkę sieciową za pomocą alertu o skoku. — Narzędzie Traceroute pomaga zlokalizować przeskok w sieci, w którym połączenie zaczyna się zatrzymywać.

Zainstaluj traceroute, jeśli polecenie jest niedostępne

W przypadku niektórych dystrybucji, Trasa Nie jest on instalowany domyślnie. Najpierw sprawdź jego obecność.

polecenie -v traceroute
traceroute --wersja

Jeśli polecenie jest niedostępne, zainstaluj pakiet odpowiedni dla Twojej dystrybucji.

sudo apt update
sudo apt install traceroute

sudo dnf install traceroute
sudo pacman -S traceroute

Na serwerze produkcyjnym wolę zainstalować narzędzie poprawnie, niż uruchamiać polecenie pobrane losowo z kontenera lub pliku binarnego innej firmy. Powinieneś móc powtórzyć test później, w tych samych warunkach.

Uruchom pierwszy czysty traceroute

Aby przetestować ścieżkę do domeny, wystarczy użyć:

traceroute linuxencaja.net

Na wyjściu wyświetlana jest lista przeskoków. Każdy wiersz zazwyczaj odpowiada routerowi, przez który przechodził. Często wyświetlany jest numer przeskoku, nazwa lub adres IP routera, a następnie kilka czasów odpowiedzi.

Aby uniknąć powolnego rozwiązywania nazw DNS podczas diagnostyki, dodaj -NCzęsto jest to pierwszy test, który przeprowadzam, gdy chcę jechać szybko.

traceroute -n linuxencaja.net

Jeśli sama nazwa domeny wydaje się podejrzana, zacznij od oddzielenia problemu z DNS od problemu z siecią. Poradnik Pamięć podręczna DNS w systemie Linux Ten krok można uznać za zakończony, zwłaszcza jeśli komputer widzi stary adres IP, a nie inny.

Czytaj gwiazdy i nie wyciągaj zbyt pochopnych wniosków.

Gwiazdy * * * Te błędy nie oznaczają automatycznie awarii sieci. Wskazują one przede wszystkim, że przeskok nie odpowiada zgodnie z oczekiwaniami na pakiety używane przez traceroute. Wiele routerów filtruje lub ogranicza te odpowiedzi.

Ważna jest reszta ścieżki. Jeśli jeden przeskok wyświetla gwiazdki, ale kolejne przeskoki odpowiadają, a punkt docelowy również odpowiada, to prawdopodobnie nie jest to wina routera pośredniczącego.

Z drugiej strony, jeśli traceroute zawsze zatrzymuje się w tym samym miejscu i dalej nic nie odpowiada, musisz zbadać pewien obszar: lokalną bramę, trasę operatora, VPN, zaporę sieciową, filtrowanie hostów lub awarię po stronie docelowej.

traceroute -n 8.8.8.8
traceroute -n 1.1.1.1
traceroute -n twój-serwer.przykład

Porównywanie wielu adresów docelowych pozwala uniknąć fałszywych tropów. Jeśli wszystko jest zablokowane na pierwszym lub drugim przeskoku, sprawdź sieć lokalną. Jeśli blokuje tylko konkretny serwer, problem najprawdopodobniej dotyczy tej trasy, dostawcy lub konkretnego filtra.

Wybierz ICMP lub TCP w zależności od kontekstu

Domyślnie traceroute może używać pakietów, które niekoniecznie odpowiadają ruchowi aplikacji, który próbujesz zdiagnozować. Jeśli testujesz stronę internetową, test TCP na porcie 443 może być bardziej miarodajny.

sudo traceroute -T -p 443 linuxencaja.net

W przypadku testu ICMP, bliskiego duchowi świst, używać -I.

sudo traceroute -I 8.8.8.8

Strony podręcznika Trasa I świst Szczegółowo opisują te tryby. W praktyce pamiętam głównie to: jeśli przeglądarka nie działa na protokole HTTPS, należy również przetestować protokół TCP 443. Traceroute UDP lub ICMP może dać inny wynik.

Sprawdź lokalną trasę, zanim obwinisz internet

Jeśli początkowe przeskoki są niespójne, sprawdź trasę używaną przez Twój komputer. Jest to niezbędne w przypadku serwera z wieloma interfejsami, siecią VPN, trasą statyczną lub dodatkowym adresem IP.

trasa IP
trasa IP: pobierz 8.8.8.8
trasa IP pobierz 1.1.1.1

uzyskaj trasę ip Pokazuje interfejs, bramę, a czasem adres źródłowy użyty do dotarcia do celu. Jeśli wynik nie jest zgodny z oczekiwaniami, traceroute po prostu potwierdza błędną ścieżkę lokalną.

Przed zdalną modyfikacją trasy należy utrzymać otwartą sesję SSH i zapewnić dostęp do konsoli. Nieprawidłowa trasa domyślna może spowodować szybsze rozłączenie z serwerem niż źle zrestartowana usługa.

Rozróżnianie opóźnienia, utraty i filtrowania

Pojedynczy przeskok o dużym opóźnieniu nie wystarczy, aby udowodnić, że router jest odpowiedzialny. Niektóre routery wolno reagują na pakiety diagnostyczne, ale nadal normalnie przekazują ruch.

Bardziej interesuje mnie degradacja, która utrzymuje się przy każdym kolejnym skoku, lub widoczna utrata jakości aż do celu. Wtedy można zacząć mówić o realnym problemie ze ścieżką lub celem.

ping -c 5 linuxencaja.net
ping -c 5 8.8.8.8
traceroute -n -q 3 linuxencaja.net

Jeśli musisz sprawdzić otwarte porty po stronie serwera, nie mieszaj wszystkiego w traceroute. Zamiast tego użyj Użyj ss lub netstat do sprawdzenia otwartych portów w systemie LinuxTraceroute pokazuje ścieżkę. SS pokazuje, co naprawdę słucha urządzenie.

Kiedy zamiast tego używać tracepath

ścieżka śledzenia Może się to przydać, gdy chcesz szybko przetestować produkt bez zaawansowanych opcji. Często jest dostępne w pakiecie. iputile i może również raportować informacje związane z MTU ścieżki.

tracepath linuxencaja.net
ścieżka śledzenia 1.1.1.1

Strona podręcznika ścieżka śledzenia Pozostaje dobrym punktem odniesienia, jeśli chcesz zrozumieć jego ograniczenia. Aby uzyskać precyzyjną diagnozę konkretnego portu lub trybu, nadal odsyłam do Trasa.

Metoda, którą stosuję przed zmianą konfiguracji

Gdy połączenie się nie powiedzie, wykonuję sprawdzenia w następującej kolejności:

przetestuj DNS za pomocą adresu IP i nazwy domeny;
rzucić traceroute -n do kilku miejsc docelowych;
przetestuj odpowiedni tryb, na przykład -T - str. 443 dla HTTPS;
kontrola uzyskaj trasę ip z danej maszyny;
sprawdź port po stronie serwera za pomocą SS jeśli droga pomyślnie dotrze do celu;
Należy zwrócić uwagę na miejsce, w którym ścieżka kończy się przed otwarciem zgłoszenia operatora lub hosta.

Dzięki tej metodzie unikniesz klasycznej pułapki: restartowania serwera lub ingerencji w zaporę sieciową, gdy problem leży po stronie nadrzędnej. A jeśli problem się powtórzy, będziesz mieć przynajmniej wyraźny zapis przeskoku, przetestowanego portu i użytej trasy lokalnej.