PKO-vypisky ke zkousce

PKO – výpisky ke zkoušce
Úvodem:
Podívat se na Xfort, jsou tam nějaké odkazy na to z čeho se učit:
http://www.exfort.org/forumbb/viewtopic.php?t=1551
Přednáška 1 – úvod
Historie síťových technologií:
1. nejdříve se přenášela data na médiích (štítky, pásky, diskety...)
2. potom se “vynalezly” sériové a paralelní porty (dvoubodové spoje – viz PZA)
3. poté nastoupily terminálové sítě (zapojení do hvězdy)
4. dále... distribuovaný model (lokální sítě - LAN)
5. propojení pracovišť ( sítě WAN )
6. mobilní technologie (WIFI,GSM)
7. specializované sítě (SAN – viz poslední přednáška nebo PZA)
Historie v datech: 1957 – vznika ARPA (Advanced Research Projects Agency), 1960 –
AT&T vyvinul dataphone, 1965 – první WAN z Massachussets do kalifornie, 1969 – síť
ARPANET (4 uzly), 1970 – NCP, 1972 – věrejná demonstrace ARPANET, 1972 – email,
1973 – ethernet, 1975 – telnet, 1990 – www, 1991 – www server a browser, 1993 – mosaic
Taxonomie (rozdělení) sítí
• podle použití – na informační systémy nebo průmyslové aplikace
• podele rozlehlosti – na LAN (local), MAN(metropolitan) nebo WAN(wide)
• podle rychlosti – prostě tak nějak na rychlé a pomalé
• podle topologie – sběrnice (viz PZA (nebo slide 9/1) – propojení více počítačů s
jednou sběrnicí), hvězda/strom (slide 10), kruh (slide 11), bezdrátové spoje (slide 12)
Vrstvená architektura – co to je? - je to vlastně taková obdoba komunikace přes
tlumočníky, proč se to zavedlo? – kvůli zjednodušení návrhu, dekompozici problému a také
snadné možnosti výměny modulů
Funkce vrstev – komunikace probíhá mezi vrstvami na stejné úrovni, vrstvy poskytují služby
vyšším vrstvám a využívají služeb nižších vrstev, komunikace mezi stejnými vrstvami je
transparentní vůči nižším vrstvám, vrstvy interagují pouze se sousedními vrstvami (tj.
vrstvami o 1 vyšší nebo o 1 nižší), komunikace mezi vrstvami je na slidu 15...
Pouzdření vrstev – prostě to zabalování probíhá tak, že nejvyšší vrstva poskytne nějaká data,
ta se zabalí do dat nižší vrstvy atd... atd...
ISO OSI referenční model:
1. Fyzická vrstva (physical layer) – poskytuje toto: umožňuje přenos bitů kanálem,
definuje signály pro „0“ a „1“, předepisuje vlastnosti média, definuje elektrické a
mechanické vlastnosti rozhraní. Na fyzické vrstvě je vytvořen tzv. fyzický okruh. Na
fyzický okruh mezi 2 počítače bývají často vkládána další zařízení jako modemy atd.
Příklad: Ethernet 10BaseT, RS232 (sériový port - COM)
2. Spojová vrstva (link layer) – Poskytuje v případě sériových linek výměnu dat mezi
sousedními počítači a v případě lokální sítě výměnu dat na této síti. Základní
jednotkou přenosu je rámec, který se skládá se záhlaví, dat a zápatí. Poskytuje funkci
spolehlivého spojení (detekce a korekce chyb), formátování dat do rámců,
rozpoznávání rámců, řízení toku na lince, jednoznačnou adresu v rámci segmentu
(link adresu – že by to byla MAC?). Na síťové vrstvě může být pro každý konec
spojení použit jiný protokol... viz obrázek
Příklad: PPP,LLC 802.2
3. Síťová vrstva (network layer) – poskytuje adresaci a směrování dat přes mezilehlé
prvky, jednoznačnou adresu v rámci sítě (síťovou adresu – že by i.p. adresa?), síťovou
službu se spojením i bez něj. Základní jednotkou přenosu je síťový paket. který se
skládá ze záhlaví a dat ...Jinak se zápatím se u síťových protokolů setkáváme jen
zřídka. Směrovač operuje s paketem tak, že ho vybalí z ethernetového rámce a před
odeslání do jiné linky jej opět zabalí...viz obrázek
Příklady: X.25, IP
4. Transportní (transport layer) – Síťová vrstva zabezpečí spojení mezi vzdálenými
počítači, tak se transportní vrstvě jeví, jakoby tam žádne modemy nebo opakovače ani
nebyly. Mezi dvěma počítači může být několik spojení na transportní vrstvě současně
(jedno třeba pro mail a jedno pro ssh). Transportní vrstva poskytuje rozklad dat na
pakety (pozor, data v paketech mohou být různé délky – viz obr.
uspořádání dat podle pořadí, multiplexuje a demultiplexuje data mezi transportními
spoji, poskytuje transportní adresy (adresa, port) a koncové řízení toku. Příklady:
UDP,TCP
5. Relační (session layer) – poskytuje vytváření logického rozhraní pro aplikace,
synchronizaci spojení (transakce), stará se o relace. DObře představitelnou relací je
např. sdílení síťového disku. Tato relace existuje po celou dobu, ovšem spojení na
transportní vrstvě se navazuje jen tehdy, když je třeba s diskem pracovat. Základní
jednotkou přenosu relační vrstvy je relační paket. Příklady: RPC, sdílení disků
6. Prezentační (presentation layer) – poskytuje sjednocení prezentace informace,
dohodu o syntaxi, transformaci dat, šifrování, kompresi. Příklady: kódování
ASCII/EBCDIC, XDR, ASN.1
7. Aplikační (application layer) – poskytuje podpůrné funkce aplikacím ASE
(Application Service Element):
• SASE – specifická podpora, přenos souborů, pošta, terminály
• CASE – univerzální podpora – vytváření aplikačního spojení, obsluha transakcí
Také předepisuje v jakém formátu a jak mají být dat přebírána od aplikačních
programů.
Příklady: knihovny pro tvorbu síťových aplikací
Pouzdření do ISO OSI – prostě jako jakékoli pouzdření to jde od nejsvrchější vrstvy k
nejnižší - vždy se přidávají hlavičky a v síťové vrstvě se přidá navíc zakončení – fyzická
vrstva to už jen přetransformuje na bity ... viz slide 25
Komunikace mezi vrstvami – routery pracují na síťové vrstvě (potřebují znát totiž i.p.
adresu), HUBy na fyzické vrstvě (jen překopírují data, k tomu není potřeba žádná adresa),
SWITCHe na spojové(linkové) vrstvě (potřebují znát MAC adresu, aby věděly, kam to mají v
LANce poslat)
Přednáška 2 – protokolová rodina TCP/IP
Všimněte si: TCP/IP není jeden protokol, ale rodina protokolů – a navíc pod souslovím
„rodina protokolů“ se skrývá síťový model – tzn. něco jako OSI (viz obrázek), tento model
(TCP/IP) používá internet. Jak vidíme, TCP/IP májen 4 vrstvy, podobné OSI jsou jen síťová a
transportní.
Rodina síťových protokolů TCP/IP neřeší (až na výjimky, jako je protokol SLIP) linkovou a
fyzickou vrstvu,proto se i v Internetu setkáváme s linkovými a fyzickými protokoly z modelu
ISO OSI.
Historie: 1974 – první zmínka o TCP, 1978 – oficiální uvedení TCP/IP, 1983 – ARPANET
adoptuje TCP/IP, 1991 – začátek prací na TCP/IP verze 6, 1995 – první RFC(co ta zkratka
znamená viz dále) dokumenty k TCP/IP v 6
RFC – Request for Comments – je to množina technických a organizačních dokumentů
TCP/IP protokoly: DNS, SNMP, FTP, SMTP, OSPF, UDP, TCP, RARP, ARP, IP, ICMP, ...
viz slide 4
Jak probíhá adresace? adresy jsou hierarchicky vrstvené, máme různé třídy adres nebo také
beztřídní adresy, dělíme adresy na subnet a supernet, probíhají tam převody mezi IP a
linkovými adresami, existují speciální adresy, máme i privátní sítě a nečíslované sítě... uf ...
slide 5
Třídy adres:
A. 0... .... (místo teček doplň jedničky či nuly) prostě první osmice bitů může být od 0 do
127 (neboli 0000 0000 až 0111 1111). Adresu sítě určuje první bajt, zbytek je určen
pro adresu v rámci sítě
B. 10.. .... (místo teček doplň cokoli) první osmice bitů může být od 128 do 191 (1000
0000 až 1011 1111) . Adresu sítě určují první dva bajyt, zbytek je určen pro adresu v
rámci sítě
C. 110. ....(místo teček doplň cokoli) první osmice bitů je od 192 do 223 (1100 0000 až
1101 1111). Adresu sítě určují první tři bajty, zbytek je určen pro adresu v rámci sítě
D. 1110 ....(místo teček doplň cokoli) první osmice bitů je od 224 do 239 (1110 0000 až
1110 1111). Adresa se již nedělí na adresu sítě a adresu počítače. Zbytek adresy tvoří
adresný oběžník (multicast)
E. 1111 ....(místo teček doplň cokoli) první osmice bitů je větší než 239 (1111 0000 až
1111 1111). Třída E je víceméně rezervou pro adresy
Maska sítě ... viz slidy – na slidu 7 je ukázané jak funguje maska podsítě, pokud je v masce
číslo za lomítkem, pak toto číslo udává počet jedniček zleva masky.
Speciální adresy:
• 0.0.0.0 - tento počítač na této síti
• 00..0.počítač – počítač na této síti
• síť.00..0 – adresa sítě jako takové
• síť.subsíť.00..0 adresa subsítě
• síť.11..1 – broadcast do sítě (do všech subsítí dané sítě)
• síť.subsíť.11..1 – broadcast do subsítě
• 11..1 – broadcast na lokální síti
• 127.xx – loopback (127.0.0.1)
Takže pokud máme např. síť 192.168.6.0 a dáme PING 192.168.6.255, pak nám odpoví
všechny počítače na této síti (ale implementace PING od Microsoftu je všechny nezobrazí,
ostatní ano).
Subsíť – počet jedniček v jejich síťové masce je větší než u standartní síťové masky síťe
Supersíť - počet jedniček v jejich síťové masce je menší než u standartní síťové masky síťe
Privátní sítě – Takto se označují sítě Intranetu – prostě dejmetomu LAN sítě firem nebo
uživatelů.Tyto sitě mají vyhrazené adresy (pro počítače uvnitř sítě – schované za NATem ),
které se nesmí vyskytovat v internetu, probíhá tam filtrování, překlad adres, třídy privátních
sítí:
A. 10.0.0.0 – 10.255.255.255
B. 172.16.0.0 – 172.31.255.255
C. 192.168.0.0 – 192.168.255.255
Nečíslované sítě (pokud by to někoho zajímalo – ve slidech to nejni) jsou to linky mezi
směrovači – prostě tyto linky se neberou jako nějaká síť, bere se to tak, že dva spojené
směrovače tvoří jeden virtuální směrovač.
Komunikace po síti – viz slidy 12-32
• slidy 12-18- komunikace po LAN – každý počítač má svou IP a MAC – to je ten třetí
řádek, pokud chce 192.168.1.1 komunikovat s 192.168.1.10 musí zadat do rámce svou
MACadresu a ip adresu cíle a dále svoji ip adresu (to aby příjemce věděl, kam má data
vrátit) a nakonec samozřejmě data co posílá. Nejprve se porovnají adresy
vyANDované (log, operace AND) s maskou podsítě a zjistí se, že oba kompy jsou ze
stejné sítě. Poté se zjistí MAC adresa cíle a to tak, že odesílatel pošle dotaz do sítě na
ip adresu příjemce (slide 16), příjemce mu v odpovědi zašle svou MAC. Tím je rámec
kompletní a může proběhnout komunikace
• slidy 19 – 32 – komunikace přes routery – jak každý počítač, tak každý router má
svoji IP a MAC adresu, routery navíc mají více IP a MAC adres, protože mají více
síťových rozhraní. Na slidech chce počítač 192.168.1.1 komunikovat se 147.32.83.10,
zadá tedy do rámce opět svou MAC, svoji ip a cílovou ip a data, porovnají se adresy
vyANDované s maskou a zjistí se že zdroj a cíl nejsou ve stejné síti (slide 21), takže se
bude posílat přes výchozí bránu (adresa 192.168.1.254). Tak, teď se přes tu bránu opět
pošle dotaz na MAC adresu brány (slide 23), příjde odpověď s MAC brány (slide 24),
takže rámec pošleme na bránu (slide 25), dobře, ale teď stále nevíme MAC cíle,
známe jen jeho IP. Opět zjistíme, že cíl není v téhle síti,no tak zase pošleme dotaz
(!!pozor, v téhle chvíli se nám změnila MAC zdroje na MAC routeru, IP zdroje
zůstává!!), tentokrát na druhý router.Ten router nám vrátí svoji MAC aresu, takže
pošleme data na něj (nezapomeň, že IP adresa zdroje zůstává stále stejná, aby se
vědělo, kam se mají data vrátit) atd. atd... konec pohádky
Překlad adres (NAT) – probíhá při komunikaci z vnitřní do vnější sítě a naopak, je to překlad
zdrojové a (nebo) cílové adresy, zdrojového a (nebo) cílového portu. Překlad může být buď
statický nebo dynamický. NAT se označuje také jako Maškaráda(Masquerade). NAT je
vysvětlený na slidu 33 – všimni si, že při „přechodu dat“ přes první router se změnila cílová
IP na adresu tohoto routeru (bez NATu by tam byla IP adresa cílového počítače)
Konfigurace počítačů:
• Nastavení IP adresy a síťové masky prvního kompa – ifconfig eth0 192.168.1.1
netmask 255.255.255.0 (slide 35)
• Nastavení defaultní brány pro kompy v podsíti – route add default gw 192.168.1.254
(slide 36)
• Nastavení směrovacích tabulek routeru 1 – je to na slidu 37, sloupce směrovací
tabulky jsou cíl v síti, maska, brána, tzn. pokud chceme poslat data na nějakou adresu
(mimochodem síť 0.0.0.0 s adresou 0.0.0.0 znamená všechny adresy), tak ta se
porovná s cílem v síti a její maskou a poud to sedí, tak se data pošlou na bránu, co je u
toho nastavená (0.0.0.0 znamená asi defaultní brána)
• Nastavení NATu – iptables -t nat –A POSTROUTING -o eth2 –j MASQUERADE
Pomocné protokoly: ICMP (Internet Control Message Protocol), IGMP(Internet Group
Management Protocol), ARP(Address Resolution Protocol), RARP(Reverse Address
Resolution Protocol), BOOTP(Bootstrap Protocol),DHCP(Dynamic Host Configuration
Protocol), RIP (Routing Information Protocol), OSPF (Open Shortest Path First Routing
Protocol), EGP (Exterior Gateway Protocol), BGP (Border Gateway Protocol)...
Přednáška 3 – protokoly linkové vrstvy
Použití linkové vrstvy – přenos dat mezi přímo propojenými systémy, dělení proudu bitů na
jednotku informace, kontrola integrity dat, adresace v rámci segmentu, zapouzdření dat vyšší
vrstvy. Na této vrstvě pracují bitově a znakově orientované protokoly.
Protokol SLIP
Serial Line Internet Protocol – vznikl na počátku 80.let, j popsán v rfc1055. Vkládá pakety
přímo do sériové linky a pro řízení linky vkládá mezi data tzv. ESCape sekvence. Každý
rámec protokolu SLIP je zakončen esc. sekvencí END (c016), většina implementací protokolu
SLIP však END umisťuje i na začátek rámce. Jestliže se znak c016 (END) vyskytne i v
přenášených datech, pak je nahrazen dvojicí znaků db16, dc16 viz obrázek...
Protokol SLIP definuje pouze zapouzdření paketů na sériové lince (vzpomeň jsi jak jsme přes
sériák hráli kdysi Duka).Nedefinuje adresaci, typ paketů,detekci chyb, kompresi ani informace
ke konfiguraci.
další info na http://en.wikipedia.org/wiki/Serial_Line_Internet_Protocol nebo na
http://sunsite.nus.edu.sg/pub/slip-ppp/whatis.html nebo na str. 75 v bibli
Protokol CSLIP
Compressed SLIP, neboli varianta protokolu slip používající kompresi, redukuje záhlaví TCP
(20b) a IP(taky 20b) (ze 40B na 3 až 16B). Komprimuje se jen záhlaví, nikoliv data.
Myšlenka komprese spočívá v tom, že autor se zamyslel nad IP a TCP záhlavím a zjistil, že
mnohé údaje v těchto záhlavích se během TCP spojení nemění nebo se mění jen málo, takže
stačí přenášet jen změněné položky IP a TCP záhlaví nebo dokonce jen přírůstky těchto
položek. Obrázek TCP a IP záhlaví je zde:
Přenáší se tyto změny položek záhlaví: identifikace IP datagramu, SeqN (pořadové číslo
odesílaného bajtu), AckN (pořadové číslo přijatého bytu), příznaky, délka okna, kontrolní
součet TCP, ukazatel urgentních dat. Ignorují se tyto změny položek záhlaví: délka IP,
kontrolní součet IP.
Komprese záhlaví komprimuje záhlaví pouze v případě, že se jedná o TCP protokol a v
záhlavích se mění pouze uvedené položky. V opačném případě (např. je odeslán ICMP paket,
je odeslán UDP datagram, jedná-li se o fragment IP-datagramu, je-li nastaven některý z
příznaků RST, SYN, FIN nebo naopak nenastaven příznak ACK atp.) se komprese neprovede
a linkou je přenesen nekomprimovaný (nezměněný) rámec. Taktéž se nekomprimuje, pokud
se změní jiné položky hlavičky. Kopresi provádí komponenta zvaná kompresor – ta studuje
pakety a v případě, že je paket komprimovatelný (jedná se o paket se záhlavím TCP + IP),
zkomprimuje ho. v opačném případě ho propustí dále.
Komprimované záhlaví obsahuje v prvním bajtu tzv. masku. Jednotlivé bity masky
specifikují, které položky v záhlaví originálního paketu se změnily, a proto celé položky nebo
jejich přírůstky musí být přenášeny i v komprimovaném záhlaví. Je-li příznak nastaven, pak v
komprimovaném záhlaví je uvedena konkrétní položka komprimovaného záhlaví, pokud není
nastaven, pak příslušná položka není v komprimovaném záhlaví přítomna. Pro další
informace, co který bit masky znamená se mrkni do bible na str. 78.
Obrázek CSLIP je na slidu 5/3 a komprimované záhlaví je na slidu 6. Více o CSLIP na
http://www.ics.muni.cz/zpravodaj/articles/16.html
Protokol HDLC
High Level Data Link Control. Tento protokol provádí detekci chyb a řízení toku dat. Je to
protokol podporující synchronní i asynchronní přenos (viz PZA), má velmi rozsáhlou normu,
která je výrobci jen částečně implementovaná a mnohdy si výrobci dělají části protokolu
podle sebe a tak se mezi různými výrobci u HDLC může projevit nekompatibilita (CISCO
HDLC, DEC HDLC).
Protokol HDLC má tři přenosové režimy:
•
ABM (Asynchronous Balanced Mode) – používá se pro komunikaci mezi 2 stanicemi.
Je full duplex tj. obě stanice mohou vysílat současně, aniž by si vzájemně na lince
překážely. Většinou se dnes setkáváme právě s tímto módem. obrázek dole...
•
NRM (Normal Response Mode) – více stanic, half duplex. Pro vysílání i příjem slouží
společné přenosové médium, tj. v jednom okamžiku lze buK přijímat, nebo vysílat.
Jedna stanice je označena jako řídící stanice a ostatní jako podřízené stanice. Je
definován tzv. pooling, tj. řízení, kdy která stanice smí vysílat. Bez povolení smí
vysílat pouze řídící stanice. Ostatní stanice mohou vysílat jen tehdy, když jim to řídící
stanice povolí. Tento mód je v internetu používán jen výjimečně.
•
ARM(Asynchronous Response Mode) – obdoba NRM, ale stanice může vysílat bez
vyzvání. Tento mód se moc nepoužívá.
Formát HDLC rámce – slide 8/3 – rámec začíná a končí tzv. křídlovou značkou (pokud jsou
dvě křídlové značky po sobě, jedná se o prázdný rámec), křídlová značka je 0111 1110,
pokud by bylo náhodou šest jedniček v datech, pak se použije bit stuffing, tzn. pokud máme
po sobě 5 jedniček, vložime za ně 0, dále je v rámci adresa, kontrolní součet, data, řídící pole
– to dělí rámce na 3 skupiny:
• U-rámce – slouží k přenosu dat, ale i pro některé řídící funkce (úvodní inicializační
dialog, řzení linky, diagnostiku).Jsou nečíslované(unnumbered)
• I-rámce – slouží k přenosu dat, ale mohou ve svém řídícím poli přenášet i některé
řídící informace (např pozitivní potvrzení přijatých rámců)
• S-rámce se používají k řízení toku dat (požadavek na vyslání a potvrzování rámců) . S
rámce zpravidla neobsahují datové pole.
Velikost řídícího pole je různá, v závislosti na režimu přenosu, potvrzování může být
střídavé, okénkové, pozitivní, negativní... formát HDLC rámce je zde na obrázku:
HDLC dialogy – slide 10 – význam zkratek:
•
•
•
SABM (Set Asynchronous Balanced Mode) – příkaz nastavuje linku do
módu ABM
UA (Unnumbered Acknowledgement) - potvrzování řídících příkazů v U
rámcich.Sekvenení čísla nepotřebná, protože v jedne chvíli může být
vyslán jen jeden (nepotvrzený) příkaz
DISC (Disconnect) - informace o vypínáni stanice
•
•
FRMR (Frame Reject) - indikuje, ze přišel rámec s nesprávnou
sémantikou.
DM (Disconnect Mode) - vyjadřuje pozitivní potvrzení příkazu DISC
Více o HDLC na: http://www.elektrorevue.cz/clanky/01026/index.html a bible str. 79
Protokol PPP
Point to Point Protocol. Je to podmnožina HDLC protokolu a proto využívá rámce tvaru
protokolu HDLC. Nevyužívá však zdaleka všechny možnosti protokolu HDLC. Dokáže
používa jak asynchronní, tak i bitově a znakově synchronní přenos dat, pro asynchronní
přenos použije 1 start bit, 8 datových bitů a 1 stop bit. Vyžaduje plně duplexní dvoubodové
spoje (Point to Point).
Cílem protokolu PPP je umožnit po jedné lince přenos více síťových protokolů současně
(mixovat protokoly). Nepoužívá I-rámce, ale přenos provádí pouze pomocí U-rámců. Nemůže
tedy použít číslování rámců, a tedy ani možnost opakování rámce v případě zjištění chybného
rámce. Na počátku datového pole umísťuje osmi nebo šestnáctibitovou identifikaci
přenášeného síťového protokolu (takhle umožní mix těch protokolů).
Formát rámce PPP – je tam křídlová značka (opět použit bit stuffing), adresa, řídící pole,
identifikátor protokolu (zde je identifikován protokol, pomocí něhož se přenáší data, datové
protokoly začínají na 0, NCP začíná na 8), data ,kontrolní součet a křídlová značka... viz obr.
Součástí protokolu PPP jsou dva služební protokoly: Protokol LCP sloužící k navázání
spojení, autentizaci stanic apod. Dále skupina protokolů NCP. Důležité je množné číslo.
Každý síťový protokol, který bude využívat linkový protokol PPP má definovánu vlastní
normu pro protokol NCP. Součástí této normy je vždy i číslo protokolu, které se použije v
poli protokol rámce, a to jak pro příslušný protokol NCP (číslo začíná číslicí 8), tak i pro
datové rámce (číslo začíná číslicí 0).
Více o PPP na...http://www.elektrorevue.cz/clanky/01026/index.html
Protokol LCP
Link Control Protocol – používá se ještě před tím, než se vůbec uvažuje o tom, jaký sí+ový
protokol na lince poběží.LCP je společný protokol (na rozdíl od protokolů NCP) pro všechny
sí+ové protokoly. Protokol LCP je určen pro navázání spojení, ukončení spojení, výměnu
autentizačních informací apod. Linka se nachází postupně ve fázi navazování spojení,
autentizace, síťový protokol a ukončování spojení, jak je znázorněno na obr. Linka začíná
vždy ve stavu odpojena.
Autentizace je fáze, kdy klient prokazuje svou totožnost. Slovo klient jsem použil záměrně.
Asi jste si položili otázku, kdo je to klient? Klientem je ta strana (stanice), která je vyzvána k
prokázání své totožnosti. Po prokázání totožnosti jedné stanice si mohou stanice svou roli
vyměnit a k prokázání své totožnosti může být vyzvána druhá strana. V praxi většinou
prokazuje svou totožnost jen jedna strana Autentizace probíhá přes nějaký PAP – Password
Authentiction Protokol)
Fáze síťový protokol v sobě může obsahovat celou řadu kroků.V tomto okamžiku přicházejí
ke slovu jednotlivé protokoly NCP. Každý síťový protokol, který chce linku využívat si musí
přivést pomocí svého protokolu NCP linku do otevřeného stavu pro tento protokol.Pokud se
objeví datové pakety síťového protokolu, pro který není linka otevřena, pak se tyto pakety
zahodí.
Formát LCP rámce je na obrázku – obsahuje kód (ten specifikuje typ příkazu protokolu LCP
, příkazy mohou být např.Conf-Req/Ack/Nack/Rej...), ID (identifikace požadavku Odesílatel
zvolí identifikaci do tohoto pole a adresát ji zkopíruje do své odpovědi. Pomocí tohoto pole se
určuje příslušnost odpovědi k danému požadavku.), délku (součet velikosti polí kód,ID,délka
a volby) a volby (požadavky/odpovědi na změnu parametrů linky)
Více o LCP například zde: http://www.networksorcery.com/enp/protocol/LCP.htm
Protokoly NCP
Network Control Protocols – jsou to IPCP, IPV6CP, SNACP, DNCP a IPXCP a další.
Protokol IPCP
Internet Protocol Control Protocol – je to protokol NCP pro protokol IP verze 4. Má ID =
8021, struktura rámce je na obrázku...
Takže kód příkazu , volby (jsou podobné LCP) Pokud dáme jako protokol v rámci PPP číslo
0021, bude nám to posílat nekomprimované pakety, pokud tam dáme 002d, posílá je
komprimované...slide 16/3
Protokol Ethernet
Předmluva
Instituce IEEE před dvaceti lety předložila projekt, jehož cílem bylo vypracovat normy pro
jednotlivé typy LAN (např. Ethernet, Arcnet, Token Ring atd.). Tyto normy popisovaly pro
každý typ LAN vrstvu MAC. Vznikla tak norma IEEE 802.3 pro Ethernet, IEEE 802.4 pro
Token Bus, IEEE 802.5 pro Token Ring atd. Pro všechny systémy pak byla vypracována
společná norma pro vrstvu LLC pod označením IEEE 802.2, což schématicky vyjadřuje
obrázek.
Problematika linkové vrstvy pro LAN tak byla rozdělena do dvou podvrstev. Spodní vrstva
Medium Access Control (MAC) částečně zasahující do fyzické vrstvy se zabývá přístupem na
přenosové médium. Horní vrstva Logical Link Control (LLC) umožňuje navazovat, spravovat
a ukončovat logická spojení mezi jednotlivými stanicemi LAN.
Nyní již o protokolu Ethernet – mnohem více o něm je v bibli na straně 112
Protokol Ethernet byl původně vyvinut firmami DEC, Intel a Xerox. Jeho varianta 10 MHz se
označuje jako Ethernet II. Později byl Ethernet normalizován institutem IEEE jako norma
802.3. Tato norma byla převzata ISO a publikována jako ISO 8802-3. Formát rámců podle
normy Ethernet II se mírně odlišuje od formátu ISO 8802-3. Postupem času vznikla norma
IEEE 802.3u pro Ethernet na frekvenci 100 MHz (Fast Ethernet) a norma IEEE 802.3z pro
frekvenci 1 GHz (gigabitový Ethernet). Struktura rámce protokolu Ethernet závisí na použité
normě. Probereme si více možných typů...
Formát rámce Ethernet II (DIX) – viz obrázek...
je tam nějaká preambule – při ní se synchronizují všechny stanice přijímající rámec, dále
DA(destination address)-adresa cíle, SA(source address) – adresa zdroje, adresy mají 24b –
jsou to adresy přidělené zařízení výrobcem, prostě adresy MAC (viz
http://en.wikipedia.org/wiki/MAC_address), dále je tam typ (ID) přenášeného protokolu, kde
0800 znamená IP, 0806 ARP, 8035 = RARP, 86DD = IPV6, 88A2 = ATA over ethernet, dále
jsou tam data (musí být minimálně 46 B dlouhé, pokud tomu tak není, vyplní se zbytek
bezvýznamnou výplní) a nakonec CRC
IEEE 802.3 – je to taktéž norma pro Ethernet – tako vá konkurence pro protokol Ethernet II
Zabývá se vrstvou MAC. Formát rámce je na obrázku...
Formát rámce je stejný jako u Ethernet II až na to že místo typu protokolu máme pole délka
označující délku přenášených dat. Dalším rozdílem je, že datové pole může v sobě nést
nikoliv jen data, ale paket protokolu 802.2, jehož záhlaví může být ještě rozšířeno o dvě pole
tvořící tzv. SNAP
Formát rámce IEEE 802.2 – viz obrázek
Nyní k popisu polí Destination Service Access Point (DSAP)/Source Service Access point
(SSAP) specifikují aplikaci cílovou/zdrojovou aplikaci, která rámec odesílá/přijímá. Např. pro
IP-protokol se používá DSAP=SSAP=AA16 a pro NetBIOS se používá DSAP=SSAP=F016.
Při použití protokolu ISO 8802-2 je možné doručovat data až jednotlivým aplikacím běžícím
na stanici. Existují i síťové protokoly, které pro komunikaci na LAN používají pouze tuto
adresaci (nepoužívají sí+ovou vrstvu). Použití takových protokolů je sice efektní (o jednu
vrstvu jsou rychlejší), ale jsou nesměrovatelné, tj. jsou určeny pouze pro LAN, nikoliv pro
WAN. Příkladem takovéhoto exotického protokolu je protokol NetBEUI.Řídící pole je
naprosto analogické řídícímu poli protokolu HDLC. Opět mezi stanicemi se může
komunikovat pomocí U, I a S-rámců. Rámce mohou být číslovány, v případě ztráty nebo
chyby v rámci může být vyžádána retransmise atd. Pro potřeby protokolu IP se používají
pouze U-rámce a P/F bit je nastaven na nulu, tj. řídící pole má hodnotu 0316 (obdobně jako v
případě protokolu PPP).
Pomocí záhlaví SNAP (Sub-network Access Protocol) je možné specifikovat protokol vyšší
vrstvy, jedná se tedy o obdobu pole protokol v Ethernetu II. Dokonce pro specifikaci
protokolu vyšší vrstvy se používají stejné hodnoty. Jinými slovy co chybělo protokolu ISO
8802-3 oproti protokolu Ethernet II(pole protokol), se krkolomně řeší pomocí záhlaví SNAP.
Porovnání Ethernet II a SNAP:
(co je SNAP (Subnetwork Access Protocol) se dočtete zde:
http://en.wikipedia.org/wiki/Subnetwork_Access_Protocol )
Teď tedy to porovnání: SNAP přenáší méně dat a podporuje další typy sítí, výsledek přenosu
je u obou stejný, nicméně v internetu je vyžadována podpora Ethernet II
Přednáška 3 – Data Link Layer (diagramy přenosu)
Přečti, pokud chceš: http://www.angelfire.com/ut/cnst/chap05.html
Možnosti potvrzování – jsou 3 možnosti potvrzování – buď pomocí ACK/NACK, nebo
pomocí BCC (block check character – něco jako parita), nebo se vrátí celý rámec s daty.
Positivní potvrzování – pokud rámec dorazí, příjemce pošle potvrzení
Čistě negativní potvrzování – potvrzení příjemce pošle, pokud rámec nedorazí, positivní
potvrzení se neposílají
Negativní potvzování – příjemce posílá jak negativní, tak pozitivní potvrzení
Číslování rámců – prostě zpět v potvrzení se pošle číslo rámce, který se nyní očekává.
Sliding window – posíláme najednou několik rámců a čekáme na potvrzení do určitého
timeoutu
Selektivní odmítnutí (Selective Reject) - pokud jsme už ten který rámec dostali (například
na slidech je to ráemec číslo 1) a příjde k nám podruhé, zašleme odesílateli odmítnutí, ať ho
příště už neposílá
Sliding Window – duplex – prostě rámce odesílají a přijímají obě strany a na konec
odeslaných rámců vždy přiloží potvrzení (tomu se říká piggybacking)
Přednáška 4 –Protokolová rodina TCP/IP – dokončení
Obsah přednášky – protokol síťové vrstvy (IP), podpůrné protokoly
(ICMP,RARP,BOOTP,DHCP), protokoly transportní vrstvy (UDP,TCP)
Protokol IP
Internet Protocol. Jeho úkolem je dopravovat data mezi dvěma libovolnými směrovači v
internetu (tzn. i přes mnohé LAN). IP-protokol je protokol, umožňující spojit jednotlivé
lokální sítě do celosvětového Internetu. Od protokolu IP dostal také Internet své jméno.
Zkratka IP totiž znamená InterNet Protocol. IP-protokol je tvořen několika dílčími protokoly:
• Vlastním protokolem IP
• Službním protokolem ICMP sloužícím zejména k signalizaci mimořádných stavů
• Služebním protokolem IGMP sloužícím pro dopravu adresných oběžníků
• Služebními protokoly ARP a RARP, které jsou často vyčleňovány jako na IP nezávislé
protokoly, protože jejich rámce nejsou předcházeny IP záhlavím
Má podporu fragmentace (co to je zjistíte zde nebo zde), podporu komunikace přes
směrovače, vytváří IP pakety z paketů vyšší vrstvy. IP adresa má velikost 4B. IP protokol
pracuje s koncovými uzly a směrovači a je to základní protokol rodiny TCP/IP.
Fragmentace – umožňuje vložení IP paketu do kratších rámců nižší vrstvy (MTU Ethernet II
je např. jen 1500B – takže si vemte, že máme třeba 64 KB velký IP datagram (64 KB je max
velikost IP datagramu), jak ho Směrovač vloží do rámce, který může mít třeba max 1500B?
Směrovač není schopen takový IP-datagram poslat dále. Směrovač se rozhoduje co dále na
základě příznaku „Fragmentace možná” (DF bit) v záhlaví IP-datagramu. Příznak
„Fragmentace možná” může být buď nastaven nebo ne. Jsou tedy dvě možnosti:
• Fragmentace je možná, pak se fragmentace provede (viz dále)
• Fragmentace není možna – pak směrovač IP datagram zahodí a odesílatele o tom
pomocí ICMP informuje signalizací „Fragmentace zakázána“ (a pokud to směrovač
umí, pošle nám, jaké nejmenší MTU je po cestě)
Pokud je fragmentace povolena, pak pak směrovač dělí delší IP-datagramy na fragmenty,
jejichž celková délka (total length) je menší nebo rovná MTU následující linky ... viz obr
Každý IP-datagram má ve svém záhlaví svou identifikaci, kterou dědí i jeho fragmenty. Díky
identifikaci příjemce pozná, ze kterých fragmentů má datagram složit. Nikdo jiný než
příjemce není oprávněn z fragmentů skládat původní datagram, tj. ani např. směrovač ze
kterého vede linka s takovým MTU, do kterého by se celý datagram již vešel. Důvod je
prostý, Internet negarantuje, že jednotlivé fragmenty půjdou stejnou cestou (ani negarantuje
pořadí v jakém dojdou). Takže směrovač, který by se pokoušel datagram sestavit by mohl být
na závadu spojení, protože fragmentů, které by šly jinou cestou by se nikdy nedočkal. Každý
fragment tvoří samostatný IP-datagram. Při fragmentaci je nutné vytvořit pro každý fragment
nové IP-záhlaví. Některé údaje (jako protokol vyšší vrstvy, či IP-adresa odesílatele a
příjemce) se získají ze záhlaví původního IP-datagramu. Při fragmentaci vstupuje do hry pole
„Posunutí fragmentu od počátku IP-datagramu (fragment offset)”, které vyjadřuje kolik bajtů
datové části původního IP-datagramu bylo vloženo do předchozích fragmentů. Pole „Celková
délka IP-datagramu (total length)” obsahuje délku fragmentu, nikoliv délku původního
datagramu. Aby příjemce poznal jak je původní datagram dlouhý, tak je poslední fragment
opatřen příznakem „Poslední fragment”. Celý mechanismus je znázorněn na obrázku.
Síť nerozlišuje mezi přenosem fragmentu a přenosem celého (nefragmentovaného) IPdatagramu. Nefragmentovaný datagram je fragment s posunutím nula a příznakem „Poslední
fragment”. Proto se často slova IP-datagram a fragment zaměňují. Mechanismus fragmentace
umožňuje i fragmentovat fragment dorazí-li na směrovač jehož odchozí linka má ještě menší
MTU.
Podpora fragmentace je dána příkazy DF(Don’t fragment) a MF(More Fragments), dále
identifikací IP datagramu a také offsetem ve fragmentu
Směrování – existuje buď přímé směrování (směrování na uzly ve stejné síti), nebo nepřímé
směrování (uzly v různých sítích). Implicitní směrování probíhá přes defaultní bránu.
Směrování může být podle směrovacích tabulek rozděleno na statické (informace jsou do
tabulky uloženy ručně při konfiguraci směrovače) a dynamické (směrovací uzly si pravidelně
vyměňují informace a podle toho tvoří sěrovací tabulky – použito u velkých sítí ).
Služby směrovače: podpora předávání paketů (forwarding – viz zde), kontrola a snižování
TTL (Time to live-viz zde), přepínání kontrolního součtu, zohlednění ToS(Terms of Service –
viz zde) podle priority (precedence - pole o 3b), nízkého zpoždění (delay - 1b) a vysoké
propustnosti (throughput – 1p).
Struktura IP datagramu – tvoří ji hlavička(záhlaví) a data.
Hlavička IP datagramu – je v ní:
• verze IP protokolu (4b)
• délka záhlaví – je udávána ne v bytech, ale ve čtyřbytech (32b), typ služby (ToS – 5b
– je to položka, která nenašla v praxi svého naplnění, měla označovat IP datagramy
tak, aby byly některé předávány přednostně a byla tak zaručena rychlá odezva),
• celková délka IP datagramu (omezeno na 64KB)
• identifikace IP datagramu (tato položka je společně s příznaky a posunutím fragmentu
využívána mechanismem fragmentace datagramu)
• příznaky (DF =1 -> nefagmentovat, MF = 0 -> poslední fragment)
• posunutí fragmentu
• TTL (pokud je 0 -> likvidace paketu)
• protokol vyšší vrstvy (1-ICMP,2-IGMP,6-TCP,17-UDP...) - je to číselná identifikace
protokolu vyšší vrstvy, který využívá IP datagram ke svému transportu . V praxi je
•
•
•
použit např. TCP/UDP nebo ICMP, IGMP – tyto dva jsou sice součástí protokolu IP,
ale chovají se jako protokoly vyšší vrstvy, tzn. v přenášeném paketu je záhlaví IP
následováno záhlavím ICMP resp. IGMP .
dále kontrolní součet záhlaví- všimni si – je to pouze kontrolní součet záhlaví nikoliv
z datagramu celého, význam tohoto pole je tedy pochybný – navíc když směrovač
změní nějakou položku záhlaví, amění se i kontrolní součet, což přináší určitou režii
IPadresy příjemce a odesílatele
volitelné položky (max 40B např. může být nastavena položka zaznamenávej
směrovače či zaznamenávej čas, což může být snadno zneužitelné hackery.Dále jsou
tam položky jako explicitní směrování (vyjádřeno, přes které směrovače se má
směrovat), striktní explicitní směrování (vypsány všechny směrovače, přes které se
směruje), upozornění pro směrovač...viz slide 8) viz obrázek...
Protokol ICMP
Internet Control Message Protocol.Protokol ICMP je služební protokol, který je součástí IPprotokolu. Protokol ICMP slouží k signalizaci mimořádných událostí v sítích postavených na
IP-protokolu. Protokol ICMP svoje datové pakety balí do IP-protokolu, tj. pokud budeme
prohlížet přenášené datagramy, pak v nich najdeme za linkovým záhlavím záhlaví IPprotokolu následované záhlavím ICMP paketu. Protokolem ICMP je možné signalizovat
nejrůznější situace, skutečnost je však taková, že konkrétní implementace TCP/IP podporují
vždy jen jistou část těchto signalizací a navíc z bezpečnostních důvodů mohou být na
směrovačích mnohé ICMP signalizace zahazovány.
Formát ICMP Paketu – Záhlaví ICMP-paketu je vždy osm bajtů dlouhé (viz obr. 5.10).
První čtyři bajty jsou vždy stejné a obsah zbylých čtyř závisí na typu ICMP-paketu.
První čtyři bajty záhlaví obsahují vždy typ zprávy, kód zprávy a šestnáctibitový kontrolní
součet. Formát zprávy závisí na hodnotě pole Typ. Pole Typ je hrubým dělení ICMP-paketů.
Pole Kód pak specifikuje konkrétní problém (jemné dělení), který je signalizován ICMP
protokolem...viz obrázek
Typy ICMP paketů – určují se typem a kódem, tady jsou:
typ
kód
popis paketu
0
0
echo odpověď
3
x
nedoručitelny IP datagram – důvod udává kód...viz dále
3
0
nedosažitelná síť
3
1
nedosažitelný uzel
3
2
nedosažitelný protokol
3
3
nedosažitelný UDP port
3
4
fragmentace zakázána
3
5
chyba explicitního směrování
3
6
neznámá síť
3
7
neznámý uzel
3
9
administrativně uzavřená síť
3
10
administrativně uzavřený uzel
3
11
nedosažitelná síť pro službu
3
12
nedosažitelný uzel pro službu
3
4
5
5
5
5
5
8
9
11
11
11
12
12
12
13
14
17
18
13
0
x
0
1
2
3
0
0
x
0
1
x
0
1
0
0
0
0
komunikace administrativně uzavřena filtrací
sniž rychlost odesílání
změň směrování ... pro co určuje kód
pro síť
pro uzel
pro síť pro daný typ služby
pro uzel pro daný typ služby
echo požadavek
odpověď na žádost o směrování
čas vypršel... proč viz kód
TTL
defragmentace
chybný parametr...jaký viz kód
chybné IP záhlaví
schází volitelný parametr
časová synchronizace – požadavek
časová synchronizace - odpověď
žádost o masku
odpověď na žádost o masku
Některé typy zpráv ICMP:
• nástroj Echo - Je jednoduchý nástroj protokolu ICMP, kterým můžeme testovat
dosažitelnost jednotlivých uzlů v Internetu. Žadatel vysílá ICMP-paket „Žádost o
echo“ a cílový uzel je povinen odpovědět ICMP-paketem „Echo“. Používá se např. u
programu PING
• nedoručitelný IP datagram – pokud nemůže být IP datagram doručen adresátovi, pak
je zahozen a odesílatel je o tomto informován přesně touto zprávou
• sniž rychlost odesílání – jestliže je síť mezi odesílatelem a příjemcem přetížena a
směrovač není schopen předávat všechny IP datagramy, pak odesílatele informuje
touto zprávou, ať je odesílá pomaleji.
• změň seměrování – pomocí tohoto ICMP se provádějí dynamické změny ve směrovací
tabulce – například touto zprávou upozorní směrovač (koho, co?) další směrovač nebo
počítač tehdy, pokud má příchozí paket odeslat na tu cestu, ze které paket přišel.
• čas vypršel – například když TTL bylo sníženo na 0 (kód zprávy 1), nebo se
signalizuje, že počítač adresáta není schopen z IP fragmentů sestavit celý IP datagram.
ICMP paket čas vypršel používají ke své činnosti programy TRACERT (WIN) a
TRACEROUTE (Linux)
• ... ... ...
Protokol IGMP
O něm jen krátce, na slidech to není, ale je to dobré vědět... Protokol IGMP je podobně
jako protokol ICMP služebním protokolem (podmnožinou) protokolu IP.Pakety IGMP
protokolu jsou baleny do IP-datagramů. Protokol IGMP slouží k šíření adresných oběžníků
(multicasts) – To znamená, že si do toho paketu IGMP napíšeme explicitně adresy, na které
chceme paket (vyšší vrstvy – např. UDP) poslat a on se nám skutečně pošle na více adres – na
tom principu funguje například VLC na Strahově a dobře to šetří síť. Multicasty jsou ale v
internetu víceméně nepoužitelné, protože nelze zajisti to, že je všechny směrovače po cestě
budou podporovat.
Pokračujeme v povídání o IP ... užitečný protokol, jež IP využívá je protokol ARP
Protokol ARP – Address Resolution Protocol - řeší problém zjištění linkové adresy protější
stanice ze znalosti její IP-adresy. Řešení je jednoduché, do LAN vyšle linkový oběžník
(linková adresa FF:FF:FF:FF:FF:FF) s prosbou: „Já stanice o linkové adrese HW1, IP-adrese
IP1, chci komunikovat se stanicí o IP-adrese IP2, kdo mi pomůže s nalezením linkové adresy
stanice o IP-adrese IP2? Stanice IP2 takovou žádost uslyší a odpoví. V odpovědi uvede svou
linkovou adresu HW2. ARP-paket je balen přímo do Ethernetu, tj. nepředchází mu žádné IPzáhlaví. Protokol ARP je vlastně samostatný, na IP nezávislý protokol. Proto jej mohou
používat i jiné protokoly, které s protokoly TCP/IP nemají nic společného. Jak ARP funguje,
resp. to, co bylo popsáno na předešlých řádcích je na obrázku
IP adresa
Zajímavosti – jedno síťové rozhraní počítače může mít více IP adres. První adresa se pak
obvykle nazývá primární a další adresy pak sekundární nebo aliasy.Využití sekundárních IPadres je běžné např. pro WWW-servery, kdy na jednom počítači běží WWWservery několika
firem a každý se má tvářit jako samostatný WWW-server.
Přidělení IP adresy počítači – může být buď statickéí(IP adresa je trvale přidělena ) nebo
dynamické (IP adresa se přidělí jen na dobu připojení). Pro přidělování adres se používají
protokoly:
• RARP -Reverse Address Resolution Protocol – přidělení adresy bezdiskové stanici,
moc se nepožívá.
•
•
BOOTP - Bootstrap Protocol – využívá protokolu UDP, slouží ke statickému
přidělování parametrů, dokáže přidělit adresu, jméno, masku, směrovače, DNS, time
server, forwarding, MTU (co to je MTU viz zde)...
DHCP – Dynamic Host Configuration Protocol Protokol DHCP vychází ze zkušeností
a částečně v sobě zahrnuje i podporu starších protokolů z této oblasti, tj. protokolů
RARP, RARP a BOOTP. V protokolu DHCP žádá klient DHCP-server o přidělení IPadresy (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 DHCP-server může
být realizován i jako součást směrovače. DHCP se používá k dynamickému
přidělování parametrů narozdíl od BOOTP
Transportní protokoly – slouží k přenosu dat mezi aplikacemi, mají podporu aplikačního
multiplexu (asi že když máme spuštěné 2 stejné aplikace, tak to neva a data se multiplexují)
pomocí portů, podporu řízení toku. K transportním protokolům patří nepotvrzovaný UDP a
potvrzovaný TCP
Protokol UDP
Něco o tomto protokolu... jinak UDP = User Datagram Protocol
Protokol UDP je jednoduchou alternativou protokolu TCP. Protokol UDP je nespojovaná
služba (na rozdíl od protokolu TCP), tj. nenavazuje spojení. Odesílatel odešle UDP datagram
příjemci a už se nestará o to, zdali se datagram náhodou neztratil (o to se musí postarat
aplikační protokol).
Záhlaví UDP -... viz obrázek
Z předchozího obrázku je patrné, že záhlaví UDP protokolu je velice jednoduché. Obsahuje
čísla zdrojového a cílového portu – což je zcela analogické protokolu TCP. Opět je třeba
dodat, že čísla portů protokolu UDP nesouvisí s čísly portů protokolu TCP. Protokol UDP má
svou nezávislou sadu čísel portů. Pole délka dat obsahuje délku UDP datagramu (délku
záhlaví + délku dat). Minimální délka je tedy 8, tj. UDP datagram obsahující pouze záhlaví a
žádná data. Zajímavé je že pole kontrolní součet nemusí být povinně vyplněné. Výpočet
kontrolního součtu je tak v protokolu UDP nepovinný. Pakliže se kontrolní součet počítá, pak se
podobně jako pro protokol TCP počítá ze struktury (pseudozáhlaví)znázorněné na obrázku
Fragmentace - I u UDP datagramů je možná fragmentace v IP-protokolu. Avšak u UDP
protokolu se zásadně snažíme fragmentaci vyhýbat.
Oběžníky - Na první pohled by se zdálo, že protokol UDP je chudým příbuzným protokolu
TCP. Může však existovat něco, co umí protokol UDP a nelze to udělat protokolem TCP?
Právě zvláštností protokolu UDP je skutečnost, že adresátem UDP datagramu nemusí být
pouze jednoznačná IP-adresa, tj. síťové rozhraní konkrétního počítače. Adresátem může být
skupina stanic – adresovat lze i oběžník. Adresovat lze všeobecné oběžníky (broadcast), ale
podstatně zajímavějším případem je adresování adresných oběžníků (multicast). Např. u
aplikací typu RealAudio navazuje každý klient spojení se serverem. Kdežto u
ProgresiveRealAudio se šíří data pomocí adresných oběžníků, tj. dochází k ohromné
úspoře kapacity přenosových cest. A právě to je příležitost pro UDP. Pomocí UDP multicast
pracuje i přenos televize na Strahově
Kecy ze slidů...
User Datagram Protocol, je to nepotvrzovaná služba bez spojení, umožňuje broadcast, pracují
přes něj DNS, Bootp, TFTP, SNMP...
Formát datagramu UDP – slide 16... budu říkat jen to barevné, zbytek je z IP paketu. Takže
hlavička obsahuje volitelné položky hlavičky, zdrojový a cílový port UDP, délku dat a
kontrolní součet (nepovinný, ale aplikace jej mohou vyžadovat, vypočítává se z
pseudohlavičky). Pseudohlavička neobsahuje volitelné položky hlavičky a z toho IP je tam
mnohem méně ... viz slide 17
Protokol TCP
Něco o tomto protokolu – jinak TCP = Transmision Control Protocol
Zatímco protokol IP přepravuje data mezi libovolnými počítači v Internetu, tak protokol TCP
dopravuje data mezi dvěma konkrétními aplikacemi běžícími na těchto počítačích. Protokol
IP adresuje IP-adresou pouze sí;ové rozhraní počítače. Pokud bychom použili přirovnání k
běžnému poštovnímu styku, pak IP-adresa odpovídá adrese domu a port (adresa v protokolu
TCP) pak odpovídá jménu konkrétního obyvatele domu. Protokol TCP je spojovanou službou
(connection oriented), tj. službou která mezi dvěma aplikacemi naváže spojení – vytvoří na
dobu spojení virtuální okruh. Tento okruh je plně duplexní (data se přenášejí současně na sobě
nezávisle oběma směry). Přenášené bajty jsou číslovány. Ztracená nebo poškozená data jsou
znovu vyžádána. Integrita přenášených dat je zabezpečena kontrolním součtem. Konce
spojení (“odesílatel” a „adresát”) jsou určeny tzv. číslem portu. Toto číslo je dvojbajtové,
takže může nabývat hodnot 0 až 65535. Základní jednotkou přenosu v protokolu TCP je TCP
segment. Někdy se také říká TCP paket. Proč segment? Aplikace běžící na jednom počítači
posílá protokolem TCP data aplikaci běžící na jiném počítači. Aplikace potřebuje přenést
např. soubor velký 2 GB. Jelikož 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 TCPzáhlaví. Přenášené 2 GB dat musí být rozděleny na segmenty, které se vkládají do TCP paketu
– přeneseně se pak místo TCP paket říká TCP segment. TCP segment se vkládá do IPdatagramu. IP-datagram se vkládá do linkového rámce. Použije-li se příliš velký TCPsegment, který se celý vloží do velkého IP-datagramu, který je větší než maximální velikost
přenášeného linkového rámce (MTU), pak IP protokol musí provést fragmentaci IPdatagramu
Nyní nějaká fakta ze slidů...
Transmission Control Protocol – je to spolehlivá spojovaná služba, podporuje multiplex i
duplexní přenos (piggybacking), dále také proudový přenos (stream – navážeš spojení, vytvoří
se nějaký tunel a přes to to běží), umožňuje potvrzování a opakování segmentů, adaptivní
přizpůsobení parametrů, má implementované sliding window, umožňuje vytváření a rušení
transportních spojení, příjem dat z vyšší vrstvy a vytváření TCP paketů, koncové řízení toku.
TCP využívají protokoly http, ssh, telnet
Hlavička (záhlaví) TCP – viz obrázek...
Hlavička TCP má tyto pole:
• zdrojový a cílový port TCP- je to port odesílatele a port příjemnce. Pětice zdrojový
port, cílový port, zdrojová IP, cílová IP a protokol (typ protokou) jednoznačně
identifikuje v daném okamžiku spojení v internetu.
• pořadové číslo odesílaného bytu (číslo prvního bytu) – TCP segment je část z toku dat
tekoucích od odesílatele k příjemci. Pořadové číslo odesílaného bytu je pořadové
číslo prvního bajtu TCP segmentu v toku dat od odesílatele k příjemci (TCP segment
nese bajty od pořadového čísla odesílaného bajtu až do délky segmentu)
• , pořadové č. očekávaného bytu(poslední dobře přijatý byte + 1) vyjadřuje číslo
následujícího bytu, který je příjemce připraven přijmout, tj. příjemce tak vlastně
potvrzuje, že úspěšně přijal data do (pořadové_číslo_očekávaného_ bytu - 1)
• délka záhlaví – vyjedřuje délku TCP záhlaví, je v násobcích 32b
• rezerva
• příznaky (URG – TCP segment nese urgentní data, ACK – potvrzení, PSH – TCP
segment nese aplikační data, RST-odmítnutí TCP spojení, SYN – Odesílatel začíná s
novou sekvencí číslování, FIN – odesílatel ukončil odesílání dat)
• délka okna – vyjadřuje maximální přírůstek čísla přijatého bytu, který bude
příjemcem ještě akceptován
• kontrolní součet TCP
• ukazatel naléhavých dat – může být nastaven pouze tehdy, je-li nastaven příznak
URG. Přičte li se tento ukazatel k pořadovému číslu odesílaného bytu, pak ukazuje
na konec úseku naléhavých dat. Odesílatel si přeje, aby příjemce tato data přednostně
zpracoval.
K poli volitelné položky: oproti položkám UDP se používají a přenáší. Volitelná položka se
skládá z typu volitelné položky, délky volitelné položky a hodnoty. Na tyto položky zbývá
40B TCP záhlaví. Mezi volitelné položky patří např.: maximální délka segmentu, zvětšení
okna, časové razítko, čítač spojení.
Navázání TCP spojení - klient začíná navazovat spojení odesláním prvního TCP segmentu. Tento
TCP segment klient vloží do IP-datagramu jehož IP-adresa odesílatele bude „Klient” a IPadresa příjemce „Server”. Klient vygeneruje náhodné číslo v intervalu 0 až 232-1, které
použije jako startovací pořadové číslo odesílaného bajtu (tzv. ISN). V našem případě bylo
vytvořeno ISN=145165778. Skutečnost, že klient právě vytvořil startovací pořadové číslo
odesílaného bajtu vyznačí v TCP segmentu nastavením příznaku SYN (….S.). Během spojení
již pořadové číslo odesílaného bajtu bude vždy vyjadřovat číslo odesílaného bajtu, tj. nemůže
být znovu vygenerováno. Obrázek navazování spojení je tady:
Segment (1) je prvním segmentem v TCP komunikaci, proto nemůže potvrzovat žádná přijatá
data. Pole pořadové číslo přijatého bajtu nemá platný význam (bývá vyplněno binárními
nulami) a nemůže být tedy ani nastaven příznak ACK (příznak ACK je nastaven ve všech
dalších TCP segmentech až do ukončení spojení). Součástí segmentů (1)a (2) byla volitelná
položka záhlaví TCP segmentu MSS (Maximum segment size). Tato položka oznamuje druhé
straně maximální délku datové části TCP segmentu jakou si přeje přijímat (aby se pokud
možno zamezilo fragmentaci IP-datagramu). Implicitně se MSS používá 536 bajtů. Tato
hodnota je používána pro spojení mimo lokální sí; (přes WAN). Pro náš příklad jsme použili
spojení v rámci lokální sítě protokolem Ethernet II. Pro linkový protokol Ethernet II je
maximální délka datové části rámce rovna 1500. Pokud od 1500 odečteme 20 pro IP-záhlaví a
dalších 20 pro TCP záhlaví, pak dojdeme k hodnotě z našeho příkladu (1460).
Takže pokud to shrneme...,tak... stavy při navazování spojení jsou : LISTEN (server je
připraven na spojení s klienty), SYN_SEND (klient odeslal první TCP segment) a
SYN_RCVD (server přijal od klienta první TCP segment, tj. segment s příznakem SYN),
potom je spojení ESTABLISHED, tedy ustanoveno...viz obrázek
Ukončování spojení TCP - Zatímco spojení navazoval v architektuře klient/server zpravidla
klient, tak ukončit spojení může libovolná strana. Strana, která první odešle TCP segment s
příznakem FIN (ukončení spojení) provádí tzv.aktivní ukončení spojení (active close), druhé
straně nezbývá než provést pasivní ukončení spojení (pasive close). Teoreticky je možné i
současné ukončení spojení.
Stavy při ukončování spojení:
• FIN_WAIT1 (strana zjistila, že už všechna data odeslala, a potřebuje např.
signalizovat konec souboru, tak v TCP segmentu nastaví příznak FIN, čímž signalizuje
aktivní ukončení spojení )
• CLOSE_WAIT (druhá strana obdržela aktivní uzavření spojení a nezbývá jí nic jiného
než potvrdit segmentem přechod do pasivního uzavření spojení – tomuto stavu
odpovídá právě CLOSE_WAIT)
• FIN_WAIT2 ( toto je stav poté, co strana obdrží potvrzení aktivního uzavření spojení
od protějšku. Ve stavu FIN_WAIT2 strana zůstává do té doby, dokud protějšek
nezašle TCP segment s příznakem FIN, tj. do přechodu do stavu TIME_WAIT. Pokud
•
•
•
aplikace nepočítá s přenosem dat v polouzavřeném spojení, a spojení je nečinné po
11,25 minuty, pak operační systém automaticky změní stav spojení na CLOSED.)
LAST_ACK – druhá strana již odeslala všechna data a signalizuje úplné končení
spojení
TIME_WAIT - všechna data oběma směry již byla přenesena. Je nutné pouze potvrdit
úplné uzavření spojení. Odesláním TCP segmentu ) je potvrzeno úplné ukončení
spojení. Tento segment již není potvrzován, proto strana zůstává ve stavu
TIME_WAIT po dobu 2 minut (některé implementace TCP/IP zkracují tuto dobu až
na 30 s).
CLOSED – druhá strana obdržela potvrzení úplného uzavření spojení a přechází do
stavu CLOSED. Strana, která odeslala toto potvrzení (segment) přechází do CLOSED
až po uplynutí zmíněného intervalu.
Stavy při uzavírání spojení jsou dobře vidět na obrázku...
Vylepšení provozu TCP – sloučení dat a potvrzení (piggyback), technika okna (viz bible
strana 234), vyhnutí se zahlcení sítě a výpadku segmentu (jak, to je na slidech, ale já to teda
nechápu...), nastavení správného timeoutu
Přednáška 5 –Síťová vrstva –směrování
Předmluva
Směrování provádí zařízení zvané směrovač. Zjednodušeně řečeno směrovač je zařízení, které
předává IP-datagramy z jednoho svého rozhraní do jiného rozhraní. Směrovač umí předat IPdatagram i do téhož rozhraní, ze kterého IP-datagram přišel. Považuje to však ze výstřednost,
takže o tom odesílatele IP-datagramu upozorní ICMP-paketem „redirect”. („změň
směrování“). Směrovači k rozhodování slouží směrovací tabulka. Příklad takovéto tabulky je
na obrázku...
Směrovací tabulka má v prvním sloupci IP-adresu cílové sítě. Představme si pro
jednoduchost, že směrovací tabulka je podle prvního sloupce sestupně tříděna. To nám
umožní snadno aplikovat základní pravidlo směrování: Více specifická adresa cílové sítě má
přednost před méně specifickou. Více specifickou adresou sítě se rozumí adresa, která má v
síťové masce více jedniček. V případě, že by se ve směrovací tabulce našly dvě či více cest k
cíli, pak se zvolí více specifická cesta. V případě, že se najdou dvě stejně specifické cesty, pak
se zvolí cesta s nejnižší metrikou (cenou). V případě, že jsou řádky směrovací tabulky
sestupně tříděny, pak stačí směrovací tabulku procházet odshora dolů. Na každém řádku se
vezme sí;ová maska, kterou se bit po bitu vynásobí IP-adresa příjemce IP-datagramu.
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í následujícího řádku. Pokud se výsledek shoduje s
IPadresou v prvním sloupci, pak se ještě otestuje následující řádek, zdali ve směrovací tabulce
neexistuje ještě k cíli jiná cesta, (pak by vstoupila do hry metrika). 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
pak odesílány všechny IP-datagramy, pro které nevyhovoval žádný jiný řádek směrovací
tabulky (všimněte si, že vyhovuje každé IP-adrese: nula krát nula je nula). Implicitní směr ve
směrovací tabulce může a nemusí být – závisí to na správci, jak tabulku naplnil. Implicitní
směr používají např. firmy pro cestu do Internetu.
Způsoby přenosu dat:
• přepojování kanálů – celý přenosový kanál je vyhrazen pro jednoho uživatele až do
ukončení přenosu
• přepojování zpráv – zpráva se posílá jako celek, nedělí se na pakety
• přepojování paketů - umožňuje sdílení přenosového kanálu více uživateli - ihned po
vyslání paketu se kanál uvolní a může tedy vysílat i jiný uživatel
Způsob doručení:
• virtuální kanál – Je vedený sítí a všechny pakety spojení prochází přes tento kanál. V
případě, že se spojení někde přeruší, je vytvořen nový kanál a poté se mohou opět
přenášet data...viz obr...
Je to jakoby roura, kterou proudí data jedním šměrem, je vytvořena pospojováním
síťových elementů. Kanál má své identifikační číslo a přenášené datové jednotky jsou
do tohoto kanálu vloženy s jeho identifikačním číslem v záhlaví. Projdou pak
pomyslným virtuálním kanálem až k adresátovi. Výhodou tohoto přenosu je to, že
datové jednotky prochází všechny stejnou cestu se stejným zpožděním a ve stejném
pořadí, což u datagramové služby zajistit nelze. IP protokol virtuální kanály
nepoužívá. (více na http://cag.csail.mit.edu/PSRG/papers/dally-ieee92.pdf)
• datagramová služba - je obdoba klasické pošty, tedy datová jednotka je vložena do
přístupového bodu sítě a má kompletní informace pro cestu k adresátovi.
Virtuální kanály – propojovací tabulky – slide 4... v tabulce směrovače je pro každý kanál
jeden řádek, v řádku jsou uvedeny uzly, které kanál propojuje (ty jsou vždy jen 2 – kanál se
totiž nemůže rozdělit) a „vzdálenost“ k těmto uzlům.
Směrovací metody: záplavové směrování, náhodné směrování, izolované směrování (buď
„horký brambor“ nebo „zpětné učení“),statické směrování, adaptivní směrování(buď
„distance vector“ nebo „link state“), hierarchické směrování
• záplavové směrování – viz slide 6 – 11 – každý směrovač vyšle paket do všech směrů
kromě toho směru (resp. „těch“ směrů, paket totiž může přijít ke směrovači i z více
směrů), z nějž paket přišel. Poté co se takto odešle, zjistí se nejkratší cesta
(dijkstrovým algoritmem, protože síť je vlastně graf, že ano), přes niž bude probíhat
směrování. Negativem může být zahlcení sítě při zjišťování cesty, proto je potřeba
nadbytečné pakety likvidovat. To se dá buď pomocí TTL, informace ve směrovači
nebo informace v paketu.
• náhodné směrování – odesílání paketu na náhodný výstup. Toto směrování, ale
nezaručuje omezenou dobu doručení a potřebuje dodatečné informace.
• horký brambor – odesílání paketu do nejkratší fronty (paketů). Stejně jako náhodné
směrování nezaručuje omezenou dobu doručení a potřebuje dodatečné informace.
• zpětné učení – využívá informaci o času/počtu průchodů paketu směrovačem (tato
informace je uložena v paketu). Směrovač má pro tuto metodu tabulku, která
obsahuje odesílatele, nejkratší čas a směr odkud paket přišel. Tuto metodu je nutno
kombinovat s jinou metodou. Při nějaké chybě se metoda pomalu adaptuje.
•
•
•
statické směrování – prostě ručně nastavíme tabulky při návrhu sítě nebo při změně
její topologie. Nereaguje však na změnu topologie, nicméně jej můžeme využít
například při nějakém výpadku síťových prvků. Nepodporuje rozdělení toku (řešením
může být stochastické směrování). Jinak statické směrování se dá kombinovat s
předchozími metodami.
adaptivní směrování – opakovaný výpočet směrovacích tabulek při provozu sítě. Ten
výpočet může být buď centralizovaný nebo distribuovaný. Toto směrování závisí na
metrice, bezpečnosti,množství přenášené informace...Je možné jej kombinovat s
předchozími metodami. Adaptivní směrování používá například „Distance vector
algoritmy“, kdy probíhá výměna kompletních směrovacích tabulek. To ale velmi
zatěžuje síť a má to pomalou konvergenci (reakci na chyby), zvláště při výpadku.
Toto směrování používají protokoly RIP, IGRP, EIGRP, BGP
delta směrování - dohledat...
protokoly RVP – ve slidech označené jako distance vector
Protokoly RVP (Routing Vector Protocols) pracují tak, že si sousední směrovače mezi sebou
vyměňují obsahy směrovacích tabulek (vektorem se míní jedna položka směrovací tabulky).
Obdržím-li jednotlivé vektory ze směrovací tabulky svého souseda, pak si z nich mohu vybrat
vektory, které ve vlastní směrovací tabulce nemám a doplnit je do vlastní směrovací tabulky.
Nesmím zapomenout u takto doplněné položky zvýšit metriku. Tyto protokoly jsou
jednoduché a snadno se implementují. Jejích nevýhodou je, že ve větších rozsáhlých sítích
může výměna vektorů oscilovat a pak některé vzdálenější sítě mohou být chvilku dostupné a
za okamžik již nikoliv. Většími sítěmi se rozumí sítě o více jak 10 LAN. Příkladem protokolů
RVP jsou protokoly RIP a RIP 2. Jelikož jsou protokoly RVP vhodné pro menší rozsáhlé sítě,
pak je vždy otázkou, zda-li se bude konfigurace sítě opravdu natolik dynamicky měnit, nebo
se sice pracněji, ale lépe nakonfigurují směrovače ručně pomocí statických položek.
Protokol RIP
Routing Information Protocol. Jeho metrikou je počet směrovačů, přes které se jde k cíli.
Spoléhá na komunikaci se sousedy, prostě si směrovače mezi sebou (pomocí bradcastů)
vyměňují obsahy směrovacích tabulek. Při směrování je nalezena pouze jedna cesta (ta
nejkratší) od odesílatele k cíli. Nevýhodou je, že v tomto protokolu není v položce směrovací
tabulky uváděna síťová maska. Proto lze protokol RIP použít jen tehdy, když v síti používáme
pouze sítě se standardní maskou.
Vylepšením je RIP2, který pracuje navíc s maskou podsítě, požaduje autorizaci a podporuje
multicast. Docela dobré info o RIP je zde... ještě víc o RIP je ve sriptech na straně 91
RIP výpočet (viz slidy 18-28): Tento algoritmus vytváří přímo routovací tabulky.Tabulky
směrovačů i uzlů obsahují identifikaci směrovačů (ve slidech písmenem) a vzdálenost k nim.
Původně má v tabulce směrovač sám sebe a se vzdáleností 0. Takže, nyní:
1) každý směrovač vyšle do všech směrů iformace o své tabulce. Ty informace co k
němu v „prvním kole“ dojdou identifikují bezprostředně okolní směrovače (tedy ty se
vzdáleností 1)
2) Opakuje se bod 1 s tím, že nyní proudí již od každého směrovače informací (každý
směrovač pošle tzv. update) více. Podle toho si předělá ten který směrovač svou
tabulku. Prostě například E ví, že mu B poslalo update, v němž je informace, že H je
od B vzdálené o 1. Jelikož E ví, že B je od něj o 1, musí být H od B vzdálené o 2
3) To se opakuje celkově tolikrát, kolikrát je to zapotřebí, prostě směrovače tu tam
rozešlou update.
RIP – výpadek linky – může způsobit problém – dobře je to popsáno ve skriptech na str. 93.
Podívejte se na obrázek...
Problém je ten, že pokud vypadne ze sítě uzel A, uzly si postupně navyšují jeho vzdálenost
Dejme tomu, že situace na počátku je 0 1 2 3 4, Nyní se A čko je odpojí, takže vzdálenost B
od A uvedená v tabulce B je neplatná, proto čeká na informaci od C, to mu pošle, že A je od
něj vzdáleno o 2, proto si B zapíše do své tabulky vzdálenost 3, nyní proběhne další update:
B pošle C to, že je od něj A vzdáleno o 3, C si zapíše 4...a vzdálenosti stoupají ... Aby si tuto
vzdálenost nenavyšovaly donekonečna, je nutné zavést nějakou max hranici, po kterou se
bude zvyšovat (tzv. nekonečno), tato hranice je u RIP stanovena na 16. Proto tedy trvá docela
dlouho, než se RIP adaptuje na výpadek linky. Ze stanovení nekonečna také plyne to, že uzel
se vzdáleností 16 a více je označen jako nedostupný.Naopak adaptace RIP na „dobré zprávy“
(změna v síti) je rychlá.
Pro rychlejší adaptaci na „špatné zprávy“ lze zavést algoritmus split horizon (v našem
příkladě to znamená, že uzel C vdálenost od A, kterou získal od B, béčku zpět nepředá, tzn. B
přijme pouze aktualizace z jiného uzlu), dalším ztychlením je algoritmus reverse poisson( C
béčku předá vzdálenost od A rovnou jako nekonečno)
protokoly LSP
Link State Protocols - Protokoly LSP pracují na zcela odlišném principu. Každý směrovač si
zjistí, jaké směrovače má za své sousedy a v pravidelných intervalech testuje jejich
dostupnost. Celou síť pak zaplavuje svými oběžníky o tom, koho má za své sousedy. Takže
každý směrovač má od všech ostatních směrovačů zprávu o tom jaké mají sousedy. Takže
každý směrovač má seznam všech cest v síti.
Na tento seznam se pustí algoritmus nejkratší cesty, kterým se zjišťuje směr kam se má IPdatagram odeslat. Tj. položky směrovací tabulky se počítají algoritmem nejkratší cesty z dat
obdržených od ostatních směrovačů. U rozsáhlých sítí je problematické zaplavovat je velkým
množstvím informací ze směrovačů, proto se takové sítě rozdělí na oblasti a zmíněný postup
se aplikuje pouze v rámci této oblasti. Na hranicích se sousedními oblastmi jsou hraniční
směrovače, které si pak vyměňují informace o celých oblastech.
Protokoly LSP jsou oproti protokolům RVP nesrovnatelně stabilnější a lze je aplikovat i u
velmi rozsáhlých sítí. Nevýhodou je, že návrh sítě, tj. rozdělení sítě na oblasti musí provést
zkušený odborník, rovněž konfigurace je netriviální. Pokud se použije protokol typu LSP bez
větších zkušeností, tak je také možné, že některými linkami data prostě nepotečou a jiné
budou přetížené. Příkladem protokolu LSP je třeba protokol OSPF.
protokol OSPF
Open Shortest Path First – dělí sítě na oblasti, kde každá oblast je očíslovaná (32 b číslem).
Oblast číslo 0 je tzv. páteř (backbone) Směrovače se rozdělí na interní, hraniční nebo páteřní
podle toho, kde směrovač leží...viz obr. slide 46. Směrování probíhá buď uvnitř oblasti nebo
mezi oblastmi (vždy přes oblast 0). Propojení sítí je buď přes autonomní systém nebo přes
hraniční směrovač autonomního systému (viz slide 47/5). Algoritmus používá autorizaci
(buď žádnou nebo jednoduchou nebo pomocí MD5).
OSPF zprávy – jsou to LSA (Link State Advertisments) zprávy, tyto zprávy mohou být
zasílány jen ve své oblasti (tedy ne mezi oblastmi). Typy paketů jsou: hello (pro testování a
nestavení spojení), popis databáze (popis databáze stavů linek) , požadavek stavu linky
(vyžádání konkrétní části databáze stavů linek), aktualizace stavu linky (LSA o lince
směrovače, o síťové lince...), potvrzení stavu linky (potvrzení příjmu paketu)
OSPF metriky – automatické – automaticky vypočtené směrovači, nemusí být
implementovány, mohou se dynamicky měnit, cena je 100 000 000/šířka pásma [bps](??),
implicitní – jsou v celé síti stejné, jsou vhodné pro homogenní prostředí, manuální – jsou
pevně nastavené
Protokoly IGP a EGP – ve slidech označené jako skupina exterior algoritmy
Protokoly IGP jsou určeny pro činnost v rámci autonomního systému. Již zmíněné protokoly
RIP, RIP2, OSPF jsou vesměs protokoly IGP.Ovšem poskytovatelé Internetu si mezi sebou
potřebují také vyměňovat směrovací informace. Poskytovatelé Internetu pro výměnu
směrovacích informací mezi autonomními systémy používají protokoly EGP. V dnešní době
používají protokol BGP (Border Gateway Protocol) verze 4.Protokoly EGP se liší od
protokolů IGP zejména tím, že ve směrování umožňují zohlednit směrovací politiku (tj. kdo
komu platí).
Agregace - Agregace je proces, kdy se z několika položek směrovací tabulky udělá jedna
položka. Tento proces je žádoucí např. při propagaci sítí vně autonomního systému.
Jednu položku můžeme z více udělat tehdy, když sítě slučované do jedné položky vytvoří
supersíť. Automatická agregace je spíše přání než realita. Poskytovateli většinou vypadnou z
jeho supersítí některé adresy, které ještě nikomu nepřidělil, takže nelze automaticky agregovat
všechny IP-adresy autonomního systému do jedné nebo několika málo položek. Prakticky se
agregace provede ručně tak, že se vně autonomního systému propagují všechny IP-adresy,
které jsou přiděleny.
Redistribuce - Na obrázku dole je otazníkem označen směrovač, který si vyměňuje současně
směrovací informace protokoly BGP, OSPF, RIP a k tomu možná má ve směrovací tabulce
několik statických položek. Otázka je, zdali se mají informace (položky směrovací tabulky)
získané jedním směrovacím protokolem propagovat do ostatních směrovacích protokolů, tj.
má-li se provést redistribuce.
Znamená to tedy vlastně to, že položka ve směrovací tabulce musí v sobě nést informaci,
jakým protokolem byla vytvořena
BGP – Border Gateway Protocol – zajišťuje směrování a řízení provozu mezi autonomními
systémy, přiděluje autonomním systémům jednoznačné identifikátory. Používá Distance
Vector Algoritmus. Směrovače jsou propojeny pomocí TCP. Slouží k připojení zákazníků s
více cestami do internetu. Obrázek jak to celé vypadá je na slidu 52 anebo se podívej na
obrázek nahoře (myslím ten s AS1 a AS2).
Přednáška 6 –QoS
Quality of Service
Kvalita služeb – je to opatření snažící se zaručit koncovému uživateli doručení dat v potřebné
kvalitě. Uplatňuje se u přenosu multimédií, IP telefonii atd. Kvalita služby je ovlivněna
stanicemi (uživatelé a servery), směrovači, přepínači a linkami (mezi směrovači nebo na
LANce)
Sdílení kapacity sítě – v jednoduché síti typu Internet se všichni uživatelé dělí o prostředky
sítě stejným dílem (100 uživatelů a linka 100 Mbit/s -> 1 Mbit/s na každého), většinou není
rychlost problém, některé aplikace (např. IP telefonie) nemusí fungovat.
Jaké jsou možnosti Qos v tomto případě?
• Rezervovat přenosovou kapacitu jen pro daný kanál
• Nastavit vyšší prioritu některým službám a zkrátit jejich odezvu
• Omezit přenos na definovaný limit (např. omezení FTP tak, aby bylo možno při tom
surfovat)
• Definovat maximální zpoždění dat - vemte si například, že sledujete video – tam je
žádoucí, aby zpoždění dat bylo minimální, naopak u HTTP nějaké to zpoždění moc
nevadí
Příklad sítě bez a s QoS: bez: slide 5 – tok se dělí rovnoměrně mezi kompy, s: slide 6 –
komunikace mezi 2 počítači si žádá tok 1 Mbps. Tak jim ji dáme a ostatním rozdělíme ten
zbytek.
Parametry tvořící QoS: šířka pásma (= rychlost přenosu dat), jednosměrné zpoždění (tzn.
čas potřebný pro přenesení paketu přes fyzické médium, což zahrnuje i čas způsobený
řazením paketů do front), rozptyl zpoždění (to jak zpoždění kolísá), ztrátovost paketů. K tomu
aby to celé funcovalo co nejlépe, je nutno zavést nějaké...
...Plánovací mechanismy: FIFO, prioritní FIFO, Round Robin, WFQ, Leaky Bucket, Leaky
Bucket + WFQ... popis:
• FIFO – slide 9 – pakety přicházejí ve frontě a postupně jsou obslouženy
• Prioritní FIFO – slide 10 nebo obrázek...
•
•
•
pakety jsou ukládány jak do fronty, tak do prioritní fronty. Pakety z prioritní fronty
mají vždy přednost...viz zde
Round Robin – dejme tomu že máme dvě fronty – jednu prioritní a druhou ostatní.
Pakety se obsluhují postupně tak, jak přicházejí, ale pokud příjde najednou paket z
fronty ostatních a z prioritní fronty, má přednost ten z té prioritní. (tady ovšem moc
nechápu jeký je rozdíl oproti prioritní FIFO)
WFQ – weighted fair queuing – každý datový tok má svoji frontu, každá tato fronta
má svou váhu. Tyto fronty jsou obsluhovány současně tak, aby se na každou dostalo,
ale samozřejmě prvků s nejvyšší váhou jde k obsluze asi nejvíc... viz obr.
Leaky Bucket – neboli děravý kýbl – viz zde nebo viz obrázek... na tomto obrázku jsou
ovšem pakety na které nezbyly tokeny, zahozeny. Podotýkám, že tomu tak nemusí být,
pakety mohou třeba jen čekat (sice se tím způsobí nějaké zpoždění, ale pokud to neva,
tak co). To co je na obrázku bych viděl jako Leaky Bucket pro UDP
•
Tak, nyní k principu. Zásobník má nějaký maximální počet tokenů, který jej může
naplnit. Tokeny přibývají rychlostí x tokenů za sekundu. Do té doby, než se zásobník
naplní, příchozí pakety čekají. Poté co se naplní, jsou pakety odeslány po řadě
maximální možnou rychlosí do sítě (tu rychlost označme B) a zásobník se vyprazdňuje
rychlostí Bt (t=čas). Poté co se zásobník tokenů vyprázdní, nezbývá dalším paketům
čekat, než se opět naplní.
Leaky Bucket + WFQ – máme n front (označených váhou), přičemž každá obsahuje v
sobě navíci Leaky Bucket ... viz slide 14
Co říká na QoS IP Protokol? IP protokol má v hlavičče informační pole ToS (Type of
Service), jehož hodnoty znamenají toto:
hodnota: význam
1000
minimalizuj zpoždění
0100
maximalizuj propustnost
0010
maximalizuj spolehlivost
0001
minimalizuj finanční náklady
0000
normální služba
ToS v aplikacích - ... viz slide 16, tam je napsané, pro jaké aplikace se používají jaká
nastavení ToS. Např. pro telnet je to 1000 (minimalizacee zpoždění), pro ftpdata je to 0100
(maximalizuj propustnost)... je to celkem logické nastavení nebo ne?...
TCP protokol a řízení toku
Efektivně lze omezovat pouze odchozí tok dat, pro příchozí musíme použít nepřímé metody.
Můžeme například pozdržet odeslání potvrzení a tím prodloužit RTT (Round Trip Time – co
to je viz dále ), ale pozor na timeout, který by po vypršení způsobil opětovné odeslání dat.
Dále můžeme měnit velikost okénka.
RTT v TCP – Zpoždění je čas, který uplyne od odeslání zprávy zdrojovým uzlem po její
přijetí na uzlu cílovém. Zahrnuje zpoždění v přenosové trase a na zařízeních, které jsou její
součástí. Je nutné rozlišit zpoždění jednosměrné (čas mezi odesláním paketu zdrojem a jeho
přijetí cílem) a zpoždění obousměrné, tzv. round-trip latency, zahrnující dobu cesty paketu
tam i zpět plus čas jeho zpracování cílem. Round-trip latency nebo také Round Trip Time
(RTT) se v síťové praxi požívá nejčastěji, protože jej lze změřit z jednoho místa (uzlu).
Od RTT se odvozuje timeout. Jenže...jak dopředu zjistit hodnotu RTT? Mějme SampleRTT =
posledně naměřený RTT, EstimatedRTT = očekávaný RTT. Pak platí:
EstimatedRTT = (1 − α ) ⋅ EstimatedRTT + α ⋅ SampleRTT kde α = 0,125
Pěkný graf na SampleRTT a EstimatedRTT je na slidu č.19.
TCP Timeout – jak se odvozuje od RTT?
DevRTT = (1 − β ) ⋅ DevRTT + β ⋅ ( SampleRTT − EstimatedRTT ) kde β = 0, 25
DevRTT popisuje proměnlivost RTT. Nyní konečně ten vzoreček pro timeout:
Timeout = EstimatedRTT + 4 ⋅ DevRTT ... timeout se po každé ztrátě paketu zdvojnásobí
TCP technika okna - Nyní je naším problémem případ, kdy klient potřebuje odeslat velké
množství dat. Klient (resp. Server) může odesílat data druhé straně aniž by jejich příjem měl
potvrzen až do tzv. okna (Window – zkratkou WIN). Představme si (viz obrázek), že klient se
serverem navázal spojení a vzájemně se dohodli na maximální velikosti segmentu (MSS) o
velikosti 1 K (tj. 1024 B) a vzájemné velikosti okna 4 K (tj. 4096 B).
Klient začne s odesíláním dat, odešle segmenty 1, 2 a 3. Poté obdrží od serveru potvrzení (4),
které potvrzuje segmenty 1 a 2. Klient v zápětí odesílá segmenty 5, 6 a 7. Jenže server data
mezitím nedokázal zpracovat a data mu zaplnila vyrovnávací pamě;, proto segmentem 8 sice
potvrdí příjem segmentů 3, 5, 6 a 7, ale zároveň klientovi uzavře okno, tj. klient nemůže s
odesíláním dat pokračovat. Poté co server zpracuje část dat (2 KB), tak umožní klientovi
pokračovat v odesílání, ale neotevře mu segmentem 9 okno celé – pouze 2 KB, protože
všechna data ve vyrovnávací paměti ještě nezpracoval a pro více dat nemá místo.
Prozkoumejme na obr. 9.16 jak vidí klient okno po přijetí segmentu 4...
První 2 KB jsou již potvrzeny, okno je tedy posunuto za bajt 2048. Tato potvrzená data již
klient nemusí udržovat v paměti. Odeslaná, ale nepotvrzená data (segment 3) tvoří 1 KB.
Klient může tedy odeslat bez dalšího potvrzení 3 KB dat.
IPv6 a QoS – QoS v dnešním internetu funguje nepovinně, je jen jeho částech. Zajištění QoS
mezi jednotlivými uživateli je tedy obtížné, IPv6 by měl tento nedostatek odstranit, protože
má v hlavičce nová pole definující způsob zpracování a identifikace informací přenášených v
síti.
Přednáška 7a) – Propojování sítí
Propojování sítí – sítě se propojují s různými topologiemi a operačními systémy. Tím se
vytvářejí „internety“. Největším „internetem“ je Internet (:-)). K propojení sítí můžeme použít
opakovač(repeater, hub), most(bridge), přepínač(switch), směrovač(router) nebo přenosovou
bránu(geteway). Některé tyto prvky použijeme i pro zlepšení spojení v rámci sítě LAN.
Opakovač – Opakovač je tvořen dvěma nebo více síťovými kartami, které jsou vzájemně
propojeny. Objeví-li se nějaký datový rámec na jednom rozhraní,pak je automaticky
zopakován na všechny ostatní. Opakovačslouží pro překonání problému útlumu signálu (čím
větší vzdálenost signál urazí, tím je slabší). Tento útlum je následkem odporu a šumu.
Opakovač vstupní signál vyčistí a zesílí, tím se prodlouží možná vzdálenost mezi
komunikujícími uzly (viz slide 3). Opakovač pro krocenou dvojlinku se označuje jako HUB.
Princip opakovače: Pracuje na úrovni bitů, nemá žádnou vyrovnávací paměť, může
propojovat libovolný počet segmentů sítě, může propojovat pouze segmenty sítě se stejnou
přenosovou rychlostí. Opakovač musí šířit kolize. V ethernetu jich nemůže být libovolně
mnoho kvůli době šíření kolize (kolize je, když vysílá více zdrojů na jedno médium současně,
signál je znehodnocen, k odstranění kolizí slouží CSMA/CD – co to je zde nebo bible strana
117) – proto mohou být mezi každými 2 body max 2 opakovače .
Filtrování opakovače – Opakovače šíří do všech směrů i to, co by šířit nemusely.Chtělo by
to nějaké filtrování provozu, což znamená, aby opakovač dokázal „rozumět“ alespoň adresám
linkové vrstvy. Pokud by se zařízení rozhodovalo podle obsahu paketu, zda poslat, či ne,
muselo by mít nějakou vyrovnávací paměť. Tím pádem by šlo propojit segmenty s různými
rychlostmi.
Most (bridge) – je to jednotka, která řídí mezi sítěmi přepojování paketů z jedné sítě do
druhé. Nešíří tedy paket do všech připojených segmentů sítě. Zlepšuje spolehlivost a
bezpečnost sítí. Most pracuje na linkové vrstvě, nemusí propagovat kolize (má vyrovnávací
paměť). Most propojuje právě 2 sítě. Varianta „vzdálený půlmost“ znamená, že jsou spolu
propojeny 2 mosty a přes ně se propojují sítě (viz slide 7). Více o mostu je tady nebo raději v
bibli na straně 115.
Přepínač (switch) – jedná se o víceportový most, je novější, rychlejší a je to jeden z
nejpoužívanějších aktivních síťových prvků. Switch nepropaguje kolize (má vlastní
vyrovávací paměť), všesměrově šíří pouze bradcasty a často se používá jako náhrada
opakovače. Přes jeden přepínač může probíhat více přenosů až do maximální kapacity
přepínače. Přepínačem se označují výkonnější mosty, které umí opakovat rámce nejen mezi
jednotlivými segmenty Ethernetu, ale i např. mezi Ethernetem a Fast Ethernetem, mezi
Ethernetem a FDDI atd. Přepínač musí umět nejenom změnit tvar rámce např. z Ethernetu na
FDDI, ale i pokusit se překlenout rozdíl mezi přenosovými rychlostmi. Problém je totiž při
přenosu dat mezi rychlým segmentem (FDDI) a např. Ethernetem, kdy z FDDI může
směrovat na Ethernet takové množství dat, že je Ethernet nedokáže odebírat.Rámce se musí
ukládat do vyrovnávací paměti přepínače atd.
Přepínač – filtrace – aby mohl přepínač filtrovat (tzn. neposílat příchozí pakety na všechny
své výstupy, ale jen tam, kam skutečně patří, resp. pokud tam nepatří, tak je zahodit), musí
znát topologii sítě, tzn. na jakém portu (zde nemyslíme samozřejmě port v soketech, ale
síťový port) je která stanice. Pokud přepínač topologii nezná, chová se podobně jako
opakovač (hub). Tu topologii můžeme na přepínači nastavit buď ručně (ale to je pracné,
protože síť se může často měnit) nebo ho nechat, ať si to zjistí sám zpětným učením. To
probíhá tak, že nejdříve se přepínač chová jako opakovač (vysílá pakety na všechny strany a
dostává odpovědi, ze kterých se učí) a učí se (ukládá si do své tabulky dvojici port, adresa
(MAC)) a po určité době začne filtrovat provoz.
Přepínač – dále... může buď celý rámec příjmout, analyzovat a poté odeslat (metoda store
and forward) nebo může přečíst pouze cílovou adresu a zbytek již rovnou odesílat (metoda cut
through) nebo může kombinovat obě metody.
Učení přepínače – viz slide 11-13 ... přepínač dostane rámec o kterém neví, do kterého portu
jej má odeslat. Pošle jej tedy do všech portů, kromě toho, ze kterého přišel a upraví tabulku.
Pokud přepínač již má stanovenou tabulku a dostane nějaký rámec nyní, pošle jej na port,
který odpovídá adrese v tabulce. Pokud přepínač dostane paket, jehož příjemcem má být
zároveň jeho odesílatel, přepínač tento paket ignoruje. Učení přepínače nebude fungovat,
pokud graf sítě bude obsahovat nějakou kružnici (smyčku). Přepínače se ale umí domluvit a
vzniklou smyčku přerušit. Ta kružnice ale může být v síti úmyslně např. jako záloha spojení.
Co když takovouto kružnici přepínače zruší? To by nebylo dobré... proto máme šikovný
algoritmus...
Spanning Tree Algorithm – Je to algoritmus, který najde kostru grafu sítě a přeruší tak
případné kružnice (tak že zablokuje některé porty směrovačů). Tím se zachová stromová
struktura. Pokud by náhodou došlo k nějakému výpadku, zablokované porty se opět uvolní.
Tento algoritmus podporují všechny moderní přepínače. Tak nyní k tomu, jak to funguje
(animace spanning tree ) ...
Spannning Tree Algorithm – princip –
1. nejdříve se zvolí „kořenový přepínač“ (root switch), bude to ten s nejmenší MAC
adresou. Na začatku (toho zvolení kořenu) bude každý přepínač tvrdit, že je root,
pokud neví o jiném přepínači. Postupně si přepínače rozesílají broadcastem BPDU
zprávy (Bridge Protocol Data Units – viz zde) a na kořenovém řepínači se dohodnou
2. Po tom zvolení si každý přepínač,co není rootem, zvolí jeden root port – to je port
tohoto přepínače na nejkratší cestě (metrikou je cena,ne jen počet hopů, záleží také na
rychlosti linek) ke kořeni .
3. Poté se na každém segmentu sítě (segment = linka propojující switche, která je
součástí kostry grafu) zvolí vyhrazený přepínač (to je ten, jež má nejlepší cestu ke
kořenovému přepínači) a jeho port s touto cenou bude vyhrazený (designated) port.
Docela dobře je to vyobrazeno na obrázku se slidů...
4. Porty přepínačů, které nepatří ke kostře grafu, se přepnou do blokujícíh o stavu. Root i
designated porty jsou vždy ve stavu forwarding.
Více o spanning tree slidy 19 – 21 a taky zde.
Stavů portů může být celkem 5: blocking (neprocházejí jím rámce, je to záložní port, pouze
přijímá BPDU a hledá root switch), listening(slouží k příjmu a vysílání BPDU (ne rámců),
buduje kostru sítě), learning(neprocházejí jím rámce, učí se MAC ostatních a přijímá BPDU),
forwarding (procházejí jím rámce, předává BPDU, zkrátka plně funkční port), disabled.
Dále ke Spanning Tree – jeho konvergence při změně topologie sítě trvá implicitně 50
sekund (20 + 15 + 15...viz slide 22). Existuje protokol Rapid Spanning Tree, který slučuje
stavy blocking,disabled a listening do jednoho stavu – discarted. Tento Rapid Spanning Tree
nemusí díky aktivnímu potvrzování čekat na timeouty.
Směrovač – Router – pracuje na síťové vrstvě (potřebuje IP adresu), propojuje sítě a pracuje
se síťovými adresami. Nešíří broadcasty z jedné sítě do druhé. Pojem směrovače je nezávislý
na stroji a OS (může to být krabička běžící na linuxu, nebo i počítač s Windows). Směrovač
přenáší data i mezi sítěmi, které používají naprosto odlišné technologie, směrovače jsou tedy
pro internet nezbytné. Kromě směrování může směrovač podporovat i další funkce (firewall,
NAT, VPN). Směrování může být statické nebo dynamické (např. RIP, OSPF...) Schopnost
předávat datové pakety mezi sí;ovými rozhraními směrovače se nazývá jako předávání
(forwarding). Zatímco u směrovačů je tato funkce požadována, tak u počítačů s klasickým
operačním systémem (UNIX, OpenVMS, NT apod.) je někdy dotazováno, jak přinutit jádro
operačního systému předávání zakázat. Na každém rozhraní směrovače může být použit jiný
linkový protokol, na jednom např. Ethernet a na druhém např. HDLC.
Přepínače na vyšších vrstvách – dnešní přepínače podporují QoS, VLAN a další funkce,
podporují různé verze Spanning Tree Algorimů. Umí filtrování rámců na různých vrstvách:
linková, síťová(Layer 3 switch – filtrování IP adres a IP protokolu, je to vlastně HW
optimalizovaný směrovač), transportní (Layer 4 switch – filtruje na úrovni portů TCP a UDP
a umožňuje rozlišovat provoz), aplikační(Layer7 switch – slouží k rozložení zátěže na více
serverů, které se navenek budou takhle tvářit jako 1 server)
Brána – přenosová brána je obecný termín, brána může znamenat:
• směrovač
• aplikační bránu – např. software pro poštovní aplikace, proxy WWW server atd.
• bránu pro překlad protokolů z jedné množiny protokolů do druhé
Přednáška 7b) – Protokol SCTP
SCTP – Stream Control Transmission Protocol – jedná se o komnikační protokol transportní
vrstvy (tedy něco jako TCP), byl původně navržen pro telefonní signalizaci po IP. Odstraňuje
nedostatky TCP a propůjčuje si některé vlastnosti UDP. V současnosti je podporován v
Linuxu , Free BSD, MacOS, Solarisu ... , tedy skoro všem kromě Windows.
Vlastnosti SCTP – po navázání spojení můžeme komunikovat ve více streamech najednou. V
rámci každého proudu (streamu) protokol garantuje doručení dat ve správném pořadí (tedy
jako TCP, ale více streamů), případný výpadek v jednom streamu neovlivní ostatní streamy.
SCTP lze tedy přirovnat ke svazku spojení TCP, ale má menší režii a několik vylepšení.
Formát SCTP – paket začíná univerzální hlavičkou (zdrojový + cílový port, ověřovací
značka, kontrolní součet), následují tzv. kousky (chunks), které obsahují řídící informace či
data pro jednotlivé proudy (typ, příznaky, délku, další hlavičky a data...). Počet nebo struktura
těchto kousků nejsou pevně dány. Formát SCTP paketu je na obrázku.
Jak probíhá u SCTP potvrzování dat? – Citelné změny v porovnání s TCP zaznamenalo
potvrzování. SCTP k němu využívá pořadová čísla (jak také jinak), která zde najdete na dvou
úrovních: Transmission Sequence Number (TSN) slouží k číslování jednotlivých datových
kousků (na úrovni asociace), zatímco Stream Sequence Number (SSN) určuje číslování v
rámci jednoho konkrétního proudu.Hlavní předností potvrzování v SCTP je, že dokáže ohlásit
chybějící kusy dat. Slouží k tomu speciální kousek nazvaný selektivní potvrzení. Ten
obsahuje nejvyšší pořadové číslo přijatého datového kousku a zároveň vyjmenovává chybějící
úseky dat. Díky tomu je odesilatel přesně informován, která data dorazila a která ne. Navíc
pokud vysílající dostane čtyři potvrzení ohlašující stejnou díru v datech, na nic nečeká a
chybějící část rovnou pošle znovu (tzv. rychlé opakování).
Multi Homing – komunikující stanice má několik IP adres, během komunikace je vybrána
jedna brána jako privátní a z ní jsou odesílána data. Pro opakování je vybrána jiná brána.
Pokud jsou s komunikací přes primární bránu větší problémy, přejde se kompletně na jinou
bránu. SCTP monitoruje všechny cesty a udržuje si přehled o jejich stavu ... více o
mutlihomingu je zde
Iniciace spojení SCTP – oproti TCP se posílá cookie – SCTP má 4 cestný handshake – init,
init-ack,cookie-echo,cookie-ack. Viz slide 8.
Formátování do zpráv – SCTP garantuje, že příjemce dostane zprávy rozdělené tak, jak je
odesílatel odeslal (podobně jako UDP – to taky posílá data po kouscích – vzpomeň na sliding
window, oproti tomu TCP odesílá se chová v podstatě jako proud bitů – zprávy nejsou nijak
rozdělené)
Ukončení spojení SCTP – oproti TCP uzavřou všechny stanice spojení najednou – viz slide
10...
Budoucnost SCTP – jedná se o velmi mladý protokol (RFC z roku 2000), je velmi vhodný
pro běžné služby jako je FTP a HTTP. Zatím se čeká na podporu SCTP ve Widows a taky ve
směrovačích. Pak to příjde a to nezachápeš, woe! více zde
Přednáška 8 – Jmenné služby
Obsah přednášky - úloha jmenných služeb, informace ve jmenných službách, jmenné
služby X.500, DNS a jiné
Úloha jmenných služeb – je to specalizovaná databáze optimalizovaná pro čtení a
vyhledávání – něco jako adresář. Provádí se v ní překlad, lokalizace, ověření a poskytování
podrobných informací.
Jmenné služby: je jich více druhů, jako příklad jmenujme X.500, LDAP, DNS (Domain
Name System), NIS (Network Information System), CDS (Cell Directory Service), Active
Directory.
X.500 – je to skupina protokolů pro elektronické adresářové služby .Vznik v roce 1988, je to
hierarchický jmenný prostor, pracuje na principu komunikace klient – server.
Koncept X.500 je ten, že je to jedna hierarchická struktura – tzv. Adresářový informační
strom. Hierarchická organizace položek tohoto stromu je samozřejmě obhospodařována více
servery. Jenda položka se skládá ze seznamu atributů, každý z těhto atributů má jednu nebo
více hodnot.
X.500 – organizace dat – záznam se zkládá z jedinečného jména, jedinečného jména a
atributů. Toto jedninečné jméno se skládá jednak z relativního jedinečného jména položky a
jednak z položek umístěných v Adresářovém stromě hierarchicky nad touto položkou v cestě
ke kořeni. Takže je to, jak psal Kubr, vlastně posloupnost relativních jedinečných jmen od
kořene. Relativní jedinečné jméno je dejme tomu něco jako název položky. Berte to jako
systém adresářů v počítači – jedinečné jméno by byla kompletní cesta k adresáři (např.
C:\programy\Kuba\PKO) a relativní jedinečné jméno by byla relativní cesta k adresáři (jen
PKO). Atributy jsou prostě jen už informace o položce – viz obrázek...
Na obrázku je jedna položka stromu. Jedinečným jménem je celý první řádek, relativním
jedinečným jménem je to “cn”. Zbytek jsou atributy.
Atributy mohou být třeba tyto: C (Country), SP (State or Province), L (Locality), O
(Organisation), OU (Organisation Unit), CN (Common Name). Příkladem může být např.
záznam: CN = atm.felk.cvut.cz, OU=FELK, O=CVUT,C=CZ ...nebo...
CN = Jan Kubr, C= CZ
X.500 využívá pro přístup k položkám protokoly DAP (Directory Access Protocol, je to
prorokol OSI) a LDAP (Lightweight Directory Access Control Protocol).
Protokol LDAP – funkce – dotazování a prohledávání (operace search a compare), změny
dat (operace add, delete a modify), autentizace (operace bind a unbind). Více o LDAP je na
http://cs.wikipedia.org/wiki/LDAP
Shrnutí: X.500 využívá decentralizovaný, jednotný globální prostor, podporuje složité dotazy
i autentizaci. Více o X.500 je na http://en.wikipedia.org/wiki/X.500
DNS... Domain Name System
Předmluva...
Vazba mezi jménem počítače a IP adresou je definována v DNS databázi. DNS (Domain
Name System)je celosvětově distribuovaná databáze. Jednotlivé části této databáze jsou
umístěny na tzv. name serverech. Chci-li se přihlásit na uzel info.pvt.net s IP adresou
194.149.104.203, použiji příkaz: telnet info.pvt.net. Ještě předtím, než se vlastní příkaz
provede, přeloží se DNS jméno info.pvt.net na IP adresu a teprve poté se provede příkaz:
telnet 194.149.104.203
Domény a subdomény - Celý Internet je rozdělen do tzv. domén, tj. 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, tzv. subdomény, např. doméně firmy lze vytvořit
subdomény pro oddělení. Doménové jméno odráží příslušnost uzlu do skupiny a podskupiny.
Každá skupina má přižazeno jméno. Z jednotlivých jmen skupin je pak složeno doménové
jméno uzlu. Např. uzel se jménem jakub.firma.cz je uzel se jménem jakub v subdoméně
firma domény cz.
Reverzní domény - Již jsme uvedli, že komunikace mezi uzly probíhá na základě IP adres,
nikoli doménových jmen. Některé aplikace naopak potřebují k IP-adrese nalézt jméno, tj.
nalézt tzv. reverzní záznam. Jedná se tedy o překlad IP-adresy na doménové jméno. Tento
překlad se často nazývá zpětným (reverzním) překladem. Podobně jako domény tvoří i IPadresy stromovou strukturu. Domény tvořené IP-adresami se pak často nazývají reverzní
domény. Pro účely reverzního překladu byla definována pseudodoména „inaddr.arpa“. Jméno
této pseudo domény má historický původ, jde o zkratku „inverse addresses in theArpanet“.
viz obrázek...
Pod doménou in-addr.arpa jsou domény jmenující se jako první číslo z IP-adresy sítě. Např.
síť 194.149.101.0 patří do domény 194.in-addr.arpa. Sí_ 172.17 patří do domény 172.inaddr.arpa. Dále doména 172.in-addr.arpa se dělí na subdomény, takže sí_ 172.17 tvoří
subdoménu 17.172.in-addr.arpa. Je-li sí_ 172.17 rozdělena pomocí sí_ové masky na subsítě,
pak každá subsí_ tvoří ještě vlastní subdoménu. Všimněte si, že domény jsou zde tvořeny
jakoby IP-adresami sítí psanými ale pozpátku. Např. Reverzní doména pro subsíť
194.149.150.16/28 je 16.150.149.194.in-addr.arpa
Zóna - Zóna je část prostoru jmen, kterou obhospodařuje jeden name server. viz obrázek
Takže doména pvtnet.cz obsahuje v sobě všechny subdomény, ale zóna pvtnet.cz delegovala
na jiné name servery pravomoci na zóny brn.pvtnet.cz, plz.pvtnet.cz a ova.pvtnet.cz. Takže
zóna pvtnet.cz obsahuje doménu pvtnet.cz až na tři uvedené výjimky.
Doména vs. autonomní systém - 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čů...viz obrázek
Jiná je situace u reverzních domén, které kopírují strukturu poskytovatelů Internetu.
DNS dotazy a odpovědi - Přeložení jména na IP-adresu zprostředkovává tzv. resolver.
Resolver je klient, který se dotazuje name serveru. Jelikož je databáze celosvětově
distribuována, nemusí nejbližší name server znát odpověď, proto může tento name server
požádat o pomoc další name servery. Získaný překlad pak name server vrátí jako odpověď
resolveru. Veškerá komunikace se skládá z dotazů a odpovědí.
Rekurzivní dotaz a odpověď - Resolver předává všechny dotazy na lokální name server. Od
name serveru pak očekává konečnou (rekurzivní) odpověď. Name server buď odpoví přímo,
nebo sám kontaktuje další name servery - prostě spustí standardní algoritmus pro vyhledání
odpovědi (tj. začne u kořenových DNS serverů a postupuje do nižších úrovní až k cíli), tj.
name server rekurzivně řeší dotaz a klientovi zašle až výsledek. Vypadá to tak, jak to ukazuje
obrázek
DNS komunikace - DNS používá jak protokol UDP, tak i protokol TCP. Pro oba protokoly
používají port 53 (tj. porty 53/udp a 53/tcp). Běžné dotazy, jako je překlad jména na IP-adresu
a naopak, se provádějí přes protokol UDP. Délka přenášených dat protokolem UDP je
implicitně omezena na 512 B (příznakem truncation může být signalizováno, že se odpověď
nevešla do 512 B a pro přídanou kompletní odpověď je nutné použít protokol TCP). Délka
UDP paketu je omezena na 512 B, protože u větších IP-datagramů by mohlo dojít k
fragmentaci. Fragmentaci UDP datagramu DNS nepovažuje za rozumnou.
Ze slidů...neboli +/- to samé ve zkratce
DNS je systém primárně určen pro překlad mezi doméovými jmény a adresami, vychází z
hosts.txt (lokální soubor v počítači, kde jsou položky typu “jméno” – “IP adresa” – většinou
se při pokusu o překlad doménového jména na IP počítač podívá najdříve do něj a až potom
žádá o pomoc DNS ). DNS shromažďuje v tabulkách tyto informace:
A (32b IP adresa), NS (autoritativní jmenný server), CNAME (synonymum ke jménu), SOA
(start of authority), PTR (reverzní překlad), HINFO (popis SW a HW), MX (preference a
jméno mail serveru), TXT (textový řetězec), AAAA (128b IP adresa ). více o DNS je zde
DNS komponenty:
• jmenný prostor a zdrojové záznamy – jmenný prostor má strukturu stromu, jméno má
velikost 0-63 B, celkově až 255 B. Jména se dělí na absolutní (atm.felk.cvut.cz) a
relativní (atm)
• jmenné servery – jsou to datové sklady vytvářející jmennou databázi. Tyto servery
odpovídají na dotazy, synchronizují databázi a udržují mezipaměť odpovědí (nějakou
Cache na časté dotazy)
• resolvery – je to soustava knihovních funkcích zajišťujících překlad. Je součástí
klienta i DNS serveru.
Strom DNS domén – struktura je hierarchická, jak poznáme jednak z názvů stránek na webu
a taky ze slidu 10. Strom reverzních domén DNS můžeme vidět na slidu 11.
Typy serverů DNS:
• primární –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í – kopíruje si databáze v pravidelných intervalech z primárního serveru.
Primární i sekundární Name Servery jsou tzv. autoritou pro své zóny, tj. jejich data o
zóně se považují za nezvratná (autoritativní)
• caching only – není pro žádnou doménu ani primárním ani sekundárním Name
Serverem avšak využívá obecné vlastnosti name serveru, tj. data, která jím prochází ,
ukládá do své paměti. Každý server je Caching server, ale souslovím Caching Only
zdůrazňujeme, že není pro žádnou zónu ani primárním ani sekundárním Name
Serverem
• root – je Name Server obsahující root doménu. Každý root server je primární server.
• forwarding – předává rekurzivní dotaz (odlehčení linky), může sám resolvovat
• slave - umí jen forwarding
Věty RR - Informace o doménových jménech a jim příslušejících IP adresách, stejně tak jako
všechny ostatní informace distrubuované pomocí DNS, jsou uloženy v paměti DNS serverů
ve tvaru zdrojových vět (Resource Records – RR). Name server naplňuje svou paměť
několika způsoby. Autoritativní data načte ze souborů na disku, nebo je získá pomocí dotazu
zone transfer z paměti jiného serveru. Neautoritativní data získává postupně z paměti jiných
serverů, tak jak vyřizuje jednotlivé DNS dotazy. V případě, že DNS klient (resolver)
potřebuje získat informace z DNS, pak požaduje po name serveru věty RR podle zadaných
požadavků. Klient může např. požadovat po serveru věty RR typu A, které obsahují IP adresy
pro dané doménové jméno apod.Všechny věty RR mají stejnou strukturu. Struktura RR věty
je znázorněna na obr.
Popis jednotlivých polí vět RR:
• NAME – doménové jméno
• TYPE – typ věty
• CLASS – třída věty
• TTL – Time to Live. 32bitové číslo udávající dobu, po kterou může být tento RR
udržován v cache serveru jako platný. Po vypršení této doby musí být věta
považována za neplatnou. Hodnota 0 zabraňuje neautoritativním serverům uložit RR
větu do cache.
• RDLENGTH – 16 bitové číslo specifikující délku pole RDATA
• RDATA – vlastní data ve tvaru řetězce proměnné délky. Formát tohoto pole závisí na
typu a třídě RR
Na následujícím obrázku jsou příklady nejčastějších typů vět RR:
DNS komunikace – probíhá přes protokol TCP i UDP na portu 53, u UDP je povoleno
přenést jen max 512B(?? opravdu ??). Dotaz se posílá na více serverů, první odpověď je
platná, ostatní se zahodí. Je tu možnost jisté nekonzistence name serverů. DNS dotaz a DNS
odpověď jsou rekurzivní. DNS update je podpora pro ddns (??), informace o zóně,
předpoklady, update. DNS komunikace podporuje pozitivní i negativní caching, umožňuje
notify –což je předání informací sekundárním DNS serverům o změně, replikaci primárního
serveru a autentizaci.
DNS dotaz – může být zodpovězen autoritativně i neautoritativně, pokud server nezná
odpověď obrátí se na root servery a potom postupuje směrem k subdoménám podle záznamů.
Může být vyžadován UDP checksum a odpověď může být omezena na velikost 512B.
Obsahem odpovědi je i doba platnosti (asi té odpovědi).
Kombinace služeb – integrace různých služeb v distribuovaném prostředí, kombinace
jmenné služby s portmapem (co to je?). DCE RPC, SUN RPC, JAVA RMI
Přednáška 9 – Bezpečnost v počítačových sítích
Osnova přenášky: základní pojmy, typy šífer, autentizace, integrita, distribuce klíčů,
firewally, typy útoků, zabezpečení aplikací
Základní pojmy síťové bezpečnosti: pro utajení přenášených dat se používá šifrování a
dešifrování, pro ověření totožnosti odesílaele a příjemce se používá autentizace, dále budeme
v předášce probírat integritu a neporiatelnost, dostupnost a řízení přístupu, detekci útoků a
reakce na ně.
Principy kryptografie – kryptovat se začalo už za Caesara, moderní techniky šifrování se
používají cca 30 let. Šifrovací algoritmus umožňuje odesilateli zašifrovat otevřený text (na
šifrovaný) a příjemci text rozšifrovat. Máme šifroací klíče – jeden pro šifrování (označme ho
KA) a jeden pro dešifrování (KB). Pokud K A = K B , pak je šifrování symetrické, pokud
K A ≠ K B , pak je šifrování asymetrické (klíč pro zašifrování může být veřejný). Označme
otevřený text jako m. Pak K A ( m ) je šifrovaný text a K B ( K A ( m ) ) je dešifrovaný (neboli opět
otevřený) text. Jak šifrování probíhá, je na slidu 6 – text se zašifruje, odešle šifrovaný a
příjemce ho rozšifruje.
Symetrické šifry – používají substituce (nahrazení písmenek) nebo transpozice (změna
pozice písmenek )
• Caesarova šifra – mějme klíč K=n, posuneme celou abecedu o n písmenek, takže
například slovo ahoj nám to při K=3 zašifruje jako dkrm...viz slidy. Logicky počet
klíčů je roven počtu písmen v abecedě – 1 (protože kdybychom to posunuli moc, jsme
zas tam, kde jsme byli).
• Monoalfabetické šifry – náhrada jednoho písmena abecedy jiným písmenem. Je 26!
klíčů. Na šifry tohoto typu lze aplikovat statistický útok.
• Polyalfabetické šifry – náhrada jednoho písmena abecedy různými písmeny – něco
jako Caesarova šifra s více možostmi nahrazení ... viz slide 7
• Transpozice – slide 8 – napíšeme si text do řádků a každý sloupeček označíme číslem
(ale pozor – na po řadě, ale zpřeházeně) – nyní čteme písmena podle čísel sloupců...ale
obrázek na slidu vydá za tisíc slov
• Data Encryption Standard – neboli DES, je to šifra která byla publikována v roce
1977. Má 56b symetrický klíč (+8b parita), byl to několikrát obnovený stadnard
(prodloužení klíče, triple DES), ale v současnosti je to slabá šifra. Její prolomení
trvalo v roce 1997 4 měsíce, ale v roce 1999 to bylo už jen 22 hodin. Proto byl v roce
2001 přijat nový standard AES (Advanced Encryption Standard) – kde jsou 128b,
192b nebo 256b klíče...více o DES je na slidu 10 a zde, o AES pak zde.
Asymetrické šifry – klíč na zašifrování a dešifrování je odlišný, existuje množství klíčů při
komunikaci různých subjektů. Je veřejný klíč (označme ho např. K B + ) – ten slouží k
zašifrování textu a je veřejně známý, a pak je privátní klíč (označme ho K B − ) - ten slouží k
dešifrování textu. Tyto klíče je složité vzájemně odvodit.
Platí rovnice: K B − ( K B + ( m ) ) = K B + ( K B − ( m ) ) = m . Jak je vidět na slidu 12, přenos probíhá
tak, že odesílael zašifruje text veřejným klíčem, a příjemce na přijatý text aplikuje svůj
privátní klíč.
RSA – je to algoritmus pro vytváření klíčů, název odvozen z příjmení jejich vynálezců (Ron
Rivest, Adi Shamir, Leonard Adleman). Princip je tento:
máme dvě prvočísla: p a q. (velikost cca 1024b a 768b).
Mějme čísla n = p ⋅ q ; z = ( p − 1) ⋅ ( q − 1) ; a číslo e, které je nesoudělné se z a menší než n
dále číslo d, kde musí plait, že ( ( e ⋅ d ) mod z = 1)
Pak platí K B + = ( n, e ) a K B − = ( n, d ) .
Algoritmus pro šifrování je c = m e mod n a pro dešifrování je m = c d mod n (kde m je
otevřený text a c je zašifrovaný text). Příklad na RSA je na slidu 14. Neděste se toho, první
tabulka je zašifrování – první sloupeček je původní text, druhý sloupeček je operace m e a třetí
sloupec je m e mod n . Analogicky probíhá dešifrování (druhá tabulka).
Autentizace – je to poskytnutí informace o identitě jednoho subjektu subjektu druhému.
Provádí se před použitím dalších protokolů a často se provádí oboustranně.
• Autentizační protokol 1.0 – pouze zadání jména (nebo nějaké jiné identifikace). Tento
je samozřejmě nedostatečný, taky se můžu představit jako někdo jiný, že...viz slide 16
•
•
•
•
•
Autentizační protokol 2.0 – kontrola uživatelského jména a IP adresy, ze které se
uživatel připojuje. Zde je ovšem možnost podvržení IP adresy
Autentizační protokol 3.0 – uživatel se přihlašuje jménem a heslem. Toto používají
například protokoly telnet nebo ftp. Zde je ovšem možnost heslo odposlechnout a
někdy ani zašifrování nepomůže.
Autentizační protokol 4.0 – to samé jako 3.0, ale pokaždé uživatel použije jiné heslo.
Zde ovšem musíme nějak pošéfovat to, jak hesla generovat tak, aby to bylo bezpečné,
protože, jak někdo na algoritmus generování příjde, tak jsme v pr...
Autentizační protokol 4.1 – uživatel zadá heslo, podle tohoto hesla se zašifruje výzva,
která se uživateli předá. Uživatel výzvu nějakým klíčem rozluští a odpoví na ni. Tento
protokol je bezpečný, ale je tu problém, jak uživateli předat klíče.
Autentizační protokol 5.0 –výzvu zašifrujeme asymetrickou šifrou (předpokládejme,
že uživateli jsme jeho privátní klíč předali už předtím), poté pošleme uživateli dotaz
na to, jaký je veřejný klíč? on nám odpoví a tím pádem můžeme přijatý text
rozšifrovat. Nojo, ale problémem je to, že hacker může mít svůj privátní i svůj veřejný
klíč – a pokud přijímá zprávy od uživatele (Alice) a tváří se jako server (Bob), je
prakticky nemožné jeho hrozbu odhalit. Jinak ještě u protokolu 5.0 je asymetrická
šifra, což je výpočetně složitější - dá se to obejít tak, že budeme mít symetrickou šifru
a klíč k ní bude jen dočasný (budeme ho po nějaké době měnit).
Integrita, digitální podpis – integrita je zaručení, že dokument nebyl změněn, dá se zaručit:
nepopiratelností – podpis zodpovědého subjektu , nebo nějakou doručenkou a nebo využitím
asymetrického šifrování
• podpis – buď šifrujeme celý dopis (zbytečně náročné) nebo hodíme na dopis nějaký
otisk (otisk se vytvoří, zašifruje (můžeme ho předtím ještě zahashovat), a dešifruje) –
po doručení dokumentu rozšifrujeme otisk a ten ověříme, jestli sedí. To jak to vypadá
je graficky znázorněno na sidech 27 a 28.
Distribuce klíčů – řešení je jak pro symetrické tak i pro asymetrické klíče.
• symetrické: KDS(Key Distribution Center – obrázek slide 30), Kerberos (každý
uživatel má vlastní klíč, kerberos přiděluje dočasné komunikační klíče)
• asymetrické: CA - Certification Authority – nejdříve se ověří uživatel dle nějakého
průkazu totožnosti a pak se mu vystaví certifikát podepsaný CA, jak to probíhá, je na
slidu 31.
Řízení přístupu – zamezení útočníkům v přístupu k prostředkům, je více možností, jak toho
dosáhnout :
• firewall – buď může být hardwarový nebo softwarový... obrázky (i když divné) jsou
na slidu 33 a 34
• zahazování,akceptace a forwardování paketů – na to máme paketové filtry (rozhodují
se podle obsahu paketu), kontextové filtry (rozhodují se podle kontextu spojení) a
aplikační brány (speciální aplikace – např. proxy)
Typy útoků :
• mapování(mapping) –první fáze útoku, kdy si hacker sbírá informace (pomocí pingu,
scanování portů). Je to dobrý předpoklad pro DDoS (viz dále co to je)
• odposlouchávání – to je snad jasné, co to je, odposlouchává na síti např. hesla a tak
•
•
•
•
podvrhnutí (spoofing)- je to podvrhnutí zdrojové IP adresy, ale dá se to poměrně
jednoduše omezit pomocí firewallu.
DoS (Denial of Service) – omezení dostupnosti služby pro legitimní uživatele. Tento
útok využívá chyby nebo přetížení
DDoS (Distributed DoS) – je to velmi nebezpečná varianta DoS, téměř bez možnosti
ochrany.
únos spojení (hijacking) – možnost ukradení spojení navázaného někým jiným.
Nicméně šifrování tento problém řeší.
Zabezpečení aplikací:
• aplikační vrstva – zabezpečení souboru např. pomocí PGP
• transportní vrstva – zabezpečení spoje, např. pomocí SSL (Secure Socket Layer)
• síťová vrstva – zabezpečení mezi dvěma uzly, např. pomocí IPsec
• linková vrstva – zabezpečení linky, např. pomocí šifrování modemů
Šifrování může probíhat na libovolné vrstvě, nižší vrstvy pak šifrují hlavičky vyšších vrstev.
Přednáška 10 – IPv6
Obsah přednášky – historie, motivace, formát datagramu, adresace, objevování sousedů,
automatická konfigurace, IPsec, mobilita
Historie a požadavky – počátkem 90, let se objevila studie o vyčerpání adres IPv4 do 10 let,
1995 vznikl IPv6, poté pomalu pronikal do praxe. Požadavky na tento protokol byly: větší
adresní prostor, zvýšení bezpečnosti, QoS, automatická konfigurace a mobilita.
Formát datagramu IPv6 – IP-datagram verze 6 se skládá ze čtyřicet bajtů dlouhého
základního záhlaví následovaného rozšířeními. Čtyřicet bajtů základního záhlaví se může zdát
hodně, ale je třeba si uvědomit, že jen IP-adresy odesílatele a příjemce zaberou 32 bajtů.
Struktura základního záhlaví je zobrazena na obr.
účelem struktury bylo minimalizovat položky a udržet konstantní délku hlavičky. Bylo
odstranění přepočítávání kontrolího součtu (ponecháno na nižší vrstvě), délka hlavičky (je
vždy stejná), rozšiřující volby a fragmentace (přesunuta do dalších hlaviček) . Volitelné
položky jsou umístěny do samostatných hlaviček. Zpracování datagramu je tedy
zjednodušeno.
Takže co tedy zbylo vlastně v té hlavičce?
• verze protokolu (ta je samozřejmě 6)
• třída dat resp. - podpora pro QoS – skládá se ze 4 bitů, tzn. nabývá hodnoty 0-15Hodnoty 0-7 jsou určený pro klasický provoz (0-nespecifikovaná data, 1-provoz na
pozadí (např. news), 1-automatický provoz (např. mail), 4 – velké přenosy dat (např.
ftp ,...))
Hodnoty 8 – 15 jsou určeny pro přenosy v reálném čase (např. audio). Datagramy s
nižší hodnotou (to však platí jen pro interval 8-15) si přeje uživatel zahodit dříve než
datagramy s vyšší hodnotou.
specifikuje přenášená data pro případ rozhodování v okamžiku zahlcení sítě.
• identifikace toku dat – toto je naprosto neotřelá myšlenka. Spolu s adresou odesílatele
se jednoznačně identifikuje dílčí tok dat v internetu. Doposud se směrování provádělo
pouze na základě adresy příjemce. Nevýhodou směrování v intenetu je, že jednotlivé
IP datagramy se dopravují samostatně, tj. pokud Internetem prochází tok IP datagramů
mezi 2 aplikacemi, pak směrovače na cestě řeší směrování pro každý datagram
samostatně. Prostě pokud posíláme megabajty dat a během přenosu nedojde ke změně
v topologii sítě, pak směrovače po cestě řeší tu samou úlohu s tím samým výsledkem
pro tisíce datagramů. Myšlenka spočívá v tom, že datagramy jednoho toku dostanou
svou identifikaci. Pak stačí, aby směrovač vyřešil úlohu (do kterého rozhraní datagram
předat) pro první datagram toku a do paměti si poznamenal výsledek. Pro další
datagram nejprve prohlédne pamě; a pokud by tam nenašel poznamenaný tok, tak řeší
úlohu směrování. Další datagramy stejného toku pak bude předávat do stejného
rozhraní aniž by řešil úlohu směrování – pouze na základě údajů v paměti. Položka v
paměti směrovače nesmí zůstat déle než 6 vteřin. Nebezpečí číhá totiž v tom, že
odesílatel resetuje svůj počítač. Zavede znovu operační systém a shodou okolností
vygeneruje stejnou identifikaci pro jiný tok. Nepředpokládá se, že by uživatel stihl
provést reset počítače do 6 vteřin. Jinou možností je využít identifikaci toku dat k
zajištění šířky přenášeného pásma. Směrovače na cestě od odesílatele k příjemci se
nakonfigurují tak, aby pro datový tok o jisté identifikaci zajišťovaly určitou šířku
pásma. Datagramy docházejí na směrovač, kde se umísťují do vyrovnávací paměti. Za
normálních okolností se jedná o frontu datagramů, která z jednoho konce přibývá a z
druhého konce se datagramy odebírají (odesílají). Směrovač však nemusí frontu
zpracovávat sekvenčně, ale může přednostně vybírat datagramy tak, aby zajistil
dohodnutou šíři pásma. V tomto případě pochopitelně nelze hrát na šestivteřinový
limit.
• délka dat (počet bytů za hlavičkou) – specifikuje délku IP datagramu bez základního
záhlaví (to má totiž délku vždy stejnou – 40B). Jelikož je toto pole dlouhé 2B, tak
největší délka přenášeného IP datagramu je 65535B. Je však možné použít volbu
„ohromný datagram“ v další hlavičce, která umožňuje posílat ještě větší datagramy
(Jumbogramy)
• další hlavička – specifikuje typ následující (zřetězené) hlavičky. Následující hlavičky
mohou být například tyto:
•
Pouze typy, které jsou uvedeny tučně jsou součástí IP protokolu. Ostatní typy jsou
typy protokolů vyšších vrstev
dosah (počet hopů) toto poslední pole odpovídá položce TTL v IPv4
Řetězení hlaviček – viz slide 7 – Pole další hlavička v základním záhlaví ukazuje jaký typ dat
(“jaká hlavička”) následuje za základním záhlavím. Teoreticky může ukazovat již na TCP
segment nebo jiný protokol vyšší vrstvy. Avšak může také ukazovat na další rozšiřující
hlavičky IP-protokolu. Pokud ukazuje na další rozšiřující hlavičku, pak i tato hlavička má
pole „další hlavička”, která ukazuje na další hlavičku. Hlavičky tak tvoří řetězec. Řetězec
obsahuje jen ty hlavičky, které jsou nutné. Je to rozdíl od IP-protokolu verze 4, který ve svém
záhlaví často přenáší nadbytečné informace. Za polem další hlavička je pole délka hlavičky.
Pole délka hlavičky specifikuje posunutí jaké je třeba udělat k další hlavičce. Základní záhlaví
délku nemá, protože je dlouhé vždy 40 bajtů. Rovněž u záhlaví fragmentů se délka nepoužívá,
protože tato hlavička je vždy 8 bajtů dlouhá.
Dále popíšu některé typy dalších hlaviček:
• Informace pro směrovače –obsahuje jednotlivé informace (volby), které jsou určeny
pro směrovače přepravující datagram. Každý směrovač, který datagram předává se
musí těmito volbami zabývat. Volba se skládá z pole typ dlouhého 1 B, pole délka
dlouhého 1 B a pole obsahujícího vlastní volbu. Obrázek uvádí některé volby.
Pokud je volba délka rozsáhlého datagramu použita, pak délka datagramu v základním
záhlaví je nastavena na nulu a používá se délka uvedená v této volbě. Zatímco v
základním záhlaví jsou pro délku určeny 2 bajty (tj. datagram může být dlouhý až 64
KB), pak 4 bajty volby rozsáhlý datagram umožňují délku až 4 GB.
• směrovací informace - Hlavička směrovací informace používá tč. jedinou volbu
(Typ=0), kterou je explicitní směrování. Kdy odesílatel specifikuje IP-adresy
směrovačů, přes které má být datagram dopravován
• záhlaví fragmentu - Fragmentovat IP-datagramy verze 6 může pouze operační systém
na straně odesílatele. Směrovače, kterými datagram prochází na své cestě od
odesílatele k příjemci fragmentovat na rozdíl od IPv4 již nesmí. Jak vypadá tato
hlavička, je znázorněno na obrázku
Na rozdíl od IP-protokolu verze 4 neobsahuje každý IP-datagram (např. v základním
záhlaví) identifikaci IP-datagramu. Identifikace IP-datagramu je nutná pro
fragmentaci, aby příjemce zjistil, které fragmenty patří do stejného datagramu. V IPv6
je identifikace datagramu pouze v dalším záhlaví, tj. není součástí každého IPdatagramu.Pole posunutí od počátku datagramu slouží k sestavení datagramů. Pomocí
tohoto pole příjemce zjistí pořadí v jakém má fragmenty skládat za sebe. Pole posunutí
od počátku datagramu neudává posunutí v bajtech, ale v násobcích osmi bajtů (v
„osmibajtech”), proto se při fragmentaci musí zajistit, aby fragmenty byly odřezávány
v délce, která je dělitelná osmi.A konečně pole M (More Fragment) indikuje poslední
fragment. Jednobitové pole M je nastaveno na jedničku, pouze v případě posledního
fragmentu na nulu.
•
autentizační hlavička - Pomocí autentizační hlavičky odesílatel autentizuje data, tj.
prokazuje, že data odeslal on. Datagram je tak zabezpečen proti změně IP-datagramu
útočníkem i proti záměně celých IP-datagramů odesílatele za IP-datagramy vložené
útočníkem. Základní autentizace je za využití algoritmu MD-5 (RFC-1321) pro
výpočet kontrolního součtu.
•
bezpečnostní hlavička – umožňuje přenášená data šifrovat – musí to být poslední
přenášená hlavička datagramu, protože data jsou již dále šifrovaná, tj. nedostupná ke
zpracování směrovačům dopravujícím IP datagram.
Řetězení hlaviček je znázorněno na obrázku...
Fragmentace - Provádí se pouze u odesílatele, informace o fragmentaci je uložena v
rozšiřující hlavičce. Hlavičky až po tu fragmentační jsou nefragmentovatelné. Doporučené
MTU (Maximum Transfer Unit) pro IPv6 je 1280B. Vyhledávání MTU cesty se děje pomocí
ICMPv6 – nemusí se implementovat.
Jumbogramy – to budou asi nějaké ty velké datagramy:-). Jejich maximální délka je až 4GB.
Ale uzly s menším MTU nemusí Jumbogramy podporovat.
Pár slov o ICMPv6 - Podobně jako v případě IP-protokolu verze 4 se pro signalizaci chybových stavů a
pro diagnostiku v IPv6 používá protokol ICMP. Protokol ICMPv6 v mnoha případech přináší zcela odlišné
funkčnosti oproti protokolu ICMPv4. Řeší např. překlad IP-adres na linkové adresy. (Na tento
problém jsou v IPv4 určeny samostatné protokoly ARP a RARP. ) Z hlediska struktury paketu
se ICMP paket jeví jako protokol vyšší vrstvy, tj. je předcházen základním záhlavím IPprotokolu i případnými dalšími hlavičkami. Jinak ICMPv6 slouží samozřejmě pro diagnostiku
a signalizaci zpráv. Pokud by to někoho zaajímalo, tak tabulka různých typů ICMPv6 paketů
je v bibli na straně 207.
Adresace IPv6
Délka adresy je 128b, tedy 16 8-bitových polí (oproti IPv4, kde byly jen 4 pole –
147.32.113.229).
Rozeznáváme tři druhy adres:
• unicast – jednoznačná adresa síťového rozhraní
• anycast – adresa skupiny síťových rozhraní. IP datagram adresovaný adresou anycast
bude doručen jednomu z těchto rozhraní.
• multicast – neboli oběžník
• !Broadcast adresy nejsou podporovány!
Používají se různé zápisy IP adresy:
• normální zápis - např. FEDC:1234:0000:ABCD:0F12:0000:0000:4567 – vedoucí
nuly (to jsou nuly,kterými čtyřčíslí začíná) se uvádět nemusí, takže zápis této adresy
může vypadat např. FEDC:1234:0:ABCD: F12:0:0:4567
• zkrácený zápis pomocí zvolené dvojtečky – zvolená dvojtečka se může v adrese
vyskytovat pouze jednou a nahrazuje tam libovolné množství čtveřic null, např.
pokud máme adresu 1234:0:0:0:0:0:0:0:14, pak ji pomocí zvolené dvojteky můžeme
napsat jako 1234::14
Adresy sítí: viz obrázek...
Oběžníky resp. Skupinové adresy: Oběžníky mají prefix obsahující v prvním bajtu samé
binární jedničky, tj. šestnáctkově FF (viz obrázek).
Také viz slide 12 – koukni, kde se vyskytuje bit T – to udává, zda je oběžník přidělen trvale
(0), nebo jen dočasně (1). Dalším polem je rozsah (4b), to je, jak jsme si řekli něco jako TTL,
hodnoty dosahu: rozhraní (1), linka (2), podsíť (3), správa (4), místo (5), globální (E) – na
slidu 12 jsou ještě příklady pro adresy, ale myslím, že je to jasné.
Adresy rozhraní – uzel – má lokální linkovou adresu, loopback, individuální a výběrovou,
může být skupinová adresa pro všechny uzly, také skupinová pro skupiny, jichž je uzel
členem a také skupinová pro vyzývaný uzel. směrovač – má adresy jako uzel + navíc
skupinové pro všechny směrovače, výběrové pro směrovače v podsíti a také všechny
přidělené výběrové adresy.
Objevování sousedů - k tomuto slouží protokol, jež je rozšířenou náhradou ARP (vzpomeň
si na zjišťování MAC). Tento protokol využívá ICMPv6 pro výzvu směrovači, odhlášení
směrovače, výzvu sousedovi, ohlášení souseda, přesměrování.Tento protokol poskytuje:
zjišťování linkových adres v lokální síti, rychlou aktualizaci změn a neplatných položek,
hledání směrovačů, přesměrování, detekci duplikových adres, ověření dosažitelnosti sousedů
a zjišťování údajů pro automatickou konfiguraci.
Hledání linkové adresy: - pošleme výsvu sousedům pomocí skupinové adresy, posledních
24b necháme samé Fka – tam se doplní ty hledané linkové adresy (jestli to chápu správně).
Pokud se nám soused s linkovou adresou ohlásí, aktualizujeme si jeho adresu.
Automatická konfigurace – viz http://www.ipv6.cz/v6about/autokonf/
Jedním z požadavků na IPv6 je automatická konfigurace. Představa, že člověk jednoduše
připojí počítač k síti a bude mu fungovat síťování, aniž by kdokoli cokoli konfiguroval, je
velmi lákavá (a z pohledu správce sítě částečně děsivá).
stavovou konfiguraci obstarává DHCPv6, nevyužívá však broadcast (jak by taky, když je
zakázaný). DHCP unique identifier (DUID) je záznam, který jednoznačně identifikuje uzel je v něm obsažena linková adresa a čas, je přiděleno výrobcem. Identity Association je zázam
jednoznačně idenifikující rozhaní ... zbytek slidu nechápu (???)
bezestavovová konfigurace – nevyžaduje konfiguraci... Jejím základním pilířem je tak zvané
objevování sousedů (neighbor discovery). Základní myšlenka je celkem prostá: každý
směrovač v určitých intervalech rozesílá do sítí, k nimž je připojen, tak zvané ohlášení
směrovače. V něm jsou obsaženy základní informace - především prefixy adres dané sítě a
zda on sám může sloužit pro předávání paketů ven (jako implicitní směrovač, default
gateway).Z ohlášení směrovačů (o které může při startu aktivně požádat pomocí výzvy
směrovači) se počítač dozví, jaké adresy používá zdejší síť. K nim si doplní zbývající část
(typicky 64 bitů), která se jednoznačně generuje z jeho Ethernetové adresy. Tak získá platné
IPv6 adresy pro své rozhraní. Také si vytvoří seznam implicitních směrovačů, kterým bude
předávat pakety směřující mimo síť. Pokud je jich víc, zpočátku je prostě střídá a směrovací
tabulku si postupně vylepšuje na základě jejich upozornění (ICMP přesměrování), pokud
paket k určitému cíli poslal nevhodným směrovačem.Zní to dost dobře, přesto však má
bezstavová konfigurace dost velkou pihu krásy. Vůbec totiž neřeší otázku DNS. Počítač se z
ní nedozví adresy zdejších DNS serverů a jak již bylo řečeno, bez DNS se v IPv6 žije velmi
velmi těžko.
Bezpečnost – je povinná implementace IPsec, autentizace je prováděna pomocí
Authentication header, šifrování pomocí ESP (Encapsulating Security Payload). Při
transportním režimu se bezpečnostní hlavičky jednoduše vloží, při tunelujícím režimu se
datagram zabalí da datagramu s bezpečnostními hlavičkami.
Bezpečnostní asociace – Security Association (SA) – obsahuje informace potřebné pro
šifrované spojení –bezpečnostní protokol, šifrovací algoritmus, klíče, čítače, doba
životnosti... SA je jednosměrná a vytváří se ve dvojicích, pro AH (Authentication Header) i
ESP je jedna dvojice. Na jeden paket se vztahuje svazek SA.
Databáze bezpečnostní politiky – je to sada pravidel uplatňovaná na všechny pakety. Říká,
jestli pakety zahodit, zpracovat bez IPsec (tedy jen odeslat a přijmout) a nebo zpracovat s IP
sec (tehdy databáze vydá svazek SA). Tuto databázi můžeme buď nakonfigurovat manuálně
nebo automaticky pomocí ISAKMP
Authentication Header – složí pro autentizaci odesílatele, umožňuje ochranu proti
opakování. Postup je takový: Nejdříme vložíme AH hlavičku, potom vyplníme položky
(autentizační data se vyulují) a poté se autentizační data vypočtou.
Encapsulation Security Payload (ESP) - slouží k šifrování obsahu (i služby AH). Obsahem
ESP hlavičky jsou data a další hlavičky. Postup je takový: Umístění ESP hlavičky, vycpávky
a šifrování, vytvoření pořadového čísla, vytvoření autentizačních dat (je li požadována
autentizace a kontrola integrity), fragmentace až po šifrování.
Mobilita - pracuje na principu domácí adresy a domácího ageta (co to ku... je?)... obrázky
viz slide 25-28
Přednáška 11 – Síťová správa
Obsah přednášky : definice, historie, protokoly a příklady
Síťová správa podle ISO:
• správa výkonu (performance management) – reaktivní a proaktivní, měření výkonnosti
a zatížení
• správa konfigurací (cofiguration management) – monitorování síťové konfigurace
• správa účetní (accounting management) - monitorování využití sítě
• správa poruch a chyb(fault management) – detekce chyb, logování a oznámení
• správa bezpečnosti (security management) – nastavení a monitorování přístupu
Architektura správy – slide 4 v síti je jeden počítač připojen jako Agent a obsahuje databázi
správy sítě, kam se ukládají data
protokol SNMP
Simple Network Management Protocol je sada protokolů usnadňujících správu
komplexních IP sítí. V současné době tímto protokolem umí komunikovat nejrůznější sítové
prvky, ať už se jedná o servery, pracovní stanice, směrovače, switche, huby a další.
Administrátorům SNMP umožňuje sledovat výkon a provoz v síti, odhalit a řešit vzniklé
problémy. SNMP může být důležitým zdrojem dat při plánování rozvoje sítě...více zde
Představte si že chcete jednomu počítači manuálně nastavit směrovací tabulku. Použijete
příkaz route add – net...
Pokud ovšem nespravujeme jeden počítač, ale rozsáhlou síť počítačů, pak je velice náročné se
postupně přihlašovat na jednotlivé systémy a tam dávat příkaz route. Zpravidla máme k
dispozici manažerskou stanici a na všech aktivních prvcích sítě (počítače, směrovače, HUBy,
modemy, databáze atd.) běží SNMP agenti, kteří jsou k dispozici manažerské stanici.
Z manažerské stanice je možné provádět dotazy na nejrůznější parametry jednotlivých
systémů. Mj. je takovým parametrem i položka směrovací tabulky. Takže z manažerské
stanice můžeme vypisovat obsah směrovacích tabulek, ale i směrovací tabulky modifikovat.
Nesmíte si jen zmodifikovat směrovací tabulky tak, abyste ztratili spojeni s manažerskou
stanicí …
MIB – Management Information Base – je to databáze parametrů zařízení. Každé zařízení
takovouto databázi obsahuje. tato DB musí mít urč. jmennou strukturu ve formě
hierarchického stromu. Touto databází je určeno, jaké proměnné jakého typu spravuje tzv.
agent. Ten běží na každém zařízení a zpracovává zprávy od tzv. managera. Obsahem zprávy
může být požadavek na čtení nebo zápis dat, agent požadavky přijímá a výsledkem jeho
činnosti je nějaká odezva managerovi. Agent nemusí jen pasivně čekat na požadavky. Pokud
nastane určitá událost, dokáže o tom informovat managera pomocí tzv. TRAP zpráv. Na řídící
stanici běží manažer komunikující s jedním či více agenty. Jedná se vlastně o architekturu
klient-server, agent je serverem, manažer klientem. Zprávy mezi nimi jsou přenášeny
protokolem UDP, jenž byl zvolen pro svoji jednoduchost a vhodnost při komunikaci typu
žádost/odpověď, na níž je síťový management založen.
SNMP rozlišuje pouze pět typů zpráv:
•
•
•
•
•
get-request – žádost o nějakou hodnotu
get-next-request – žádost o další hodnotu v pořadí (použití při žádosti o pole dat)
get-response – odpověď na žádost
set-request – žádost o zápis hodnoty
trap – zpráva, kterou agent informuje managera o nějaké události
Model komunikace SNMP je na obrázku – podstatou SNMP je, jak od síťových zařízení
získat informace (parametry) a také možnost, jak tyto informace změnit.
Poslední verzí je verze 3. Model je takový, že máme nějaký „Uzel Správy“ – ten obsahuje
SNMP agenta a stavové a konfigurační informace. Tento „Uzel Správy“ pak komunikuje
pomocí SNMP služeb se „Stanicí správy“.
Management Information Base – slide 7 – nechápu, vysvětlit
SNMP služby – snmpget, snmpset, snmpgetnext, snmpgetbulk, trap, inform
RMON
Remote monitoring – viz zde – Jde o sledování stavu vzdálené sítě na dálku. Oproti SNMP
umožňuje mnohem lepší monitoring sítě, všelijakou historickou analýzu atd.Základní ideou
při návrhu RMON bylo mít inteligentního agenta, který je schopen co nejpodrobnějšího
monitorování síťového segmentu a uchovávání sesbíraných informací. Získané informace
(aktuální i historická data) z různých agentů lze pak prezentovat na centrální správcovské
konzole při minimální komunikační zátěži a zároveň minimální výpočetní zátěži konzoly.
Princip RMON - RMON standard definuje skupiny informací, které mohou být
monitorovány síťovým analyzátorem nebo sondou (agentem). RMON MIB (Management
Information Base) standard umožňuje vzdálené monitorování Ethernet i Token Ring
segmentů a to využitím již zavedeného protokolu SNMP. RMON je typickým příkladem
distribuovaného řešení. Stejně jako klasický SNMP model, i RMON model se skládá ze dvou
částí. Tou první je agent (sonda), která je umístěna na monitorovaném segmentu. Druhou částí
je správní aplikace, běžící na centrální konzole, v ideálním případě jako nadstavba základní
správní platformy. Pomocí této RMON aplikace můžeme zkonfigurovat agenta ke sběru
požadovaných informací, které jsou zasílány na centrální konzolu při vyžádání nebo při
výskytu definované události. Těchto agentů - sond může být rozmístěno v síti tolik, kolik má
síť segmentů. Samozřejmě u velkých sítí se tyto sondy umisťují strategicky jen na
nejdůležitější segmenty, případně podle potřeby na ty segmenty, kde se objevují nějaké
problémy.
Skupiny informací RMON, které mohou být monitorovány: statistic (monitoruje se
okamžitý provoz – byte, kolize, cyby), history – (dtto (??) ale historie), alarms (prahování
některých hodnot), hosts (přenosová statistika pro každý uzel), hosts top N (setříděná
statistika hosts), Traffic Matrix (monitoring vzájemné komunikace mezi uzly ), Filters ,
Packet Capture (Pakety pro další dekódování), Events (záznamy událostí)
RMON MIB – podobně jako v SNMP má i každé zařízení v RMON svou MIB (Management
Information Base)
Přednáška 12 – ukládání dat
Direct Attached Storage – je když...připojíme (např. k serveru nebo pracovní stanici) přímo
nějaké datové uložiště (datový sklad třeba...). Připojení může být realizováno např. přes SCSI
nebo opická vlákna.více zde
Network Attached Storage – uložiště dat (stanice s RAID poli např.) je k počítači připojeno
pomocí sítě rozhraní (klasický IP protokol) a tak poskytuje centralizovaný datový sklad pro
různé klienty. Počítači se disky jeví jako dálkově připojené.K přístupu k datům používá
(narozdíl od SAN) dobře známé protokoly. více zde
Storage Area Network – je to vlastní síť datových uložišť, je připojena k serveru nebo
pracovní stanici např. přes SCSI nebo přes Fibre Channel. Tato datová uložiště se pak v
počítači jeví jako lokálně připojené disky. Proto může např. server ze SANu klidně
nabootovat. více zde
iSCSI (SCSI over IP) Attached Storage – je to nějaký datový sklad připojený k síti IP přes
iSCSI protokol – to je protokol transportní vrstvy, který umožňuje využívat SCSI přes síť
TCP/IP. více zde
LAN – NAS (SAN) – jak lze vidět na slidech, NAS i SAN může být připojeno k počítačům
pomocí sítě LAN.
Přenos dat – jak je vidět, Direct Attached Storage a SAN se v architektuře datových skladů
nijak neliší, ale rozdíl je v přenosu dat. U DAS se přenáší přímo přes SCSI sběrnici, u SAN
přes síť SAN a u iSCSI a stejně tak u NAS přes TCP/IP síť.
Protokoly pro přenos dat
Fibre channel – je to síťová technologie (gigabitová rychlost) pro přenos dat z datových
skladů po síti. I když název je Fibre Channel, tato technologie dokáže pracovat jak přes
optická vlákna,tak přes kroucenou dvojlinku. Topologie může být buď Point to Point (dvě
zařízení jsou propojeny spolu – viz zde) nebo Arbitrated Loop(zařízení jsou propojeny ve
smyčkách – viz zde) nebo Switched Fabric (všechny zařízení i smyčky jsou připojeny k
nějakým switchům – viz zde ). Propustnost Fibre Channel může být od 200 do 4800 MB/s
(wow!) a fibre channel podporuje řízení toku. Struktura paketu (rámce) fibre channel je na
slidu 10
iSCSI – je to protokol pro přenos SCSI příkazů přes síť TCP/IP, je to protokol transportní
vrstvy (tedy přenos SCSI příkazů přes TCP), HyperSCSI je protokol podobný iSCSI až na to,
že kašle na rodinu TCP/IP a pracuje přes Ethernet, proto se např. nemusí zabývat segmentací
a sestavením, díky tomu je rychlejší, ale nemá takovou flexibilitu pro IP sítě. Jak vypadá
rámec obsahující iSCSI je vyobrazeno na slidu 11.
Fibre Channel over IP – umožňuje přenos Fibre Channel paketů přes IP protokol, využívá k
tomu opět protokol TCP, takže je to v podstatě něc jako iSCSI. Využívá tunelování (???) pro
přenos FC informací přes IP sítě. Rámec obsahující FCIP je na slidu 12. FCIP je dobrý pro
Point to Point komunikaci mezi síti SAN (viz slide 14)
Internet Fibre Channel Protocol (iFCP)- pro přenos FC informací využívá ne tunelování,
ale směrování, propojuje různé SAN struktury (slide 14)
ATA over ethernet – je to síťový protokol, který dává možost si vytvořit levné sítě SAN,
Protože funguje přes Ethernet,nezávisí na technologiích vyšších vrstev (IP,UDP,TCP...) –
prostě se ATA příkazy vkládají přímo do ethernetových rámců. Proto to nejde nijak směrovat
(není tam totiž IP paket, ale pouze Ethernet)
Další technologie – IPv4, IPv6, ARP over FC.
Přednáška 12 – IDS
Intrusion Detection System – je to systém, který detekuje nechtěné manipulace s počítačem
skrz internet. Používá se k detekování rozličných hrozeb, které nedokáže detekovat firewall
(toto zahrnuje síťové útoky proti zranitelným služám nebo nějaký malware (viry, trojany,
červy...)). Jsou různé typy IDS
• :network IDS - NIDS – je položen na strategickém bodě (bodech) v síti, aby
monitoroval traffic, který přez něj jde a podel toho odchytávat pakety. To je sice
hezké, ale může to docela omezit propustnost sítě . Příkladem Network IDS je třeba
Snort – Open source program.
• host based - prostě na hostitelském kompu je spuštěn nějaký soft, který identifikuje
útoky na systém tak, že analyzuje systémová volání, modifikace souborového
systému, příchozí data... – prostě nějaký takový antivir
• sinature based - monitoruje pakety na síti a porovnává je s databází (vzpomeň na
NOD signature database) údajů, Problém je, že když je objevena nějaká nová
hrozba,nějaky čas to trvá, než se zanese do databáze -
•
anomaly based (IDS monitoruje traffic a porovnává ho s „baseline“, což jsou vlastně
informace, co by měl normálně traffic obsahovat, jaké protokoly a porty by se měly
normálně využívat. Tyto informace jsou získávány nějakou heuristikou sítě Pokud se
v trafficu vyskytne nějaká anomálie, IDS informuje admina )
• honeypot – podle překladu je to hrnec s medem, je to tedy nějaké lákadlo pro
nebezpečné útočníky, jejich útoky směřuje na sebe, čímž je odvrací od ostatních
(cenných) počítačů a navíc tyto útoky může analyzovat a tak sesbírat informace.
Komponenty IDS: sensory – generují bezpečnostní události, console – monitorují události,
informují o hrozbách a ovládají sensory, Central Engine – ukládá záznamy o událostech
(zachycené sensory) do databáze a reaguje na bezpečnostní události.
Chyby IDS mohou být buď false positives (zbytečný poplach) nebo false negatives
(nezachycený útok)
Pasivní x reaktivní IDS – pasivní IDS pouze detekuje hrozby a upozorní na ně, kdežto
reaktivní IDS (známý jako IPS, resp. Intrusion Prevention System) dělá nejen to, co pasivní,
ale také provádí nějaká opatření proti hrozbám (blokuje je)
Intrusion Prevention System – je to považováno za takové rozšíření IDS. Výhodou oproti
IDS je to, že dokáží v reálném čase reagovat na hrozby (odvrátit je). Většina IPS systémů je
schopná sledovat protokoly 7 vrstvy (aplikační), jako jsou HTTP,FTP a SMTP, kteréžto
představují největší nebezpečí. Možnosti realizace IPS jsou L7 switch, aplikační firewall +
IDS, hybrid switch, inline NIDS.