Corporate presentation Hálózati hibák felderítése és elhárítása Scheidler Balázs, LOK 2006.

2 Tartalom Hibaelhárítás alapelvek ISO OSI és ahogy azt ma látjuk Hálózati interfészek, beállítások Adatkapcsolati réteg ethernet esetén IP beállítások és tipikus problémák TCP/UDP beállítások és tipikus problémák Alkalmazás szint Monitorozás

3 Hibaelhárítás alapelvek Minden hibának megvan a maga oka, de ez első blikkre nem mindig egyértelmű :) Egyszerre csak egy hibajelenséggel foglalkozzunk, könnyen lehet, hogy a többi már csak következmény (a „nem működik az internet” nehezen megoldható). A megoldáshoz vezető út: haladjunk végig a rendszer komponensein, és minden réteget külön-külön ellenőrizzünk, logüzenet gyakran nincs!

4 ISO OSI és ahogy azt ma látjuk Az OSI (Open Systems Interconnection) az ISO és az ITU-T által szabványosított hálózati modell. A TCP/IP nem feleltethető meg az ISO OSI- nak, bár hasonló elveket követ, azonban közel sem „vegytiszta”. Az OSI modell által használt fogalomkészlet jól használható a TCP/IP tárgyalása kapcsán is, a legtöbb hálózati eszköz gyártó is az OSI által definiált rétegeket használja (L2, L3, L7)

5 Az OSI modell

6 OSI és a TCP/IP Fizikai réteg – közös (X.25, Ethernet, Token Ring, FDDI,...) Adatkapcsolati réteg – közös (PPP, HDLC, …) Hálózati réteg – Internet Protocol (IP) Transzport réteg – ICMP/UDP/TCP/SCTP … Session – nincs egyértelmű megfeleltetés Prezentációs réteg ~ SSL Alkalmazási réteg – HTTP, FTP,...

7 Fizikai réteg A fizikai réteg szerepe: a fizikai kapcsolat biztosítása két hálózati végpont között a fizikai szint lehet: Ethernet, X.25, FDDI,... A fizikai szint eszközei: hálózati interfész, kábelek, jelismétlők (hub) Ethernet esetén a fizikai réteg csomagkapcsolt, az adatátvitel csomagok segítségével történik.

8 Hálózati interfészek, beállítások I. Linux alatt a hálózati interfészeket a kernelben lévő driverek vezérlik. A hálózati interfészek neve utal az általuk megvalósított technológiára (pl. ethX ethernet) Az ismert hálózati interfészek: ifconfig -a (régi, BSD kompatibilis módszer) ip link ls (Linux natív)

9 ip link kimenet

10 Hálózati interfész driverek A kártyák driverét gyakran modulból töltjük be, a modulok paramétereit le tudjuk kérdezni a „modinfo -p” paranccsal. A driverek gyakran nyújtanak extra funkciókat modulparamétereken keresztül:

11 Hálózati interfész driverek A modul paramétereit módosíthatjuk az alábbi állományokon keresztül: /etc/modules.conf /etc/modules, /etc/modutils (Debian/Ubuntu) Kernelbe fordított driver esetén a boot loaderen keresztül kernel paraméterként.

12 Fizikai réteg beállításai Ethtool segítségével lehetőségünk van finom- hangolni az ethernet hálózat beállításait

13 Lehetséges problémák és felismerésük Hibás hálózati interfész nincs link (ethtool, led), nincs forgalom (RX/TX számlálók), nincs interrupt (/proc/interrupts) Hibás kábel nincs link (ethtool, led), van link de nincs forgalom (keresztkábel helyett egyenes) nincs RX csomag Sikertelen autonegotiation a két fél más sebességet és duplexitást lát ethtool-lal ill. modulparaméterekkel állítható

14 Tippek és trükkök GBit esetén az átvihető maximális csomagméret emelhető (max 9000 byte-ig), ami nagy mennyiségű adat átvitele esetén csökkentheti a PPS-t. De nem érdemes 1 lap méreténél nagyobbra venni. A teljesítmény növelhető a megszakítások processzorhoz rendelésével, routing esetén érdemes a bejövő/kimenő interfészt ugyanahhoz a CPU-hoz rendelni. Egy gép átviteli képességét elsősorban a PPS befolyásolja.

15 Adatkapcsolati réteg Ethernet esetén (L2) A réteg szerepe: Az IP által használt logikai címzés (IP cím) megfeleltetése fizikai címzésre (Ethernet MAC cím) Az adatcsomagok átvitele MAC cím alapján történik, sorrend és megérkezés nem garantált. (nem Ethernet hálózatokon nem feltétlenül így van, pl. PPP) Tipikus L2 eszközök: store & forward eszközök, switch, bridge

16 ARP protokoll működése IP csomagok forgalmazása előtt meg kell állapítani a célállomás IP címéhez tartozó MAC címet: küldő állomás broadcast csomagot küld a hálózatra: Ki rendelkezik az adott IP címmel? ha egy gép olyan broadcast csomagot kap, melyben a saját IP címe szerepel, egy unicast csomaggal válaszol, melyben szerepel a saját MAC címe. Az IP->MAC leképezés eredménye az ún. ARP cache-ben tárolódik.

17 ARP cache tartalma Az ARP cache „arp” illetve az „ip neigh” parancs segítségével menedzselhető. Egy IP->MAC megfeleltetés bizonyos ideig tárolódik, majd ha nincs kommunikáció, kiesik. Bizonyos időközönként a kernel a cache-ben található elemeket is megerősíti.

18 ARP cache trükkök Egy gép akkor is válaszolhat egy IP -re érkező ARP kérésre, ha az adott IP cím amúgy nem lokális. ilyenkor az adott IP címre érkező forgalom ugyanúgy a fenti géphez jut, mintha ő maga szolgálná ki az ilyen forgalmat a gép aztán routeolhatja IP szinten, de csak egyszerűen le is hallgathatja, majd továbbíthatja a valódi célnak. Saját címmel kiküldött ARP válasz küldésével lehet „figyelmeztetni” a hálózaton lévő többi gépet MAC cím változásáról (gratuitous arp).

19 Lehetséges problémák és felismerésük IP cím ütközés nincs vagy csak egyirányú IP forgalom van hol megy, hol nem megy … az ARP cache-ben az adott IP-hez letárolt MAC cím változik, annak függvényében, hogy ki válaszolt utoljára ARP kérésre (arp -n) Hálózati kártya csere után nem működik a forgalom bizonyos eszközök hosszú időn keresztül tárolják az IP->MAC megfeleltetést, így egy kártyacsere esetén nem veszik rögtön észre a megváltozott MAC címet.

20 Diagnosztikai eszközök ip neigh – natív Linuxos parancs az ARP cache menedzselésére arp – BSD kompatibilis ARP menedzsment eszköz arping – ARP válaszidők mérése

21 Hálózati réteg (IP) A réteg szerepe: csomagok átvitele az összekapcsolt hálózatokon logikai címzés (IP cím) alapján. Tulajdonságok: független az átviteli médiumtól (ethernet, ppp) a sorrend és az átvitel nem garantált, közvetlenül nem használt, alapul szolgál a magasabb szintű protokollokhoz, maximum 64k-s csomagok, a tördelésről az IP réteg gondoskodik. Tipikus eszköz: router

22 IP beállítások Minden hálózati interfész egy/több IP címmel rendelkezik (ifconfig, ill. ip address) Közvetlenül kapcsolt hálózatokon lévő gépek elérhetők az ARP protokoll segítségével. Távoli hálózatok elérhetők a lokális hálózaton megjelenő router segítségével. A csomagok irányítása a gép routing táblázata alapján történik.

23 Routing tábla A routing tábla IP alhálózatok elérhetőségét írja le, a következő parancsokkal kezelhető: ip route (natív Linux) route (BSD kompatibilis)

24 IP címek és alhálózatok A routing tábla IP alhálózatok elérhetőségét adja meg. Egy IP alhálózatot a hálózati cím illetve egy kötödő netmask adja meg. Például: / A netmaskot meg lehet adni ún. prefix jelöléssel is, a baloldalt álló egyesek számával: /27

25 Netmask

26 IP fragmentáció Az IP képes maximum 64kB csomagot átvinni, a fizikai réteg viszont általában ennél kisebb méreteket támogat (ethernet MTU 1500 byte) A darabolás overhead-et jelent (minden csomag külön fejléccel rendelkezik), ezért a fragmentáció káros, igyekszünk elkerülni. Ehhez küldés előtt szükség van a teljes útvonal MTU-ra (Path MTU) Ha a PMTU felderítés nem működik, akkor kis MTU-val rendelkező csatornák esetén problémák lehetnek.

27 Lehetséges problémák és felismerésük I. Szűk netmask bizonyos gépeket nem tudunk megcímezni (No route to host) bizonyos gépek forgalma mindig a default gateway-hez megy, amire az egy ICMP redirect-tel válaszol („netstat -ns” vagy tcpdump) Bő netmask bizonyos gépek megcímzésekor ARP kérések mennek ki, ahelyett, hogy a default gateway felé menne („arp -n” vagy tcpdump)

28 Lehetséges problémák és felismerésük II. Hibás routing tábla: nem megfelelő irányba menő csomagok (tcpdump vagy ip route get) Hibás forrás IP cím: egy gépről kimenő kapcsolat forrás IP címét a routing határozza meg, általában a kimenő interfész elsődleges IP címe lesz egy kapcsolat forrása, de ez változtatható Nem működik a PMTU: bizonyos kapcsolatok fennakadnak, valahol szűrik az „ICMP fragmentation needed” csomagot

29 IP szintű eszközök ping – válaszidők mérése ICMP pinggel hping2 – válaszidők különböző csomagokkal traceroute/mtr – routing útvonal ip address/ip route – ip címek/routeok állítása tcpdump/ethereal – hálózati forgalom elemzés iptables – csomagok szűrése fejlécek alapján netstat – nyitott socketek, statisztikák (-s opció)

30 tcpdump

31 TCP/UDP beállítások és tipikus problémák A réteg szerepe: alkalmazások által közvetlenül használható protokollok, egy gép több párhuzamos kommunikációban részt vehet a portszámok bevezetésével szükség esetén képes garantálni az átvitt adatok garantált megérkezését (TCP)

32 Lehetséges problémák és felismerésük Csomagszűrt forgalom: Általában ha az IP szint működik, a TCP/UDP is fog, kivéve, ha az útvonalon egy router/tűzfal szűri a forgalmat (ICMP administratively prohibited, tcpdump). Fennakadt kapcsolatok: Nem működő PMTU, ICMP frag needed csomagok szűrése (megoldás: TCP MSS limitálása)

33 Diagnosztikai eszközök tcpdump/ethereal telnet netcat netstat -ns

34 Alkalmazás szint A réteg szerepe: az itt futó szoftverek valamilyen konkrét alkalmazást valósítanak meg, gyakran közvetlenül a felhasználói igényeket hajtva végre (kliens programok: böngésző, levelező, stb.) az itt futó programok TCP/UDP kapcsolatokat használnak, a hálózat elemeit gyakran NÉV segítségével címzik (bár természetesen IP címet is lehet használni).

35 Lehetséges problémák és felismerésük DNS problémák Egyáltlán nem működik a DNS (IP címet használva működik, név alapján nem) reverse DNS nem működik (a kliens fel tudja oldani a szervert,de a szerver nem tudja feloldani IP cím alapján a klienst, amit gyakran hibának tekint és elutasít) A DNS beállításai a resolv.conf állományban találhatók.

36 Diagnosztikai eszközök minden TCP/IP rétegben használt eszközök itt is használhatók host, dig – DNS problémák tcpdump/ethereal – kimenő/bemenő csomagok elemzése, ellenőrzése általános szoftver diagnosztikai eszközök (strace/ltrace/logok/stb)

37 Hálózati hibák detektálása A problémát észre kell venni, egy jól beállított rendszer is bármikor meghibásodhat (pl: markoló :) Monitorozó eszközök: nagios – adatgyűjtés, riasztás munin – adatok gyűjtése és ábrázolása (elsősorban hoszt/alkalmazás adatok)

38 Összegzés Egy jól működő rendszert is kell monitorozni. Hálózati problémák diagnosztizálásakor érdemes a rétegek szerint sorban haladni, és egymás után kizárni a lehetséges problémákat. Ha egy probléma nem a beállításokban keresendő, akkor a különböző csomagelemző eszközök (tcpdump/ethereal) rengeteget segítenek, de támpontot nyújthatnak a különböző számlálók (RX/TX interfészeknél, csomagszűrő szabályoknál)

39 Köszönöm Köszönöm a Figyelmet! Kérdés?