Nastroje.md

# Nástroje Přehled toho, co použít, kdy a jak číst výstup. Systematický postup je v [diagnostice](Diagnostika) — tohle je referenční příručka. ## ping Nejzákladnější test. Pošle paket a čeká na odpověď. ```ping 8.8.8.8ping -c 4 seznam.cz          # jen čtyři paketyping -6 ipv6.google.com      # přes IPv6ping -M do -s 1472 8.8.8.8   # test MTU``` Co ti řekne odpověď: - **odpovídá** — cesta tam i zpátky funguje- **Request timeout** — nic nedorazilo, nebo se ztratila odpověď- **Destination host unreachable** — někdo na cestě neví, kudy dál, a řekl ti to- **Destination net unreachable** — totéž, ale o celé síti Pozor na dvě věci. Za prvé, spousta serverů ping ignoruje z principu, takže nedostat odpověď neznamená, že server neběží. Za druhé, ping měří kompletní okružní cestu — když je odezva vysoká, nevíš, na které straně. ## traceroute a mtr Ukáže, kudy paket letí. Využívá [TTL](Smerovani) — postupně posílá pakety s TTL 1, 2, 3 a sbírá stížnosti od routerů po cestě. ```traceroute 8.8.8.8           # Linux, macOStracert 8.8.8.8              # Windowstraceroute -T -p 443 seznam.cz   # přes TCP, prochází firewally``` `mtr` je traceroute, který běží pořád dokola a počítá statistiku. Pro hledání ztrátovosti je nesrovnatelně lepší: ```mtr 8.8.8.8mtr -c 500 -r 8.8.8.8        # 500 cyklů, textový reportmtr -6 -c 500 -r ipv6.google.com``` ### Jak číst výstup Tohle je místo, kde se dělá nejvíc chyb. **Hvězdičky uprostřed cesty nic neznamenají.** Ten router prostě neodpovídá na ping, protože to má nastavené jako nejnižší prioritu. Pokud se provoz dostane dál, je všechno v pořádku. **Ztrátovost na jednom uzlu, která se dál neopakuje, taky nic neznamená.** Ze stejného důvodu. **Ztrátovost, která začne na nějakém uzlu a pokračuje až do konce, je skutečný problém.** Tohle hledáš. **Skok v latenci je normální**, když trasa jde přes oceán nebo mezi poskytovateli. Podezřelé je až to, když latence vyskočí a už neklesne, aniž by se změnila geografie. ## dig Nástroj na DNS. Zapomeň na `nslookup`, `dig` je lepší ve všem. ```dig seznam.cz                 # A záznamdig seznam.cz AAAA            # IPv6dig seznam.cz MX              # poštadig @8.8.8.8 seznam.cz        # dotaz na konkrétní serverdig +short seznam.cz          # jen odpověď, bez balastudig +trace seznam.cz          # celá cesta hierarchií od kořenedig -x 8.8.8.8                # zpětný překlad``` Nejužitečnější trik je porovnat vlastní resolver s cizím. Když `dig @8.8.8.8` funguje a `dig` bez parametru ne, máš rozbitý resolver, ne DNS obecně. `+trace` je nedocenitelný, když ladíš vlastní doménu — ukáže přesně, na které úrovni hierarchie se to láme. ## nmap Zjistí, co je na daném stroji dostupné. ```nmap -Pn 192.168.1.10          # běžné portynmap -p- 192.168.1.10          # všech 65535, trvá to minutynmap -sV -p 443 example.com    # jaká verze čeho tam běžínmap -sn 192.168.1.0/24        # kdo všechno je v síti``` Přepínač `-Pn` znamená „nepinguj napřed, jen skenuj". Bez něj nmap přeskočí stroje, které neodpovídají na ping, což jsou dnes skoro všechny Windows. Poslední řádek je mimochodem nejrychlejší způsob, jak zjistit, co ti vlastně v síti běží. Doporučuju spustit — většina lidí je překvapená. Skenuj jen vlastní sítě a stroje, ke kterým máš oprávnění. ## ss a netstat Co poslouchá na tomhle stroji a jaká spojení jsou otevřená. ```ss -tulpn                     # Linux: poslouchající TCP i UDP s procesyss -tn state established      # aktivní spojenínetstat -ano                  # Windowslsof -i -P -n                 # macOS``` Souvislosti jsou v [porty a spojení](Porty-a-spojeni). ## tcpdump Když všechno ostatní selže, podívej se, co skutečně letí po drátě. Strmější křivka učení, ale nic jiného ti neřekne pravdu. ```tcpdump -i eth0 -n                          # všechno, bez překladu jmentcpdump -i eth0 -n host 192.168.1.10        # jen provoz s tímhle strojemtcpdump -i eth0 -n port 53                  # jen DNStcpdump -i eth0 -n icmp                     # jen pingtcpdump -i eth0 -n arp                      # jen ARPtcpdump -i eth0 -w zaznam.pcap              # do souboru pro Wireshark``` Typické použití: zapneš tcpdump na routeru, vyvoláš problém a díváš se, jestli pakety vůbec dorazily. To jediné rozliší „firewall to zahodil" od „nikdy to nepřišlo", což jsou dvě úplně jiné diagnózy. Pro vizuální analýzu ulož do souboru a otevři ve **Wiresharku**. Ten umí skládat TCP spojení dohromady a ukázat celý průběh. ## iperf3 Měření skutečné propustnosti mezi dvěma body. ```iperf3 -s                     # serveriperf3 -c 192.168.1.10        # klientiperf3 -c 192.168.1.10 -R     # opačný směriperf3 -c 192.168.1.10 -u -b 100M   # UDP, pro test ztrátovosti``` Tohle je jediný poctivý způsob, jak změřit domácí síť. Speedtest v prohlížeči měří cestu k cizímu serveru a míchá do toho poskytovatele. Když ti iperf3 mezi dvěma stroji v LAN ukáže 940 Mb/s, máš zdravý gigabit. Když ukáže 300, hledej kabel nebo poloduplex. ## curl Univerzální nástroj na testování HTTP a nejen jeho. ```curl -v https://seznam.cz                    # celý průběh včetně TLScurl -I https://seznam.cz                    # jen hlavičkycurl -4 https://ifconfig.co                  # moje veřejná IPv4curl -6 https://ifconfig.co                  # moje veřejná IPv6curl --resolve seznam.cz:443:1.2.3.4 https://seznam.cz   # obejít DNS``` Ten poslední trik je zlatý při stěhování webu — otestuješ nový server na správné doméně ještě předtím, než přepneš DNS. ## Rychlá referenční tabulka | Chci zjistit | Použij ||---|---|| Je to vůbec dostupné? | `ping` || Kudy to jde a kde se to ztrácí? | `mtr` || Překládá se jméno? | `dig` || Co je na tom stroji otevřené? | `nmap` || Co poslouchá u mě? | `ss -tulpn` || Dorazily pakety vůbec? | `tcpdump` || Jak je to rychlé? | `iperf3` || Co odpovídá webserver? | `curl -v` || Jaká je moje veřejná adresa? | `curl ifconfig.co` |