Pokud jste někdy pracovali v síťovém prostoru nebo na podpoře, pravděpodobně máte dobré příběhy týkající se odstraňování problémů se ztraceným připojením. Nevyhnutelně je nainstalován a konfigurován nějaký nový systém, ale nemůžeme zajistit, aby provoz přecházel do systému nebo ze systému.
Jeden takový příběh, který si pamatuji, zní asi takto.
Případ použití
Řešil jsem řešení back-endového úložného pole, které právě nainstalovala velká známá americká finanční korporace. Zákazník se pokoušel nakonfigurovat replikaci dat ze své produkční lokality (PROD) v Houstonu na lokalitu pro obnovu po havárii (DR) v San Antoniu. Systém obnovy po havárii byl již dlouho implementován a měl pověst známé dobré konfigurace.
Místo výroby bylo zcela nové a samozřejmě bylo příčinou všech našich problémů. Skutečným problémem bylo, že jsme nebyli schopni přesunout provoz mezi dvěma replikačními rozhraními, která jsme nakonfigurovali. Byli jsme schopni dosáhnout mimo bránu na webu DR, ale nebyli jsme schopni dosáhnout mimo web PROD. Provoz narážel na zařízení brány a byl vynechán.
Během půl hodiny od odstraňování problémů jsem se klienta zeptal, zda má na webu PROD firewall, který by mohl blokovat provoz na potřebných portech. "Samozřejmě ne, mezi těmito stránkami není žádný firewall." Tato odpověď byla šokující vzhledem k tomu, že se jednalo o jednu z největších finančních institucí v celé zemi. Ale stejně jako všechny pozice, které stojí před zákazníky, musíte být zdvořilí a zdvořilí.
Takže jsem prošel každou kontrolu, na kterou jsem z mé strany pomyslel. Firewall interního úložiště zakázán:zkontrolujte. Porty otevřené z DR do PROD:zkontrolujte. Porty otevřené z PROD do DR? Ne.
Ukázalo se, že po čtyřech hodinách odstraňování problémů a překonfigurování rozhraní zákazník řekl:"Dovolte mi, abych zavolal našemu firewallu."
Jaký jsi chlap?
To je divná pozice, kterou jste si najali, protože jste uvážili, že mezi těmito stránkami nemáte firewall. Ale nebylo to divné, protože samozřejmě měli firewall. Problém vyřešen. Nyní, když noční můra skončila, nástroje, které jsem použil, abych zjistil, kde k problému došlo, byly starý dobrý Telnet (kterému se můžeme věnovat v pozdějším článku) a samozřejmě traceroute .
Příkaz
Nyní, když vidíte jasný případ použití pro traceroute , promluvme si o příkazu samotném a o tom, jaké informace z něj můžete získat. Účelem tohoto článku je koneckonců, abyste získali trochu více znalostí o nástroji, který traceroute nabídky.
Syntaxe je poměrně jednoduchá. Příkaz traceroute <x> (x zde je IP nebo název hostitele) je nejzákladnější verze a začne posílat pakety na určený cíl. Tento výsledek vám umožní sledovat cestu paketů odeslaných z vašeho počítače do každého ze systémů mezi vámi a požadovaným cílem.
Pokud bych například chtěl sledovat cestu ze svého počítače na google.com , zadal bych něco takového:
[root@rhel8dev ~]# traceroute www.google.com
traceroute to www.google.com (216.58.194.100), 30 hops max, 60 byte packets
1 _gateway (192.168.2.1) 2.396 ms 2.726 ms 3.057 ms
2 145.sub-66-174-43.myvzw.com (66.174.43.145) 119.355 ms 119.315 ms 119.508 ms
3 * * *
4 10.209.189.140 (10.209.189.140) 120.321 ms 119.836 ms 120.009 ms
5 66.sub-69-83-106.myvzw.com (69.83.106.66) 119.042 ms 119.489 ms 119.156 ms
6 2.sub-69-83-107.myvzw.com (69.83.107.2) 120.039 ms 125.954 ms 101.450 ms
7 112.sub-69-83-96.myvzw.com (69.83.96.112) 110.757 ms 108.485 ms 122.108 ms
8 112.sub-69-83-96.myvzw.com (69.83.96.112) 115.028 ms 121.073 ms 125.537 ms
9 116.sub-69-83-96.myvzw.com (69.83.96.116) 121.793 ms 124.769 ms 124.434 ms
10 Bundle-Ether10.GW6.DFW13.ALTER.NET (140.222.237.123) 128.082 ms 128.400 ms 126.509 ms
11 google-gw.customer.alter.net (204.148.43.118) 106.276 ms 107.885 ms 105.718 ms
12 108.170.252.129 (108.170.252.129) 99.725 ms 101.797 ms 108.170.252.161 (108.170.252.161) 101.671 ms
13 108.170.230.109 (108.170.230.109) 101.207 ms 100.515 ms 99.730 ms
14 dfw06s48-in-f100.1e100.net (216.58.194.100) 99.059 ms 94.502 ms 94.015 ms
[root@rhel8dev ~]# Rozdělení
Pojďme si tyto výsledky rozdělit na menší sousta. Tento příkaz může produkovat spoustu informací a jak se říká:„Nejlepší způsob, jak sníst slona, je jedno sousto po druhém.“
[root@rhel8dev ~]# traceroute www.google.com
traceroute to www.google.com (216.58.194.100), 30 hops max, 60 byte packets
1 _gateway (192.168.2.1) 2.396 ms 2.726 ms 3.057 ms Tady se díváme jen na první skok. Tento poskok však můžeme použít k rozebrání informací, které jsou na displeji. Nejprve vidíme, co se skutečně odesílá a kam:
traceroute to www.google.com(IP), 30 hops max, 60 byte packets
Z tohoto výstupu zjistíme, že provoz posíláme na požadovaný cíl (www.google.com ). Traceroute standardně měří 30 skoků 60bajtových paketů.
Dále vidíme první skok. Zde narážíme na externí bránu:
1 _gateway (192.168.2.1) 2.396 ms 2.726 ms 3.057 ms
Zde můžete zjistit, kam vlastně skočit jeden, a pak jsou zde tři číselné hodnoty. Ty jsou známé jako Round-Trip Time (RTT), což označuje dobu, kterou daný paket potřebuje, než dosáhne svého cíle a nasměruje zprávu ICMP zpět ke zdroji. Ve výchozím nastavení traceroute směruje tři pakety dat pro testování každého skoku. Více informací o tomto procesu můžete najít online, ale to, že každý paket směruje chybovou zprávu ICMP zpět ke zdroji, když se dostane k zařízení v síti. Tato akce umožňuje traceroute k určení RTT daného paketu a nemusí nutně znamenat chybu.
Nyní se podívejme na skoky 2 až 4:
2 145.sub-66-174-43.myvzw.com (66.174.43.145) 109.206 ms 109.400 ms 109.423 ms
3 * * *
4 10.209.189.140 (10.209.189.140) 124.793 ms 123.585 ms 124.585 ms Můžeme zde vidět něco nového. Hop 2 vypadá normálně:Zařízení je zasaženo časy RTT v rozsahu 100 milisekund. Pak to začne být zajímavé. Vidíme pouze hvězdy (*).
Co tyto hvězdy (hvězdičky) znamenají? Byly pakety zahozeny? Vypršel jim časový limit?
Nech mě to vysvětlit. Pokud jde o tyto hvězdy, existují dvě možnosti. Za prvé, ICMP/UDP nemusí být nakonfigurováno. Pokud traceroute příkaz se úspěšně dokončí a uvidíte tyto hvězdičky, s největší pravděpodobností zařízení, které bylo zasaženo, nebylo nakonfigurováno tak, aby odpovídalo na provoz ICMP/UDP. Tento výsledek neznamená, že provoz nebyl předán. Druhou možností je, že pakety byly zahozeny kvůli problému v síti. Tyto výsledky jsou obvykle časové limity paketů nebo byl provoz blokován firewallem.
Jak můžete vidět ve výše uvedeném příkladu, i poté, co vidíme hvězdičky na skoku 2, pakety pokračují a jsou směrovány zpět ve skoku 4. Toto chování vede k úspěšnému traceroute jak vidíme, že Google byl dosažen.
Stánek s sebou
Traceroute může být neocenitelným nástrojem, pokud jde o řešení problémů se sítí. Opravdu pomáhá představit si, kde se problém skutečně vyskytuje. V zákulisí traceroute samozřejmě probíhají další operace které zde nebyly uvedeny.
Vřele doporučuji, pokud se chcete ještě více do hloubky podívat na tento nástroj, abyste provedli průzkum online. Existuje mnoho informací o Time-to-Live (TTL) a RTT, které v zájmu času nebyly zahrnuty v tomto článku. Mým cílem je, abyste nyní lépe porozuměli tomu, kdy a proč byste měli používat traceroute a jak interpretovat data, která nabízí. Další informace o řešení problémů se sítí a konceptech naleznete v našich souvisejících článcích zde.