Přidat článek mezi oblíbenéZasílat nové komentáře e-mailem Jak diagnostikujeme a řešíme problémy se síťovými připojeními - díl II., routing (směrování)

V předchozím díle jsme si řekli jak diagnostikovat a případně opravit problémy s TCP/IP stackem. V tom dnešním se budeme věnovat další zásadní věci IP sítí, kterou je routing (česky směrování). Trilogii pak uzavřeme posledním dílem věnovaným DNS.

Pokračujeme, kde jsme skončili

Naposledy jsme skončili v situaci, kdy jsme otestovali a případně opravili lokální TCP/IP stack a základním způsobem diagnostikovali další potenciální závady. Dnes pokračujeme testem konektivity vaší LAN do dalších subnetů.

Směr stanice Touha...

Sítě TCP/IP, jak už víme, se skládají z jednotlivých subnetů. Tyto subnety jsou propojeny routery (směrovači). V následující kapitolách nejprve popíšeme princip fungování a posléze i základní postupy testování a opravy. Předem se omlouvám za poněkud vyšší porci úvodní teorie, ta je nicméně nutným požadavkem pro pochopení funkčnosti směrování.

Základní stavební kameny směrování

Celý proces směrování je "vztahem" dvou komplementárních subjektů: samotného routeru (rovněž gateway, česky též směrovač či brána), který reprezentuje fyzickou topologii sítě a routovací tabulkou, která je jeho elektronickým ekvivalentem. Zní to podivně ;-), ale princip je jednoduchý a bude vysvětlen dále.

Víme už, že subnet je definován IP adresním rozsahem, přesněji řečeno sadou IP adres definovanou číslem sítě a maskou. Typicky v domácnostech a malých firmách se ponejvíce používá rozsahu 192.168.x.0/24 (kde "x" nabývá hodnot od 0 do 254). Mějme nyní hypotetickou situaci: na tomto subnetu existuje hostitel A, který chce odeslat data hostiteli B, schválně nespecifikuji, kde se hostitel B nachází. První, k čemu dojde, je zpětný překlad jména hostitele B na IP adresu. Jak k tomu dochází, záleží na použitém protokolu, buď je dotazován server DNS (většina případů), nebo se použije proprietární překlad pomocí vlastních prostředků protokolu (např. u NetBIOS to může být dotaz u BrowseMastera sítě, WINS serveru nebo už výše zmiňovaného DNS serveru). Resolving, jak dopředný, tak zpětný bude popsán ve třetí kapitole věnované DNS. A nyní to začne být zajímavé. V každém případě stack projde routovací tabulku a na jejím základě odešle paket vybraným rozhraním na vybraného hostitele.

Routovací tabulka

Routovací tabulka je seznam, ve kterém jsou uvedeny záznamy o tom, kam a kudy má systém poslat paket. Jedná se o celkem triviální záležitost, obsahem této tabulky jsou záznamy o cíli směrování, masce, bráně, rozhraní a metrice. Systém prochází jednotlivé záznamy, a pokud odpovídají adrese cílového hostitele B, použijí se informace nacházející se na daném řádku.

Než přikročíme k názorným ukázkám, řekneme si, jak zobrazit routovací tabulku. Na Windows systémech k tomu slouží příkaz route, speciálně pak pro výpis tabulky ve spojení s parametrem print. Kompletní nápovědu získáte zadáním samotného příkazu route, připadně můžete použít i nápovědu Windows XP, která je velmi dobře zpracována. Pro systémy postavené na GNU/Linux slouží k témuž rovněž příkaz route, ovšem bez parametru print. Namísto něj doporučuju použít přepínač -n, kterým zajistíte, že tabulka bude vypisována bez překladu IP adres na jmenné názvy (tedy podobně, jak je vypisována ve Windows a dle mého názoru lépe čitelně)

Nejjednodušší routovací tabulka vypadá takto:

C:\>route print
===========================================================================
Seznam rozhraní
0x1 ........................... MS TCP Loopback interface
0x2 ...00 0c 29 79 e7 f0 ...... AMD PCNET Family PCI Ethernet Adapter - Packet Scheduler Miniport
===========================================================================
===========================================================================
Aktivní směrování:
       Cíl v síti     Síťová maska            Brána        Rozhraní  Metrika
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
  255.255.255.255  255.255.255.255  255.255.255.255               2       1
===========================================================================
Trvalé trasy:
  Žádné

Toto je výpis routovací tabulky stroje, který má aktivní TCP/IP stack, ale nemá aktivní žádná fyzická síťová rozhraní (rozhraní č.2 je odpojeno). Jak je patrné, celá síť 127.0.0.0/8 je směrována na virtuální adaptér 127.0.0.1 přes loopback rozhraní 127.0.0.1. Jiné směrování není možné (a pomocí ping si to můžete sami ověřit)

Trochu zajímavější to bude, nainstalujete-li do systému nějaké rozhraní:

C:\Documents and Settings\user>route print
===========================================================================
Seznam rozhraní
0x1 ........................... MS TCP Loopback interface
0x2 ...00 0c 29 79 e7 f0 ...... AMD PCNET Family PCI Ethernet Adapter - Packet Scheduler Miniport
===========================================================================
===========================================================================
Aktivní směrování:
       Cíl v síti     Síťová maska            Brána        Rozhraní  Metrika
          0.0.0.0          0.0.0.0     192.168.10.1  192.168.10.225       10
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
     192.168.10.0    255.255.255.0   192.168.10.225  192.168.10.225       10
   192.168.10.225  255.255.255.255        127.0.0.1       127.0.0.1       10
   192.168.10.255  255.255.255.255   192.168.10.225  192.168.10.225       10
        224.0.0.0        240.0.0.0   192.168.10.225  192.168.10.225       10
  255.255.255.255  255.255.255.255   192.168.10.225  192.168.10.225       1
Výchozí brána:      192.168.10.1
===========================================================================
Trvalé trasy:
  Žádné

Jak je patrno, tabulka nám přidáním jednoho rozhraní pěkně nabobtnala. Pokusíme se ji společně interpretovat (POZOR, v případě Windows začínáme odspodu, u Linuxu zase odshora):
První řádek se samými 255 je tzv. limitovaný broadcast, který označuje v routovací tabulce existenci vlastního rozhraní hostitele (proto je také první; tj. komunikace vůči sobě samému není fyzicky směrována mimo počítač).
Řádek začínající 224.0.0.0 je směrovací záznam pro multicast (kdo chce vědět více, odkážu jej na wikipedii: Multicast_address ).
Řádky s cíli 192.168.10.255 označují směrování broadcastu, tj. vysílání paketů určených všem hostitelům na daném subnetu.
Analogicky řádek s cílem subnetu 192.168.10.0 (resp. 127.0.0.0 pro loopback) pak označuje jak mají být směrovány pakety do lokálního subnetu.
A konečně poslední řádek označuje výchozí směr, pokud není nalezena shoda v jiném řádku. Poznáte jej tak, že cíl je označen jako 0.0.0.0 a maska rovněž 0.0.0.0. Záznam je ještě jednou uveden pod položkou "Výchozí brána".

Speciálně bych zmínil položku metrika, která nalézá uplatnění ve složitějších sítích, a která určuje prioritu použití záznamu v případě, že se směruje přes více spojení. Lze tak určit "výhodnější" směr. Bohužel bližší popis (stejně jako popis směrovacích protokolů pro použití ve velkých WAN sítích) je nad rámec už tak hutného článku.

Nyní, když jsme si popsali významy jednotlivých řádků, bych rád uvedl přesnou interpretaci některých z nich a následně uvedl příklad spojení a aplikovaného směrovacího pravidla.

Vezměme tento řádek:

      Cíl v síti     Síťová maska            Brána        Rozhraní  Metrika
     192.168.10.0    255.255.255.0   192.168.10.225  192.168.10.225       10

Můžeme jej lidsky interpretovat takto:
"Pakety pro hostitele, kteří mají adresu v subnetu 192.168.10.0/24 (kombinace čísla subnetu a masky; adresy 192.168.10.1 až 192.168.10.254) směruj přes bránu 192.168.10.225 a totožné rozhraní. S ohledem na to, že adresa 192.168.10.225 je adresa našeho adaptéru, odesílají se data přímo hostiteli B."

Další, už složitější příklad:

       Cíl v síti     Síťová maska            Brána        Rozhraní  Metrika
          0.0.0.0          0.0.0.0     192.168.10.1  192.168.10.225       10

Interpretujeme následovně:
"Pakety pro hostitele, o nichž nemáme informace v jakém subnetu leží (0.0.0.0 s maskou 0 odpovídá celému adresnímu prostoru IP verze 4), předej bráně 192.168.10.1 přes své rozhraní 192.168.10.225. S ohledem na to, že nevíme nic o topologii sítě nebo sítí mimo náš subnet, musíme využít služeb směrovače v našem subnetu. Ten zařídi další spojení k hostiteli B."

Jako reálný příklad můžeme uvést paket, který chceme odeslat dvěma hostitelům B1 a B2, kteří mají adresy 192.168.10.10 a 195.32.47.5: hostiteli B1 lze odeslat paket přímo, protože z routovací tabulky je jasné, že hostitel B1 patří do stejného subnetu jako náš stroj A. S hostitelem B2 je to už horší, žádná z řádek na něj nesedí, vyjma poslední řádky, kterou je směr na výchozí bránu. Tudíž jediné, co může hostitel A udělat, je odeslat paket bráně 1921.168.10.1 a my můžeme doufat, že vše funguje jak má a paket dorazí do cíle.

Router

Nyní jsme narazili na samotný router. Zatím jsme jej nijak nedefinovali ani neřekli jak funguje. Pokusím se to tedy objasnit. Router je hostitel, který je připojen k alespoň dvěma subnetům a zároveň je schopen předávat pakety (tj. routovat či česky směrovat). Standardní hostitelé používající obecné operační systémy, jako Windows, Linux či BSD mají v základní konfiguraci předávání paketů vypnuté, je tedy třeba na místě toto zmínit. Vyjímečnost routeru tkví v tom, že "vidí" i jinou síť či jiné sítě a je i jejich součástí. Pokud byste si to chtěli geometricky představit, doporučuji analogii se dvěma kružnicemi, které se dotýkají v jednom bodě. Tento bod je pak součástí obou kružnic a když pojedete tužkou po jedné kružnici, musíte projít tímto bodem, abyste byli schopni přejít na kružnici druhou.

[82102-kruznice-png]

Router jako takový implementuje z hlediska funkčnosti naprosto totožnou směrovací tabulku jako každý jiný hostitel, rozdíl je v tom, že jeho tabulka obsahuje více záznamů, minimálně přibudou ty, které určují směr pro druhý (či další) subnet(y). Co se stane, obdrží-li router paket od hostitele A, umístěného v subnetu 192.168.10.0/24 pro hostitele B v subnetu 10.0.0.0/24 s adresou 10.0.0.138? Je to velmi podobné tomu, jak se chová samotný hostitel: Za předpokladu, že jedno z jeho rozhraní je součástí subnetu v němž se nachází hostitel B (tj. má odpovídající záznam v routovací tabulce), předá paket přímo hostiteli B. Za předpokladu, že žádné jeho rozhraní není součástí cílového subnetu, předá paket své výchozí bráně (prakticky každý router připojený k internetu musí mít svou výchozí bránu; příklad, kde není výchozí brána potřeba je izolovaná síť vytvořená ze dvou subnetů). Jak je vidět, celý proces s hledáním hostitele B se opakuje, jen na vyšší úrovni a probíhá, dokud existuje cesta (tj. dokud lze paket na základě routovací tabulky předat), nebo dokud nevyprší hodnota TTL (hostitelem A nastavená na 64), kterou každý router snižuje o jedničku). TTL hodnota je implementována z prostého důvodu: aby v síti nebloudili "bludní Holanďani" - pakety, jež není možno doručit kvůli zacyklení směrovacích tabulek (příklad směrování mezi hostiteli: A -> B -> C -> A -> ... )

Co je důležité

Každý hostitel musí mít alespoň jednu výchozí bránu, každý router musí znát (tj mít v routovací tabulce) alespoň dvě sítě a rovněž mít výchozí bránu.

Řešíme problémy

Nyní se, již vybaveni teoretickými základy, vrhněme na naši nefungující síť. V prvé řadě je třeba zkontrolovat, zda všichni hostitelé mají nastavenu správnou výchozí bránu. Ve windows to provedete pomocí už známého příkazu ipconfig

C:\>ipconfig

Konfigurace protokolu IP systému Windows


Adaptér sítě Ethernet Připojení k místní síti:

        Přípona DNS podle připojení . . . : testing
        Adresa IP . . . . . . . . . . . . : 192.168.10.225
        Maska podsítě . . . . . . . . . . : 255.255.255.0
        Výchozí brána . . . . . . . . . . : 192.168.10.1

jak je vidět, výchozí brána je nastavena. V naprosté většině případů bude brána nastavena pomocí protokolu DHCP, pokud si nejste jisti, použije detailnější výpis ipconfig /all, ve kterém lze dohledat, zda bylo použito DHCP, případně se podívejte na vlastnosti protokolu TCP/IP v nastavení síťového adaptéru.

[82104-network-png]

V případě, že je nastavení výchozí brány v pořádku, je možno bránu opingat, a přesto ping na IP adresu mimo náš subnet není úspěšný, je třeba upřít pozornost na samotný router. V první řadě zkontrolujte, že router je korektně připojen ke všem sítím jichž by měl být členem. Velmi často se stává, že např. DSL routery ztratí spojení s DSLAM, u WAN linek dochází k poruchám na spojové infrastruktuře apod. Pokud vše vypadá v pořádku, zkontrolujte routovací tabulku na routeru.

"Velké" systémy jako Windows či Linux si přidávají záznamy do routovací tabulky samy podle toho, jak se spouštějí jednotlivá síťová rozhraní. Oproti tomu například u některých verzí Cisco IOS (operační systém routerů Cisco) si systém routovací tabulku sám nemodifikuje a je třeba ruční úpravy konfigurace.

U typického "domácího" připojení je problém routování do značné míry omezen, protože WAN rozhraní routeru obdrží výchozí bránu, jakož i další informace v drtivé většině případů pomocí DHCP a nastavení počítačů v LAN se řídí opět pomocí DHCP, tudíž stačí nechat přednastavené hodnoty konfigurace a mělo by vše fungovat. V případě, že některá část sítě není spravována pomocí DHCP, doporučuji ověřit a zkontrolovat správnost a aktuálnost nastavení.

Takto jsme zkontrolovali první tzv. hop (tj. první přesměrování routerem). Co ale dělat v případě, když chyba není u nás, ale spojení přesto nefunguje? V takovém případě je nutno použít nástroj pro trasování cesty směrování. Tímto nástrojem je příkaz tracert (u Linuxu existuje obdoba traceroute v balíku iptools; případně můžete použít příkaz ping -R).

Typická ukázka (cíl je záměrně zvolen tak, že je nedostupný):

C:\>tracert -d 195.32.47.5

Výpis trasy k 195.32.47.5 s nejvýše 30 směrováními

  1    < 1 ms    < 1 ms    < 1 ms  192.168.10.1
  2    39 ms    38 ms    39 ms  88.123.201.71
  3    39 ms    40 ms    39 ms  88.123.202.17
  4     *        *        *     Vypršel časový limit žádosti.
  5     *        *        *     Vypršel časový limit žádosti.
  6    44 ms    42 ms    43 ms  80.188.33.246
  7    43 ms    42 ms    43 ms  80.188.33.245
  8    43 ms    43 ms    42 ms  194.228.21.32
  9    45 ms    43 ms    41 ms  194.228.21.90
 10     *        *        *     Vypršel časový limit žádosti.
 11     *        *        *     Vypršel časový limit žádosti.
 12     *        *        *     Vypršel časový limit žádosti.
 13  ^C

Zde je vidět, že pakety prošly dvanácti routery, ale třináctý hop byl už neúspěšný. Je třeba ovšem poznamenat, že samotné hvězdičky neznamenají neúspěch, to může znamenat i jen to, že daný router má ve firewallu zakázáno odesílat odpovídající ICMP informace o trasování s tím, že trasování probíhá dále. Viz následující příklad:

C:\>tracert -d 194.228.32.3

Výpis trasy k 194.228.32.3 s nejvýše 30 směrováními

  1    < 1 ms    < 1 ms    < 1 ms  192.168.10.1
  2    39 ms    38 ms    39 ms  88.123.201.71
  3    39 ms    40 ms    39 ms  88.123.202.17
  4     *        *        *     Vypršel časový limit žádosti.
  5     *        *        *     Vypršel časový limit žádosti.
  6    43 ms    42 ms    43 ms  80.188.33.246
  7    42 ms    42 ms    42 ms  80.188.33.245
  8    43 ms    42 ms    42 ms  194.228.21.32
  9    43 ms    42 ms    42 ms  194.228.21.102
 10    44 ms    55 ms    43 ms  194.228.37.219
 11     *        *        *     Vypršel časový limit žádosti.
 12    42 ms    43 ms    43 ms  194.228.32.3

Trasování bylo dokončeno.

Zde se dostavil úspěch, cíl byl nalezen po dvanáctém hopu.

Složitější problémy s routingem

Jako zásadnější problém se může jevit, máme-li topologii sítě rozvinutější, tj. používáme více segmentů sítě s různými subnety. Takovým příkladem může být hvězdicovitá nebo lineární topologie sítě.

Typickou ukázkou hvězdicovité topologie může být jednoduchá LAN síť, ve které běží VPN server a z důvodů bezpečnosti jsou VPN klienti umístěni v separátním subnetu (virtuální VPN adaptér není přemostěn do sítě LAN, nýbrž routován). V takovém případě je nutno dbát, aby VPN koncentrátor měl ve své routovací tabulce umístěny veškeré možné a povolené směry, tj. minimálně směr do LAN a obráceně do VPN, případně i směrem do internetu.

[82101-hvezda-png]

V případě lineární sítě, která může být reprezentována nějakou větší místní komunitní sítí, která takto řeší např. problém dosahu či konektivity apod. V takovém případě, pokud není implemetován nějaký routovací protokol, je potřeba, aby všechny routery v dopředném směru "věděly", že za daným subnetem, jehož jsou členy, existují i další subnety. Jen ve velmi sporadických případech lze toto řešit pomocí výchozí brány (nelze tehdy, pokud směr do internetu se odlišuje od směru k dalším subnetům, případně pokud se jedná o hybridní síť, tj. jak hvězdicovitou, tak lineární). V takových případech nastupuje nutnost ruční editace směrovací tabulky (což je úkon, jak jste si možná všimli, který jsme dosud nepoužili) a přidat do směrovací tabulky směry na "skryté" sítě.

[82103-linie-png]

Závěr

Dnes jsme si ukázali, jakým způsobem funguje směrování, popsali jsme si základní lokalizaci a odstraňování problémů a v závěru jsme si ukázali i typické problémy větších a rozlehlejších sítí.

Dobrá rada na závěr je jedna: máte-li problém se složitější topologií sítě, namalujte si ji na papír, všechno pak vypadá jednodušeji a snadněji odhalíte chybu.

V případě dotazů použijte laskavě diskuzi pod článkem.

Jsou zobrazeny jen nové komentáře. Zobrazit všechny
Předmět Autor Datum
Touchwoode, doufám že jsi nerezignoval a pokusíš se nám nalít více znalostí do hlavy. Těším se na da… nový
Jack 31.10.2007 22:58
Jack
kdyžtak dotaz, když budu mít router A, který bude připojen k internetu, bude na něm NAT a LAN třeba… poslední
krakonos35 16.08.2017 07:13
krakonos35

kdyžtak dotaz, když budu mít router A, který bude připojen k internetu, bude na něm NAT a LAN třeba 192.168.0.0/24 a poté budu chtít udělat ještě jednu lokální sít, tak na routeru 2 nastavím WAN ip z rozsahu routeru 1 a na LAN také novou LAN, potřebuji NAT i na tom druhém routeru? KTerý v podstatě spojuje jednu lokální sít s druhou?

Zpět na články Přidat komentář k článku Nahoru