Počítačové sítě

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