Když jsem pracoval v roli zaměřené na sítě, jednou z největších výzev vždy bylo překlenout propast mezi síťovým a systémovým inženýrstvím. Sysadmins, kteří nemají přehled o síti, často obviňují síť z výpadků nebo podivných problémů. Síťoví administrátoři, neschopní ovládat servery a unavení postojem k síti „vinen, dokud se neprokáže nevina“, často obviňují koncové body sítě.
Obviňování samozřejmě problémy neřeší. Pokud si uděláte čas na pochopení základů něčí domény, může to vést ke zlepšení vztahů s ostatními týmy a rychlejšímu řešení problémů. Tato skutečnost platí zejména pro systémové správce. Když budeme mít základní znalosti o odstraňování problémů se sítí, můžeme našim kolegům ze sítě přinést silnější důkazy, když máme podezření, že síť může být na vině. Podobně můžeme často ušetřit čas tím, že některé počáteční řešení problémů provedeme sami.
V tomto článku se budeme zabývat základy řešení problémů se sítí pomocí příkazového řádku systému Linux.
Rychlý přehled modelu TCP/IP
Nejprve se na chvíli podívejme na základy síťového modelu TCP/IP. Zatímco většina lidí používá k diskusi o teorii sítě model OSI (Open Systems Interconnection), model TCP/IP přesněji reprezentuje sadu protokolů, které jsou nasazeny v moderních sítích.
Vrstvy v modelu sítě TCP/IP v pořadí zahrnují:
- Vrstva 5: Aplikace
- Vrstva 4: Doprava
- Vrstva 3: Síť/internet
- Vrstva 2: Datový odkaz
- Vrstva 1: Fyzický
Předpokládám, že jste s tímto modelem obeznámeni, a budete pokračovat diskusí o způsobech řešení problémů na vrstvě zásobníku 1 až 4. Kde začít s řešením problémů, závisí na situaci. Například, pokud můžete SSH na server, ale server se nemůže připojit k databázi MySQL, problém pravděpodobně nebude ve fyzické nebo datové vrstvě na místním serveru. Obecně platí, že je dobré postupovat směrem dolů. Začněte s aplikací a poté postupně řešte problémy s každou nižší vrstvou, dokud problém neodhalíte.
S tímto pozadím z cesty přejdeme na příkazový řádek a začněme odstraňování problémů.
Vrstva 1:Fyzická vrstva
Fyzickou vrstvu často považujeme za samozřejmost ("Ujistili jste se, že je kabel zapojen?"), ale problémy s fyzickou vrstvou můžeme snadno vyřešit z příkazového řádku Linuxu. To je, pokud máte k hostiteli konektivitu konzoly, což nemusí být případ některých vzdálených systémů.
Začněme tou nejzákladnější otázkou:Je naše fyzické rozhraní funkční? ip link show příkaz nám říká:
# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:82:d6:6e brd ff:ff:ff:ff:ff:ff
Všimněte si indikace DOWN ve výše uvedeném výstupu pro rozhraní eth0. Tento výsledek znamená, že vrstva 1 nenastane. Můžeme zkusit problém vyřešit kontrolou kabeláže nebo vzdáleného konce připojení (např. přepínače).
Než však začnete kontrolovat kabely, je dobré se ujistit, že rozhraní není pouze deaktivováno. Vydáním příkazu k vyvolání rozhraní můžete tento problém vyloučit:
# ip link set eth0 up
Výstup ip link show může být obtížné analyzovat na rychlý pohled. Naštěstí -br switch vytiskne tento výstup v mnohem čitelnějším formátu tabulky:
# ip -br link show
lo UNKNOWN 00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
eth0 UP 52:54:00:82:d6:6e <BROADCAST,MULTICAST,UP,LOWER_UP>
Vypadá to, že ip link set eth0 up udělal trik a eth0 je zpět v podnikání.
Tyto příkazy jsou skvělé pro řešení zjevných fyzických problémů, ale co zákeřnější problémy? Rozhraní mohou vyjednávat nesprávnou rychlostí nebo kolize a problémy s fyzickou vrstvou mohou způsobit ztrátu nebo poškození paketů, což má za následek nákladné opakované přenosy. Jak začneme s odstraňováním těchto problémů?
Můžeme použít -s příznak s ip příkaz pro tisk dalších statistik o rozhraní. Níže uvedený výstup ukazuje většinou čisté rozhraní s pouze několika zahozenými přijatými pakety a bez dalších známek problémů s fyzickou vrstvou:
# ip -s link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether 52:54:00:82:d6:6e brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
34107919 5808 0 6 0 0
TX: bytes packets errors dropped carrier collsns
434573 4487 0 0 0 0
Pro pokročilejší odstraňování problémů s vrstvou 1, ethtool utility je skvělá volba. Zvláště dobrým případem použití tohoto příkazu je kontrola, zda rozhraní vyjednalo správnou rychlost. Rozhraní, které vyjednalo špatnou rychlost (např. 10Gb/s rozhraní, které uvádí pouze 1Gb/s rychlost), může být indikátorem problému s hardwarem/kabeláží nebo nesprávnou konfigurací vyjednávání na jedné straně linky (např. špatně nakonfigurovaný port přepínače).
Naše výsledky mohou vypadat takto:
# ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: on (auto)
Supports Wake-on: d
Wake-on: d
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
Všimněte si, že výše uvedený výstup ukazuje linku, která byla správně vyjednána na rychlost 1000 Mb/s a plně duplexní.
Vrstva 2:Propojovací vrstva
Linková vrstva je zodpovědná za místní připojení k síti; v podstatě jde o komunikaci rámců mezi hostiteli ve stejné doméně vrstvy 2 (běžně nazývané místní síť). Nejrelevantnějším protokolem vrstvy 2 pro většinu systémových administrátorů je protokol ARP (Address Resolution Protocol), který mapuje adresy IP vrstvy 3 na adresy MAC ethernetové vrstvy 2. Když se hostitel pokusí kontaktovat jiného hostitele ve své místní síti (jako je výchozí brána), má pravděpodobně IP adresu druhého hostitele, ale nezná MAC adresu druhého hostitele. ARP tento problém řeší a MAC adresu zjistí za nás.
Běžným problémem, se kterým se můžete setkat, je položka ARP, která se nevyplní, zejména pro výchozí bránu vašeho hostitele. Pokud váš localhost nedokáže úspěšně vyřešit MAC adresu své brány na vrstvě 2, nebude moci odesílat žádný provoz do vzdálených sítí. Tento problém může být způsoben nesprávnou IP adresou nakonfigurovanou pro bránu, nebo se může jednat o jiný problém, například špatně nakonfigurovaný port přepínače.
Záznamy v naší tabulce ARP můžeme zkontrolovat pomocí ip neighbor příkaz:
# ip neighbor show
192.168.122.1 dev eth0 lladdr 52:54:00:11:23:84 REACHABLE
Všimněte si, že adresa MAC brány je vyplněna (o tom, jak bránu najít, si povíme více v další části). Pokud by došlo k problému s ARP, pak bychom viděli selhání rozlišení:
# ip neighbor show
192.168.122.1 dev eth0 FAILED
Další běžné použití ip neighbor příkaz zahrnuje manipulaci s tabulkou ARP. Představte si, že váš síťový tým právě nahradil upstream router (což je výchozí brána vašeho serveru). MAC adresa se také mohla změnit, protože MAC adresy jsou hardwarové adresy, které jsou přiřazeny ve výrobě.
Poznámka: Zatímco jedinečné adresy MAC jsou zařízením přiřazeny ve výrobě, je možné je změnit nebo podvrhnout. Mnoho moderních sítí často také používá protokoly, jako je Virtual Router Redundancy Protocol (VRRP), které používají vygenerovanou MAC adresu.
Linux ukládá položku ARP po určitou dobu do mezipaměti, takže možná nebudete moci odesílat provoz na vaši výchozí bránu, dokud nevyprší časový limit položky ARP pro vaši bránu. U vysoce důležitých systémů je tento výsledek nežádoucí. Naštěstí můžete ručně odstranit položku ARP, což vynutí nový proces zjišťování ARP:
# ip neighbor show
192.168.122.170 dev eth0 lladdr 52:54:00:04:2c:5d REACHABLE
192.168.122.1 dev eth0 lladdr 52:54:00:11:23:84 REACHABLE
# ip neighbor delete 192.168.122.170 dev eth0
# ip neighbor show
192.168.122.1 dev eth0 lladdr 52:54:00:11:23:84 REACHABLE
Ve výše uvedeném příkladu vidíme vyplněnou položku ARP pro 192.168.122.70 na eth0. Poté odstraníme položku ARP a uvidíme, že byla odstraněna z tabulky.
Vrstva 3:Síťová/internetová vrstva
Vrstva 3 zahrnuje práci s IP adresami, které by měl znát každý správce systému. IP adresování poskytuje hostitelům způsob, jak se dostat k jiným hostitelům, kteří jsou mimo jejich místní síť (ačkoli je často používáme i v místních sítích). Jedním z prvních kroků k řešení problémů je kontrola místní IP adresy počítače, což lze provést pomocí ip address příkaz, opět pomocí -br příznak pro zjednodušení výstupu:
# ip -br address show
lo UNKNOWN 127.0.0.1/8 ::1/128
eth0 UP 192.168.122.135/24 fe80::184e:a34d:1d37:441a/64 fe80::c52f:d96e:a4a2:743/64
Vidíme, že naše rozhraní eth0 má IPv4 adresu 192.168.122.135. Pokud bychom neměli IP adresu, chtěli bychom tento problém vyřešit. Chybějící IP adresa může být způsobena místní chybnou konfigurací, jako je nesprávný konfigurační soubor síťového rozhraní, nebo může být způsobena problémy s DHCP.
Nejběžnějším nástrojem první linie, který většina správců systému používá k odstraňování problémů s vrstvou 3, je ping užitečnost. Ping odešle paket ICMP Echo Request vzdálenému hostiteli a na oplátku očekává odpověď ICMP Echo Reply. Pokud máte problémy s připojením ke vzdálenému hostiteli, ping je běžný nástroj pro zahájení odstraňování problémů. Provedení jednoduchého pingu z příkazového řádku posílá ICMP echa vzdálenému hostiteli neomezeně dlouho; budete muset CTRL+C ukončit ping nebo předat -c <num pings> vlajka, takhle:
# ping www.google.com
PING www.google.com (172.217.165.4) 56(84) bytes of data.
64 bytes from yyz12s06-in-f4.1e100.net (172.217.165.4): icmp_seq=1 ttl=54 time=12.5 ms
64 bytes from yyz12s06-in-f4.1e100.net (172.217.165.4): icmp_seq=2 ttl=54 time=12.6 ms
64 bytes from yyz12s06-in-f4.1e100.net (172.217.165.4): icmp_seq=3 ttl=54 time=12.5 ms
^C
--- www.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 12.527/12.567/12.615/0.036 ms
Všimněte si, že každý ping zahrnuje dobu, kterou trvalo přijetí odpovědi. Při ping může být snadným způsobem, jak zjistit, zda je hostitel naživu a reaguje, v žádném případě to není definitivní. Mnoho síťových operátorů blokuje pakety ICMP jako bezpečnostní opatření, ačkoli mnoho dalších s touto praxí nesouhlasí. Dalším běžným problémem je spoléhání se na časové pole jako přesný indikátor latence sítě. Pakety ICMP mohou být omezeny rychlostí mezilehlého síťového zařízení a nemělo by se na ně spoléhat, že poskytnou skutečnou reprezentaci latence aplikace.
Dalším nástrojem v pásu nástrojů pro odstraňování problémů vrstvy 3 je traceroute příkaz. Traceroute využívá pole Time to Live (TTL) v IP paketech k určení cesty, kterou provoz vede ke svému cíli. Traceroute bude odesílat jeden paket po druhém, počínaje TTL o jedné. Protože platnost paketu vyprší při přenosu, upstream router odešle zpět paket ICMP Time-to-Live Exceeded. Traceroute pak zvýší TTL, aby určil další skok. Výsledným výstupem je seznam zprostředkujících směrovačů, kterými paket prošel na své cestě k cíli:
# traceroute www.google.com
traceroute to www.google.com (172.217.10.36), 30 hops max, 60 byte packets
1 acritelli-laptop (192.168.122.1) 0.103 ms 0.057 ms 0.027 ms
2 192.168.1.1 (192.168.1.1) 5.302 ms 8.024 ms 8.021 ms
3 142.254.218.133 (142.254.218.133) 20.754 ms 25.862 ms 25.826 ms
4 agg58.rochnyei01h.northeast.rr.com (24.58.233.117) 35.770 ms 35.772 ms 35.754 ms
5 agg62.hnrtnyaf02r.northeast.rr.com (24.58.52.46) 25.983 ms 32.833 ms 32.864 ms
6 be28.albynyyf01r.northeast.rr.com (24.58.32.70) 43.963 ms 43.067 ms 43.084 ms
7 bu-ether16.nycmny837aw-bcr00.tbone.rr.com (66.109.6.74) 47.566 ms 32.169 ms 32.995 ms
8 0.ae1.pr0.nyc20.tbone.rr.com (66.109.6.163) 27.277 ms * 0.ae4.pr0.nyc20.tbone.rr.com (66.109.1.35) 32.270 ms
9 ix-ae-6-0.tcore1.n75-new-york.as6453.net (66.110.96.53) 32.224 ms ix-ae-10-0.tcore1.n75-new-york.as6453.net (66.110.96.13) 36.775 ms 36.701 ms
10 72.14.195.232 (72.14.195.232) 32.041 ms 31.935 ms 31.843 ms
11 * * *
12 216.239.62.20 (216.239.62.20) 70.011 ms 172.253.69.220 (172.253.69.220) 83.370 ms lga34s13-in-f4.1e100.net (172.217.10.36) 38.067 ms
Traceroute vypadá jako skvělý nástroj, ale je důležité pochopit jeho omezení. Stejně jako u ICMP mohou zprostředkující směrovače filtrovat pakety, které traceroute spoléhá na, jako je zpráva ICMP Time-to-Live Exceeded. Ale co je důležitější, trasa, kterou provoz vede do az cíle, nemusí být nutně symetrická a není vždy stejná. Traceroute vás může svést k tomu, že si budete myslet, že váš provoz vede do cíle a zpět po pěkné lineární cestě. Tato situace však nastává jen zřídka. Provoz může sledovat jinou zpáteční cestu a trasy se mohou dynamicky měnit z mnoha důvodů. Zatímco traceroute může poskytovat přesné reprezentace cesty v malých podnikových sítích, často to není přesné při pokusu o trasování ve velkých sítích nebo na internetu.
Dalším běžným problémem, se kterým se pravděpodobně setkáte, je absence upstream brány pro konkrétní trasu nebo absence výchozí trasy. Když je paket IP odeslán do jiné sítě, musí být odeslán do brány k dalšímu zpracování. Brána by měla vědět, jak směrovat paket do jeho konečného cíle. Seznam bran pro různé cesty je uložen v směrovací tabulce , které lze kontrolovat a manipulovat s nimi pomocí ip route příkazy.
Směrovací tabulku můžeme vytisknout pomocí ip route show příkaz:
# ip route show
default via 192.168.122.1 dev eth0 proto dhcp metric 100
192.168.122.0/24 dev eth0 proto kernel scope link src 192.168.122.135 metric 100
Jednoduché topologie mají často pouze nakonfigurovanou výchozí bránu, kterou představuje položka „výchozí“ v horní části tabulky. Chybějící nebo nesprávná výchozí brána je běžný problém.
Pokud je naše topologie složitější a požadujeme různé trasy pro různé sítě, můžeme zkontrolovat trasu pro konkrétní prefix:
# ip route show 10.0.0.0/8
10.0.0.0/8 via 192.168.122.200 dev eth0
Ve výše uvedeném příkladu posíláme veškerý provoz směřující do sítě 10.0.0.0/8 na jinou bránu (192.168.122.200).
I když nejde o protokol vrstvy 3, stojí za zmínku DNS, když mluvíme o IP adresování. Domain Name System (DNS) mimo jiné překládá IP adresy na názvy čitelné pro člověka, jako je www.redhat.com . Problémy s DNS jsou extrémně časté a jejich řešení je někdy neprůhledné. O DNS bylo napsáno mnoho knih a online průvodců, ale zde se zaměříme na základy.
Signálem potíží s DNS je možnost připojit se ke vzdálenému hostiteli pomocí IP adresy, ale nikoli jeho názvu hostitele. Provedení rychlého nslookup na název hostitele nám může říct docela dost (nslookup je součástí bind-utils balíček na systémech založených na Linuxu Red Hat Enterprise):
# nslookup www.google.com
Server: 192.168.122.1
Address: 192.168.122.1#53
Non-authoritative answer:
Name: www.google.com
Address: 172.217.3.100
Výstup výše ukazuje server, na kterém bylo vyhledávání provedeno proti 192.168.122.1 a výsledná IP adresa byla 172.217.3.100.
Pokud provedete nslookup pro hostitele, ale ping nebo traceroute zkuste použít jinou IP adresu, pravděpodobně se díváte na problém se zadáním hostitelského souboru. V důsledku toho zkontrolujte hostitelský soubor, zda neobsahuje problémy:
# nslookup www.google.com
Server: 192.168.122.1
Address: 192.168.122.1#53
Non-authoritative answer:
Name: www.google.com
Address: 172.217.12.132
# ping -c 1 www.google.com
PING www.google.com (1.2.3.4) 56(84) bytes of data.
^C
--- www.google.com ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
# cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
1.2.3.4 www.google.com
Všimněte si, že ve výše uvedeném příkladu je adresa www.google.com vyřešeno na 172.217.12.132. Když jsme se však pokusili pingnout hostitele, byl provoz odesílán na 1.2.3.4. Podívejte se na /etc/hosts soubor, můžeme vidět přepsání, které někdo musel nedbale přidat. Problémy s přepsáním hostitelského souboru jsou extrémní běžné, zvláště pokud pracujete s vývojáři aplikací, kteří často potřebují provést tato přepsání, aby otestovali svůj kód během vývoje.
Vrstva 4:Transportní vrstva
Transportní vrstva se skládá z protokolů TCP a UDP, přičemž TCP je protokol orientovaný na spojení a UDP je nespojovaný. Aplikace naslouchají na zásuvkách , které se skládají z IP adresy a portu. Provoz směřovaný na IP adresu na konkrétním portu bude jádrem směrován do naslouchací aplikace. Úplná diskuse o těchto protokolech přesahuje rámec tohoto článku, takže se zaměříme na řešení problémů s připojením na těchto vrstvách.
První věc, kterou možná budete chtít udělat, je zjistit, jaké porty naslouchají na localhostu. Výsledek může být užitečný, pokud se nemůžete připojit k určité službě na počítači, jako je web nebo SSH server. K dalšímu běžnému problému dochází, když se démon nebo služba nespustí, protože na portu naslouchá něco jiného. ss Příkaz je neocenitelný pro provádění těchto typů akcí:
# ss -tunlp4
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
udp UNCONN 0 0 *:68 *:* users:(("dhclient",pid=3167,fd=6))
udp UNCONN 0 0 127.0.0.1:323 *:* users:(("chronyd",pid=2821,fd=1))
tcp LISTEN 0 128 *:22 *:* users:(("sshd",pid=3366,fd=3))
tcp LISTEN 0 100 127.0.0.1:25 *:* users:(("master",pid=3600,fd=13))
Pojďme si tyto příznaky rozebrat:
- -t - Zobrazit porty TCP.
- -u – Zobrazit porty UDP.
- -n - Nepokoušejte se překládat názvy hostitelů.
- -l - Zobrazit pouze naslouchající porty.
- -p - Zobrazit procesy, které používají konkrétní soket.
- -4 – Zobrazit pouze zásuvky IPv4.
Když se podíváme na výstup, můžeme vidět několik poslechových služeb. sshd aplikace naslouchá na portu 22 na všech IP adresách, označených *:22 výstup.
ss command je mocný nástroj a přehled jeho stručné manuálové stránky vám může pomoci najít příznaky a možnosti, abyste našli, co hledáte.
Další běžný scénář řešení potíží zahrnuje vzdálené připojení. Představte si, že se váš místní počítač nemůže připojit ke vzdálenému portu, jako je MySQL na portu 3306. Nepravděpodobný, ale běžně instalovaný nástroj může být vaším přítelem při řešení těchto typů problémů:telnet . telnet příkaz se pokusí navázat TCP spojení s jakýmkoli hostitelem a portem, který mu zadáte. Tato funkce je ideální pro testování vzdálené konektivity TCP:
# telnet database.example.com 3306
Trying 192.168.1.10...
^C
Ve výstupu výše telnet visí, dokud to nezabijeme. Tento výsledek nám říká, že se nemůžeme dostat na port 3306 na vzdáleném počítači. Aplikace možná neposlouchá a musíme použít předchozí kroky pro odstraňování problémů pomocí ss na vzdáleném hostiteli – pokud máme přístup. Další možností je hostitelský nebo mezilehlý firewall, který filtruje provoz. Možná budeme muset spolupracovat se síťovým týmem na ověření připojení vrstvy 4 napříč cestou.
Telnet funguje dobře pro TCP, ale co UDP? netcat poskytuje jednoduchý způsob, jak zkontrolovat vzdálený port UDP:
# nc 192.168.122.1 -u 80
test
Ncat: Connection refused.
netcat nástroj lze použít pro mnoho dalších věcí, včetně testování TCP konektivity. Všimněte si, že netcat nemusí být ve vašem systému nainstalována a často se považuje za bezpečnostní riziko, když ji necháte ležet. Až budete s odstraňováním problémů hotovi, můžete zvážit jeho odinstalaci.
Výše uvedené příklady probíraly běžné, jednoduché nástroje. Mnohem výkonnějším nástrojem je však nmap . Celé knihy byly věnovány nmap funkčnost, takže se jí v tomto článku pro začátečníky nebudeme zabývat, ale měli byste vědět o některých věcech, které umí:
- Skenování portů TCP a UDP na vzdálených počítačích.
- Otisky prstů OS.
- Určení, zda jsou vzdálené porty uzavřeny nebo jednoduše filtrovány.
Zabalení
V tomto článku jsme se zabývali mnoha úvodními síťovými základy a propracovali jsme se k síťovému stacku od kabelů a přepínačů k IP adresám a portům. Zde diskutované nástroje by vám měly poskytnout dobrý výchozí bod pro řešení základních problémů s připojením k síti a měly by se ukázat jako užitečné při snaze poskytnout vašemu síťovému týmu co nejvíce podrobností.
Jak budete postupovat při řešení problémů se sítí, nepochybně narazíte na dříve neznámé příznaky příkazů, efektní jednoduché řádky a nové výkonné nástroje (tcpdump a Wireshark jsou mé oblíbené), abych se dostal do příčin vašich problémů se sítí. Bavte se a pamatujte:Balíčky nelžou!