Rozwiązywanie problemów z siecią Linux i debugowanie

Od czasu do czasu użytkownicy Linuksa i Uniksa napotykają różne problemy z siecią. Wiele z tych problemów przedstawiono tutaj i na innych forach poświęconych rozwiązywaniu problemów, ale są one bardzo konkretne i zawierają wiele dodatkowych informacji technicznych, a czasem trudno jest zrozumieć główny punkt i prawdziwą przyczynę błędów systemu.

Zadając to pytanie, zamierzam założyć stronę wiki społeczności, która umożliwia uogólnienie naszej sieci rozwiązywania problemów i debugowania. Mam nadzieję, że użytkownicy Linuksa i Uniksa mogliby łatwiej rozpoznać i rozwiązać („podzielić i pokonać”) swoje problemy sieciowe za pomocą tej strony.

Rodzicem tej strony powinna być Najlepsza praktyka w diagnozowaniu problemów . Ale tutaj powinniśmy skupić się na rozwiązywaniu problemów sieciowych z przestrzeni użytkownika i jądra.

Przypuszczam, że jeśli:

1. Udostępnij informacje o korzystaniu z doskonałego narzędzia do diagnostyki sieci wraz z konkretnymi przykładami użycia i przykładami błędów sieciowych, które pomagają wykryć.
2. Udostępnij link do świetnego samouczka sieciowego związanego z tym tematem
3. Opowiedz o ogólnej metodzie lub przepisie, która pozwala rozwiązać niektóre problemy sieciowe
4. Udostępnij informacje o zestawie narzędzi do debugowania sieci i rozwiązywania problemów

idealnie pasuje do tego tematu.

Zacznę od udostępnienia linku do narzędzi diagnostycznych varios i 12-letniego prostego samouczka . Również ArchLinux poradnik wydają się mieć aktualne informacje o naszym obiekcie. Aby zanurzyć się w sieci linuksowe, zdecydowanie musimy odwiedzić Linux Networking-HOWTO .

Myślę, że ogólne zasady rozwiązywania problemów z siecią to:

1. Dowiedz się, na jakim poziomie stosu TCP / IP (lub innego stosu) występuje problem.
2. Zrozum, jakie jest prawidłowe zachowanie systemu i jakie jest odchylenie od normalnego stanu systemu
3. Spróbuj wyrazić problem w jednym zdaniu lub kilku słowach
4. Korzystając z informacji uzyskanych z systemu buggy, własnego doświadczenia i doświadczenia innych osób (google, różne forum itp.), Spróbuj rozwiązać problem aż do sukcesu (lub niepowodzenia)
5. Jeśli ci się nie uda, zapytaj innych o pomoc lub radę

Co do mnie, zwykle uzyskuję wszystkie wymagane informacje za pomocą wszystkich potrzebnych narzędzi i staram się dopasować te informacje do moich doświadczeń. Zdecydowanie, jaki poziom stosu sieciowego zawiera błąd, pomaga odciąć mało prawdopodobne warianty. Korzystanie z doświadczenia innych osób pomaga szybko rozwiązać problemy, ale często prowadzi to do sytuacji, że mogę rozwiązać jakiś problem bez jego zrozumienia, a jeśli problem pojawi się ponownie, nie będę mógł rozwiązać go ponownie bez Internetu.

Ogólnie nie wiem, jak rozwiązywać problemy z siecią. Wydaje się, że w mojej mózgu jest jakaś magiczna funkcja SolveNetworkProblem(information_about_system_state, my_experience, people_experience), która czasami może zwrócić dokładnie prawidłową odpowiedź, a czasem może się nie powieść (tak jak tutaj TCP umiera na laptopie z Linuksem ).

Zwykle używam narzędzi z tego zestawu do debugowania sieci:

• ifconfig(lub ip link, ip addr) - do uzyskiwania informacji o interfejsach sieciowych
• ping- do sprawdzania poprawności, jeśli host docelowy jest dostępny z mojego komputera. pingmoże również służyć do podstawowej diagnostyki DNS - możemy pingować hosta według adresu IP lub jego nazwy, a następnie zdecydować, czy DNS w ogóle działa. A potem traceroutelub tracepathlub, mtraby zobaczyć, co się tam dzieje.
• dig - zdiagnozuj wszystko DNS
• dmesg | lesslub dmesg | taillub dmesg | grep -i error- dla zrozumienia, co jądro Linux myśli o problemach.
• netstat -antp+ | grep smth- moje najpopularniejsze użycie polecenia netstat, które wyświetla informacje o połączeniach TCP. Często wykonuję filtrowanie za pomocą grep. Zobacz także nowe sspolecenie (z iproute2nowego standardowego pakietu narzędzi sieciowych Linuksa) i lsofjak w lsof -ai tcp -c some-cmd.
• telnet <host> <port> - jest bardzo przydatny do komunikacji z różnymi usługami TCP (np. na protokołach SMTP, HTTP), możemy również sprawdzić ogólną możliwość połączenia z jakimś portem TCP.
• iptables-save(w systemie Linux) - aby zrzucić pełne tabele iptables
• ethtool - pobierz wszystkie parametry karty interfejsu sieciowego (status łącza, prędkość, parametry odciążania ...)
• socat- narzędzie szwajcarskiej armii do testowania wszystkich protokołów sieciowych (UDP, multicast, SCTP ...). Szczególnie przydatne (bardziej niż telnet) z kilkoma -dopcjami.
• iperf - aby sprawdzić dostępność przepustowości
• openssl( s_client, ocsp, x509...) do debugowania wszystkie kwestie SSL / TLS / PKI.
• wireshark - potężne narzędzie do przechwytywania i analizy ruchu sieciowego, które pozwala analizować i wychwytywać wiele błędów sieciowych.
• iftop - pokaż dużym użytkownikom w sieci / routerze.
• iptstate (w systemie Linux) - bieżący widok śledzenia połączenia zapory.
• arp(lub nowy (Linux) ip neigh) - pokazuje status tablicy ARP.
• routelub nowszy (w systemie Linux) ip route- pokaż status tablicy routingu.
• strace(lub truss, dtracelub w tusczależności od systemu) - jest użytecznym narzędziem, które pokazuje, które wywołania systemowe przetwarzają problem, a także pokazuje kody błędów (errno), gdy wywołania systemowe nie powiodą się. Informacje te często mówią wystarczająco dużo, aby zrozumieć zachowanie systemu i rozwiązać problem. Alternatywnie, użycie punktów przerwania w niektórych funkcjach sieciowych gdbmoże pozwolić ci dowiedzieć się, kiedy są one wykonane i za pomocą jakich argumentów.
• w celu zbadania problemów z zaporą w systemie Linux: iptables -nvLpokazuje, ile pakietów jest dopasowanych do każdej reguły ( iptables -Zaby wyzerować liczniki). LOGCel włożony w łańcuchach zapory jest przydatna, aby zobaczyć, które pakiety do nich dotrzeć i jak one zostały już przekształcone kiedy się tam dostać. Aby uzyskać dalsze NFLOG(związane z ulogd), loguje się pełny pakiet.

Zaskakująca liczba „problemów sieciowych” sprowadza się do tego rodzaju problemów DNS. Wstępne rozwiązywanie problemów należy zastosować ping -n w.x.y.z, aby pominąć rozpoznawanie nazw DNS hosta i po prostu sprawdzić łączność IP. Następnie użyj, route -naby sprawdzić domyślną trasę IP bez rozpoznawania DNS.

Po sprawdzeniu łączności IP i routingu nslookup, hosti digmoże dostarczyć informacji. Pamiętaj, że „blokowanie” może oznaczać, że przekroczono limit czasu DNS.

Nie zapomnij sprawdzić istnienia i zawartości /etc/resolv.conf. Klienci DHCP zmieniają ten plik przy każdej dzierżawie, a czasem źle go oceniają lub jeśli na dysku jest mało miejsca, aktualizacja może się nie powieść.

Mogą występować problemy z okablowaniem. Jeśli masz dostęp do sprzętu, upewnij się, że wszystkie kable są podłączone i podłączone mechanicznie. Jeśli widzisz routery lub interfejsy Ethernet, upewnij się, że lampki łącza są włączone.

Zdalnie musisz polegać na ethtooli mii-tool.

[root@flask ~]# ethtool eth0
Settings for eth0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Speed: 10Mb/s
        Duplex: Half
        Port: MII
        PHYAD: 24
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: g
        Wake-on: d
        Current message level: 0x00000001 (1)
                               drv
        Link detected: yes

„Wykryto łącze: tak” jest dobre, ale 10 Mb / s i Half duplex nie są dobre, ponieważ karta sieciowa na tym komputerze może działać lepiej. Muszę dowiedzieć się, czy karta sieciowa jest wygłupiona, czy kabel jest. Inny komputer podłączony do tego samego routera mówi 100 Mb / s, pełny dupleks.