Počítačové sítě studijní materiály pro studenty SPŠ Hradec Králové 24. února 2004
Download • formát HTML (zip) • formát pdf • formát ps (PostScript)
1
Obsah 1 Úvod - základní pojmy 1.1 Základy sítí . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Typy sítí . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Síťové pojmy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 4 4 4
2 Historie Internetu 2.1 Historie TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Základní data vývoje Internetu a TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Velká jména Internetu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 5 5 5
3 Principy síťových architektur 3.1 Síťové protokoly . . . . . . . . . . . 3.2 Referenční model OSI . . . . . . . . 3.2.1 Fyzická vrstva . . . . . . . . 3.2.2 Linková vrstva . . . . . . . . 3.2.3 Síťová vrstva . . . . . . . . . 3.2.4 Transportní vrstva . . . . . . 3.2.5 Relační vrstva . . . . . . . . 3.2.6 Prezentační vrstva . . . . . . 3.2.7 Aplikační vrstva . . . . . . . 3.3 Způsoby přenosu informací . . . . . 3.3.1 Synchronní přenos . . . . . . 3.3.2 Paketový přenos . . . . . . . 3.3.3 Asynchronní přenos . . . . . 3.4 Virtuální okruh . . . . . . . . . . . . 3.4.1 Pevné a komutované virtuální
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . okruhy
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
6 6 7 8 8 8 9 10 10 10 10 10 11 11 12 13
4 Architektura TCP/IP 4.1 Vrstva síťového rozhraní - network interface 4.2 Vrstva mezisíťová - internet layer . . . . . . 4.3 Transportní vrstva . . . . . . . . . . . . . . 4.4 Aplikační vrstva . . . . . . . . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
14 14 15 15 15
5 Vrstva síťového rozhraní 5.1 Sériové linky . . . . . . . . . . . . . 5.1.1 Nulový modem . . . . . . . . 5.2 Modemy . . . . . . . . . . . . . . . . 5.3 Digitální okruhy . . . . . . . . . . . 5.3.1 euroISDN2 . . . . . . . . . . 5.4 LAN - lokální sítě . . . . . . . . . . . 5.4.1 Strukturovaná kabeláž . . . . 5.4.2 Ethernet . . . . . . . . . . . . 5.4.3 Ethernet 10 Mbps . . . . . . 5.4.4 Fast Ethernet 100 Mbps . . . 5.4.5 Gigabitový Ethernet 1 Gbps 5.5 WAN - rozlehlé sítě . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
17 17 18 18 19 20 21 21 23 27 28 29 29
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
2
5.5.1 5.5.2
SLIP protokol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PPP protokol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29 30
6 Síťová vrstva 6.1 IP protokol . . . . . . . . . . . . . . . . . . . 6.2 IP datagram . . . . . . . . . . . . . . . . . . 6.3 Protokol ICMP . . . . . . . . . . . . . . . . . 6.4 Protokoly ARP a RARP . . . . . . . . . . . . 6.5 IP adresa . . . . . . . . . . . . . . . . . . . . 6.5.1 Síť - historická epocha I . . . . . . . . 6.5.2 Síť - historická epocha II . . . . . . . . 6.5.3 IP-adresy v intranetu . . . . . . . . . 6.5.4 Dynamicky přidělované adresy . . . . 6.6 Směrování . . . . . . . . . . . . . . . . . . . . 6.6.1 Předávání a filtrace . . . . . . . . . . . 6.6.2 Směrování . . . . . . . . . . . . . . . . 6.6.3 Manipulace se směrovacími tabulkami
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
31 31 36 36 41 42 43 45 48 49 50 51 52 54
7 Transportní vrstva 7.1 Protokol TCP - Transmision Control Protocol 7.2 TCP segment . . . . . . . . . . . . . . . . . . 7.3 Navázání a ukončení spojení protokolem TCP 7.3.1 Navazování spojení . . . . . . . . . . . 7.3.2 Ukončování spojení . . . . . . . . . . . 7.4 Protokol UDP . . . . . . . . . . . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
56 56 58 59 59 64 66
8 Aplikační vrstva 8.1 Služba DNS . . . . . . . . . . . . . . . . . . . . . . 8.1.1 Domény a subdomény . . . . . . . . . . . . 8.1.2 Reverzní domény . . . . . . . . . . . . . . . 8.1.3 Dotazy . . . . . . . . . . . . . . . . . . . . 8.1.4 Resolver . . . . . . . . . . . . . . . . . . . . 8.1.5 Name server . . . . . . . . . . . . . . . . . . 8.2 Implementace jmenného serveru - program named 8.2.1 A . . . . . . . . . . . . . . . . . . . . . . . . 8.2.2 CNAME . . . . . . . . . . . . . . . . . . . . 8.2.3 NS . . . . . . . . . . . . . . . . . . . . . . . 8.2.4 MX . . . . . . . . . . . . . . . . . . . . . . 8.2.5 PTR . . . . . . . . . . . . . . . . . . . . . . 8.2.6 $ORIGIN . . . . . . . . . . . . . . . . . . . 8.3 DHCP server . . . . . . . . . . . . . . . . . . . . . 8.3.1 Mechanismus DHCP . . . . . . . . . . . . . 8.3.2 Server DHCP . . . . . . . . . . . . . . . . . 8.4 FTP server . . . . . . . . . . . . . . . . . . . . . . 8.4.1 Spolupráce serveru s klientem . . . . . . . . 8.4.2 Konfigurace wu-ftpd . . . . . . . . . . . . . 8.4.3 Příklady konfigurace . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
68 68 68 69 72 75 76 79 83 83 83 84 85 86 86 86 86 89 89 89 90
9 Bezpečnost sítí s IP
91
3
Kapitola 1
Úvod - základní pojmy 1.1
Základy sítí
1.2
Typy sítí
1.3
Síťové pojmy
4
Kapitola 2
Historie Internetu 2.1
Historie TCP/IP
2.2
Základní data vývoje Internetu a TCP/IP
2.3
Velká jména Internetu
5
Kapitola 3
Principy síťových architektur • Síťová architektura - struktura řízení komunikace • příliš složitý problém - rozdělení do vrstev • síťová architektura je popsána systémem služeb, funkcí a protokolů • komunikace mezi cizinci
3.1
Síťové protokoly
• síťový protokol - způsob komunikace mezi počítači v síti • v Internetu se používá TCP/IP • soustava síťových protokolů = síťový model
6
3.2
Referenční model OSI
• mezinárodní normalizační úřad (ISO) normalizoval soustavu protokolů označovaných jako ISO OSI • kladen důraz na otevřenost - architektura otevřených systémů (Open Systems Architecture, OSA) • všechna koncová zařízení vyhovující normám možnost připojit k síti • normalizace propojení otevřených systémů (Open Systems Interconnection, OSI) • referenční model OSI přijat v roce 1984 • reálný systém = zařízení, které tvoří samostatný celek, schopné vykonávat zpracovávání a přenos informace (počítač, terminál, periferní zařízení. . .) • pokud je síťové vybavení reálného systému v souladu s OSI - jedná se o reálný otevřený systém 7
3.2.1
Fyzická vrstva
• popisuje elektrické, optické signály používané při komunikaci mezi počítači • na fyzické vrstvě je tvořen tzv. fyzický okruh (datový okruh) • na fyzický okruh mezi dvěma počítači jsou vkládána další zařízení (např. modemy) • jediná vrstva, která podporuje fyzickou komunikaci mezi dvěma systémy
3.2.2
Linková vrstva
• linková vrstva (= spojová vrstva) zajišťuje výměnu dat v rámci lokální sítě • výměna dat mezi bezprostředně propojenými počítači • základní jednotkou pro přenos dat je na linkové vrstvě datový rámec • složení linkového datového rámce: – záhlaví (Header) - linková adresa příjemce, linková adresa odesílatele MAC adresa: ∗ ∗ ∗ ∗ ∗
fyzická, hardwarová adresa délka 48 bitů, vyjadřuje se šestnáctkovém tvaru (12 hexa č9číslic) 24 bitů - kód výrobce, jednoznačný identifikátor organizace (OUI) 24 bitů - označení fyzického rozhraní kódy výrobcům přiděluje IEEE (Institute for Electrical and Electronics Engineers)
– přenášená data (Payload) - např. paket síťové vrstvy – zápatí (Trailer) - kontrolní součet z přenášených dat
• na fyzické vrstvě mohou být pro každý konec spojení použity jiné protokoly na fyzické vrstvě
3.2.3
Síťová vrstva
• zajišťuje přenos dat mezi vzdálenými počítači v rámci WAN • poskytuje transportní vrstvě nezávislost na směrování • základní jednotkou přenosu je síťový paket, který se balí do linkového rámce • v rámci WAN (rozlehlé sítě) leží69 mezi počítači jeden nebo více směrovačů • mezi směrovači je na linkové vrstvě přímé spojení
8
• směrovač vybalí síťový paket z datového rámce (jednoho linkového protokolu) a před odesláním je zabalí do jiného datového rámce (obecně jiného linkového protokolu) • síťovou vrstvu nezajímají jednotlivé linkové protokoly na cestě mezi oběma konci spojení • na síťové vrstvě je jednoznačně v cel WAN adresováno síťové rozhraní (např. síťová karta Ethernet)
3.2.4
Transportní vrstva
• předpokládá, že spojení je zajištěno - plně se spoléhá na služby síťové vrstvy • věnuje se realizaci spojení mezi jednotlivými aplikacemi na vzdálených počítačích
• mezi dvěma počítači může být několik transportních spojení současně • z hlediska transportní vrstvy jsou adresovány jednotlivé aplikace - číslo portu • z hlediska síťové vrstvy jsou adresovány počítače - síťová adresa počítače (síťové rozhraní) • jednotkou přenosu je transportní paket • transportní paket se přenáší v datové části síťového paketu
9
3.2.5
Relační vrstva
• úkolem vrstvy ke organizovat a synchronizovat dialog mezi aplikacemi • poskytuje služby - checkpoint, synchronizace transakcí, korektní uzavírání souborů
3.2.6
Prezentační vrstva
• zodpovídá za reprezentaci a zabezpečení dat • zabezpečením se rozumí šifrování, zabezpečení integrity dat, digitální podepisování
3.2.7
Aplikační vrstva
• aplikační vrstva předepisuje v jakém formátu a jak mají být data předávána mezi aplikacemi
3.3
Způsoby přenosu informací
• síťových protokolů je velké množství, na jedné vrstvě je často více protokolů • zvláště u nižších vrstev se se rozlišuje jaký typ přenosu protokol zabezpečuje a zdali zabezpečuje službu – spojovanou – nespojovanou • zdali protokol používá virtuální okruhy • rozeznáváme přenos: – synchronní – paketový – asynchronní
3.3.1
Synchronní přenos
• je vyžadován pro přenos zvuku, videa • vždy když je nutné zajistit stejnoměrně po dobu přenosu požadovanou šíři pásma • pokud odesílatel nevyužije zajištěné pásmo, pak zůstane nevyužito • synchronní přenos využívá rámce konstantní délky, které jsou přenášeny sítí konstantní rychlostí 10
• garance šíře přenosového pásma se u synchronního přenosu provádí rozdělením přenášených rámců na sloty • pro dané spojení se pak v každém rámci vyhradí jeden nebo více slotů • šíře pásma je dána počtem slotů daného spojení, které přenese síť za vteřinu
3.3.2
Paketový přenos
• vhodný zejména pro přenos dat • pakety nesou data obecně různé délky • paket nese data vždy jedné aplikace (jednoho spojení) • pakety jsou různé délky - nelze garantovat šíři pásma • výhodou je efektivní využití pásma - pokud nekomunikuje jedna aplikace, může komunikovat jiná
3.3.3
Asynchronní přenos
• asynchronní přenos používá např. ATM • jedná se o kombinaci paketového přenosu se synchronním • jako u synchronního se data přenášejí v malých paketech - nazývají se buňky • podobně jako u paketového přenosu se v jedné buňce přenášejí data jedné aplikace (jednoho spojení)
11
• buňky mají stejnou délku - když každá x-tá buňka bude k dispozici aplikaci, lze tímto garantovat šířku pásma • pokud aplikace buňku neodešle, může být odeslána buňka jiné aplikace (efektivní využití)
3.4
Virtuální okruh
• některé síťové protokoly vytvářejí v síti virtuální okruh (virtual circuit) • všechny pakety procházejí tímto okruhem • pokud je okruh přerušen, spojení se přeruší do vytvoření nového okruhu • okruh může nebo nemusí garantovat doručení datagramu • výhoda virtuálního okruhu: – okruh je nejprve sestaven, poté jsou do něj vkládána data – každý datagram nemusí nést úplnou, globálně jednoznačnou adresu příjemce (např. IP adresu) – pro správné doručení postačí nést identifikaci okruhu, kterým se mají data přenést • zničení uzlu ve virt. okruhu znamená přerušení spojení
12
• na Internetu (IP protokol) se nepoužívají virtuální okruhy • každý IP datagram nese IP adresu příjemce = úplnou směrovací informaci a je dopravován samostatně • zničení uzlu znamená zničení datagramu, který přes tento uzel prochází, nikoli zničení spojení • další datagramy jsou směrovány přes jiné uzly • v Internetu se nad nespojovaným IP protokolem používá protokol TCP, který garantuje doručení dat
3.4.1
Pevné a komutované virtuální okruhy
Virtuální okruhy rozeznáváme: • pevné - pevně sestavené administrátorem sítě (např. pevné linky v telef. síti) • komutované - virt. okruhy vznikají dynamicky podle okamžité potřeby (komutované linky v telef. síti)
13
Kapitola 4
Architektura TCP/IP Protokolová zkratka nezahrnuje pouze dva protokoly - TCP, IP. Oproti OSI referenčního modelu tvoří pouze 4 vrstvy. Jednotlivé vrstvy modelu TCP/IP: • vrstva rozhraní sítě - network interface • vrstva mezisíťová - internet layer • transportní vrstva - transport layer • aplikační vrstva - application layer
Architektura TCP/IP nemůže odpovídat rozvrstvení podle OSI, protože vznikla ještě před jeho oficiálním přijetím. Porovnání OSI modelu s modelem TCP/IP: vrstva TCP/IP vrstva OSI vrstva rozhraní sítě vrstva fyzická a spojová vrstva mezisíťová vrstva síťová transportní vrstva transportní vrstva aplikační vrstva vrstva prezentační, relační a aplikační
4.1
Vrstva síťového rozhraní - network interface
• umožňuje přístup k fyzickému přenosovému médiu
14
• pro TCP/IP možno využít všech známých typů přenosových prostředí – lokálních sítí - Ethernet, Token Ring, FDDI – rozlehlých sítí - X.25
4.2
Vrstva mezisíťová - internet layer
• zajišťuje především síťovou (logickou) adresaci, směrování, předávání datagramů • protokol intersítě IP (internet protocol): – zodpovědný za vysílání datagramů na základě síťových adres obsažených v záhlaví – poskytuje síťovou službu bez spojení (nespojovanou) – protokol nezaručuje doučení datagramu - služba je označována jako nespolehlivá – specifikace verze 4 (IPv4)je v RFC 791 • vrstva zajišťuje také mapování adres: – protokol mapování adres (Address Resolution Protocol, ARP) - používá se při znalosti cílové IP adresy stanice (rozhraní) pro nalezení příslušné fyzické adresy rozhraní (MAC) – protokol obráceného mapování adres (Reverse Address Resolution Protocol, RARP ) - používá se při znalosti vlastní fyzické adresy pro získání vlastní IP adresy (nejčastěji u bezdiskových stanic, když zjišťují svoji IP adresu od serveru v síti) • vrstva obsahuje další řídící protokoly: – protokol řídících hlášení (Internet Message Protocol, ICMP) - slouží k přenosu specifických zpráv týkajících se chyb a zvláštní okolností při přenosu datagramů • vrstva je odpovědná za směrování datagramů
4.3
Transportní vrstva
Transportní vrstva odpovídá transportní vrstvě podle modelu OSI. Poskytuje mechanismus pro koncový přenos dat mezi dvěma stanicemi. Definuje transportní službu se spojením (TCP) nebo bez spojení (UDP): • Transmission Control Protocol (TCP) - poskytuje transportní službu se spojením (tzv. spolehlivý protokol) • User Datagram Protocol (UDP) - poskytuje transportní službu bez spojení (nespolehlivý protokol) Kromě transportních protokolů pracuji na této vrstvě také směrovací protokoly: • Routing Information Protocol (RIP) • Border Gateway Protocol (BGP)
4.4
Aplikační vrstva
Vrstva aplikačních procesů je nejvyšší vrstvou síťové architektury Internetu a obsahuje v všechny protokoly, které poskytují uživatelům konkrétní aplikace. Některé protokoly jsou přesně závislé na typu transportní služby (transportním protokolu. Některé vyžadují protokol TCP na transportní vrstvě: • FTP, Telnet, HTTP,. . . Některé vyžadují protokol UDP: • DHCP, BOOTP, TFTP,. . . 15
Některé mohou pracovat z jakýmkoli protokolem transportní vrstvy: • např. DNS Mezi nejpoužívanější protokoly patří: • Telnet • FTP (File Transfer Protocol) • TFTP (Trivial Transfer Protocol) • NFS (Network File System) • SMTP (Simple Mail Transfer Protocol) • BOOTP (Bootstrap Protocol) • DHCP (Dynamic Host Configuration Protocol) • DNS (Domain Name System) • HTTP (Hypertext Transfer Protocol)
16
Kapitola 5
Vrstva síťového rozhraní V zásadě se rozlišují dva typy počítačových sítí: • lokální sítě (LAN) • rozlehlé sítě (WAN) Z hlediska fyzické vrstvy jsou protokoly pro LAN jednou skupinou a protokoly pro WAN druhou skupinou protokolů. Protokol ATM smazává rozdíl mezi LAN a WAN. WAN Rozsáhlé sítě pokrývají velkou škálu situací. Připojení domácího PC pomocí sériové asynchronní linky (modem), kde rychlost je v desítkách kbps a6 po mezikontinentální linky o rychlostech až v Gbps. LAN Jedná se o středně rychlé sítě. Komunikuje zpravidla několik stanic na sdíleném médiu. V rámci jedné LAN se používá jeden linkový protokol (např. Ethernet). V klasické LAN je použit pouze jeden linkový protokol.
5.1
Sériové linky
PC má zpravidla dvě sériová rozhraní - COM1, COM2. Sériová rozhraní slouží pro asynchronní arytmický přenos dat. Sériový a paralelní přenos dat Sériový přenos • mezi příjemcem a odesílatelem je jedna dvojice vodičů • jednotlivé znaky se přenášejí za sebou - sériově Paralelní přenos • používá se osmi vodičů nebo násobek osmi • všechny bity přenášeného znaku se přenesou najednou - paralelně Na fyzické úrovni se pro sériová rozhraní nejčastěji používají normy V.35, X. .21 a V.24. Sériová rozhraní počítače (PC) jsou konstruována podle normy V.24. Rozhraní se pro rychlosti větší než 64 kbps nedoporučuje a je nutno požít rozhraní9 V.35 nebo X.21.
17
5.1.1
Nulový modem
Pokud bychom chtěli propojit dva počítače přímo pomocí rozhraní V.24, propojovací kabel musí být speciálně zapojený. Vysílání musí být překříženo s příjmem. Takto zapojený kabel se nazývá nulový modem.
5.2
Modemy
Pro připojení na větší vzdálenosti se často používá telefonní síť. Pro použití telefonní sítě pro datový přenos je nutné datové informace modulovat a na druhé straně demodulovat - modulátor/demodulátor. Modem se připojuje směrem k počítači pomocí rozhraní V.24 na sériový port a druhým na telefonní linku. Typy modemových linek rozlišujeme: • komutovaná linka • pevná linka Komutovanou linku používáme při běžném telefonování. Vytočením telefonního čísla se vytvoří virtuální okruh, ten je potom použit pro přenos hlasu nebo dat.
18
Pevná linka se používá pro trvalé propojení - trvale propojený okruh. Při pevné lince není nutné stále vytáčet spojení. Operátorovi se většinou platí paušální poplatek za přenos dat. Při vyšších přenosových rychlostech se v případě pevných linek někdy nepoužívá pouze jeden telefonní okruh (tzv. dvoudrát), ale dva okruhy (tzv. čtyřdrát). Jeden okruh je určen pro příjem a druhý pro vysílání. Okruhy musí být vzájemně překříženy. Okruh použitý v jednom modemu pro vysílání musí být přiveden do druhého modemu jako příjem. Počítač ovládá modem pomocí tzv. AT-příkazů.
5.3
Digitální okruhy
Digitální okruhy - neboli ISDN linky. V rámci ISDN se dnes nabízí připojení euroISDN2 a euroISDN30. Toto jsou obchodní názvy v literatuře se používá: • Basic Rate - euroISDN2 - tedy připojení, kdy ve fyzicky jednom vedeni (kroucená dvoulinka) jsou dva datové kanály B, každý o kapacitě 64 kbps a jeden signalizační kanál D o kapacitě 16 kbps • Primary Rate - euroISDN30 - ve fyzicky jednom vedení (linka E1) je 30 datových kanálů B (po 64 kbps) a 1 signalizační D (64 kbps)
19
5.3.1
euroISDN2
Využívá stávající telefonní rozvody kroucenou dvoulinkou. Lze využít i stávající metalické rozvody pro analogové telefony. Kroucená dvoulinka přicházející od Telecomu vytváří tzv. rozhraní U. Rozhraní U je rozhraní mezi Telecomem a krabičkou - NT-1 (dodá Telecom). Ze zařízení NT-1 vycházejí 2 dvoulinky - rozhraní S/T. Rozhraní S/T má charakter sběrnice, na kterou se připojují digitální zařízení (dig. telefon, dig. modem,. . . ).
Možnost připojit více zařízení, ale v jednom okamžiku mohou komunikovat pouze dvě - dva datové kanály B. Kanál D - slouží k signalizaci a k sestavení virtuálního okruhu (vytočení čísla). Digitální modem - vlastně není modem (stojí mezi dvěma digitálními prostředími, nikoli digitálníanalogové), ale pouze konvertuje jeden typ dig. rozhraní (V.34 - sériový port) na jiný (rozhraní S/T - konektor RJ45).
20
ISDN využívá synchronní přenos dat. Využívá přenos rychlostí 192 kbps, který je rozdělen do do slotů pro jednotlivé kanály.
5.4
LAN - lokální sítě
Lokální sítě (LAN) jsou určeny pro propojení počítačů na kratší vzdálenosti (stovky metrů až kilometry). Volba fyzického rozhraní (síťová karta) závisí na volbě linkového protokolu: • Ethernet • Fast Ethernet • Gigabitový Ethernet • FDDI Arcnet a Token Ring jsou v praxi málo používané.
5.4.1
Strukturovaná kabeláž
Strukturovanou kabeláží se rozumí komplexní řešení nízkonapěťových rozvodů v budově - telefonní rozvodu a rozvody LAN. V místnostech budovy jsou zásuvky, ze kterých vedou rozvody na propojovací panel (patch panel). Optická vlákna jsou vyvedena na distribuční box optiky. Propojovací panel a distribuční box optiky bývají uzavřeny ve skříni - Rack Mount - spolu s aktivními prvky (hub, switch), případně s telef. ústřednou. Mezi propojovacím panelem a aktivní i prvky s používá tzv. Patch Cord.
Normy pro rozvody (kabeláž): • kategorie 5 - dodavatel garantuje práci v šířce do 100 Mhz, nezávisle na použitém protokolu • kategorie 5+ - rozšířená kategorie. Pracuje také do 100 MHz, ale je přísnější a cílem je možnost provozovat na tomto vedení Gigabitový Ethernet • kategorie 6 - šířka pásma do 200 Mhz • kategorie 7 - šířka pásma do 600 Mhz
21
Měděné rozvody se provádí pomocí svazků kroucených dvoulinek a konce se opatřují konektory RJ 45. Konektor RJ 45 obsahuje 8 vývodů pro 4 páry. Nejčastěji se používá zapojení dle EIA 568B. Toto zapojení umožňuje použít pár pro analogový telefon (pár 1). Pro Ethernet se využívají 2 páry (2 a 3). Pár 4 zůstává volný.
22
5.4.2
Ethernet
Protokol byl původně vyvinutý firmami DEC, Intel a Xerox. Varianta 10 Mhz se označuje jako Ethernet II, později byl normalizován jako 802.3. Max. délky segmentu lze rozšířit pomocí opakovačů. HUB - opakovač Opakovač je tvořen dvěma nebo více síťovými kartami, které jsou navzájem propojeny. Objeví-li se datový rámec na některém rozhraní, pak je automaticky zopakován na všechny ostatní. Opakovač může být osazen i porty pro kroucenou dvojlinku. V případě kroucené dvojlinky je jádrem sítě opakovač. Z opakovače se hvězdicovitě rozbíhají kroucené dvojlinky k jednotlivým počítačům. Opakovač pro kroucenou dvojlinku se označuje jako HUB.
23
• HUBY je možné mezi sebou propojovat - vysílání a příjem je nutno překřížit • většinou mají HUBy, kde jeden port jr osazen přepínačem, který působí překřížení párů (uplink). • pomocí HUBů nelze kombinovat 10BASE-T, 100BASE-TX, 1000BASE-CX • délka kabelu mezi opakovačem a stanicí je standardně 100 m • HUB pracuje na úrovni fyzické vrstvy • komunikace v LAN osazené HUBY je transparentní - stanice komunikují jako by tam HUBy nebyly
24
Most - přepínač Také jako opakovač spojuje jednotlivé segmenty LAN, ale neopakuje mechanicky všechny rámce, které se na n2kterém z jeho portu objeví. Most je realizován specializovaným počítačem, který má předávací tabulku. Tabulka obsahuje seznam všech linkových adres všech síťových rozhraní LAN. U každé adresy je poznamenáno, na kterém portu mostu se nachází. Příchozí datový rámec se předává dále pouze na port, kde sídlí příjemce, podle tabulky. Důležitým parametrem mostu je, jak velkou předávací tabulku může obsahovat - jak velkou má paměť. Tabulka se plní ručně nebo automaticky. Jak se tabulka plní automaticky? Po zapnutí pracuje most jako opakovač - opakuje vše na všechny adresy, ale u příchozího rámce se podívá na linkovou adresu, ze které rámec přišel a k tomuto portu si to poznamená do tabulky. Přepínaný Ethernet vlastně znamená použít místo opakovačů mostů - přepínačů (switch). Přepínače jsou výkonnější mosty, které umí opakovat rámce mezi jednotlivými segmenty Ethernetu, ale i např. mezi Ethernetem a Fast Ethernetem, mezi Ethernetem aFDDI . . . Protokol CSMA/DA Pro výměnu rámců mezi stanicemi se používá protokol CSMA/DA. Jak pracuje? Potřebuje-li nějaká stanice vysílat, poslechne si zdali jiná stanice právě nevysílá. V případě, že médium není používáno (klid, nikdo nevysílá), pak začne vysílat. Ve stejný okamžik, ale mohou začít vysílat dvě stanice najednou. V tomto případě dochází ke kolizi. Vysílání je nutno opakovat. Čím je na Ethernetu větší provoz, tím je větší pravděpodobnost vzniku kolizí. Rozumnou zátěží je využití sítě na 20 %. U Ethernetu s frekvencí 10 Mhz (10 Mbps) je propustnost asi 2 Mbps. Při plně duplexním provozu nemůže docházet ke kolizím. Bezkolizním segmentem v přepínaném Ethernetu je segment mezi počítačem a portem přepínače. Struktura rámce protokolu Ethernet
25
26
5.4.3
Ethernet 10 Mbps
Ethernet používá čtyři typy rozhraní: • AUI neboli 10BASE-5 (tlustý koaxiální kabel), segment max. 500 m • BC neboli 10BASE-5 (tenký koaxiální kabel), segment max. 185 m, jsou-li použity stejné síťové karty, pak může mít segment 300-400 m • TP neboli 10BASE-T (kroucená dvoulinka) • optický spoj neboli 10BASE-F
27
V RJ45 konektoru se používá pro Ethernet dva páry. Jeden pár vysílání, druhý pár pro příjem. Pokud ethernetový segment sdílí pouze dvě stanic, které jsou propojeny přímo propojovacím kabelem, pak musí být páry překříženy (příjem překřížen s vysíláním)
Síťová rozhraní se na takovémto segmentu přepínají do plně duplexního provozu (Full Duplex) – zcela se oddělí vysílání od příjmu. Dosahuje se hraničních rychlostí v obou směrech. Na tomto principu je postaven tzv. přepínaný Ethernet (rozbočovače).
5.4.4
Fast Ethernet 100 Mbps
Fast Ethernet se připojuje kroucenou dvoulinkou (100BASE-TX) nebo optikou (100BASE-FX). Rozdíl oproti klasickému Ethernetu je pouze v kvalitě vedení.
28
5.4.5
Gigabitový Ethernet 1 Gbps
Gigabitový Ethernet je standardizován pro optické spoje nebo pro kroucenou dvoulinku (4 páry) • 1000BASE-CX - metalické spoje, rozvody min, kategorie 5+, využívá v3všechny 4 páry kroucené dvoulinky • 1000BASE-LX - buzený laserem, max. délka segmentu do 2 km • 1000BASE-SX - pro vícevidová vlákna, pro vzdálenosti do 250 m
5.5
WAN - rozlehlé sítě
Mezi nejrozšířenější spojové protokoly pro rozlehlé sítě dnes patří HDLC (Frame Relay, ISDN) a protokoly SLIP a PPP
5.5.1
SLIP protokol
SLIP protokol je omezen na přenos pouze IP datagramů. SLIP = Serial Line Internet Protocol. Podporuje IP protokol po vytáčeném spojení (komutovaná, pevná linka) se sériovým rozhraním připojeným na modem. Běžná podporovaná rychlost pro protokol SLIP je 1.2 kbitps až 19.2 kbps. Protokol vkládá IP datagramy přímo do sériové linky. Tedy, protokol SLIP je velice jednoduchý a nezjišťuje: • detekci chyb při přenosu • SLIP nenese informaci o přenášeném protokolu - nelze jej tedy použít pro přenos datagramů jiných protokolů než IP • není možné, aby se koncové body informovaly o své IP adrese, či jiných konfiguračních parametrech • nelze jej použít pro synchronní linky
Varianta protokolu SLIP s kompresí se označuje jako CSLIP (Compressed SLIP).
29
5.5.2
PPP protokol
Protokol SLIP je dnes prakticky nahrazen dvobodovým protokolem (Point-to-Point Protocol, PPP). Tento protokol podporuje multiprotokolové prostředí - ne pouze protokol IP. PPP lze využít nejen pro asynchronní spojení, ale i pro synchronní. Protokol provádí dynamickou konfiguraci při navazování spojení a testuje kvalitu spoje. Může podporovat kompresi na spoji. PPP není ve skutečnosti jediný protokol, skládá se ze dvou úrovní: • protokol řízení spoje (Link Control Protocol, LCP) - navazuje spojení, dohaduje konfiguraci a testuje spoj. Volitelné fáze jsou autentizace a zjištění kvality spoje. • protokol řízení sítě (Network Control Protocol, NCP) - používá se jako podpora pro jednotlivé protokoly vyšší, síťové vrstvy Navazování spojení po sériovém spoji prostřednictvím PPP začíná provedením všech funkcí protokolu LCP, po němž následuje výměna rámců NCP. PPP nerozeznává primární a sekundární typ stanice, kterákoli stanice může začít „vyjednáváníÿ prostřednictvím PPP. Pro (volitelnou) autentizaci PPP se využívá jednoho ze dvou protokolů: • Password Authentication Protocol (PAP) - jednoduchý protokol založený na výměně textového hesla po síti • Challenge Authentication Protocol (CHAP) - neposílá se heslo po síti. Oslovená stanice pošle náhodně vygenerovaný řetězec stanici, která iniciovala komunikaci. Každá stanice zpracuje řetězec pomocí sdíleného tajného klíče.
30
Kapitola 6
Síťová vrstva 6.1
IP protokol
Linkové protokoly slouží pro dopravu dat mezi stanicemi v rámci lokální sítě, případně mezi směrovači rozsáhlé sítě. Úkolem IP protokolu je je dopravit data mezi libovolnými dvěma počítači v Internetu - přes mnohé LAN. Data jsou od odesílatele k příjemci dopravována (směrována) přes směrovače (router). Na cestě od odesílatele k příjemci se může vyskytnout řada směrovačů. Každý směrovač řeší pouze směrování k následujícímu směrovači. Next hop - tedy následující uzel, kam se data předávají dále. Hop - následující směrovač nebo cílový stroj. IP protokol umožňuje spojit jednotlivé LAN do celosvětového Internetu. Od protokolu IP dostal také Internet své jméno: • IP = InterNet Protocol - tedy protokol spojující jednotlivé sítě IP protokol je tvořen několika dílčími protokoly: • vlastní protokol IP • služební protokol ICMP • služební protokol IGMP • služební protokol ARP, RARP V protokolu IP má každé rozhraní (network interface) IP adresu (IPv4 = 4B, IPv6 = 16B). Základní prvkem WAN je směrovač (router), který propojuje jednotlivé LAN do rozlehlé sítě (WAN). Jako směrovač může sloužit běžný počítač s více síťovými rozhraními nebo specializovaná skříňka (box).
31
Schopnost přesávat datové pakety mezi síťovými rozhraními směrovače se nazývá předávání - forwarding. U směrovačů je forwarding požadován, u klasického počítače, který neslouží jako směrovač je tato vlastnost spíš nežádoucí. Proč dva protokoly? Linkový a IP? Linkový protokol (Ethernet) slouží k dopravě dat v rámci LAN. Tedy k dopravě k nejbližšímu směrovači. Směrovač linkový rámec „vybalíÿ a „přebalíÿ do jiného linkového rámce (i když se použije stejný linkový protokol).
Linkový rámec má po přebalení jiné fyzické adresy. Směrovač nemění obsah IP datagramu.
32
33
Pokud by se používala pro dopravu dat pouze linková adresa (6B), tak mluvíme o nesměrovatelných protokolech. Data je možné dopravovat pouze v rámci LAN - neprojdou za směrovač. Např. protokol NetBEUI (Microsoft).
34
35
6.2
IP datagram
IP datagram se skládá ze záhlaví a přenášených dat.
Popis IP datagramu: • celková délka - max. délka je 65535B • doba životnosti datagramu - TTL - slouží k zamezení nekonečného toulání IP datagramu Internetem. Každý směrovač snižuje TTL alespoň o jedničku. Není-li možné již snížit, datagram se zahazuje. • protokol vyšší vrstvy - číselná identifikace protokolu vyšší vrstvy, který využívá IP datagram ke svému transportu – ICMP = 1 – IGMP = 2 – TCP = 6 – UPD = 17 (desítkově)
6.3
Protokol ICMP
Protokol ICMP je služební protokol, který je součástí IP-protokolu. Slouží k signalizaci mimořádných událostí v sítích s IP-protokolem. Své pakety balí do IP-protokolu.
36
37
38
• Echo Echo je jednoduchý nástroj protokolu ICMP, kterým můžeme testovat dosažitelnost jednotlivých uzlů v síti.
39
– žadatel vyšle ICMP paket - „Žádost o Echoÿ – cílový uzel je povinen odpovědět ICMP paketem „Echoÿ Toto využívá program ping • Nedoručitelný IP datagram Nejde-li doručit IP datagram dále směrem k adresátovi, je zahozen a odesílateli je protokolem ICMP uvědomen zprávou „Nedoručitelný IP-datagramÿ • Sniž rychlost odesílání Pokud je síť mezi odesílatelem a příjemcem někde přetížena, směrovač který není schopen dále předávat všechny datagramy, odešle odesílateli ICMP-datagram „sniž rychlost odesíláníÿ • Změň směrování - redirect pomocí tohoto ICMP-datagramu se provádí dynamické změny ve směrovací tabulce:
• Čas vypršel - time exceeded – kód=0 – položka TTL byla na směrovači snížena na nulu, datagram bude zlikvidován – kód=1 – počítač adresáta není schopen v daném čase sestavit z fragmentů celý IP-datagram
40
6.4
Protokoly ARP a RARP
Protokol ARP Řeší problém zjištění linkové adresy protější stanice ze znalosti její IP-adresy. • do LAN se odešle linkový oběžník (broadcast – FF:FF:FF:FF:FF:FF) a žádostí o zjištění linkové adresy pro IP-adresu příjemce • stanice s IP příjemce odpoví
41
Protokol RARP Slouží k překlad linkové adresy na IP-adresu - reverzní ARP. Smysl protokolu RARP je pouze pro bezdiskové stanice - znají pouze svoji linkovou adresu (MAC) a potřebují zjistit svoji IP-adresu. Dnes víceméně nahrazeno komplexnějším protokolem DHCP.
6.5
IP adresa
Protokol IPv4 používá adresu o délce 4 byty. IP adresa jednoznačně identifikuje síťové rozhraní systému. Jednoznačná adresa se nazývá unicast. Pokud má systém více síťových karet (více síťových rozhraní) - každé má svoji jednoznačnou IP adresu. Na jednom síťovém rozhraní je možné provozovat několik IP-adres. První adresa se obvykle nazývá primární a další adresy sekundární nebo aliasy. IP aliasing je možné využít např. pro provozování několika různých WWW serverů na jednom síťovém rozhraní (virtuální WWW servery). Většina počítačů má pouze jedno síťové rozhraní, takže IP adrese se říká IP adresa počítače IP adresa je tvořena 4 byty a zapisuje se notací, kdy se jednotlivé byty oddělují tečkou: • dvojková notace - jednotlivé bity každého bajty se vyjadřují jako dvojkové číslo: 10101010.01010101.11111111.11111000 42
• desítková notace - čtyři osmiciferná jsou zapsána jako desítková čísla: 170.85.255.248 • šestnáctková notace - jednotlivé bajty se vyjadřují v šestnáctkové soustavě: aa.55.ff.f8 • IP-adresa se skládá ze dvou částí: • adresy (lokální) sítě • adresy počítače v (lokální) síti Jak zjistit, která část IP-adresy je adresa sítě a která adresou počítače?
6.5.1
Síť - historická epocha I
Tato epocha byla od počátku Internetu až do roku 1993. V této epoše bylo slovo síť specifikováno RFC-796 (J.
Postel 1.9.1981). Kolik bajtů z IP-adresy tvoří adresu sítě určují počáteční bity prvního bajtu adresy. IP-adresy se dělí do pěti tříd: • třída A - nejvyšší bit prvního bajtu má hodnotu 0.Zbylých 7 bitů prvního bajtu tvoří adresu sítě, zbytek adresu počítače v rámci sítě. V třídě A je tedy 126 sítí (mimo 0 a 127 - mají zvláštní význam). V každé síti je 2 na 24 - 2 adres pro počítače (adresy tvořené samými nulami a jedničkami • třída B - nejvyšší dva bity prvního bajtu mají hodnotu 10 (binárně), zbylých 6 bitů a následující bajt je určen pro adresu sítě (14 bitů), pro počítače v každé síti zbývá 16 bitů (2 bajty) - tedy 2 na 16 -2 počítačů • třída C - nejvyšší3í tři bity prvního bajtu mají hodnotu 110 (bin). Zbylých 5 bitů a následující 2 bajty jsou určeny pro adresu sítě (2 na 22 sítí). Pro počítače zbývá 1 bajt - tedy 256 - 2 počítačů.
43
Speciální IP adresy IP adresa je obecně ve tvaru: síť.počítač • Jsou-li na místě sítě nebo počítače binárně samé nuly - pak se to vyjadřuje slovem „tentoÿ • Jsou-li tam samé jedničky - pak se to vyjadřuje slovem všichni
44
Každé síťové rozhraní - interface - má alespoň jednu jednoznačnou adresu - unicast Celý systém má jednu adresu programové smyčky 127.0.0.1 Síťová maska Síťová maska určuje, které bity v IP adrese tvoří adresu sítě. Síťová maska je čtyřbajtové číslo - bity, které jsou částí adresy sítě mají hodnotu 1, ostatní jsou 0 Standardní sítové masky: třída A 255.0.0.0 třída B 255.255.0.0 Síťová maska slouží k vyřešení úlohy: jak určit adresu sítě, na které leží počítač o třída C 255.255.255.0 dané IP adrese.
6.5.2
Síť - historická epocha II
V roce 1993 vyšly RFC-1517 až 1520. Tato RFC změnila pohled na slovo síť jak je chápáno v Internetu. Přestalo se na sítě hledět přes sítě, ale výhradně přes síťové masky. Víceméně se změnilo původní dělení Ip adresy na adresu sítě a adresu počítače, na dělení na adresu sítě, adresu subsítě a adresu počítače.
Z hlediska síťové masky je adresa sítě i subsítě jeden celek. Adresy s maskami majícími méně jedniček než je standardní maska se nazývají adresy super-sítí, adresy s maskami o více jedničkách než má standardní maska se nazývají adresy subsítí.
45
46
Subsítě Síťová maska nerozlišuje mezi částí IP adresy určené pro síť a pro subsíť.
Jak mohu rozdělit IP adresu sítě třídy C (např. 194.149.115.0)?
47
6.5.3
IP-adresy v intranetu
Použití technologie Internetu uvnitř uzavřené firemní sítě se nejprve označovalo slovem - internet (malé i), později se objevilo slovo - intranet. IP-adresy musí být v Internetu přidělovány celosvětově jednoznačně. Dříve si firma volila libovolné IPadresy pro svoji firemní síť, když neuvažovala, že se někdy bude připojovat do Internetu. Po připojení do Internetu byly nuceny svoje sítě přečíslovat. Kolidující adresy je možné také obejít pomocí NAT (Network Address Translator). Lépe je použít adres třída A 10.0.0.0/8 10.0.0.0 až 10.255.255.255 172.16.0.0 až 172.31.255.255 tzv. neveřejných podle RFC1918: třída B 172.16.0.0/12 Použití těchto třída C 192.168.0.0/16 192.168.0.0 až 192.168.255.255 adres také zvyšuje bezpečnost sítě, protože v Internetu jsou nepoužitelné. O přidělení těchto adres není třeba nikoho žádat.
48
6.5.4
Dynamicky přidělované adresy
Je-li interval adres přidělen, je nutné adresy sdělit jednotlivým stanicím (rozhraním) na síti. Existují dvě možnosti: • staticky - trvalé přidělení IP-adresy • dynamicky - přidělení IP-adresy na dobu připojení V protokolu DHCP žádá klient DHCP-server o přidělení IP-adresy (případně o další služby). DHCP-server může být realizován jako proces na počítači s operačním systémem UNIX, Windows NT atp. Nebo DHCPserver může být realizován i jako součást směrovače. Zatímco přidělování IP-adres na LAN je v současné době doménou protokolu DHCP, pro přidělování IPadres počítačům za komutovanou linkou (např. zákazníkům poskytovatele Internetu) se zpravidla přidělují IP-adresy pomocí protokolu PPP. Protokol PPP je linkovým protokolem používaným na asynchronních sériových linkách. Neumožňuje takové služby jako protokol DHCP, avšak přidělit IP-adresu stanice umí. Adresní plán Před připojením k Internetu je potřeba udělat adresní plán: • schematické znázornění propojení jednotlivých LAN do WAN • seznam jednotlivých LAN s odhadovaným počtem síťových rozhraní na LAN Adresní plán by měl obsahovat rezervu s výhledem na příští období. Jako rezerva se běžně bere dvojnásobek současného stavu.
49
6.6
Směrování
Směrování IP-datagramů (IP routing) a předávání IP-datagramů (IP forwarding) jsou dva procesy, na kterých Internet stojí. Základní schema směrování vypadá takto:
50
• loopback - programová smyčka - použije se vždy, když nějaké rozhraní zjistí, že je potřeba něco předat opět na vstup • někdy operační systém informace automaticky předává na výstup, bez zásahu aplikačních programů. Jedná se o: – explicitní směrování - source routing – předávání - forwarding – požadavek o echo - echo request – přesměrování - redirect Operační systémy mají v jádře nějaké parametry, kterými lze takováto automatická zpracování IP-datagramů zakázat. Velice často je zakázáno explicitní směrování.
6.6.1
Předávání a filtrace
Vlastností mnohých OS je, že IP-datagramy nepředávají mechanicky, ale provádějí filtraci (screening) - nepředávají všechny pakety, ale jen některé - prolustrované. Předávaný IP-datagram se předá filtračnímu procesu, který buď předání schválí nebo zamítne. . Filtrační proces se rozhoduje buď na základě informací: • IP-záhlaví - není-li adresát nebo příjemce na „černé listiněÿ • TCP-záhlaví - např. podle čísel portu • aplikační protokol - použití u firewallů
51
6.6.2
Směrování
Směrování je podobné třídění dopisů na poště.
Směrovač třídí IP-datagramy. Tento proces se nazývá směrování. Směrovač obdrží IP-datagram a musí rozhodnout, do kterého svého rozhraní jej má vhodit, kterému svému sousedovi (next hop) jej má poslat. Zjednodušeně řečeno - směrovač je zařízení, které předává IP-datagramy z jednoho svého rozhraní do jiného. Směrovač umí předat IP-datagram i do stejného rozhraní, ale považuje to za neobvyklé a pošle odesílateli IPdatagram (ICMP-paket - redirect). Směrovač obdržel paket s cílovou adresou 10.5.2.1 - do jakého rozhraní jej má vložit?
52
Směrovači k rozhodování slouží směrovací tabulka (= třídící stůl na poště). Směrovací tabulka má v prvním sloupci IP-adresu cílové stanice. Základní pravidlo směrování zní: Více specifická adresa cílové sítě má přednost před méně specifickou Více specifickou adresou se rozumí adresa, která má v síťové masce více jedniček. Pokud se ve směrovací tabulce najdou dvě či více cest vedoucí k cíli, zvolí se ta více specifická. V případě, že se najdou dvě stejně specifické cesty, zvolí se ta s nejnižší metrikou (cenou). Zpracování • Pokud je směrovací tabulka sestupně setříděna, pak stačí tabulku procházet od shora dolů. • na každém řádku se vezme síťová maska, která se bit po bitu vynásobí s IP-adresou příjemce IPdatagramu • výsledek se porovná s prvním sloupcem • pokud se výsledek nerovná IP-adrese sítě v prvním sloupci, pak se přejde na zpracování dalšího řádku • pokud se výsledek shoduje s IP-adresou v prvním sloupci, otestuje se ještě následující řádek, zda neexistuje k cíli ještě jiná cesta - pak by se rozhodovalo na základě metriky Příklad: Směrovač je postaven před rozhodnutí, kterým svým síťovým rozhraním IP-datagram o adrese 10.5.2.1 odeslat. Prochází směrovací tabulku: 1. řádek 192.168.1.0 255.255.255.0 92.168.254.5 serial 1 4 Vynásobením (AND) cílové adresy 10.5.2.1 a maskou 255.255.255.0 dostaneme 10.5.2.0, což se nerovná IP-adrese v první sloupci (192.168.1.0). Vyhodnocení pokračuje dalším řádkem. 2. řádek 10.1.2.0
255.255.255.0
lokální rozhraní
Ethernet
0
Vynásobením (AND) cílové adresy 10.5.2.1 a maskou 255.255.255.0 dostaneme 10.5.2.0, což se nerovná IP-adrese v první sloupci (10.1.2.0). Vyhodnocení pokračuje dalším řádkem. 3. řádek 10.5.1.0
255.255.255.0
10.10.10.2
serial 2
3
Vynásobením (AND) cílové adresy 10.5.2.1 a maskou 255.255.255.0 dostaneme 10.5.2.0, což se nerovná IP-adrese v první sloupci (10.5.1.0). Vyhodnocení pokračuje dalším řádkem. 4. řádek 10.5.0.0
255.255.0.0
10.5.5.0
serial 1
2
Vynásobením (AND) cílové adresy 10.5.2.1 a maskou 255.255.255.0 dostaneme 10.5.2.0, což se rovná IP-adrese v první sloupci (10.5.0.0). datagram se vloží do rozhraní serial 1 a bude předán směrovači s IP-adresou 10.5.5.5. Pokud by se nejednalo o sériovou linku, ale např. o Ethernet, pak by bylo třeba zjistit linkovou adresu směrovače o IP-adrese 10.5.5.5 protokolem ARP. 5. řádek 0.0.0.0
0.0.0.0
10.10.10.2
serial 2
1 53
6. řádek 10.5.0.0
255.255.0.0
10.5.5.0
serial 1
2
Poslední řádek obsahující v prvním sloupci 0.0.0.0 s maskou 0.0.0.0 se nazývá default. Tímto implicitním směrem jsou odesílány všechny IP-datagramy, pro které nevyhověl žádný jiný řádek směrovací tabulky. Tento řádek vyhoví každé IP-adrese. Implicitní směr v tabulce být nemusí. Často je implicitní směr cestou do Internetu.
6.6.3
Manipulace se směrovacími tabulkami
Směrovací tabulku je třeba jednotlivými položkami naplnit. POložky jsou v tabulce trvale, dokud se nezmění nebo se systém nevypne. Pojmem gateway se často rozumí následující směrovač (next hop). Výpis směrovací tabulky v systému NT:
Výpis směrovací tabulky v systému UNIX:
Slpupec Flags - příznaky: • U - up - směr je dostupný
54
• G - gateway - cesta k cíli vede přes směrovač. Next hop je směrovač. Linková vrstva bude hledat linkovou adresu uvedeného směrovače, nikoli přímo adresáta, ten není přímo dostupný. • H - host - jedná se o adresu rozhraní (počítače), nikoliv sítě. Maska je 255.255.255.255. • D - položka byla vytvořena na základě ICMP-zprávy. • M - položka byla na základě zprávy redirect modifikována. • S - static - jedná se o statickou položku, vytvořenou příkazem route. Naplnění tabulky a rušení položek Směrovací tabulka se plní: • při konfiguraci síťového rozhraní, kdy říkáme jakou má síové rozhraní adresu a masku. V UNIXu se jedná o příkaz ifconfig • staticky (ručně) příkazem route. • dynamicky pomocí ICMP-zpráv redirect. • dynamicky směrovacími (aplikačními) protokoly. Příkaz route v NT: route [-f] [command [destination] [MASK netmask] [gateway] [METRIC metric]] -f vymaže nejprve obsah směrovací tabulky -p u příkazu ADD zajistí, aby tato položka zůstala ve směrovací tabulce i po restartu PC command určuje příkaz pro manipulaci se směrovací tabulkou: PRINT - vypiš obsah tabulky ADD - přidej položku do tabulky DELETE - zruš položku v tabulce CHANGE - změň položku destination specifikuje cílovou síť netmaskspecifikuje síťovou masku gatewayspecifikuje next hop METRIC specifikuje metriku příklad: route -p add 10.0.0.32 mask 255.255.255.240 192.168.1.2 V systému UNIX je příkaz bohtaší. Nejsou zde trvalé položky - po restartu je vždy potřebné tabulku nově naplnit.
55
Kapitola 7
Transportní vrstva 7.1
Protokol TCP - Transmision Control Protocol
Protokol TCP je proti protokolu IP protokolem vyšší vrstvy. Proč jsou potřeba dva protokoly? IP přepravuje data mezi libovolnými počítači v Internetu, protokol TCP dopravuje data mezi dvěma konkrétními aplikacemi běžícími na těchto počítačích. Pro dopravu dat mezi počítači využívá protokol IP. IP protokol adresuje pouze síťové rozhraní počítače (např. síťový adaptér). Protokol TCP je spojovanou službou (connection oriented): • mezi dvěma aplikacemi naváže spojení • na dobu spojení vytvoří virtuální okruh • okruh je plně duplexní - data se mohou přenášet současně oběma směry na sobě nezávisle • přenášené bajty jsou číslovány • ztracená nebo poškozená data jsou znovu vyžádána • integrita dat je zabezpečena kontrolním součtem Zabezpečeni přenosu je účinné pouze proti poruchám technických prostředků. Nejedná se o zabezpečení proti inteligentnímu útočníkovi, který data modifikuje a zároveň modifikuje i kontrolní součet. Proti těmto útokům je účinný např. protokol SSL (vyšší vrstva). Konce spojení (odesílatel - adresát) jsou určeny číslem portu. Číslo portu je dvojbajtové - může nabývat hodnot 0-65535. Pro protokol UPD je označeni portu také dvojbajtové. Jedná se o jinou sadu portů. Pro rozlišení se zapisuje např. 53/tcp nebo 53/udp (tyto dva porty nemají nic společné). Cílová aplikace je v Internetu jednoznačně určena (adresována): • IP-adresou • číslem portu • použitým protokolem - TCP nebo UDP Protokol IP dopraví IP-datagram na konkrétní počítač. Na tomto počítači běží jednotlivé aplikace. Podle čísla portu operační systém pozná, které aplikaci má TCP-segment doručit. Porty připomínají poštovní schránky v paneláku:
56
Základní jednotkou přenosu v protokolu TCP je TCP-segment. Někdy se říká TCP-paket, ale segment je lepší vyjádření. Příklad: Aplikace potřebuje přenést soubor 2 GB velký. TCP-segmenty jsou baleny do IP-datagramů, které má pole ’délka’ dlouhé 16 bitů, tak TCP-segment může být dlouhý maximálně 65535 minus délka TCP-záhlaví. Přenášené 2 GB dat musí být rozděleny na segmenty, které se vkládají do TCP-paketu - tedy TCP-segmentu. TCP-segment se vkládá do IP-datagramu, IP-datagram se vkládá do linkového rámce (např. Ethernet protokolu). Je-li TCP-segment příliš velký, který se celý vloží do velkého IP-datagramu, který je větší než max. velikost přenášeného linkového rámce (MTU), pak IP protokol musí provádět fragmentaci IP-datagramu. Fragmentace zvyšuje režii, proto je cílem vytvářet segmenty takové velikosti, aby fragmentace nebyla nutná.
57
7.2
TCP segment
58
Struktura TCP-segmentu: • zdrojový port (source port) - port odesílatele segmentu • cílový port (destination port) - port adresáta segmentu • pořadové číslo odesílaného bajtu - pořadové číslo prvního bajtu TCP-segmentu v toku dat (32 bitů), číslování začíná od náhodně zvoleného čísla • pořadové číslo přijatého bajtu - číslo následujícího bajtu, který je příjemce připraven přijmout, příjemce potvrzuje, že přijal vše do tohoto bajtu • délka záhlaví - vyjadřuje se v násobcích 32 bitů • délka okna - přírůstek pořadového čísla bajtu, který bude ještě příjemcem akceptován • ukazatel naléhavých dat – URG - TCP-segment nese naléhavá data – ACK - TCP-segment má platné „pořadové číslo přijatého bajtuÿ – PSH - TCP-segment nese aplikační data – RST - odmítnutí spojení – SYN - odesílatel začíná s novou sekvencí číslování, TCP-segment nese pořadové číslo prvního odesílaného bajtu – FIN - odesílatel ukončil odesílání • kontrolní součet - počítá se z přenášených dat
7.3
Navázání a ukončení spojení protokolem TCP
Protokol TCP využívá k transportu dat protokol IP, nad tímto protokolem zřizuje spojovanou službu. Musí řešit problémy: • navazování spojení • ukončení spojení • potvrzování přijatých dat • vyžádání ztracených dat • problémy průchodnosti přenosové cesty Popis TCP segmentu je jen malé část popisu TCP protokolu. Podstatně rozsáhlejší částí je popis výměny TCP segmentů - handshaking - mezi oběma konci spojení
7.3.1
Navazování spojení
Protokol TCP umožňuje jedné straně navazovat spojení, druhá strana spojení buď akceptuje nebo odmítne. Z hlediska aplikační vrstvy: • server - strana, která spojení očekává • klient - strana, která spojení navazuje Nejběžnější aplikační model je klient/server. Protokol TCP umožňuje i to, že by spojení navazovaly obě strany současně.
59
Příklad: • klient si přeje navázat spojení se serverem bežícím na počítači „serverÿ na portu 4433 (server:4433) • klient pro spojení používá port 1458 • port serveru musí být všeobecně znám - klienti o něm musí vědět • klientovi je zpravidla přidělen nějaký volný port operačním systémem na dobu spojení - OS přiděluje tímto způsobem portu větší než 1024 (klientské, neprivilegované porty) • porty menší než 1024 - privilegované porty, může je použít pouze privilegovaný uživatel (UNIX - root) • servery používají všeobecně známá čísla portů - přiděluje organizace IANA tvůrcům serverů
60
Proces navázání spojení • klient vygeneruje náhodné číslo, které použije jako startovací pořadové číslo odesílaného bajtu (ISN) • ISN = 145165778 • vytvoření startovacího pořadového čísla odesílaného bajtu označí v TCP segmentu nastavením příznaku SYN (. . . .S.) • v žádném dalším segmentu tohoto spojení nemůže klient nastavit příznak SYN • segment (1) je prvním segmentem TCP - nemůže potvrzovat žádná přijatá data • pole „pořadové číslo bajtuÿ nemá platný význam - binární nuly • nemůže být u tohoto segmentu nastaven příznak ACK • kombinace nastaveného příznaku SYN a nenastaveného ACK je specifická pro první TCP segment spojení - žádost o spojení • součástí segmentů (1) a (2) byla volitelná položka záhlaví - MSS (Maximum segment size) • položka oznamuje druhé straně max. délku datové části TCP segmentu jakou si přeje přijímat (aby se zamezilo fragmentaci IP-datagramů) • volba MSS se může vyskytovat pouze v TCP segmentech s nastaveným SYN (první dva segmenty) • implicitně je MSS = 536 bajtů (použitelné pro spojení mimo lokální síť - WAN)
61
• pro Ethernet II je max. délka datové části rámce = 1500 (1500 - 20 pro IP-záhlaví - 20 pro TCP záhlaví = 1460) • segment (2) již potvrzuje přijatí data - nastaven příznak ACK • od segmentu (2) budou již všechny segmenty potvrzovat přijatá data - bude nastaven příznak ACK • segment (3) také potvrzuje příznak SYN • segment (3) a další již nemohou nést volitelnou položku záhlaví MSS • segmentem (3) končí navazovaní spojení • protokol TCP potřebuje pro navázání spojení „třífázový handshakingÿ • segment (4) - od klienta k serveru, po obdržení ACK od druhé strany je možné začít s vysíláním dat • jedná se o duplexní spoj • segment, který nese aplikační data má nastaven příznak PSH • segment s nastaveným ACK a PSH (.AP. . .) - nese aplikační data a potvrzuje příjem dat od druhé strany • segment s pouze ACK (.A. . . .) pouze potvrzuje příjem dat (asi momentálně nemá co poslat, ale musí potvrzovat příjem) V každém okamžiku je spojení v nějakém stavu. Při navazování spojení to může být: • server ve stavu: – LISTEN - server je připraven na spojení s klienty – SYN RCVD - server přijal od klienta první TCP segment - segment s příznakem SYN • klient ve stavu: – SYN SEND - klient odeslal první segment se SYN Pokud se spojení naváže, tak obě strany (klient i server) přecházejí do stavu ESTABLISHED - spojení navázáno. V tomto stavu mohou oba konce současně přenášet data (duplexní spoj).
62
Spojení a jejich stav je možné vypsat příkazem netstat -a
Odmítnutí spojení Spojení se odmítá nastavením příznaku RST (Reset) v záhlaví segmentu TCP. Spojení je odmítáno v zásadě ve dvou případech: • Klient požaduje spojení na portu, na kterém neběží žádný server. • Je odmítnuto pokračovat v již navázaném spojení. Možno rozlišit dva případy: – Aplikace si po odeslání ukončit spojení rychle (nechce dlouho vyčkávaly ve stavu TIME WAIT). Proto použije odmítnutí spojení. – Jedna ze dvou stran zjistí, že protějšek je nedůvěryhodný, pak okamžitě ukončí spojení. Např, při použití protokolu SSL. Protokol SSL zabezpečuje bezpečnou komunikaci (šifrovanou a autentizovanou). Pokud se nedokáže jedna strana autentizovat nebo neumí použít silné kryptografické algoritmy, jak vyžaduje druhá strana, tak je spojení okamžitě ukončeno nastavením příznaku RST. Přenos dat Když je spojení navázáno, obě strany mohou posílat data. TCP-segmenty obsahují příznaky PSH (segment nese aplikační data), případně příznak ACK (potvrzení přijatých dat). Pokud nemá jedna ze stran co posílat - alespoň musí potvrzovat data přijatá z druhé strany (příznak ACK).
63
7.3.2
Ukončování spojení
Spojení zpravidla zahajuje klient (v architektuře klient/server), ukončit spojení může libovolná strana. Spojení ukončuje TCP segment s příznakem FIN. Provádí tzv. aktivní ukončení spojení (active close). Druhá strana je nucena provést tzv. pasivní ukončení (pasive close). Postup při ukončování spojení:
• segment (6) aktivuje uzavření spojení nastavením FIN • segment (7) potvrzuje uzavření spojení - zahájeno polouzavřené spojení - half duplex • strana, která aktivně spojení uzavřela, již nemůže poslat data • většinou segment (7) obsahuje také příznak FIN a spojení uzavře i druhá strana • ale - strana, která zatím neposlala FIN, může v přenosu dat pokračovat (half duplex) - polouzavřené spojení • segmentem (8) uzavírá spojení i druhá strana (.A. . .F) • segment (9) potvrzuje uzavření spojení (.A. . . .)
64
Stavy při ukončování spojení:
• FIN WAIT1 - strana zjistila, že již vše odeslala, a oznámí to příznakem FIN (obdoba konce souboru EOF) - signalizuje aktivní uzavření spojení • CLOSE WAIT - druhá strana obdržela aktivní uzavření spojení a nezbývá nic jiného než toto potvrdit (segment (7)) - přechod do pasivního uzavření spojení • FIN WAIT2 - stav po obdržení potvrzení segmentem (7) od protějšku. Strana teď čeká na aktivní ukončení od druhé strany • LAST ACK - druhá strana odeslala všechna data a signalizuje ukončení spojení segmentem (8) • TIME WAIT - všechna data byla již oběma směry předána. Je nutné pouze potvrdit úplné uzavření spojení. Odeslání (9) je potvrzeno úplné ukončení spojení. Tento segment již není potvrzován. • CLOSED - druhá strana obdržela potvrzení úplného uzavření spojení a přechází do stavu CLOSED. Strana, která odeslala (9) přechází do stavu CLOSED po uplynutí určitého intervalu (cca 30s) Ukončení spojení je čtyřfázové.
65
7.4
Protokol UDP
Protokol UDP je jednoduchou alternativou protokolu TCP. Protokol je nespojovaná služba (rozdíl oproti protokolu TCP) - nenavazuje spojení. Odesílatel odešle UDP datagram příjemci a už se nestará o to, Zda se náhodou datagram cestou neztratil (o to se případně musí postarat aplikační protokol). UPD datagramy jsou baleny do IP-datagramu:
66
Záhlaví UDP protokolu je velice jednoduché. Obsahuje čísla zdrojového a cílového portu - to je zcela analogické protokolu TCP. UDP má svoji nezávislou sadu čísel portů. Pole délka dat obsahuje délku UDP datagramu (záhlaví + data). Výpočet kontrolního součtu je v protokolu UDP nepovinné. Oběžníky Adresátem UDP datagramu nemusí být pouze jednoznačná IP-adresa, tedy konkrétní síťové rozhraní počítače, ale i skupina stanic - adresovat lze i oběžník. Adresovat lze všeobecné oběžníky - broadcast, ale i adresné oběžníky - multicast.
67
Kapitola 8
Aplikační vrstva 8.1
Služba DNS
Všechny aplikace používají k identifikaci uzlů IP-adresu. Pro člověka je jednodušší zapamatovat si jmenné označení síťového rozhraní. Pro každou IP-adresu máme zavedeno jméno síťového rozhraní (počítače) - doménové jméno počítače. Výjimkou, kdy musíme použít IP-adresu, je identifikace samotného name serveru. Jedna IP-adresa může mít přiřazeno i několik doménových jmen. Vazba mezi jménem počítače a IP-adresou je definována v DNS databázi (Domain Name System). Jedná se o celosvětově distribuovanou databázi. Jednotlivé části této databáze jsou umístěny na tzv. name serverech.
Použití IP-adres místo doménových jmen je praktické, když máme podezření, že DNS nepracuje správně. http://194.149.104.203 ping 194.149.104.203 jmeno@[194.149.104.203] Problém může nastat při číselném označení severů při dopravě pošty.
8.1.1
Domény a subdomény
Celý Internet je rozdělen do tzv. domén - skupin jmen, která k sobě logicky patří. Domény specifikují, patří-li jména jedné firmě, jedné zemi apod. V rámci domény je možné vytvářet podskupiny - subdomény. Každá skupina má přiřazeno jméno, z jednotlivých jmen se pak skládá doménové jméno uzlu. Doménové jméno • skládá se z řetězců vzájemně oddělených tečkou • jméno se zkoumá zprava doleva
68
• nejvyšší instancí je tzv. root doména, vyjadřuje se tečkou zcela vpravo (většinou se vynechává) • v root doméně jsou definovány tzv. generické domény - TLD - Top Level Domains: edu, com, net, org, mil, int, arpa a dvojznakové domény jednotlivých států (ISO-3166) Jména tvoří stromovou strukturu:
Syntaxe jména: • jméno je uváděno v tečkové notaci • první řetězec je jméno počítače, další řetězec je jméno nejnižší3í vnořené domény • pro jednoznačnost by na konci řetězce měla být tečka - root doména • celé jméno může mít max. 255 znaků, jednotlivý řetězec max. 63 znaků • řetězce mohou obsahovat písmena, číslice, pomlčky (nesmí být na začátku nebo na konci) • možno používat malá i velká písmena Někdy je možné konec jména vynechat: • závěrečnou tečku je možné vynechat téměř vždy • na počítačích uvnitř domény je možné psát pouze jméno počítače bez domény
8.1.2
Reverzní domény
Komunikace probíhá na základě IP-adres, nikoli doménových jmen. Některé aplikace naopak potřebují k IPadrese nalézt tzv. reverzní záznam - překlad IP-adresy na doménové jméno. Tento překlad se často nazývá reverzním překladem. Podobně jako domény tvoří IP-adresy stromovou strukturu. Pro účely reverzního překladu byla definována pseudodoména in-addr.arpa (inverse addresses in the Arpanet).
69
Příklady: • síť 194.149.101.0 patří do domény 194.in-addr.arpa • síť 172.17 patří do domény 172.in-addr.arpa • síť 172.17 patří do subdomény 17.172.in-addr.arpa • reverzní doména pro subsíť 194.149.150.16/28 je 16.150.149.194.in-addr.arpa Doména 0.0.127.in-addr.arpa Komplikací je adresa 127.0.0.1 - síť 127 je určena pro loopback - softwarovou smyčku na každém počítači. Ostatní IP-adresy jsou v Internetu jednoznačné, adresa 127.0.0.1 se vyskytuje na každém počítači. Každý name server je zároveň autoritou (primárním name serverem) k doméně 0.0.127.in-addr.arpa Zóna Data o doméně uložené na name serveru jsou nazývány zónou. Zóna obsahuje jen část domény. Doména je skupina počítačů, které mají společnou pravou část svého doménového jména.
70
Domény a autonomní systémy Autonomní systémy dělí Internet z hlediska IP-adres (směrování), naproti tomu domény dělí Internet z hlediska jmen počítačů. Reverzní domény kopírují strukturu poskytovatelů Internetu.
71
8.1.3
Dotazy
Přeložení jména na IP-adresu zprostředkovává tzv. resolver. Resolver je klient, který se dotazuje name serveru. Databáze je celosvětově distribuována, tady nejbližší name server nemusí znát odpověď, proto tento name server může žádat o překlad další name servery. veškerá komunikace se skládá z dotazů a odpovědí. Name server po startu načte do paměti data pro zónu, kterou spravuje. Primární name server načte data z lokálního disku, sekundární name server dotazem zone transfer získá data z primárního name serveru. Data primárního a sekundárního name serveru se nazývají jako autoritativní. Name server i resolver společně sdílejí paměť cache. Během práce do ní ukládají kladné odpovědi na dotazy, které provedly jiné name servery. Z hlediska našeho name serveru jsou tato data neautoritativní. Šetří čas při opětovných dotazech.
72
Takto pracuje DNS na serverech. Na ostatních počítačích je realizován pouze tzv. pahýlový reslover - z celého mechanismu zůstane pouze resolver. resolver předává všechny požadavky na lokální name server. Od name serveru očekává konečnou (rekurzivní) odpověď. Name server odpoví přímo nebo sám kontaktuje další name servery - name server řeší rekurzivně dotaz a klientovi zašle až výsledek. Lokální name server udržuje společnou cache pro všechny lokální počítače.
73
DNS používá jak protokol UDP, tak protokol TCP.Vždy používá port 53 • 53/udp • 53/tcp Běžné dotazy - překlad jména na IP-adresu a naopak - se provádějí pomocí UDP. Délka přenášených dat je omezena na 512 B. Dotazy, kterými se přenášejí data o zóně (zone transfer ) - např. mezi primárním a sekundárním name serverem, se přenášejí protokolem TCP. V Internetu platí pravidlo, že databáze s daty nutnými pro překlad jsou uloženy alespoň na dvou nezávislých počítačích. Proč protokol UDP: • datagram se vyšle prvnímu serveru • nepřijde-li odpověď do krátkého časového okamžiku, pošle se datagram s žádostí dalšímu • zkusí se další, pak se kolečko opakuje do vypršení časového intervalu
74
8.1.4
Resolver
Resolver je komponenta zabývající se překladem IP-adresy. Resolver je klient. Jedná se o soustavu knihovních funkcí, která se linkuje s aplikačními programy, požadujícími tyto služby (telnet, ftp, WWW). Potřebuje-li např. WWW-klient převést jméno počítače na IP-adresu, pak zavolá příslušnou knihovní funkci. • klient zavolá knihovní funkce, které0 zformulují dotaz a vyšlou jej na server • v UNIXu je server realizován programem named • server provede překlad sám nebo si vyžádá pomoc od dalších serverů, nebo zjistí, že překlad není možný • pokud odpověď nedorazí, vyšle se dotaz na další name server uvedený v konfiguraci • použije se odpověď, která přišla jako první domain jméno-místní-domény Příkazem name server name server IP-adresa-name serveru se specifikuje IP-adresa name serveru, který má resolver kontaktovat. Příkazů name server je možné zadat více. Konfigurační soubor pro resolver v UNIXu:
75
V případě konfigurace resolveru na name serveru je možné zadat adresu 127.0.0.1 Pokud nechceme používat DNS a přesto chceme pracovat se jmény počítačů, je možné tyto překlady provádět lokálně pomocí souboru /etc/hosts. Je možné obě metody kombinovat. Konfigurace ve Windows:
8.1.5
Name server
Name server udržuje informace pro překlad: • jmen počítačů na IP-adresy • reverzní překlad (IP-adresy na jména) Obhospodařuje nějakou zónu - část z prostoru všech počítačů. Zóna je tvořena doménou nebo její částí. Name server může pomocí věty typu NS delegovat správu subdomény na name server nižší úrovně. Name server je program, který provádí na žádost resolveru překlad. V UNIXu je realizován programem named. Podle uložení dat rozlišujeme následující typy name serverů: 76
• primární name server - udržuje data o své zóně v databázích na disku. Pouze na primárním name serveru má smysl editovat tyto databáze. • sekundární name server - kopíruje si databáze v pravidelných časových intervalech z primárního name serveru. Primární a sekundární name server jsou tzv. autoritou pro své domény - jejich data se pro jejich zóny považují za věrohodná • caching only server - není pro žádnou doménu ani primární ani sekundární name server - není žádnou autoritou. Využívá obecné vlastnosti name serveru - data, která jím procházejí ukládá do své paměti. Tato data se označují jako neautoritativní. Každý server je caching, ale tento je only caching • root name server - name server obsluhující root doménu. Každý root name server je primárním name serverem, což jej odlišuje od ostatních name serverů Jeden name server může být pro nějakou zónu primárním name serverem, pro jinou může být sekundárním. Z hlediska klienta není mezi primárním a sekundárním name serverem rozdíl. Přidá-li správce zóny do databáze další počítač - po době stanovené ve větě SOA se tato databáze automaticky opraví na sekundárním name serveru. Autoritativní data pocházejí z databází na disku. Je zde pouze jedna výjimka - pro správnou činnost musí name server znát root name servery. Pro tyto však není autoritou, přesto každý name server má na disku databázi informaci o root serverech.
1. Resolver zformuluje požadavek na name server a očekává jednoznačnou odpověď. Umí-li name server odpovědět, pak obratem zašle odpověď. Odpověď hledá ve své cache paměti (5). Zde se nacházejí data získaná při předešlých řešeních (autoritativní i neautoritativní). Nezná-li odpověď, pak kontaktuje další 77
servery. Vždy začíná name serverem. Každý name server musí znát IP-adresy root name serverů. Není-li dostupný žádný root name server, pak pokus o překlad zkolabuje. Root name server zjistí, že informace o doméně cz delegoval větou typu NS na name server nižší úrovně. Dotazujícímu se name serveru vrátí IP-adresu separujícího doménu cz. 2. Name server se obrátí na server pro doménu cz, který zjistí, že informace o doméně delegovala větou NS na nižší úroveň. Vrátí tedy IP-adresu serveru spravujícího doménu pipex.cz 3. Server se obrátí na server spravující doménu pipex.cz, který požadavek vyřeší (nebo ne). Výsledek vrátí klientovi. 4. Informace, které server obdržel si uloží do cache. Forwarding a slave servery Tyto vlastnosti name serveru nesouvisí s tím, zda jsou primární nebo sekundární, ale souvisí se způsobem jejich překladu. Je-li síť připojena pomalou linkou, pak místní name server zatěžuje linku svými překlady. V tomto případě je výhodné name server konfigurovat jako forwarding server: • vezme požadavek od klienta a předá jej forwarderovi - name serveru na rychlé síti • forwarder dotaz rekurzivně vyřeší a pošle forwarding name serveru konečný výsledek • jako forwarder je praktické použít name server poskytovatele Internetu • forwarding server čeká na odpověď - nedočká-li se v daném časovém intervalu, pak sám kontaktuje root name servery a pokouší se překlad vyřešit sám Nemá-li name server kontaktovat root name servery, ale pouze čekat na odpověď, označujeme navíc tento server jako slave server • slave servery se používají v uzavřených podnikových sítích (za firewallem), kde není možné kontaktovat root name servery • slave server pak kontaktuje forwardera na firewallu • slave server musí být forwarding server
78
8.2
Implementace jmenného serveru - program named
Programem named je v Unixu realizován jmenný server. Program named si při startu přečte databáze DNS na disku a uloží je do paměti. Program named si při svém startu přečte konfigurační soubor named.boot. Konfigurační soubor je implicitně umístěn v adresáři /etc, jiné umístění konfiguračního souboru je nutné specifikovat parametrem na příkazovém řádku při spouštění programu named. Konfigurační soubor named.boot obsahuje následující příkazy: • directory - specifikuje adresář, ve kterém jsou uloženy databáze DNS na disku. V dalších příkazech se pak uvádějí jména souborů bez cesty. Příklad: directory /etc/namedb/namedb • primary - určuje, že jmenný server bude primárním jmenným serverem pro doménu uvedenou jako první parametr příkazu a příslušná databáze je v textovém souboru uvedeném jako druhý parametr. Příklad: primary pvt.cz db.pvt.cz Každý jmenný server musí být primárním jmenným serverem alespoň pro doménu 0.0.127.in-addr.arpa. Tj. ani v případě cacheování pouze jmenného serveru nesmí v jeho konfiguračním souboru chybět např. příkaz: primary 0.0.127.in-addr.arpa db.0.0.127 • secondary - určuje, že jmenný server bude sekundárním jmenným serverem pro doménu určenou prvním parametrem. Další parametry (musejí být uvedeny jako IP-adresy) jsou pak IP-adresy serverů, odkud se budou programem named-xfer přenášet data. Je-li uveden poslední parametr (nesmí být ve for- mě 79
IP-adresy), pak se chápe jako jméno souboru, kam se mají data po přenesení na počítači uložit. Příklad: secondary cbu.pvt.cz 172.17.14.1 172.17.18.1 cbu.pvt.cz.tmp ukazuje, že autoritativní data o doméně cbu.pvt.cz se mají kopírovat ze serveru o IP-adrese 172.17.14.1 a uložit do souboru cbu.pvt.cz.tmp. Když tento server není dostupný, pak se zkopírují ze serveru 172.17.18.1. Není-li uvedeno jméno souboru (poslední parametr), pak se přenesená data neukládají na disk. • cache - určuje z jakého souboru se mají zkopírovat do paměti informace o kořenových jmenných serverech. Příklad: cache . cache.db říká, že do paměti se mají uložit ze souboru cache.db informace o kořenových jmenných serverech. Tento soubor neobsahuje autoritativní data, tj. na počátku neobsahuje záznam SOA, takže každý záznam musí obsahovat explicitně uvedené všechny údaje - zejména pole TTL. • forwarders - určuje, že jmenný server je forwarding server. Jako další parametry se uvádějí IP-adresy jmenných serverů dostupných v Internetu (forwarderů). Příklad: forwarders 193.85.240.40 193.85.240.40 Stejná IP-adresa dvakrát? To je u forwarderů častý trik. Tím se totiž zvětší časový interval, po který forwarding server čeká na odpověď, než začne sám kontaktovat kořenové jmenné servery. • slave - následuje v případě podřízeného serveru (slave serveru) za příkazem forwarders a určuje, že jmenný server nemá kontaktovat v žádném případě kořenové jmenné servery. Příklad: forwarders 193.85.240.40 193.85.240.40 slave Příklad konfiguračního souboru pro primární jmenný server domény pvt.cz: directory /etc/namedb primary pvt.cz db.pvt.cz primary 17.172.in-addr.arpa db.172.17 primary 0.0.127.in-addr.arpa db.127.0.0 cache . db.cache
Databáze Databáze DNS jsou uloženy na primárním jmenném serveru v souborech. Při startu jmenného serveru se jejich obsah nahraje do paměti. Databáze DNS se skládá z jednotlivých souborů, které jsou specifikovány vždy jako poslední parametry jednotlivých příkazů konfiguračního souboru named.boot. Databáze na disku může obsahovat následující typy dat: • Autoritativní data k obhospodařované zóně. Musí začínat záznamem typu SOA. Mohou být udržována pouze na primárním jmenném serveru. Sekundární jmenný server je obdrží pomocí dotazu zónového přenosu z primárního nebo jiného sekundárního jmenného serveru. • Data umožňující přístup ke kořenovým jmenným serverům. Nezačínají záznamem SOA. Explicitně se v nich uvádí pole TTL. Jsou to neautoritativní data pro místní jmenný server. Musí být na každém jmenném serveru s výjimkou podřízeného serveru. 80
• Data pomocí nichž deleguje jmenný server autoritu k subdoménám na jiné jmenné servery. K delegování autority se používají věty typu NS. • V případě, že se deleguje autorita na jmenný server, jehož doménové jméno je součástí delegované subdomény, pak je třeba ještě přidat záznam typu A specifikující IP-adresu tohoto jmenného serveru. Obecná syntaxe jednotlivých řádků databáze (tzv.resource records) je: [name]
[TTL]
třída typ
Data_závislá_na_typu_věty
Pole v [] jsou nepovinná - jejich hodnoty se přejímají z předchozího záznamu, případně ze záznamu SOA. Komentáře jsou uvozeny středníky. Význam jednotlivých polí: • Pole name obsahuje doménové jméno. Může nastat několik situací: – Pole není vyplněné, pak se jeho hodnota bere z pole name předchozího záznamu. – V záznamu typu SOA může mít pole name hodnotu @. Takováto hodnota znamená, že se do pole name má dosadit jméno domény uvedené v příslušném příkazu souboru named.boot. – Doménové jméno je uvedeno v poli name bez tečky na konci, pak se automaticky za toto jméno dodá jméno domény uvedené ve větě SOA. V případě, že před větou (bez tečky na konci) je uveden příkaz $ORIGIN, pak se dodává jméno domény uvedené v příkazu $ORIGIN. – Doménové jméno je uvedeno v poli name s tečkou na konci, pak se jedná o tzv. absolutní jméno, které se bere tak, jak je napsáno. • Pole TTL obsahuje ve vteřinách dobu života záznamu v paměti. Jmenný server tuto hodnotu automaticky snižuje. Dosáhne-li hodnota nuly, pak se záznam prohlásí za neplatný. Implicitně má pole hodnotu nula. Avšak pokud předchází záznamu záznam typu SOA, pak se implicitní hodnota bere z pole TTL záznamu typu SOA. Záznam typu SOA je uveden vždy na počátku souboru, tj. nemusí náš záznam předcházet zcela bezprostředně. • Třída je IN (Internet), HS (Hesiod) či CH (Chaos). V našem případě se budeme zabývat výhradně záznamy typu IN. (Existují i implementace programu named podporující Hesiod, my se jimi však zabývat nebudeme.) • Typ je jeden z typů uvedených v tab. 11.1. • Poslední pole obsahuje data závislá na typu záznamu. Pokud se zde použije doménové jméno, pak nesmíme za ním zapomenout napsat tečku, protože v opačném případě by se za jméno automaticky dodalo jméno domény. Naopak pokud je zde IP-adresa, tak za čtvrtou číslicí v IP-adrese tečka být nesmí. Blíže viz RFC-1035. Formát záznamů Jména v databázi musí začínat na první pozici. Pokud je prvním znakem řádku mezera, pak se použije jméno z předchozího řádku. SOA Záznam typu SOA (Start Of Authority) - určuje jmenný server, který je autoritativním zdrojem informací pro danou doménu. Věta SOA je vždy právě jedna, a to na počátku souboru. Jako příklad - záznam pro server domény pvt.cz.: @ IN SOA cbu.pvt.cz. bindmaster.cbu.pvt.cz. ( 1 ;Serial 86400 ;Refresh after 24 hours 600 ;Retry after 5 min. 120960 ;Expire after 2 weeks 86400) ;Minimum TTL of 1 day
81
• Jméno pvt.cz, musí začínat od první pozice na řádku a musí končit tečkou. Označuje název zóny. Zpravidla se zde místo jména zóny napíše @, který říká, aby se název zóny vzal z druhého parametru (tj. jména domény) příkazu souboru named.boot. • IN označuje typ adresy (IN Internet) • První jméno za SOA (cbu.pvt.cz.) je jméno počítače, na kterém jsou data uložena (jméno primárního jmenného serveru) a druhé jméno (bindmaster.cbu.pvt.cz.) definuje poštovní adresu osoby zodpovědné za data. Jelikož znak @ má v záznamu SOA zvláštní význam, tak se místo znaku @ v poštovní adrese píše tečka, tj. místo
[email protected] se píše bindmaster.cbu.pvt.cz. • Závorky umožňují pokračování záznamu na dalších řádcích (pro přehlednost). 296 Velký průvodce protokoly TCP/IP a systémem DNS • Serial označuje sériové číslo verze databázového souboru. Pokud soubor změníme, musíme zvětšit i toto sériové číslo. Doporučujeme zásadně používat číslo tvaru rrrrmmddčč (rok, měsíc, den, číslo aktualizace v rámci dne). Sekundární jmenný server se dotazuje primárního jmenného serveru pouze na záznam typu SOA. Porovná hodnotu pole serial v záznamu typu SOA, a pouze v případě, že primární jmenný server má v záznamu typu SOA hodnotu pole serial větší než má sekundární jmenný server, pak se provede přenos zóny z primárního jmenného serveru na sekundární jmenný server. Takže pokud správce opraví databázi DNS na primárním jmenném serveru a opomene zvýšit hodnotu pole serial, pak se žádná sekundární data nepřenesou a změny se na sekundární jmenný server vůbec nedostanou. Pokud takovouto chybu správce primárního jmenného serveru zjistíte, pak máte jedinou možnost zrušit na sekundárním jmenném serveru soubor pro příslušnou zónu, program named na sekundárním jmenném serveru ukončit a znovu jej nastartovat. Hodnota pole serial neovlivňuje chování primárního jmenného serveru, tj. pokud pole opomenete na primárním jmenném serveru zvýšit, tak po restartu jmenného serveru se na primárním jmenném serveru změny provedou. • Další údaje udávají různé časové údaje v sekundách: – Refresh jak často mají sekundární servery ověřovat svá data. Zjistí-li při ověřování, že mají data s nižším serial, pak provedou protokolem TCP transfer zóny. – Retry jestliže sekundární server nemůže kontaktovat primární po uplynutí intervalu refresh, bude to dále zkoušet každých retry sekund. – Expire jestliže se sekundárnímu jmennému serveru nepodaří kontaktovat primární do expire sekund, přestane poskytovat informace (data jsou příliš stará). Musí platit: Expire ¿ Refresh. – TTL tato hodnota se vztahuje ke všem záznamům v db souboru (jako výchozí hodnota) a je poskytována jmenným serverem v každé jeho odpovědi. Říká, jak dlouho mohou ostatní servery (tj. neautoritativní servery) udržovat daný záznam ve své paměti cache (nula znemožňuje ukládání vět do cache). Nevíte-li, co zadat, pak RFC-1537 doporučuje pro top level domény:
86400 7200 2592000 345600
; ; ; ;
Refresh 24 hours Retry 2 hours Expire 30 days Minimum TTL 4 days
; ; ; ;
Refresh 8 hours Retry 2 hours Expire 7 days Minimum TTL 1 day
Pro ostatní domény:
28800 7200 604800 86400
82
8.2.1
A
Záznamy typu A (Address) přiřazují doménovým jménům počítačů IP-adresy. Za IP-adresou nesmí být tečka. Příklad 1: pvt.cz. ... www www.cbu muj.cbu.pvt.cz. tvuj ...
IN
SOA
...
IN IN IN IN
A A A A
172.17.14.1 172.17.18.1 172.17.14.2 10.1.1.3
V příkladě 1 záznamu typu A přiřazují IP-adresy počítačům: www.pvt.cz, www.cbu.pvt.cz, muj.cbu.pvt.cz a tvuj.pvt.cz.
8.2.2
CNAME
Větami typu CNAME vytváříme synonyma k doménovým jménům. Často se říká, že vytváříme „aliasy k jménům počítačůÿ? Příklad 2: firma.cz. ... mail www ...
IN
SOA
...
IN IN
A CNAME
192.1.1.2 mail.firma.cz.
Příklad 2 popisuje situaci, kdy firma má jeden počítač mail.firma.cz, který chce také používat jako wwwserver. Na pravé straně příkazu CNAME musí být doménové jméno, kterému je přiřazena IP-adresa záznamem typu A. Na pravé straně nesmí být synonymum, tj. CNAME nesmí ukazovat na CNAME. Příklad 3 ukazuje chybnou delegaci jmen. Příklad 3 (chybný!): firma.cz. ... mail www server ...
IN
SOA
...
IN IN IN
A CNAME CNAME
192.1.1.2 mail.firma.cz. www.firma.cz.
V záznamech typu CNAME se zásadně snažíme na pravé straně zapisovat úplné doménové jméno s tečkou na konci. V případě, že tečku neuvedeme, pak se dodá ještě jméno domény. Toho se sice v malých databázích dá využít, ale jak velikost databáze roste, tak se stává nepřehlednou a případné chyby tohoto druhu se někdy i těžko dohledávají.
8.2.3
NS
Záznamy typu NS definují autoritativní jmenné servery pro doménu. Na pravé straně musí být doménové jméno, kterému je přiřazena IP-adresa větou typu A. Na pravé straně nesmí být synonymum, tj. záznam typu NS nesmí ukazovat na záznam typu CNAME. Stejné záznamy typu NS jsou vždy ve dvou databázích:
83
1. V databázi domény vyšší úrovně. Těmito záznamy typu NS je delegována pravomoc na jmenný server nižší úrovně. V případě, že jméno jmenného serveru nižší úrovně samo leží v doméně nižší úrovně, pak musí být za tento záznam typu NS přidán ještě záznam typu A s IP-adresou jmenného serveru. To je nutné proto, že jmenný server vyšší úrovně musí IP-adresu jmenného serveru nižší úrovně uvádět v dodatečných informacích v DNS-odpovědi ? tj. aby bylo možné se na jmenný server nižší úrovně vůbec dostat. 2. Na autoritativním jmenném serveru pro doménu (tj. podle terminologie předchozího bodu na jmenném serveru ?nižší úrovně?). Příklad 5: Jmenný server domény firma.cz, tj. autoritativní jmenný server domény vyšší úrovně s přiřazeným neautoritativním záznamem typu A pro ns.cbu: firma.cz.
IN IN IN IN IN IN IN
ns cbu ns.cbu ...
SOA NS NS A NS NS A
... ns.provider.cz. ns.firma.cz 11.1.1.1 ns.firma.cz. ns.cbu.firma.cz. 11.2.2.2
Jmenný server domény cbu.firma.cz, tj. autoritativní jmenný server domény nižší úrovně má k dispozici databázi: cbu.firma.cz.
ns
IN IN IN IN
SOA NS NS A
... ns.firma.cz. ns.cbu.firma.cz. 11.2.2.2
... Na pravé straně vět typu NS je třeba psát úplná doménová jména s tečkou na konci!
8.2.4
MX
Záznamy typu MX specifikují poštovní server domény. V drtivé většině případů totiž nechceme mít mailovou adresu tvaru: uživatel@počítač.firma.cz ale pouze tvaru: už
[email protected] tj. přejeme si skrýt jméno poštovního serveru. Záznam typu MX ukazuje na jaký počítač má být pro doménu dopravena pošta. Navíc však v záznamu typu MX je číselná priorita, pomocí které lze určit několik počítačů, na než může být pošta pro doménu posílána. Nejprve se zkouší odeslat pošta na počítač s nejvyšší prioritou (nejnižším číslem), když se to nepodaří, pak na další počítač (s vyšším číslem) atd. Příklad 6 popisuje situaci, kdy pošta pro doménu firma.cz má být doručována na počítač mail.firma.cz, pokud tento počítač není dostupný, pak se pošta odešle na počítač mail1.provider.cz, kde vyčká do dostupnosti počítače mail.firma.cz. Pokud ani počítač mail1.provider.cz není dostupný, pak se pošta odešle na počítač mail2.provider.cz. Příklad 6: firma.cz.
IN IN IN IN
SOA MX MX MX
... 30 20 10
mail2.provider.cz. mail1.provider.cz. mail.firma.cz.
84
mail ...
8.2.5
IN
A
11.1.1.8
PTR
Záznam typu PTR slouží k překladu IP-adresy na doménové jméno. Tj. k překladu prvků domény in-addr.arpa na jméno počítače. Příklad 7 Záznamy typu PTR pro počítač ns.firma.cz o IP-adrese 195.47.200.1 a pro počítač www.firma.cz o IPadrese 195.47.200.201: 1.200.47.195.in-addr.arpa. 201.200.47.195.in-addr.arpa.
IN IN
PTR ns.firma.cz. PTR www.firma.cz.
Jenže takovýto příklad je zcela vytržený z kontextu. Ve skutečnosti je třeba si uvědomit celý mechanismus delegací. Náš příklad je podrobně popsán v příkladu 8. Příklad 8: Předpokládejme, že naší firmě (firma.cz) jsou přiděleny IP-adresy v rozsahu 195.47.200.0/24, tj. celá síť třídy C. Pak pro reverzní překlad musí být: 1. Na jmenném serveru ns.ripe.net, tj. jmenný server vyšší úrovně pro Evropu (Amsterodam): • V souboru named.boot bude uveden např. řádek primary 195.in-addr.arpa195.rev • V souboru 195.rev je pak např. uvedeno: 195.in-addr.arpa. ... 200.47
IN
SOA ...
IN IN
NS NS
ns.firma.cz. ns.provider.cz.
... 2. Na jmenném serveru ns.firma.cz (primární jmenný server): • V souboru named.boot bude uveden např. řádek: primary 200.47.195.in-addr.arpa 200.47.195.rev • souboru 200.47.195.rev je pak např. uvedeno: 200.47.195.in-addr.arpa.
1 201 ...
IN IN IN IN IN
SOA NS NS PTR PTR
... ns.firma.cz. ns.provider.cz. ns.firma.cz. www.firma.cz.
3. Na jmenném serveru ns.provider.cz (sekundární jmenný server) V souboru named.boot bude uveden např. řádek: secondary 200.47.195.in-addr.arpa 195.47.200.1 200.47.195.rev Je třeba opět připomenout, že se nesmí zapomínat psát tečky za jménem počítače (na pravé straně), protože v případě opomenutí tečky se dodá doména končící in-addr.arpa, což je opravdu nepoužitelné. Asi čekáte, že také zdůrazním, že na pravé straně nesmí být synonymum (CNAME), tj. že záznam typu PTR nesmí ukazovat na větu typu CNAME. Avšak není tomu tak. Dlouhá léta to bylo považováno za chybu v programu BIND, až se to stalo velice užitečnou pomůckou a posléze dokonce normou RFC- 2317.
85
8.2.6
$ORIGIN
V parametru name databázového záznamu se uvádí doménové jméno buď absolutně (s tečkou na konci) nebo relativně (bez tečky na konci). Právě za relativní doménové jméno se automaticky přidává implicitní doména. Příkaz $ORIGIN slouží pro změnu implicitní domény. Databáze DNS může obsahovat příkaz: $ORIGIN implicitní doména Od tohoto okamžiku je implicitní doména změněna na hodnotu uvedenou jako první parametr příkazu $ORIGIN. V případě, že se uvede relativní jméno, pak se doplňuje na úplné jméno přidáním domény definované v záznamu typu SOA nebo parametrem příkazu $ORIGIN, který předchází databázový záznam. Příkaz $ORIGIN tak mění implicitně nastavenou doménu. Není-li změněna implicitní doména příkazem $ORIGIN, pak se bere doména z příkazu SOA. Je-li v příkazu SOA místo domény znak @, pak se bere první parametr příkazu primary resp. secondary ze souboru /etc/named.boot.
8.3
DHCP server
Server pro dynamickou konfiguraci stanic pro provoz protokolu TCP/IP - Dynamic Host Configuration Protocol. Klientský počíta4 přijíma svoji konfiguraci ze sítě. • Klient vyšle do sítě žádost o IP adresu • DHCP server odpoví a pošle zpět asdresu společně s dalšími informacemi potřebnými pro dokončení síťové konfigurace Dynamické konfigurování je také výhodné pro konfiguraci mobilních nebo dočasně připojených počítačů. Se serverem DHCP umí komunikovat klienti z různých operačních systémů. Protokol DHCP je historicky odvozen z protokolu BOOTP (Boot Protocol). Tento protokol používaly bezdiskové (diskless) pracovní stanice pro zavedení operačního systému ze sítě.
8.3.1
Mechanismus DHCP
Klient vyšle požadavek o konfiguraci do sítě. Naslouchající server po přijetí požadavku zkontroluje svoji databázi a vyšle vhodnou odpověď. Odpověď vždy obsahuje adresu a navíc může obsahovat i údaje o name serverech, masce sítě a implicitní bráně. Klient po přijetí odpovědi provede konfiguraqci svých nastavení. Server DHCP si ukládá seznam adres, které může přidělit. každá adresa se přiděluje s tzv. lhůtou - jak dlouho může klient tuto adresu využívat, než je nutné znovu kontaktovat DHCP server a požádat o obnovení konfigurace.
8.3.2
Server DHCP
Server DHCP je v linuxu implementován démonem dhcpd - http://www.isc.org. Konfigurační souborem serveru je soubor /etc/dhcpd.conf: • sada deklarací popisující sítě, hostitelské počítače, možný rozsah přidělovaných adres • sada parametrů popisujících chování serveru a konfigurujících příslušné odpovědi Pro různé sdružování kientů slouží: • Group - použije určitou skupinu parametrů • Host - aplikovat na konkrétní kllientský počítač • Shared Network • Subnet • Range - rozsah IP adres Příklady:
86
option domain-name "pgchk.cz"; option domain-name-servers 172.16.1.100, 195.70.130.1, 195.70.130.19; subnet 172.16.1.0 netmask 255.255.255.0 { range 172.16.1.70 172.16.1.90; default-lease-time 600; max-lease-time 7200; option subnet-mask 255.255.255.0; option broadcast-address 172.16.1.255; option routers 172.16.1.100; } Složitější konfigurace:
# Sample configuration file for ISCD dhcpd # # Make changes to this file and copy it to /etc/dhcpd.conf # default-lease-time max-lease-time
21600; 21600;
option option option option option option
255.255.255.0; 192.168.1.255; 192.168.1.2; 192.168.1.2; "gybon.cz"; "192.168.1.100:/opt/ltsp/i386";
subnet-mask broadcast-address routers domain-name-servers domain-name root-path
shared-network WORKSTATIONS { subnet 192.168.1.0 netmask 255.255.255.0 { range 192.168.1.50 192.168.1.90; } } group { use-host-decl-names option log-servers # filename filename host ws001 { hardware ethernet fixed-address } host ws002 { hardware ethernet fixed-address } host ws003 { hardware ethernet fixed-address } host ws004 { hardware ethernet fixed-address } host ws005 {
on; 192.168.1.100; "/lts/vmlinuz-2.4.18-ltsp-1"; "/lts/vmlinuz-2.4.19-ltsp-1";
00:10:5A:D7:34:9C; 192.168.1.101;
00:10:5A:D7:34:8E; 192.168.1.102;
00:50:04:BF:F6:15; 192.168.1.103;
00:10:5A:D7:34:22; 192.168.1.104;
87
hardware ethernet fixed-address
00:10:5A:D7:33:EE; 192.168.1.105;
} host ws006 { hardware ethernet 00:10:5A:D7:34:3B; fixed-address 192.168.1.106; } host ws007 { hardware ethernet 00:10:5A:D7:34:67; fixed-address 192.168.1.107; } host ws008 { hardware ethernet 00:10:5A:D7:34:96; fixed-address 192.168.1.108; } # stanice ucitelska V1 - 386 - pouze terminal host ws009 { hardware ethernet 00:60:97:77:06:FC; fixed-address 192.168.1.109; filename "/lts/vmlinuz-386"; option option-128 e4:45:74:68:00:00; option option-129 "NIC=3c509"; } # stanice 486 host ws010{ hardware ethernet 00:60:97:75:CE:50; fixed-address 192.168.1.110; option option-128 e4:45:74:68:00:00; option option-129 "NIC=3c509"; } ########### ucebna V2 ########### host ws011 { hardware ethernet 00:01:02:23:B2:27; fixed-address 192.168.1.111; } host ws012 { hardware ethernet 00:01:02:23:b2:54; fixed-address 192.168.1.112; } host ws013 { hardware ethernet 00:50:DA:d8:52:ce; fixed-address 192.168.1.113; } host ws014 { hardware ethernet 00:50:DA:CC:59:AB; fixed-address 192.168.1.114; } host ws015 { hardware ethernet 00:50:DA:d8:52:6e; fixed-address 192.168.1.115; } host ws016 { hardware ethernet 00:50:DA:d8:53:35; fixed-address 192.168.1.116; } host ws017 {
88
#This is NOT a MAC address
#This is NOT a MAC address
hardware ethernet fixed-address
00:50:DA:d8:52:65; 192.168.1.117;
} host ws018 { hardware ethernet 00:01:02:23:ac:69; fixed-address 192.168.1.118; } # <<<<<<<<<<<<<< stanice mimo ucebny >>>>>>>>>>>>>>>>>>> # IP > 192.168.1.120 # # muj testovaci host tucnak { hardware ethernet 00:50:fc:65:c0:e0; fixed-address 192.168.1.121; } }
8.4
FTP server
Protokol FTP - (File Transfer Protocol) se na Internetu používá zhruba od r. 1971. Od té doby zaznamenal jen velmi málo změn. Jedna ze známých implementací FTP serveru je Washington University FTP srver wu-ftpd. Velká část komerčních serverů používá wu-ftpd místo standardního FTP serveru, který byl dodán s jejich systémem.
8.4.1
Spolupráce serveru s klientem
Když se chce FTP klient připojit k serveru: • náhodně zvolí dostatečně vysoké číslo zdrojového portu (vyšší než 1024) • jako cílový port na serveru zvolí port 21 (standard FTP) • po navázání spojení může klient serveru posílat příkazy Když klient zašle požadavek na přenos souboru: • server vybere náhodné číslo portu, a zašle je klientovi • klient na tomto portu kontaktuje server a vytvoří se nové spojení • původní spojení zůstává otevřeno pro přenos doplňujících informací (požadvak na přerušení přenosu) Tato architektura je v dnešní době nevhodná z důvodů zabezpečení sítí firewally.Firewally považují příchozí spojení va vysokých portech za nabezpečná a nepovolují je. Toto chování má za následek znemožnění přenosu dat pomocí FTP. Klient se serverem se spojí, ale při požadavku na přenos souboru „zamrzneÿ. Řešení nabízí pasivní přenos - je založené na tom, že spojení pro přenos dat neiniciuje server, ale klient. Software je možné získat na adrese http://www.wu-ftpd.org
8.4.2
Konfigurace wu-ftpd
Konfigurační soubor /etc/ftpaccess obsahuje typy příkazů: • řízení přístupu • automaticky vypisované informace pro uživatele • vytváření protokolů • různé příkazy pro server • řízení práv Příkazy pro řízení přístupu určují, kdo se může k serveru připojit a kdo ne. 89
8.4.3
Příklady konfigurace
90
Kapitola 9
Bezpečnost sítí s IP
91
