Diagnostyka sieci i DNS

Wstęp

„Strona nie działa” to nie diagnoza. To objaw. Jak „boli mnie” u lekarza. Dobry lekarz nie zaczyna od operacji. Zaczyna od pytania, gdzie boli, i sprawdza po kolei: temperatura, ciśnienie, osłuchanie.

Admin robi to samo, tylko jego stetoskop nazywa się ping. Dziś poznasz drabinę diagnostyczną: idziesz od dołu do góry i zatrzymujesz się na pierwszym szczeblu, który nie działa.

1. Kabel i karta: ip -br link. Jest UP?
2. Adres: ip -br a. Jest adres i dobra maska?
3. Brama: ping do bramy.
4. Internet po adresie: ping 1.1.1.1.
5. DNS: dig nazwa.
6. Port: nc -zv serwer 443.
7. Aplikacja: curl -I https://strona.

Pierwsze dwa szczeble znałeś z lekcji 69. Dziś reszta.

Laboratorium

Zbudowałem mały internet w pudełku. Komputer dom z adresem 192.168.1.10. Domowy ruter. dostawca internetu. I strona z serwerem WWW pod adresem 198.51.100.80. Ruter jest też serwerem DNS dla domeny kurs.lab. Wszystkie wyniki poniżej są z tego pudełka. Na Twoim komputerze z prawdziwymi stronami wyglądają tak samo, tylko liczby są większe.

ping — halo, jest tam kto?

Ping to zawołanie przez płot: „halo?”. Druga strona odkrzykuje. Mierzysz, ile trwało.

ping -c 3 198.51.100.80

PING 198.51.100.80 (198.51.100.80) 56(84) bytes of data.
64 bytes from 198.51.100.80: icmp_seq=1 ttl=62 time=0.395 ms
64 bytes from 198.51.100.80: icmp_seq=2 ttl=62 time=0.050 ms
64 bytes from 198.51.100.80: icmp_seq=3 ttl=62 time=0.048 ms

--- 198.51.100.80 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2049ms
rtt min/avg/max/mdev = 0.048/0.164/0.395/0.163 ms

-c 3 znaczy: trzy razy i koniec. Bez tego Linuksowy ping pinguje do śmierci albo do Ctrl+C, co nastąpi pierwsze. time to czas tam i z powrotem. 0% packet loss to najpiękniejsze słowa w sieciach.

A ttl=62? Pakiet startuje z licznikiem, zwykle 64, i każdy ruter po drodze odejmuje jeden. 64 minus 62 to dwa rutery po drodze. Zgadza się: ruter i dostawca.

Uwaga: brak odpowiedzi na ping nie zawsze znaczy, że serwer leży. Wiele serwerów i zapór celowo ignoruje ping. Jak sąsiad, który jest w domu, ale nie otwiera akwizytorom. Dlatego ping to szczebel, a nie wyrok.

traceroute, tracepath i mtr — gdzie urywa się droga

Ping mówi „dochodzi albo nie”. Ale gdzie się gubi? Na to jest traceroute. Pakiet wysyła się z licznikiem 1. Pierwszy ruter odejmuje jeden, ma zero, wyrzuca pakiet i odsyła: „tu umarł pakiet, pozdrawiam, ruter numer jeden”. Potem licznik 2, i tak dalej. Każdy ruter po drodze sam się przedstawia. Sprytne jak śledzenie paczki przez to, że co chwilę celowo ją gubisz.

sudo apt install traceroute mtr-tiny   # [Ubuntu]
sudo dnf install traceroute mtr        # [RHEL]
traceroute -n 198.51.100.80

traceroute to 198.51.100.80 (198.51.100.80), 30 hops max, 60 byte packets
 1  192.168.1.1  0.229 ms  0.005 ms  0.003 ms
 2  203.0.113.1  0.148 ms  0.004 ms  0.003 ms
 3  198.51.100.80  0.009 ms  0.005 ms  0.004 ms

Trzy przystanki: mój ruter, dostawca, strona. -n znaczy „nie zamieniaj adresów na nazwy”. Bez tego traceroute dla każdego przystanku pyta DNS i wszystko trwa wieki.

tracepath robi to samo i jest zwykle już zainstalowany, bo należy do pakietu iputils. Działa bez roota i przy okazji mówi, jakie MTU ma trasa:

tracepath -n 198.51.100.80

 1?: [LOCALHOST]                      pmtu 1500
 1:  192.168.1.1                                           0.026ms
 2:  203.0.113.1                                           0.008ms
 3:  198.51.100.80                                         0.052ms reached
     Resume: pmtu 1500 hops 3 back 3

A mtr to traceroute i ping w jednym, odpalany w kółko. Na żywo pokazuje, na którym przystanku gubią się pakiety. W trybie raportu robi kilka rund i wypisuje tabelkę:

mtr -n --report -c 5 198.51.100.80

HOST: vm                          Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.1                0.0%     5    0.0   0.0   0.0   0.0   0.0
  2.|-- 203.0.113.1                0.0%     5    0.1   0.1   0.0   0.1   0.0
  3.|-- 198.51.100.80              0.0%     5    0.1   0.1   0.1   0.1   0.0

Teraz psuję laboratorium. Dostawca przestaje przekazywać ruch dalej. Jak to wygląda od strony domu?

traceroute to 198.51.100.80 (198.51.100.80), 5 hops max, 60 byte packets
 1  192.168.1.1  0.027 ms  0.011 ms  0.003 ms
 2  * * *
 3  * * *

HOST: vm                          Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.1                0.0%     3    0.1   0.1   0.1   0.1   0.0
  2.|-- ???                       100.0     3    0.0   0.0   0.0   0.0   0.0

Mój ruter odpowiada. Dalej cisza. Problem nie jest u mnie w domu, jest za ruterem. Dzwonię do dostawcy, i to z konkretem, a nie z „NIE DZIAŁA INTERNET!!!”.

Jedno zastrzeżenie. Gwiazdki na jednym przystanku, a dalej znowu odpowiedzi? To nie awaria. Niektóre rutery po prostu nie przedstawiają się traceroute'owi. Awaria jest wtedy, gdy od pewnego miejsca gwiazdki są już do końca.

DNS — rozmowa z biurem numerów

Pamiętasz biuro numerów z lekcji 68? Dziś uczymy się je przesłuchiwać. Narzędzie numer jeden to dig.

sudo apt install dnsutils    # [Ubuntu], dostarcza dig, host i nslookup
sudo dnf install bind-utils   # [RHEL]
dig www.kurs.lab

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;www.kurs.lab.			IN	A

;; ANSWER SECTION:
www.kurs.lab.		300	IN	A	198.51.100.80

;; Query time: 4 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)

Czytamy od góry. status: NOERROR, czyli biuro znalazło odpowiedź. Sekcja pytania: pytałem o rekord A dla www.kurs.lab. Sekcja odpowiedzi: adres 198.51.100.80. Liczba 300 to TTL. Na dole: kto odpowiadał, 192.168.1.1, port 53, przez UDP. Ten UDP to ta pocztówka z lekcji 68.

Na co dzień wystarcza wersja dla zabieganych:

dig +short www.kurs.lab

198.51.100.80

A chcesz zapytać konkretne biuro, a nie to z /etc/resolv.conf? Dodaj @: dig @9.9.9.9 google.com. Jeśli dwa serwery DNS odpowiadają różnie, właśnie znalazłeś problem.

Rekordy DNS — rubryki w książce telefonicznej

Książka telefoniczna ma różne rubryki: numer domowy, komórkowy, adres. DNS też. Typ rekordu podajesz po nazwie.

A — adres IPv4. To, co już widziałeś.

AAAA — adres IPv6. Cztery A, bo adres jest cztery razy dłuższy. Ktoś w komitecie miał poczucie humoru.

dig +short AAAA www.kurs.lab

2001:db8::80

CNAME — przezwisko. „Sklep” to tak naprawdę „www”. Biuro odsyła do prawdziwej nazwy, a potem podaje jej adres:

dig sklep.kurs.lab +noall +answer

sklep.kurs.lab.		300	IN	CNAME	www.kurs.lab.
www.kurs.lab.		300	IN	A	198.51.100.80

MX — kto odbiera pocztę dla domeny. Liczba to priorytet: mniejsza wygrywa.

dig MX kurs.lab +short

10 poczta.kurs.lab.

TXT — dowolny tekst. W praktyce: zabezpieczenia poczty (SPF, DKIM, DMARC) i potwierdzanie, że domena należy do Ciebie, kiedy podłączasz ją do Google Workspace albo Microsoftu.

dig TXT kurs.lab +short

"v=spf1 mx -all"

PTR — odwrotna książka: masz numer, szukasz nazwiska. Pytasz flagą -x:

dig -x 198.51.100.80 +short

www.kurs.lab.

Serwery pocztowe bardzo lubią PTR. Serwer bez poprawnego PTR wysyłający pocztę wygląda jak ktoś, kto dzwoni z zastrzeżonego numeru i mówi „wygrałeś samochód”.

TTL — time to live, termin ważności. Te 300 przy każdym rekordzie to sekundy, przez które inni mogą trzymać odpowiedź w pamięci i nie pytać ponownie. Jak data na jogurcie. Dlatego po zmianie adresu w DNS część świata widzi stary adres, dopóki TTL nie minie. Planujesz przeprowadzkę serwera? Dzień wcześniej zmniejsz TTL.

host i nslookup — kuzyni diga

host mówi krócej i po ludzku:

host www.kurs.lab
host -t MX kurs.lab
host 198.51.100.80

www.kurs.lab has address 198.51.100.80
www.kurs.lab has IPv6 address 2001:db8::80
kurs.lab mail is handled by 10 poczta.kurs.lab.
80.100.51.198.in-addr.arpa domain name pointer www.kurs.lab.

nslookup to dziadek, którego znajdziesz też w Windowsie. Dlatego warto go znać: na cudzym laptopie z Windowsem to często jedyne narzędzie DNS pod ręką.

nslookup sklep.kurs.lab

Server:		192.168.1.1
Address:	192.168.1.1#53

sklep.kurs.lab	canonical name = www.kurs.lab.
Name:	www.kurs.lab
Address: 198.51.100.80

curl, wget i nc — górne szczeble

Adres jest, DNS działa. Czy usługa odpowiada? nc -zv puka do okienka i nic nie mówi. -z to „tylko sprawdź”, -v to „powiedz, co wyszło”:

nc -zv www.kurs.lab 80
nc -zv www.kurs.lab 22

Connection to www.kurs.lab (198.51.100.80) 80 port [tcp/http] succeeded!
nc: connect to www.kurs.lab (198.51.100.80) port 22 (tcp) failed: Connection refused

Port 80 otwarty. Port 22: Connection refused, odmowa. To ważna informacja: serwer żyje i odpowiedział, tylko przy okienku 22 nikt nie siedzi. Porównaj z tym:

nc -zv -w 3 198.51.100.80 443

nc: connect to 198.51.100.80 port 443 (tcp) timed out: Operation now in progress

timed out to co innego: nikt nie odpowiedział w ogóle. Zwykle znaczy to, że ochroniarz, czyli zapora, po cichu wyrzuca pukających. Odmowa to zamknięte okienko. Cisza to ochroniarz w drzwiach. Na stronie strona ustawiłem taką cichą regułę na port 443. Zapory to temat lekcji 73.

[RHEL] nc pochodzi tam z pakietu nmap-ncat i jego komunikaty wyglądają trochę inaczej, ale -zv działa.

Na samej górze aplikacja. curl -I pyta serwer WWW tylko o nagłówki, bez całej strony:

curl -I http://www.kurs.lab/

HTTP/1.0 200 OK
Server: SimpleHTTP/0.6 Python/3.13.18
Content-type: text/html
Content-Length: 23

200 OK to sukces. 404 to brak strony, 301 lub 302 to przekierowanie, 500 to awaria po stronie serwera. A curl -v pokazuje całą rozmowę krok po kroku:

curl -v http://sklep.kurs.lab/

* Host sklep.kurs.lab:80 was resolved.
* IPv4: 198.51.100.80
*   Trying 198.51.100.80:80...
* Connected to sklep.kurs.lab (198.51.100.80) port 80
> GET / HTTP/1.1
> Host: sklep.kurs.lab
> User-Agent: curl/8.5.0
> Accept: */*
>
< HTTP/1.0 200 OK
< Server: SimpleHTTP/0.6 Python/3.13.18
<h1>Sklep kursowy</h1>

Zobacz, ile szczebli drabiny jest w jednym wyniku. was resolved, czyli DNS działa. Connected, czyli port działa. Linijki z > to, co wysłałeś. Z < to, co przyszło. Przy HTTPS zobaczysz jeszcze rozmowę o certyfikacie. curl -v to najlepszy przyjaciel admina strony.

wget służy głównie do pobierania plików, ale też powie, co się dzieje:

wget -O- http://www.kurs.lab/

Resolving www.kurs.lab (www.kurs.lab)... 198.51.100.80, 2001:db8::80
Connecting to www.kurs.lab (www.kurs.lab)|198.51.100.80|:80... connected.
HTTP request sent, awaiting response... 200 OK

-O- znaczy „wypisz na ekran zamiast zapisywać do pliku”. W skryptach przydaje się kod wyjścia: dla strony, której nie ma, wget kończy się kodem 8, czyli „serwer odpowiedział błędem”. Kciuk w dół z uzasadnieniem.

Jak to działa pod spodem

ping, traceroute i mtr używają protokołu ICMP, który służy do wiadomości serwisowych sieci: „odpowiedz”, „nie ma drogi”, „czas życia pakietu minął”. Linuksowy traceroute domyślnie wysyła pakiety UDP, a ICMP-em są odpowiedzi od ruterów. Licznik, który rutery odejmują, to pole TTL w nagłówku IP. To inne TTL niż to w DNS, nazwa ta sama, żebyś nie miał za łatwo.

I ważna różnica przy DNS. Programy, takie jak ping, curl czy przeglądarka, pytają o nazwy przez system, czyli przez kolejność z /etc/nsswitch.conf: najpierw /etc/hosts, potem DNS. A dig, host i nslookup pytają serwer DNS bezpośrednio i /etc/hosts w ogóle nie czytają. Sprawdzam. Dopisuję do /etc/hosts fałszywy adres dla www.kurs.lab:

echo '192.168.1.1 www.kurs.lab' | sudo tee -a /etc/hosts
getent ahostsv4 www.kurs.lab | head -1
ping -c1 www.kurs.lab | head -1
dig +short www.kurs.lab

192.168.1.1     STREAM www.kurs.lab
PING www.kurs.lab (192.168.1.1) 56(84) bytes of data.
198.51.100.80

Ping idzie na 192.168.1.1, bo słucha notesu. Dig mówi 198.51.100.80, bo pyta biuro numerów. Ten sam komputer, ta sama nazwa, dwie odpowiedzi. Jeśli „dig pokazuje dobrze, a strona i tak nie działa”, zajrzyj do /etc/hosts. Ktoś mógł tam zostawić wpis z testów sprzed pół roku.

Ściąga flag