TCPIP Alapok-#1 MS PDF

Windows Server 2008
TCP/IP
Alapok
I. ktet
V2.1
Petrnyi Jzsef
2009, Petrnyi Jzsef

2.1 verzi, azaz harmadik kiads
Minden jog fenntartva.
A knyv rsa sorn a szerz s a kiad a legnagyobb gondossggal s
krltekintssel igyekezett eljrni. Ennek ellenre elfordulhat, hogy nmely
informci nem pontos vagy teljes, esetleg elavultt vlt.
Az algoritmusokat s mdszereket mindenki csak sajt felelssgre alkalmazza.
Felhasznls eltt prblja ki s dntse el sajt maga, hogy megfelel-e a cljainak. A
knyvben foglalt informcik felhasznlsbl fakad esetleges krokrt sem a
szerz, sem a kiad nem vonhat felelssgre.
A cgekkel, termkekkel, honlapokkal kapcsolatos listk, hibk s pldk kizrlag
oktatsi jelleggel kerlnek bemutatsra, kedvez vagy kedveztlen kvetkeztetsek
nlkl.
Az oldalakon elfordul mrka- valamint kereskedelmi vdjegyek bejegyzjk
tulajdonban llnak.
Microsoft Magyarorszg
2010
Ksznetnyilvnts:
Habr a knyv megrshoz meglehetsen sok forrst hasznltam fel, de kln
szeretnk ksznetet mondani Joseph Davies-nek (Cable Guy), akinek rsai,
knyvei a leginkbb hatottak a szemlletemre, az elkpzelseimre.
Emellett meglepen sok hasznos informcit kaptam a Wikipedibl is. Lehet,
hogy politikai terleten hasznlhatatlan, de alap informatikai ismeretekben
ers.
"- Akkor beszljnk nyltan. Nem hinyzik magnak valami?

Tt gondolkozott.
- Csak a meggyfa szipkm - mondta aztn. - De majd faragok msikat.
- Nem trgyi rtelemben gondoltam. n a tevkenysg hinynak kros
kvetkezmnyeire cloztam.
Tt megzavarodott. A felesgre nzett, aki azonban szintn vrakoz kifejezssel
nzett vissza r, mintha tle vrn a magyarzatot.
- Ltom, nem rtik - llaptotta meg Varr rnagy. - Nzzk, Ttk. Egy stt szobban
a legkisebb zaj is megsokszorozdva hangzik. Nomrmost, a semmittevs gy hat a
szervezetre, mint a sttsg a hallszervekre. Felersti a bels neszeket, kprzatokat
okoz a ltmezn, zakatolst idz el az agyban. A katonimmal, ha nincs semmilyen
elfoglaltsguk, mindig levgatom s visszavarratom a nadrggombjaikat. Ettl
tkletesen megnyugszanak. Remlem, rtik, mit akarok mondani?
Ttk sszenztek, mg tancstalanabbul, mint az elbb. Nmi habozs utn Mariska
megjegyezte:
- Ha a mlyen tisztelt rnagy rnak le vannak szakadva a gombjai, azokat szvesen
felvarrom.
- Maguk teljesen flremagyarzzk a szavaimat - legyintett az rnagy elgedetlenl. Legalbb azt mondjk meg, van-e vletlenl egy darab cukorsprga a hznl, ami jl
ssze van gubancoldva.
- Az biztosan akad - derlt fl Mariska. - Mirt van r szksge a mlyen tisztelt rnagy
rnak?
- Mert ki akarom bogozni! - mondta a vendg idegesen. - n nem brok olyan ttlenl
lni, mint maguk.
- Ht mirt nem tetszik szlni? - kiltott fl cseng hangjn gika, aki - nem elszr jobban tltott a helyzeten, mint a felnttek. - Hiszen mi ketten, az anyu meg n,
sohasem szoktunk lbe tett kzzel lni.
- Ht mit csinlnak?
- Ilyenkor estefel, amikor nincs jobb dolgunk, dobozokat szoktunk hajtogatni.
Az rnagy szeme flcsillant.
- Dobozokat? - ismtelte. - Roppant rdekes! - kiltott fl. - Mifle dobozokrl van sz?"
rkny Istvn: Ttk
TARTALOMJEGYZK
1
Tanulj velem! ________________________________________________________________________ 10
Alapozs _____________________________________________________________________________ 12
2.1
Hfehrke s a ht rteg _______________________________________________________ 12
2.2
Fogalmak ________________________________________________________________________ 16
2.2.1
Szabvnyok _________________________________________________________________ 16
2.2.2
Kinek szl az zenet? ______________________________________________________ 17
2.2.3
Host vs node________________________________________________________________ 17
2.2.4
Subnet vs link ______________________________________________________________ 18
2.2.5
Azok a frnya dobozok ____________________________________________________ 19
2.2.6
Hlzati eszkzk __________________________________________________________ 21
2.2.6.1
Hub _____________________________________________________________________ 21
2.2.6.2
Switch __________________________________________________________________ 21
2.2.6.3
Bridge __________________________________________________________________ 21
2.2.6.4
Gateway _______________________________________________________________ 21
2.2.6.5
Router _________________________________________________________________ 21
A hlzati eszkz rteg protokolljai _______________________________________________ 22

3.1
LAN technolgik _______________________________________________________________ 23
3.1.1
Ethernet ____________________________________________________________________ 25
3.1.1.1
Ethernet II _____________________________________________________________ 26
3.1.1.2
Ethernet 802.3 ________________________________________________________ 32
3.1.1.3
Ethernet 802.3 SNAP _________________________________________________ 34
3.1.2
Token Ring: IEEE802.5 s IEEE 802.5 SNAP ____________________________ 36
3.1.3
Fiber Distributed Data Interface: FDDI __________________________________ 41
3.1.4
IEEE 802.11, azaz WIFI ____________________________________________________ 44
3.1.5
Alrteg protokollok: LLC s MAC _________________________________________ 47
3.2
Address Resolution Protocol, ARP ____________________________________________ 48
3.2.1
ARP nvfelolds ____________________________________________________________ 53
3.2.2
Dupliklt cm meghatrozs ______________________________________________ 56
3.2.3
Fekete lyuk detektlsa ___________________________________________________ 58
3.2.4
3.3
WAN technolgik ______________________________________________________________ 63
3.3.1
Point To Point Protocol, PPP ______________________________________________ 63
3.3.1.1
PPP konfigurls LCP-vel ____________________________________________ 67
3.3.1.2
PPP Autentikci______________________________________________________ 71
3.3.1.3
Visszahvs ____________________________________________________________ 87
3.3.1.4
Protokoll belltsok NCP-vel ________________________________________ 88
3.3.1.5
PPP over Ethernet ____________________________________________________ 92
3.3.2
4
Inverse ARP, Reverse ARP, Proxy ARP ___________________________________ 60
NBMA: Frame Relay _______________________________________________________ 95
Az internet rteg protokolljai ______________________________________________________ 96

4.1
IPv4 ______________________________________________________________________________ 97
4.1.1
Az IP Header _______________________________________________________________ 97
4.1.1.1
Tredezettsg ________________________________________________________ 103
4.1.1.2
IP Options ____________________________________________________________ 107
4.1.2
let a hatron: Route, NAT, Proxy _______________________________________ 116
4.1.2.1
Az IP cm ______________________________________________________________ 117
4.1.2.2
Route __________________________________________________________________ 121
4.1.2.3
RIP ____________________________________________________________________ 129
4.1.2.4
OSPF __________________________________________________________________ 130
4.1.2.5
NAT ___________________________________________________________________ 131
4.1.2.6
Proxy __________________________________________________________________ 134
4.1.3
ICMP, azaz a PING s a haverok __________________________________________ 135
4.1.3.1
ICMP Echo Request & Reply ________________________________________ 137
4.1.3.2
ICMP Destination Unreachable _____________________________________ 140
4.1.3.3
ICMP Source Quench ________________________________________________ 149
4.1.3.4
ICMP Redirect ________________________________________________________ 150
4.1.3.5
ICMP Router Discovery ______________________________________________ 153
4.1.3.6
ICMP Time Exceeded ________________________________________________ 157
4.1.3.7
ICMP Parameter Problem ___________________________________________ 158
4.1.3.8
ICMP Address Mask Request & Reply ______________________________ 159
4.1.4
IGMP, azaz egy kis Multicast _____________________________________________ 160
4.1.4.1
Egy szerver kldeni akar ____________________________________________ 166
4.2
4.1.4.2
Egy kliens fogadni akar ______________________________________________ 167
4.1.4.3
A router, aki sszehozza a feleket __________________________________ 168
4.1.4.4
IGMP v1 _______________________________________________________________ 169
4.1.4.5
IGMP v2 _______________________________________________________________ 171
4.1.4.6
IGMP v3 _______________________________________________________________ 174
IPv6 _____________________________________________________________________________ 179
4.2.1
4.2.1.1
Unicast cmek ________________________________________________________ 184
4.2.1.2
Multicast cmek ______________________________________________________ 190
4.2.1.3
Az IPv6 Csomag ______________________________________________________ 196
4.2.1.4
Neighbor Discovery, ND _____________________________________________ 206
4.2.1.5
Multicast Listener Discovery (MLD) _______________________________ 209
4.2.1.6
Autokonfigurci ____________________________________________________ 211
4.2.2
Alapok _____________________________________________________________________ 181
IPv4 -> IPv6 konverzik __________________________________________________ 213
4.2.2.1
Intra-Site Automatic Tunnel Addressing Protocol, ISATAP ______ 221
4.2.2.2
6TO4 __________________________________________________________________ 222
4.2.2.3
TEREDO ______________________________________________________________ 223
A szlltsi rteg protokolljai ______________________________________________________ 227

5.1
User Datagram Protocol - UDP _______________________________________________ 227
5.2
Transmission Control Protocol - TCP ________________________________________ 232
5.2.1
A Sequence Number s az Acknowledgment Number pingpongcsata 244
5.2.1.1
1. lps: SYN __________________________________________________________ 244
5.2.1.2
2. lps: SYN-ACK ____________________________________________________ 247
5.2.1.3
3. lps: ACK__________________________________________________________ 249
5.2.1.4
4. lps: GET __________________________________________________________ 250
5.2.1.5
5. lps: ACK__________________________________________________________ 252
5.2.1.6
6. lps: HTTP ________________________________________________________ 254
5.2.1.7
7. lps: FIN-ACK ____________________________________________________ 257
5.2.1.8
8. lps: ACK-FIN ____________________________________________________ 258
5.2.1.9
9. lps: ACK__________________________________________________________ 259
5.2.2
TCP Options _______________________________________________________________ 261
5.2.2.1
End Of Option List s No Operation ________________________________ 261
5.2.2.2
Maximum Segment Size Option _____________________________________ 262
5.2.2.3
TCP Window Scale Option __________________________________________ 263
5.2.2.4
Selective Acknowledgment (SACK) Option ________________________ 264
5.2.2.5
TCP Timestamps Option_____________________________________________ 265
5.2.2.6
Pldk _________________________________________________________________ 266
5.2.3
TCP flag-ek ________________________________________________________________ 269
5.2.4
TCP kapcsolatok kezelse ________________________________________________ 271
5.2.4.1
Egy TCP kapcsolat kialakulsa ______________________________________ 271
5.2.4.2
Egy TCP kapcsolat fenntartsa ______________________________________ 272
5.2.4.3
Egy TCP kapcsolat felbomlsa ______________________________________ 273
5.2.4.4
A TCP kapcsolatok llapotai ________________________________________ 275
5.2.5
5.2.5.1
Send Window ________________________________________________________ 277
5.2.5.2
Receive Window _____________________________________________________ 279
5.2.6
TCP adatfolyam ___________________________________________________________ 277
Az jrakldsek rendszere _______________________________________________ 281
5.2.6.1
Slow Start algoritmus ________________________________________________ 283
5.2.6.2
Congestion Avoidence algoritmus __________________________________ 284
5.2.6.3
Az jraklds llektana______________________________________________ 284
5.2.6.4
Dead Gateway felismers ___________________________________________ 284
5.2.6.5
Forward RTO-Recovery (F-RTO) ___________________________________ 285
5.2.6.6
Selective Acknowledgement (SACK) _______________________________ 286
5.2.6.7
Karn algoritmus ______________________________________________________ 286
5.2.6.8
Fast Retransmit ______________________________________________________ 286
Az alkalmazs rteg protokolljai, szolgltatsok ________________________________ 289

6.1
Dynamic Host Configuration Protocol (DHCP) ______________________________ 291
6.1.1
Csomagszerkezet _________________________________________________________ 293
6.1.2
DHCP Options _____________________________________________________________ 296
6.1.3
DHCP folyamatok _________________________________________________________ 298
6.1.3.1
Egy normlis cmbrls nylbetse _______________________________ 298
6.1.3.2
Egy cm elengedse __________________________________________________ 307
6.1.3.3
Renew s Rebuild ____________________________________________________ 308
6.1.3.4
Subnet vlts _________________________________________________________ 310
6.1.4
6.2
DHCP v6 ___________________________________________________________________ 311
Domain Name System (DNS) _________________________________________________ 315
6.2.1
DNS Name Query Request s Name Query Response zenetek _______ 316
6.2.1.1
DNS Query Header ___________________________________________________ 317
6.2.1.2
Query Question Entries______________________________________________ 320
6.2.1.3
Query Erforrs rekordok __________________________________________ 322
6.2.2
DNS Update s Update Response zenetek _____________________________ 325
6.2.2.1
DNS Update s Update Response header __________________________ 326
6.2.2.2
Update Zone Entries mez __________________________________________ 328
6.2.2.3
Update Erforrs rekordok _________________________________________ 329
6.2.3
DNS folyamatok ___________________________________________________________ 330
6.2.3.1
Nvfelolds ___________________________________________________________ 330
6.2.3.2
Reverz nvfelolds ___________________________________________________ 334
6.2.3.3
Hogyan csinljunk hlyt magunkbl? _____________________________ 336
6.2.4
DNS az IPv6-ban __________________________________________________________ 341
Kivezets ____________________________________________________________________________ 343
Forrsok, linkek ____________________________________________________________________ 344
Javtsok ____________________________________________________________________________ 348

9.1
2.1 verzi, 2011 prilis ________________________________________________________ 348
9.2
2.0 verzi, 2010 mrcius ______________________________________________________ 348
9.3
1.1 verzi, 2009 december ____________________________________________________ 349
10 A szerz _____________________________________________________________________________ 351
A TCP/IP PROTOKOLL MKDSE
1 T ANULJ VELEM !
Rendhagy knyv lesz1. Pldul rgtn itt az elejn el fogom rulni, hogy nem
vagyok m olyan nagy felkent tudora a tmnak. Nyilvn az alatt a hsz v alatt,
amita informatikval foglalkozom, ragadt rm ez meg az - de annyira mlyen, mint
ahogy most tervezem, sohasem merltem mg el a hlzatok mkdseinek
rejtelmeibe.
Pedig megrn.
Manapsg ezen mlik minden. Ma mr gy nznk egy hlzati krtya nlkli gpre,
mint gyerekeink a szdsszifonra. (Jrtl mr gy, hogy opercis rendszert
teleptettl s az nem ismerte fel a gpedben lv hlzati krtykat? Idegtp
kinldsok szoktak ilyenkor kvetkezni, amg pendrive-on valahogy fel nem
varzsolod a hlzati krtya drivert.)
Persze, ami egyfell knyelem, az a msik oldalrl tmrdek inkompatibilts, a
harmadik oldalrl rengeteg meghibsodsi lehetsg, a negyedik oldalrl pedig
veszly. Ha n hozzfrek a drton keresztl, akkor ms is. Ezzel pedig bele is
mentnk a hlzati biztonsg tmakrbe... abba, mellyel ez a knyv nem fog
foglalkozni. Meg gy egyltaln, ez az rs nem fog tlzottan foglalkozni semmilyen
rintleges egyb terlettel sem. Mg az is lehet, hogy IP cm sem lesz benne2.
Hogyan kell konfigurlni egy DHCP vagy egy DNS szervert? Rengeteg knyv,
whitepaper foglalkozik vele. Keresd meg, olvasd el.
Ebben a knyvben mi leginkbb csomagokat fogunk kinyitni, megvizsglni. Meg
csomagokba rejtett csomagokat. Meg azokba csomagolt csomagokat. Meg... ugye,
rthet a mintzat?
Gondolom, ijeszten hangzik. Tny, hogy a vilg egyik legunalmasabb dolga az RFC-k
olvasgatsa.
Itt jvk be a kpbe n. Egyfell kifejezetten fontosnak tartom, hogy aki
informatikval foglalkozik, tisztban legyen az alapokkal. Ne kezdjen el vakarzni,
ha a Network Monitort kell hasznlnia. Msfell tudatban vagyok annak, hogy
nlam is vannak fehr foltok. Azt is tudom, hogy tanulni gy tudok a legjobban, ha
feldolgozom az anyagot, megemsztem, majd elmagyarzom. Ez fog trtnni ebben a
knyvben: egytt fogunk haladni elre, egyre tbbet s tbbet megrtve a dobozols
rejtelmeibl. Harmadrszt pedig szeretem a kihvsokat: kivncsi vagyok, sikerl-e
egy ilyen szraz, hivatalos szveget szrakoztatv tennem?
1
2
n mr gy ltszik minden szakknyvemet ezzel a mondattal fogom kezdeni. (-:

Ok, ez mr tnyleg tlzs.
~ 10 ~
TANULJ VELEM!
Lthat, ez egy integratv knyv lesz. Krbebstyztam magam szakknyvekkel,
elttem van az internet hatalmas informcitmege - s hol innen, hol onnan szedek
majd el valami darabot. Aztn ezekbl az infotglkbl fog felplni a hz.
n adom a maltert.
Egy nagyon fontos megjegyzs. Magyar nyelv szakknyvek esetn a szerzk mindig
problmzni szoktak rajta, hogy lefordtsk-e magyarra a szakszavakat, vagy
hasznljk az angol eredetiket? n gy vgom t ezt a gordiuszi csomt, hogy
deklarlom: a knyv nyelve se nem magyar, se nem angol. Hunglish.
Ebben az orszgban az informatikusok gyis ezt a nyelvet beszlik.
Vgl mg egy megjegyzs. Habr az a clom, hogy egy nehznek tartott terletet
knnyebben fogyaszthatv tegyek, de ez nem jelenti azt, hogy mindent a
legvgskig szjbargsan fogok elmagyarzni. Lesznek fogalmak pldul, melyeket
eleve ismertnek fogok felttelezni. Ergo a m lvezethez legalbb flmveltnek kell
lenni.
Jut eszembe. A knyv tbb helyen is egyfajta fejldsregny. Azaz bevezetek egy
fogalmat - valahogy. Megrtjk. Hasznljuk. Aztn pr oldallal ksbb kiderl, hogy
az a bizonyos fogalom jval bonyolultabb, s olyan formban, ahogy addig n
hasznltam, valjban nem is mkdhetne. Viszont ha gy vezettem volna be elsre,
ahogy valjban kinz, akkor tl bonyolult lett volna megrteni. Termszetesen
ezekre a csalafintasgokra menetkzben fny derl - de ha csak gy felcsapod a
knyvet s beleolvasol, lehet, hogy gnek ll a hajad.
Mindenesetre nem lesz stagalopp: papr, ceruza, szmolgp legyen a kzeledben.
Jelen ktethez tartozik egy msodik ktet, illetve egy 50 oldalas sszefoglal fzet is.
A teljes csomagot innen tudod letlteni:
http://mivanvelem.hu/letoltheto-konyvek/
~ 11 ~
2 A LAPOZS
2.1 H FEHRKE
S A HT R TEG
Azaz ne mondj a kereskedknek semmit.

De ne szaladjunk ennyire elre.
A normlis hlzati kommunikci egyltaln nem olyan egyszer dolog, mint
gondolnnk. Tbb rszfeladatot kell benne megoldanunk, radsul ezeknek egytt is
kell mkdnik. Tekintve, hogy gyrt mint gen a csillag, a feladat szabvnyosts
utn kiltott. Az Open System Interconnection (OSI) szervezet volt az, aki erre a
nemes feladatra vllalkozott. gy kpzeltk el, hogy a hlzati kommunikcit
rtegekre bontjk, ezen bell pontosan definiljk az egyes rtegek feladatt, illetve
a rtegek peremn zajl kommunikcit. A tbbi meg mr a gyrtk dolga.
A vgeredmny egy olyan rendszer lett, mely kt modellbl llt ssze:
Egyrszt kialakult a 7 rtegbl ll struktra.
Msrszt definiltk az egyes rsztevkenysgeket ellt protokollokat.
A felsorols fentrl lefel fog haladni, hiszen gy alakul majd ki a valsgnak jobban
megfelel bra. De olvasni alulrl felfel kell.
LAYER7: APPLICATION LAYER (ALKALMAZS RTEG)
Minden olyan alkalmazs, mely pt arra, hogy hlzatos krnyezetben dolgozik.
LAYER6: PRESENTATION LAYER (MEGJELENTSI RTEG)
Elemszts az alkalmazsi rteg szmra. Az adatokat alaktja olyan formkra,
melyeket az alkalmazsok mr kzvetlenl tudnak rtelmezni.
LAYER5: SESSION LAYER (VISZONYLATI RTEG)
A kommunikciban rsztvev alkalmazsok kztti kapcsolat, az n session
menedzselse.
LAYER4: TRANSPORT LAYER (SZLLTSI RTEG)
A csomagok, illetve szegmensek tnyleges eljuttatsa a cmzetthez.
LAYER3: NETWORK LAYER (HLZATI RTEG)
tvonalkeress, logikai cmzsek. Routerek.
~ 12 ~
ALAPOZS
LAYER2: DATA LINK LAYER (ADATKAPCSOLATI RTEG)
Itt kezdnk el figyelni arra, hogy a kommunikci alapveten kt rsztvev kztt
zajlik. MAC address, ethernet.
LAYER1: PHYSICAL LAYER (FIZIKAI RTEG)
Az eszkznk s a drt kztti kapcsolat. Csatlakozok, tkiosztsok, feszltsgek,
kbelek.
Ez a ht rteg mindegyik hlzati szereplnl megtallhat. Csak ppen aki kldeni
akar, az fentrl halad rajta vgig lefel, aki pedig fogadni, az fordtva.
2.1. BRA R TEGEK S CS OMAGOK ( FORRS : W IKIPEDIA )
Az brn jl lthatak azok a dobozolsok is, melyeket ebben a knyvben

boncolgatni fogunk. Lthat, hogy van maga az adat. Az alatta lv rteg ehhez
hozzteszi a sajt informciit (fejlc), majd jracsomagolja az egszet. A kvetkez
rteg mr ezt a csomagot kapja meg, mellyel ugyangy bnik el, mint az elz rteg.
Fogadskor pedig rtegenknti kicsomagols zajlik le.
A htrteg modell:
http://www.citap.com/documents/tcp-ip/tcpip006.htm
http://www.leapforum.org/published/internetworkMobility/split/node12.html
~ 13 ~

No, mi is volt az elejn az a mondat azokkal a kereskedkkel?
Ez egy memoriter. A knnyebb megjegyzs rdekben kreltak egy pldamondatot:
Please Do Not Tell Sales People Anything
Lthat, hogy az els betk alulrl felfel az egyes rtegek neveinek kezdbetivel
egyeznek meg.
Ok, ez volt a pihens.
Mi jut eszedbe, amikor szabvnyostsrl hallasz? Nem kell szgyenlsnek lenned,
magunk kztt vagyunk. Lass brokrata folyamatok... megdermedt formk... s egy
csom hjfej, akik heteket vitatkoznak egy-egy nveln. Ht, igen. Csakhogy. Vedd
figyelembe, hogy rengeteg pnzrl van sz. Az a bizonyos nvel az egyik gyrtnak
sokmillis bevtelt jelenthet, mg a msiknak sokmillis bukst. Mert amg a
hivatalnokok az ntformkkal tklnek, az let nem ll meg: a gyrtk mr
termkeket dobnak piacra. Lsd a kzelmltbl a VHS-Betamax csatt, vagy
mostanban a Blu-Ray vs HD DVD hborskodst.
Habr a hlzati folyamatok szabvnyostsa nem mai trtnet - akkoriban mg nem
voltak olyan harapsan aggresszvek a gyrtk, mint ma - de mgis valami hasonl
jtszdott le. A publikum - a szabvnyostkkal nem foglalkozva - a TCP/IP mellett
voksolt. Azaz amikorra vgre sszecsiszoldott a gynyr 7 rteg szabvny,
addigra a vilg mr a TCP/IP alap hlzatokat hasznlta. 4 rteggel. Az OSI 1977ben kezdett el dolgozni a modell kialaktsn. Tudomsom szerint az egsz mg ma
sincs befejezve. Ha elkezded bogarszgatni az egyes dokumentumokat, lthatod,
hogy van kztk 1983-as-tl 2006-osig mindenfle.
ITU Data networks, open system communications and security, X-series
http://www.itu.int/rec/T-REC-X/en
A TCP/IP v4 pedig 1979-ben jtt ki s 1983-ra terjedt el szleskren.

De ne hidd, hogy felesleges volt OSI-k minden igyekezete. A 7 rteg
kommunikcis modell - igaz, hogy tl bonyolult lett - de minden krlmnyek
kztt megllja a helyt. Platoni rtelemben egy idea lett belle. Egy sma, mely
meghatrozza a gondolkodsmdot. Azaz elmletben tudjuk, hogy a 7 rteg a
tkletes, de a gyakorlatban megelgsznk nggyel3.
Ettl fggetlenl, ha egy hlzatos kollga azt mondja, hogy L2 switch, biztos lehetsz benne, hogy a
Layer2 ebben az esetben az OSI-ISO fle 7 rteg msodik rtegt jelenti. Mely nagyjbl ugye a
TCP/IP els rtegnek felel meg.
3
~ 14 ~
ALAPOZS
Hozz kell mg tennem, hogy nem csak TCP/IP ltezik a vilgon. Ok, ez a
legismertebb... de ezen kvl virgzik mg szz virg.
The Network Protocols Map Poster:
http://www.javvin.com/map.html
Vizsgljuk meg vgre azt a 4 rteget. Mely tulajdonkppen 5.
LAYER5: Application layer (applikcis rteg)

LAYER4: Transport layer (szlltsi rteg)
LAYER3: Internet layer (internet rteg)
LAYER2: Data Link layer (adatkapcsolati rteg)
LAYER1: Physical layer (fizikai rteg)
Ha nagyon akarjuk, a kt modell rtegeit megfeleltethetjk egymsnak, de tl sok

rtelme nincs. Ez kt klnbz modell. Ha memorizlni akarjuk, akkor mondhatjuk
azt, hogy az OSI-ISO modell fels hrom rtegt bezsfoltk egy rtegbe, mondvn,
hogy ha mindhrom rteg az alkalmazssal foglalkozik, akkor ne szedjk mr szt
ennyire a feladatokat.
Tartozom mg egy magyarzattal: mirt is t az a ngy? Nos, azrt, mert mg
szakmn bell sem egyrtelm, hogy rdemes-e az als kt rteget kln kezelni.
Van, ahol sszevonjk, van ahol nem. Mivel ez a knyv a Microsoft TCP/IP
megvalstsval foglalkozik, ezrt mi speciel sszevontan fogjuk e kettt kezelni,
mghozz Network Interface Layer (hlzati eszkz rteg) nven.
Miutn mr ennyi mindent tudunk, nzzk is meg, hogyan nznek ki ezek a
dobozolsok egyms mellett:
~ 15 ~
2.2. BRA A Z OSI S TCP/IP RTEGEK E GYMS MELLETT
2.2 F OGALMAK
Kezdk szmra lehet, hogy zavar lesz, hogy itt rgtn olyan fogalmakkal
tallkoznak, melyek magyarzathoz mg nem ismert fogalmakat hasznlok fel.
Nem baj.
Valahogy mindenkinek el kell indulni. Lehet, hogy most elsre valami rthetetlen, de
rthetv vlik, ha ksbb lapozunk vissza, amikor mr elkezdnk hasznlni egy
fogalmat.
2.2.1 S Z ABV N Y O K
Az informatikban a szabvnyt RFC-nek hvjk. Ez els blikkre fura lehet, mivel az
RFC eredetileg azt jelenti, hogy Request For Comment. Ha szszerint fordtjuk, akkor
lehetne ajnlsnak, vlemnykrsnek is fordtani - de ez a mi szintnkn mr kb
annyira vlemnykrs csak, mint amikor a felesg megkrdezi a frjt, hogy
kvrnek tartja-e? Csak egy vlasz ltezik.
Rgztett folyamatokban - pl. ITIL - az RFC annyit tesz, hogy szeretnnk formba
nteni egy rszfolyamatot, egy mdszert. Ezt lerjuk s megkpkdtetjk az
rintettekkel. Ezt hvjk vlemnykrsnek. Ha mindenki elmondta a vlemnyt, az
eredeti dokumentumokon tvezettk a mdostsokat, akkor ll ssze a szabvny melyet az IETF-nl ugyangy neveznek, mint a vlemnykr iratot, az RFC-t. Csak
ppen ekkor mr ktelez rvny. (Vannak kivtelek, s igazbl ez az egsz
messze nem ilyen egyszer, de egyelre bven elg ennyi absztrakci.)
~ 16 ~
ALAPOZS
IETF: Internet Engineering Task Force. Ez a trsasg gondozza mind az

internet, mind az internethez kthet rendszerek szabvnyait.
IANA: Internet Assigned Numbers Authority. k a felelsek mindenrt, ami
szm alak s az internettel kapcsolatos.
A knyvben rengeteg RFC-re fogunk hivatkozni. Ez a csontvza a kommunikcinak
az informatikban. Minden, hangslyozom, minden erre pl - eltekintve persze az
abszolt egyedi, nem szabvnyos alkalmazsoktl. Az egyes cgek fejleszti az RFC-k
alapjn fejlesztenek. (Nem ritka az sem, hogy egy cg a sajt mdszereibl fogadtat
el RFC-t.) Az RFC-k garantljk, hogy klnbz cgek fejlesztsei kpesek legyenek
kommuniklni egymssal.
J hr, hogy az RFC-k publikusak. Mg jobb hr, hogy rengeteg helyen megtallhatk
a neten. Kevsb j hr, hogy viszonylag kevs bennk a humoros jelenet.
Meglehetsen szraz anyagok, na. De ez az egyrtelmsg miatt muszj is.
A teljessg szndka nlkl nhny link:
http://en.wikipedia.org/wiki/Request_for_Comments
http://www.ietf.org/
http://www.faqs.org/rfcs/
http://www.rfc-editor.org/rfc.html
2.2.2 K I N E K
S Z L A Z Z EN E T ?
Unicast
: Egy felad, egy cmzett.
Multicast
:Egy felad, tbb - kivlasztott - cmzett.
Anycast
: Egy felad, tbb - kivlasztott - cmzett. De ha brmelyik
megkapta, akkor a tbbiekhez mr nem jut el.
Broadcast
: Egy felad, mindenki ms cmzett.
2.2.3 H O ST
VS NODE
Ez viszonylag gyors tisztzs lesz. A host, az egy szmtgp, mely rszt vesz a
hlzati kommunikciban. A hostnak vannak hlzati csatoli. A legtbbszr ezek
hlzati krtyk. Ezeket a csatolkat nevezzk node-nak.
Magyarul egy host akr tbb node-dal is rendelkezhet.
~ 17 ~

2.2.4 S UB N E T
V S LI N K
A subnet (alhlzat) egy nagyobb hlzatnak a rsze. Legfontosabb jellemzje, hogy

a subneten lv gpek azonos cmzsi protokollokat hasznlnak, kzvetlenl ltjk
egymst, nem kell router ahhoz, hogy kommuniklni tudjanak egymssal.
A link pedig olyan node-ok halmaza, melyek egy router mgtt helyezkednek el.
Egyltaln nem biztos, hogy a linken lv node-ok ugyanabba a subnetbe tartoznak.
2.3. BRA L INK S S UBNET
A fenti kpen mind a ngy munkalloms ugyanazon a linken tallhat. Ennek

ellenre a zld s a narancssrga munkallomsok klnbz alhlzatba tartoznak.
(Az IP cmek alapjn pedig csak a zld munkallomsoknak van eslyk arra, hogy
elrjk az internetet.) Az azonos szn gpek tudnak kommuniklni egymssal, a
klnbz sznek pedig kzvetlenl nem.
Ebben a felllsban egy broadcast el fog jutni mind a ngy munkallomshoz. Ha el
szeretnnk kerlni ezt a felesleges forgalmat, akkor az azonos szn
munkallomsok szmra kln VLAN-okat kell ltestennk a switchen.
~ 18 ~
ALAPOZS
2.2.5 A ZO K
A FR N Y A DO BO Z O K
Az informcik a hlzaton dobozszersgekben utaznak. rtem ezalatt azt, hogy az

egysgeknek ltalban van alja, teteje - s van tartalma.
2.4. BRA LTALNOS CSOMAGOLSI SMA
A header az a bitkupac, ahol a csomagra vonatkoz informcik utaznak.

A payload az a szlltott tartalom.
A trailer pedig a csomag vgt jelz bitsorozat.
FRAME, AVAGY KERET: A Network Interface rtegre jellemz. Azrt hvjk

keretnek, mert mindkt oldalrl le van hatrolva, azaz tnylegesen is van
neki fejlce s lezrsa.
DATAGRAM, AVAGY DOBOZ: Az Internet rtegre jellemz, de elfordul a Transport
rtegben is. Nincs lezrsa, ehelyett a fejlc tartalmazza a csomag hosszt.
Fontos jellegzetessg, hogy kompakt informcit szllt, azaz a tartalom
magban is rtelmezhet.
SEGMENT, AVAGY SZEGMENS: A Transport rtegre jellemz. Formailag ugyanaz,
mint a datagram, de az ltala szlltott informci nem kompakt. Kpzeljnk
el egy hossz adatfolyamot, melyet felszeleteltnk s a darabokat raktuk bele
egy-egy csomagba. A csomag tartalma darabonknt nem rtelmezhet. csak
ha jbl sszerakjuk a teljes folyamot.
Lthat, hogy markns klnbsgek vannak az egyes tipusok kztt. Csakhogy ez

nem mindig lnyeges. Van amikor csak egy entitsrl beszlnk, melyet tovbbtani
kell - s ilyenkor a tovbbts mdja a lnyeges, nem az entits felptse. Ekkor
egyszeren csak csomagnak (packet) nevezzk ezt a bigyt.
Nagyon fontos megrteni, hogy a csomagok egymsba vannak csomagolva.
~ 19 ~
2.5. BRA C SOMAGOK HTN CSOMAG OK
Ezen menjnk most vgig. A Transport rtegben keletkezik egy csomag, egy TCP
szegmens. Ennek van fejlce (TCP header) s tartalma (segment, azaz adatfolyamdarab). Ez a csomag kerl t az Internet rtegbe, ahol , azaz a teljes Transport
csomag lesz az IP datagram tartalma. Az Internet rteg hozzteszi a sajt fejlct,
majd az gy keletkez datagramot passzolja le a Network Interface rtegnek. A sma
ugyanaz, a Network Interface keret tartalma a teljes IP datagram lesz, ennek az
elejre jn a Network Interface fejlc, illetve a keretet fizikailag is lezr trailer.
Amikor ez az egsz megrkezik a cmzetthez, az egyes szintek fejlcei alapjn
kdolja vissza az zenetet s rtelmezi a legvgl kapott adatszegmenst.
A kompaktsg rtelemszeren csak rtegszinten rtend. Azaz ha nzek egy
TCP szegmenst, akkor az abban lv payload az egy adatfolyam rsze,
nmagban nem rtelmezhet, nem kompakt. Ellenben ha megnzem azt az
IP datagramot, amelyikbe az elz TCP szegmenst csomagoltam, akkor ez mr
kompakt lesz, hiszen egy jl megfoghat dolog van benne, a TCP szegmens.
Nem megynk bele, hogy a TCP szegmens odabent nem kompakt.
~ 20 ~
ALAPOZS
2.2.6 H L Z AT I
E S ZK Z K
Milyen eszkzkre gondolok? Olyanokra, melyek segtenek kipteni s fenntartani

egy szmtgpes hlzatot - s ezek kzl is azokra, melyek hlzatokat,
hlzatrszeket ktnek ssze valamilyen formban.
2. 2 .6 . 1 H U B
Az OSI modell szerint rtve L1 szinten mkd eszkzk, fizikailag ktnek ssze
node-okat. Minden forgalmazott csomag kimegy minden node-hoz, nincs semmilyen
portszeparci. Gyakorlatilag egy buta eloszt.
2. 2 .6 . 2 S W I T C H
Annyibl hasonl a hubhoz, hogy ez is eloszt, de mr kpes szrni a forgalmat, azaz

egy konkrt node-hoz csak az a forgalom megy ki, melyet neki szntak, plusz a
broadcast. Tulajdonkppen egy intelligens eloszt, az L2 rtegben.
2. 2 .6 . 3 B R I D G E
Szintn L2 eszkz, azonos nvter, azonos protokollokat hasznl alhlzatokat kt

ssze. Pontosabban, egy alhlzatot, mely tbb rszre oszlott. Ez azt jelenti, hogy a
bridge routolst nem vgez, a csomagokat csak forwardolja egyik helyrl a msikra.
Manapsg a bridge s a switch fogalmak meglehetsen sszemosdtak.
2. 2 .6 . 4 G A T E W A Y
Klnbz protokollokat hasznl hlzatokat sszekapcsol eszkz. Mind a ht

rtegben mkdhet.
2. 2 .6 . 5 R O U T E R
L3 rtegben dolgoz eszkz. Klnbz nvter - de azonos protokollokat hasznl alhlzatokat kt ssze. Ksbb rszletesen is foglalkozunk vele.
~ 21 ~
3 A HLZATI ESZKZ RTEG PROTOKOLLJAI

Akrhogy is nzzk, a drton vad elektronok tekernek. Mi a valsgban csak az
elektromos jelszint vltozst tudjuk rzkelni. Ebbl a folyamatos ramlsbl kell
diszkrt csomagokat formlnunk, emberi (hah!) logika szerint.
Errl szl a hlzati eszkz rteg.
Lthat, hogy neki van a legnehezebb dolga. kszti el a legkls dobozt, is
rzkeli fogad oldalon a dobozok hatrait. A tbbiek mr biztos krvonalakkal
rendelkez dobozokat kapnak, melyekbe btran pakolgathatjk bele a sajt
csomagjaikat.
Trtnelmileg gy alakult ki, hogy a konkrt hlzatok kiterjedstl fggen
klnbz protokollok terjedtek el. Ezt ma mr elg nehz elmagyarzni, tekintve,
hogy mostansg nem ritka a tbb kilomtert is tr loklis hlzat (Local Area
Network, LAN), mikzben szmlzsi okokbl kis tvolsgokon is szoktak
nagykiterjeds hlzatokra (Wide Area Network, WAN) jellemz protokollokat (pl.
PPP) hasznlni. n mindenesetre LAN/WAN bontsban fogom sorbavenni ezeket.
~ 22 ~
A HLZATI ESZKZ RTEG PROTOKOLLJAI
3.1 LAN
TECHNOLGIK
Teht ott jrunk, hogy a Network Interface Layerben vagyunk, azaz az els
csomagols el is kezddik a... Data Link Layerben. Hogy nemrg azt rtam, Windows
krnyezetben nincs is olyan? Dehogyisnem, csak begymszltk a NIL-be.
Mivel mg teljesen az elejn vagyunk, nem rt, ha sorra vesszk, mit is kell
biztostania egy ilyen csomagolsnak:
ELHATROLS. rtem ez alatt, hogy pontosan rzkelnnk kell az egyes
csomagok hatrait, illetve csomagon bell a header/trailer s payload
hatrokat.
PROTOKOLL AZONOSTS. rtelemszeren szintn nagyon fontos. Ha
valamit kisnylknt csomagoltam be, akkor azt ne mikrohullm stnek
csomagoljk ki, mert annak nagyon bna lesz.
CMZS. Ki a felad, ki a cmzett?
INTEGRITS. A cmzettnek legyen lehetsge meggyzdni arrl, hogy
teljesen pen kapta-e meg a csomagot.
Kezdjk lesteni a fkuszt. Ezen a nagy fejezeten bell a kvetkez hlzati
technolgikkal fogunk foglalkozni: Ethernet, Token Ring, FDDI, IEEE802.11.
Mindegyik technolgin bell klnbz frame formtumokkal futhatunk ssze.
Fl, hogy itt egy kiss zavaross vlhat a fejtegets. Azt mr tisztztuk, mi a
klnbsg packet s frame kztt, de milyen a viszony a tovbbtsi technika, a
frame formtuma s a protokoll kztt?
Nos, konkrtan: az Ethernet az egy kerettovbbtsi technika, az Ethernet
keretekhez viszont tbbfajta frame formtum is tartozhat: Ethernet II, Ethernet
802.3, Ethernet 802.3 SNAP. Keverni ket tilos: ha az egyik kommunikl fl
mondjuk az Ethernet II formtumba csomagol, akkor a msik, amelyik az Ethernet
802.3 SNAP formtumra szmt, nem fogja rteni, dacra, hogy a keret tovbbtsi
technikja mindkt esetben Ethernet.
IEEE LANs, azaz 802.x szabvnyok, rszletes ismertetssel:
~ 23 ~

A protokollokkal kapcsolatban ltalnossgban elmondhat, hogy a protokoll az egy
elrt viselkedsi forma. Mint egy szigoran rgztett cselekvssor egy diplomciai
fogadson. Mint egy klasszikus tnc. "A fiatalr a hlgy derekra helyezi a jobb kezt,
a hlgy a fiatalr vllra helyezi a bal kezt, a fiatalr jobb lbval knnyedn
elrelp, a hlgy jobb lbt elretve velefordul." Ez a konkrt tnc szablya, aki
nem gy tncol, azt kivezetik a blterembl.
A frame formtum ezzel szemben egy technikai megegyezs. Egy aprsg, mely kell
a protokoll szerinti viselkeds megvalstshoz. Mint az azonos nyelv beszd a
tnc kzben, vagy a mindkt fl ltal ismert zszljelek egy tengeri hadgyakorlaton.
Nzznk egy pldt az informatikbl.
A fogadhoz beesik 10 darab keret. Ethernet krtykat hasznlunk, a frame
formtum pedig - mind a feladnl, mind a cmzettnl - Ethernet II, azaz a fogad ki
tudja csomagolni a keretek tartalmt. A fregmentlt IP datagramokat ssze tudja
rakni (ehhez ismernie kell az IP protokollt4), gy megkapja az IP payload-ot, a TCP
szegmenst - abbl pedig ki tudja csomagolni az eredeti informcit (ismerve a TCP
protokollt5), mondjuk azt hogy "MAIL FROM: info@cegnev.hu". Ez pedig, mint tudjuk,
az SMTP protokoll6 egyik utastsa, egsz konkrtan az elkldend levl feladjt
lltja be.
Protocols and protocol stacks:
Layer2 - IP
Layer3 - TCP
6 Layer4 - Applikci
4
5
~ 24 ~

3.1.1 E T H ER N E T
Hawai. s aloha.
Ott kezddtt. A hawai egyetemen fejlesztettek ki egy alapveten rdihullmok
tvitelre optimalizlt rendszert. Kkemny 9.6 Kbps-t tudott. gy hvtk, hogy
ALOHA.
Ethernet:
http://en.wikipedia.org/wiki/Ethernet
Erre a rendszerre alapozva hoztak ssze 1972-ben Palo Altoban, a Xeroxknl (igen,
ott ahol az egeret, az ablakos GUI-t s valami fnymsolt is feltalltak) egy 2.94
Mbps-t tud hlzatot, melyet Ethernetnek neveztek el. A nv arra utal, hogy a
hlzati kommunikci a levegbe, azaz az terbe ordiblson alapul. De erre
ksbb mg visszatrnk.
1979-ben 3 nagy cg (Digital, Intel s a Xerox) szvetsget ktttek, hogy ltalnos
szabvnny neveljk ki az Ethernetet. Ezt a vltozatot hvjk Ethernet II-nek, vagy
DIX-nek7. Akkor 10 Mbps-t tudott.
1981-ben lett az Ethernet IEEE 802.3 nven nemzetkzi szabvny. 1995-ben jtt a
100 Mbps sebessg fast Ethernet... s azta sincs meglls. Jelenleg ppen a 40
Gbps, illetve 100 Gbps vltozatok fejlesztse folyik szorgalmasan.
Fggetlenl a sebessgtl, az Ethernet keretek szlltsi mdszere nem vltozott. A
frame-k ugyanazt a mdit (koax, csavart rpr vagy vegszl) hasznljk, mghozz
gy, hogy egyszerre csak egy keret tekerhet rajta. Azaz a felad beleordtja az
informcijt az terbe s ha ppen mindenki ms csendben volt, akkor az el is jut a
cmzettekhez. Ha ppen akkor valaki ms is beleordtott, akkor mindkett
szgyenlsen elhallgat, vletlenszer ideig vrnak, majd jrakezdik.
Egsz pontosan gy trtnt az eset, hogy Robert Metcalfe, a szabvny egyik tulajdonosa otthagyta a
Xeroxot, megalaptotta a 3Com-ot, majd indulsknt vette r a hrom nagyot a szabvny
tmogatsra.
7
~ 25 ~

Szoktak erre egy npszer hasonlatot is hasznlni: olyan ez, mint egy udvarias barti
beszlgets egy nagyobb trsasgban. Valaki elkezd egy sztorit, befejezi. Megszlal
msvalaki, elmondja a trtnett, elhallgat. Aztn ketten szlalnak meg egyszerre,
szlelik s elhallgatnak. Zavart csend, majd az egyik jrakezdi, ksbb pedig jn a
msik is.
Ezt a viselkedst informatikus nyelven gy hvjk, hogy carrier sense multiple access
with collision detection, azaz CSMA/CD.
Nos, ennyi bevezet utn immr semmi sem menthet meg minket a keretek
boncolstl.
3. 1 .1 . 1 E T H E R N E T I I
RFC 894
3.1. BRA ETHERNET II FRAME FORMTUM
Mivel ez az els frame formtum, gy itt mondom el: eszedbe se jusson ezeket
megtanulni! Ilyen brbl legalbb ktszz lesz mg. Ha csak nem a keretek, illetve a
hlzati datagramok lesznek eljvend leted csaldtagjai, bven elg, ha kimsolod
egy pendrive-ra a knyvet, s ha hlzati forgalmat kell elemezned, akkor
megkeresed a megfelel brt. A srbben elfordulkat gyis meg fogod jegyezni.
A kevsb srn elfordulk meg vlemnyem szerint az emberi agyat sokkal
rtkesebb dolgok trolsra terveztk.
~ 26 ~

Jjjenek a rszletek.
PREAMBLE: a szirnz felvezet aut a sorban. Szszerint szirnzik: felvltva
tartalmaz egyeseket s nullkat. Pontosabban a 8 bjtbl 7 bjt szirna, az utols
pedig botlik egyet: 10101011, jelezve azt, hogy innentl jn a nagykvet a tartalom.
Ez a sorozat a szinkronizlshoz kell, rdekes mdon a network monitorozskor
nem is ltszik.
DESTINATION ADDRESS: A cmzett MAC cme.
SOURCE ADDRESS: A felad MAC cme.
ETHERTYPE: Ez a kt bjtos rtk mondja meg, hogy a payload kinek a mije, azaz mire
szmtson a felette lv rteg. Az esetek nagy rszben az rtke 0x0800, mely IP
csomagot jelent - de lehet 0x0806 is, mely ARP zenetet takar.
PAYLOAD: A felette lv rtegnek szl informci. Maximlis mrete 1500 bjt lehet,
a minimlis rtke - a megbzhat tkzsdetektls miatt - 46 bjt. Ha nincs ennyi,
akkor kiptoljk.
FRAME CHECK SEQUENCE (FCS): Magyarul CRC8. Ez tulajdonkppen egy lenyomat9
magrl a frame-rl 10 , a frame mg tzve. A fogad ugyangy rkldi az
algoritmust s amennyiben ugyanazt az rtket kapja, mint ami az FCS mezben van,
akkor a frame tartalma biztosan nem vltozott meg tkzben.
Az FCS szintn nem ltszik a network monitorozsnl.
Akkor mi ltszik? Nzzk meg11.
Cyclical Redundancy Check.

Egsz pontosan az trtnik, hogy a keretet, mint bitsorozatot elosztjk egy 33 bites prmszmmal,
majd a mindig 32 bites maradk kerl az FCS mezbe.
10 Nyilvn nem belertve az FCS s a Preamble mezket.
11 Az brk ellltshoz a Wireshark programot hasznltam.
8
9
~ 27 ~
3.2. BRA E GY E THERNET II FRAME
Ksbb mr nem fogok minden egyes capture brt ennyire szjbargsan

elmagyarzni, de mivel ez az els, ezrt itt egy kicsit b lre eresztem a szveget.
A fenti brn az elkapott hlzati folyam hatodik kerett ltjuk. (Ha a legfels sort
lenyitnm, akkor ott egy sszefoglalt tallnk a keretrl.)
A msodik sor lett lenyitva, ez ugyanis maga az Ethernet II keret fejlce.
Az bra legaljn pedig maga a teljes frame tallhat, a hexa editorokban megszokott
bjt formtumban. A bemzolt rsz mindig azt mutatja, amit a felette lv ablakban
kijelltnk.
Keressk meg az brn (3.1. bra ETHERNET II frame formtum) emltett rszeket.
~ 28 ~
3.3. BRA D ESTINATION A DDRESS
Mint rtam, a Preamble mez nem lthat, gy a legels mez a Destination Address.
Fent a program szpen kibontja, hogy milyen eszkzrl is van sz (a MAC cm
gyrtspecifikus), alul viszont csak a hexadecimlis, hat bjtnyi rtk lthat.
3.4. BRA S OURCE A DDRESS
~ 29 ~

Ugyanez lthat a Source Address meznl is.
3.5. BRA A Z E THER T YPE MEZ
Vgl az utols brn lthatjuk az EtherType mez rtkt, mely hatrozottan

0x0800-nak ltszik, azaz IP csomagrl van sz.
A kvetkez kt sor - melyeket nem bontottam ki - alkotja a payload-ot. Ezekkel
rrnk ksbb is foglalkozni.
s ennyi. Krds lehet mg, hogy ha frame, akkor muszj, hogy legyen trailer is. Hol
van?
Elbjt. Mint rtam, a trailer itt a Frame Check Sequence, mely a capture fjlban nem
lthat.
Ha mr itt kerltek el, ejtsnk mg pr szt a MAC cmekrl.
3.6. BRA D ESTINATION MAC A DDRESS
~ 30 ~

A MAC Address alapveten egy hatbjtos rtk, ahol az els hrom bjt a hardver
gyrtjra utal, a msodik hrom pedig a konkrt eszkz azonostja.
Az els bjt legals kt bitje specilis szerepkrrel br, mind a felad, mind a cmzett
cmben.
DESTINATION ADDRESS, I/G BIT (INDIVIDUAL/GROUP)
Azt hatrozza meg, hogy a megclzott cm egyedi (unicast, azaz individual), vagy
csoportos (multicast, azaz group). Unicast esetben a bit rtke 0, multicast esetben
1. A broadcast (FFFFF) ebben az esetben a multicast alesete.
DESTINATION ADDRESS, U/L BIT (UNIVERSAL/LOCALLY ADMINISTERED)
Azt hatrozza meg, hogy a megclzott cm eredeti, begetett (universal) vagy
loklisan fellrt (locally administered). Alaphelyzetben egy hlzati eszkznek a
vilgon egyedi MAC cme van - bizonyos esetekben viszont fellrhatjuk ezeket az
rtkeket.
Nzzk a forrs oldalt.
3.7. BRA S OURCE MAC A DDRESS
Vszcseng. Bejelzett? Nem? Az baj.

Lapozz csak vissza ehhez az brhoz: 3.4. bra Source Address. Lthatod, hogy a
capture fjlban gynyren ki van rszletezve mindkt oldalon mind a kt bit
jelentse. Mrpedig a forrscmnl ugyangy I/G bitnek rtelmezi az els bitet...
mikzben a fenti rajzon n azt rajzoltam be, hogy No Routing/Routing.
Akkor most mi van?
Az van, hogy csaltam. Az I/G bit a feladnl igazbl semmilyen jelentssel nem br.
Gondold el, ltezhet egyltaln multicast felad? Na ugye. Ebbl kifolylag az
Ethernet technolgikban az rtke masszvan nulla, ezt ltjuk a capture fjlban is.
De van, amikor hasznljuk. A Token Ring pldul MAC szinten routolgat, neki
kifejezetten jl jn, hogy ezen a biten tud jelezni.
~ 31 ~
3. 1 .1 . 2 E T H E R N E T 8 0 2. 3
RFC 1042
Itt mr egybl a lecsba csapunk.
3.8. BRA A Z E THERNET 802.3 FRAME FORMTUM
Ez egy elg rdekes szvr. Mint lthat, van ugyan keret (IEEE 802.3), de abban egy
jabb csomagols, gynevezett kapszula van. Ez a bels kapszula a Network
Interface Layer mr korbban emltett egyik alprotokollja, a Logical Link Control
(IEEE 802.2).
Most nzzk csak a kls keretet. Nagyjbl ugyanazt ltjuk, mint az elz frame
formtumnl: a Preamble ugyan kt rszre szakadt, de ez csak logikai sztvlaszts,
hiszen annyi trtnt mindsszesen, hogy az utols, klnbz bjtot mshogy
neveztk el. A Destination Address, a Source Address teljesen ugyanaz12 s az FCS is.
A klnbsg a Source Address utn kezddik. Itt egy kt bjton brzolt hossz
rtket tallunk, mikzben az Ethernet II esetben ezen a helyen a
protokollazonost volt. (A hosszt gy kell elkpzelni, hogy az LCC header els
bjtjtl a payload utols bjtjig terjed bjtok szma. Vegyk szre, hogy ez
gyakorlatilag megegyezik az Ethernet II esetben a payload-dal.)
12
Azzal az apr eltrssel, hogy a szabvny megengedi a 2 bjtos MAC cmeket is.
~ 32 ~

Most kpzeljnk el egy olyan szervert, mely mind a kt frame formtumot ismeri.
Honnan fogja az tudni, hogy ez a kt bjt most hossz rtk, vagy protokolltpus?
Nagyon egyszeren. Tudjuk, hogy a payload rtke minimum 46 bjt, maximum
1500. Egsz egyszeren ebben az intervallumban nincsen protokollazonost kd.
Teht ha a Source Address utni rtk mondjuk 1000, akkor Ethernet 802.3 frame
formtummal llunk szemben.
Nzzk most magt a 802.2 LCC datagramot.
DESTINATION SERVICE ACCESS POINT, DSAP: A cmzett oldaln milyen protokollra
szmthatunk.
SOURCE SERVICE ACCESS POINT, SSAP: Ugyanez, forrs oldalon.
Nyilvn ezek kdszmok lehetnek. Ami minket a leginkbb rdekel, az az, hogy az IP
csomag rtke 0x06. Kellemetlen tny, hogy az iparban gyakorlatilag ezt a kdot
senki nem hasznlja, helyette a 0xAA kd terjedt el. De ezzel majd a kvetkez frame
formtumnl foglalkozunk bvebben.
CONTROL: Ez egy egy- vagy ktbjtos kd. Arra vonatkozik, hogy magt az LCC
kapszult hogyan ksztettk el. rtkei:
TYPE1: A kapszula egy LCC datagram, a Control bjt rtke 0x03. Ez egy
meglehetsen megbzhatatlan kapszulzs, nem foglalkozik a szllts
megbzhatsgval.
TYPE2: A kapszula egy LCC session rsze, hibadetektls, sorbarendezs, meg
ilyenek.
Az IP datagrammok s ARP csomagok szlltsa kizrlag TYPE1 mdon trtnik,
teht neknk elg a 0x03 rtket megjegyeznnk. (lltlag van egy TYPE3 is, de
ezzel mg ritkbban tallkozhatunk, mint a TYPE2-vel.)
PAYLOAD: A felettnk lv rteg eredeti datagramja. Termszetesen a kiptls itt is
jtszik.
~ 33 ~
3. 1 .1 . 3 E T H E R N E T 8 0 2. 3 S N AP
RFC 1042
Bonyoltsuk tovbb a tornyot.
3.9. BRA IEEE 802.3 SNAP FRAME FORMTUM
Mint korbban is rtam, az Ethernet 802.3 frame formtum DSAP/SSAP mezjben a

0x06 rtket ritkn hasznljk az IP protokoll megadshoz. Helyette egy
gynevezett Sub-Network Access Protocol-on (SNAP) keresztl adjk meg a payload
protokolljt. Ekkor a DSAP/SSAP mezkben a 0xAA rtkkel jelezzk, hogy nem itt
kell keresni a protokollazonostt, hanem egy jabb kapszulzson bell, az SNAP
headerben. s lthat, ott is vigyorog a j reg EtherType.
Menjnk sorban. Az IEEE802.3 header teljesen ugyanaz, mint korbban, ne is
vesztegessnk sok szt r.
DSAP, SSAP: Jelentse ugyanaz, mint korbban, a fix rtkk: 0xAA.
~ 34 ~

CONTROL: Jelentse ugyanaz, a fix rtk: 0x03.
ORGANIZATION CODE: Ez valamikor jelentett valamit, de mra mr nem sok rtelme
maradt. A hrom bjtbl az els mondta meg, hogy melyik szervezet felels a
tovbbi kt bjt rtelmezsrt. Jelenleg a fix rtk: 0x00-00-00.
ETHERTYPE: rtelmezse - s rtkei - megegyeznek az Ethernet II frame formtum
lersnl rtakkal.
PAYLOAD: Tovbbra is maga az IP datagram. De szmoljunk csak: a klnbz
dobozolsokra azrt mr elment nmi bjt, azaz a payload mretkorltai is
megvltoztak. A hatrok immr: 38-1492 bjt. (Az utbbi szm nem ismers? Nem,
nem Kolumbusz. MTU? Az bizony. Mi is pontosan ez az MTU? Maximum
Transmission Unit, azaz a drton tkldhet maximlis hasznos teher. De ht nem
pont errl beszltnk?)
Az IEEE802.3 trailer maradt a rgi.
Ezzel vgig is futottunk az Ethernet frame formtumokon. Mit saccolsz, melyik a
legelterjedtebb? Nyilvn a legegyszerbb, az Ethernet II. Nem is igazn rtem, mi
hzdott meg amgtt a logika mgtt, mely ltrehozta a 802.3 szabvnyt, mely egy
jabb tekeredssel visszatrt az Ethernet II formtumhoz, elpazarolva egy csom
hasznos bjtot, gyakorlatilag nulla elnyrt cserbe.
A Windows Server 2008 s a Windows Vista fejleszti is hasonlkppen
gondolkodtak, ugyanis alapbelltsban az Ethernet II formtumot preferljk.
Megrtik a 802.3 formtumot is, csak utljk. Azaz ha brmilyen krs (ARP) rkezik
hozzjuk 802.3 formtumban, akkor Ethernet II formtumban vlaszolnak vissza. Ha
az rdekld veszi a lapot s is tll Ethernet II-re, akkor minden rendben. Ha nem,
akkor gy jrt. A szerver/Vista nem fog vele kommuniklni.
Ezen a hozzllson egy registry vltoz tlltsval lehet mdostani.
HKLM\System\CurrentControlSet\Services\Tcpip\Parameters
Itt kell ltrehozni a kvetkez vltozt:
ArpUseEtherSNAP [reg_dword]
Ha nulla az rtke, akkor letiltja a 802.3 SNAP frame formtumot. Ha egy, akkor
engedi.
~ 35 ~

3.1.2 T O K EN R I N G : IEEE802.5
IEEE 802.5 SNAP

RFC 1042
A modellvast.
Ha az Ethernet kommunikci esetben azt mondtam, hogy az udvarias barti
trsasg beszlgetshez hasonlt, akkor a Token Ring leginkbb egy
modellvasthoz. Egy olyanhoz, mely egy hossz, tekergs, de azrt zrt plyn jr
krbe-krbe. A szerelvnyen van egy mozdony s egy tehervagon - ez a Token - az
llomsok pedig felpakoljk r, illetve leszedik rla a kereteket. Egyszerre csak egy
szerelvny megy a plyn, s egyszerre csak egy keretet tud szlltani.
Pontostsuk a hasonlatot. Nem egy darab szerelvny - token - ltezik. Igaz, hogy
egyszerre csak egy tekerhet a sneken, de brmelyik lloms kiveheti a tokent a
forgalombl s bellthat egy sajtot.
Pontostsuk mg tovbb a hasonlatot. A sneken vagy token (res szerelvny) vagy
frame kzlekedik. Az az lloms, amelyik kldeni akar, leszedi a tokent s betesz egy
frame-t. Amelyik megkapta a neki szl frame-t, leszedi s elindt egy res tokent. 13
Hasonltsuk ssze, a mkdsi mdbl kifolylag milyen elvi klnbsgek lesznek az
Ethernet technolgihoz kpest?
Kevsb lesz rzkeny az llomsok szmnak nvelsre. Amg az Ethernet

esetben 30 lloms fltt tragikus kakofniv fajult a kommunikci, addig
a Token Ring esetben nagyjbl 200 munkallomsnl kezdett el a
rendszergazda switch vsrlsn gondolkodni. (A maximlis rtk viszont
250 krl volt.)
Az tkzsdetektls elmaradsa miatt nincs minimlis frame mret.
A Token Ring tviteli sebessge kevsb fggtt az llomsok szmtl.
Meglehetsen stabilan hozta a maximum kzeli rtket, mg az Ethernet
svszlessge 14 drasztikusan cskkent az llomsok csatlakoztatsval.
Mindezt gy, hogy a Token Ring a 16 Mbps sebessget tartotta az Ethernet
meg csak akkor tudta a 10 Mbps-t, ha kt gpet ktttnk ssze... cross
kbellel.
Jogos lehet a krds, mi trtnt vezetkszakadskor? Hiszen ezzel megsznne a gyr, azaz minden
lloms leesne a hlzatrl. A vlasz a csatlakozban rejlik. A TR csatlakozk olyan spci bonyolult
szerkezetek, hogy mr a patch panelben szlelik, ha baj van (elromlott a krtya, a tloldali csatlakoz,
megszakadt a vezetk) s rvidzrral kikzlik a hibs szakaszt. Nem vletlenl voltak ezek olyan
drgk.
14 Kaptam olyan visszajelzst, hogy ez nem svszlessg, hanem adattviteli sebessg. Teljesen igaz,
de az informatikai kzbeszdben ez a vltozat is meggykeresedett.
13
~ 36 ~

Azaz minden tekintetben jobb volt a Token Ring, mint az Ethernet. n hat vig
dolgoztam akkoriban olyan cgnl, ahol tisztn Token Ring hlzatunk volt - s vgig
gy reztem magam, mint aki egy kivlasztott cgnl dolgozhat. Hrom pesti
kerletben elhelyezked, t telephelyes hlzatot fogott t egy gyrnk. Nem is
titkoltan nztem le az ethernetes kollgkat, amikor soroltk, milyen problmik
vannak. Neknk ugyanis csak egy volt: valahogyan meg kellett keresni a hlzat
zemeltetsre a pnzt. A Token Ring ugyanis piszok drga. Mg annl is drgbb. A
kbelezs, a csatlakozk... na s persze a hlzati krtyk. Az ezredfordul tjn egy
Token Ring krtya 45-50000 forint krl volt, mikzben egy Ethernet krtya kb a
tizedbe fjt.
Aztn egyszercsak a vilg megrzta magt s elrohant a Token Ring technolgia
mellett. Az Ethernet rai mg jobban lezuhantak, mikzben a sebessge drasztikusan
megntt. Persze a bekiabls technikbl kvetkez 'max. 30 node egy linken' korlt
tovbbra is megmaradt - de megjelentek az olcs s okos switch-ek, melyek
drasztikusan lecskkentettk az tkzsek eslyeit15. Innentl kezdve a francot sem
rdekelte az ingadoz sebessg, ha az egybknt bszme nagy rtk krnykn
ingadozott. Ha egyltaln.
Igaz, idkzben a Token Ring is kijtt egy 100 Mbps sebessg technolgival
(vegszlon), az roll is cskkent (ma mr 15e krl lehet kapni 4/16/100 Mbps
TR krtyt), de ha megnzzk, az Ethernet jelenleg milyen sebessghatrokat
ostromol, hossz tvon nem sok eslyt adok a Token Ringnek.
s akkor most jjjn egy kis trtnelemra.
Magt az elvet Olaf Soderblum dolgozta ki, mg 1969-ben. Az IBM megvette tle,
majd Token Ring nven dobta piacra, 1984-ben. (Hogy kzben mit csinltak?
Gondolom, j alaposan tgondoltk.) A technolgibl nemzetkzi szabvny 1985ben lett, a keresztsgben az IEEE 802.5 nevet kapta.
Ennek a frame szerkezett mutatja be az albbi bra.
Szaknyelven szlva klnvlasztottk a broadcast domaint a collision domaintl. Azaz a switch

megjegyezte, hogy melyik lbn milyen MAC cmmel rendelkez lloms lg (illetve ha kaszkdolva
lettek a switchek, akkor milyen llomsok) s csak a nekik szl csomagokat irnytotta arra. Ezzel
jelentsen lecskkent az tkzsek valsznsge. Ettl fggetlenl persze a broadcast kimegy
minden munkallomsra, mely a switchen lg. Illetve ez csak akkor igaz, ha a switchen egy darab
VLAN (Virtual LAN) fogja ssze az sszes portot. Amennyiben a portokat tbb VLAN-ba szedjk szt,
akkor a broadcast VLAN-on bell marad. Azaz a VLAN jelenti egyben a broadcast domaint is.
Fontos, hogy ne keverjk ssze a VLAN-t a subnettel. Az elz definilsa s kezelse L2 szinten (OSI
modell) trtnik, MAC address alapjn s jellemzen egy switch vgzi, mg az utbbi L3 szinten, IP
cmek alapjn s jellemzen egy router a felgyel. (Habr ma mr lteznek L3 switchek is.)
15
~ 37 ~
3.10. BRA IEEE 802.5 F RAME FORMTUM
START DELIMITER: Egy bjt, mely jelzi a keret kezdett. A bitek helyn roppant
rejtlyes nev szimblumok tallhatk, bizonyos J s K gynkk. (Annyit tudtam
kibogozni rluk, hogy valami Manchester kdols adatok, melyeket egybknt a
rditechnikban hasznlnak.) Tl sokat nem kell foglalkoznunk velk, az
Ethernetnl megszokott mdon ezek sem ltszdnak a capture fjlban.
ACCESS CONTROL: Szintn egy bjt, melyben a biteknek kln-kln van rtelme.
Els hrom bit: A token prioritst lltja be. Izgi, nem? Frame szinten tudjuk
szablyozni, mennyire fontos adatrl van sz. Ht klnbz rtke lehet.
Msodik hrom bit: Tulajdonkppen ez egy priorits reset bitsorozat. Azt a
prioritst adja meg, melyre a token akkor ll, miutn leszedtk rla a
szlltott frame-t.
Hetedik bit: Egyre ll, ha a szerelvny elhalad az gynevezett monitoroz
lloms eltt. Amennyiben a monitoroz lloms el olyan szerelvny r,
melynek mr magasra van lltva ez a bitje, akkor az lloms kikapja a
forgalombl.
Nyolcadik bit: Jelzi, hogy ami most jn, az token (0) vagy frame (1).
~ 38 ~

FRAME CONTROL: Egy bjt hossz. A bitek jelentse:
Els kt bit: Azt mondja meg, hogy a frame LLC frame, vagy MAC frame. (Ugye
emlksznk, a Token Ring varzsol MAC szinten is.)
Kvetkez ngy bit: Amennyiben MAC management frame-rl van sz, akkor
jelzi, hogy a MAC alrtegen bell konkrtan milyen tipusrl. Ezek lehetnek
Purge, Claim, Token vagy Beacon tipusak.
Utols kt bit: Csak gy foglalt.
Purge, Claim, Token s Beacon:
http://www.techfest.com/networking/lan/token.htm
DESTINATION ADDRESS: A megclzott lloms MAC cme. Vigyzat, lehet MAC

management multicast cm is.
SOURCE ADDRESS: A felad MAC cme.
Az IEEE 802.2, azaz LLC header totlisan ugyanaz, mint az Ethernet keretek (802.3,
802.3 SNAP) esetn.
PAYLOAD: Azt mr rtam, hogy a Token Ring frame-nek nincs als korltja. (Ok,
negatv szm nem lehet.) De mi a helyzet a fels rtkkel? Mennyi a Token Ring
MTU-ja? Attl fgg. Mitl? Egy bonyolult algoritmustl, mely mg tn a
napjegyenlsgek ciklikus vltakozst is figyelembe veszi. A pontos lersa az RFC
1042-ben tallhat.
FRAME CHECK SEQUENCE: A mr jl ismert ngybjtos CRC.
END DELIMITER: Egybjtos rtk, a mr korbban emltett J s K szimblumokkal. A
kt utols bitjnek rtelmezhet rtkei vannak.
Intermediate Frame Indicator: Ez a frame az utols a sorban(0), vagy vannak
mg(1)?
Error Detected Indicator: Jelzi, hogy ellenrzskor pp volt-e a CRC.
~ 39 ~

FRAME STATUS: Egy bjt, a kvetkez rtkekkel:
Address Recognized Indicator: Amennyiben a megclzott lloms szreveszi
a kldsi szndkot, akkor ezt a bitet magasra lltja, jelezve ezzel, hogy j
volt a cmzs.
Frame Copied Indicator: Amikor a megclzott lloms hlzati krtyja
felkapja a frame-t, magasra lltja ezt a bitet, jelezve ezzel, hogy minden ok,
megkapta a keretet.
Mindkt indiktor megduplzva szerepel, mivel ezt a mezt mr nem vdi a CRC
ellenrzs.
Az utols hrom mez - Frame Check Sequence, End Delimiter s a Frame Status nem ltszdnak a capture fjlban.
A cmben szerepel az SNAP nv is. Gondolhatnd, hogy itt majd fogok foglalkozni a
Token Ring SNAP frame formtumval... de tvedsz. Nem fogok vele klnsebben
foglalkozni. Az Ethernet 802.3-nl mr lertam, hogyan kapunk a norml, LLC-vel
megbolondtott frame formtumbl SNAP frame formtumot, s mivel a kavars
lnyege az volt, hogyan jelezzk, hogy a payload jelenleg IP datagram - amely ugye
egy szinttel feljebb van - gy az talakts, azaz a sznaposts a Network Interface
Layerben is ugyangy trtnik, fggetlenl a tovbbtsi technolgitl. A
DSAP/SSAP rtkek ugyangy 0xAA-ra vltanak, a Control 0x03-ra, bejn az
rtelmezhetetlen Organization Code mez s jbartunk, az EtherType is. Igen,
Token Ringnl is EtherType-nal hvjk. Fura, mi?
~ 40 ~

3.1.3 F I B ER D I ST R I BUT E D D AT A I N T E R FA C E : FDDI
RFC 1188
A Token Ringhez hasonlan itt is modellvasutazunk. Csak ppen itt kt snplya is
fut egyms mellett, biztos, ami biztos alapon. s mindkett piszkosul gyors - azaz a
valsgban vegbl van. (A technolgia ltezik rz vezetken is, de akkor CDDI-nek
hvjk.)
Mik a fontosabb jellegzetessgei?
Elssorban a megbzhatsg. Norml esetben mindig csak az egyik gyr
mkdik, ha az megszakad, akkor lp be a krbe a msodik. Ha mindkt
gyr megszakad ugyanazon a ponton, akkor a kt gyr sszektsvel
tovbbra is mkdik az adattvitel. (A forgalom irnya ellenttes a kt
gyrn.)
A leginkbb elterjedt vltozat sebessge 100 Mbps. Ez valamikor fantasztikus
sebessgnek szmtott, manapsg mr csak olyan "szdval elmegy"
kategria. Ha nem foglalkozunk a megbzhatsggal s mindkt gyrt
hasznljuk egy idben, akkor 200 Mbps-t rhetnk el.
Az vegszl miatt nagy tvolsgokat tud lefedni. 200 kilomter mg nem
problma.
A viszonylag nagy adattviteli sebessg, a nagy tvolsg s a nagy
megbzhatsg miatt elssorban gerinchlzatok (backbone) kiptsre
hasznljk.
A frame szerkezete meglehetsen hasonlt a Token Ring technolginl megismert
frame szerkezetre.
~ 41 ~
3.11. BRA FDDI F RAME FORMTUM
PREAMBLE: Nem hiszem, hogy az eddigiek utn brmi jat is tudnk mondani. a
tlkls a kanyarban.
START DELIMITER: Teljesen hasonlatos a Token Ring hasonl mezjhez, olyan szinten,
hogy itt is megtalljuk J s K gynkket.
Sem a Preamble, sem a Start Delimiter mezk nem lthatk a monitoroz
programokban.
FRAME CONTROL: egy bjt, a kvetkez bontsban:
Class bit: Szinkron (1) vagy aszinkron (0) keretrl van-e sz? A szinkron
keret garantlt svszlessget s vlaszidt jelent, mg az aszinkron kerettel
elrt svszlessg dinamikusan vltozik, a lehetsgeknek megfelelen.
Cmhosszsg bit: Hny bjtosak a cmek? 2 (0) vagy 6 (1)? Megjegyzem, az
els vltozat gyakorlatilag kizrt, hogy a vadonban is elforduljon.
Maradk hat bit: formtumlers, illetve kontroll bitek. (Vlasztk akad
bven, tokenbl is s keretbl is jutott rendesen.)
DESTINATION ADDRESS: Teljesen megegyezik az Ethernet fejezetben trgyaltakkal.
SOURCE ADDRESS: Dett.
~ 42 ~

IEEE 802.2 LCC HEADER: A szoksos.
PAYLOAD: Az IP Datagram.
FRAME CHECK SEQUENCE: A jl ismert CRC.
END DELIMITER: A Start Delimiterhez hasonlan J s K szimblumokat tartalmaz.
Tekintve, hogy az FDDI keretnek nincs rgztett hossza, ez a mez jelzi a keret vgt.
FRAME STATUS: kt bjt, a kvetkez bontsban:
ADDRESS RECOGNIZED INDICATOR: Amennyiben a megclzott lloms szreveszi a
kldsi szndkot, akkor ezt a bitet magasra lltja, jelezve ezzel, hogy j volt
a cmzs.
FRAME COPIED INDICATOR: Amikor a megclzott lloms hlzati krtyja
felkapja a frame-t, magasra lltja ezt a bitet, jelezve ezzel, hogy minden ok,
megkapta a keretet.
ERROR INDICATOR: Ha az FCS hibs, akkor az lloms magasra lltja ezt a bitet.
Termszetesen ebbl a keret formtumbl is ltezik SNAP vltozat.
FDDI:
http://www.javvin.com/protocolFDDI.html
http://www.laynetworks.com/FDDI.htm
~ 43 ~

3.1.4 IEEE 802.11,
A ZA Z
WIFI
Kezdjk azzal, hogy ez nem is egy szabvny. Hanem sok.

3.1. TBLZAT
IEEE
Megjelens
szabvny
802.11
802.11a
802.11b
802.11g
802.11n
802.11y
1997
1999
1999
2003
201016
2008
Mkdsi
frekvencia
[GHz]
2,4
5
2,4
2,4
2,4/5
3,7s
Jellemz
sebessg
(Mbps]
0,9
23
4,3
19
74
23
Maximlis
sebessg
[Mbps]
2
54
11
54
248
54
Hattvolsg
beltren [m]
Hattvolsg
kltren [m]
~20
~35
~38
~38
~70
~50
~100
~120
~140
~140
~250
~5000
A vezetknlkli hlzat node-jai ktfle mdon kommuniklhatnak egymssal:

Ad-hoc md: Kt node kzvetlenl kapcsoldik egymshoz.
Infrastructure md: Tbb node kapcsoldik egy Access Point-hoz (AP).
Brmelyik mdban is mkdik a vezetknlkli hlzat, mindig kell, hogy legyen egy
neve. Ezt Service Set Identifier-nek, azaz SSID-nek nevezzk. (Maximlis mrete 4
bjt.)
Gondolom, nem ettl koppan az llkapcsunk a padln: a vezetknlkli hlzatok
broadcast alapak. Ebbl persze az is kvetkezik, hogy nagyon knnyen
lehallgathatk. Tbb kisrlet is trtnt a hekkerek17 elhessegetsre:
Wired Equivalent Privacy, WEP: fj.
Wi-Fi Protected Access, WPA: so-so.
Wi-Fi Protected Access 2, WPA2: yes.
WPA, WPA2:
http://hu.wikipedia.org/wiki/WPA
ltalban a wifi:
http://en.wikipedia.org/wiki/802.11
http://hu.wikipedia.org/wiki/Wi-Fi
WIFI keret:
http://wifi.cs.st-andrews.ac.uk/wififrame.html
Nzzk akkor a kereteket.
16
17
Vrhatan. Amikor ezeket a sorokat rom - 2009 mrciusban - a Draft8 az aktulis verzi.
Definci: a hekker az a gonosz hacker.
~ 44 ~
3.12. BRA IEEE 802.11 F RAME FORMTUM
FRAME CONTROL: Ktbjtos mez, meglehetsen sok informcitartalommal.

Protocol version (2 bit)
Type (2 bit): Lehetsgek: management frame (00), control frame (01) s
data frame (10).
Subtype (4 bit): A fenti tipuson bell az altpusok.
To DS (1 bit): Ha magas, akkor az azt jelenti, hogy ez egy olyan csomag,
melyet egy wireless Access Point kldtt valamilyen vezetkes hlzat fel.
From DS (1 bit): Na, vajon?
More Fragments (1 bit): Ha magas, akkor azt jelzi, hogy a keret egy nagyobb,
fregmentlt keret tredke. Ha alacsony, akkor azt, hogy a keret vagy nem
fregmentlt, vagy ez az utols tredk.
Retry (1 bit): Ha magas, akkor ez egy jrakldtt keret.
Power Management (1 bit): Ha magas, akkor a felad node energiatakarkos
zemmdban mkdik.
More Data (1 bit): Ha magas, akkor a feladnak mg van mondanivalja.
(Azaz nem res a kimen puffere.)
WEP (1 bit): Ha magas, akkor a payload titkostott.
Order (1 bit): Ha magas, akkor a kereteket sorrendben kell feldolgozni.
~ 45 ~

DURATION/ID: Ktbjtos mez, gyakorlatilag egy idrtk, mikroszekundumban.
Mennyi idre van szksg a keret s az ACK tovbbtsra. (Ez utbbi a MAC alrteg
rsze.)
ADDRESS1: Hat bjt. Vagy a cllloms MAC cme (amennyiben a cl egy wireless
node), vagy egy SSID (amennyiben a cl egy Access Point).
ADDRESS2: Hat bjt. Amennyiben a felad egy wireless node, akkor MAC cm.
Amennyiben egy Access Point, akkor SSID.
ADDRESS3: Hat bjt. Brmilyen MAC cm vagy az SSID tallhat benne. A fogad
lloms hasznlja szrsi clra.
SEQUENCE CONTROL: Kt bjt. A tredezett keretek kezelsre szolgl.
Fragment Number (4 bit): A tredk sorszma.
Sequence Number (12 bit): Tulajdonkppen ez is a keret sorszma, de 4095
utn jraindul nullrl.
ADDRESS 4: Hat bjt. Opcionlis mez, az eredeti felad MAC cmt tartalmazza.
Tipikusan akkor van rtke, ha a To DS, From DS mezk nem resek.
FRAME CHECK SEQUENCE: CRC.
IEEE 802.2 LCC HEADER: Ezt mr ismerjk.
PAYLOAD: Alapveten hrom tipus hasznos teherrl beszlhetnk:
Control Frame: Request To Send (RTS), Clear To Send (CTS) s
Acknowledgement (ACK).
Management Frame: Authentication, Association, Beacon, Probe s kismilli
egyb.
IP Datagram: A klasszikus IP csomag a felettnk lv rtegbl.
A payload maximlis rtke 2312 bjt lehet, melyet a titkosts mg tovbb
cskkenthet, tekintve, hogy brmelyik mdszert is hasznljuk, be kell ldoznunk pr
bjtot a payloadbl.
Vgl a SNAP vltozat. Nos, egyfell ugyangy kpzdik, mint az sszes tbbi
hlzati technolginl, ezrt megint nem rajzolok. Msfell pedig tudni kell, hogy a
hasznlata ktelez. Mr amikor.
Mikor is? Csak az IP datagramoknl. Emlkezznk vissza, mikor sznapoltunk?
Amikor az IP datagramra utal paramtert mshol, egsz konkrtan az EtherType
mezn keresztl szerettk volna bemutatni. Logikusan: ha nincs IP datagram,
nyilvn nincs SNAP sem.
~ 46 ~

3.1.5 A L R T E G
P R O T O K O LL O K :
LLC
MAC
Az a bizonyos nem ltez Data Link Layer kt alrteggel is br. Ezek egsz konkrtan:
Logical Link Control (LLC) s Media Access Control (MAC).
A 802.2 LLC protokollt mr jl ismerjk. A korbbi fejezetek majd mindegyikben
felbukkan, mint egy kapszula. Tulajdonkppen a payload-ra tesz r egy headert. (A
DSAP, SSAP, Control mezk az IEEE 802.3 keret rszletezsnl lettek kibontva.)
LLC:
http://www.erg.abdn.ac.uk/users/gorry/course/lan-pages/llc.html
De mi a szsz ez a MAC alrteg? Az azonos hangzson kvl van-e ms kze is a MAC

cmhez?
Van:a MAC alrteg cmzsi mechanizmust hvjk MAC cmnek.
Irkltam itt mindenflt a barti trsasg udvarias beszlgetsrl, na meg a
modellvastrl. Ezeket sszefoglalan Channel Access Control Mechanism nven
illetik... s a MAC alrteg valstja meg, egsz konrtan az n. Multiple Access
Protocol (MAP) segtsgvel. Mint a neve is mutatja, ez a protokoll hivatott
biztostani azt, hogy tbb eszkz is kpes legyen kommuniklni ugyanazon a mdin.
Maga a MAP lehet mr akr az tkzsfigyels, akr a token krztets.
Media Access Control:
http://en.wikipedia.org/wiki/Media_Access_Control
MAC Address:
http://en.wikipedia.org/wiki/MAC_address
~ 47 ~
3.2 A DDRESS R ESOLUTION P ROTOCOL , ARP

RFC 826
Mint a neve is mutatja, itt bizony cmfeloldsrl lesz sz. Ez egy olyan protokoll,
mely az eggyel fentebb lv rteg jellemz cmhez - IP cm az Internet rtegben keresi meg a Data Link rtegbeli cmet, mely, mint nemrg rtam, a MAC address.
Kiskt jn.
Mely hlzati technolgik hasznljk?
Az eddig felsoroltak pldul nagyon. A PPP-n alapul WAN technikk meg nem
igazn - s akkor is fordtva.
Hasznlhat IP-MAC feloldson kvl msra is?
Igen. Csak nem hasznljk.
Milyen hatkrben hasznlhat?
Csak a legkzelebbi hop-ig. Teht olyan IP cm MAC addresst nem tudjuk
megkrdezni tle, mely nem a sajt subnetnkn van. Nyilvn nem is akarjuk.
A Windows Server 2008-ban lv ARP implementci klnbzik-e a Windows Server
2003-ban lvtl?
Bizony, igen. De erre ksbb mg visszatrnk. Stay tuned.
Magt az ARP kommunikcit az RFC 826 rja le. Ez alapjn ktfle zenettpust
klnbztethetnk meg:
ARP REQUEST: Egy node szeretn megtudni, hogy az ltala megclzott IP
cmhez milyen MAC address tartozik. Kld egy MAC szint broadcast
zenetet, benne a krt IP cmmel.
ARP REPLY: Az a node, aki magra vette a krst - azaz az IP cme megegyezett
az ARP request broadcast zenetben lv IP cmmel - kld vissza egy ARP
reply unicast zenetet.
Rgtn lthatjuk, mirt is nem j ms subnet-en lv node-ok esetn: broadcast. Az
nem szokott tmenni a routereken. HUB, Bridge, L2 Switch - mind ok.
IP router nem.
~ 48 ~
3.13. BRA ARP KRDEZZ - FELELEK
Az brn egy pingels folyamata ltszik. Az els csomag egy ARP request, mely az
Austek hlzati krtyt tartalmaz szmtgprl (192.168.1.100) jn, s a
192.168.1.111 IP cmhez tartoz MAC addresst krdezi. A msodik csomag egy ARP
reply az LG hlzati krtyt tartalmaz gptl, benne a krt IP cmhez tartoz MAC
address. Utna mr mehet is a ping.
Nzzk meg az ARP keretek felptst.
De elszr pozcionljuk helyre az ARP keretet. Hol tallhat, azaz kinek is a
payload-ja? Lapozzunk vissza a megfelel fejezethez (3.1.1.1 Ethernet II), lthatjuk,
hogy pldul az Ethernet II keret belseje lehet IP datagram (0x0800) vagy ARP keret
(0x0806). s persze nem csak az Ethernet II keret jhet szba, hanem minden egyb
eddig trgyalt keret is. (St, olyanok is, melyek eddig nem kerltek emltsre: ATM,
HIPPI, stb.) De a lnyeg akkor is lthat: az ARP nem rsze az IP-nek, hanem azzal
prhuzamosan tevkenykedik - azaz a Network Interface rtegben a keretek
tartalma lehet az eggyel fentebbrl jv IP datagramm, vagy a rtegen bell mozg
ARP csomag.
3.14. BRA ARP KERET
~ 49 ~

HARDWARE TYPE: Kt bjt, arra vonatkozik, hogy a Network Interface rtegben milyen
hlzati technikt hasznlunk. (Aranyos, ugye: az Ethernet frame fejlce utal arra,
hogy ARP csomag van benne, az ARP csomag fejlce meg arra, hogy Ethernet
keretben utazik.)
Az Ethernet kdja az egyes (0x00-01), a tbbi kdot az IANA weblapjrl lehet
lelopni.
Hardware Type kdok:
http://www.iana.org/assignments/arp-parameters/
PROTOCOL TYPE: Kt bjt, arra utal, hogy az ARP milyen protokoll szmra biztostja a
nvfeloldst. Elmletileg ugyanazok lehetnek az rtkei, mint az EtherType meznek
- gyakorlatilag ha nem 0x08-00 (IP), akkor a node eldobja a csomagot.
HARDWARE ADDRESS LENGTH: A hardware address jelen esetben a MAC address. Mint
tudjuk, ennek az rtke gyrilag begetve 6 bjt, de vannak olyan esetek, amikor 2
bjt is lehet. (Pl. Frame Relay.)
PROTOCOL ADDRESS LENGTH: Ez pedig az IP cm hossza. rtelemszeren az rtke fixen
418.
OPERATION: Kt bjt, az ARP keret tipust adja meg. Az ARP request tipusa 0x00-01,
az ARP reply tipusa pedig 0x00-02. A tbbi lehetsges rtket a korbban is emltett
weblapon tallhatjuk meg.
SENDER HARDWARE ADDRESS, SHA: A felad MAC cme.
SENDER PROTOCOL ADDRESS, SPA: A felad IP cme.
TARGET HARDWARE ADDRESS, THA: A cmzett MAC cme.
TARGET PROTOCOL ADDRESS, TPA: A cmzett IP cme.
Na, krem. Prbljuk meg elkpzelni, hogyan is nz ki egy ARP request. Addig ok,
hogy az OPERATION kdja 0x-00-02. De az utols ngy mezbl vajon melyiknek nem
lesz rtke? Ugye, tudjuk a felad MAC address-t, IP cmt, tudjuk a cmzett IP
cmt... logikus, hogy aTHA meznek kell resnek lennie.
Ellenrizzk le.
18
IPv6 esetn vajon mennyi? Vigyzz, beugrats krds: az IPv6 nem hasznl ARP-ot.
~ 50 ~
3.15. BRA ARP REQUEST
Itt lthat a korbbi ping capture kibontva. Miket is ltunk benne:
Az Ethernet frame fejlcben ott van a 0x0806 kd, teht a payload egy ARP
keret.
Az ARP keret szerint a hardvertipus Ethernet, a protokolltpus IP s az ARP
keret tipusa request.
A mretekkel nem kell foglalkozni, a 6/4 pros gyakorlatilag konstans.
Vgl, ha jobban megnzzk, lthat, hogy a THA mez rtke tnyleg csupa
nulla.
~ 51 ~
3.16. BRA ARP REPLY
Ez pedig az ARP reply vlasz. Nem akarok mr tl rszletesen belemenni, az elz

kp alapjn te is rtelmezhetsz rajta mindent. A lnyeg, hogy az SHA rtk
tartalmazza a helyes vlaszt.
Egy aprsgra hvnm mg fel a figyelmet. Az Ethernet frame vgn szerepel egy
Trailer mez, csupa nullval. Ez a Padding. Mint rtam, az Ethernet keretnek mindig
van minimlis mrete. Amennyiben a kldend csomag ezt nem ri el, nullkat
lknek a vgre.
Address Resolution Protocol:
http://en.wikipedia.org/wiki/Address_Resolution_Protocol
Ennyi volt a bemelegts. Vizsgljuk most meg, hogyan is trtnik konkrtan az ARP
nvfelolds megvalstsa. Hiszen, mint tudjuk, az rdg a rszletekben.
~ 52 ~

3.2.1 ARP
N V F E LO LD S
Magt a nvfeloldst mr lthattuk az elz oldalakon. Broadcast ARP request res

THA rtkkel, ARP reply helyes SHA rtkkel. A vilg egyszer.
Azrt a krdez mg megejt egy rpke ellenrzst, megnzi, hogy a reply-ban
visszakapott SPA megegyezik-e a request-ben kikldtt TPA rtkkel. Ha igen, akkor
beteszi a cmprt az n Neighbor cache-be19.
Termszetesen a vlaszol is berakja a sajt cache-be a krdez adatait. Hadd
gyljenek a fontos informcik.
A folyamat teljes rszletesggel az albbi brn lthat.
3.17. BRA A HAGYOMNYOS ARP KOMMUNIKCI
A Neighbor Cache pldul egy jdonsg. A korbbi Windows verziknl a cmek n. ARP cache-ben
voltak. A vlts nem csak azt jelenti, hogy a Windows 2008-ban tvettk az IPv6 terminolgit tvettk azokat a technikai vltoztatsokat is, melyekkel javtani lehetett valamit az IPv4-es
megoldsokon.
19
~ 53 ~

Gyors ismtls mirt is j egy ilyen cache? Arra, hogy ne kelljen llandan broadcast
zenetekkel tmni a csvet. s mirt is rossz? Mert knnyen be lehet vele csapni egy
gpet.
A becsapsnak ktfle mdja ltezik:
Alattomos informatikusok kicserlik az egyik gpben a hlzati krtyt. Vagy
trjk a MAC cmt. A cache-ben rossz bejegyzs marad, a csomagok rossz
cmre lesznek elkldve.
ARP Poisoning. Rosszfik kldenek egy preparlt ARP request csomagot a
kiszemelt ldozatnak. Az onnantl azt fogja hinni, hogy a cache-ben trolt IP
cmnl megvltozott a MAC address (mert az informatikusok vagy kicserltk
benne a krtyt, vagy trtk a MAC cmt).
Man in the Middle tmads:
http://tudastar.netacademia.net/default.aspx?upid=2836
Lthatod, a helyzet mgsem olyan egyszer. Ha automatikusan elfogadom a

vltozsokat, akkor trhet a gp. Ha nem, akkor egy vltozs esetn a fekete lyukba
kldm a csomagokat.
Megolds?
Egy apr mdosts. A korbbi Windows-ok mr akkor mdostottk a cache-ben
lv bejegyzskben a felad cmt, amikor megkaptk az els, j MAC cmet
tartalmaz ARP request csomagot (3.17. bra A hagyomnyos ARP kommunikci). A
Windows 2008 ellenben ekkor mg nem: visszakrdez (broadcast) s megvrja a
vlaszt20.
Ha mr az eltr viselkedsekrl van sz. Szp nagy pofonba lehet beleszaladni, ha
Windows Server 2008-bl rakunk ssze multicast NLBS rendszert - s gy
kpzeljk, hogy minden ugyangy fog mkdni, mint Windows Server 2003 esetn.
Nos, nem.
Meglepdve fogjuk tapasztalni, hogy a clusternket ms subnetbl nem fogjk
elrni. Pedig rnzsre minden rendben, subneten bell mkdik is hibtlanul.
A jelensg mgtt ARP nvfeloldsi gubanc rejtzik.
Windows 2008 NLBS esetn amikor subneten kvlre szeretne csomagot kldeni a
cluster, akkor a virtulis krtyjrl kld ARP request-et a router fel. Ekkor az SPA
unicast IP cm, mg az SHA multicast MAC address. Nos, ez a kombinci ltalban
szinte leszek: ebben nem vagyok 100%-ig biztos. Az ltalam hasznlt forrsok teljesen kdsen
fogalmaztak. rkig trtam a netet, de ott sem talltam egyrtelm inft. Addig ok, hogy a forrsok
szerint a Windows Server 2008 mg vr egy krt - de szerintem gy lenne logikus, ha ezt a krt __
kezdemnyezn: egybknt a gonosz fi kldene mg egy request-et, oszt jl van.
20
~ 54 ~

kiveri a biztostkot a routereknl. Lenyelik a request-et, nem kldenek vissza
vlaszt - enlkl viszont a cluster nem tudja elkldeni a csomagot.
Korbban a Windows 2003 NLBS ilyen esetekben csalt egy kicsit: nem a virtulis
krtya IP cm / MAC address prost kldte el, hanem annak a valsgos krtynak
az rtkeit, amelyen a virtulis krtya ki lett alaktva. Ezzel persze mkdtt a
nvfelolds.
Nos innentl kezdve kt dolgot tehetnk. Vagy megvrjuk, amg a Microsoft kitall
valamit - vagy a keznkbe vesszk a dolgot. Ez utbbi abbl ll, hogy az NLBS cluster
sszes node-jn felvesszk a Neighbor Cache-ba a router IP cm - MAC address
prost.
Kt lehetsgnk van:
Arp s <IP address> <Mac Address>
netsh interface ipv4 set neighbors "hlzati krtya neve" "<ip-Address>" "<Mac-Address>"
A msodiknak megvan az az elnye, hogy kikapcsols utn is megmarad.

Unable to connect to Windows Server 2008 NLB Virtual IP Address from hosts in different subnets when
NLB is in Multicast Mode:
http://tinyurl.com/chd56l
~ 55 ~

3.2.2 D UP LI K LT
C M M E G HA T R O Z S
Ezzel messze nincs mg vge a gubancoknak. Mi van pldul akkor, ha a gratuitous

ARP-ra brmilyen vlasz is jn?
Egyike az let nagy krdseinek. Az meg klnsen, hogy mi a fene is egyltaln ez a
gratuitous ARP? Ezrt nem kell fizetni? A tbbirt meg igen? Vagy inkbb csak
felesleges?
Nem egszen. A gratuitous ARP egy olyan ARP request, melyet sajt magunknak
kldnk ki - azaz a TPA s az SPA megegyezik. Aztn vrjuk, hogy jn-e r vlasz. Ha
igen, akkor baj van: tbb pldnyban lteznk. Jogos a krds, mirt is tennnk
ilyesmit? Ht, pldul be szeretnnk illeszkedni egy hlzatba s kivncsiak
vagyunk, hogy mennyire egyedi az IP cmnk a subneten.
Induljunk ki abbl, hogy megtrtnt a baj. Kiderlt, hogy kett van bellnk. Mi az
els dolgunk? Termszetesen az, hogy tisztzzuk, kit hogy hvnak. Mi magunk - a
prbajkdex szerint - a tmad felek vagyunk, a msik pedig rtelemszeren a
vdekez fl lesz21. (Angolban offending node s defending node.)
A kvetkez lps az lesz, hogy megnzzk, mit is csinltunk eddig. Kikldtk a
gratuitous ARP request-et. A vdekez node felvette, hiszen az neki szlt, majd
ugyanazzal a mozdulattal be is rakta a sajt ARP cache-be, miszerint ehhez az IP
cmhez a mi MAC cmnk tartozik.
Hopp. Ezzel most jl kibabrltunk. Hiszen csak krdezni akartunk.
Nosza, gyorsan tegyk rendbe a dolgokat. Rakjunk ssze egy msik ARP csomagot,
ahol az SHA mezbe a vdekez node MAC addresst rjuk, az IP cmek meg
maradnak ugyanazok, mint a gratuitous ARP csomagban. A vdekez node - s
persze mindenki ms is a subneten - felkapja ezt a csomagot is, majd korrigl a
cache-ben... azaz visszall az eredeti llapot.
Huhh.
Akit esetleg zavar, hogy a msik fl a vdekez, gondoljon arra, hogy arrl van sz, hogy mi lpnk
be j fiknt abba hlzatba, ahol a tbbieknek mr rgta megvan a knyelmes, jl bejratott IP
cme.
21
~ 56 ~

J ez neknk? Nem igazn. A Windows 2008/Vista vonalon mr nem is gy mkdik.
Egyfell a tmadknt kiadott gratuitous ARP mr nem tartalmazza a felad
IP cmt - azaz az SPA res. Mit fog csinlni a vdekez fl? Felkapja, rakn be
az IP cmet a cache-be... de ht az res. Nem is rakja be.
Ha mi vagyunk a vdekezk s kapunk egy hagyomnyos gratuitous ARP
krst... nos, mr vagyunk annyira okosak, hogy fel tudjuk ismerni - s nem
rakjuk be az ARP cache-be. Csak azrt sem. gy a rgtn utna rkez Bocsesz
gratuitous ARP request-tel sem kell foglalkoznunk.
Kivesztk mr a tmt? dehogy.
Mi is trtnik velnk, mint tmadkkal, az utn, hogy visszakaptuk azt a bizonyos
duplikcit jelz ARP reply zenetet? Attl fgg. Ha manulisan konfigurlt IP
cmnk van, akkor az tvlt APIPA IP cmre, persze egy eventlog bejegyzs s egy
figyelmeztet zenet kisretben.
Amennyiben DHCP szervertl kapjuk az IP cmet - jelen esetben a rossz IP cmet akkor egsz egyszeren kldnk a DHCP szervernek egy DHCPDECLINE zenetet.
Nem kell az IP cmed, kgyl egy msikat. Ha a DHCP szerver egy Windows Server
2008 alapokon fut szerver, akkor meg is jegyzi ezt az IP cmet, nehogy ksbb
ismt kikldje. Majd kld egy msikat.
Ezekben az esetekben rendezdtt a helyzet. De mi van akkor, ha bekapcsoltak egy
szmtgpet, mely nincs rajta a hlzaton s van egy manulisan konfigurlt IP
cme? Aztn, miutn felllt rajta a TCP/IP, rdugjk a hlzatra, ahol mr van egy
msik gp, ugyanezzel az IP cmmel. Van ilyenkor gratuitous ARP? Szomor, de
nincs. A kt node ugyanazzal az IP cmmel fog dolgozni. Termszetesen
mindkettnek az eventlogja tele lesz hibazenettel, hiszen az ARP keretek alapjn
szlelni fogjk egyms jelenltt - de a javtsra mr kptelenek.
~ 57 ~

3.2.3 F EK ET E
LY UK D E T E K T L S A
Mi is az a fekete lyuk?
Eddig beszltnk arrl az esetrl, amikor egy node IP cme mr ltezett azon a
hlzaton, ahov be akart nyomulni. Ezt le lehetett rendezni.
De mi van akkor, ha egy node-ot lekapcsoltunk? A felad gp cache-ben mg ott van
a bejegyzs, adott esetben kldi is neki a csomagokat. Ciki, de ekkor visszajelzs sem
jn arrl, hogy a csomagok elnyeldtek - egyszeren eltntek a fekete lyukban. Amg
a cache ki nem rlt, addig bizony nem is trtnik vltozs. (Ok, a TCP/IP
magasabb rtegeiben lv protokollok, szolgltatsok szleltk, hogy nem jtt ltre a
kapcsolat. De ARP szinten a nvfelolds ltszlag mkdtt, hiszen megvolt a MAC
address, ssze lehetett lltani a csomagokat s el lehetett kldeni azokat a nagy
semmibe.)
A Windows 2008/Vista oprendszerekben mr ltezik egy n. Neighbor
Unreachability Detection metdus.
Ehhez viszont meg kell ismerkednnk egy j szereplvel. gy hvjk, hogy unicast
ARP request. Az elv egyszer: ha meg akarunk gyzdni arrl, hogy egy tetszleges
node l-e mg, akkor direktben kldnk neki egy ARP request-et s vrjuk a hozz
tartoz ARP reply-t. Vigyzat, a vizsglati mdszer nem megfordthat! Teht az ARP
reply megrkezse utn az rdekld biztos lehet benne, hogy a msik node
mkdik... de aki a reply-t kldte vissza, az nem lehet biztos abban, hogy az tnyleg
meg is rkezett, azaz a felad elrhet a szmra.
Ez az egyik mdszer. Melyik lehet a msik?
Mr cloztam r. Ott vannak a fentebb lv protokollok. Pldul a j reg TCP. Az
ugye llandan visszajelzseket kr. Mi lenne, ha figyelnnk, hogy ezek tnyleg
megrkeznek-e a tloldalrl?
Ok, ezek az eszkzk. Hogyan pl fel ebbl egy algoritmus?
~ 58 ~

gy, hogy a cache bejegyzsek mell llapotot jelz informcik kerlnek. Ezek
jelzik, hogy mi is ppen most a helyzet a bejegyzett rtkkel.
A lehetsgek:
INCOMPLETE: ppen folyik az ellenrzs egy frissiben ltrejtt bejegyzsnl.
REACHABLE: Megjtt az ARP reply a node-tl, minden ok. Fontos elem, hogy
ez a bejegyzs nem az rkkvalsgig tart. Egy bizonyos idtartamon bell
vletlenszer ideig l a bejegyzs, utna meg kell jtani - feltve, hogy a
tvoli node nem adja folyamatosan jelt a ltezsnek. Ez gyakorlatilag azt
jelenti, hogy minden sikeres TCP visszajelzs utn a szmll jraindul.
STALE: Letelt a Reachable Time. Amg jra meg nem bizonyosodunk ismt a
tvoli node ltezsrl, addig ebben az llapotban marad a bejegyzs.
DELAY: Amikor a bejegyzs mr Stale llapotba kerlt, de mg nem kldnk ki
neki unicast ARP request csomagot, mert htha a TCP mg aktivizlja magt.
(Ez az elmlet. A gyakorlatban a Windows Server 2008/Vista kihagyja ezt a
lpst.)
PROBE: ppen ellenrizzk egy korbban Stale/Delay llapotba kerlt
bejegyzs valdisgt. Nyilvn unicast ARP request csomaggal.
Ha mr itt jrunk, emltsk meg, milyen lehetsgeink vannak manulisan
befolysolni a cache tartalmt.
Pldul trlhetjk:
arp -d *
netsh interface ipv4 delete neighbors
Kilistzhatjuk:
arp -a
netsh interface ipv4 show neighbors
Hozzadhatunk manulisan rtkeket:

Lsd az NLBS clusteres linket.
~ 59 ~

3.2.4 I N V ER S E ARP, R EV ER S E ARP, P RO XY ARP
Defnicikra fogok szortkozni, minimlis krtssel. Pusztn csak azrt, hogy ne
nzznk tgranylt szemekkel, ha a cmben szerepl kifejezsekkel sszefutunk
valahol.
INVERSE ARP: Szigoran a Non-Broadcast Multiple Access (NBMA) rendszereknl
hasznljk. Ezek WAN technolgik, olyasmik, mint pl. a Frame Relay, ATM vagy az
X.25. Itt ltalban a hardver azonost az ismert, az IP cm pedig nem. Ebbl
kifolylag az ARP alrteg mdszereit, az ARP keretszerkezetet tvettk ugyan, de
pont fordtva hasznljk fel: hardver azonostbl keresnek IP cmet.
REVERSE ARP: Nagyon hasonl az Inverse ARP-hoz, legalbbis olyan szempontbl,
hogy hardverazonosthoz keres IP cmet. Csakhogy ezt a metdust mr nem csak a
fenti WAN technolgik hasznltk, hanem gyakorlatilag mindegyik ms is,
mghozz olyan clbl, hogy IP cmet ignyelhessenek maguknak. Aztn jtt a
BOOTP s elsprte a francba az egszet... majd jtt a DHCP s elsprte a francba a
BOOTP-t22. Szval ennyire aktulis dologrl van sz.
PROXY ARP: Gondolom, mr vrtuk. Megszoktuk mr, hogy a gonosz routerek
mindenhol bekavarnak, emiatt kell DHCP proxy, meg WINS proxy... nyilvn lesz
valamilyen proxy az ARP-hoz is.
Milyennek kpzeljk? Mondjuk, van egy router, a kt lbn kt subnet. Aztn az
egyiken elindul egy ARP Request egy olyan node fel, mely a msik lbn lg, erre a
Proxy ARP felkapja a krst s tdobja a tloldalra.
Egyszer, nem?
Lehet... de ez a koncepci ezer sebbl vrzik.
Elszr is, nem nagyon mszklhat a drton olyan ARP Request csomag, melyben a
felad IP cme s a cmzett IP cme ms alhlzatokhoz tartozik. Ilyenkor ugyanis a
node nem a msik node MAC cmre szokott kvncsi lenni, hanem sokkal inkbb a
vele egy alhlzaton lv default gateway MAC cmre.
De mg ha van is ilyen csomag, a router akkor sem dobja t a tloldalra, hanem
hazudik, azaz amikor az egyik oldalon krdeznek tle egy MAC cmet, akkor a
sajtjt adja vissza, mondvn, hogy kldd csak el nekem a csomagot, n majd tudom,
mit kell kezdenem vele. Mg konkrtabban: Data Link Layer szinten a Proxy ARPknt viselked router egyszeren csak hazudik, majd ha a hazugsg rvn
hozzkerl a csomag, akkor mr L3 szinten routolja.
J krds, hogy most akkor tekerhet-e ilyen specilis csomag a drton?
22
Ez egy hatsos bon-mot, de nem teljesen igaz. PXE boot esetn mg hasznljk a BOOTP-t.
~ 60 ~

Egy kedves olvas hvta fel r a figyelmemet, hogy bizony igen.
Sometimes called promiscuous ARP and described in RFCs 925 and 1027, proxy ARP is a method by which
routers may make themselves available to hosts. For example, a host 192.168.12.5/24 needs to send a
packet to 192.168.20.101/24, but it is not configured with default gateway information and therefore
does not know how to reach a router. It may issue an ARP Request for 192.168.20.101; the local router, receiving
the request and knowing how to reach network 192.168.20.0, will issue an ARP Reply with its own data link
identifier in the hardware address field. In effect, the router has tricked the local host into thinking that the
router's interface is the interface of 192.168.20.101. All packets destined for that address will be sent to the
router.
Jeff Doyle :Routing TCP/IP Volume I.
Azaz ha a node-nak nincs belltva semmilyen default gateway rtke, akkor vgs
elkeseredsben kikldhet egy ARP request-et, melyet mr kezelni tud a Proxy ARP.
Jl hangzik... de engem teljesen megzavart. n ugyanis ms knyvbl tanultam, s
abban azt mondja Joseph Davies, hogy Windows rendszerekben kt helyen
tallkozhatunk Proxy ARP funkcival:
Windows Server 2008/Vista opercis rendszerekben a Network Connection
folderben a Network Bridge kpessg pont ezen alapul.
Windows Server 2008-ban amikor a RAS oszt a subneten bellrl egy
elklntett IP znbl cmeket, akkor gyakorlatilag ugyanilyen bridzsels
jtszdik le.
Ami egyrtelmen azt jelzi, hogy a Proxy ARP csak akkor mkdik, ha a proxy
egysg kt oldaln ugyanaz a subnet tallhat.
Nzzk meg a Wikipedia-t.
For example, suppose a host, say A, wants to contact another host B, where B is on a different subnet/broadcast
domain than A. For this, host A will send an ARP request with a Destination IP address of B in its ARP packet. The
multi-homed router which is connected to both the subnets, responds to host A's request with its MAC address
instead of host B's actual MAC address, thus proxying for host B. In the due course of time, when host A sends a
packet to the router which is actually destined to host B, the router just forwards the packet to host B. The
communication between host A and B is totally unaware of the router proxying for each other.
http://en.wikipedia.org/wiki/Proxy_arp
Ez bizony egyrtelmen az els verzi. Viszont wikipedia.

De mit r errl a TCP/IP Guide?
In contrast to the normal situation, in some networks there might be two physical network segments connected
by a router that are in the same IP network or subnetwork. In other words, device A and device B might be on
different networks at the data link layer level, but on the same IP network or subnet.
http://www.tcpipguide.com/free/t_ProxyARP.htm
~ 61 ~

Akkor most melyik az igaz??
J hrem van: mindkett. A legels idzet ugyanis Cisco routerekre vonatkozik s a
magam rszrl biztos vagyok benne, hogy ezek tnyleg tudjk azt, amit lltanak
rluk. Azaz a Proxy ARP komponensk tnyleg le tudja kezelni azt a szitucit,
amikor az ARP Request-ben ms alhlzatba tartozik a kt IP cm.
Msfell viszont Windows rendszerekben nem fordulhat el ilyen ARP Request.
Nem lltom, hogy minden Windows verzit leteszteltem, de a sajt gpemet igen.
Leszedtem a hlzati krtyrl minden komponenst, csak a TCP/IPv4 maradt rajta.
Abbl meg trltem a default gateway rtkt. jraindtottam a gpet, kirtettem az
ARP cache-t, elindtottam a Wireshark-ot s lelkesen nekilltam pingelni, telnetelni.
Semmi. Habr a parancssorban kaptam rendesen a hibazeneteket, de a sniffer nem
mutatott semmit.
Azaz lehet, hogy a routerem tnyleg tudta volna a Proxy ARP-ot, de a Windows
szleli, hogy nem frank a hlzat belltsa s nem is enged ki a hlzatra
semmilyen idita csomagot.
Lergtunk minden csontot? Nem. Egy kedves olvas kldtt egy pldt arra, hogyan
fordulhat el Windows rendszerekben is ilyen csomag.
Igen, jl ltod, ez egy durvn flrekonfigurlt rendszer. De nem elkpzelhetetlen. A

PC0 rnzsre mg a routert sem kpes elrni, hiszen nincsen vele egy subneten.
(Vigyzat, csalok. Errl majd ksbb.) De a PC1-rl azt hiszi, hogy vele igen. Ezrt
kld neki egy ARP request broadcast-ot, melyet elkap a router is. Ha olyan fajta (pl.
Cisco, ahol alaprtelmezsben be van kapcsolva a Proxy ARP), akkor ccg egyet,
megcsvlja a fejt, s behazudja a sajt MAC cmt a PC1 MAC cme helyett.
Mindenfle ARP-ok:
http://www.javvin.com/protocolARP.html
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080094adb.shtml
~ 62 ~
3.3 WAN
TECHNOLGIK
3.3.1 P O I N T T O P O I N T P R O T O CO L , PPP
Elre szlok, hogy ez egy kimerten hossz fejezet lesz. Mr most tegyl fel fni egy
kvt. Literes fazkban.
Kezdjk ott, hogy habr protokollnak hvjk, de a PPP nem az. Sokkal inkbb egy
protokollcsald. Meglehetsen sok alprotokollt tartalmaz, ezek j rszvel meg is
fogunk ismerkedni.
Mire is j?
Ha a nevbl indulunk ki, akkor taln nem lesz olyan nagy a meglepets: pont s
pont kztti kapcsolat menedzselshez szksges protokollkupacrl lesz sz.
Mivel csak kt pontrl van sz, egy csom eddig tanult dologra nincs szksgnk.
Nyugodtan kidobhatjuk, a unicast/multicast/broadcast fogalmakat. Ember, csak kt
node van. Igazbl se barti beszlgetsrl, se kisvonatrl sem beszlhetnk. Vajon
fogunk tallkozni Data Link Layer szint cmzssel, azaz MAC addressel?
Nem.
Csak.
Kt.
Pont.
Van.
A PPP eldje - a SLIP - ennek megfelelen egyszer is volt, mint a fak. Csak TCP/IP-t
tudott tpasszrozni a drton, kptelen volt vezrlparamtereket egyeztetni s az
autentikcihoz is zokni volt. A PPP mindezeket tudja, st tbbet is. Radsul
nagyjbl ugyanolyan sebessget biztost, mint a jval egyszerbb SLIP - gy
egyltaln nem csoda, hogy teljesen kiszortotta. A Windows Server 2008 s a Vista
mr nem is tmogatja az SLIP-t.
SLIP vs PPP:
http://sunsite.nus.sg/pub/slip/slip-vs-ppp.html
PPP:
http://en.wikipedia.org/wiki/Point_to_Point_Protocol
http://www.cisco.com/en/US/docs/internetworking/technology/handbook/PPP.html
http://www.tcpipguide.com/free/t_PointtoPointProtocolPPP.htm
~ 63 ~

Mint rtam, egy kteg protokoll. Ezek alapveten hrom kategrikba sorolhatk:
Data Link Layeren bell csomagolgat protokollok, melyek biztostjk azt,
hogy ugyanazon a drton, akr egyidejleg is, klnbz magasabb szint
protokollokhoz tartoz csomagok tekerjenek.
Link Control Protocol (LCP): a kapcsolat paramtereinek klcsns
megtrgyalst, egyeztetst vgz protokollcsald.
Network Control Protocols (NCPs): Protokollokat kontrolll protokollok. A
PPP-n klnbz protokollok hznak t, ezeknek a paramtereit egyeztetik a
kt vgpont kztt az NCP-k. (Ilyen pldul az Internet Protocol Control
Protocol, azaz IPCP.)
Kezdjk a boncolst a szoksos mdon. Nzzk meg, hogyan pl fel egy PPP
csomag.
Ht. gy, ahogyan egy HDLC (High-Level Data Link Control) csomag. Abbl
szrmazik.
3.18. BRA PPP CSOMAGOLS HDLC KERET SEGTSGVEL
FLAG:
Az elefnt farka s ormnya. Mint a gyerekkori viccben, ez jelzi, hogy hol

kezddik s hol vgzdik az elefnt. Az rtke fix: 0x7E.
ADDRESS: Az eredeti HDLC keretben ebben az 1 bjtban volt a megclzott node cme.
Mint rtam, itt sszesen kt pont van, teht ez a mez meglehetsen felesleges. Az
rtke ennek is konstans: 0xFF.
CONTROL: Ez a mez is igazbl a HDLC kommunikciban virt. Az rtke PPP
csomag esetn konstans, illeszkedve a HDLC keret szablyaihoz: 0x03.
~ 64 ~

PROTOCOL: Az els nem konstans mez. A szlltott protokollra utal. (Az IP pldul
0x00-21, a Novell IPX meg 0x00-2B.)
FRAME CHECK SEQUENCE: A j reg CRC, igaz, kiss rvidebb, mint ahogy
megszokhattuk.
Nem tudom, te hogy vagy vele, engem hatrozottan zavart mr els olvasskor is ez
a svszlessg-pazarls. rtelmetlen konstansokat kldzgetnk? Ilyen jl llunk a
drtokkal?
Nyilvn ez nem csak nekem jutott eszembe. Ltezik egy msik PPP csomag is.
3.19. BRA L EEGYSZERSTETT PPP CSOMAG
Megsgom, ez a gyakoribb.
Az, hogy a konstans mezk elmaradtak, gondolom nem lep meg senkit. De nzzk
csak meg, mi trtnt a Protocol mezvel? sszezuhant. Kt bjt helyett egy lett.
Tanulmnyozzuk t ezt a tblzatot:
http://www.iana.org/assignments/ppp-numbers.
Lthatjuk, hogy a legsrbben hasznlt protokollok esetben a fels bjt res. Nincs
r szksg.
Persze jogos lehet a krds, hogy mi van akkor, ha felvltva jn IP csomag meg
mondjuk IPCP (0x80-21)? Nos, itt mutatkozik meg a PPP nagy ereje, a rugalmassg.
Ahogy korbban is rtam, a PPP egyik protokollja az LCP, a Link Control Protocol. Ez
egy olyan protokoll, melyen keresztl a PPP-re vonatkoz belltsokat egyezteti le a
kt node.Teht mind azt, hogy elhagyhat-e az ADDRESS mez, vagy a CONTROL mez,
vagy olyan protokollrl lesz sz, amelyiknl az als bjt res-e... mindezt az LCP-n
keresztl beszlik meg a felek. Utna pedig nyilvn mr tudjk rtelmezni a
csomagokat.
~ 65 ~

Mg nhny kis szines a PPP csald letbl.
A PPP csomagoknak is van maximlis mretk (MTU, azaz itt inkbb Maximum
Receive Unit, azaz MRU). Csak ppen nem fix mretek. Az MRU maximlis rtke
65535, a kiindulsi rtke 1500 bjt, a tnyleges rtke pedig helyzettl fgg. A felek
LCP-n keresztl llapodnak meg.
Amikor a kt node kztti vonalrl beszlnk, akkor nem felttlenl egy madzagra
kell gondolnunk. A PPP kpes arra is, hogy kt node kztt prhuzamos kiplt
csatornkat (tipikus plda ISDN B csatornk) egyknt kezeljen. Ezt gy hvjk, hogy
PPP Multicast Protocol. Ehhez egy teljesen ms keret szerkezet tartozik. Ha nem
haragszol, ezt nem rajzoltam meg.
A lnyeg, hogy a forgalom fragmentlva van, maguk a tredkek pedig szpen le van
kezelve: sorszmok, pozci rtkek jelzik, hogy mi s hol ment t a drton.
Sllyedjnk.
Alapveten egy PPP kapcsolat felptse ngy lpsbl ll:
PPP konfigurls LCP-vel.
Autentikci.
Visszahvs.
Protokoll bellts NCP-vel.
~ 66 ~
3. 3 .1 . 1 PPP K O N F I G U R L S LC P- V E L
RFC 1662
Induljunk ki a teljes HDLC keretbl, ezen egyszerbb megmutatni, hol is jelenik meg
az LCP.
3.20. BRA A Z LCP KERET FELPTSE
Ugye, ltjuk? Ha sszehasonltjuk a korbbi brval (3.18. bra PPP csomagols

HDLC keret segtsgvel), nem nehz szrevenni, hogy minden ugyanaz, csak az IP
datagram helyett itt LCP keret van.
Nos, igen. Az LCP informcik teljesen ugyanolyan csomagban utaznak, mint
amilyen a teljes PPP csomag. Hogy mirt a teljeshez hasonlt? J vicc, az LCP-nek
nincs LCP-je, hogy letisztzza, mit lehetne elhagyni.
~ 67 ~

RFC 1661
Nzzk a csomag belsejt.
CODE: 1 bjtos mez, az LCP zenet tipust jelzi.
3.2. TBLZAT
CODE Kerettpus
1
Configure-Request
2
Configure-Ack
3
Configure-Nak
4
Configure-Reject
5
Terminate-Request
6
Terminate-Ack
7
Code-Reject
8
Protocol-Reject
9
Echo-Request
10
Echo-Reply
11
Discard-Request
Lers
Vgjunk bele egy PPP kapcsolat felptsbe.
Amennyiben elfogadtuk a Configure-Request-et, akkor kldnk egy ACK-ot.
Amennyibe felismertk a konfigurcis opcikat, de azok elfogadhatatlanok.
Amennyiben nem ismertk fel a konfigurcis opcikat.
Zrjuk le a PPP kapcsolatot.
Elfogadtuk a lezrst.
Nem ismertk fel a kdot.
Nem ismertk fel a protokollt.
A PPP kapcsolat tesztelse
Vlasz a PPP kapcsolat tesztelsre
A linken tli kapcsolat tesztelse
IDENTIFIER: 1 bjtos mez, egy rtk, mely sszekapcsolja a krseket s a vlaszokat.

LENGTH: 2 bjtos rtk, az LCP zenet mrete.
DATA: Maga az LCP zenet. A lnyeg. Ezt hamarosan tovbb is fogjuk boncolni.
Ok, akkor ahogy igrtem, belessuk magunkat az LCP adatok (DATA) vilgba.
Kezdjk azzal, hogy tippeljk meg: vajon mindegyik kd rtkhez van-e rtelme LCP
adatokat is kldeni? Ugye, nem? Gyakorlatilag csak a 'Configure' tipus LCP
keretekhez tartozik adatmez is.
Metljk tovbb az LCP keretet.
~ 68 ~
3.21. BRA LCP O PTION EGY LCP KERETBEN
Az LCP DATA mez egy vagy tbb n. LCP OPTION blokkbl ll. Ezekben a
blokkokban utaznak a tnyleges konfigurcis paramterek.
Az LCP OPTION felptst egy korbbi brn (3.21. bra LCP Option egy LCP
keretben) lthatjuk.
TYPE: Az opci tpusa.
LENGTH: A konkrt Option mrete. Tbbfajta Option blokk ltezhet.
OPTION DATA: Most mr tnyleg eljutottunk a konfigurcis paramterekhez.
A lehetsges rtkeket a kvetkez tblzat tartalmazza.
~ 69 ~
3.3. TBLZAT
Option Name
Maximum Receive Unit (MRU)
Type
1
Length
4
Asynchronous
Control
Character Map (ACCM)
Authentication Protocol
5 v. 6
Magic Number
Protocol Compression
5
7
6
2
Address and Control Field

Compression
Callback
13
3.4. TBLZAT
Autentikci kdja
0xC2-27
0xC2-23-81
0xC2-23-05
0xC0-23
~ 70 ~
Lers
A konkrt PPP kapcsolatban szllthat maximlis
csomagmret.
Aszinkron kapcsolatban melyik ASCII vezrljel legyen az
Escape.
A PPP kapcsolatban melyik authentikcit hasznljuk. Az
rtkeket a 3.4. tblzat tartalmazza.
Vletlenszm hurokdetektlsi clbl.
Flag. A felad ezzel jelzi, hogy egybjtos protokollazonostt
szeretne hasznlni.
Flag. A felad ezzel jelzi, hogy nem szeretne Address s
Control mezket ltni a csomagokban.
Valamikor a visszahvs egyeztetsre hasznltk. Ma mr
erre a CBCP Network Control Protocol szolgl.
Autentikci neve
Extensible Authentication Protocol (EAP)
MS CHAPv2
Message Digest v5 Challange Handsake Authentication Protocol (MD5-CHAP)
Password Authentication Protocol (PAP)
3. 3 .1 . 2 PPP A U T E N T I K C I
Lm, lm eljutottunk az autentikcikig. J ideig itt is fogunk idzni.

Mint eddig is lthattuk, az LCP-n bell a felek letisztztk, milyen autentikcit
fognak hasznlni. Windows Server 2008 illetve Vista alatt a kvetkezk jhetnek
szba:
Password Authentication Protocol (PAP)
Challenge Handshake Authentication Protocol (CHAP)
Microsoft Challenge Handshake Authentication Protocol version2 (MS-CHAP
v2)
Extensible Authentication Protocol (EAP)
3.3 .1 .2 .1 P A S S W O R D A U T H E N T I C A T I O N P R O T O C O L , PA P
RFC 1334
Habr azt rtam, hogy "jhetnek szba", de ennl az autentikcinl ezt nem kell
szszerint rteni. Ha lehet, akkor maradjunk annyiban, hogy ez inkbb szba sem
jhet.
Mirt is nem? Mert plain-text formtumban kldi t a jelszt a drton. Ami azrt elg
gz. Nem is ajnlott les krnyezetben hasznlni, maximum csak vonaltesztelsi
clokra, egyszer hasznlatos felhasznlkkal.
Nzzk akkor a koreogrfit:
Els krben a kapcsoldni kvn fl kld egy PAP Authentication-Request
csomagot az autentikl flnek. Ebben a csomagban benne van a kapcsoldni
vgy felhasznl neve s jelszava. Plain-text. Nan.
Az autentikl fl erejt megfesztve kikdolja a jelszt, majd sszehasonltja
a nla trolt usernv/password prossal. Ha stimmel, akkor egy PAP
Authentication-ACK csomagot kld vissza. Ha nem, akkor egy PAP
Authentication NAK csomagot.
Nem sok egyszerbb dolog ltezik a vilgon.
Ugyanez csomagszinten - pusztn csak azrt, hogy ha elkapunk egy ilyen csomagot a
hlzaton, akkor ne jjjnk zavarba a jelsz kiolvassnl.
~ 71 ~
3.22. BRA PAP R EQUEST
PROTOCOL: Az autentikci tipusa. PAP esetn 0xC0-23.

CODE: Egy bjtos rtk, a csomag tipusra utal. Az Authentication-Request rtke 1.
IDENTIFIER: Egy bjtos rtk, mely az sszetartoz PAP csomagokat azonostja.
LENGTH: Vajon? Az egsz csomag mrete.
ID LENGTH: Egy bjtos rtk, a felhasznl nevt tartalmaz, vltoz mret

mez mrete.
PEER
PEER ID: A felhasznl nevt tartalmaz vltoz mret mez.

PASSWORD LENGTH: Egy bjtos rtk, a felhasznl jelszavt tartalmaz, vltoz mret
mez mrete.
PASSWORD:
A felhasznl jelszavt tartalmaz vltoz mret mez. (Igen, ezt kell

kiolvasni a csomagbl.)
Nzzk ugyanezeket a vlaszcsomagnl.
~ 72 ~
3.23. BRA PAP A UTHENTICATE
PROTOCOL: Ugyanaz.
CODE:
Nagyjbl ugyanaz. Az Authenticate-ACK rtke 2, az Authenticate-NAK rtke
3.
IDENTIFIER: Ugyanaz.
LENGTH: Ugyanaz.
MESSAGE LENGTH: Egy bjtos rtk, az zenetet tartalmaz, vltoz mret mez
mrete.
MESSAGE: Itt lehet tetszleges szveget zenni az autentiklni kvn flnek. A
Windows nem hasznlja ezt a mezt.
Nos, ez volt a legegyszerbb autentikci. Nem biztos, hogy megnyugtat, de ennl
csak bonyolultabbak jnnek.
~ 73 ~
3.3 .1 .2 .2 C H A L L E N G E H A N D S H A K E A U T H E N T I C A T I O N P R O T O C O L (CHA P)
RFC 1994
Egy rnyalattal biztonsgosabb, mint a PAP. Igen, tudom, most csaptad fldhz a
knyvet. Mit jelent az a biztonsgiparban, hogy "egy rnyalattal"? Valami vagy
biztonsgos vagy nem. Nem?
Elmeslem a kedvenc viccemet. Nem mintha ez lenne a legkacagtatbb vicc a
vilgon, de tanulsg tren ott van az lmeznyben.
Kt turista gyalogol a szavannban. Egyszer csak megltjk messzirl, hogy egy
oroszln rohan feljk. Az egyik gyorsan lel, elkap a htizskjbl egy edzcipt s
lecserli r a trabakancst. A msik rtetlenkedve nzi:
- Te komolyan azt hiszed, hogy ebben a cipben lefutod az oroszlnt?
- Az oroszlnt? Azt nem. De tged igen.
Azaz nem tudunk abszolt biztonsgosak lenni... csak biztonsgosabbak. Annyira,
hogy mr ne rje meg a rosszfiknak velnk vacakolni. Nyilvn ez a hatr
folyamatosan vltozik. Ami valamikor nagyon sok erforrst ignyelt, az ma mr a
gyerek otthoni gpn is elfut. Ezrt is jnnek ki j, meg j mdszerek.
Valamikor a CHAP nem is volt olyan rossz autentikcis eljrs23. A koncepci
lnyege az, hogy a jelsz ne utazzon t a drton. Ugye, ha nem megy t a jelsz,
vitzkedhetnek a capture-huszrok, nem tudjk megszerezni.
Persze, valaminek azrt t kell mennie. Nincs olyan, hogy varzsszra elbukkan
egy-egy buborkbl mindkt helyen a jelsz.
A kulcssz: OWF24. Azaz One Way Function. Magyarul olyan fggvny, mely csak az
egyik irnyba mkdik. Fti Marci frappns hasonlatval lve: a hsdarl. Egyik
oldalon belerakjuk a disznt, a msik oldalon kijn a darlt hs. Hiba szeretnnk
megfordtani a folyamatot, nem fog sikerlni.
Cryptographic hash function:
http://en.wikipedia.org/wiki/Cryptographic_hash_function
A CHAP s az MS-CHAP v1 nagyjbl azonos logikt kvet eljrsokat jelent. Egyedl a darls,
azaz az OWF ms. Az MS-CHAP v1-et a Windows Server 2008/Vista vonal mr nem tmogatja.
24 Nem azonos a hasonlan hangz WTF-fel.
23
~ 74 ~

Matekban ezt sokflekppen lehet elrni. Magt a darlsi algoritmust hash-nek25
hvjk. De az OWF nem pusztn darlst jelent. Bejn a kpbe a s is.
Nyugi, j helyen jrsz, ez nem egy szakcsknyv. Snak (salt) azt az rtket hvjk,
amellyel egybedarljk a preparland rtket. (Ezt ltalban azrt csinljk, hogy
vdekezzenek az n. dictionary attack, azaz a sztron alapul prblkozs ellen. Ez
j is akkor, ha a s nem publikus. Ha az, akkor adtunk egy pofont az
exkrementumnak.)
Mg egy fontos tulajdonsg a hash algoritmusokrl: egyrtelmek. Azaz ha van egy
rtk s arra rkldk egy hash algoritmust, mindig ugyanazt a tmr rtket
(darlt hs) kapom.
Nzznk egy ltalnos OWF folyamatot. Fogom a jelszt, beledobom a hsdarlba.
Melldobok valami st. Ez ltalban egy fix rtk, melyet a szervertl kapok
(challenge). Az algoritmusbl kijn egy rtk, ezt elkldm a partnernek (response).
Hiba kapja el tkzben Hekker Henry, a fasrtbl mr nem tud disznt gyrtani. A
szerver ismeri a st - nan, kldte - nla is megvan a jelsz, teht ugyangy ssze
tudja darlni az egszet. Mivel a hash eredmnye egyrtelm, gy ha a kt rtk
megegyezik, akkor j volt a jelsz.
Ha mr kezdend rteni, megjegyzem, rengeteg chap jelleg autentikci ltezik.
Ezek leginkbb az OWF folyamatban trnek el egymstl. Egyik erre tesz mg kt
tnclpst, amaz veggel a feje tetejn cifrzza... sznes a vilg. Mindenesetre a
Windows Server 2008 s Vista vonal az egyszerbbek kzl a CHAP autentikcit
ismeri, a bonyolultabbak kzl meg az MS-CHAPv2 autentikcit. (Habr az
utbbival is fogok bvebben foglalkozni, elljrban legyen elg annyi, hogy a CHAP
csak egyirny autentikcit ismer, azaz a szerver meg tud gyzdni arrl, hogy a
kliens tnyleg a kliens-e... de fordtva nem. A kliens nem lehet biztos abban, hogy a
szerver tnyleg a szerver-e. Ezt majd csak az MS-CHAPv2 fogja tudni.)
Chap:
http://en.wikipedia.org/wiki/Challenge-handshake_authentication_protocol
25
SHA-x, MDy, stb...
~ 75 ~

Akkor most mr nzzk meg konkrtan, hogyan is mkdik az a CHAP.
Elszr is, MD5-t hasznl. (Ezt becsletesen jelzi is az LCP megfelel

mezjben.)
Az autentikl fl (a szerver) kld egy kihvst (challenge). Ebben van egy
session ID, egy karaktersorozat (a s) s a sajt neve.
Az autentikland fl elkszt egy vlaszt (response). Ez gy nz ki, hogy a
session ID-t, a st s a jelszt bedarlja MD5-tel, majd mellteszi a felhasznl
nevt. El is kldi.
Az autentikl fl legyrtja a sajt darlt husijt: ismeri a session ID-t, a st s
a jelszt. Ha a kt hash megegyezik, akkor visszakld egy CHAP Success
zenetet. Ha nem, akkor egy CHAP Failure zenet megy vissza.
A sok duma utn nzzk meg, hogyan is nz ez ki csomagszinten. Els krben lssuk
a Challenge/Response csomagok szerkezett.
3.24. BRA CHAP C HALLENGE /R ESPONSE
PROTOCOL: A CHAP esetben az rtk: 0xC2-23.

CODE: Azonost. Challenge esetben 1, Response esetben 2.
IDENTIFIER: A session ID.

LENGTH: A CHAP csomag mrete.
VALUE SIZE:
Egy bjtos rtk, a lnyeges informcit tartalmaz, vltoz mret mez

(VALUE) mrete.
~ 76 ~

VALUE: Itt utazik a lnyeg.
NAME: Az aktulis felad nevt tartalmaz mez.
Erre jhet vlaszknt a CHAP Success, illetve CHAP Failure.
3.25. BRA CHAP S UCCESS / F AILURE
CODE: Azonost. Success esetn az rtke 3, Failure esetn 4.

IDENTIFIER: Session ID.
LENGTH: A csomag mrete.
MESSAGE: Itt lehet visszadumlni. CHAP esetn a Windows nem teszi.
Megszntetett autentikcik a Windows Server 2008-ban:
http://www.windowsnetworking.com/articles_tutorials/Windows-Server-2008-Networking-Services.html
~ 77 ~
3.3 .1 .2 .3 M I C R O S O F T C H A L L E N G E H A N D S H A K E A U T H E N T I C A T I O N P R O T O C O L V E R S I O N 2 (MSCHA P V 2)
RFC 2759
Mint rtam, ez is egyfajta CHAP autentikci, csak ez klcsns azonostsra is kpes.
Gondolom, nem kell klnsebben magyarznom, mennyivel biztonsgosabb ez a
mdszer. Bolond vilgban lnk, ma mr az autentikl felet is hamisthatjk.
A kzs gykr ott is ltszik, hogy a PROTOCOL mezben ugyanaz lesz a kd, mint a
CHAP estn: 0xC2-23. Viszont az LCP-ben a CHAP verzin belli kd mr ms. (Lsd
3.4. tblzat.)
Akkor nzzk, ebben az esetben milyen a tncrend.
Az autentikl fl elkldi a szoksos CHAP(!) csomagot. (Challenge.)

Az autentikcit kr fl visszakld egy MS-CHAPv2 Response csomagot.
Ebben benne van a felhasznlnv, a s az autentikl fl szmra s a
darlths, azaz az autentikl fl ltal kldtt s, egybedarlva a felhasznl
jelszavval, ez utbbi radsul titkostva. Jelen esetben MD4 hash algoritmust
hasznlunk. (Vegyk szre, megvltozott az OWF: MD5 helyett MD4, s a
session ID nincs beledarlva a vlaszba.)
Az autentikl fl eljrja ugyanezt a pr lpst: s, jelsz, hash, titkosts.
Amennyiben a kt szmtsi eredmny megegyezik, akkor egy CHAP Success
csomagot vesz le a polcrl. Amennyiben nem, akkor egy CHAP Failure
csomagot. Mindkt esetben sszerakja, ahogy kell. (Lsd 3.25. bra CHAP
Success / Failure) Csakhogy ezzel mg nincs vge, mg neki is autentiklnia
kell magt. Ez egy kicsit trkks, ugyanis nem azt csinlja, hogy elkldi a sajt
jelszavt - hiszen honnan is tudhatn szegny autentikcira vr fl, hogy mi
a tloldali service account user jelszava? Nem, ehelyett egy teljesen msik
OWF eljrssal bolondtja meg a felhasznl jelszavt, majd ezt a csomagot
kldi vissza. Ugyanezzel az OWF eljrssal fog nekiugrani a kliens is - s ha az
eredmny ugyanaz, akkor megnyugodhat, mert az autentikl fl tnyleg
olyan partner, aki mr korbban is tudta a jelszavt. Most mr csak azt
kellene letisztzni, mi is ez az j OWF? Kapaszkodj, nem lesz egyszer. Fogja a
kliens ltal neki kldtt st, mellteszi a sajt maga ltal korbban elkldtt
st, belecsapja a kliens ltal korbban kldtt teljes vlaszt, a kliens
felhasznli nevt s a jelszavt, majd ezt az egszet betitkostja. Mi? Hogy
hol van itt az OWF? Jogos a krds, nekem is vgig kellett trnom hozz az
RFC2759-et, hogy megtalljam. Teht nem a kliens jelszavt teszi direktben
bele a csomagba, hanem vgigkldi a jelszt egy MD4 darln, st, utna a
darlt hst ismt ledarlja - majd ez kerl a ksbb titkostand csomagba.
~ 78 ~
Az autentikcira vr kliens elszr is rl, ha CHAP Success csomagot kap de utna mindenkppen le kell ellenriznie, hogy az annak a MESSAGE
mezjben rkez j katyvasz megegyezik-e az ltala ugyangy, ugyanolyan
bonyolultan ellltott loklis katyvasszal. Ha nem, akkor ktelezen el kell
dobnia a csomagot.
Nzzk ugyanezt grafikusan is.
3.26. BRA MS-CHAP V 2 R ESPONSE
CODE: Azonost. MS-CHAPv2 Response esetn az rtke 2.

IDENTIFIER: Ugyanaz, mint a CHAP esetben.
LENGTH: Az egsz csomag mrete.
~ 79 ~

VALUE SIZE:
A CHAP-hoz hasonlan itt is a VALUE mez mrete - azzal az apr

klnbsggel, hogy itt a PEER CHALLENGE, RESERVED, WINDOWS NT RESPONSE s
FLAG mezk egyttest tekintjk VALUE meznek.
PEER CHALLENGE: A s az autentikl fl szmra.
RESERVED: Majd. Egyelre 0.
WINDOWS NT RESPONSE: Itt megy vissza a titkostott vlasz.
FLAGS: Majd. Egyelre 0.
NAME: Az autentikcit kr fl neve.
~ 80 ~
3.3 .1 .2 .4 E X T E N S I B L E A U T H E N T I C A T I O N P R O T O C O L (EAP)
RFC 3748
Megynk befel, mint maci a mlnsba.
Eddig ugyanis viszonylag egyszer volt az let. LCP, megllapodtunk az
autentikciban, eltncoltuk a mhecske tncot - s mr azonostottuk is magunkat...
vagy egymst.
Az EAP viszont egy jabb absztrakcis szintet vezet be.
Az EAP ugyanis egy ltalnos, autentikcis cl hordoz kzeg, direkt a PPP
szmra kitallva. Egy olyan protokoll, mely tetszleges autentikcis protokollt
kpes magba kapszulzni.
Hogy mi az rtelme?
Nehz erre rviden vlaszolni.
Az eddig trgyalt autentikcis mdszerek rgztett formtumak voltak, radsul
az zenetvltsok szma is limitlt volt. (Kett, vagy hrom.) Az EAP ezzel szemben
ad egy rugalmas szerkezetet, ahol mindenki azt pakol a mezkbe, amit akar s a kt
fl annyit beszlgethet egymssal, amennyit akar.
Ebbl az is kvetkezik, hogy ltezhetnek az EAP keretein bell a mr jl ismert
protokollok: semmi akadlya nem lenne, hogy csinljunk egy EAP-PAP protokollt
pldul. Mondjuk, rtelme sem. Nem is ltezik. St, a Windows Server 2008 s Vista
rendszerekben mg az EAP-CHAP sem tmogatott.
Akkor mgis milyen 'plugin' autentikcikat dughatunk az EAP-ba?
EAP-TLS (Smart Card Or Other Certificate nvre hallgat a Windows GUI-ban)
PEAP: Protected EAP (EAP az EAP-ban.)
n mondtam, hogy megynk a mlnsba. Ne gondold, hogy viccelek.
De mieltt nagyon elszaladnnk, nzzk azokat a dobozokat.
Eleve az EAP protokollon bell ngy zenettpust klnbztetnk meg:
EAP-REQUEST: Az autentikl fl kldi a behatolni igyekvnek.
EAP-RESPONSE: Az autentikland fl kldi a cerberusnak. Mind a kt fajta
zenetbl tetszleges szm lehet egy autentikcis folyamat sorn.
EAP-SUCCESS: Az autentikl fl kldi, amennyiben sikerlt a bejelentkezs.
EAP-FAILURE: Az autentikl fl kldi, amennyiben nem sikerlt a
bejelentkezs.
~ 81 ~
3.27. BRA EAP-REQUEST
ILLETVE
EAP-RESPONSE
PROTOCOL: Az EAP kdja 0xC2-27.

CODE: Azonost. Request:1. Response: 2.
IDENTIFIER: Ez pontozza ssze a Request-Response csomagokat.
LENGTH: Az EAP zenet mrete.
TYPE: Az EAP-on belli informci tipusa.
TYPE-SPECIFIC DATA: Maga az informci.
Ltjtok, ugye? Ez egy teljesen ltalnos doboz, egy univerzlis szllteszkz.

Minden a TYPE s TYPE SPECIFIC DATA mezkn mlik. Van bellk nhny.
3.5. TBLZAT
Type Tpus
1
Identity
2
3
Notification
Nak
13
25
29
EAP-TLS
PEAP
EAP-MSCHAP-V2
Megnevezs
Amennyiben EAP-Request-rl van sz, akkor az autentikl fl kri a bekredzked fl
nevt. Amennyiben EAP-Response-rl van sz. akkor meg pont fordtva.
Az autentikl fl szveges zenetei a msik flnek. Htha kirja a kpernyre.
Az autentikland fl seglykiltsa, amennyiben nem ismeri a krt autentikcis
mdszert. A TYPE-SPECIFIC DATA mezben ekkor visszakldi, hogy miket is ismer.
Errl van sz.
Errl van sz.
Errl van sz.
n mondtam, hogy mlns. Lthat, hogy az autentikci beazonostsa kicsszott

az LCP kezei kzl. Az LCP annyit fog tudni, hogy EAP. Aztn majd a RequestResponse kommunikcin bell letisztzzk a felek, melyik autentikcirl is lesz
konkrtan sz.
~ 82 ~

Hadd krdezzem meg, mirt hajtod le a fejed olyan szgyenlsen s rugdosod azt a
lthatatlan kavicsot, ltszlag teljes odafigyelssel? Ha valami nem stimmel,
krdezzl nyugodtan.
Igen, teljesen igazad van. De nekem is.
Azt rtam korbban, hogy az EAP-ba bele lehet dugni a TLS-t s a PEAP-ot. A
tblzatban meg ott szerepel az MS-CHAPv2. Akkor most wtf?
Nos, az van, hogy habr elfogadhat az MS-CHAPv2 is, de azt igazbl gy
csempszik majd be. A PEAP-on keresztl. De errl ksbb rszletesen is rok majd.
Nzzk akkor a tbbi EAP csomagot.
3.28. BRA EAP-SUCCESS ILLETVE EAP-FAILURE
CODE: Azonost. Success: 3. Failure: 4.

IDENTIFIER: A legutols EAP-Response azonostja.
LENGTH: Fixen 4.
~ 83 ~
3.3 .1 .2 .5 EAP- M S- C HA P V 2
Csak azrt, mert ezt mr jl ismerjk, gy lthatjuk, hogyan 'eaposodik' egy

autentikcis protokoll. (Egybknt, mint rtam, sima EAP-pal nem szoks MSCHAPv2-t hasznlni.)
Az autentikl fl kld egy EAP-Request csomagot, melynek a tipusa: Identity.

A bekredzked kld egy EAP-Response csomagot, ennek tipusa szintn
Identity.
Egybl megy is vissza egy EAP-Request csomag, melynek tipusa MS-CHAP v2,
a tartalma pedig teljesen ugyanaz a Challenge, mint amilyenrl korbban is
rtam.
Innetl pedig teljesen ugyangy trtnik minden, csak ppen most mr az
EAP csomagok TYPE SPECIFIC DATA meziben utaznak az informcik.
3.3 .1 .2 .6 EAP- TL S
RFC 2716, 2246

Nos, itt egy j fi a blokkban: a TLS. Eddig rla nem volt sz.
Egy kicsit messzirl fogok indtani. Amikor titkostani akarok egy kommunikcit,
akkor azt ktflekppen tehetem meg: vagy egy szimmetrikus kulcs titkostst
hasznlok, vagy egy asszimetrikusat. Mindkettrl rengeteget lehetne rni, de n
most csak kt tnyre fogok szortkozni:
A szimmetrikus kulcs titkosts gyors. Piszkosul gyors. Sokkal gyorsabb,
mint az asszimetrikus.
A szimmetrikus kulcs titkostsnak van egy slyos hibja: a kulcsot valahogy
el kell juttatni mindkt kommunikl flhez, mg akkor is, ha azok tbbezer
kilomter tvolsgra vannak egymstl, kzttk pedig ott feszl a hekker
cen.
Gondolom, nem kell hozz zseninek lenni, hogy beugorjon a megolds: ht kldjk el
a szimmetrikus titkosts kulcst (session key) asszimetrikus titkostssal, ez lass
ugyan, de csak egyszer, maximum ktszer kell hasznlni - utna pedig hadd szljon,
ami a csvn kifr, szimmetrikus titkostssal.
Ezt hvjk gy, hogy TLS.
Mr megint furcsn nzel. Igen, ezt nevezik gy is, hogy SSL. Az elv ugyanaz, de van
egy risi klnbsg: a TLS az SSL utdja. SSL-bl volt az 1.0 (mely soha nem lett
publiklva), volt a 2.0 (mely bugzott, mint macska jjel), aztn jtt a 3.0, mely mr
~ 84 ~

egszen j volt - de nem folytattk a sort, mert jtt helyette a TLS 1.0, aztn az 1.1 s
most ppen az 1.2 az aktulis. Hogy mi minden vltozott az egyes verzikban, arra
most nem trnk ki. De ha pldul olyat ltsz valahol, hogy most implicit vagy
explicit titkostst szeretnl, akkor tudjl rla, hogy az gynevezett inicializcis
vektor a TLS1.1-tl explicit. Azaz az implicit az j esllyel SSL 3.0 lesz.
Nzzk akkor, mik is a TLS elnyei:
Biztonsgos. Jelenlegi ismereteink, a jelenlegi szmtsi teljestmnyek
ismeretben elmondhat, hogy nem trhet. (Persze nem mindegy, hny
bitesek a kulcsok.)
Nagyon knnyen klcsnss tehet. Menjnk csak vgig a folyamaton!
o A node bekopog B node-hoz.
o B node elkri A node tanstvnyt.
o B node elkldi A node-nak a session key-t, melyet A node publikus
kulcsval titkost.
o A node a privt kulcsval kicsomagolja a session key-t.
o A node elkri B node tanstvnyt.
o A node becsomagolja a korbbi session key-t B node publikus
kulcsval, majd elkldi neki.
o B node kicsomagolja a session key-t a privt kulcsval.
o Bjos mellktermkknt mindkt flnl ott ragadt egy session key,
mellyel mr tudjk titkostani a tovbbi kommunikcit. Nyilvn ha
valamelyik hazudott, akkor a kommunikci sem jn ltre.
Vegyk szre, hogy eddig a TLS-rl beszltem, gy ltalnossgban. A fejezet cme
viszont az, hogy EAP-TLS.
Megijedni nem kell, habr mr nem sok ltszik az gbl a sok mlnabokortl.
Tulajdonkppen az trtnik, hogy a TLS kommunikci a korbban mr megismert
EAP csomagokon bell fog utazni. A TYPE rtke 13 lesz, a lnyegi informci pedig
a TYPE-SPECIFIC DATA mezkben utazik.
~ 85 ~
3.3 .1 .2 .7 PR OT ECT ED EX TE N S IB L E AU THE N T ICA TI ON P R O TO COL (P EAP )
Ahogy a szls mondja, attl mert paranois vagy, mg nem biztos, hogy nem
ldznek. Nzzk csak meg az elz kt protokollt: mind az EAP-TLS, mind az EAPMS-CHAPv2 esetben a lnyeg, azaz a TYPE-SPECIFIC DATA mez tartalma
titkostva van. De a tbbi informci nem. s van, amikor ez is szmt.
Hogyan tehetjk mg biztonsgosabb ezt a kommunikcit? gy, hogy beletereljk
az egszet egy TLS csatornba.
Vigyzat, mlns, nagyon mlns!
Tudsz kvetni?
A PPP kapcsolatban rsztvev kt node, mieltt mg brmi is trtnne, egy EAP
kapcsolaton keresztl kipt egy TLS kapcsolatot. Ebben a kiptsben nem jelenik
meg a tnyleges felhasznli nv s jelsz, mg egyszer hangslyozom, a node-ok
ptik ki a csatornt.. Aztn amikor mr van mindkt oldalon session key, akkor
indul be a tnyleges EAP autentikci, immr a bejelentkezni kvn user adataival.
Ez a bizonyos msodik EAP (azaz a PEAP-on belli EAP) ktfle lehet:
EAP-MS-CHAP v226 (PEAP-on bell Secured Password nven talljuk a GUI-n)
EAP-TLS (PEAP-on bell Smart Card Or Other Certificate nvre hallgat)
TLS-en belli TLS... szp, mi. s nha mg mi nevezzk paranoisnak magunkat. Hol
vagyunk mi egy RFC gyrt biztonsgi szakembertl?
26
Itt mr lehet.
~ 86 ~
3. 3 .1 . 3 V I S S Z A H V S
Ma mr elg kicsi az elfordulsi valsznsge, de rsze a folyamatnak, gy

emlkezznk meg rla is. Magt a folyamatot az n CallBack Control Protocol, azaz
CBCP viszi vgig. Nem kell tl bonyolult dolgokra gondolni, az LCP-nl megismert
csomagokat hasznlja, a kvetkez eltrsekkel:
A PROTOCOL ID rtke 0xC0-29

A CODE rtkek az LCP-nl lertak lehetnek, de csak az els 7 fordulhat el.
Az els 3 esetben (Callback Request [1], Callback Response [2] s Callback
ACK [3]) az LCP OPTION mezkben utaznak a ksr informcik, melyek
leginkbb telefonszmok.
~ 87 ~
3. 3 .1 . 4 P R O T O K O L L B E L L T S O K NC P- V E L
Itt elssorban IPCP-vel s CCP-vel fogunk foglalkozni. ECP-vel bizony mondom, nem.
Ezek ugyanis mind NCP-k.
Msfl sor. De egy fl templomnyi tmjnfst.
Kezdjk ott, hogy mi is ez a meglehetsen zavaros NCP, azaz Network Control
Protocol? Az, amit a neve is sugall. Egy protokoll, mely segti, hogy a kt pont kztt
a hlzat mkdjn. Pontosabban, az NCP nem kizrlag egy protokollt jelent,
hanem egy csaldrl van sz. Ennek tagjait soroltam fel az els kt mondatban:
IPCP: IP Control Protocol
CCP: Compression Control Protocol
ECP: Encryption Control Protocol
~ 88 ~
3.3 .1 .4 .1 IP C O N T R O L P R O T O C O L
RFC 1332, 1877

Ez tulajdonkppen egy DHCP, csak ppen kt pont kztt. A DHCP szerver funkcit
az autentikl node jtssza el, olyan rtelemben, hogy osztja ki az IP rtkeket a
betmad node-nak.
A felpts teljesen hasonl, mint az elz alfejezetben trgyalt CallBack Control
Protocolnl: LCP csomagokban utaznak az informcik, csak ppen egyes mezknek
specilis rtkeik lesznek.
Ilyenek.
A PROTOCOL ID rtke: 0x80-21.
A CODE rtkek kzl szintn csak az els 7 lehetsges. Az els ngyhez tartozik LCP
OPTION blokk is, ezek tartalmt az albbi tblzat mutatja:
3.6. TBLZAT
Option Name
IP Address
Primary DNS Server Address
Primary NBNS Server Address
Secondary DNS Server Address
Secondary NBNS Server Address
Type
3
129
130
131
132
Length
6
6
6
6
6
Description
A kiosztott IP cm
Az elsdleges DNS szerver cme
Az elsdleges WINS szerver cme
A msodlagos DNS szerver cme
A msodlagos WINS szerver cme
A gondos megfigyelnek feltnhetett, hogy a krvnyez azrt nem kapott meg

mindent. Pldul hol van a subnet mask? Alaprtelmezsben. Ne felejtsk el, hogy
kt pont kztt ptnk hlzatot, teht subnet mask-nak tkletesen megfelel a
255.255.255.255. Default gateway? Nyilvn az autentikl fl IP cme. Lehet egynl
tbb Default Gateway egy hoston? Nem igazn. De a szmtgp okos, az IPCP utn a
route tblba rja be az autentikl fl IP cmt, mghozz gy, hogy az legyen a
legkisebb kltsg. Amennyiben ltezett korbban 1-es metric, akkor mindegyik
korbbi bejegyzs metric rtkt megnveli eggyel, a friss bejegyzst pedig egynek
veszi. (De errl le lehet beszlni.)
Mi nincs mg? Mondjuk DNS domain nv. Na, az nem is lesz. Legalbbis tisztn IPCP
segtsgvel biztosan nem. Ilyenkor jn az, hogy lopunk, csalunk, hazudunk - azaz
proxy. Amennyiben az autentikl fl - aki az IPCP-t is biztostja - kpes DHCP
proxyknt viselkedni, s van a krnyken DHCP szerver, s a betrekv node
Windows Server 2008 vagy Vista, akkor az kld egy DHCPINFORM zenetet, az
autentikl fl proxyzza a valdi DHCP szerver fel, a vlaszt dett a msik irnyba,
~ 89 ~

vgl az ifj padawan eldob minden opcit, eltekintve a 15-stl, mely a DNS
Domain Name nvre hallgat.
Az let szp. Csak nem egyszer.
3.3 .1 .4 .2 C O M P R E S S I O N C O N T R O L P R O T O C O L , CCP
RFC 1962
Semmi meglepets nem vrhat. Ez egy olyan protokoll, melynek segtsgvel a felek
megbeszlik, hogy milyen tmrtsi technikt hasznljanak a klnbz
adatcsomagok kldzgetsre.
Egy kzl lehet vlasztani.
RFC 3078
Legalbbis a Microsoft rendszerekben. Ez pedig az MPPC, azaz a Microsoft Point-toPoint Compression. Jelzem, hogy rukapcsols tnye forog fenn, azaz aki MPPC-t
vlasztott, az nagy valsznsggel 27 kapott vele MPPE-t is, mely a Microsoft Pointto-Point Encryption nvre hallgat titkostsi folyamatot takarja. A szakirodalomban
gy is szoktak elfordulni, hogy MPPC/MPPE.
Termszetesen ez a protokoll is az LCP csomagformtumot hasznlja.
A PROTOCOL ID rtke: 0x80-FD.
Szintgy csak az els 7 LCP CODE hasznlatos, ezek kzl az els ngynl
fordulhatnak el LCP OPTION blokkok.
3.7. TBLZAT
Option Name
Organization
Unique
Identifier
Microsoft
Point-to-Point
Compression (MPPC)
Type
0
Length
min. 6
Description
A tmrtsi mdszer beazonostsa
18
MPPC/MPPE esetn a szksges paramterek (leginkbb a

titkostshoz hasznlt kulcs hossza, a titkosts erssge, meg
ilyenek)
Feltve, hogy a korbbi autentikcis fzisban a felek valamelyik klcsnsen autentikl

mdszerben egyeztek meg. Ellenkez esetben nincs MPPE. Meg az ersebb titkostst biztost
tunnelling protokollok esetben sem.
27
~ 90 ~
3.3 .1 .4 .3 E N C R Y P T I O N C O N T R O L P R O T O C O L , ECP
RFC 1968
Itt lehetne kln megbeszlni az adatcsomagok titkostshoz hasznlt mdszerrel
kapcsolatos paramtereket. Ha lehetne mst is hasznlni, mint az MPPE, melyet mr
a CCP-n bell letisztztunk.
Windows rendszerekben nem nagyon fogunk tallkozni vele. Ergo ebben a
knyvben sem.
~ 91 ~
3. 3 .1 . 5 PPP O V E R E T H E R N E T
RFC 2516
Na, ez meg milyen csodabogr?
Ok, tudom, hogy klti a krds, hiszen rengeten hasznljuk ezt a mdszert, de klnsen az eddigiek alapjn - nem lepdnk meg, ha sokan bizonytalansgot
reznnek az erben.
Hiszen kitrgyaltuk az Ethernet technolgit, lttuk, hogy a PPP egy teljesen ms
vilg... akkor hogyan jn ssze ez a kett? s legfkppen, mirt?
A vlaszt az ISP-k krnykn kell keresglni. Ezek a cgek ugyanis azt szeretik, ha az
elfizetik PPP kapcsolaton keresztl jnnek be. Hiszen ekkor a kapcsolat remekl
autentiklhat, minden mrhet, minden kzbentarthat, magnak a kapcsolatnak a
szintjn. Lehet forgalmat szablyozni, lehet forgalom alapjn szmlzni... knan.
De mit szeretne az gyfl? Ht azt, hogy ne bonyoltsk tl az lett, hadd lgjon
csak egy mezei Ethernet hlzaton. Az egyszer a szp.
Ebbl szletett meg ez az szvr.
Mint a neve is mutatja, alapveten Ethernet keretekrl lesz sz, csak ppen a
Payload-ban PPPoE keretek fognak utazni, azok payloadjban pedig vagy PPPoE
informcik (Discovery fzis), vagy PPP keretek (PPP Session fzis). Magyarul
Ethernetbe kapszulzzuk a PPPoE-t, abba meg a PPP-t.28
Ahogy jeleztem, a kommunikcinak kt fzisa ltezik:
Discovery Phase: a kliens node felfedezi az Access Concentrator-t, aki egy
AAA szerver29 segtsgvel autentiklja.
PPP Session Phase: ltrejn a PPP session, beindult a kommunikci.
Valahogy gy nz ki egy keret.
Mieltt dhs levelet fogalmaznl Dr. Grtsy Lszlnak, megkrdeznm: az irniarzkeld

mkdik? Amennyiben nem, akkor javaslom, hogy kapcsold be. Az egsz knyv sorn szksged lesz
r.
29 AAA: Authentication, Authorization, Accounting. Azaz kiforgatjuk a gatyjbl a delikvenst.
28
~ 92 ~
3.29. BRA PPP O E KERET
VERSION: 4 bites mez, az rtke mint a totban: fix 1-es.

TYPE: Dett.
CODE:
A Discovery fzis sorn klnbz tartalm csomagok cserlnek gazdt. Ez a

mez hivatott arra, hogy beazonostsa a tipusokat.
A PPP session fzisban az rtke 0.
ID: A Discovery fzisban az rtke 0. Utna pedig a kialakult session
azonostja.
SESSION
LENGTH: A PPPoE payload mrete.
PAYLOAD: Meglehetsen rugalmas mez. A Discovery fzisban az adott lpshez

szksges PPPoE informcik utaznak itt. A PPP Session fzisban viszont mr PPP
keretek. (Ezt jelezn az a csillag ott a kpen.)
~ 93 ~
3.3 .1 .5 .1 PP P O E D I S C O V E R Y - S Z I G O R A N K O C K A F E J E K N E K
Nem mintha ms is eljutott volna idig a knyv olvassban.

Ahhoz, hogy a kliens s az Access Concentrator egymsra talljanak, egy kzepesen
bonyolult prostncot kell lejtenik: PADI, PADO, PADR... PADS. Mint egy barokk
pavane.
PPPOE ACTIVE DISCOVERY INITIATION (PADI): A kliens kldi... bele a nagyvilgba.

Ebbl kvetkezen az zenet az egy broadcast. (Csupa magas bit.) A CODE
rtke 9, a SESSION ID rtke 0.
PPPOE ACTIVE DISCOVERY OFFER (PADO): Az AC kldi vissza. Ez mr unicast
zenet, a kliens MAC cmre. A CODE rtke 7, a SESSION ID rtke 0. A
csomag tartalmazza az AC nevt, s a Service-Name rtket.
PPPOE ACTIVE DISCOVERY REQUEST (PADR): A kliens kldi vissza. Unicast zenet
az AC MAC cmre. A CODE rtke 25, a SESSION ID rtke 0. A csomag
tartalmazza a Service-Name rtket.
PPPOE ACTIVE DISCOVERY SESSION-CONFIRMATION (PADS): Az AC kldi vissza a
kliensnek. Unicast zenet a kliens MAC cmre. A CODE rtke 101 - s itt jn
a lnyeg: a SESSION ID rtke mr a vgleges session azonost. A Servicename termszetesen itt is benne van a csomagban.
~ 94 ~

3.3.2 NBMA: F R A M E R E LA Y
Most egy kicsit tgtjuk a ltkrnket. A PPP olyan WAN kapcsolatot jelentett, mely
kt node kztt jtt ltre. Mi lenne, ha hasonl WAN technikt hasznlnnk... de tbb
node is rszt vehetne a buliban?
Ekkor beszlnk Non-Broadcast Multiple Access (NBMA) linkekrl. Mint a neve is
mutatja, ebben az esetben egy linken tbb node is megtallhat, de a linken nem
lehet broadcast. Legismertebb kpviseli ennek a technolginak az X.25, illetve a
Frame Relay.
Az X.25 valamikor igen elterjedt volt, mert szakadoz vonalakon is jl teljestett. Ma
mr a vonalak sokkal megbzhatbbak, gy mr zavar az X.25-ben a tl nagy
kommunikcis vzfej. Gyakorlatilag a jval kevesebb ellenrzst tartalmaz, emiatt
persze sokkal gyorsabb Frame Relay ki is szortotta. A Windows Server 2008 spec
mr csak az utbbit tmogatja.
Leginkbb hlzatok sszekapcsolsra hasznljk. Fontos jellegzetessge, hogy az
egyes node-ok fel a szmlzs az tvitt adatmennyisg alapjn trtnik.
3.30. BRA F RAME R ELAY (F ORRS : W IKIPEDIA )
A Frame Relay mkdsnek kiveszse meghaladja e knyv kereteit.

Az albbi linkeken kimert lerst tallhatunk rla:
http://www.protocols.com/pbook/frame.htm
http://en.wikipedia.org/wiki/Frame_Relay
http://www.szabilinux.hu/trendek/trendek422.html
~ 95 ~
4 A Z INTERNET RTEG PROTOKOLLJAI

De mg mieltt tovbbmennnk, foglaljuk ssze egy brn, mirl is beszltnk
eddig, illetve mi vrhat a tovbbiakban.
4.1. BRA E GY HLZATI CSOMAG FELPTSE
Az alfa s az omega. Ltjuk, hogy a Network Interface rtegben megismert keret

tnyleg bekeretezi a csomagot, azon bell pedig a payload maga az IP datagram,
mely ll egy IP fejlcbl s egy IP payloadbl... az utbbi persze nem ms, mint egy
TCP szegmens, melynek szintn van fejlce a hasznos tartalma.
gy nznek ki a hagyma hjai... azaz a hlzati modell rtegei.
Csomagcentrikus megkzeltsben.
~ 96 ~
AZ INTERNET RTEG PROTOKOLLJAI
4.1 IP V 4
RFC 791
4.1.1 A Z IP H EA D E R
Els krben az IP datagrammal fogunk foglalkozni. Az elz brt most
leegyszerstettem: elfelejtjk, hogy egyltaln hallottunk olyasmirl, hogy TCP
szegmens. Nincs. Nem ltezik. Csak egy zrt doboz van (IP payload), melyet az IP
csomagba (IP Datagram) raktak, s neknk - illetve szerencsre a szabad
elektronoknak - ezeket kell elszlltaniuk valahov.
4.2. BRA E GY IP CSOMAG FELPTSE
A cmbl is ltszik, hogy ez a fejezet az IP fejlcrl fog szlni... a ksbbiekben pedig

megnzzk, mi minden lehet mg az IP payload - az egybknt ugye nem ltez TCP
szegmensen kvl. (Sgok: ICMP, IGMP s mg sokan msok.)
Csapjunk is egybl a lecsba.
~ 97 ~
4.3. BRA A Z IP FEJLC
VERSION:Az IP verziszma. Jelenleg csak a 4-es, illetve a 6-os rtk rtelmezett.

INTERNET HEADER LENGTH: Mint az brn is lthat, ez egy ngy bites mez. Itt
troldik, hogy mekkora is az IP fejlc.
Szmoljunk egy kicsit. 4 bit, az annyi, mint 15 darab nulltl klnbz rtk. Mit
lehet ennyi helyen trolni? 15 bjtot? Deht az bra alapjn minimum 20 bjtos a
fejlc s akkor mg nem is beszltnk az opcionlis OPTIONS AND PADDING
mezkrl. Akkor?
Nos, itt az n szszmll rtkt troljk. A sz, mint tudjuk, elszll... msrszt 4
bjt mret. Mivel az INTERNET HEADER LENGTH maximlis rtke 15, gy a fejlc
maximlis mrete 15*4=60 bjt. Minimlisan pedig 20 bjt, azaz a mez rtke nem
lehet 5-nl kisebb.
s most akkor engedjnk szabad utat a morgoldsnak. Ha ragaszkodunk a 60-as
fels korlthoz, akkor hny biten is trolhatunk 63 klnbz rtket? Igen, hat.
Teht ezzel a kavarssal sproltunk 2, azaz kett bitet. Viszont minden
ki/becsomagolsnl beraktunk egy plusz mveletet. Mindegyiknl. Radsul bejtt
mg egy megkts, az OPTIONS AND PADDING mezknek, fggetlenl attl, hogy
milyen opcit, azon bell milyen rtkeket tartalmaznak, mindig 4 bjtosnak kell
~ 98 ~

lennik. Azaz ha van egy ktbjtos IP opci, akkor a kt bit sprolson buktunk kt
bjtot, mert res tltelket - padding-ot - kell tenni a vgre. Radsul mindezt egy
olyan rendszerben, mely alapbl borzalmasan pazarl, gondoljl csak a korbbi
fejezetben megismert SNAP talaktsokra, ahol tk feleslegesen trolunk le
konstans rtkeket.
Deht... ez van, ezt kell megtanulnunk.
TYPE OF SERVICE (TOS): Itt kellemetlen vlasztsra knyszerltem. Egyfell ez egy
nagyon j, szszerint bitre lebontott struktrval rendelkez 1 bjtos mez. Volt.
RFC 791
Az RFC 791 szerint. Ezt pldul hls lenne rszletesen is lerni, egyszer, rthet.
Csakhogy ma mr a kutya sem hasznlja.
4.4. BRA M IT IS TALLUNK A TOS HELYN ?
Legalbbis sem az XP SP3, sem a Vista, sem a Windows Server 2008 nem a 791-es
RFC szerint rtelmezi ezt a mezt... s van egy olyan halvny sejtsem, hogy a
Windows 7 sem gy fogja.
RFC 2474
Ehelyett az RFC 2474 a men. Mondanom sem kell, bonyolult s rthetetlen. Pedig
jl indul: azt mondja, dobjuk ki az utols kt bitet. Nem kll. A maradk hat bitet
pedig elnevezzk DSCP-nek, azaz Differentiated Services Code Point-nak. (Lsd. a
fenti bra.) Utna viszont nagyon kds lesz. Az RFC-bl annyit ki tudtam hmozni,
hogy a hat bitben lv szervzkdok azt hatrozzk meg, hogy a csomagok milyen
elbnsban rszesljenek, azaz gyakorlatilag egyfajta svszlessg-kezelsre (QOS)
hasznlhatk, mghozz blokk alap szervezettsgben. Ezeket a blokkokat
~ 99 ~

Differentiated Services (DS) domain-eknek nevezik. De ott mr eltrt az agyam,
amikor az RFC azt mondta, hogy az n. DS-compliant hlzatokban a kdok
kiosztst s az az alapjn trtn viselkedst hzirendek hatrozzk meg, melyek
ismertetse nem rsze az RFC-nek.
A Windows annyit tesz ehhez, hogy hasznlj Group Policy-t, vagy ha szereted a
kihvsokat, van egy csom API30.
Mg egy dolgot tisztznunk kell. n azt mondtam korbban, hogy az utols kt bitet
kidobtuk - az brn viszont az szerepel, miszerint az egyik bit ECN-Capable
Transport (ECT), a msik pedig ECN-CE. Ezek bizony nem tnnek hasznlaton kvli
biteknek.
Nem is azok.
RFC 3168
A szabvnyalkotk rcsaptak a kt res bitre, mint gyngytyk a takonyra s az RFC
3168-ban az gynevezett Explicit Congestion Notification (ECN) funkci
megvalstsra hasznltk fel. Mirl is van itt sz? Arrl, hogy a routerek, ha
elrasztjk ket, utols seglykiltssal jelezhetik, hogy 'elvtrsak, ne ljetek!'. Ez az
ECN. Ha a felad host olyan, hogy kpes venni ezt az adst, akkor leengedi a fegyvert.
Ha nem, akkor rezzenstelen arccal tzel tovbb.
Lehetsges rtkek:
00
: A felad kegyetlen s sket.
01 v. 10
: A felad egy rz llek.
11
: A router lommrgezskzeli llapotban van.
Mint lthat (4.4. bra Mit is tallunk a TOS helyn?), az n szmtgpem jelenleg
sket brgyilkos - ez ugyanis az alaprtelmezs. De a netsh paranccsal t lehet
lltani a mentalitst, mghozz hlzati krtynknt.
TOTAL LENGTH: A teljes IP datagram mrett jelzi, bjtban. Mivel a mez ktbjtos, gy
az IP datagram maximlis mrete 65535 byte lesz31. Mi van, ha ennl nagyobb a
csomag mrete? Trdelnk.
IDENTIFICATION: Ha mr trdelnnk kell, akkor valahogy jeleznnk is kell, mely
tredkek tartoznak ugyanahhoz az IP datagramhoz. Ezrt szmozzuk a csomagokat.
FLAGS: Igen, mg mindig trdelnk.
Generic QoS (GQoS) and Traffic Control (TC) API, vagy Quality Windows Audio-Video Experience
(qWAVE), azaz QoS2 API.
31 Rmlik valakinek a gyilkos ping?
30
~ 100 ~
4.5. BRA FLAGS
1. Az els bit hasznlaton kvli.

2. A msodik bit azt jelzi, hogy trdelhet-e a csomag? Ha az rtke egy, akkor
nem.
3. A harmadik bit azt mutatja, hogy a mostani IP csomag az utols-e, vagy jn
mg tredk. Ha az rtke 0, akkor ez az utols.
Az brn 0100 lthat, azaz decimlisan 4. (Igen, a mez ngy bitet foglal el, de csak
hrom br rtelmezhet rtkkel: ez a kzps kett. Nem, nem n vagyok a hlye.)
FRAGMENT OFFSET: Ha mr trdeltnk, akkor ez az rtk mutatja meg, hogy a konkrt
csomag hanyadik tredk ppen.
Jelzem, hogy a trdelsrl - fragmentation - ksbb bvebben is lesz sz. Egyelre
legyen elg annyi, hogy ellenezzk.
TIME-TO-LIVE: Azaz van-e let a hall eltt? s ha van, akkor mennyi? A mezben lv
rtk ugyanis azt mutatja, hogy meddig l a csomag. Ha lejrt, akkor az a hlzati
eszkz, amelyiknl az eset bekvetkezett, eldobja a csomagot.
Vajon mi lehet a mrtkegysge? ra? Secundum? Tick?
RFC 1812
Egyik sem. Valamikor tnyleg id dimenzij volt, de az RFC 1812 ta inkbb
szmll, melynek rtke minden hopnl - azaz hlzati eszkzn trtn
thaladsnl - cskken egyet. Logikusan, ha kldnk egy csomagot, amelynek a TTL
rtke 0, akkor az nem fog kimenni a subnetrl. Ha a TTL rtke 1, akkor a subnetrl
kimegynk ugyan, de maximum csak a szomszd alhlzatra.
PROTOCOL: Azt mondja meg, hogy az IP Payload-ban milyen protokollhoz tartoz
csomag utazik. Nhny plda:
~ 101 ~

4.1. TBLZAT
rtk
1
2
6
17
41
47
50
51
Protokoll
ICMP
IGMP
TCP
UDP
IPv6
GRE
ESP
AH
HEADER CHECKSUM: Tulajdonkppen egy CRC, de csak a fejlc integritst biztostja.

Beugrats krds: a feladskori rtk vajon megegyezik-e az rkezsi rtkkel?
Jaj, ht hogyan is egyezne meg? pp most mondtam, hogy a TTL rtkt minden hop
lecskkenti. Nyilvn minden fejlcbeli mdostskor jra kell szmolni az ellenrz
rtket.
SOURCE ADDRESS: A felad IP cme... feltve, hogy a NAT nem rondt bele.
DESTINATION ADDRESS: A cllloms IP cme. Feltve, hogy a NAT nem rondt bele.
OPTIONS AND PADDING: J megfigyelkpessggel rendelkez olvask szrevehettk,
hogy a korbbi brn (4.3. bra Az IP fejlc) ez a mez narancssrga. Ezzel finoman
arra prbltam clozni, hogy ez a mez teljesen opcionlis. Mire is j? Van egy
csom kisr informci, melyek bizonyos esetekben jl jhetnek a hlzati
eszkzk szmra. A kisr informcik tipusokra vannak osztva, mindegyiknek
kdja van - s adatstruktja, termszetesen. Ezeket gy hvjk, hogy IP Options, azaz
IP opcik. (Ksbb bvebben is fogunk velk foglalkozni.)
Ha nem hasznljuk ezt a mezt, akkor az IP fejlc mrete 20 bjt. Ha hasznljuk,
akkor a LENGTH meznl trgyaltak alapjn mr tudjuk, hogy a fejlc mrete
maximum 60 bjt lehet, illetve nggyel oszthatnak kell lennie. Az gegyadta vilgon
semmi sem garantlja, hogy egy konkrt IP opci adatszerkezete pont nggyel
oszthat szm bjtbl lljon - ergo ilyenkor rtktelen trmelkkel (padding) fel
kell tlteni a mezt.
~ 102 ~
4. 1 .1 . 1 T R E D E Z E T T S G
Habr mr esett rla sz, de nem rt pontosan letisztzni: mi is pontosan az a

bizonyos MTU? Ha szigoran nzzk, akkor elegend kibontani az akronimot:
Maximum Transmission Unit, szszerint fordtva: a legnagyobb elszllthat egysg.
Persze gy tl sok rtelme nincs, ha rtelem szerint fordtunk, akkor azt mondhatjuk,
hogy a legnagyobb payload mrete, melyet mg egy csomagon bell el tudunk
szlltani.
MTU:
http://en.wikipedia.org/wiki/Maximum_transmission_unit
Ez az a pont, ahol nem nevezhetjk csak gy csomagnak a csomagunkat.

Mirt is nem mindegy? Mert lthattuk az brn (4.1. bra Egy hlzati csomag
felptse), hogy csak nzpont krdse, mit is neveznk payload-nak. Ami egyik
szintrl payload, belenzve tovbbi header s payload. Ezrt fontos tisztzni, hogy
az MTU-t a Network Interface Layer viszonylatban rtelmezzk - azaz az MTU a NIL
payload maximlis mrete.32
J. Akkor mekkora is az MTU?
Attl fgg. Lapozz vissza a NIL fejezethez. Azt fogod tallni, hogy csomagtovbbtsi
technolgitl fggen ms s ms. Mi fog trtnni, ha a csomagunk nagyobb MTUval rendelkez alhlzatrl kisebb MTU-val rendelkez alhlzatra kerl? Muszj
tprselni a nagy szekrnyt a kis ajtn: kisebb darabokra vagdossuk a csomagot azaz fragmentlunk. Kinek fog ez leghamarabb fjni? gy van, az Internet rtegnek ergo ebben a rtegben kell megoldanunk a fragmentls adminisztrcijt,
mghozz rtelemszeren az IP header-ben.
Helyben vagyunk. Errl fog szlni ez a fejezet.
Megjegyzem, ezen a tren nem igazn egysges a szakirodalom. Van ahol azt mondjk, hogy a
konkrt rtegre jellemz MTU az a konkrt rteghez tartoz maximlis payload mrete. A
gyakorlatban viszont inkbb az terjedt el, hogy a hlzati krtynak van MTU-ja - mely felfogs
ebben az esetben a fenti, a NIL rtegre vonatkoz defincit jelenti.
32
~ 103 ~

Mit is tudunk eddig? Elg sokat. Ha fragmentldott a csomagunk, akkor
Az sszetartoz, azaz ugyannak a csomagnak a darabjait az IDENTIFICATION
mez azonostja be.
A darabok sorrendjt a FRAGMENT OFFSET mez hatrozza meg.
A szls tredkeket a MORE FRAGMENTS flag azonostja.
Akinek ennyi elg is, az nyugodtan tugorhatja a kvetkez pr oldalt. Ugyanis itt
fogom kifejteni, hogyan is trtnnek pontosan ezek a dolgok.
Elszr is vizsgljuk t alaposan az albbi kt brt.
4.6. BRA F RAGMENTLT CSOMAG HARMADIK TREDKE
4.7. BRA F RAGMENTLT CSOMAG UT OLS TREDKE
~ 104 ~

Mieltt darabokra cinclnnk az brt, egy gyors krds: vajon hogyan lehet a
legegyszerbben tredezett csomagokat produklni? gy van, a varzslatos ping
paranccsal. A parancsnak ugyanis van egy olyan paramtere, mely a payload mrett
adja meg - egyszeren nagyobbra kell vlasztanunk az rtket, mint az aktulis MTU
rtknk. A fenti brk is gy keletkeztek: kiadtam a ping -l 5000 192.168.1.2
parancsot.
Bnusz feladat: aki az brk alapjn megmondja, mennyi az MTU-m rtke, az kap
egy nyalkt. De tessk igyekezni, mert a kvetkez oldalakon elrulom a megoldst.
Akkor kezdjk az els brval. Van benne egy ronda tglalap: ez mutatja azt, hogy
mely keretekrl van egyltaln sz: a 213-as a krs, 214-217 kztt jn vissza a
tredezett vlasz. Magn az els brn a harmadik tredket lthatjuk, a msodik
brn pedig a negyedik, azaz utols csomagot.
Akkor most egy ideig nem is szlnk semmit, mindenkit megkrek, hogy az eddigi
informcik alapjn nzze t alaposan a kpeket.
.
nz
.
.
mg mindig nz
.
.
Gondolom, megvolt. Akkor nzzk t egytt. Mindkt brn lthat, hogy a
csomagban az IDENTIFICATION mez rtke 0xddda. Teht ugyanahhoz az eredeti
csomaghoz tartoznak. Az els kpen a FLAGS mez bitjei jelzik, hogy a csomag nem
nem (sic) tredezett (don't fragment not set), azaz tredezett - s ezen bell mg
tbb csomag is van (more fragments set), azaz ez nem az utols adag. Az utols
tredknl a more fragments rtke not set, azaz jelzi, hogy nincs mr tbb tredk
ebbl a (0xddda) csomagbl.
Nzzk akkor mg a FRAGMENT OFFSET rtket: a harmadik csomagnl 2960, a
negyedik csomagnl pedig 4440. Itt mr azrt kellene jcskn matekozni, ha a
Wireshark nem lenne olyan kedves s nem adna pontosabb infkat is.
Elszr pldul a fels tbln mr a keret sszefoglal sorban is lthatjuk az egyes
offset rtkeket. (Ha esetleg ismeretlen lenne a fogalom: offset alatt mindig
valamilyen rtkhez kpesti elcsszst szoktunk rteni.) Az els keretnl az offset
nulla, azaz a keret sszerakskor a 0. pozcibl fog indulni. A msodik keret rtke
1480, azaz a keret a kpzeletbeli szmegyenesen az 1480. pozcibl indul, azaz az
elz az 1479. pozciban vgzdik. A harmadik keret offset rtke 2960, a
negyediknl ugyan nem ltjuk a fsorban, de ha rnznk az alatta lv ablak aljra,
meglehetsen vilgosan s egyrtelmen ltjuk, melyik csomag mettl meddig tart
rszt kpezi az eredeti szttrdelt csomagnak.
~ 105 ~

Ok. Mr csak egy krds tisztzsa maradt htra: mennyi is akkor az MTU?
Nyilvn els krben azt mondannk, hogy 1480. Hiszen ekkora darabokbl ll ssze
a vgs csomag.
De.
Nzzk meg alaposabban az brkat. Ltunk IP OPTIONS mezt? Nem. Akkor
mekkora lehet a fejlc? 20 bjt. Gyorsan csekkoljuk le, nzzk meg a HEADER
LENGTH mez rtkt: ott is azt ltjuk, hogy '20 bytes'.
Teht IP csomagon bell a fejlc 20 bjt, a payload pedig 1480 bjt. Ugyanezt sszeg
formjban is lthatjuk, ha rnznk a harmadik csomag TOTAL LENGTH mezjnek
rtkre.
Csakhogy, hogyan is definiltuk az MTU-t? gy, hogy az a NIL kereten bell a
payload - de ez viszont a teljes IP datagram, azaz 1500 bjt. az MTU.
Egy dolgon lehet mg elgondolkodni: mi is van akkor a fejlcekkel? Hiszen a vgs
csomagnak csak egy IP header-e van, ezzel szemben a ngy tredknek bizony ngy.
Nem vesz el ez rtkes biteket a keretekbl?
De, elvesz.
Amikor ssze kell raknunk a csomagot, akkor kapunk 3 darab 1480 bjtos s 1 darab
568 bjtos payload tartalmat, illetve 4 darab 20 bjtos fejlcet. A ngy fejlc alapjn
legyrtjuk az eredeti csomag 20 bjtos fejlct - 60 bjt informci pedig megy a
kukba. Aztn az eredeti payload mr csak a tredkek 1480 bjtos payload
darabkibl, illetve az utols tredk maradk payload darabkjbl lesz
sszerakva.
Most kpzeljk el a kvetkezt: szegny csomagunkat rossz sorsa olyan tvonalra
vezeti, ahol az egyik alhlzat MTU rtke 4460, a kvetkez alhlzaton ugyanez
2662, majd a harmadik alhlzaton 1500. Mi trtnik ilyenkor? Lehet-e a tredezett
csomagokat tovbb trdelni? Le tudja-e ezt kezelni az IP rteg?
Igen, le tudja.
Csak nem szereti.
Mi sem.
Szerencsre ma mr az ilyesmi nagyon ritka, nem is nagyon mennk bele a konkrt
megvalsts boncolgatsba.
Mindenesetre ha teljesen rejtlyesen, kiszmthatatlanul viselked hlzati
kommunikcival tallkozol, mely hol j, hol nem - akkor elszr mindig az MTU
krnykn rdemes sztnzned.
~ 106 ~
4. 1 .1 . 2 IP O P T I O N S
Mint korbban is rtam, ez egy opcionlis mez. Ha nincs, gy is j. Ha van, gy is j.

De, mint ltni fogjuk, itt fleg olyan informcik utaznak, melyeknek tl sok kzk
nincs az IP payloadhoz - itt inkbb a kommunikci komponensei zengetnek
egymsnak, jrszt tesztelsi clzattal.
Ezek az zenetek 1 s 40 bjt kztt tetszleges mretek lehetnek - de
emlksznk,33 a mretnek nggyel oszthatnak kell lennie. Hny IP Option lehet egy
IP fejlcben? Amennyi belefr. Majd megltjuk. Hogyan kell sztosztani az egyes IP
Option csomagokat, ha fragmentldott az IP datagramm? Attl fgg. Majd
megltjuk.
Akkor lssuk meg.
OPTION CODE: 1 bjt, vezrlinformcik. Ennek a rszei:
COPY:
Balrl az els bit. Tredezett IP datagramok esetn van szerepe.

Amennyiben az rtke 0, akkor az IP Option csomagok csak az els tredkbe
kerlnek bele. Ha 1, akkor mindegyikbe.
OPTION CLASS: Balrl a msodik s a harmadik bit.
4.2. TBLZAT
Option Class binrisan
00
01
10
11
Option Class decimlisan

0
1
2
3
Lers
Hlzati kontroll
Majd csak j lesz valamire
Nyomozs, mrs
Majd csak j lesz valamire
OPTION NUMBER: A
maradk t bit egy azonost kd. Ez mondja meg, hogy ki is

pontosan a konkrt IP Option.
4.3. TBLZAT
Copy bit
0
0
1
0
1
1
0
33
Option Class
00 (0)
00 (0)
00 (0)
00 (0)
00 (0)
00 (0)
10 (2)
Option number
00000 (0)
00001 (1)
00011 (3)
00111 (7)
01001 (9)
10100 (20)
00100 (4)
Lers
End Of Option List
No Operation
Loose Source Routing
Record Route
Strict Source Routing
IP Router Alert
Internet Timestamp
Tulajdonkppen most rom le harmadszor, teht lassan mr muszj lesz.
~ 107 ~

Nem csak a fenti tblzatban lv IP opcik lteznek.
A teljes lista itt tallhat meg:
http://www.iana.org/assignments/ip-parameters
4.1 .1 .2 .1 E N D O F O P T I O N L I S T , N O O P E R A T I O N
A kt IP opcit nyugodtan kezelhetjk egytt. Mind a kettnek egy bjtnyi az rtke,

ez gyakorlatilag az OPTION CODE. Az els rtke 0, a msodik 1. A NO OPERATION
bjt (1) vlasztja el egymstl a klnbz IP Option csomagokat, az END OF THE
OPTION LIST bjt (0) pedig lezrja az utolst.
4.1 .1 .2 .2 R E C O R D R O U T E
4.8. BRA R ECORD R OUTE
Itt nincs tl nehz dolgom: egyszeren csak le kell fordtanom a nevet.

Record route -> feljegyezzk az tvonalat. Azaz megy a csomag hop-rl hop-ra, Az
ugrs sorszma kerl bele a Next Slot Pointer mezbe34, a router IP cme pedig a
soron kvetkez IP Address mezbe.
Pontosabban sorszm*4, mert egy IP cm 4 bjt, s gy kapjuk meg azt a mretnvekmnyt, melyet
majd ssze kell hasonltanunk az Option Length mez rtkvel ahhoz, hogy eldnthessk, egyltaln
rgzthetjk-e mg az IP cmeket, vagy mr tlcsordultunk.
34
~ 108 ~
4.9. BRA R ECORD R OUTE IP O PTION
Az brn egy kiknyszertett Record Route lthat. gy vettem erszakot a

rendszeren, hogy bertam a ping -r 4 index.hu parancsot. Jelen esetben a 4-es szm az
Option Length paramter rtke - ez jelenti azt, hogy maximum 4 IP cmet
jegyezhetek fel. Ltszik is szpen az IP Option kikalkullt mrete: 4*4 bjt az IP
cmeknek, 1 bjt az Option Code (az rtke ugye 7), 1 bjt az Option Length s 1 bjt
a Next Slot Pointer - azaz sszesen 19 bjt. (Nyilvn a nggyel oszthatsg miatt lesz
1 bjt padding is, jelen esetben rtelemszeren egy End of Option List mez.)
Azt is tudjuk, hogy az IP fejlc maximlis mrete 60 bjt, teht maximum 9 IP cmet
tudunk rgzteni. Ha tbb esik tba, akkor gy jrtunk. (De legalbb megsproltunk
pr bitet az Internet Header Length meznl.)
Akkor most mr csak az a krds, hogy mirt nem ltunk semmit a csomagban?
Nos, semmi garancia sincs arra, hogy mind az n hlzatomban, mind a vad
interneten bartsgos routereket fogok tallni. Nzzk csak meg mg egyszer az
brt? Egy csom echo request, de nincs egyetlen echo reply sem. Valjban tnyleg
ez is trtnt: a ping timeout-ra futott - azaz a routerek nem voltak hajlandak
egyttmkdni.
Egy fontos megjegyzs: ha esetleg arra gondolnl, hogy a tracert is ilyen
mdon szedi ssze egy tvonal llomsait, akkor tvedsz. Az ugyanis mindig
eggyel nagyobb TTL rtk pinggel prblkozik.
~ 109 ~
4.1 .1 .2 .3 S T R I C T S O U R C E R O U T I N G / L O O S E S O U R C E R O U T I N G
Az ers emberek opcija. Megmondjuk annak a nyomorult IP csomagnak, hogy

konkrtan milyen tvonalon jusson el a clllomshoz. Mghozz a STRICT esetben
routerrl routerre elrjuk az tvonalat, mg a LOOSE esetben csak azokat a
routereket adjuk meg, melyeken t kell haladnia a csomagnak - hogy kzben merre
bklszik, az az dolga.
Jogos lehet a krds: ennek meg ugyan mi rtelme van? Azrt lteznek klnbz
routolsi algoritmusok, azrt fecsegnek ezek a routerek olyan sokat egyms kztt,
hogy lehetleg minden csomag optimlis tvonalon kzlekedjen. Hogyan jvk n, a
felad host, ahhoz, hogy elrjam az tvonalat?
Emlkezznk vissza: mire is hasznljuk ltalban az IP Options blokkokat?
Tesztelsre. Itt is errl van sz. Ha olyan a hlzatunk, hogy van benne egy
alacsonyabb kltsg tvonal, meg a biztonsg kedvrt egy magasabb kltsg
alternatv tvonal, akkor hogyan tudjuk letesztelni, hogy a msodik tvonal ppen
mkdik-e? Hiszen minden csomag az els tvonalon megy. Mkd hlzatot meg
megszaggatni a teszt kedvrt... nem elegns.
Ilyenkor jnnek be a kpbe a SOURCE ROUTING opcik.
4.10. BRA S TRICT S OURCE R OUTING
OPTION CODE: STRICT esetben 137, LOOSE esetben 131. (Kibonts: 4.1. tblzat )
OPTION LENGTH S NEXT SLOT POINTER: Ugyanaz a matek, mint az elz IP opcinl.
FIRST IP ADDRESS, SECOND IP ADDRESS, OTHER IP ADRESSES: Ide kretik felsorolni az sszes
rintend IP cmet. Mennyi is lehet bellk? Az IP OPTIONS max 40 bjt, ebbl
megettnk hrmat, marad 37, az IP cm 4 bjtos, azaz osztunk nggyel - marad
kilenc. Ennl hosszabb tvonalat, ha belegebednk sem tudunk sszelltani.
~ 110 ~

Szaladjunk t gyorsan a folyamaton. A router/destination host megkapja a csomagot.
Ha a NEXT SLOT POINTER rtke nagyobb, mint az OPTION LENGTH rtke, akkor
megdbbenve veszi tudomsul, hogy a csomag neki szlt. Amennyiben nem, akkor a
kvetkezk trtnnek:
Megnveli nggyel a NEXT SLOT POINTER mez rtkt.
A router belenyl az IP datagram htizskjba, elveszi a kvetkez IP cmet.
Ezzel az IP cmmel fellrja az IP csomag fejlcben szerepl DESTINATION IP
ADDRESS mez rtkt.
Belerakja a sajt cmt az IP csomag htizskjba, mghozz gy, hogy az
elz hop-nl elhasznlt IP cmet rja fell.
Kirgja a csomagot.
Egy utols gondolat: a SOURCE ROUTING nem mindenhol engedlyezett. Az
interneten pldul tipikusan nem.
~ 111 ~
4.1 .1 .2 .4 IP R OU TER AL ER T
Azaz a vszcseng. Ez az, amikor az vods nzk felkiabljk Vitz Lszlnak, hogy
'Vigyzz, jn a Csokoldpofa!'.
Ugyanez informatikusra fordtva azt jelenti, hogy ez az IP opci figyelmezteti az
aktulis hostot, hogy vigyzat, ezzel a csomaggal valamit csinlnia kell a
tovbbpasszolson kvl. Tipikusan ilyenek a ksbb rszletezend IGMP csomagok.
4.11. BRA IP R OUTER A LERT
Lthat, a csomag szerkezete nincs igazn tlbonyoltva.

OPTION CODE: rtke 148.
OPTION LENGTH: rtke fix 4-es.
VALUE: Jelen esetben az rtke 0.
~ 112 ~
4.1 .1 .2 .5 IN TE R N E T T IM E S TAM P
Nmileg hasonlt a RECORD ROUTE opcihoz - csak itt nem az tvonalat, hanem a
csomag megrkezsi idpontjait rgztik a routerek, illetve a cllloms.
Pusztn rdekessgknt jegyzem meg, hogy az idt az elz jfl ta eltelt
milliszekundumokban mri.
4.12. BRA I NTERNET T IMESTAMP
OPTION CODE: 68. Ugye, mr nem kell rszleteznem?

OPTION LENGTH, NEXT SLOT POINTER: Ugyanazok, mint eddig.
OVERFLOW: Lthattuk, az IP OPTIONS blokk mrete vges. Mi van, ha kilencnl tbb
hoston megy t a csomag? Akkor itt, az OVERFLOW mezben lthatjuk, hny host
maradt ki. (4 bit, teht max 15.)
FLAGS: Itt tudjuk megadni, hogy tulajdonkppen mit is rgztsnk: csak az
idblyeget(0), vagy rjuk mell a host IP cmt is(1)? rtelemszeren az utbbi
esetben feleannyi hop adatait tudjuk rgzteni, azaz hamarabb lp plyra az
OVERFLOW mez is.
~ 113 ~
4.13. BRA FLAG=1
Van mg egy meglehetsen klnleges rtke a FLAG meznek, ez a 3-as. Ekkor

megint htizskozunk: belerakunk elre IP cmeket a batyuba, az idblyeg pedig
csak akkor rgzdik, amikor elrjk az elrt IP cmmel rendelkez hostot.
IP ADDRESS / TIMESTAMP: A rgztett rtkek.
s akkor a dem.
4.14. BRA I NTERNET T IMESTAMP MEGADSA A PING PARANCSON BELL
~ 114 ~
4.15. BRA I NTERNET T IMESTAMP LELEPLEZVE
A fenti brbl lthat, hogy csak a szomszdos hostot pingettem meg. (Egy IP cm
s egy idblyeg bejegyzs van mindsszesen a batyuban.) n a szvem szerint
pingettem volna tvolabbi hostokat is, de mr a kvetkez routeren sem volt
engedlyezve ez az IP opci... az internetrl mr nem is beszlve.
Matekozzunk egy kicsit. Szmoljuk ki pldul az idblyegbl, mennyire volt
kaporszakll reg este, amikor ez a capture kszlt?
Mindkt bra azt mondja, hogy az idblyeg: 4271687066 ms, azaz osztva 1000 s
osztva 3600, az annyi, mint az elz jfl utn 1186,6 ra.
Ejnye, de megvltozott mostansg az idszmts.
Valami nem stimmel.
Tovbb olvasva az RFC 791-et, azt mondja, hogy amennyiben nem ll a router
rendelkezsre UTC formj id, vagy az nem millisecundum pontossg, akkor
gyakorlatilag brmi is lehet az idblyeg. Ezt onnan tudjuk, hogy ilyenkor a
legmagasabb helyirtk bit magasra lett lltva. Hogyan is nz ki a szmunk
binrisban?
gy: 11111110100111001100010110011010.
Bizony, a bal szls rtk magas... azaz innentl nem kthet ssze direktben a szm
a vals idrtkkel.
De legalbbis nem publikus a kplet.
~ 115 ~

4.1.2 L ET
A HA T R O N :
R O U T E , NAT, P RO X Y
Sokig - kimondva-kimondatlanul - olyan esetekrl beszltnk, amikor a felad s a

cmzett egy alhlzaton vannak. Csakhogy az elz fejezetben mr knyelmetlenl
sokszor hangzott el az a sz, hogy 'router'. Felttelezem, sok emberben horgadt fel a
krds, hogy mennyiben is vltoznak meg a csomagok akkor, ha hatrrk is
vegzljk a kldemnyeket?
Akkor nzzk, mi is trtnik pontosan a hatron. Az els, s messze a legkorrektebb
megkzelts az, hogy attl fgg35.
Ugyanis egy csomagot lehet routolni meg natolni.
Mi a klnbsg?
Messzirl fogunk kzelteni.
Mindenki tudja, mi az az IP cm?
Minden krdsre vlaszold nyugodtan azt, hogy attl fgg. Egyrszt gy a krdez lesz
rknyszertve arra, hogy tbb informcit adjon, msrszt idt nyersz a j vlasz megfogalmazsra
is. Csak az nmaguktl elvakult emberek, illetve a remnytelenl navak akarnak mindig egybl
vlaszolni.
35
~ 116 ~
4. 1 .2 . 1 A Z I P C M
Ok, elismerem, egy hlzatokrl s a TCP/IP-rl szl knyv szzvalahanyadik

oldaln elg hlyn hangzik ez a krds. De gy tapasztaltam, nha nem rt az
evidencikat is elmagyarzni, hogy szp kerek legyen az anyag.
Teht az IP cm az egy ngybjtos azonost, mely nmagban nem mond semmit.
Minden IP cmhez tartozik egy msik ngybjtos szm, az n. alhlzati maszk
(subnet mask). Ez definilja, hogy magbl az IP cmbl hny bit azonostja a
hlzatot s hny bit a hlzaton bell a krdses hostot.
Pldul a 192.168.1.164 IP cm s a 255.255.255.0 alhlzati maszk a kvetkez
dolgokat hatrozza meg:
A hlzat azonostja
: 192.168.1
A hlzaton bell a host azonostja
: 164.
Mirt? A binris matek miatt:
192.168.1.164
255.255.255.0
-> 11000000 10101000 00000001 10100100

-> 11111111 11111111 11111111 00000000
Azt mondjuk, hogy amg az alhlzati maszk rtke 1, addig tart a hlzat azonost,
amikor pedig 0, akkor ott mr a host azonostt kapjuk. Valamivel matekosabban
gy is mondhatnm, hogy az IP cm s az alhlzati maszk binris szorzata (AND)
adja a hlzat azonostjt, illetve az alhlzati maszk negltja (NOT) szorozva az IP
cmmel adja a host azonostjt.
Szoktk ezt gy is jellni, hogy nem rjk le az alhlzati maszk minden egyes bitjt,
csak megadjk, hogy hny darab egyes van benne. (Remlem, az nem lep meg, hogy
az alhlzati maszk mindig balra zrt - azaz balrl tltdik fel egyesekkel.)
Ekkor a fenti plda gy nz ki: 192.168.1.164/24.
Nyilvn az sem nagy meglepets, hogy ebben az esetben a hlzaton 256 klnbz
host lehet. (Igazbl 254, mert a kt szls cm fenn van tartva a hlzat
beazonostsra, illetve a broadcast cmre.)
~ 117 ~

Vizsgljunk meg egy cifrbb esetet.
Hogyan szedjk kett a kvetkez IP cmet: 10.48.247.6/20?
Binrisan:
IP cm
: 00001010 00110000 11110111 00000110
Alhlzati maszk
: 11111111 11111111 11110000 00000000
Innen mr csak vissza kell konvertlgatni:
Hlzat azonost : 10.48.240
Host azonost
: 7.6
A hostok maximlis szma pedig: 212-2, azaz 4094.
Csavarjunk mg egyet a pldn. Fogja-e egymst kzvetlenl ltni a kvetkez kt
host: 10.48.247.6/20 s 10.48.247.5/22?
Miutn mindenki megtette a ttjeit, vgjunk bele. Mikor ltja egymst kt host?
(Router nincs.) Ha azonos alhlzaton vannak.
Matek.
Az els cm felbontst fentebb lthattuk. Jhet a msodik cm.
IP cm
: 00001010 00110000 11110111 00000101
Alhlzati maszk
: 11111111 11111111 11111100 00000000
Hlzat azonost
: 10.48.244
Host azonost
: 3.5
A hostok maximlis szma : 210-2, azaz 1022.
Megegyezik a kt hlzat azonostja? Nem. Teht a kt host kzvetlenl nem ltja
egymst - dacra annak, hogy az IP cmk szomszdos. Csak ppen a maszk
klnbzik.
Mg egy feladat, ha mr gy belejttnk. Fogja-e ltni egymst - router nlkl - az
albbi kt host?
4.4. TBLZAT
Nv
host1
host2
host1:
IP cm
192.168.154.63
192.168.154.64
IP cm
Alhlzati maszk
Hlzat azonost
Host azonost
Hostok maximlis szma
~ 118 ~
Alhlzati maszk
255.255.255.192
255.255.255.192
: 11000000 10101000 10011010 00111111

: 11111111 11111111 11111111 11000000
: 192.168.154.0
: 63
: 2^6-2, azaz 62.

host2:
IP cm
Alhlzati maszk
Hlzat azonost
Host azonost
Hostok maximlis szma
: 11000000 10101000 10011010 01000000

: 11111111 11111111 11111111 11000000
: 192.168.154.64
:0
: 2^6-2, azaz 62.
Nos, ltjuk? Megint nem egyeznek meg a hlzati azonostk. Megint nem fogjk
ltni egymst. Pedig itt rnzsre minden stimmelt, azonosak voltak az alhlzati
maszkok, szomszdosak voltak az IP cmek... aztn mgsem.36
Maradjunk annyiban, hogy gyakorlott szem kell az IP cmekkel val kavarshoz. s
ha csak egy picit is bizonytalan vagy, akkor mindenfle szgyenkezs nlkl el kell
kapni a calc.exe programot s kiptygni a vlaszt.
Remlem, rthet volt a levezets. Sosem rt ugyanis, ha pontosan tisztban
vagyunk az elmlettel. Mg akkor sem, ha a gyakorlat kicsit mskppen mkdik.
A kristlytiszta elmlet ellenre ugyanis a fenti host-ok ltni fogjk egymst. Router
nlkl is.
A folyamat megrtshez szedjk el az emptinkat. Prbljuk megrteni, mit is
ltnak az adott szitucikbl az egyes host-ok?
Rgtn ott kezddik, hogy amikor egy alkalmazs kldeni akar egy csomagot egy IP
cmre, akkor nem tudja a cmzett subnet mask rtkt. Azt ugyanis nem szoktk
megadni. Mit tehet szegny IP rteg? Indulskppen veszi a felad subnet mask
rtkt, majd megnzi, hogy ezen belltsokkal egy subnet-en van-e a cmzettel?
Jelen esetben igen, dacra annak, hogy a cmzett, a sajt subnet mask rtke szerint
nem! Kld egy ARP request-et, s mivel ebben a csomagban is csak IP cm van, a
cmzett radsul egy linken is van vele, gy az ARP broadcast megtallja. A cmzett
vlaszul klden a sajt MAC cmt a feladnak. Pikns mdon is csak a felad IP
cmt s a sajt subnet mask rtkt tudja, ezek alapjn viszont is gy ltja, hogy
egy subnet-en vannak a feladval, teht a feladnak kldi az ARP response
csomagot, nem a routernek. Bjos esemny, hogy a felad meg is kapja, hiszen egy
linken vannak. Abban a pillanatban, hogy mindkt host megkapja egyms MAC
cmt, lendletbl be is indul a kommunikci, kzvetlenl a kt host kztt. A
router jelen esetben csak a gyertyt tartja.
Cifra? Igen. De mkdik. (Megjegyzem, nem egyrtelm, hogy ez j is. Szvsz
clszerbb lenne, ha a trehnyul konfigurlt rendszerek inkbb nem is
mkdnnek.)
Tessk szrevenni az ordas csalst. Host1 igazbl egy alhlzat legfels cme, azaz a broadcast
cm, Host2 pedig a vele fentrl rintkez alhlzat legals cme, azaz a hlzat azonostja. Ergo ilyen
IP cm hostok nem is ltezhetnek. Ettl persze a plda mg j, csak ppen a valsgban host1 utols
oktettje 62, illetve host2 utols oktettje 65 lett volna.
36
~ 119 ~

Vissza a fsodorhoz. Nos, a vilg nem volt mindig ilyen rugalmas, mint ahogy n
eddig kavartam. Nagyon sokig ilyen bonts egsz egyszeren nem volt
engedlyezve. Az IP cmek osztlyokba voltak sorolva, mgpedig az alhlzati
maszkok szigor behatrolsval. Valahogy gy.
4.5. TBLZAT
Osztly
Bal
oldali
bitek
A
0
B
10
C
110
D
1110
(multicast)
E (foglalt)
1111
Hlzatokat
ler
bitek
szma
8
16
24
Als
hatr
Fels hatr
Hlzatok
szma
1.0.0.1
128.1.0.1
192.0.0.1
224.0.0.0
126.255.255.254
191 .255.255.254
223.255.255.254
239.255.255.254
127
16384
2097152
240.0.0.0
254.255.255.254
Hostokat
ler bitek
szma
24
16
8
Hostok
szma
16777214
65534
254
Ezt valamikor gy hvtk, hogy Classful IP cmkioszts. Szerencsre elrplt felette

az id vasfoga. Ez ugyanis borzasztan pazarl volt - az IP cmek pedig kezdtek
rohamosan elfogyni.
A cmfogysra volt az egyik megolds a CIDR37, azaz az alhlzati maszkok sokkal
rugalmasabb tologatsa. (Ezt mutatta be a msodik/harmadik matekozs plda.)
A msik megolds pedig a NAT38.
Az a NAT, ami mshogy mkdik, mint a routols.
37
38
Classless Inter Domain Routing

Network Address Translation
~ 120 ~
4. 1 .2 . 2 R O U T E
Ehhez persze elszr el kell mlyednnk a routols lelkivilgba - s majd csak

utna trhetnk vissza a NAT-hoz.
Mr az sem egyszer, mit is neveznk routolsnak? Routols az, ha
betrcszunk/bevpeneznk egy hlzatba, ahol egy IP poolbl kapunk cmet?
Nem, ha az IP pool a bels hlzatbl van kihastva, azaz ugyanaz a hlzati
azonostnk, mint a tbbi gp. Ekkor csak bridzsels39 trtnik.
Routol pldul egy switch? Nem. A switchek ltalnossgban az ISO/OSI L2
rtegben dolgoznak (ebben a knyvben ez a NIL rtegnek felel meg), mg a
routerek az L3-ban40. (Amely itt az Internet rteg.)
Gondolom, mr krvonalazdik: routols akkor trtnik, ha egy kldemny az egyik
alhlzatbl egy msikba szeretne tmenni. (A protokoll termszetesen azonos.) A
router pedig az az elem, amelyiknek egyik lba az egyik hlzatba, a msik lba
pedig a msikba lg bele41 - pedig kpes a kett kztti forgalom lebonyoltsra.
Alakulunk.
ssunk bele egy kitallt folyamatba.
4.16. BRA R OUTOLS HLZATBAN
1. A Forrs nvvel jellt szmtgpnek halaszthatatlan kzlendje tmad,

melyet a Cl nev szmtgppel szeretne megosztani. A hlzat egyszer
Ethernet.
1 szan - 2 treff.
Tudom, hogy van L3 switch is, de ezekkel most nem akarom bonyoltani a knyvet.
41 Megjegyzem, lttam mr szzlb routert is.
39
40
~ 121 ~

2. A Cl nev szmtgp IP cmt megszerzi valahonnan. (Vagy benne van a
programban, vagy segtsgl hvja a nvfeloldsi folyamatot s mondjuk egy
DNS szerver megsgja neki.)
3. Szomoran veszi tudomsul, hogy abszolt ms hlzatrl van sz, teht
kzvetlenl nem tudja elkldeni a csomagot.
4. Egy - ksbb trgyaland algoritmussal - megszerzi annak a hostnak az IP
cmt, mely felels az idegen hlzatba kldtt csomagok tovbbtsrt. Ez
jelen esetben a Router A lba lesz.
5. Az IP cm birtokban - az ARP segtsgvel - begyjti a Router A MAC
address-t, s gy mr ssze tudja rakni a kldend csomagot:
a. Source IP address : 192.168.12.25
b. Source MAC address : 00-1e-8c-ab-37-2e
c. Target IP Address : 10.10.99.124
d. Target MAC address : 00-18-f8-f1-34-0a (!!)
6. Mivel egy fogadott csomag beazonostsa alulrl felfel trtnik (2.1. bra
Rtegek s csomagok (forrs: Wikipedia), gy a Target IP cm hiba a Cl
szmtgp, de a Target MAC address miatt a Router A magnak fogja
rezni a csomagot. Felszipkzza. A Target IP alapjn rtelmezi a feladatot,
megkeresi, melyik lbn kell tovbbtania a csomagot (ne feledjk, lteznek
szzlb routerek is), az ARP segtsgvel begyjti a Cl szmtgp MAC
address rtkt, majd sszerakja a kvetkez csomagot:
a. Source IP address : 192.168.12.25
b. Source MAC address : 00-1e-8c-f1-34-0a
c. Target IP Address : 10.10.99.124
d. Target MAC address : 00-0d-87-3d-4e-4d
7. A Target MAC address miatt a Cl szmtgp felveszi a csomagot, a Target IP
cm alapjn ltja, hogy neki szl. Boldog. Miutn megrkezett az sszes
csomag, sszerakja az zenetet, s az eddig trgyalt mdon vlaszol.
Nagyon durvn ennyi. De mr most is lthat, hogy van egy-kt zavaros terlet:
Honnt is tudja a Forrs, hogy neki pont Router A szmra kell elkldeni ezt
a csomagot?
Honnt is tudja a Router, hogy melyik lbn kell tovbbkldenie a csomagot?
s mi van akkor, ha a Cl szmtgp nem kapcsoldik kzvetlenl a
Routerhez, hanem van kztk mondjuk mg 5 darab kztes router is?
Elszr ismerkedjnk meg a Default Gateway, illetve a route tbla fogalmakkal.
A Default Gateway, mint a neve is mutatja, maga a default, azaz az alaprtelmezett.
Ez elmletileg azt jelenti, hogy minden esetben, amikor a host a sajt alhlzatrl
idegen alhlzatra szeretne csomagot kldeni, akkor erre a cmre tovbbtja azt.
~ 122 ~

A 4-es pontban innt, ebbl a belltsbl tudta a Forrs, hogy ki lesz a kvetkez
hop az tvonalon. Elmletben.
A gyakorlatban viszont rhgve megjelenik a sznen a route tbla.
A route tbla ugyanis egy nagyon pontosan, finoman szablyozhat tvlaszt
tblzat, melynek rsze a Default Gateway koncepci is, de ennl jval finomabban is
lehet szablyozni az egyes megclzott tvonalakat. Gondoljunk bele pldul egy
olyan esetbe, ahol egy alhlzatbl nem csak egy router nyit kijratot.
Rgen matekoztunk mr.
===========================================================================
Interface List
8 ...00 1e 8c ab 37 2e ...... Realtek RTL8168B/8111B Family PCI-E GBE NIC
1 ........................... Software Loopback Interface 1
9 ...02 00 54 55 4e 01 ...... Teredo Tunneling Pseudo-Interface
13 ...00 00 00 00 00 00 00 e0 isatap.{47CE5CAA-223F-4CD4-9A17-D91D7DDC2066}
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination
Netmask
Gateway
Interface Metric
0.0.0.0
0.0.0.0
192.168.1.1
192.168.1.101
20
127.0.0.0
255.0.0.0
On-link
127.0.0.1
306
127.0.0.1 255.255.255.255
On-link
127.0.0.1
306
127.255.255.255 255.255.255.255
On-link
127.0.0.1
306
192.168.1.0
255.255.255.0
On-link
192.168.1.101
276
192.168.1.101 255.255.255.255
On-link
192.168.1.101
276
192.168.1.255 255.255.255.255
On-link
192.168.1.101
276
192.168.99.0
255.255.255.0
192.168.1.2
192.168.1.101
21
224.0.0.0
240.0.0.0
On-link
127.0.0.1
306
224.0.0.0
240.0.0.0
On-link
192.168.1.101
276
255.255.255.255 255.255.255.255
On-link
127.0.0.1
306
255.255.255.255 255.255.255.255
On-link
192.168.1.101
276
===========================================================================
Persistent Routes:
Network Address
Netmask Gateway Address Metric
192.168.99.0
255.255.255.0
192.168.1.2
1
===========================================================================
gy nz ki a szmtgpem tvlasztsi tblzata. Rnzsre vannak sorok, melyek

egszen jl rtelmezhetek... de az egsz... egy kicsit zrs.
De csak addig, amg el nem kezdnk szmolgatni.
~ 123 ~

Vegynk 3 megclzott IP cmet:
1. 192.168.1.103, binrisan 11000000 10101000 00000001 01100111
2. 192.168.99.17, binrisan 11000000 10101000 01100011 00010001
3. 195.247.14.56, binrisan 11000011 11110111 00001110 00111000
Most jn a neheze. Szorozzuk ssze ezeket egyenknt binrisan (AND) az
tvlasztsi tblzatban szerepl Netmask rtkekkel, melyeket a lenti tblzat 2. s
3. oszlopa is tartalmaz..
1. (192.168.1.103):
11000000 10101000 00000001 01100111 AND...
4.6. TBLZAT
Ssz
1
2
3
4
5
6
7
8
9
10
11
12
NetMask
0.0.0.0
255.0.0.0
255.255.255.255
255.255.255.255
255.255.255.0
255.255.255.255
255.255.255.255
255.255.255.0
240.0.0.0
240.0.0.0.
255.255.255.255
255.255.255.255
NetMask binrisan
00000000.00000000.00000000.00000000
11111111. 00000000.00000000.00000000
11111111.11111111.11111111.11111111
11111111.11111111.11111111.11111111
11111111.11111111.11111111.00000000
11111111.11111111.11111111.11111111
11111111.11111111.11111111.11111111
11111111.11111111.11111111.00000000
11110000.00000000.00000000.00000000
11110000.00000000.00000000.00000000
11111111.11111111.11111111.11111111
11111111.11111111.11111111.11111111
Eredmny
00000000.00000000.00000000.00000000
11000000 00000000 00000000 00000000
11000000 10101000 00000001 01100111
11000000 10101000 00000001 01100111
11000000 10101000 00000001 00000000
11000000 10101000 00000001 01100111
11000000 10101000 00000001 01100111
11000000 10101000 00000001 00000000
11000000.00000000.00000000.00000000
11000000.00000000.00000000.00000000
11000000 10101000 00000001 01100111
11000000 10101000 00000001 01100111
rjuk fel a Network destination rtkeket is binrisan, majd tegyk mell az elz
tblzat Eredmny oszlopt.
4.7. TBLZAT
Ssz
1
2
3
4
5
6
7
8
9
10
11
12
Network Destination
0.0.0.0
127.0.0.0
127.0.0.1
127.255.255.255
192.168.1.0
192.168.1.101
192.168.1.255
192.168.99.0
224.0.0.0
224.0.0.0.
255.255.255.255
255.255.255.255
Network Destination binrisan

00000000.00000000.00000000.00000000
01111111. 00000000.00000000.00000000
01111111. 00000000.00000000.00000001
01111111.11111111.11111111.11111111
11000000.10101000.00000001.00000000
11000000.10101000.00000001.01100101
11000000.10101000.00000001.11111111
11000000.10101000.01100011.00000000
11110000.00000000.00000000.00000000
11110000.00000000.00000000.00000000
11111111.11111111.11111111.11111111
11111111.11111111.11111111.11111111
Elz eredmny
00000000.00000000.00000000.00000000
11000000 00000000 00000000 00000000
11000000 10101000 00000001 01100111
11000000 10101000 00000001 01100111
11000000 10101000 00000001 00000000
11000000 10101000 00000001 01100111
11000000 10101000 00000001 01100111
11000000 10101000 00000001 00000000
11000000.00000000.00000000.00000000
11000000.00000000.00000000.00000000
11000000 10101000 00000001 01100111
11000000 10101000 00000001 01100111
CT
32
0
0
0
32
30
24
17
2
2
2
2
A tblzathoz hozzfztem egy CT, azaz counter oszlopot. Ez az rtk mutatja azt,
hogy ha a harmadik s a negyedik oszlopot balrl jobbra haladva binrisan
sszehasonltom, akkor meddig, azaz hanyadik karakterig tart az egyezs.
Az a sor nyer, ahol a legnagyobb ez az rtk. Holtverseny esetn a NetMask
egyeseinek szma dnt.
~ 124 ~

Jelen tblzatban mind az els, mind az tdik sorban a CT rtke 32, de az els
sorhoz tartoz Netmask-ban az egyesek szma hatrozott nulla, mg az tdik
sorban 24. Azaz a 192.168.1.103 cm megtmadsa esetn az 5. sor nyert, ezt
visszakeresve a route tblbl, lthatjuk, hogy a 192.168.1.101 hlzati krtyn kell
kimennnk, s onlink-en vagyunk, teht nincs szksgnk routerre.
2. (192.168.99.17):
11000000 10101000 01100011 00010001 AND...
Az elz pldban becsletesen vgigszmoltunk minden sort. A tovbbiakban
annyibl egyszerstenk, hogy a localhostra (127.0.0.1), a multicast-ra (240.0.0.0)
s a broadcast-ra (255.255.255.255) vonatkoz sorokat kivennm. A pldinkban
ezek sohasem fognak nyerni.
4.8. TBLZAT
Ssz
1
2
3
4
5
6
7
8
9
10
11
12
NetMask
0.0.0.0
NetMask binrisan
00000000.00000000.00000000.00000000
Eredmny
00000000.00000000.00000000.00000000
255.255.255.0
255.255.255.255
255.255.255.255
255.255.255.0
11111111.11111111.11111111.00000000
11111111.11111111.11111111.11111111
11111111.11111111.11111111.11111111
11111111.11111111.11111111.00000000
11000000 10101000 01100011 00000000

11000000 10101000 01100011 00010001
11000000 10101000 01100011 00010001
11000000 10101000 01100011 00000000
4.9. TBLZAT
Ssz
1
2
3
4
5
6
7
8
9
10
11
12
Network Destination
0.0.0.0

00000000.00000000.00000000.00000000
Elz eredmny
00000000.00000000.00000000.00000000
CT
32
192.168.1.0
192.168.1.101
192.168.1.255
192.168.99.0
11000000.10101000.00000001.00000000
11000000.10101000.00000001.01100101
11000000.10101000.00000001.11111111
11000000.10101000.01100011.00000000
11000000 10101000 01100011 00000000

11000000 10101000 01100011 00010001
11000000 10101000 01100011 00010001
11000000 10101000 01100011 00000000
17
17
17
32
Az elz algoritmus alapjn most a 8-as sor nyert, azaz a 192.168.99.17 cm

esetben a 192.168.1.101 hlzati krtynkon kell kimennnk, s a 192.168.1.2
cmen lesz az a gateway, amelyik kienged minket a megfelel irnyba.
~ 125 ~

3. (195.247.14.56):
11000011 11110111 00001110 00111000 AND...
Most mr nem kell olyan sok duma.
4.10. TBLZAT
Ssz
1
2
3
4
5
6
7
8
9
10
11
12
NetMask
0.0.0.0
NetMask binrisan
00000000.00000000.00000000.00000000
Eredmny
00000000.00000000.00000000.00000000
255.255.255.0
255.255.255.255
255.255.255.255
255.255.255.0
11111111.11111111.11111111.00000000
11111111.11111111.11111111.11111111
11111111.11111111.11111111.11111111
11111111.11111111.11111111.00000000
11000011 11110111 00001110 00000000

11000011 11110111 00001110 00111000
11000011 11110111 00001110 00111000
11000011 11110111 00001110 00000000
4.11. TBLZAT
Ssz
1
2
3
4
5
6
7
8
9
10
11
12
Network Destination
0.0.0.0

00000000.00000000.00000000.00000000
Elz eredmny
00000000.00000000.00000000.00000000
CT
32
192.168.1.0
192.168.1.101
192.168.1.255
192.168.99.0
11000000.10101000.00000001.00000000
11000000.10101000.00000001.01100101
11000000.10101000.00000001.11111111
11000000.10101000.01100011.00000000
11000011 11110111 00001110 00000000

11000011 11110111 00001110 00111000
11000011 11110111 00001110 00111000
11000011 11110111 00001110 00000000
6
6
6
6
Az elz algoritmus alapjn most az 1-es sor nyert, azaz a 195.247.14.56 cm

esetben a 192.168.1.101 hlzati krtynkon kell kimennnk, s a 192.168.1.1
cmen lesz az a gateway, amelyik kienged minket a megfelel irnyba.
Windows IP Configuration
Ethernet adapter Local Area Connection:

Connection-specific DNS
Link-local IPv6 Address
IPv4 Address. . . . . .
Subnet Mask . . . . . .
Default Gateway . . . .
Suffix
. . . .
. . . .
. . . .
. . . .
.
.
.
.
.
:
:
:
:
:
fe80::21e:8cff:feab:372e%8
192.168.1.101
255.255.255.0
192.168.1.1
Ez viszont, mint fent is lthatjuk, pont a Default Gateway. Mely minden eddigi
pldban ott volt holtversenyben az els helyen, csak a NetMask-jban lv kevs
egyes miatt vesztett. Itt viszont nem volt holtverseny.
~ 126 ~

Azaz sszessgben elmondhatjuk, hogy amikor el kell dntennk, hogy egy
csomagot melyik hlzati krtynkon s melyik router fel kldjk ki, akkor
amennyiben van olyan sor az tvlaszt tblban, mely illeszkedik a csomagban lv
target IP address-re (32-es counter), akkor az a sor nyer. Holtverseny esetn a
szorosabb illeszkeds a gyztes.
(Egy 192.168.105.23 cmre val kldsnl illeszkedni fog a 192.168.105.0/24, illetve
a 192.168.0.0/16 sor is az tvlasztsi tblban - de rezzk, hogy az els a
szorosabb. A legszorosabb pedig a 192.168.105.23/32 lenne.)
Ha egyik sor sem illeszkedik, akkor a Default gateway lesz a nyer: hiszen a 0.0.0.0/0
mindenre passzol.
Illetve van mg egy tnyez, amelyrl eddig nem beszltnk: ez a Metric paramter.
Ez egy kltsg rtk - s a sorokhoz rendeljk. Azonos illeszkeds esetn az
alacsonyabb kltsg sor nyer.
Trjnk vissza mg egy gondolat erejig a fenti pldkhoz. Lthattad, ez nem egy
tlagos szmtgp route tblja volt - hiszen akkor lenne egy default gateway s
ksz. Itt viszont kzltk a szmtgppel, hogy a 192.168.99.0/24 hlzat nem a
Default gateway mgtt van, hanem arra egy msik kijrat - a 192.168.1.2 - vezet.
Ezt a kvetkez paranccsal tudtuk elrni:
route add -p 192.168.99.0 mask 255.255.255.0 192.168.1.2
s mivel hasznltam a -p kapcsolt, gy ez egy persistent, azaz lland bejegyzs lett
a tblban. jraindts sorn sem veszik el. Nem mellkesen, a route print parancs
esetn a persistent route bejegyzsek kln sorban is ltszanak.
Ok. Megismertk a route tblt. Tudjuk, mi alapjn dnt egy host. De hogyan dnti
el egy router, hogy melyik hlzati adaptern kldjn ki egy csomagot, ha a
cllloms neadjisten sok routerrel arrbb tallhat?
Ht, pldul megszerkeszthetnk egy univerzlis, bazi nagy route tblt, melybe
belevesszk az sszes alhlzatunkat, majd ezt - megfelelen az egyes routerekre
szabva - feltltgetnnk az tvlasztinkra. Tnylegesen is ltezik ilyen, gy hvjk,
hogy statikus tvlaszts.
De nem ez a hossz let titka.
~ 127 ~

Manapsg mr sokkal elterjedtebb a dinamikus tvlaszts. Ekkor a routerek,
klnbz algoritmusokat s protokollokat hasznlva lefocizzk egyms kztt azt,
hogy a route tblik mindig naprakszek legyenek.
Kt ilyen tvlasztsi algoritmust emltenk meg:
RIP
OSPF
Routing:
http://en.wikipedia.org/wiki/Routing
Implementing IP routing:
http://technet.microsoft.com/en-us/library/cc750576.aspx
IP Routing:
http://technet.microsoft.com/en-us/library/bb727001.aspx
~ 128 ~
4. 1 .2 . 3 RIP
Nyilvn amikor elneveztk, jt vigyorogtak a Rest In Peace (Nyugodjk bkben)

thallson - de valjban a betsz azt jelenti, hogy Routing Information Protocol.
Maga a protokoll az n. distance-vector routing protokollok csaldjba tartozik. Ez
nagyjbl azt takarja, hogy az ugrsszmokat (hop count) hasznlja routolsi
kltsgknt. Ezeket az rtkeket trolja egy routolsi tblban, mely tblkat
bizonyos idszakonknt mindegyik router sztkrtli a nagyvilgba. A tbbi router
veszi az adst - na meg persze adja is a sajtjt - gy rve el egyfajta konvergencit.
Nagy htrnya az algoritmusnak az, hogy nagyon hamar elri a vgtelent: 15 hop
felett mr kezelhetetlen forgalmat produklna a hlzaton - gy hivatalosan is ez a
fels korltja. Emiatt nagy hlzatokban nem hasznlhat, mivel a 16 hop-ra lv
routerek mr nem ltnk egymst.
A RIPv1 mg csak a classful vilgban tudott dolgozni (nem hasznlt alhlzati
maszkot, hiszen ekkor az IP cm egyben meg is hatrozta az IP osztlyt), a RIPv2 mr
ismeri a CIDR-et. A RIPng (new generation) pedig mr tmogatja az IPv6-ot.
Adattovbbtsra UDP protokollt hasznl - azaz egy tipikus alkalmazs szint
protokollrl van sz.
Routing Information Protocol:
http://en.wikipedia.org/wiki/Routing_Information_Protocol
Distance Vector Routing Protocol:
http://en.wikipedia.org/wiki/Distance-vector_routing_protocols
~ 129 ~
4. 1 .2 . 4 OS PF
Az akronim az Open Shortest Path First kifejezst takarja. A protokoll a link-state

routing protokollok npes csaldjba tartozik. (Itt lakik mg az IS-IS s a BGP is.)
Akik otthonosan mozognak az Exchange 2000/2003 routolsban, most
felshajthatnak: ismers dolgok jnnek.
A rendszerben a routerek kztt kapcsolatok - linkek - vannak. Mindegyik link egyegy slyozott vektor. Ebben a topolgiban az OSPF nagyon hamar kpes megtallni
az optimlis tvonalat. A linkek egy adatbzisban - Link-State Database, LSDB laknak, ez az adatbzis terjed a routerek kztt, mint a ntha.
Logikusan kvetkeznek az elnyei:
Csak ha vltozs trtnik egy linkben, akkor kezdenek el kommuniklni
egymssal a routerek. (Eltekintve a bels fecsegsktl.)
Elg ha a routerek a szomszdaikkal cserlik ki az LSDB vltozsokat - elbbutbb a vltozsok mindenhov eljutnak.
A fentiekbl jn, hogy jval nagyobb hlzatok is kezelhetk vele, mint a RIP
protokollal, s nem mellkes az sem, hogy brmelyik konnektor kiesse viszonylag
hamar detektlhat.
Az OSPF a hlzati eszkz rtegben dolgozik. Nyilvn ennek is van v2, v3 verzija,
st, az MOSPF a multicastot is tmogatja.
OSPF:
http://en.wikipedia.org/wiki/Open_Shortest_Path_First
~ 130 ~

Rendben.
Vlaszoltunk mindkt krdsre. Tudjuk, mi alapjn dnt egy router, s tudjuk azt is,
hogyan rteslnek az alhlzatok topolgijrl a routerek. Radsul tudjuk azt is,
mi minden vltozik egy csomagban, ha az tmegy egy routeren. (Ugye emlksznk: a
MAC address.)
Feltve, hogy a router routol s nem natol.
De mirt is csinlna ilyet?
Ht, pldul azrt, mert rohamosan fogynak a kiadhat IP cmek az IPv4 vilgban.
4. 1 .2 . 5 N AT
Lassan tnyleg nem szom meg, hogy ne ruljam el, mi is a NAT. Kikdolva annyit
tesz, hogy Network Address Translation, magyarul taln hlzati cmek fordtsnak
lehetne nevezni.
Az a trkkje, hogy a kt hlzat kzs hatrn lebzsel router meg tudja
szemlyesteni az 'A' hlzatban tallhat brmelyik hostot a 'B' hlzatban, gy,
hogy a sajt 'B' hlzatbli IP cmrl nyomul.
Szerintem brn sokkal rthetbb lesz.
4.17. BRA NAT MKDS KZBEN
Ja, eddig nem beszltnk a 'port' fogalmrl. Ez magyarul 'kapu'-t jelent... de mg a

legelvakultabb nyelvvd informatikusok sem szoktk lefordtani.
Gondoljuk csak el: egy host mkds kzben rengeteget kommunikl a hlzaton.
Nem ritka, hogy ppen jn le a bngszbe egy oldal, a levelezkliens pont rnz a
szerverre, hogy van-e j levl, a torrent kliens pedig a Szerzi Jogi trvnyeket tlti
le ugyanekkor. Ha mindez egy idben megy, akkor nagy gondban lennnk,
~ 131 ~

amennyiben mi lennnk a hlzati krtya: vajon melyik csomag melyik
alkalmazshoz tartozik?
Erre talltk ki a port szmot.
Azaz igazbl amikor egy alkalmazs (bngsz) kommuniklni akar egy msikkal
(weboldal), akkor mind a felad, mind a cmzett teljes cme gy nz ki: ip_cm:port
Plda42:
Felad
Cmzett
: 192.168.11.124
: 217.20.130.97
:2874
:80
Ez egsz konkrtan azt jelenti, hogy a 192.168.11.124 IP cm gp - valsznleg egy

bngszbl - az index.hu nyitlapjt krte le.
Eredetileg szabad volt a vsr portok tern, aztn kialakultak rgztett - de csak
ajnlott! - port szmok. A 80-as pldul tipikusan a http szolgltats - de nem
ktelezen. A 25-s az smtp szolgltats... s gy tovbb. Aztn vannak znk is, az
1024-65535 tipikusan a kliens portok, azaz a kliens programok felad cmei.
Egyben a 65535 a legmagasabb szbajhet rtk is. Fejszmolk ebbl kapsbl ki
is szmolhattk, hogy a port szm rszre 2 bjt ll rendelkezsre.
Most, hogy mr tudjuk, mi az a port, nzzk t alaposan az brt: 4.17. bra NAT
mkds kzben.
A 10.0.0.2 forrs IP cmrl (port: 3123, tipikus kliens port) egy webszerverhez
szeretnnk kapcsoldni: 143.23.0.4:80. Csakhogy kzben van egy natol router,
mely eltrolja a felad adatait egy port mapping tblzatban, majd kicserli a felad
adatait a csomagban: berja a sajt kls lbnak IP cmt s egy msik kliens portot.
Mindezt szintn rgzti a port mapping tblzatban, st, ide kerlnek a cmzett
adatai is. A mdostott feladtl elmegy a krs a cmzetthez, az vissza is vlaszol
neki. Itt kap szerepet a port mapping tblzat, a router abbl keresi ki, hogy ki is volt
az eredeti felad, fellrja a csomagban a cmzett cmt s tovbbtja fel a csomagot.
Kicsit pontostsunk.
Amikor a cmfordts gy trtnik, hogy csak az IP cmet cserli ki a router, akkor
beszlnk NAT-rl. Br kicsi az eslye, de elfordulhat, hogy kt node fordul
ugyanazon webszerverhez, ms IP cmrl, de ugyanazt a kliensportot hasznlva ilyenkor a router azrt zavarba hozhat.
Emiatt inkbb elterjedtebb az a cmfordts, amikor a router nemcsak a felad IP
cmt, hanem a portszmt is kicserli. Ekkor beszlnk PAT-rl.
42
Ezt gy egybknt hvjk socket-nek is.
~ 132 ~
Illetve megklnbztetnk olyan verzit, amikor a router csak a source

adatokat piszklja (SNAT) s van olyan, amikor a router a cl adatokat
babrlja (DNAT). De a szmtstechnikai kznyelv ezt az egsz bagzst (NAT,
PAT, SNAT, DNAT) nevezi egsz egyszeren csak NAT-nak.
Aki szeretne jobban is elmlylni a klnbz cmfordtsokba:
http://en.wikipedia.org/wiki/Network_address_translation
Szp, szp. De nyilvn az akci szmolsignyes mvelet. Mirt van neknk erre
szksgnk? Mirt nem j a jval egyszerbb route mvelet?
Mint rtam korbban, durvn kezdtek elfogyni a kiadhat IPv4 cmek. A CIDR sokat
segtett ugyan, de nem eleget.
Erre talltk ki a privt IP tartomnyokat.
4.12. TBLZAT
Cmtartomny
A
B
C
Als hatr
10.0.0.0
172.16.0.0
192.168.0.0
Fels hatr
10.255.255.255
172.31.255.255
192.168.255.255
Vgs cm
169.254.255.255
Cmek szma
65536
Illetve ksbb bvlt a klub.

RFC 3927
4.13. TBLZAT
Kezd cm
169.254.0.0
Ez utbbi az IPv4 link-local tartomny. (Lenykori neve APIPA, Automatic Private

Internet Protocol Addressing.)
A fenti IP tartomnyokat csak bels hlzatokon illik hasznlni. Tisztessges edge
routerek - azaz az internet hatrait rz routerek az ISP-knl - ezeket a
tartomnyokat nem routoljk ki. St, a tisztessges cges edge routerek mr el sem
engedik az internetes edge routerekig. Semmi keresnivaljuk a publikus neten.
Mi kvetkezik ebbl? Pldul az, hogy n, mint Nagy Cg, vehetek a szolgltatmtl
1, azaz egy IP cmnyi hozzfrst a nethez. Ide leteszek egy bszme ers routert,
mg pedig simn betehetek tbb milli gpet, hiszen natol routerekbl akr
vgtelen mret hlzatot is ki tudok pteni. A bels IP cme egyiknek sem fog
megjelenni a neten.
~ 133 ~

Aztn lehet mindegyikrl tolni lg nyelvvel az iwiwet.
Amit mg rdemes megjegyezni, hogy a NAT-nak ersen megvannak a korltai. Nem
egy olyan protokoll ltezik, ahol nem csak az IP datagram fejlce tartalmazza az IP
cmeket, hanem maga az alkalmazs is belerakja egyes adatcsomagjaiba ezeket.(Pl.
FTP protokoll, PORT v. PASV parancsok.) Ilyenkor a natol eszkz vagy fel van
ksztve arra, hogy itt is cserlni kell az IP cmeket, vagy elhasal az alkalmazs.
4. 1 .2 . 6 P R O X Y
Habr ez mr nagyon alkalmazs rtegbeli technika, a tisztnlts kedvrt ejtenk

rla pr szt itt is.
A proxy azt jelenti, hogy helyettest. Informatikban azt rtjk alatta, hogy jn 'A'
gp, szeretne elrni valamit 'B' gpen - de ezt kzvetlenl nem tudja megtenni. Meg
kell r krnie 'C' gpet. a proxy.
Mint amikor elmegyek egy jgazdaghoz, az inassal bekldm a nvjegyemet, aki
cserbe kihoz nekem egymilli eurt. Itt az inas volt a proxy, n nem is tallkoztam a
gazdag emberrel. Ez j lehet neki, mert mi van, ha nlam revolver van s tbb pnzt
akarok - illetve j lehet nekem, mert lehet, hogy az illet ebols s mr a pillantsa is
fertz. Az inas pedig biztosan fegyvertelen s oltva is van.
Nem ismers? Nem ugyanezt csinlta a NAT?
Nos, nem. Nem vletlenl tettem ide ezt a fejezetet.
Kezdjk azzal, hogy a kt technolgia ms szinten mkdik. A proxy az alkalmazs
rtegben, a NAT az internet rtegben. De risi klnbsg van a mgrakott
intelligenciban is. A proxy konkrt alkalmazs-rtegbeli protokollra van belltva.
(Kln proxy-t kell rni a http-re, kln proxy-t az smtp-re, s gy tovbb.) A proxy
pontosan ismeri a protokollkszlet utastsait. Ha nvjegy helyett nyelesfst adok
az inasnak, akkor elveszi, majd odabent bedobja a kukba. Ha nvjegy helyett
revolvert adok neki, akkor kihvja a rendrsget. A millit csak a konkrt nvjegyre
hozza ki vlaszul. Ha idkzben bvl a protokoll utastskszlete, akkor
termszetesen a proxy-t is utna kell okostani - nehogymr a pendrive-ot is kidobja
a kukba, ha egybknt a rajta lv informci egyenrtk a nvjeggyel.
Mit csinl ekzben a NAT? sz nlkl forgatja a cmeket. Eszbe sem jut, hogy
rtelmezze, a megclzott port vajon melyik protokollhoz tartozik.
Fel se nz az asztaltl, csak veri a billentyket.
~ 134 ~

4.1.3 ICMP,
A ZA Z A
PING
S A H AV ERO K
RFC 792, 950, 1812, 1122, 1191, 1256

Ksbb fogjuk ltni, hogy a szlltsi protokollok egsz jl meg lettek szervezve: az
egyik gyors, de nincs benne semmi hibavizsglat, a msik pedig lass, kicsit
fecsegbb - cserbe beptett hibaellenrzst s javtst is tartalmaz. Mink a
vlaszts, melyiket hasznljuk.
Az IP nem ilyen. Az IP headerben nincs semmilyen hibajelzsi lehetsg.
Akkor mi van? ICMP - azaz az Internet Control Message Protocol.
Hol is helyezkedik el a csomagok hierarchijban az ICMP? Vajon az IP alatt...
mellette... vagy fltte? Segtek: 4.2. bra Egy IP csomag felptse.
Az IP datagramm ll IP header-bl s IP payload-bl. (Eddig az IP header-t
boncolgattuk.)
Az IP payload lehet:
TCP szegmens vagy UDP csomag,
Egyb IP protokoll datagram (GRE, AH, ESP, stb...)
ICMP csomag,
IGMP csomag.
Az ICMP csomag pedig - micsoda meglepets - llni fog egy ICMP header-bl s egy
ICMP payload-bl. Tiszta Matrjoska baba.
4.18. BRA A Z ICMP ELHELYEZKEDSE A DOB OZOKBAN
Az ICMP csomagok fognak neknk visszajelzseket adni mind a routolsi hibkrl,

rdekessgekrl, mind a csomagszlltsi hibkrl. Olyan az ICMP, mint a Ngy
pnclos s a kutya cm filmben a kutya: normlis esetben a ngylb csak utazott
~ 135 ~

a tankban, de ha Guszlikk bajba kerltek, akkor a kutyt kldtk el egy zenettel
segtsgrt.
Persze ezt nem gy kell elkpzelni, hogy amikor visszament egy ICMP zenet a
feladnak, akkor az megismtelt volna egy elveszett csomagot. Az a TCP. Jelen
esetben az ICMP hibazenetre vagy a router/host rtkel t bizonyos helyzeteket,
vagy a host beletolja a rendszergazda kpbe az zenetet, mondvn, hogy 'csinlj
babm valamit, mert baj van'.
Merljnk el a konkrtumokban.
4.19. BRA E GY LTALNOS ICMP CSOMAG
Az brn lthatjuk, hogyan nz ki egy teljesen ltalnos ICMP csomag.

TYPE: Az zenet tpusa. A ksbbiekben a kvetkezkkel fogunk megismerkedni:
4.14. TBLZAT
ICMP Type
0
3
4
5
8
9
10
11
12
17
18
Ennl van tbb is:
http://www.iana.org/assignments/icmp-parameters
~ 136 ~
Kzismert neve
Echo reply
Destination unreachable
Source Quench
Redirect
Echo Request
Router Advertisement
Router Solicitation
Time Exceeded
Parameter Problem
Address Mask Request
Address Mask Reply

CODE: A tpuson bell az altpus.
CHECKSUM: CRC.
Eddig volt az ICMP header.
TYPE SPECIFIC DATA: Tpustl fgg adatok. Tulajdonkppen ez a payload.
4. 1 .3 . 1 IC M P E C H O R E Q U E S T & R E P L Y
Ez az a parancs, melyet mg gyerekeim nagymamja is ismer. A vilg legegyszerbb

tesztje: ping index.hu -> s mr tudjuk is, hogy vajon mkdik-e a netnk. Vagy
ledosoltk-e ppen az indexet.
Mint a tesztek legtbbje, ez is kt rszbl ll:
Elszr belergunk a szrkupacba. (ICMP Echo Request)
Ha visszamorog, akkor mg l a kutya. (ICMP Echo Reply)
4.20. BRA A Z ICMP ECHO CSOMAGOK SZERKEZETE
Mind a kt ICMP ECHO csomag hasonlan strukturlja a TYPE SPECIFIC DATA mez
szerkezett.
TYPE: A pontos rtkeket a 4.14. tblzat tartalmazza.
CODE: Nagy bds nulla.
CHECKSUM: CRC.
~ 137 ~

IDENTIFIER, SEQUENCE NR: Ezek az azonostk jellik az sszetartoz REQUEST-REPLY
csomagokat.
OPTIONAL DATA: Valami ballaszt. Az letszer teszthez kell adat is, amit t kell vinni.
Nzzk, mit mond a sztetoszkpunk.
4.21. BRA ICMP ECHO REQUEST
A kpernykivgson jl lthat, amit az brn (4.18. bra Az ICMP elhelyezkedse a

dobozokban) is prbltam rzkeltetni: az ICMP csomag az IP csomag payload-jban
van - azaz megelzi az egszet egy IP header.
Az ICMP csomagban a TYPE=8 jelzi a REQUEST-et, az azonost szm rtke 1 ugyanennyinek kell lennie a REPLY csomagban is. Vgl a ballaszt, a DATA... na, mi is
ez? Legalul ltszik, hogy a mez az angol ABC betivel sorfolytonosan tltdik fel,
mghozz gy, hogy ha elfogynak a betk, akkor kezddik az ABC ellrl.
Mekkora lehet a DATA mrete? Az alaprtelmezett rtk 32 bjt, a maximlis rtk
pedig 65500. (Mint korbban is rtam, az IP csomag maximlis mrete 65536 bjt43.)
Ping of Death:
http://en.wikipedia.org/wiki/Ping_of_death
A korai opercis rendszerek nagy rszt remekl meg lehetett fektetni egy 65500 bjtnl nagyobb
ping kikldsvel. Ez volt a ping of death. A felesleg ugyanis tlcsordult, bele a verembe. Aztn bof.
De ezeket a lyukakat mr a mlt vezredben befoltoztk.
43
~ 138 ~

Vgl gy nz ki a fogadjisten.
4.22. BRA ICMP ECHO REPLY
Ehhez az brhoz nincs sok hozzfznivalm. Elgedett shajtssal vehetjk

tudomsul, hogy az IDENTIFIER s a SEQUENCE NUMBER mezk rtke megegyezik
a korbbi REQUEST-ben lv rtkekkel, a TYPE jelenleg 0, a CODE masszvan tartja
a zrt, a DATA pedig tovbbra is az angol ABC-bl kpzdik.
Gyernk tovbb, lesz ez mg sokkal rdekesebb is.
~ 139 ~
4. 1 .3 . 2 IC M P D E S T I N A T I O N U N R E A C H A B L E
Az elbb lttuk, mi trtnik egy sikeres ping esetn. Most megnzzk, mi trtnik
sikertelen prblkozsok esetn.
Nyilvn visszamegy egy zenet a sikertelensgrl.
Hogyan is? Hiszen nem rtk el a cmzettet. Akkor ki kldi vissza az zenetet?
Termszetesen az utols mg elrt hlzati elem. Illetve, a legutols elem, aki
informcival br. (Elkpzelhet ugyanis, hogy a megclzott host elrhet ugyan, de
pldul a megadott portja nincs nyitva.)
Az zenet pedig egy ICMP csomag, mghozz a 3-as tipus, az ICMP Destination
Unreachable.
4.23. BRA ICMP D ESTINATION U NREACHABLE
TYPE: Jelen esetben az rtke: 3.

CODE: Van nhny rtke. Lsd 4.15. tblzat.
CHECKSUM: CRC.
UNUSED: Sorminta.
IP HEADER + FIRST 8 BYTE: Hogy valami legyen is abban a csomagban. Persze itt mr
van informcidsabb ballaszt is, mint az angol ABC. De ezt egy konkrt pldn
hamarosan lthatjuk.
~ 140 ~
4.15. TBLZAT
Code Elnevezs
0
Network Unreachable
1
Host Unreachable
Protocol Unreachable
Port Unreachable
Fragmentation Needed and

DF Set
Source Route Failed
5
6
Destination
Unknown
Destination Host Unknown
Source Host Isolated
Communication
with
Destination
Network
Administratively Prohibited
10
Communication
with
Destination
Host
Network Unreachable for
the Type Of Service
11
Network
12
Host Unreachable for Type

Of Service
13
Communication
14
Host Precedence Violation
15
Precedence Cutoff in Effect
Megjegyzs
A visszafelesel router route tbljban nincs a csomag cmzettjnek IP
cmre vonatkoz bejegyzs.
A visszafelesel router route tbljban nincs a csomag cmzettjnek
hlzatra vonatkoz bejegyzs.
A cmzett host kldi vissza, ha a csomagban szerepl protokollazonostt
nem tudja rtelmezni.
A cmzett host kldi vissza, ha a csomagban szerepl porton nem figyel
semmilyen szolgltats. Apr trkk, hogy ez az zenet csak UDP szlltsi
protokoll mellett generldik, TCP esetn - a ksbb trgyaland Reset,
azaz RST - elnyomja.
A router kldi vissza, ha az MTU eltrsek miatt trdelnie kellene a
csomagot, de a DF (Don't Fragment) flag nem engedi.
Ha az IP Options rovatban elrtuk a ktelezen kvetend tvonalat a
routerek kztt, de az nem teljesthet.
Ha a megclzott host hlzatra vonatkozan van ugyan bejegyzs a
router route tbljban, de az valtlan. A gyakorlatban nem hasznljk, a
0 kd megy vissza helyette.
Elmletileg ez az zenet akkor keletkezik, ha a megcmzett host a
Network Interface Layer cmfeldert mechanizmusai szerint nem
ltezik. Gyakorlatilag csak akkor hasznljk, ha a router-hez PPP
kapcsolaton keresztl kapcsold host/router rhetetlen el.
Ha a felad host el van szigetelve hlzatnak tbbi rsztl. Egyltaln
nem hasznljk.
Ha gy egybknt ltezik route bejegyzs a megclzott munkalloms
hlzatval kapcsolatban, csak network policy tiltja a csomag
tovbbtst. A htkznapokban nem hasznljk, egyedl katonai clokra
engedlyezett.
Ha network policy tiltja a csomag tovbbtst a megclzott host
szmra. A htkznapokban nem hasznljk, egyedl katonai clokra
engedlyezett.
Amennyiben a router gy van belltva, hogy hasznlja a TOS mezt
(emlksznk, 4.1.1 fejezet, leginkbb svszlessg-szablyozs.), de a
csomagban nem tall ehhez szksges inft s emiatt nem ri el a cmzett
hlzatot.
Amennyiben a router gy van belltva, hogy hasznlja a TOS mezt, de a
csomagban nem tall ehhez szksges inft s emiatt nem ri el a cmzett
hostot.
A routeren packet filter tiltja a csomag tovbbtst. Elmletileg
hasznljk, a gyakorlatban inkbb nem - tl direkt vlasz lenne a
rosszindulat portszkennelsekre.
Amennyiben a TOS mezben megadott Precedence rtk nem
engedlyezett.
Amennyiben a TOS mezben megadott Precedence rtk alacsonyabb a
minimlisan megengedettnl.
Destination Unreachable Messages:

http://www.tcpipguide.com/free/t_ICMPv4DestinationUnreachableMessages-3.htm
http://www.networkcomputing.com/netdesign/1107icmp3.html?ls=NCJS_1107bt
Nzznk meg konkrtan is egy zenetet.
~ 141 ~
4.24. BRA ICMP DESTINATION UNREACHABLE - PORT UNREACHABLE
Itt a kvetkez trtnt: a 192.168.1.108 host meg szerette volna tudni a

10.227.160.1 host netbios nevt egy netbt -A 10.227.160.1 parancs kiadsval. Erre
vlaszolta azt a megclzott host, hogy bocs haver, de nekem a 137-es UDP portomon
nem figyel semmilyen szolgltats sem. (Valsznleg 'X'-re vgzdik a host
opercis rendszernek a neve.)
Lthat, hogy az ICMP payload gyakorlatilag mindent elmond. Ott van benne a
_krs_ teljes IP header-e, illetve az IP payload-jnak els nyolc bjtja. A transport
rtegnl majd ltni fogjuk, melyek is ezek a bjtok - de remlem, most sem kell a
szomszdba menni logikrt. Elhangzott mr a knyvben, hogy egy port rtke 065535 kztti rtk lehet, ez egsz pontosan kt bjton brzolhat. A length s a
checksum szintn 2-2 bjtos mezk - s mr meg is vagyunk. Ezek kerlnek bele - az
IP header mellett - az ICMP payload-ba. (A capture fjlban az eredeti krs(37)
kzvetlenl az ICMP csomag(38) eltt lthat, teht itt most nem sokat segtett az
ICMP payload. De nincs ez mindig gy.)
~ 142 ~

Vgl, oldva a tl szraz lerst, elmeslem, hogyan sikerlt rgztenem ezt a capture
fjlt.
Elljrban megjegyeznm, hogy az ICMP Destination Unreachable zenet egy
tlagos hlzatban ritka, mint a fehr holl. Legtbbszr ugyanis a hlzati hibk
vagy timeout, vagy RST formjban jelentkeznek.
Nos, elgondolkodtam. A Destination Host Unreachable zenet ismers volt,
gondoltam, nem lesz nehz reproduklnom. Nosza, pingeljnk meg egy nem ltez
hostot!
4.25. BRA R EQUEST T IMED O UT
Nem tl biztat. Mi is trtnik kzben?
4.26. BRA R EQUEST T IMED O UT - A HTTRBEN
~ 143 ~

Semmi. Kiadunk egy ICMP Request krst, vrakozunk, majd tudomsul vesszk,
hogy mg vlaszra sem mltatnak. De azrt beprblkozunk mg hromszor.
Pedig istenbizony, szoktam ltni munka kzben ilyen zeneteket. Mikor is volt
utoljra ilyen...? Megvan: amikor elrtam egy szerveren a default gateway rtkt!
Nosza, t is rtam a gpemen lvt 192.168.1.75-re.
4.27. BRA D ESTINATION H OST U NREACHABLE
s igen, itt van. Ezt kerestk. Capture fjl:
4.28. BRA D ESTINATION H OST U NREACHABLE - A HTTRBEN
Vagy mgsem? Egy nyomorult ICMP zenet sincs benne, a szmtgpem vad ARP
broadcast viharokkal prblja megtudni a kamu default gateway MAC Address-t majd egy id utn elunja.
Ez sem az igazi.
~ 144 ~

Nyilvn, ha ltez IP cmet rok DGW-nek, mely persze nem egy router cme, akkor
megint Request Timed Out jn vissza.
Ok. Jtsszunk el a router packet filtervel. Gondoltam, vagy a 2-es, 3-as... vagy a 13as kd (4.15. tblzat) csak meglesz.
Itt mr nem frasztalak kpekkel, nem lett meg. Gyakorlatilag minden kisrletre
RST-t kaptam vissza. Megprbltam flrevezetni a csomagot a Strict Source Routing
segtsgvel (4.1.1.2 IP Options) de a routerem nem tmogatta ezt az opcit.
Vgl teljesen vratlanul mosolygott rm a szerencse. Megtrszeltem az index.hu-t.
4.29. BRA T RACERT INDEX . HU
Rnzsre semmi klns, a folyamat sikeresen lezajlott. Azrt rnztem a capture

fjlra... s ebben talltam meg a korbbi brn (4.24. bra ICMP DESTINATION
UNREACHABLE - PORT UNREACHABLE) bemutatott ICMP zenetet.
Szemldkm nyilvn egybl a plafonig szktt: ez most akkor hogyan? Mi is ment
itt flre? Amikor minden j?
Ehhez ismerni kell egy kicsit a tracert lelkivilgt.
E mgtt a parancs mgtt tulajdonkppen ping parancsok bjnak meg. Mint
korbban is rtam, a tracert egyltaln nem a Record Route nev IP opcit hasznlja
egy tvonal llomsainak rgztsre. Pingel. Csak ppen mindig eggyel nagyobb
TTL rtkkel - azaz minden ping a kvetkez hop cmvel jn vissza.
~ 145 ~

De a tracert nem elgszik meg ennyivel. Minden egyes hop esetn igyekszik
begyjteni az IP cm mell a host nevt is. (Lsd. 4.29. bra Tracert index.hu.) Kedves
tle. Nv viszont ktfajta van: egyrszt tallhatk nevek DNS znkban, msrszt
van magnak a hostnak is neve, melyet Windows-t futtat gpen rvid, azaz Netbios
nvnek hvunk. A tracert beprblkozik mindkt nvfeloldssal... s erre a
prblkozsra kapta azt a vlaszt a 10.227.160.1 hosttl, hogy azon bizony nem fut
Netbios Name Service szolgltats, azaz az UDP 137-es portja mgtt nem dolgozik
senki. Gyors ellenteszt: kiadtam a netbt -A 10.227.160.1 parancsot - s ugyangy
megjttek a vrt ICMP zenetek a capture fjlban.
Vedd szre a szituci szpsgt. Nem tudtam elrni egy portot, erre kaptam vissza
az ICMP hibazenetet. De ppen nemrg rtam, hogy eljtszottam a router packet
filtervel - s mgsem jttek a vrt zenetek. Akkor most mi van?
A kulcs a szlltsi protokollnl van. Amikor packet filterrel jtszottam, akkor a
telnet 192.168.1.1 port_number parancsokkal prblkoztam - a telnet viszont TCP.
Mit is r a 4.15. tblzat a 3-as kdnl? TCP esetben az RST elnyomja az ICMP-t.
Mivel is prblkozik a Netbios nvfelolds? gy van, UDP-vel.
Tanulsg:
Az ICMP Destination Unreachable zenetek nem is annyira gyakoriak, mint ahogy
azt az ember els rnzsre gondoln.
~ 146 ~
4.1 .3 .2 .1 PM TU
Ebben az alfejezetben rdemes pr szt ejtennk a kicsit misztikus PMTU-rl is. A

betsz konkrtan a Path MTU, azaz Path Maximum Transmission Unit kifejezs
kezdbetibl ll ssze. Az MTU-rl esett mr sz a knyvben, hasonlkppen a
fontossgrl is. Tudjuk, hogy az MTU az adott hlzatban tvitt csomagokban a
maximlis hasznos teher (payload) mrett jelenti, NIL szinten. rtknek ismerete
azrt fontos, mert ha nagyobb payload-dal rendelkez csomag rkezik, akkor azt
bizony trdelni kell - s mi mr azt is tudjuk, hogy a trdels nagyon egszsgtelen
mvelet: zablja az erforrsokat, bonyoltja az letet s molesztlja a
nyugdjasokat.
rtelemszeren az igazi az lenne, ha a forrsknt viselked hostunk mr a csomag
sszeraksakor tudn, hogy a clpontig vezet tvonalon mennyi az egyes
alhlzatok MTU rtke. Ekkor ugyanis maga is a legkisebb MTU-ra mretezn a
csomagot, gy nem kellene egyszer sem trdelni azt az t sorn.
RFC 1191
Ezt a konkrt tvonalra vonatkoz MTU rtket nevezzk PMTU-nak.
Meghatrozshoz pedig az ICMP Destination Unreachable zenetet hasznljuk,
egsz konkrtan a 4-es kddal brt. Persze ehhez egy kicsit t kell alaktanunk a
csomag szerkezett. (A PMTU detektlssal a 1191-es RFC foglalkozik, az ezt ismer
eszkzk az n. RFC 1191 compliant eszkzk.)
Ne gondolj tl nagy talaktsra. A korbbi brn (4.23. bra ICMP Destination
Unreachable) lthat egy ngy bjtos sorminta. A mdostott csomagban ebbl
elvesznk kt bjtot s ide troljuk le a NEXT HOP MTU rtkt - azaz azt, hogy a
kvetkez alhlzatban mekkora lesz az MTU rtk.
Nem tl bonyolult, ugye? Mr csak arrl kell gondoskodnunk, hogy egsz biztosan
jjjn is ICMP visszajelzs. (Ne feledjk, az ICMP Destination Unreachable zenet
alapveten azrt hibazenet.) Ezt gy rhetjk el, hogy belltjuk a kezdeti MTU
rtkt a loklis hlzatunkon hasznlt rtkre, a DF flag-et magasra billentjk - s
elkldjk a csomagot. (Ezt hvjuk PMTU detektlsi kezdemnyezsnek.) Ha a
csomag gy is vgigment visszajelzs nlkl, akkor nagyon j: az alhlzatunk MTU
rtke egyben a PMTU is. (Vagy nem... de errl ksbb.) Ha valahol trdelni kellett
volna, de a DF-fel ezt ugye letiltottuk, akkor 4-es kd ICMP Destination
Unreachable zenet jn vissza. Szerencss esetben mr az jabb szerkezettel amelyikben mr ltezik mez a megkvnt MTU rtk szmra. jracsomagolunk,
immr az j MTU rtkkel.
~ 147 ~

gyes.
De mi van akkor, ha - akr csak - egy router is buta az tvonalon s nem ismeri a
1191-es RFC-t?
Kt eset lehetsges:
A router visszakldi a 4-es ICMP Unreachable Destination zenetet, de mg a

rgi fajtt. Ekkor a feladtl fgg a tovbbi stratgia. Besaccolhat egy rtket,
aztn kisrletezgethet vele tovbb, de mehet egybl tutira is, a legkisebb, mg
rtelmes rtkre (576 bjt) lltva az MTU-t.
A router mg ostobbb, mg a rg ICMP zenetet sem kldi vissza. Ezt hvjk
feketelyuk routernek. Ekkor egy kicsit cifrbb az eljrs. A feladnak azrt
egy id utn fel fog tnni, hogy nem rkeznek meg a hibafeldertsi
felhanggal kldtt csomagjai. A TCP csomagoknl pldul kapnia kellene egy
visszaigazolst. Ha ez nem trtnik meg, akkor a felad megprblkozik a DF
nullra lltsval. Amennyiben ez utn mr visszajn a visszaigazols, akkor
rzkeli, hogy MTU problmval s feketelyuk routerrel ll szemben. Innentl
a stratgia mr ugyanaz, mint az elbbi pontban, azzal az apr eltrssel,
hogy a sikertelen MTU prblkozst nem az ICMP zenet fogja jelezni a felad
szmra, hanem a TCP visszajelzs elmaradsa.
A Windows Server 2008 s a Vista routerknt viselkedve RFC 1191 kompatibilisek,

felad hostknt viselkedve pedig helybl PMTU detektlsak. Ezeket az attitdket
registry-bl mdosthatjuk - de minek?
PMTU:
http://en.wikipedia.org/wiki/Path_MTU_discovery
http://www.netheaven.com/pmtu.html
~ 148 ~
4. 1 .3 . 3 IC M P S O U R C E Q U E N C H
Ksznm, elegem van. Bff.

Mondja ezt a router, miutn minden testnylsn keresztl telenyomtk
csomagokkal, pedig nem tudja ebben a tempban feldolgozni s tovbbkldeni
azokat.
Az ICMP Source Quench egy olyan zenet, melyet egy tlterhelt router kld vissza a
csomagok feladinak. Az zenet lnyege: lasstsatok, fik!
Igenm, de van ezzel egy kis baj:
Vannak olyan fik, akik kptelenek lasstani. Az ICMP zenet ugyanis IP
szint - viszont az internet layer-ben nincs forgalomszablyozs. Egyedl a
TCP-ben van, mely viszont mr a transport rteg. Egyedl a konkrt
implementcitl fgg, hogy figyel-e az egyik rteg a msik rteg
problmira.
Az ICMP Source Quench zeneteket el is kell kldeni. Pont annak a routernek,
amely egybknt is erforrs problmkkal kszkdik. Olyan ez, mint amikor
veszettl dolgozol egy projekten, ltod, hogy nem leszel ksz hatridre,
segtsget krsz a fnkdtl - aki jelentst irat veled arrl, mirt haladsz
lassan. Ok, hogy a legtbb implementciban a tlterhelt router nem kld
minden csomagra ICMP Source Quench vlaszt - de ez csak hajszrt a
Niagara ellen.
Eddig csak jindulat hozzllsrl beszltnk. De mi van a rosszfikkal? Ha
n azzal keresnm a kenyrrevalt, hogy weboldalakat dosolok44 le, akkor az
els ICMP Source Quench csomag lttn kjes vigyor nten el az arcomat s
flig r szjjal fokoznm tovbb a tempt - hiszen mr karnyjtsnyira
vagyok a clomtl.
Szval, szp, szp ez a visszajelzs mka... de nem egyrtelmen hasznos. A
WIndows Server 2008 / Vista implementcikbl teljesen ki is maradt: a routerknt
viselked szerver nem kldzget ilyesmit vissza, a kliensknt mkd opercis
rendszerben pedig az IP rteg nem veszi a fradtsgot, hogy zavarja vele a TCP
csatornt.
A csomag felptse egybknt teljesen megegyezik az ICMP Destination
Unreachable csomag felptsvel. (4.23. bra ICMP Destination Unreachable)
44
DOS: Denial of Services. Azaz tlterhelses tmads.
~ 149 ~
4. 1 .3 . 4 IC M P R E D I R E C T
Szemlyes vallomssal kezdem: utlok mindent, ami megprbl okosabb lenni

nlam. Nem azrt, mert ehhez mg csak meg sem kell erltetnie magt - hanem
azrt, mert ha valami nem tudja biztosan, hogy mit akarok, akkor minden varils
nlkl egyszeren csak csinlja azt, amit mondok neki. Ifj informatikusknt
viszolyogtam a PnP-tl, az automatikus hlkrtya konfigurlstl - s a Word
teleptse utn is az az els teendm, hogy a tools/options alatt kikapcsolok
mindent, ami gy kezddik, hogy auto.
Nos, az ICMP Redirect pont ilyen kellemetlen funkcit lt el.
Elmeslek egy sztorit.
Nagy gyfl. Magas rendelkezsre lls. A fhadiszlls s a nagyon fontos telephely
fldrajzilag is tvol vannak egymstl. A kett kztt brelt vonal feszl, nem is egy:
van egy elsdleges s van egy backup vonal. Eltr szolgltatktl, termszetesen.
4.30. BRA A JTSZTR
A fhadiszllson mind a kliensgpek, mind az Exchange szerver route tblja olyan

pre volt, amilyen egy route tbla csak lehetett. Egyedl a Default Gateway cme volt
benne mindegyikben. Ez egy Route Switch Processor (RSP) jelleg masina volt, azaz
ismert minden tvonalat, mondta meg mindenkinek, hov menjen. Ha pldul
~ 150 ~

egy fhadiszllsbli kliens el akart rni egy klienst a telephelyen, akkor elkldte a
csomagjait az RSP-hez, az tlkte azokat az elsdleges routerhez, onnan pedig mr
mentek is tovbb. Ha zemzavar miatt ledlt az les vonal, akkor az RSP a backup
routerhez kldte tovbb a csomagokat. Ment minden szpen... amg ki nem lett
cserlve a vas az RSP alatt. Az jon ugyanis elfelejtettk letiltani az ICMP Redirect
funkcit.
Ekkor indult be a rock'nroll.
Els zemzavar. gyfl reklaml, hogy a naggyon fontos telephelyrl nem rik el az
Exchange szervert. Hlzatos ember tvizsglja a rendszert - minden rendben.
Exchange rendszergazda tvizsglja a szervert - minden rendben. Akkor most mi
van?
Ht az ICMP Redirect betette a lbt a rendszerbe. Ez a szolgltats ugyanis a
hlzati forgalom optimalizlsra hivatott. gy mkdik, hogy ha egy kliens kld
egy csomagot egy routernek s a router rzkeli, hogy a kvetkez hop is mg
ugyanezen az alhlzaton van, akkor kld vissza a kliensnek egy ICMP Redirect
zenetet, mondvn, hogy 'bartom, legkzelebb kldheted direktben is oda a
csomagot, ne terheljl mr, ha van egyszerbb t is'.
A kliens fogja az ICMP Redirect csomagot, kiveszi a vzbl az oxignt belle a msik
router cmt, s bejegyzi a sajt route tbljba, hogy ha legkzelebb ehhez a
szerverhez kell mennie, akkor mr ne a Default Gateway-t zaklassa.
Nzzk most akkor a pldt. A telephelyrl egy kliens rcsatlakozott az elsdleges
vonalon az Exchange szerverre. Kldtt neki egy csomagot, a szerver pedig vlaszolt.
Hogyan? Mivel a Default Gateway cme az RSP volt, elkldte annak a vlaszcsomagot.
Az meg visszaszlt, hogy van m rvidebb t, a Router HQ1-en keresztl. A szerver
boldogan jegyezte be a route tbljba a telephelyi kliens IP cmt az elsdleges
router - mint kvetkez hop - IP cmvel egyetemben.. Innentl a csomagok az RSP
kikerlsvel mentek a Router HQ1 fel. (Ismtls: ugye egy hostra vonatkoz route
bejegyzsnl a subnet mask 255.255.255.255, mg a Default Gateway subnet mask
bejegyzse 0.0.0.0. Habr mindkett 32 pontot fog elrni az illesztsi vizsgn, de a
subnet mask egyeseinek szma miatt a hostra vonatkoz - azaz az ICMP Redirect
indiklta - bejegyzs fog nyerni.)
Ezzel nem is volt addig baj, amg az les vonal mkdtt. De amikor ledlt, az RSP
hiba tudta, hov kellene menni helyette, az Exchange szerver mr le se tojta. A sajt
route tblja alapjn nyomult lg nyelvvel az elrhetetlen Router HQ1 routerre.
Kln szpsge volt az esetnek, hogy a bejegyzsek nem magba a route tblba
trtntek, hanem a route cache-be - azaz a bejegyzsek nem voltak perzisztensek -
~ 151 ~

gy az jraindts mindig megoldotta a hibt. Mi meg csak lltunk ott, a fejnket
vakarva.
A trtnetnek nem az a tanulsga, hogy hny helyen hibztunk. tgondoltabb
tervezssel nyilvn el lehetett volna kerlni ezt a hibt.
Az igazi tanulsg az, hogy tudjl errl a lehetsgrl. Amikor megtervezel egy
bonyolult hlzatot, benne tmrdek routerrel, akr RIP, akr OSPF dinamikus
routolssal... ne felejdkezz el rla, hogy ltezik mg egy mechanizmus, mellyel
foglakoznod kell: vagy le kell tiltanod, vagy be kell ptened az elkpzelseidbe.
Vizsgljuk meg akkor most mr ezt a csomagot.
4.31. BRA ICMP R EDIRECT
TYPE: Jelen esetben 5.

CODE: Tbb rtke is lehet.
4.16. TBLZAT
CODE Jelentse
0
Egy egsz hlzatra vonatkoz tirnyts (Elsorvadt.)
1
Egy hostra vonatkoz tirnyts
2
Egy egsz hlzatra vonatkoz tirnyts, amennyiben TOS-t is hasznlunk.
3
Egy hostra vonatkoz tirnyts, amennyiben TOS-t is hasznlunk.
ROUTER IP ADDRESS: Az a cm, ahov az rintett csomagokat mostantl kldeni kell.

Egy krds maradt mr csak htra: mit szl ehhez a Windows Server 2008 / Vista?
Nos, alaphelyzetben be van kapcsolva ez a viselkedsi md, de kikapcsolhat:
netsh interface ipv4 set global icmpredirects=enabled v. disabled
ICMP Redirect:
http://en.wikipedia.org/wiki/ICMP_Redirect_Message
~ 152 ~
4. 1 .3 . 5 IC M P R O U T E R D I S C O V E R Y
Egy jabb mechanizmus, mely belenylkl az IP routolsba. Ha rviden ssze

szeretnm foglalni, mirl is van sz, azt kellene mondanom, hogy olyan
mechanizmusrl van sz, melynek segtsgvel a hostok megtalljk a szmukra
idelis default gateway-t. s mg csak vletlenl sem ejtettem ki azt a szt a szmon,
hogy DHCP (Dynamic Host Configuration Protocol), vagy ES-IS (End System to
Intermediate System Routing Protocol). (Amilyen hossz kifejezsekrl van sz,
vletlenl nem is lehetne a nevket kiejteni.) De mg csak azt sem mondtam, hogy
routing protokoll. Nem, krem szpen, a trtnet csak DGW keressrl szl.
ES-IS:
http://www.javvin.com/protocolESIS.html
Azt rtam volna, hogy 'mechanizmusrl'? Akkor hibztam. Ugyanis

mechanizmusokrl van sz.
ICMP Router Advertisement:
A router ezerrel reklmozza magt.
ICMP Router Solicitation:
A hostok nyaggatjk a routereket.
Vad egy kicsit, nem? Belltasz egy default gateway rtket, aztn egy fl ra mlva
vagy a router dumlja le a hostrl s llt be egy msikat - vagy a host hvja ki maga
ellen a sorsot, eldobva a belltott default gateway rtket, egy szebb s csinosabb
rtkrt.
s mg csak nem is figyelmeztettek elre, hogy ilyenek trtnhetnek.
Nyilvn nem errl van sz. Lehetsgekrl beszlnk, melyek alaprtelmezsben a
Windows Server 2008 / Vista rendszerekben igencsak takarkra vannak kapcsolva.
De attl mg rdemes megismerkedni velk.
ICMP Router Discovery Protocol:
http://www.networkdictionary.com/protocols/irdp.php
~ 153 ~
4.1 .3 .5 .1 ICM P R O U T E R A D V E R T I S E M E N T
Ezt az zenetet a routerek kldik. Ha senki sem ingerli ket, akkor kvzi
vletlenszer idztssel (7-10 perc), ha bejelentkezik egy host az ICMP Router
Solicitation zenettel, akkor viszont kapsbl. (Meg, ht!)
Hov kldik? Ez is vltoz. Van olyan router, aki az all host multicast IP cmre
(224.0.0.1) s van olyan router, aki a subnet broadcast cmre. (Az RRAS-ba ptett
ICMP Router Discovery az all host multicast IP cmet preferlja.)
Mit kldenek? Ezt.
4.32. BRA ICMP R OUTER A DVERTISEMENT
TYPE: Jelen esetben 9.

CODE: Zr. Nincs aleset.
~ 154 ~

NUMBER OF ADDRESSES: Ez egy kicsit furcsa lehet, hiszen a Default Gateway azrt
Default, hogy minden arra menjen, amire nincs konkrt szably. Hogyan lehet akkor
mgis tbb belle? gy, hogy biztosra akarunk menni. A Default Gateway-k sem
lnek rkk. Simn lehet olyan hlzatunk, amelyben az els hop kt klnbz
router is lehet. Vagy mondjuk ugyanazon router tbb lbbal is ll az alhlzaton.
Szz sznak is egy a vge, ez az rtk az a bizonyos 'n'.
ADDRESS ENTRY SIZE: Hny szbl llnak az egy-egy routerre vonatkoz bejegyzsek.
Mivel mind az IP cm, mind a preferenciaszint 4-4 bjtos rtkek, gy
4*2*8(bit)/32(bit) = 2 lesz a konstans rtk.
LIFETIME: Hny
Advertisement?
msodperccel
korbban
volt
legutbbi
ICMP
Router
ROUTER IP ADDRESS #N: Szpen sorban jnnek a kiajnlott Default Gateway IP cmek.
PREFERENCE #N: Az adott IP cm preferencija... magyarul mennyire szeresse a host az
illetkes DGW-t. Minl nagyobb a szm, annl jkpbb a router.
~ 155 ~
4.1 .3 .5 .2 ICM P R O UT ER D IS CO VE R Y
Gondolom, nem lepdik meg senki, amikor elrulom, hogy ezt az zenetet a hostok
kldik, mghozz vagy az all router multicast IP cmre (214.0.0.2) vagy a subnet
broadcast cmre. (A Windows Server 2008 /Vista megint a multicast-ot szeretik.)
Mikor? Amikor egy routertl ICMP Router Advertisement csomagot kapnak.
(Amennyiben az ICMP Router Discovery engedlyezve van egy hoston s nem adunk
meg konfigurlskor Default Gateway-t, akkor a host szorgalmas lesz s magtl is
kld ICMP Router Solicitation csomagokat.)
Mit kldenek? Ezt:
4.33. BRA ICMP R OUTER S OLICITATION
Lthat, hogy abszolt nincs tlvarilva. Ez szimpln egy szemrmetlen

fenkriszls, mely a hajlandsgot jelzi - semmi tbb.
TYPE: Jelenleg 10.
CODE: Nulla.
Windows Server 2008 / Vista alatt a kvetkez paranccsal kapcsolgathatjuk:
netsh interface ipv4 set interface <interfaceNameOrIndex>
routerdiscovery=enabled v. disabled v. dhcp
Az alaprtelmezett kapcsol a dhcp. Ez a DHCP szervertl teszi fggv az ICMP

Router Discovery engedlyezst: ha a szerveren meg van adva a Perform Router
Discovery opci (kdszm=31), akkor mehet - ha nincs, akkor nem.
~ 156 ~
4. 1 .3 . 6 IC M P T I M E E X C E E D E D
Id van.
Pontosabban, nincs. Elfogyott.
Alapveten rengeteg olyan pont van, ahol elfogyhat az id, de ne feledjk, most az IP
rtegben vagyunk. Kt idrzkeny feladatunk van:
Csomagokat sszerakni.
Csomagokat routolni.
Az els tnyleg id dimenzij. Ha a fogad host egy bizonyos id alatt kptelen
sszerakni egy szanaszt tredezett csomagot - mert mondjuk nem rkezett meg egy
darab - akkor egy ICMP Time Exceeded - Fragment Reassembly Time Exceeded
zenettel reaglja le a helyzetet.
A routernl kicsit ms a helyzet. Minden csomagnak van egy TTL rtke, mely
tulajdonkppen 'alkalom' dimenzij: indulskor a csomag kap egy rtket s
minden router, amelyiken tmegy, levesz belle egyet. Aztn az a router, amelyiknl
nullra fut a szmll, visszakld egy ICMP Time Exceeded - TTL Exceeded zenetet.
4.34. BRA ICMP T IME E XCEEDED
Lthat, hogy nagy csodk nincsenek, a csomag felptse teljesen megegyezik az

ICMP Destination Unreachable csomagval.
TYPE: 11.
CODE:
0: ICMP Time Exceeded - TTL Exceeded
1: ICMP Time Exceeded - Fragment Reassembly Time Exceeded
~ 157 ~
4. 1 .3 . 7 IC M P P A R A M E T E R P R O B L E M
Tbb felttelnek kell egytt bekvetkeznie, hogy ezt az ICMP pldnyt

levadszhassuk45:
A host ne tudja rtelmezni a csomagban lv IP fejlcet.
Az ICMP zenetek szles skljbl egyet se lehessen rhzni az esetre.
Azaz ez a 'valami baj van, de fogalmam sincs, hogy mi' zenet.
4.35. BRA ICMP P ARAMETER P ROBLEM
A szoksos ICMP csomagtl annyiban tr el, hogy az Unused sormintbl elvettnk

egy bjtot s rtelmet adtunk neki.
TYPE: 12
CODE:
4.17. TBLZAT
CODE
0
1
2
Jelents
A hiba oka a POINTER bjtban
Hinyzik egy ktelez rtk
Elbaltzott hossz
POINTER: Egy szm, mely azt mutatja, hogy az IP Header-en bell melyik bjton
kezddik a hibs paramter.
IP HEADER AND FIRST 8 BYTES OF DATAGRAM: Hogy ne kelljen sokat keresglni, hol van a
hibs IP Header.
45
Kivve CRC error. Akkor ugyanis visszajelzs nlkl dobjk el a hostok a csomagokat.
~ 158 ~
4. 1 .3 . 8 IC M P A D D R E S S M A S K R E Q U E S T & R E P L Y
Arrl mr beszltnk, mi van akkor, ha egy szenilis host elfelejti a Default Gateway
rtkt - illetve egy szemfles router ajnl neki egy rvidebb utat az erdn keresztl.
Jelen ICMP zenetet arra hasznljuk, ha a host a subnet mask rtkt felejti el.
A mechanizmus gy nz ki, hogy a megzavarodott host kld egy ICMP Address Mask
Request krst: vagy egy direktet egy kipczett routernek, vagy egy broadcastot az
alhlzatnak. Ha valaki fogja az adst s ismeri az alhlzatra vonatkoz helyes
subnet mask rtket, akkor visszakldi azt egy ICMP Address Mask Reply
csomagban. Ha nem jn semmilyen visszajelzs, akkor a host knjban a classful
kategrik alapjn vlaszt magnak subnet mask rtket. (4.5. tblzat)
4.36. BRA ICMP A DDRESS M ASK R EQUEST & R EPLY
TYPE: Request: 17, Reply: 18

CODE: Fix nulla.
IDENTIFIER, SEQUENCE NUMBER: A pinghez hasonl azonost szmok, az
sszetartoz csomagokat jellik.
ADDRESS MASK: A Request csomagban egy nulla, a Reply csomagban pedig a helyes
subnet mask rtk utazik.
lltgats:
netsh interface ipv4 set global addressmaskreply=enabled v. disabled
Alaprtelmezsben Windows Server 2008 / Vista esetben tiltott.
~ 159 ~

4.1.4 IGMP,
A Z A Z EG Y K I S
M UL T I CA ST
RFC 1112, 2236, 3376
Egzotikus terletre megynk. Biztos vagyok benne, hogy mindenki hallott mr a

multicast-rl, de abban is biztos vagyok, hogy nem sokan hasznljuk.
Pedig nem tnik rossz dolognak.
Egy gyors emlkeztet. Milyen cast-ok vannak?
UNICAST
: A forgalom kt hlzati pont kztt trtnik, a hostok
kzvetlenl egymst cmezik.
BROADCAST : Egy host ad, mindenki ms fogja az adst.
MULTICAST
: Egy host ad, tbb host fogad - de nem mindegyik.
Mg mindig az ismtlsnl maradva: mit is jelent az, hogy fogad? A Network
Interface Layer fejezetben volt sz arrl, hogy a frame-ek akr kisvasti kocsin, akr
a drtba beleordtva eljutnak minden node-hoz a linken. Mindegyik hlzati krtya
megvizsglja, hogy rintett-e a csomaggal kapcsolatban.
Ha neki szl, akkor a konkrt hoston felkldi egy rteggel feljebb. -> UNICAST.
Ha mindenkinek szl, akkor mindegyik host felkldi egy rteggel feljebb. ->
BROADCAST.
Ha sok hostnak - de nem mindegyiknek - szl, akkor a konkrt host megnzi,
hogy kzte van-e a kivlasztottaknak. Ha igen, akkor felkldi egy rteggel
feljebb. -> MULTICAST.
Gondoljuk vgig, mi lehet a multicast nagy elnye? El akarok kldeni egy nagy
mret fjlt tbb hostnak. Unicast mdon a nagy fjl tbbszr is tmenne a drton. A
multicastnl a felad csak egyszer kldi el - s mindenki, aki rintett benne,
felkapkodja a csomagokat. Tipikusan ilyen szituci lehet egy vide stream, vagy egy
csoportos telepts.
Ok, most mr nagyjbl tudjuk, mi az a multicast. De mi az az IGMP?
Internet Group Management Protocol.
Mit tudunk a broadcastrl? Sok mindent, tbbek kztt azt is, hogy a routerek
nagyon szigoran blokkoljk. Gondolj bele, ha nem tennk, akkor az egsz vilg
rteslne arrl, hogy pl. DHCP szervert keres a szmtgped.
Ezzel szemben a multicast tmegy a routeren.
~ 160 ~

A trkk az, hogy amikor egy host kap egy multicast cmet, akkor odaszl a
routernek, hogy 'te, figyi, ezen a subneten van valaki, aki az albbi multicast cmen
figyel'. Mi tbb, a routerek egymssal is kommuniklnak, megbeszlve, hogy melyik
router mgtt milyen multicast cmek tartzkodnak.
Ez a multicast tmj nagy fecsegs hostok s routerek, illetve routerek s routerek
kztt, ez az IGMP.
De mieltt belesnnk magunkat a routereket
foglalkozzunk egy kicsit magval a multicast-tal.
rint
kommunikciba,
Amikor megemltettem a classful IP osztlyokat, akkor sz volt egy n. multicast

tartomnyrl is. Ez a 224.0.0.0 - 239.255.255.255 cmtartomny. Nem mondtam, de
a CIDR erre a tartomnyra mr nem vonatkozik: itt egy kicsit msok a szablyok s
ezek nem is vltoztak az osztlyok eltrlsvel. (A subnet mask-ot pldul
elfelejtheted.)
Ebben a cmtartomnyban vannak gynevezett well-known (lefoglalt) cmek s
vannak egyedi cmek. Nzznk nhnyat az els kategribl:
4.18. TBLZAT
IP cm
224.0.0.1
224.0.0.2
224.0.0.4
224.0.0.5
224.0.0.6
224.0.0.0-224.0.0.255
239.0.0.0-239.255.255.255
Jelentse
Az sszes multicast kpes host a hlzaton
Az sszes multicast kpes router a hlzaton
Az sszes DVRMP46 router a hlzaton
Az sszes MOSPF47 router a hlzaton
Az sszes PIM48 router a hlzaton
Loklis cmek, nem mennek t a routeren
Adminisztratv clokra fenntartott tartomny (administrative scoping49)
Multicast cmek:
http://en.wikipedia.org/wiki/Multicast_address
Az egyedi cm defincija mg egyszerbb: minden lehet egyedi cm, amely nem

lefoglalt.
Mit rtnk multicast group nven? Minden olyan hostot, mely egy konkrt multicast
cmen figyel. Pldul az 'sszes multicast kpes host a hlzaton' az egy multicast
group, mert a 224.0.0.1 cmen mindegyik host figyel.
s akkor az mi, hogy multicast kpes host? Most akkor minden gp ismeri a
multicast-ot, vagy csak a kivlaszottak? s vajon mindegyik ugyangy?
Distance Vector Multicast Routing Protocol
Multicast Extension to Open Shortest Path First routing protocol
48 Protocol Independent Multicast routing protocol
49 RFC 2365
46
47
~ 161 ~
Route protokollok:
http://www.cisco.com/en/US/tech/tk828/tech_brief09186a00800a4415.html
http://en.wikipedia.org/wiki/Distance_Vector_Multicast_Routing_Protocol
http://www.javvin.com/protocolMOSPF.html
http://www.dataconnection.com/multicast/pimprotocol.htm
Az RFC 1112 szerint az ismersnek tbb szintje van:

Level0 : Se klds, se fogads szintjn nem ismeri a host a multicaast-ot.
Level1 : Tud multicast csomagot kldeni.
Level2 : Tud multicast csomagot kldeni s fogadni is.
A Windows Server 2008 / Vista alatt ezeket a szinteket netsh-val (nan!) tudjuk
lltgatni:
netsh interface ipv4 set global mldlevel=none v. sendonly v. all.
Na, mg egy kis alapozs. Hogyan is kell ezt az egszet elkpzelnnk? Akkor az
Ethernet krtys hostnak van egy becsletes IP cme, mondjuk a 192.168.100.2 aztn van mellette egy multicast cme is?
Bizony. Amennyiben pldul engedlyezzk rajta a multicast-ot, akkor rgtn kap
egy 224.0.0.1 cmet50. s ehhez adhatjuk hozz az egyedi cmeinket, attl fggen,
milyen csoportokat szeretnnk kialaktani.
Igen, igen, ltom a zavarodat. Eddig arrl volt sz, hogy Ethernet, teht NIL szinten
MAC address alapjn trtnik az azonosts. Milyen MAC address alapjn fogjk
megtallni a multicast csomagok a gpnket? Neadjisten t fog menni az ARP
broadcast a routereken?
Nem, ettl nem kell flni.
Nem lesz ARP broadcast51.
A multicast cmekhez automatikusan rendeldik MAC address a cm alapjn, egy
viszonylag egyszer algoritmus segtsgvel:
A 48 bites MAC address fels 25 bitje egy fix rtk, mghozz a kvetkez:
00000001 00000000 01011110 0.
Az als 23 bitje pedig az IP cm jobb szls 23 bitje.
50
51
Ne keresd, az ipconfig -all nem mutatja.

Lassan mondom, hogy Orbn Viktor is megrtse.
~ 162 ~

Konkrt plda:
Ltrehozok egy egyedi multicast group address-t, legyen ez a 224.61.0.4. Hogyan fog
kinzni az ehhez a cmhez rendelt MAC address?
Az els fele egyszer: 00000001 00000000 01011110 0.
A msodik felhez kell elszr az IP cm:11100000 00111101 00000000 00000100.
Ebbl elvesszk a jobb szls 23 bitet, majd hozzcsapjuk az els flhez:
00000001 00000000 01011110 00111101 00000000 00000100
Innentl csak t kell vltani hexadecimlisba: 01-00-5E-3D-00-04
rtem?52
4.37. BRA H OGYAN KELETKEZIK A MULTICAST MAC ADDRESS (F ORRS : WWW . TCPGUIDE . COM )
Ha azt mondod, hogy mg nem minden vilgos, akkor azt mondom, hogy bizony
igazad van. Hny MAC cme lehet egy hlzati krtynak? Lehet-e egyszerre valdi,
begetett MAC cme s lehet-e mellette multicast MAC cme? Ha lehet, akkor
mennyi? s hogyan jelenik majd ez meg?
Itt most vissza kell nylnunk az elz nagy fejezethez, azon bell is egszen eddig az
brig: 3.6. bra Destination MAC Address. Hogy ne lapozz annyit, idemsolom a
vonatkoz rszt:
A MAC Address alapveten egy hatbjtos rtk, ahol az els hrom bjt a hardver gyrtjra
utal, a msodik hrom pedig a konkrt eszkz azonostja.
Az els bjt legals kt bitje specilis szerepkrrel br, mind a felad, mind a cmzett
cmben.
A fenti MAC Address kpzs csak Ethernet hlzatokra vonatkozik. Token Ring esetn pldul az
RFC1469 rja le a mdszert.
52
~ 163 ~

DESTINATION ADDRESS, I/G BIT (INDIVIDUAL/GROUP)
Azt hatrozza meg, hogy a megclzott cm egyedi (unicast, azaz individual), vagy csoportos
(multicast, azaz group). Unicast esetben a bit rtke 0, multicast esetben 1. A broadcast
(FFFFF) ebben az esetben a multicast alesete.
DESTINATION ADDRESS, U/L BIT (UNIVERSAL/LOCALLY ADMINISTERED)
Azt hatrozza meg, hogy a megclzott cm eredeti, begetett (universal) vagy loklisan
fellrt (locally administered). Alaphelyzetben egy hlzati eszkznek a vilgon egyedi MAC
cme van - bizonyos esetekben viszont fellrhatjuk ezeket az rtkeket.
Ebbl a bizonyos I/G bitbl fogja tudni a hlzati krtya drivere, hogy ppen
multicast MAC cmrl van-e sz, vagy valdirl. Amennyiben az elz, akkor tudni
fogja, hogy nem a begetett MAC cmmel kell sszehasonltania, hanem a krtyhoz
rendelt multicast MAC cmekkel. Majd amikor felkapta a csomagot, a MAC-IP
sszerendelsbl fogja tudni, hogy a krtya melyik IP cmre tovbbtsa azt innentl pedig mr jhet az UDP, utna pedig az alkalmazs.
J. Akkor mr csak egy krds van htra: hol lltom be a kliensen a multicast IP
cmet?
...
B flnapos turkls utn arra jutottam, hogy ilyen ltalnos belltablak nincs. Ha
van multicast-kpes alkalmazsod, akkor abban vagy van multicast IP belltablak
(pl. Message Queue) vagy az alkalmazs maga vlaszt ki egy multicast cmet egy
bedrtozott multicast tartomnybl - s ilyenkor elg csak engedlyezned.
RFC 2730
Ezenkvl szbajhet mg a bolondsipka is: Multicast Address Dynamic Client
Allocation Protocol, azaz MADCAP. Ez teljesen analg a DHCP-vel, olyannyira, hogy a
Windows 2000 ta rsze a DHCP szolgltatsnak is. Termszetesen a MADCAP sem
osztogat boldog-boldogtalannak multicast cmeket, kell hozz egy kliens is, aki kr.
Multicast how-to:
http://tldp.org/HOWTO/Multicast-HOWTO-2.html
Internet Protocol IP Multicast Technology:
http://www.cisco.com/en/US/docs/internetworking/technology/handbook/IP-Multi.html
TCP/IP Address Resolution for Multicast IP Addresses:
http://www.tcpipguide.com/free/t_TCPIPAddressResolutionForIPMulticastAddresses.htm
Introduction to Multicast
http://www.firewall.cx/multicast-intro.php
~ 164 ~

Most, hogy mr nagyjbl ismerjk az ptkockkat, nzzk vgig, mi is trtnik
egy multicast kommunikci sorn.
~ 165 ~
4. 1 .4 . 1 E G Y S Z E R V E R K L D E N I A K A R
Itt a nyilam, mibe ljem?

Nyilvn elszr kell egy csoportcm, ahov el akarom kldeni a csomagokat. Ez lehet
egy specilis clra lefoglalt (ez az egyszerbb, ezt legalbb helybl tudjuk) s lehet
egy teljesen egyedi - mely esetben a kld alkalmazsnak kell valahonnan ismernie a
csoportcmet.
Mondjuk megvan a megclzott multicast IP cm. Kldnk ARP broadcast-ot?
dehogy. Hiszen nemrg rtam, hogy az IP cmbl egyrtelmen meg tudjuk
hatrozni a cmzett MAC Address-t. s nem csak mi, feladk, hanem a cmzett is
magnak. Azaz biztosak lehetnk benne, hogy ha be van lltva nla az a bizonyos
multicast IP Address, akkor fel fogja kapni a drtbl a csomagot.
Mieltt tjra indtannk a csomagot, beszljnk mg a TTL-rl. Mekkorra
vlasszuk? Nyilvn ha megclzott IP cm a 224.0.0.0-224.0.0.255 kztt van, akkor a
TTL az 1 lesz. Mert ez szigoran helyi cm kell legyen, azaz mr az els router le kell
blokkolja. Ha viszont 224.0.1.0 feletti cmrl van sz, akkor valami magasabb TTL-t
kell kiokoskodnunk. (Ltezik r egy klszablyszer tblzat.)
J. Legyen a TTL mondjuk 10. Ekkor tmehetnk 9 routeren. De hogyan talljuk meg
ezt a bonyolult tvonalat?
~ 166 ~
4. 1 .4 . 2 E G Y K L I E N S F O G A D N I A K A R
Nem, nem lversenyen.

Akr arrl van sz, hogy a kliensnek van valamilyen multicast IP cme, melyen figyel
a well-known csomagokra... akr arrl, hogy egy alkalmazssal egyeztettek egy
egyedi IP cmet s azon figyel - nos, maga az IP cm meglte mg kevs abban az
esetben, ha a felad s a cmzett kztt van egy router. Azaz a multicast IP cm
nagyobb, mint 224.0.1.0.
Ebben az esetben a kliens nem ldglhet ttlenl a vezetken, hanem akciba kell
lpnie. Fogja, s rtesti a routert, hogy van m a hlzatban egy olyan host, aki
ezen a bizonyos multicast IP cmen figyel. (IGMP Host Membership Report.) A router
pedig fogja s tudomsul veszi.
Mi trtnik, ha bekapcsoldik egy msik host is ebbe a multicast kommunikciba az
illet subnet-en - azaz is megkapja ugyanazt a multicast IP cmet? is szl a
routernek. Mit csinl a router? Nagy vben letojja. A routernek csak arra az egy
informcira van szksge, hogy _minimum egy_ host figyel-e a cmre.
Ugye, pont ezrt multicast.
~ 167 ~
4. 1 .4 . 3 A R O U T E R , A K I S S Z E H O Z Z A A F E L E K E T
Feltve, hogy a router IGMP kompatibilis.

Hogyan is nz ki egy ilyen router feladatlistja?
Elszr is, nyilvn meredten figyel az IGMP Host Membership Report

csomagokra.
Msodszor is intenzven rdekldik, mi is a helyzet a subnet-en: azaz
rendszeresen IGMP HOST Membership Query krseket kld ki.
Akr gy, akr gy, beesnek az adatok. A router ezeket szpen
csoportostgatja, ptyolgatja, tblzatban tartja.
De ezzel a kinccsel nem bnik fukarul: ha az alhlzaton van msik IGMPkpes router is, akkor vele is megosztja az informcit. (Erre szolglnak a
korbban mr emltett DVRMP, MOSPF s PIM routing protokollok.)
s persze a lnyeg: figyel a host helyett is. Azaz ha a router a kls lbn
szleli, hogy valaki multicast cmre kldtt egy csomagot, mghozz olyanra,
mely csoportos cmhez tartozik a bels lbn lv subneten is host, akkor
temeli a multicast forgalmat a bels lbra is.53
Mindezt persze kaszkdolva is tudja - ksznheten a routerek egyms
kztti kommunikcijnak. Azaz ha van a router, alatta egy downstream
router, az alatt meg egy msik downstream router, a multicast csomag kpes
lekeveregni a legals szintre is - feltve, hogy a lncban az sszes router
IGMP-kpes, a csomag TTL-je pedig enged annyi hopot.
IGMP linkek:
http://en.wikipedia.org/wiki/Internet_Group_Management_Protocol
http://www.networksorcery.com/enp/protocol/igmp.htm
http://www.javvin.com/protocolIGMP.html
Ez azrt nem ennyire egyszer. Mit is rtnk azalatt, hogy egy router figyel a multicast forgalomra?
Ugye nem lehet minden ltez multicast cmhez kln MAC Address-e.
Akkor felrnt megvizsglni olyan csomagokat is, melyeket nem is neki kldtek?
Pontosan. Ezt nevezik promiszkusz zemmdnak. Kt verzija is van:
Teljes: a host minden csomagot felrnt.
Multicast: a host csak a multicast csomagokat - ugye az Ethernet MAC Address esetn az
utols bit magas az els oktetbl - rntja fel, de abbl mindegyiket.
s igen, az nyert, aki arra tippelt, hogy mindkett borzaszt erforrsignyes zemmd. Radsul
tik is egymst.
53
~ 168 ~
4. 1 .4 . 4 IG MP V 1
RFC 1112
Rviden sszefoglalva az eddigieket:
A hostok, amennyiben ismerik a multicast zemmdot, s van multicast
cmk, Host Membership Report zeneteket kldzgetnek rendszeresen a
hlzaton. Az zenetek feladja a sajt, nem multicast IP cmk, cmzettje az
aktulis multicast cm, a TTL pedig 1.
A routerek, feltve, hogy IGMP-kpesek, rendszeresen kldzgetnek Host
Membership Query zeneteket a LAN-on. (Felad a router nem multicast IP
cme, cmzett a 224.0.0.1, a TTL szintn 1.) Ezekre a hostok Host Membership
Report zenetekkel vlaszolnak.
Gondoljuk vgig, hogyan is van ez? A router kikld egy HMQ zenetet, majd minden
host eszeveszett mdon elkld vlaszknt egy HMR zenetet? Ekkora vihar, jrszt
feleslegesen? Hiszen a routert istenigazbl nem az rdekli, hogy konkrtan mely
hostok tartoznak egy-egy multicast csoportba, neki bven elg az is, hogy van-e
legalbb egy tagja egy csoportnak?
Ebbl kifolylag nem minden host vlaszol egyszerre, hanem vletlenszer ideig
fontolgatjk a megszlalst, majd vlaszol... az egyik. Mivel a HMR esetn a cmzett a
multicast csoport, gy a csoportbli tovbb fontolgatk mr rteslnek rla, hogy
valaki vlaszolt, ergo nekik mr nem kell.
Amennyiben mltnyoland idtartamon bell nem jn vlasz egy konkrt multicast
csoportbl, akkor a router halk shajtssal trli azt a tblzatbl s rtesti a haver
routereket.
~ 169 ~

Akkor nzzk most mr bit szinten is a konkrtumokat.
4.38. BRA IGMP V 1 CSOMAG FELPTSE
VERSION: Az IGMP verziszma, rtelemszeren jelen esetben 1.

TYPE: Az zenet tipusa.
1: Host Membership Query
2. Host Membership Report
UNUSED: Vajon?
CHECKSUM: A j reg CRC.
GROUP ADDRESS: HMR esetn a csoporttagsgot jelent multicast cm. HMQ esetn
nem hasznlt, az rtke 0.0.0.0.
IGMPv1:
~ 170 ~
4. 1 .4 . 5 IG MP V 2
Az IGMPv1 egyszer volt, valamennyire hatkony is - de akadt rajta tkletesteni

val.
RFC 2236
Az IGMPv2-ben a kvetkez jdonsgok debtltak:
'Elhagytam A Vrost Csoportot' zenet, azaz Leave Group Message.
Csoportspecifikus lekrdezsek, azaz Group Specific Query.
Krdezbiztos (querier) megvlasztsa.
4.1 .4 .5 .1 EL HAG Y TA M A C SO P OR T OT
Az IGMPv1-ben ha kirlt egy multicast csoport, a router egszen addig nem rteslt
rla, amg krbe nem kldtt egy HMQ lekrdezst s arra vgl nem kapott HMR
vlaszt az rintett csoportbl. Azaz egszen addig nyomta t erre a hlzatra is a
multicast adst. Most mondhatnnk, hogy 'jajjaj, szegny router, na bumm, egy kicsit
feleslegesen dolgozott' - de ne felejtsk el, a multicast kommunikcinak ppen az a
lnyege, hogy nagy svszlessget ignyl adsok mennek rajta, clzottan. s akkor
mg nem is beszltnk arrl, mennyi id, amg egy alhlzaton a 'csoport kirlse'
informci vgighullmzik a tbbi IGMP-kpes routeren.
Az IGMPv2-ben eleinte minden ugyangy megy. A router kld egy HMQ lekrdezst,
amelyre minden csoportbl vlaszol az egyik host. Emlksznk, a hostok
vletlenszer merengsi idvel reaglnak, s az els vlaszol nyer. Nos, az IGMPv2ben ennek az els vlaszolnak annyira megn az nbizalma, hogy azt felttelezi,
az egyetlen, ergo az utols csoporttag a csoportban. Emiatt ha valamilyen oknl
fogva elhagyja a csoportot, akkor kld egy 'legyetek jk, ha tudtok' zenetet, azaz
egy Leave Group Message csomagot. A cmzett ilyenkor a 224.0.0.2, azaz az all router
csoport, a felad a host nem multicast cme, a Group Address pedig az elhagyott
multicast csoport cme. Persze az IGMPv2 routerek sem most jttek le a falvdrl,
ellenrzsknt kikldenek egy csoportspecifikus query-t, a ksbb trgyaland
Group Specific Query csomagot. Ha erre valaki vlaszol, akkor a routerek nem
csinlnak semmit. Ha csak nma csend kveti a krdst, akkor tnyleg a kilp host
volt az utols, beindul a multicast csoport trlsi procedrja.
~ 171 ~
4.1 .4 .5 .2 C S O P O R T S P E C I F I K U S L E K R D E Z S
A Group Specific Query (GSQ) zenet teljesen analg az IGMPv1 Host Message Query
zenetvel. Az egyetlen klnbsg az, hogy amg az ltalnos esetben hasznlt HMQ
zenet cmzettje a 224.0.0.1 (all host), illetve a csomagban lv GROUP ADDRESS
rtke 0.0.0.0, addig a GSQ zenetben mindkt helyen a lekrdezend csoport
multicast cme tallhat. Ebbl kvetkezen nem minden multicast host kapja meg,
hanem csak az illet csoporttagok - ergo csak k reaglnak egy HMR zenettel.
4.1 .4 .5 .3 A K R D E Z B I Z T O S
Akkor jn be a kpbe, ha tbb IGMP-kpes router is van egy alhlzaton. Nyilvn

annak nincs semmi rtelme, hogy mindkett HMQ zenetekkel rassza el a hlzatot
- ppen elg, ha az egyik krdezskdik, aztn a vltozsokat mr valamelyik routing
protokoll segtsgvel tkldni a msiknak. Vagy tbbinek.
Mi a kivlaszts mdszere? Melyik lesz az ersebb kutya?
Amelyiknek nagyobb a ... IP cme.
~ 172 ~

Nzzk, hogyan vltozott meg a csomagszerkezet.
4.39. BRA IGMP V 2 CSOMAG FELPTSE
rvendetes vltozsokat lthatunk. Pldul a korbbi kt flbjtot sszevontk

egybe, illetve talltak funkcit annak a kihasznlatlan bjtnak is.
TYPE:
4.19. TBLZAT
TYPE
17 (0x11)
18 (0x12)
22 (0x16)
23 (0x17)
rtelmezse
Host Membership Query (ide tartozik a GSQ is)
IGMPv1 Host Membership Report
IGMPv2 Host Membership Report
Leave Group Message
MAXIMUM RESPONSE TIME: Lekrdezsek esetn (HMQ/GSQ) maximum ennyi ideig vr

a router a vlaszra.
GROUP ADDRESS: A hagyomnyos HMQ esetn 0.0.0.0, minden ms esetben az rintett
multicast cm.
IGMPv2:
~ 173 ~
4. 1 .4 . 6 IG MP V 3
RFC 3376
Nehz gy. Az IGMPv2-vel mr tkletesre faragtuk a multicast forgalom kezelst mi jhet mg? Mit tudunk mg javtani rajta?
A hagyomnyos multicast kommunikcin mr semmit. Csakhogy ma mr a
multicast sem a rgi.
Mi is a multicast? Van egy forrs s az gy juttat el egy adst nhny kivlasztott
gpre, hogy a forgalom csak egyszer megy t a drton.
Tippelj: mennyi eslye van annak, hogy egy ltalad internetre kldtt ads elri
mindazokat multicast hostokat, melyek klnbz kontinenseken vannak
rcsatlakozva a netre? Ugye, nem nehz: nulla. Ma az interneten elhanyagolhatan
kevs a multicast routerek szma54.
De lpjnk tl ezen a fzison. Legyen egy idelis enterprise mret hlzatod, ahol
minden router egyben IGMP-kpes is. Gynyr. Mehet oda-vissza mindenhol a
multicast. Elkezdnk nyomni egy adst mondjuk San Francisco-ban, aztn aszerint,
hogy a tvolabbi hlzatokban, illetve az azok mgtti hlzatokban akad-e olyan
host, mely ehhez az adshoz tartoz multicast cmmel rendelkezik, a routerek teszik
a dolgukat. gy az ads elbb-utbb eljut Kazincbarcikra is.
De mi van akkor, ha valahol vkony a svszlessg? Mondjuk Budapest s London
kztt? Ekkor az sszes magyar helysznen borzasztan fog szaggatni az ads.
Logikusan clszerbb lenne valami hordozhat mdin mr elre eljuttatni az
anyagot Budapestre - s mg nhny helyi kzpontba a vilgban - majd amikor indul
a msor, mindegyik rsztvev host maga dnti el, melyik adra figyel a csoporton
bell. Ezt hvjk gy, hogy Multiple Source For Multicast Traffic, az IGMPv3 pedig
azrt jtt ltre, hogy ezt a kommunikcit ki tudja szolglni.
MBONE:
http://www.mbone.net/
http://en.wikipedia.org/wiki/Mbone
http://acs.lbl.gov/OldMisc/mbone/
Viszont ltezik az interneten egy MBONE, azaz Multicast Backbone. Ezt leginkbb dediklt
szervezetek (IETF, NASA) hasznljk. De tulajdonkppen itt is arrl van sz, hogy multicast szigeteket
ktnek ssze egy gerincvonallal, gy, hogy maga a gerinc a normlis IP forgalomba van
belecsatornzva. (IP-in-IP tunnel). Rszletesebben lsd a link szekcit.
54
~ 174 ~
4.1 .4 .6 .1 IGM P V 3 H O S T M E M B E R S H I P Q U E R Y
Az IGMPv2-ben mr csoportspecifikuss tettk a HMQ zenetet - most emellett

forrsspecifikus is lesz. Azaz a router mr nem csak egy csoportot cloz meg a
query-vel, hanem konkrt forrsokat is. Egsz konkrtan a query tartalmazni fog egy
forrslistt, s vagy csak a listn szerepl forrsokra csimpaszkod hostok kapjk
meg (include list) vagy pont ellenkezleg, a minden ms forrsra akaszkodott hostok
(exclude list).
4.40. BRA IGMP V 3 H OST M EMBERSHIP Q UERY
Egy kicsit megntt a csomag. Az eleje a rgi (mg a TYPE=11 is), de utna kapott egy
csom mezt.
RESERVED: Sorminta.
SUPPRESS ROUTER-SIDE PROCESSING: Ez egy trkks flag. Arrl van sz, hogy ha - a
lentebb lv - robusztussgi elrs magas, akkor a krdezbiztosnak akkor is ki kell
kldenie a HMQ csomagokat, ha mr kapott vlaszt. Ilyenkor lltja magasra ezt a
flag-et, jelezve a tbbi routernek, hogy habr neki muszj volt kikldenie ezt a
krst, de ne foglalkozzanak vele - azaz ne nullzzk le a stopperket. (Mely fut id
lesz sszehasonltva a QUERY INTERVAL rtkvel.)
~ 175 ~

QUERIER'S ROBUSTNESS VARIABLE: A krdezbiztos - azaz a felad router robusztussgt jelz vltoz. Egy mrszm, amely azt mutatja, hogy hny IGMP
csomag veszhet el anlkl, hogy beinduljon egy helyrelltsi folyamat.
QUERIER'S QUERY INTERVAL: Hny msodperc telhet el kt query kztt.
NUMBER OF SOURCES: Mennyi SOURCE ADDRESS is lesz a csomagban... azaz mennyi is
az 'n'?
SOURCE ADDRESS X: A multicast forrs cme.
~ 176 ~
4.1 .4 .6 .2 IGM P V 3 H O S T M E M B E R S H I P R E P O R T
Nyilvn ez sem lett egyszerbb. A kt legltvnyosabb vltozs.

Le lett foglalva a 224.0.0.22 cm az IGMPv3-kpes routerek szmra. A hostok
csak erre a cmre kldenek IGMPv3 tipus HMR zenetet.
A HMR-ben nem egyszeren a csoporttagsg szerepel, hanem gynevezett
Group Record blokkok. Minden blokk tartalmaz egy multicast cmet s n
darab - a multicast cmen sugrz - source cmet.
4.41. BRA IGMP V 3 H OST M EMBERSHIP R EPORT
TYPE: 0x22.
NUMBER OF GROUP RECORDS: A blokkok szma.
~ 177 ~

GROUP RECORD #X: Adatblokk.
4.42. BRA IGMP V 3 G ROUP R ECORD
RECORD TYPE: A lista vajon megenged (include) vagy lezr (exclude)?

AUXILIARY DATA LENGTH: Mennyi kisr adatot rittyentettnk mg a blokk vgre.
NUMBER OF SOURCES: A forrsok szma.
MULTICAST ADDRESS: A csoport multicast cme, melyhez a host kapcsoldik.
SOURCDE ADDRESS #X: A msort szolgl forrsok cmei.
AUXILIARY DATA: Azok a bizonyos kisr adatok.
~ 178 ~
4.2 IP V 6
J 10-15 vvel ezeltt megjsoltk, hogy az IP cmek el fognak fogyni, az internet
pedig sszeszakad. Nos, ez nem trtnt meg, ksznheten a korbban mr emltett
CIDR-nek s NAT-nak.
Persze ezzel csak idt nyertnk, hiszen mindkett csak foltozsa egy kintt
gnynak.
Azrt a NAT csak erforrsignyes. Gondoljunk egy kicsit vissza a folyamatra:
lthatjuk, egy kapcsolathoz a routernek el kellett raktroznia a port mapping
rtkeket. Mi van, ha tbb ezer kapcsolat prg t a routeren percenknt?
Fst. Meg cskkentett felhasznli lmny.
Mi van akkor, ha erforrsokat akarunk publiklni az internet fel? Mondjuk,
kt darab webszervert? A routernek csak egy darab 80-as portja lesz. A msik
webszervernek mr bele kell trdnie a nem szablyos portba. rlni fognak
neki a remnybeli ltogatk. (Feltve, hogy a nluk lv tzfalon egyltaln
engedlyezve lesz mondjuk a helyettestnek kitallt 81-es port.)
A NAT nem igazn tud megbrkzni azzal a szitucival, amikor maga az
alkalmazs szint protokoll rakosgat be IP cm, illetve port rtkeket a
szlltand csomagba - hiszen nonszensz lenne elvrni egy natol eszkztl,
hogy ismerje az sszes protokollt.
Titkosts. Ha a router belepiszkl a csomagba, akkor hiba rtam al odabent
digitlisan, az egsz megy a levesbe. Arrl nem is beszlve, hogy egy rendesen
titkostott csomagot nem is tud a router rtelmezni. (Mondjuk a NAT
Traversal - IPSEC NAT-T - segtsgvel le lehet kezelni a problmt, viszont ez
erforrsba kerl.)
Prbljuk meg elkpzelni a multicast forgalmat egy natolt hlzat fel.
s ezek mg csak a NAT htrnyai. Lehetne sorolni az IPv4 kellemetlen
tulajdonsgait is:
Szk nvtr.
A routolsi szintek nehezen strukturlhatk.
Az autokonfigurci hinya.
A QOS55 csak azzal a bizonyos mdostott TOS mezvel oldhat meg, de ezt
nem minden hlzati elem ismeri. (Pontosabban, vannak olyan elemek,
melyek a TOS rgebbi rtelmezst ismerik csak.)
A mobil kliensek tmogatsnak nehzkessge. (Pl. ha a mobil kliens
menetkzben cellt vlt, a kapcsolat nem szakadhat meg.) Ezt IPv4 all
lekezelni nagyon krlmnyes.
55
Quality Of Services: svszlessg-szablyozs.
~ 179 ~

Nyilvn itt jn kpbe az j internet, az IP v...6. (Az t... az menetkzben elvrzett.56)
RFC1719
Valahogy gy trtnt:
1990. Az IETF megllaptja, hogy baj van. Belevgnak a CIDR-be.
1993. Az IETF kezdemnyezsre beindul az IPng (new generation)
kidolgozsa. Mg ebben az vben kijn az RFC1719, egyfajta irnyelv
gyjtemny.
1995. Rengeteg felmrs, tletels utn elmletben sszell a kp. Az
jszlttet IPv6-nak nevezik el.
1995. Ugye, dbbenet. n viszonylag korn lettem fgg, de az els emailcmem gy
is csak 1997-ben keletkezett57, az els honlapom pedig 1998-ban debtlt. Akkortjt
kezdtem rcsodlkozni erre az rdekes j vilgra.
Mikzben a httrben mr faragtk a mg jabbat58.
4.43. BRA A Z INTERNET 1982 FEBRURJBAN

56Stream
jelleg adattvitelre terveztk. De senki nem hasznlta. 1970-ben?

lazybear@rocketmail.com
58 Emlkszem, 1999 krnykn egy hibt jelentettem be a cgem internet-szolgltatjnak.
- IPv4-et vagy IPv6-ot hasznlnak? - krdezett vissza a rendszergazda.
- Iz... - lett hirtelen melegem - mi a klnbsg?
57
~ 180 ~

4.2.1 A L AP O K
Amikor ezt az egsz internet dolgot elkpzeltk, senkinek mg csak meg sem fordult
a fejben, hogy az a tmnytelen mennyisg kiadhat cm, melyet a 4 bjtos IP cm
s a 4 bjtos subnet mask segtsgvel reprezentlni tudunk, valamikor mg kevs
lesz.
De kevs lett.
Az ignyek ugyanis nttek. Nehogy mr ne n mondhassam meg a
kenyrpirtmnak, hogy mikorra rek haza s mennyire ssse t addigra a kenyeret.
A htgpem pedig igenis kldjn figyelmeztet emailt, ha kevs benne a sr. Ez
mind-mind IP cmet kvn. Mghozz egyedit, mert egy benatolt kenyrpirt, lssuk
be, nem az igazi. (Lehet, hogy a router mgtt mr a porszv foglalta le a megfelel
portot.)
Mondtam, hogy nagyobb lesz a nvtr. Mennyivel?
IPv4 alatt 4 bjtot hasznltunk, most 16-ot fogunk. Aki ebbl azt a kvetkeztetst
vonta le, hogy az j nvtr ngyszerese lesz a rginek, az menjen vissza a j reg
alma materbe s nyomjon egy tockost a matektanrnak, mert rosszul tantottk
meg szmolni. Ngy bjton 232 klnbz szm brzolhat. 16 bjton pedig 2128. Ha
elosztjuk a kt szmot egymssal, azt kapjuk, hogy az IPv6-ban egsz pontosan 296szor tbb lehetsgnk van, mint az IPv4-ben. (Ms szval nem ngyszerese, hanem
negyedik hatvnya.) Ez borzasztan nagy szm ahhoz, hogy legalbb az elkvetkez
tz vben nyugodtan lhessnk a htsnkon. (Remlve, hogy Knban s Indiban
rr lesznek vgre a npszaporulaton59.)
Hogyan fogjuk lerni ezt az rlt nagy szmot?
Nzznk egy pldt:
11000000 10101000 00010111 00001100
Ez a 192.168.23.12, binrisan brzolva.
Csak a hecc kedvrt rjunk fel egy IPv6 cmet binrisan:
11000000 10101000 00010111 00001100 11000000 10101000
00010111 00001100 11000000 10101000 00010111 00001100
11000000 10101000 00010111 00001100
Ez a 192.168.23.12.192.168.23.12.192.168.23.12.192.168.23.12.
Flelmetes. Ki a fene fog ekkora szmokat megjegyezni?
59
Rossz vicc volt, bocs.
~ 181 ~

Nos, termszetesen meg lehet - de ahhoz tmrebb brzols kell. Itt jn be a kpbe
bartunk, a hexadecimlis.
Ekkor ezt kapjuk:
C0A8:170C: C0A8:170C: C0A8:170C: C0A8:170C
Nos, valamennyit mr sszbbment: ez mr csak 8 szmjegy a 16 helyett - igaz,
ezekben mr vannak betk is.
A rossz hr, hogy ezt a prba cmet mr nem lehet tovbb tmrteni: a jvben
rendszergazdaknt nyolc szmjegy cmekkel kell fejben zsonglrkdnnk. A j hr,
hogy amennyiben nulla rtk bjtok is vannak a cmben, akkor mg tmrthetnk
egy kicsit:
fe80:0:0:0:fd12:2f1:1234:abcd:
Lthat, hogy nem kell mindenhol kirni balrl a nullkat. Nem azt rjuk, hogy
0000 vagy 02f1. (Mint ahogy a tizes szmrendszerben sem azt rjuk, hogy
192.168.023.012.)
fe80::fd12:2f1:1234:abcd:
Ez mr kacifntosabb rvidts. Amg az egyms melletti blokkokban csak
nullk vannak, addig az a rsz elhagyhat. Vegyk szre, hogy ahol
kimaradtak a nullk, ott megduplzdtak a kettspontok. Hogy mennyi
maradt ki? Tudjuk, nyolc rszletnek kell lenni, ltunk tt - teht hrom
blokknyi nullnk van. Vigyzat, egy cmen bell csak egy ilyen sszevons
lehet. Nincs olyan cm, hogy fe80::abcd::21 - tekintve, hogy ekkor nem
tudnnk, hogy mely rszen hny res blokk volt. (Aztn ebbl elg vad dolgok
is ki tudnak slni. Hogy mst ne mondjak, a localhost gy nz ki, hogy ::1.)
~ 182 ~

Hallom a krdst, mi hr van a subnet mask-rl? Kszni szpen, a lnyege
megmaradt, csak mostantl prefixnek nevezik. Tovbbra is azt fogja mutatni, hogy
az IP cm hny szmjegye azonostja a hlzatot s hny szmjegye magt a hostot.
Egyszerbb pldval illusztrlni: fe80:0:1234:adf:2::/64. A '/' jel mgtti szm
mutatja meg, hogy ha binrisan rjuk fel a szmot, akkor balrl hny szmjegy
azonostja a hlzatot. A '/64' az ugye jelen esetben azt jelenti, hogy kzpen van a
hatrvonal, a cm els fele a hlzati azonost, a msodik fele pedig a host
azonost, egsz konkrtan:
hlzat
: fe80:0:1234:adf
host
: 2:0:0:0, azaz 2::
RFC 2373
Az IPv4-nl megismert cmzsek (unicast, broadcast, multicast) kre eggyel bvlt:
belpett melljk az anycast is. Ez nagyon hasonl a multicast-hoz, ugyangy tbb
host is figyelhet egy csoportos cmen - de brmelyik is kapta fel maghoz a
csomagot, akkor az mr fel lesz kapva - a tbbieknek nem jut belle.
~ 183 ~
4. 2 .1 . 1 U N I C A S T C M E K
A kvetkez unicast cmek lteznek:

UNIQUE-GLOBAL, azaz egyedi globlis cm
LINK-LOCAL cm, azaz csak a linken rtelmezett cm
SITE-LOCAL cm, azaz csak a loklis site-on rtelmezett cm
UNIQUE-LOCAL, azaz loklisan egyedi cm
Specilis cmek
Transition, azaz ttrsi cmek.
4.2 .1 .1 .1 E G Y E D I G L O B L I S C M E K
Az egyedi globlis cmek, mint a nevk is mutatja, abszolt egyediek. Az egsz

vilgegyetemben. A felptsk nagyjbl gy nz ki:
4.44. BRA E GYEDI G LOBLIS C M
001: Ez a fix rsze a cmnek.

GLOBAL ROUTING PREFIX: Ettl lesz a cm globlis. Tulajdonkppen ebben a
tartomnyban fognak nyzsgni az ISP-k.
SUBNET ID: A globlis cmen belli alhlzatok (site). Logikusan 65536 lehet bellk.
INTERFACE ID: A node egyedi azonostja. Mivel ez egy olyan elem, mely a legtbb
cmzsi techniknl visszakszn, rdemes elmlyedni a generlsban. Ltezik egy
kdols, 64-bit Global Identifier (IEEE EUI-64) a pontos neve. Ennek van egy olyan
fejezete, mely azzal foglalkozik, hogyan is lehetne egy 48 bites MAC (IEEE 802)
addressbl 64 bites egyedi azonostt fabriklni. Le fogsz esni a szkrl, ha elrulom,
hogyan: a MAC address kzepre beszrnak 16 bitet, mghozz ezeket: FFFF.
Pontosabban, ez az ajnls, de az IPv6-ban inkbb az FFFE rtket szrjk be. Mg
pontosabban, ez csak az egyik lehetsges interface id generlsi md... de a
legnpszerbb. (Emlksznk, a MAC address els 24 bitje a gyrt azonost kdja, a
msodik 24 a krty? Azaz a FFFE rtk pont a kett kz szrdik be.)
~ 184 ~

A fenti cmkpzs az elmleti vltozat. A gyakorlatban beszrtak a tervezk nhny
maty csujjogst a koreogrfiba: a MAC address gyrtspecifikus rszben a
konverzi sorn tfordtanak egy bitet. Pusztn a tmrebb szmbrzols kedvrt.
A teljes folyamat az brn lthat.
4.45. BRA M DOSTOTT S MEGVARILT EUI64
~ 185 ~
4.2 .1 .1 .2 L I N K - L O C A L C M E K
A link-local cmek azon cmei egy node-nak, melyek csak az adott linken rvnyesek.
A router ezeket a cmeket nem fogja kiengedni.
Kpzsk:
4.46. BRA L INK L OCAL
1111111010: Fix rtk.

0: 54 res bit: Meglehetsen fix rtk.
INTERFACE ID: Mr ismerjk.
Gondolom, ltod te is, hogy ez az egsz felrhat gy is, hogy FE80::/64 prefix + node
azonost.
Az INTERFACE ID rtknek linkenknt kell egyedinek lennie, azaz eltr linkeken
simn kiadhat ugyanaz az INTERFACE ID.
~ 186 ~
4.2 .1 .1 .3 S I T E - L O C A L C M E K
Amikor ilyen nagy cmtartomnyunk van, simn elfordulhat, hogy n. kztes

alhlzati rendszert iktatunk be a GLOBAL ROUTING PREFIX s az INTERFACE ID kz
(SUBNET ID). Ezeket a kztes alhlzatokat hvjk site-nak, a site-on bellrl kitrni
nem kpes cmeket pedig site-local cmeknek.
gy nznek ki:
4.47. BRA S ITE LOCAL
A szereplket mr ismerjk. A link local cmeknl rtak itt is rvnyesek, csak site
szinten: az INTERFACE ID-nak site szinten kell egyedinek lenni.
Itt mondjuk elgondolkodtam. Ha megnzed a globlis cmeknl a Subnet ID mrete
16 bit, itt meg 54. Ht ezt meg hogyan?
Nem lehet ms a megolds, mint az, hogy a kt Subnet ID nv mgtt eltr
tartalmak lteznek.
Globlis cmnl az ISP-nk subnetel neknk egy kztes szintet. 216, azaz 65536
kztes alhlzatot hozhat ltre.
A Site-local cmnl viszont mi magunk - az ISP-nk mgtt - hozhatunk ltre
egy szigoran loklisan rtelmezett kztes subnet rendszert.
~ 187 ~
4.2 .1 .1 .4 U N I Q U E L O C A L A D D R E S S :
RFC 4193
A helyzet az, hogy a site-local cmek miatt nem lehetnk 100 szzalkig biztosak
abban, hogy a link-local cmeink abszolt egyediek a linken.
RFC 3879 - Developer Pain
4.48. BRA U NIQUE L OCAL CMEK
Emiatt vezettk be a unique-local cmeket. Olyan, vilgmretben nagyon nagy

valsznsggel egyedi cmekrl van sz, melyek loklisan (maximum site szinten)
rtelmezettek, ezen a hatron nem lphetnek t. Ltszlag faramuci dolog ez. Akkor
hasznljk, ha cgek sszeolvadsrl van sz, vagy ssze-vissza kborl mobil
felhasznlkrl. Az els ht bit jelzi a cm kategrijt (1111110), a kvetkez bit
egy flag (L). Ezt kveti egy 40 bites azonost, a Global ID. Ettl lesz a cm nagy
valsznsggel vilgmretben egyedi.
RFC 4193
Ez egy pszeudorandom szm, a generlsa az RFC4193-ban le van rva, de a net is
tele van olyan oldalakkal, ahol ugyanezzel az algoritmussal Global ID-t
generlhatunk magunknak. Ha az L flag magas, akkor ezt az algoritmust hasznltuk a
cmadshoz. Jelenleg ugyan ms algoritmus nem ltezik, de ha lesz, akkor az L flag
alacsony llapota fogja jelezni, hogy az jabbat hasznltuk. Ez utn jn 16 bit site
azonost, majd a jl ismert 64 bites node azonost.
~ 188 ~
4.2 .1 .1 .5 S P E C I L I S C M E K
Pldul a localhost: ::1/128

4.2 .1 .1 .6 T R A N S I T I O N C M E K
tlltani az internetet az IPv6-ra... igen nagy falat lesz. Nem is fog menni egyik
naprl a msikra. A bks tmenet rdekben szksgnk lesz egy csom ktlt
cmre. Itt csak felsorolom ezeket, a rszletezskre ksbb kerl sor.
IPv4-compatible address
IPv4-mapped address
6to4 address
ISATAP address
Teredo address
~ 189 ~
4. 2 .1 . 2 M U L T I C A S T C M E K
ltalban gy nznek ki:
4.49. BRA M ULTICAST
11111111: Fix rtk.

FLAGS: A ngy bitbl a hrom als - azaz jobb szls - bit flagknt viselkedik. Menjnk
jobbrl:
Transient, azaz T-flag.
RFC 2373
Ha alacsony, akkor ez egy well-known cm. Ha magas, akkor egy ksza, akrki
ltal kiosztott cmrl beszlnk.
Prefix, azaz P-flag.
RFC 3306
Ha magas, akkor a multicast cm egy unicast global prefix-hez kapcsoldik. Ha
alacsony, akkor nem.
Rendezvous Point Address, azaz R-flag.
RFC 3956
Ha magas, akkor a multicast cm tartalmaz n. randevpont (RP) cmet. Ha
alacsony, akkor nem.
~ 190 ~

SCOPE: A multicast csoport rvnyessgi kre.
4.20. TBLZAT
A szkp rtke
0
1
2
3
4
5
8
E
F
rtelme
Lefoglalt, nem hasznlhat
Interface-local scope
Link-local scope
Admin-local scope
Site-local scope
Organization-local scope
Global scope
GROUP ID: A multicast csoport jellemz cme.

s akkor nzzk az elrecsomagolt, beptett multicast cmeket. Logikusan
mindegyik az FF0x blokkal fog indulni. (Mirt logikusan? Az 1111 1111 fix rsz az
ugye FF, a flag rtkek 0000, azaz 0, ezzel meg is van az FF0. Az x az meg a szkp.)
FF01::1 - interface-local scope all-nodes multicast address, azaz minden-node

multicast cm, hoston bell60.
FF02::1 - link-local scope all-nodes multicast address, azaz minden-node
multicast cm, linken bell. (Vegyk szre, hogy ez tulajdonkppen a
broadcast! Nincs is kln, megsznt. Ez a multicast cm van helyette.)
FF01::2 - interface-local scope all-routers multicast address, azaz mindenrouter multicast cm a hoston bell.
FF02::2 - link-local scope all-routers multicast address, azaz minden-router
multicast cm a linken bell.
FF05::2 - site-local scope all-routers multicast address, azaz minden router
multicast cm a site-on bell.
Rengeteg egyb elre definilt multicast cm ltezik - pl. sszes DHCPv6 szerver,
meg egyb nyencsgek. Tessk utnaolvasni.
IPv6 multicast cmek:
http://www.iana.org/assignments/ipv6-multicast-addresses
60
Tipikus tbb hlzati krtyval (node) rendelkez host.
~ 191 ~

Gondolom, elg sok ez gy els krben. Ismtlskppen nzzk vgig, milyen
cmekre is kell hallgatnia egy mezei hlkrtynak:
link-local cm
unique global
unique local
loopback
minden-node hoston bell
minden-node linken bell
solicited-node (ez majd csak ksbb fog megjelenni a knyvben)
egyedi multicast cmek
Durva egy kicsit. Ez ugyanis mind egy-egy IP cm, mely a krtyhoz rendeldik.
Alaphelyzetben.
Jogos lehet a krds, hogyan fogunk ezek kztt a cmek kztt tjkozdni? IPv4
esetn a rutinos rendszergazda rnzett egy IP cmre s mr vgta is, hogy az privt
vagy publikus. Mi a helyzet az IPv6 esetben?
4.21. TBLZAT
Cmtipus
Unique global
Link local
Site local
Unique local #161
Unique local #262
Multicast63
Cmtartomny eleje
2000::
FE80::
FEC0::
FD00::
FC00::
FF01::0001
Cmtartomny vge
3FFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF
FEBF::FFFF:FFFF:FFFF:FFFF
FEFF::FFFF:FFFF:FFFF:FFFF
FDFF::FFFF:FFFF:FFFF:FFFF
FCFF::FFFF:FFFF:FFFF:FFFF
FF35::FFFF:FFFF
Nem egyszer, az tny. De nem is megtanulhatatlan.

Most, hogy mr van nmi fogalmunk az IPv6 cmzsrl, rdemes lehet vgignzni
annak a gpnek az IP konfigurcijt, melyen jelenleg is gpelek:
Host Name
Primary Dns Suffix:
Node Type
IP Routing Enabled
WINS Proxy Enabled
:hq
: Hybrid
: No
: No

Connection-specific DNS Suffix
Description
Physical Address
DHCP Enabled
Autoconfiguration Enabled : Yes
IPv4 Address
Subnet Mask
. :
Realtek RTL8168B/8111B Family PCI-E Gigabit Ethernet NIC (NDIS 6.0)
: 00-1E-8C-AB-2F-88
: Yes
: fe80::c5cc:1c5c:8384:4546%8(Preferred)
: 192.168.1.101(Preferred)
: 255.255.255.0
Pszeudorandom algoritmussal.
Jvbeni algoritmussal - ergo ez a tartomny mg nem l.
63 Nem folytonos tartomny, mg a definilt rsztartomnyok kzl sem aktv mindegyik.
61
62
~ 192 ~

Lease Obtained
Lease Expires
Default Gateway
DHCP Server
DHCPv6 IAID
DNS Servers
NetBIOS over Tcpip
:
:
:
:
:
:
2008. jnius 3. 19:14:09

2008. jnius 4. 19:14:08
192.168.1.1
192.168.1.1
201334412
84.2.44.1
84.2.46.1
Enabled
Tunnel adapter Local Area Connection* 6:

Description
Physical Address
DHCP Enabled
Autoconfiguration Enabled
IPv6 Address
Default Gateway
NetBIOS over Tcpip
. :
:
:
:
:
:
:
:
:
Teredo Tunneling Pseudo-Interface

02-00-54-55-4E-01
No
Yes
2001:0:d5c7:a2ca:3c2f:2bc6:3f57:fe9a(Preferred)
fe80::3c2f:2bc6:3f57:fe9a%9(Preferred)
::
Disabled

Description
Physical Address
DHCP Enabled
Default Gateway
DNS Servers
NetBIOS over Tcpip
. :
:
:
:
:
:
:
:
isatap.{47CE5CAA-223F-4CD4-9A17-D91D7DDC2066}
00-00-00-00-00-00-00-E0
No
Yes
fe80::5efe:192.168.1.101%10(Preferred)
84.2.44.1
84.2.46.1
: Disabled
Illetve a route tbla:

===========================================================================
Interface List
8
00 1e 8c ab 2f 88
Realtek RTL8168B/8111B Family PCI-E Gigabit
(NDIS 6.0)
1
Software Loopback Interface 1
9
02 00 54 55 4e 01
10
00 00 00 00 00 00 00 e0
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination
Netmask
Gateway
Interface
0.0.0.0
0.0.0.0
192.168.1.1
192.168.1.101
127.0.0.0
255.0.0.0
On-link
127.0.0.1
127.0.0.1
255.255.255.255
On-link
127.0.0.1
127.255.255.255
255.255.255.255
On-link
127.0.0.1
192.168.1.0
255.255.255.0
On-link
192.168.1.101
192.168.1.101
255.255.255.255
On-link
192.168.1.101
192.168.1.255
255.255.255.255
On-link
192.168.1.101
224.0.0.0
240.0.0.0
On-link
127.0.0.1
224.0.0.0
240.0.0.0
On-link
192.168.1.101
255.255.255.255
255.255.255.255
On-link
127.0.0.1
255.255.255.255
255.255.255.255
On-link
192.168.1.101
===========================================================================
Persistent Routes:
None
Ethernet
NIC
Metric
20
306
306
306
276
276
276
306
276
306
276
IPv6 Route Table

===========================================================================
Active Routes:
If
Metric Network Destination
Gateway
9
18
::/0
On-link
1
306
::1/128
On-link
9
18
2001::/32
On-link
9
266
2001:0:d5c7:a2ca:3c2f:2bc6:3f57:fe9a/128
On-link
~ 193 ~

8
276
fe80::/64
On-link
9
266
fe80::/64
On-link
10
281
fe80::5efe:192.168.1.101/128
On-link
9
266
fe80::3c2f:2bc6:3f57:fe9a/128
On-link
8
276
fe80::c5cc:1c5c:8384:4546/128
On-link
1
306
ff00::/8
On-link
9
266
ff00::/8
On-link
8
276
ff00::/8
On-link
===========================================================================
Persistent Routes:
None
Csemegzznk.
Vajon mi lehet az IPv6 cmem? Vigyzat, beugrat krds, ugye elg sok lehet. De
jelen esetben csak link-local cmeket ltunk, az egyik pl. gy nz ki:
fe80::c5cc:1c5c:8384:4546%8. Rnzsre tbb baj is van a cmmel. Elszr is, mi az
a %8 a vgn? Aztn az INTERFACE ID egyltaln nem gy nz ki, mintha a MAC
address-bl kpeztk volna betoldssal. ruls? Nos, a %8 formulra egyszer a
vlasz: htkznapi cm esetn ez az interface azonost szma, gynevezett
znaazonost. (A route tblnl lthat, hogy konkrtan egy Realtek hlkrtyrl
van sz.)
J, akkor mi van az INTERFACE ID-val? Az, hogy az EUI-64 nem ktelez. A Windows
Server 2008 illetve a Vista alaphelyzetben pldul vletlenszeren generlt interface
ID-t hasznl. Errl a kvetkez parancs segtsgvel tudjuk lebeszlni:
netsh interface ipv6 set global randomizeidentifiers=disabled
Miutn kiadtam ezt a parancsot s megjtottam az IP cmemet, a kvetkezt

kaptam:
Link-local IPv6 Address: fe80::21e:8cff:feab:2f88%8
Ugye, mindjrt ms? Ez mr EUI-64. A maty csujjogatssal.

Mirt is nincs globlisan vagy loklisan egyedi (global/local unique) cmem? Mert a
routerem azt mondta, hogy nekem olyanom nincs. Pontosabban, nem mondta, hogy
van.
Aztn nagyon elszaladtunk amellett, hogy nekem nem is egy link-local IP cmem van.
Mi is a tbbi? Nos, transition cmek. Azok, melyeket csak gy megemltettem
korbban. Most sem kapnak nagy szerepet... de azrt vegynk szre valamit:
mindkett, a Teredo s az Isatap is Tunnel Adapter Local Area Connection nven fut.
Tunnel... valami belecsvezve valamibe. Mi van most? IPv4. Mi lesz majd? IPv6.
Nyilvn logikus, hogy ezeket a cmeket hasznlva tulajdonkppen az IPv6-ot
csatornzzuk bele az IPv4-be.
~ 194 ~

Vgl egy krds: ha teszem azt a Magyar Telecom globlis azonostja 1100 0000
0000 0000 0000 0000 0000 0000 0000 0000 0000 1 s a n ezen bell a 0000 0000
0000 0011 subnetben vagyok, akkor mi lesz a vilgegyetemben az egyedi
azonostm?
Laptoljuk ssze: 001, mert ez abszolt fix. Ehhez hozzcsapjuk az ISP globlis
azonostjt s a subnet azonostt. Ez lesz a prefix, ehhez jn majd az INTERFACE
ID, melyet a link-local cmbl tudunk kibnyszni. Jelen esetben ez
c5cc:1c5c:8384:4546.
Innen mr csak matekozs: 3800::1:3:c5cc:1c5c:8384:4546/64.
Long live calc.exe.
(Hint: fel kell rni bitsorozatknt, bjtonknt csoportostani, tvltani, kt bjt egy
blokk.)
Vgezetl egy tblzat, arrl, melyik IPv6-os cmnek melyik IPv4-es cm felel meg.
4.22. TBLZAT
IPv4
Internet cmosztlyok
Multicast cmek (224.0.0.0/4)
Broadcast cmek
Meghatrozatlan cm (unspecified address): 0.0.0.0
Loopback: 127.0.0.1
Publikus IP cmek
Privt IP cm tartomnyok
APIPA (168.254.0.0/16)
64
IPv6
Elfogyott
Multicast cmek (FF0x::/8)
Szintn nincs
Meghatrozatlan cm (unspecified address): ::64
Loopback: ::1
Global Unicast Address
Unique Local, Site Local Addresses
Link Local Addresses
Kicsit sok a kettspont, de gondolom rthet.
~ 195 ~
4. 2 .1 . 3 A Z I P V 6 C S O M A G
Az IPv6 csomag felptse nmileg eltr az eddig megszokott csomagoktl.

ltalban volt olyan, hogy header, meg payload (nhol trailer is) - de olyannal eddig
mg nem tallkoztunk, hogy a header tcssszon a payloadba.
Eddig.
4.50. BRA IP V 6 CSOMAG
Van packet s van header, odig rendben is volnnk - de van egy extension header a
payload-on bell. St, nem is egy, mert az brn is tbbes szmmal lett jellve.
Bizony, bizony. gy lett rugalmas az IPv6. Van egy rgztett fejlce, van egy rgztett
PDU-ja - ez volt az IPv4-ben a payload - s a kett kztt van egy tetszlegesen
bvthet gumi gyrdzna.
~ 196 ~

Habr mg nem minden rsze rthet a rajznak, de valami ilyesmit kell elkpzelni:
4.51. BRA F EJLC LNCOLSOK
A fels brn nincs Extension Header, a fejlc kzvetlenl a payload-dal, azaz a TCP
szegmenssel folytatdik. Az als brn jelentsen bonyolultabb lett a helyzet, kt
extra fejlc is befurakodott az IPv6 fejlc s a payload kz.
Az Upper-Layer Protocol Data Unit-tal (ez neveztem PDU-nak) van a legkevesebb
gondunk: mint rtam, ez felel meg az IPv4 payload-nak, azaz lehet TCP, UDP, ICMPv6.
A tbbi mezvel viszont rdemes rszletesebben is megismerkedni.
~ 197 ~
4.2 .1 .3 .1 IP V 6 H E A D E R
4.52. BRA IP CSOMAGOK FEJLCEINEK
SSZEHASONLTSA
Nos, itt vannak. Melyik a nagyobb? Na...? Ha jl figyeltl korbban, akkor mr tudod a
korrekt vlaszt: 'attl fgg'. Lthatod, hogy az IPv4 csomag ll egy fix - 20 bjt mret rszbl, majd jn az IP Options mezk vgelthatatlan sora. (Maximum 60
bjt, termszetesen nggyel oszthatra kiegsztve.)
Ezzel szemben az IPv6 fejlc mrete fix 40 bjt. Tessk krem, jabb s kisebb pedig az IP cmek ngyszerannyi helyet foglalnak.
Na, ja. Csakhogy az IP Options mezket poftlanul kiszerveztk a payload-ba, s hogy
a PSzF se jjjn r, tneveztk Extension Headers nvre.
Ami nem vltozott, az az IP csomag (header+payload) maximlis mrete: az
tovbbra is 65535 bjt65. Azaz tulajdonkppen lthat, hogy csak a dgt rugdostuk
t az egyik gy all a msik al, a fejlc mrete a payload mretnek rovsra
cskkent.
Illetve az IPv6 csomag lehet nagyobb is, mint 65535 bjt, ekkor jumbogram-nak hvjuk, s nmileg
mshogyan kezeljk.
65
~ 198 ~

Boncolgassuk egy kicsit az IPv6 fejlcet.
4.53. BRA A Z IP V 6 CSOMAG FEJLCE
VERSION: rtelemszeren az rtke: 6.

TRAFFIC CLASS: Teljes mrtkben analg az IPv4 csomagban lv DS bjttal. (Tudjuk, 6
bit DSCP, 2 bit ECN - ezt az egszet Type of Services-nek (TOS) hvjk s a QOS-hez
kell.66)
FLOW LABEL: 20 bites mez, egy konkrt, specilisan kezelend adatforgalmat jell.
RFC 3697
Olyan forgalomrl van sz, mely az IPv4-ben elg mostohn volt kezelve - tekintve,
hogy a hetvenes vekben ezeknek tl sok szerepk nem volt. A stream jelleg
adatfolyamokrl beszlek. A FLOW LABEL, mint cimke azonostja az egyes
adsokhoz tartoz csomagokat. (Mindemellett ha az rtke nem nulla, akkor jelzi a
routereknek is, hogy ezeket a csomagokat klnleges elbnsban kell rszestenik.)
66
Eddig ez a legvadabb mondat a knyvben.
~ 199 ~

PAYLOAD LENGTH: Mekkora a payload konkrt rtke. Ugye a bevezetben mr lttuk,
hogy az Extension Headers miatt a payload rtke nem rgztett. Gondolom az elz
oldalon emltett 65535-s fels korlt miatt senkit nem lep meg, hogy a mez
mrete kt bjt.
HOP LIMIT: Tulajdonkppen ugyanarra szolgl, mint az IPv4 esetben a TTL. A felad
indulskor bellt egy rtket majd mindegyik router lekap belle egyet
thaladskor. A csomag akkor hal hsi hallt, ha ez az rtk lenullzdott.
NEXT HEADER: De hiszen ezt mr lttuk! (4.51. bra Fejlc lncolsok) Ez
tulajdonkppen egy kd, azt mutatja meg, hogy a kvetkez blokkban mi jn:
valamilyen Extension Header vagy mr a tnyleges PDU.
~ 200 ~
4.2 .1 .3 .2 IP V 6 E X T E N S I O N H E A D E R S
Mint emltettem, az IPv4-ben hasznlt IP Options blokkokat helyettestik.

4.23. TBLZAT
Next Header Field rtk
0
6
17
41
43
44
50
51
58
59
60
Megnevezs
Hop-by-Hop Options header
TCP
UDP
Encapsulated IPv6 header
Routing Header
Fragment header
Encapsulating Security Payload header
Authentication header
ICMPv6
Konyec, nincs tbb header
Destination Options header
A felptsk is teljesen hasonl.
4.54. BRA LTALNOS E XTENSION H EADER
NEXT HEADER: Ez mutat a kvetkez blokkra.

HEADER EXTENSION LENGTH: Tekintve, hogy az Extension Header mrete nem rgztett,
valahogyan jelezni kell, hol van a vge.
OPTIONS: Itt pedig jnnek a tipusoktl fgg adatblokkok. A felptsk teljesen
analg az Extension Header felptsvel, azaz jn egy tpusazonost kd (mivel a
konkrt Extension Header-en bell is lehetnek alesetek), egy hosszrtk s maga az
adat. (Igen, Matrjoska baba.)
~ 201 ~
4.2 .1 .3 .2 .1
HO P- B Y - H OP O P T I O N S H E A D E R
A nulls kd. Ez az a header, melyet minden tbaes hop felolvas, rtelmez.

Rgtn egy olyan opcit header-t talltunk, amelynek tbb altipusa (options) is
ltezik.
RFC 2460
PAD1/PADN OPTIONS: 1, illetve tetszleges szm res bjtot fz hozz a Hop-by-Hop
header-hez. Amennyiben jl rtettem, ezekre a feltltsekre szmolsi
optimalizlsok miatt van szksg.
RFC 2675
JUMBO PAYLOAD OPTION: Egy flmondat mr esett arrl, hogy az IPv6 mr tmogat
65535 bjtnl nagyobb csomagot is. Senkinek nem tmadt knyelmetlen rzse:
hogyan is lehetsges ez, ha a PAYLOAD LENGTH mez mrete csak 16 bit? Nos, gy,
hogy a csomag mrete nem ott troldik, hanem a Jumbo Payload option 32 bites
adatterletn. Ez maximum 4 GB mret payload-ot enged.
rtjk mr, hogy mirt Jumbo?
RFC 2711
ROUTER ALERT OPTION: Figyelmezteti a routert, hogy ezzel a csomaggal mg lesz egy
kis pluszmunkja. (Emlksznk, multicast-nl voltak ilyesmik korbban.)
~ 202 ~
4.2 .1 .3 .2 .2 D E S T I N A T I O N O P T I O N S H E A D E R
A csomag szlltsra vonatkoz paramtereket tartalmazhat. rtelmezni

ktflekppen lehet:
Ha van mellette Routing Header, akkor minden tbaes clpontra vonatkozni
fognak a paramterek.
Ha nincs mellette Routing Header, vagy a Routing Header elrbb van, mint a
Destination Options Header, akkor a paramterek csak a legvgs clpontra
fognak vonatkozni.
RFC 3775
Mik lehetnek ezek a paramterek? Pldul a Home Address Option. Ezt akkor
hasznljuk, ha mobil eszkzn kommuniklunk - olyan mobil eszkzn, mely
tnylegesen is mozog. Ekkor az Option adatmezjbe belekerl a mobil eszkz hazai
cme - az a cm, mely eredetileg, a mobil eszkz eredeti linkjn tartozott hozz.67
4.2 .1 .3 .2 .3 R O U T I N G H E A D E R
Ilyet is lttunk mr korbban. (Strict/Loose Source Routing; 4.1.1.2 IP Options)

Ez az, amikor elrjuk a csomagnak, hogy milyen tvonalon kell mennie.
Az IPv6-ban a szigorsg enyhlt, azaz a Routing Header mr csak a loose tipus
elrst tmogatja.
A Windows meg mg ezt se. A Windows Vista eleinte mg elvolt vele, de aztn az
IETF biztonsgi szempontok miatt inkbb azt javasolta, hogy hanyagoljk. A Vista
SP1-bl emiatt ki is vettk. (A Windows Server 2008-ba meg mr bele sem kerlt.)
Ha ilyen csomagokat kapnak, akkor sz nlkl eldobjk azokat.
4.2 .1 .3 .2 .4 F R A G M E N T H E A D E R
A j reg tredezs. Mikor is van r szksg? Ha a csomag tl nagy. Mekkora a tl

nagy: 65535 felett?
Dehogyis. Az MTU felett. Emiatt kezdjk gy a kommunikcit, hogy meghatrozzuk
a PMTU rtkt. Inkbb, mint hogy trdeljk a csomagot.
Ha mr az IPv4-ben sem szerettk a trdelst, akkor gondolhatod, hogy az IPv6-ban
gy utljuk, mint veges tt a hanyattesst. Pldul a kzbens hop-oknak tilos.
Vagy a felad trdel, vagy senki sem.
67
A mobil IPv6-rl majd valamikor mskor.
~ 203 ~

4.2 .1 .3 .2 .5 A U T H E N T I C A T I O N H E A D E R
RFC 2401, 2402

A csomag integritst biztostja egy n. Integrity Value Check (ICV) sszeg
segtsgvel. A szmolshoz rtelemszeren nem hasznlja fel az IP Header sszes
mezjt, hiszen ezek kztt vannak olyanok, melyek menet kzben norml
zemmenetben is vltoznak.
Az integrits biztostsa mellett mg az AH dolga a forrs autentikltatsa s egy n
visszajtszs elleni vdelem is. Ez utbbi abbl ll, hogy a csomag rsze egy
Sequence Number, ezt minden hozznyl hop megnveli eggyel. (Tessk, rgtn itt
is van egy elem, melyet nem lehet belevenni az ICV-be.)
4.2 .1 .3 .2 .6 E N C A P S U L A T I N G S E C U R I T Y P A Y L O A D H E A D E R
RFC 2406
Az AH sok mindent nyjt - titkostst speciel nem. Arra az ESP j.
Mind az AH, mind az ESP Header, illetve a mgttk lv eljrsok meglehetsen
komplex rendszert alkotnak, ezekkel majd ksbb foglalkozunk.
~ 204 ~
4.2 .1 .3 .3 ICM P V 6
RFC 4443
Nagyjbl ugyanazok a feladatok, mint az ICMPv4 esetben - csak valamivel
ramvonalasabb adatszerkezettel. Msok lettek a mezk, a nevek, a kdok - de a
funkcik maradtak.
Mivel ezekrl mr volt sz bven ebben a knyvben, gy csak egy tblzatban teszem
egyms mell az azonos funkcikat.
4.24. TBLZAT
ICMPv4
Destination Unreachable-Network Unreachable
(Type3, Code 0)
Destination Unreachable-Host Unreachable (Type 3,
Code 1)
Destination Unreachable-Protocol Unreachable (Type
3, Code 2)
Destination Unreachable-Port Unreachable (Type 3,
Code 3)
Destination Unreachable-Fragmentation Needed and
DF Set (Type 3, Code 4)
Destination Unreachable-Communication with
Destination Host Administratively Prohibited (Type 3,
Code 10)
Source Quench (Type 4, Code 0)
Redirect (Type 5, Code 0)
Time Exceeded-TTL Exceeded (Type 11, Code 0)
Time Exceeded-Fragment Reassembly Time Exceeded
(Type 11, Code 1)
Parameter Problem (Type 12, Code 0)
ICMPv6
Destination Unreachable-No Route to Destination
(Type 1, Code 0)
Destination Unreachable-Address Unreachable
(Type1, Code 3)
Parameter Problem-Unrecognized Next Header Type
Encountered (Type4, Code 1)
Destination Unreachable-Port Unreachable (Type 1,
Code 4)
Packet Too Big (Type 2, Code 0)
Destination Unreachable-Communication with
Destination Host Administratively Prohibited (Type 1,
Code 1)
Nyema
Neighbor Discovery Redirect message (Type 137, Code
0)
Time Exceeded-Hop Limit Exceeded in Transit (Type
3, Code 0)
Time Exceeded-Fragment Reassembly Time Exceeded
(Type 3, Code 1)
Parameter Problem (Type 4, Code 0 v. 2)
~ 205 ~
4. 2 .1 . 4 N E I G H B O R D I S C O V E R Y , N D
RFC 4861, 4862

Mint a neve is mutatja, arrl van sz, hogy az azonos linken lv node-ok valamilyen
mechanizmus alapjn megkeresik egymst. Azonkvl, hogy j trsasgban jobban
telik az id, a mdszernek van tbb elnye is:
Ha csomagot kell kldennk, jval hatkonyabban be tudjuk szerezni a
cllloms MAC cmt.
Ha egy MAC address megvltozik, automatikusan rteslnk rla.
Hasonlkppen arrl is, ha a hostot lekapcsoljk. Vagy lefagy.
Kpbe kerlnk: tudni fogjuk, hol vannak a linken routerek.
DHCP nlkl valsthatunk meg autokonfigurcit.
A routereknek lehetsgk van a szolgltatsaikat reklmozni. (Radsul
nem is kell fizetnik rte.)
A routerek tirnythatnak forgalmakat, ha ltezik jobb tvonal.
rezzk, hogy ez tbb dologbl lett sszegyrva. Ott vannak benne az ICMPv4
fejezetben taglalt mechanizmusok, de a MAC vadszatra korbban hasznlt ARP
folyamatok is.
Itt mindent ICMPv6 zenetekkel fogunk megvalstani. Konkrtan:
Router Solicitation (Type 133)
Router Advertisement (Type 134)
Neighbor Solicitation (Type 135)
Neighbor Advertisement (Type 136)
Redirect (Type 137)
Referenciatblzat az IPv4 s az IPv6 mechanizmusok kztt:
4.25. TBLZAT
IPv4
ARP Request message
ARP Reply message
ARP cache
Gratuitous ARP
Router Solicitation message
Router Advertisement message
Redirect message
~ 206 ~
IPv6
Neighbor Solicitation message
Neighbor Advertisement message
Neighbor cache
Duplicate Address detection
Router Solicitation message
Router Advertisement message
Redirect message

Csomagszinten gy kell elkpzelni, mintha ICMPv6 lenne. Leginkbb azrt, mert
ugye, az.
4.55. BRA N EIGHBOR D ISCOVERY ZENET
Az eddigiektl eltren ebbe a fejezetbe nem mennk bele annyira rszletesen inkbb csak elv szintn mutatnm be a Neighbor Solicitation / Neighbor
Advertisement folyamatokat.
Azt tudjuk, hogy ez a kt zenet tpus az ARP Request / Reply zeneteket vltja fel.
Mi is volt az ARP Request legnagyobb hibja? Az ARP broadcast. Egyrszt nagy
terhelst jelentett a hlzatnak, msrszt pedig a routerek lenyakaztk.
Az IPv6-ban ugyan eljtszhattk volna mindezt a minden-node link-local cmre
kldtt zenettel, de akkor ugyanott lennnk, mint az ARP broadcast-tal.
Ehelyett egy specilis multicast cmre megy ki az rdekld zenet. Ezt a specilis
cmet hvjk gy, hogy solicited-node cm. A kvetkezkppen kpzdik:
4.56. BRA S OLICITED - NODE
A megrts kulcsa az als mez. Kinek is az Interface ID-ja? Nyilvn nem a felad.
Annak nem lenne semmi rtelme. Termszetesen a keresett IP cmbl - IP(B) kpzdik a solicited-node cm.
~ 207 ~
4.57. BRA M KDSBEN A SOLICITE D NODE CMZS
Az rdekld (A) node teht legyrtja ezt a solicited -node cmet s elkldi neki a
sajt IP cmt - IP(A) - sajt MAC cmt - MAC(A) - s persze a keresett IP cmet IP(B). Mely node-ok fogjk felkapni ezt a krst? Akiknek a - sajt maguknak mr
korbban legyrtott solicited-node - cmk megegyezik a felad ltal megadott
solicited-node multicast cmmel. Egsz konkrtan: az a pr node fogja felkapni, ahol
az interface ID jobb szls 24 bitje megegyezik. A tbbi node bksen krdzik
tovbb. Tiszta haszon az ARP broadcast-hoz kpest.
A tbbi mr hasonl: a megtallt node visszakldi a MAC(B) cmet s mr mehet is a
traccs.
Egy jabb gondolkods krds: a korbban bemsolt adataim alapjn vajon mi is
lesz az n solicited-node cmem?
Az els 104 bit, az ugye adott. A maradk 24 bit pedig kiszmolhat az Interface IDbl.
Merre is vagy, calc.exe?
Tessk, a cm: ff02:1::ff00:0084:454668. Most az egyszer nem segtek.
Elkpzelhet, hogy valakiben felmerl a krds: mire is j ez az egsz cc? Hiszen
az interface ID a MAC address-bl kpzdik... egyszeren szmoljunk belle vissza s
mr mink is a MAC.
Az tlet j... de sajnos ez csak ajnls. Az interface ID sokflekppen keletkezhet,
semmi garancia sincs r, hogy pont az EUI-64 volt a keletkezsnek alapja.
68
Azt ugye ltjuk, hogy az rtke (ff02) alapjn ez egy link-local multicast cm?
~ 208 ~
4. 2 .1 . 5 M U L T I C A S T L I S T E N E R D I S C O V E R Y ( ML D )
RFC 2710
MLD: ez volt az IPv4-ben az IGMP. Pontosabban az IGMPv2.
RFC 3810
Az IGMPv3-nak pedig az MLD2 felel meg.
Ok, kpben vagyunk. Jhetnek a rszletek.
Rgtn egy klnbsg: IPv4-ben egy host vagy tmogatta a multicast
kldst/fogadst, vagy nem. IPv6-ban nincs ilyen lazasg: a multicast ismerete
ktelez.
Tudom, szomor leszel, de a rszletekbe olyan tlzottan azrt nem fogok belemenni.
Egyrszt az MLD tnyleg nagyon hasonlan mkdik, mint az IGMP, gy a
mechanizmusok ismertetsbe nincs rtelme tlzottan elmlyedni.
Itt is vannak zenetek, az analgikat az albbi tblzat mutatja:
4.26. TBLZAT
IGMPv2
Host Membership Query (Type 17)
Host Membership Report (Type 22)
Leave Group (Type 23)
MLD
Multicast Listener Query (ICMPv6 Type 130)
Multicast Listener Report (ICMPv6 Type 131)
Multicast Listener Done (ICMPv6 Type 132)
~ 209 ~

Maguk az zenetek - mint a tblzatbl is lthat - ICMPv6 tipus zenetek. Mint a
Neighbor Discovery-nl. A csomag szerkezete is hasonl:
4.58. BRA MLD ZENET
Hasonl... de nem ugyanaz. Vegyk szre, hogy egy Extension Header befurakodott a
kpbe. Router Alert Option. Mire is j ez? Lapozzunk vissza.
gy van. Figyelmezteti a routert, hogy ezzel a csomaggal lesz nmi adminisztrcis
munkja. (Lsd IGMP.)
~ 210 ~
4. 2 .1 . 6 A U T O K O N F I G U R C I
RFC 2464
Ez megint egy szp tma. Kezdjk megint azzal, hogy milyen lehetsgnk volt
autokonfigurcira IPv4 alatt? Igen, a DHCP. (Illetve, brmilyen furcsn hangzik, de
egyfajta stateless autokonfigurci volt az APIPA is.)
Az IPv6 alatt tgabb lett a horizontunk:
Stateless autoconfiguration
Stateful autoconfiguration
Kombinlt brlet
Az egsz gy kezddik, hogy a router - ha van egyltaln - kikld a linkre egy Router
Advertisement zenetet. Ennek meglttl, illetve tartalmtl fggen az egyes
hostok eldntik, hogy itt most a fenti hrom autokonfigurcis esetbl melyik ll
fent.
Itt most csak a stateless vltozatot vizsglgatjuk, a DHCP mkdsvel majd az
alkalmazs rtegben fogunk megismerkedni.
RFC 4862
Van egy hostunk, egy hlzati krtyval. Feldugjuk egy IPv6 hlzatra. DHCPv6
nincs. Router van.
A router meghatrozott idnknt kld egy zenetet (Router Advertisement) a
minden-node link cmre. Az zenet sokmindent tartalmaz, tbbek kztt:
A router MAC cmt
A linken l prefixeket
A linken rvnyes MTU-t
A linkre vonatkoz spci routolsokat
A linken rvnyes maximlis hop szmot
Van-e DHCP a linken?
s mg sok egyebet. Mennyire j ez neknk? Nagyon. Kzpontilag szablyozhat
MTU? Hmm... finom. A link sszes prefixe? lljunk csak meg. Ha adottak a prefixek
(rgi szhasznlatban a subnetek) - Router Advertisement, azon bell Prefix
Information opci - a hlkrtya meg ismeri a sajt MAC cmt, ismeri az EUI-64
mdszert... simn le tudja gyrtani magnak a link sszes prefixre a prefixnek
megfelel IPv6 cmet.
~ 211 ~

Mennyivel jobb mr, mint egy hasratsszeren kiadott cm a 169.254.0.0./16 IP
tartomnyban?
Szval belp az j lloms a linkre. Olyan korban lnk, hogy trelmetlenek
vagyunk: nem vrjuk meg, hogy a router krbekldje az zenett, belergunk:
Router, kldj zenetet! (Router Solicitation.) s az kld. Ez alapjn a node sszerakja
magnak a link-local cmeit. Elkpzelhet, hogy tkzni fog msik node cmeivel?
Bizony, igen. Ekkor jn a j reg Neighbor Discovery. Megszlitjuk a solicited-node
cmen azt az IP cmet, melyet magunknak kvnunk lefoglalni. Ha nem jn vlasz,
nyertnk. Mink a cm.
(Ki kell r trnem, hogy a Windows implementcinl ez is mskpp van egy kicsit.
Arrl mr rtam, hogy az Interface ID nem EUI-64 mdon generldik, hanem
vletlenszeren. Arrl viszont nem, hogy a tervezk gy saccoltk, nagyon kicsi az
eslye annak, hogy a vletlen azonostk kztt egyformk legyenek: ezrt elhagytk
az ellenrzst.)
Mi van, ha megvltozik a MAC cmnk? gy csinlunk, mintha ND krdseket
kaptunk volna, elrasztjuk a linket vlaszokkal.
Mi van, ha kt hlkrtyval is kapaszkodunk egy linken? Hol ez, hol az fog
vlaszolni az ND krsekre - terhelseloszts.
~ 212 ~

4.2.2 IP V 4 -> IP V 6
K O N V E R ZI K
RFC 2893
Szval itt van ez a szebb s jobb IPv6. De mg mita, hogy itt van. Hogyan fogunk
erre ttrni? s mikor? Mikortl kell hexa-dec-bin konvertls szmolgpet
integrlni a rendszergazdk mobiltelefonjba?
Prbljuk meg kicsiben elkpzelni. Van egy magyar rtelemben kis/kzepes cges
hlzatunk: 1-200 gp, 10-15 szerver, egy core.net a kzpontban, kt telephely
(site1.net, site2.net), meg egy dmz.net. Hogyan llnnk neki?
Els krben fellltannk hrom kategrit:
IPv4 only host
:
olyan gp, amelyik csak az IPv4 mdot ismeri.
IPv6 only host
:
olyan gp, amelyik csak az IPv6 mdot ismeri.
IPv4/IPv6 host
:
olyan gp, amelyik mind a kettt ismeri.
Mikor fogunk eljutni oda, hogy egy szervernk IPv6 only legyen? Taln az unoknk.
Teljesen termszetes, ha elszr azt clozzuk be, hogy minden host, minden router
IPv4/IPv6 host legyen. Szerencsre ez ma mr nem akkora nagy kihvs, a Service
Pack 2 ta az XP is kpes r.
~ 213 ~
4.59. BRA IP V 6 TELEPTSE W INDOWS XP AL
rtelemszeren az utdok - Vista, Windows7 - mr gyrilag beptve tartalmazzk

az IPv6 ismerett.
4.60. BRA T IPIKUS IP V 4/IP V 6 HOST
~ 214 ~

Mr csak az skvlet NT4 hasznlkat69 kell meggyzni, hogy ha a ksbbiekben is
el szeretnk rni a hlzatot, akkor esetleg elkezdhetnnek a frissts gondolatval
kacrkodni. (Br valsznleg inkbb be fogjk szerezni a Trumpet Winsock IPv6ot.)
Ezzel a kliens oldal rendben is lenne. De ott vannak mg a szerverek s a hlzati
eszkzk. Rossz hrem van: a Windows Server 2000 e tekintetben elg gzos.
Amennyire tudom, nem erszakolhat meg. Viszont Windows Server 2003-tl felfel
mr minden rendben. A hlzati eszkzk cserje meg pusztn csak elszntsg s
pnz krdse.
IPv6 Microsoft rendszerekben:
http://www.windowsnetworking.com/articles_tutorials/IPv6-Support-Microsoft-Windows.html
Akkor mr vgeztnk is volna? Ht, a sajt kis szemtdombunkon j esllyel igen. Be

mernnk rakni IPv6 only munkallomst? Mirt ne? s szervert? Tuti, hogy a
vezrigazgat egyik fontos klss kapcsolata fog elhasalni, amikor be akar
vpenezni. DMZ-be webszervert? DMZ szlre tzfalat, routert?
Nagyjbl ezek a fenntartsok lteznek ez interneten is. Jelenleg egyre tbb az
IPv4/IPv6 host - de azrt szerverben, hlzati eszkzben mg nagyon btor az, aki
IPv6 only hostot tesz elrhetv.
Pedig a helyzet annyira nem is remnytelen. Mit saccolsz, ha van egy IPv4/IPv6
munkallomsod, egy IPv4/IPv6 router mgtt, mely router mr kzvetlenl
csatlakozik az internetre - s el akarsz rni egy IPv6 only webszervert, mely eltt egy
IPv4/IPv6 router van... sikerlni fog?
4.61. BRA IP V 6 ONLY WEBSZERVER ELRSE I
Igen.
69
Ne rhgj, tudom, hogy nlatok is van.
~ 215 ~

A kulcs a csatornzs, azaz a tunneling. Hol jn be a kpbe az ismeretlen faktor? Ht
az interneten. Jelenleg akkor kapunk jobb eredmnyt, ha az internetet IPv4 only
hlzatnak felttelezzk.
4.62. BRA IP V 6 ONLY WEBSZERVER ELRSE II
Ekkor az trtnik, hogy a kt router kztt ltrejn egy csatorna - IPv6-over-IPv4

Tunneling - melyen keresztl az IPv6 csomagok IPv4 csomagokban utaznak t.
Hogyan is kell ezt elkpzelni? Elveszek fizikailag egy vakondot. felhzom kulccsal,
belltom a megfelel irnyba - s mr frja is az utat az interneten keresztl?
Nyilvn nem. Hogyan is lehetne rtelmezni, hogy elkezdnk alagutat frni egy olyan
megfoghatatlan valamibe, mint az internet?
Sokkal inkbb arrl van sz, hogy a megszokott csomagszerkezetbe valamelyik jl
meghatrozott ponton berakunk egy plusz csomagolst.
4.63. BRA IP V 6- OVER -IP V 4 T UNNELING
~ 216 ~

Amit gy becsomagoltunk, azt megvtuk attl, hogy tkzben brki piszklja. Ez a
plusz csomagols lehet autentikcis fejlc, lehet titkosts (ksbb ltunk
mindegyikre pldt) - s lehet egyszeren inkompatibilis informcikat elrejt
csomagols.
Hogyan keletkezik egy ilyen csatorna?
Vagy magunkat nem kmlve kemny fizikai munkval ltrehozzuk.
Vagy automatikusan keletkezik, felismerve, hogy itt bizony csatornzni kell.
Mikortl tekinthetnk kipltnek egy csatornt? Nagyon egyszer: ha a kt
vgpontja beazonostotta magt s ltrejtt kztk a kapcsolat. A legszebb az
egszben, hogy ennyi elg is. Teljesen mindegy, hogy a kt vgpont kztt mennyit
bklsznak a csomagok. Az se rdekel senkit, hogy odafel ms tvonalon megy a
csomag, mint visszafel. Csak odarjen.
Azrt az megr mg egy gondolatfutamot, hogy mi is ez a beazonosts? Melyik
cmket hasznljk a hdfllsok a csatorna kiptshez?
Brmilyen meglep is, az IPv4 cmket. Teht amikor manulisan ptnk ki egy
IPv6-over-IPv4 csatornt, akkor a kt vgpont IPv4-es cmeit kell megadnunk.
Viszont a csatornn mr IPv6 forgalom fog keresztlfolyni, ahol a csatorna egy plusz
routingot, egy plusz ugrst jelent. Ez viszont azt jelenti, hogy a csomagok
tovbbtsakor mr a hdfllsok IPv6 cmei fognak szmtani.
4.64. BRA C SATORNAPTS MANUL ISAN
Szz eszmefuttatsnl is tbbet r egy konkrt plda. Van neknk egy IPv6
alhlzatunk Kazincbarcikn (1a04:ff1:1::/64) s van egy msik New Yorkban
(1a04:ff1:2::/64). A kt alhlzatot szeretnnk sszektni az interneten keresztl.
Mindkt alhlzatban zemel egy-egy Windows Server 2008, melyeket routerknt
hasznlunk. (Tudom, nyakatekert a dolog, de ez alapveten egy Windows knyv, n
pedig nem akarok belemenni router clhardver konfigurlsba. Nem is tudnk.)
~ 217 ~

rtelemszeren mindkt szervernek vannak IPv4 s IPv6 cmei is - de a jelen
pldban csak az internet fel fordul IPv4 cmk a lnyeges.
Els lpsben ptsk fel a csatornt Kazincbarcika fell:
netsh interface ipv6 add v6v4tunnel ToNewYork 82.145.1.240 135.11.5.1
Msodik lpsben ptsk fel a csatornt New York fell:

netsh interface ipv6 add v6v4tunnel ToKazincbarcika 135.11.5.1 82.145.1.240
Mint lthat, a csatorna kiptshez a hdfllsok IPv4 cmeit hasznltuk.

Most mr csak meg kellene mondani a routereknek, hogy merre vannak az egyes
IPv6 alhlzatok. Ezt megtehetnnk a korbban mr emltett 'route add' paranccsal
is, de a sorminta kedvrt legyen most ez is netsh-val.
Kazincbarcika:
netsh interface ipv6 add route 1a04:ff1:2::/64 ToNewYork
New York:
netsh interface ipv6 add route 1a04:ff1:1::/64 ToKazincbarcika
s kszen is vagyunk.
Egy gondolatkisrlettel nzzk meg, mit is csinltunk.
New York-bl szeretnk elrni az egyik kazincbarcikai gp fjlmegosztst.
Kazincbarcikn csak IPv6only hostok vannak, teht az IPv4 szba sem jhet.
A kazincbarcikai gp IPv6 cmt valahogy (DNS, host fjl) megtudjuk. Megprblunk
rkapcsoldni. Elkszl a SYN csomag, elindul. A default gateway-knt is mkd
routerbe pp nemrg gettk bele, hogy a kazincbarcikai IPv6 cmtartomny
(1a04:ff1:1::/64) esetben melyik adaptert hasznlja: ez a ToKazincbarcika
adapter. A router szpen becsomagolja IPv4 csomagba az IPv6 csomagot s elkldi
az IPv4-es csatornn Kazincbarcikra. Az ottani router lehntolja a kls IPv4
csomagolst, az IPv6 csomagot pedig mr el tudja kldeni a helyi gpnek az IPv6only
hlzaton.
J, most mr ismerjk a manulis csatornaptst. Hogyan nz ki akkor az
automatikus?
Els krds: milyen entitsok kztt van rtelme automatikus csatornaptsrl
beszlni? Nyilvn nem routerekrl van sz, mert azokat a szakik manulisan
konfigurljk. De mi van akkor, ha egy host akar csatornzni egy msik host-tal, vagy
~ 218 ~

egy routerrel? Elvrhat-e Mari nnitl a brszmfejtsen, hogy kiptsen egy IPv6over-IPv4 csatornt az anyavllalatnl ldgl Auntie Mary gpvel?
Klti krds volt.
Ilyenkor maga az opercis rendszer pti ki automatikusan a szksges csatornt.
Mik a felttelek?
Mindkt host IPv4/IPv6 host legyen.
Ismerjk a tvoli host IPv4 cmt.
A szituci:
Az egyik IPv4/IPv6 hostrl (Mari nni) el szeretnnk rni egy msik IPv4/IPv6
hostot (Auntie Mary), IPv6 protokollon keresztl. A kett kztt viszont ott feszl
valahol egy IPv4 only hlzat.
Lthat, a csatornt ki tudnnk pteni, hiszen megvannak az IPv4 cmek. De nem
tudunk semmit a tvoli host IPv6 cmrl.
Illetve, dehogyisnem.
Host Name
Primary Dns Suffix:
Node Type
IP Routing Enabled
WINS Proxy Enabled
:hq
: Hybrid
: No
: No

Connection-specific DNS Suffix . :
Description
Realtek RTL8168B/8111B Family PCI-E Gigabit Ethernet NIC
(NDIS 6.0)
Physical Address
: 00-1E-8C-AB-2F-88
DHCP Enabled
: Yes
: Yes
: fe80::c5cc:1c5c:8384:4546%8(Preferred)
IPv4 Address
: 192.168.1.101(Preferred)
Subnet Mask
: 255.255.255.0
Lease Obtained
: 2008. jnius 3. 19:14:09
Lease Expires
: 2008. jnius 4. 19:14:08
Default Gateway
: 192.168.1.1
DHCP Server
: 192.168.1.1
DHCPv6 IAID
: 201334412
DNS Servers
: 84.2.44.1
84.2.46.1
NetBIOS over Tcpip
Enabled
~ 219 ~

Description
:
Physical Address
:
DHCP Enabled
:
:
IPv6 Address
:
:
Default Gateway
:
NetBIOS over Tcpip
:
. :
02-00-54-55-4E-01
No
Yes
2001:0:d5c7:a2ca:3c2f:2bc6:3f57:fe9a(Preferred)
fe80::3c2f:2bc6:3f57:fe9a%9(Preferred)
::
Disabled

Description
:
Physical Address
:
DHCP Enabled
:
:
:
Default Gateway
:
DNS Servers
:
NetBIOS over Tcpip
. :
00-00-00-00-00-00-00-E0
No
Yes
fe80::5efe:192.168.1.101%10(Preferred)
84.2.44.1
84.2.46.1
: Disabled
Ez a szmtgpem IP konfigurcija. (ipconfig -all) Megeskszm brmire, hogy

csak egy hlzati krtym van - mgis a listban hrom interface ltszik.
A pirossal jelltek ugyanis nem fizikai krtyk. Ezek klnbz - automatikus csatornatipusokhoz (Teredo, Isatap) elksztett interface-k. Kzs tulajdonsguk,
hogy a hozzjuk tartoz IPv6 cm egy rgztett algoritmus alapjn generldik az
IPv4 cmkbl, azaz a felad is ki tudja szmolni ezeket.
~ 220 ~
4. 2 .2 . 1 I N T R A -S I T E A U T O M A T I C T U N N E L A D D R E S S I N G P R O T O C O L , IS AT A P
RFC 4214
A nevbl is ltszik, hogy ez a csatornzs csak site-on bell mkdik. Brmennyire
is szomor, de Mari nni s Auntie Mary nem ezt a technikt fogjk hasznlni az
interneten keresztli csatornaptshez. A keletkez IPv6 cm nem lesz globlis.
Az algoritmus:
Mivel link-local cm lesz belle, gy az els 64 bit adott: fe80::/64.

A node azonost egy kicsit cifra:
Ha az IPv4 cmem publikus IP cm, akkor ::200:5efe:w.x.y.z.
Ha az IPv4 cmem privt, akkor
::0:5efe:w.x.y.z.
Ahol w.x.y.z az IPv4 cm oktettjei.
Ellenrizzk le a sajt gpem adataival:

IPv4 cm: 192.168.1.101
Isatap cm: fe80::5efe:192.168.1.101
Stimmel.
Esetleg gondot okozhat a kvetkezetlen rsmd.
Mi az, hogy fe80::5efe:192.168.1.101? Hogyan kerltek hirtelen a cmbe
pontok? Nem kell ktsgbe esni, ezt csak a szemlletessg kedvrt rjk gy.
Akit zavar, az legfeljebb gyorsan tszmolja az IPv4 cmt hexadecimlisba
(c0a8:165) s gy rja fel az Isatap cmet: fe80::5efe:c0a8:165.
Ez a legegyszerbb csatornzs, de a lnyeg remekl ltszdik. Ha n egy IPv4/IPv6
host vagyok s kldeni akarok egy msik IPv4/IPv6 hostnak egy IPv6 csomagot,
mikzben az tviteli kzegknt funkcionl hlzat csak IPv4-es, akkor a cmzett
IPv4 cmbl tudni fogom az ISATAP csatornjnak a vgponti cmt - s mr
indulnak is az ptipari vakondok kipteni a csatornt. Amint az megvan, mehet a
korbban emltett IPv6-over-IPv4 Tunneling.
~ 221 ~
4. 2 .2 . 2 6T O4
RFC 3056
Ennl az automatikus csatornatpusnl mr unique-global cmet kapunk. Azaz
elmletileg Mari nni s Auntie Mary mr kpesek lennnek ezt a csatornt
hasznlni. De csak elmletileg. A csatornnak van ugyanis egy kellemetlen felttele:
nem lehet tkzben cmfordt (natol) hlzati eszkz. Ms szval, a
hdfllsoknak publikus IP cmekkel kell brniuk - mrpedig ha a kt ltes hlgy
cges hlzatban dolgozik, akkor ez valsznleg nem ll.
De azrt nzzk meg, hogyan generldik ennl a tipusnl az automatikus cm.
Mivel unique-global cmrl van sz, a kpzse is hasonl.
Lesz egy 48 bites prefix: 2002:w.x.y.z
16 bit site azonost
64 bit node azonost.
Mint emltettem, ha a hostnak privt IP cme van, akkor nem generldik 6to4 cme,
gy az n gpemnek sincs.
Csak a plda kedvrt kpzeljk el, hogy dafke generlok magamnak 6to4 cmet.
Legyen a site azonostm: c01d. Ekkor a kvetkez 6to4 cmet kapnm:
2002:c0a8:165:c01d: c5cc:1c5c:8384:4546.
(A node azonostt a link-local cmbl lehet kiolvasni.)
Gondolom, ltszik a bukta: mivel a prefix kpzshez az IP cmemet hasznltuk s az
nem publikus cm, gy egyltaln nem garantlja semmi sem, hogy az egyedisget
biztost prefixem vilgmretben tnyleg egyedi is lett. Azaz dafke ide vagy oda, nem
tudnm biztonsgosan hasznlni.
Ennl a csatornatpusnl is az IPv6-over-IPv4 kapszulzst hasznljuk.
~ 222 ~
4. 2 .2 . 3 TE RE DO
RFC 4380
Itt is unique-local cmeket kapunk - s ez a csatorna mr thidalja a cmfordtsokat
is. Igen, ez az, melyet vgre becsletben megszlt kollganink is tudnak majd
hasznlni.
Szakemberknt viszont azt kell mondjam, ez a legbonyolultabb eljrs.
Kezdjk ott, hogy nem a megszokott IPv6-over-IPv4 kapszulzst hasznlja. Annak
ugyanis volt egy kellemetlen tulajdonsga: az IPv4 csomagban, amikor jelezni
akartuk, hogy milyen protokollt is tartalmaz a payload, azt mondtuk, hogy
protocol41, azaz IPv6. Ettl viszont a legtbb tzfal eldobja az agyt. Meg a
csomagot.
A Teredo ravaszabb egy kicsit: IPv4-en belli UDP csomagba kapszulzza be magt,
gy mr srtetlenl tsuhan a kerberoszok mellett.
Fontos, hogy a Teredo csatornk kiptshez nem elg a kt vgpont. Szksg van
nmi segtsgre is, mgpedig a megfelel IPv6 cmek kiszmolshoz. (Ne felejtsk
el, privt cmekbl kpeznk unique-global cmeket.) Ezt a segtsget egy n. Teredo
szerver biztostja a vgpontoknak, azaz a Teredo klienseknek. (Emellett a szerver a
kommunikci beindtsnl is segdkezik.)
Honnan szerznk ilyen szervert? Van. Legyen elg ennyi. A Microsoft zemeltet ilyen
szervereket valahol a felhben, az opercis rendszerei pedig hasznljk a
szolgltatsaikat, anlkl, hogy kln rtestennek rla minket.
Ennyi bevezets utn nzzk, hogyan keletkezik egy Teredo cm.
70
Kezdnk egy 32 bites prefix-szel. Ez abszolt konstans, az rtke

2001:000070.
Itt jn a Teredo szerver IPv4 cme, szintn 32 biten.
16 bitnyi flag. Ebbe most nem mennk bele.
Megkutyult kls port. 16 bit.
Megkutyult kls cm. 32 bit.
Ltod, ugye, hogy global unique?
~ 223 ~

Ht, iz. Ebbl egyedl a konstans rthet elsre.
Viszont van egy l Teredo cmnk, ott vigyorog a pr oldallal korbbi listban:
2001:0:d5c7:a2ca:3c2f:2bc6:3f57:fe9a
Analizljuk sznn.
Az els 32 bit ok, az a konstans.
A msodik 32 bit mr izgalmasabb. D5c7:a2ca, visszaszmolva decimlisba:
213.199.162.202. az anyuka kis segtje, a Microsoft httrben sernyked Teredo
szervere71.
A kvetkez blokk rtke 3c2f, ez flag formra alaktva: 0011110000101111. Ha
nem haragszol, ezt nem rszletezem. (Az RFC-ben szpen le van rva.)
Aztn megynk bele a mlnsba. A kls port azt az rtket jelenti, amelyre a NATnak fordtania kell az UDP kommunikcit. Ezt az rtket a Teredo szerver adja. A
megkutyuls pedig azt jelenti, hogy a tnyleges rtket lekizrvagyozzk (XOR72) a
0xFFFF rtkkel. Ezzel bizonyos NAT implementcikat vgnak t. Jelen esetben az
rtk 2bc6, ezt visszaxorozzuk, akkor azt kapom decimlisban, hogy 32686.
A kls 32 bites cm pedig egy publikus IP cmet fog adni. Ezzel az IP cmmel - s az
elzekben kiszmolt port rtkkel - fogok megjelenni a natol linksys routerem
kls feln. A kutyuls elve ugyanaz, csak mivel most 32 bites szmot xorozunk, gy
a konstans a 0xFFFFFFFF szm lesz. Szmoljuk ezt is vissza: 3f57fe9a xor FFFFFFFF,
az annyi mint C0A80165, ez IPv4 formtumba alaktva 192.168.1.101.
Hopp. Itt valami ruls trtnt. Kls cmknt ugyanazt a cmet kaptam vissza, mint
ami a bels, privt IP cmem - pedig itt egy publikus IP cmet kellett volna tallnom.
Leellenriztem.
Nem fix IP cm, vltozik. Hivatalosan a teredo.ipv6.microsoft.com cmen tallhat az aktulis

Teredo szerver.
71
72
0
0
1
1
A kizr vagy (XOR) igazsgtblja:

0
->
0
1
->
1
0
->
1
1
->
0 (Ez miatt kizr.)
A mveletnek van egy rdekes trkkje: ha tetszleges szmot xorolunk egy szmmal, majd a mvelet
eredmnyt xoroljuk ugyanazzal a szmmal, akkor az eredeti szmot kapjuk vissza. rthetbben: (A
xor B) xor B = A.
~ 224 ~

Elindtottam a Wireshark programot, majd menetkzben megvltoztattam az IP
cmemet. Nos, a Vista tbbszr is lekrdezte a teredo.ipv6.microsoft.com cmet - de
semmit nem kommuniklt vele. Ebbl arra kvetkeztettem, hogy a fenti rtkeknek
egyelre nincs jelentsge. Amikor elszr prblok majd meg Teredo csatornt
pteni valahov, valsznleg akkor kapom csak meg az igazi port, illetve IP cm
rtkeket.
Mivel az IPv4-IPv6 konverzik kzl messze ez a leghasznlhatbb, st, mi tbb, egy
tlagos krnyezetben ez az egy lesz hasznlhat, rdemes a Teredo csatornzsban
jobban elmlylni.
Kezdjk a sors fintorval. A korbbi kiadsokban azt rtam, hogy a Teredo szerver
semmilyen Microsoft termknek nem lesz rsze.
Aztn kijtt a Windows Server R2.
Amelyikben mr van Teredo szerver s Teredo Relay is. (Teredo kliens mr a
Vistban is volt.)
4.65. BRA T EREDO RENDSZER ELEME I
Az brrl leolvashat, hogy a NAT mgtti Teredo kliens vagy egy Teredo relay-n,
vagy egy Teredo host-specific relay-n keresztl tud kommuniklni a tloldali Teredo
klienssel, illetve IPv6 node-dal. A Teredo szerver a csatorna kiptshez kell (ez
oszt IPv6 cmet s indtja be a kommunikcit.) A Windows Sever R2 eltt mind a
~ 225 ~

Teredo szervert, mind a Teredo relay-t a Microsoft adta (valahol a felhben), illetve
megadta a lehetsget az ISP-knek sajt Teredo eszkzk teleptsre.
A Windows Server R2 megjelensvel annyi vltozott, hogy mi is zemeltethetnk
Teredo szervert s Teredo relay-t sajt magunknak. A Windows Teredo kliensek
helybl ugyan a teredo.ipv6.microsoft.com cmre vannak bedrtozva, de ezt a netsh
segdprogrammal tudjuk mdostani. (Illetve csoporthzirendbl.)
Cable Guy
http://technet.microsoft.com/en-gb/magazine/2009.07.cableguy.aspx#id0270013
~ 226 ~
A SZLLTSI RTEG PROTOKOLLJAI
5 A SZLLTSI RTEG PROTOKOLLJAI

Megvagyunk a cmzsekkel s az tjelz tblkkal. pp itt az ideje, hogy a szekrrel
is foglalkozzunk.
De melyikkel? Hiszen kett kzl is vlaszthatunk: van egy Trabantunk s egy
Volvnk.
5.1 U SER D ATAGRAM P ROTOCOL - UDP

RFC 768
a Trabant. Hogy mirt?
Kapcsolatmentes. A felad s a cmzett nem beszlgetnek: a felad elkldi a

csomagot, a cmzett vagy megkapja, vagy nem. De semmilyen formban sem
jelez vissza.
Megbzhatatlan. A csomagokban nincs semmi sorszmozs, nincs semmi
elveszs elleni vdelem. UDP esetben minden ilyesmit arra az alkalmazsra
bznak, amelyik kldi/fogadja a csomagokat. (CRC ellenrzs ugyan van, de az
csak sztlan csomageldobshoz vezet.)
Nem trol. Ahogy berkezik egy UDP csomag, az rgtn megy is tovbb az
alkalmazs rteg fel. Ha az nem veszi t, akkor gy jrt.
Nem trdel. Trdeljen helyette ms. (Ezt mondjuk megteszi az IP rteg.)
Nincs benne folyamatszablyozs. Azaz nem tud se gyorstani, se lasstani.
Hagyomnyos. A megszokott dobozols technolgit kveti.
Szval, fapad. Cserbe egyszer, mint a tgla, nem rakdik risi vzfej header a
csomagokra s a kisr kommunikci hinya miatt gyors is.
Hogyan is rtk anno a Trabant kezelsi kziknyvben?
"A Trabant tfekvse kitn, s gyorsulsa kifogstalan.
Ez azonban nem szabad, hogy knnyelmsgre csbtson."73
73
Az irodalomba temelve Esterhzy Pter ltal.
~ 227 ~

A teljessg kedvrt emltsnk meg nhny pldt a hasznlatra.
A DNS nagyon j plda, ugyanis az vegyesen hasznl UDP-t, illetve TCP-t. Ha
elfr az zenet egy UDP csomagban - tipikusan nvfeloldsi krs, illetve
vlasz - akkor az UDP lesz a befut. Ha tbb csomagra lesz szksg - tipikusan
znatranszfer - akkor viszont a TCP.
Van, amikor maga az alkalmazs szint protokoll foglalkozik a csomagok
szlltsnak megbzhatsgval. Ilyen pl. a TFTP.
Van, amikor a felad periodikusan kldi el az informcikat. Ilyenkor nem
gond, ha az egyik kldemny nem rkezik meg, hiszen hamarosan megy a
msik. Ezt tudja a korbban mr emltett RIP.
Vgl a multicast. A TCP csak egy-egy tipus kapcsolatot tud kezelni.
Az UDP protokoll:
http://en.wikipedia.org/wiki/User_Datagram_Protocol
Aki figyelmesen olvasta eddig a knyvet, nyilvn nem fog meglepdni a kvetkez
brn.
5.1. BRA A Z UDP ZENET HELYE A CSOMA GBAN
Szpen lthatak az egyes rtegek, lthat, hogy ami az egyik rtegnek payload, az a
msikon bell tovbb oszlik header+payload darabokra - s gy tovbb.
~ 228 ~
5.2. BRA A Z UDP H EADER
SOURCE PORT: Azt a portot azonostja, amelyiken az alkalmazs elkldte a csomagot.

DESTINATION PORT: Azt a portot tartalmazza, amelyiken a fogad oldali alkalmazs
fogadja a csomagot.
LENGTH: Az UDP csomag mrete. Minimum 8 bjt (ekkor csak a header van),
maximum... na, mennyi? Mivel a LENGTH 16 bites, gy maximum 65535 bjt lehet.
CHECKSUM: A j reg CRC.
Nzzk meg mindezt a gyakorlatban is.
Az nslookup index.hu parancs hatsra a kvetkez trtnt.
5.3. BRA UDP CSOMAG FELPTSE
~ 229 ~

Szpen ltszik az UDP header s alatta az UDP message is.
Ez egy szp, tiszta protokoll, az gegyadta vilgon semmi kavars nincs vele.
Vagy mgis?
Ekkor futottam bele az UDP Pseudo Header fogalomba.
Nem trflok, egy csom idt foglalkoztam vele, ttrtam a fl internetet. Mi az, hogy
pszeud? Most akkor van? Ha igen, akkor hol? Az UDP zenetben? De hiszen ott
nincs. Az IP csomagban? Ott sem volt. De ha nem ltezik, akkor meg mirt emlegetik?
Nos, hosszas kutatsok utn meglett a vgs megolds.
Az UDP Pseudo Header ltezik is... meg nem is.
J, mi?
5.4. BRA UDP P SEUDO H EADER
Errl a szerkezetrl van sz. Vizsgld meg alaposan a korbbi brt (5.3. bra UDP
csomag felptse) Ltsz valahol a capture fjlban ilyen szerkezetet? Ugye nem.
Pedig ott van.
Csak darabokban. Ott van ugyanis a Source IP Address, a Destination IP Address s a
Protocol az IP fejlcben, a Length pedig az UDP fejlcben. (Az Unused bjt csak
padding clt szolgl.)
Nos, ez a szerencstlensg azrt pszeud, mert kln nem utazik a csomagban,
hanem a csomag egyb mezibl rakja ssze a kld/fogad host.
Jogos a krds, hogy mi szksg lehet r?
~ 230 ~

Ez a kapocs. Ez fogja ssze az IP headert s az UDP zenetet. Mghozz gy, hogy a
korbban nagyvonalan elintzett CHECKSUM meznl nem rultam el, mely mezk
is vesznek rszt az ellenrz sszeg generlsban. Nos, egsz konkrtan az UDP
Pseudo Header s a teljes UDP csomag, belertve a fejlcet s az zenetet.
(Logikusan, ahogy vltoznak az IP csomag adatai - pl. a Destination IP Address - vagy
natols miatt az UDP portszmok, a CHECKSUM mindig jraszmoldik.)
Felmerlhet mg egy krds: mi van a multicastnl? Akkor hogyan is kezeljk ezt a
CHECKSUM mezt? A vlasz az, hogy UDP esetben a mez hasznlata opcionlis, ha
zr az rtke, akkor senki nem foglalkozik vele.
Meg mg egy krds: s az IPv6? A vlasz az, hogy igen. Nyilvn be fog jtszani:
egyfell a pszeudo header vltozni fog (nemcsak a nagyobb IP cmek miatt, de a
mezk sem lesznek ugyanazok), msfell IPv6-ban mr ktelez a CHECKSUM mez
hasznlata.
The Checksum field and the UDP Pseudo Header:
http://www.tcpipguide.com/free/t_UDPMessageFormat-2.htm
~ 231 ~
5.2 T RANSMISSION C ON TROL P ROTOCOL - TCP

H, ki jul el,
ha meglt egy Volgt?
H, ki ltta mr
a Zaporozsec szobrt?
Ki az az rlt, ki Trabantra vgyik,
taln csak egy mzeum.
Kerljn inkbb valamivel tbbe,
manapsg ez a minimum.
Volvo!
Volvo!
Volvo!
A KFT szsszenettl eltren azrt van rtelme a Trabantnak (illetve a manapsg

helyette hasznlt fapados jrgnyoknak) s persze megvan a funkcija a Volvnak is.
Csak ppen az utbbinak meg is kell fizetni az rt.
RFC 793
Nzzk, mit is tud a luxuskategria?
Kapcsolatcentrikus. No, nem gy, mint egy iwiw-fgg plzacica, hanem

gy, hogy mieltt brmekkora darabot is elkldene a rbzott adathalmazbl,
kipt egy kapcsolatot a kld s a fogad kztt, majd klds kzben polja
is ezt a kapcsolatot.
nmegtartztat. Mind kld, mind fogad oldalon kpes a kldsi sebessg
szablyozsra.
Ktirny. Ugyanazon a kapcsolaton egyszerre mehet mindkt irny
forgalom.
Megbzhat. Az adatfolyam darabki szmozottak s mindegyiket leltr
szerint t kell vennie a fogadnak. Ha ez nem trtnik meg, akkor a felad
jra elkldi.
Trhetetlen. A TCP rteg kpes kommuniklni a Network Interface rteggel,
gy az MTU ismeretben akkora adagokat kr az alkalmazsi rteg adataibl,
hogy azokat ksbb IP szinten ne kelljen trdelni.
Monogm. A kapcsolatot csak kt host kztt tudja kipteni.
Folyamatos. Az tvitel adatfolyam (stream) jelleg. Ezrt mondjuk azt, hogy
a TCP payload az szegmens s nem datagram. (Ettl fggetlenl persze a
stream darabjai csomagokban - IP datagram - utaznak.)
~ 232 ~

Cserbe egy kicsit brokratikus. Na j, nem kicsit. Ez a rengeteg oda-vissza szl
vezrlinformci, a kapcsolat menedzselse nem megy ingyen - svszlessggel,
processzoridvel, memrival fizetnk rte. rtelemszeren akkor clszer
hasznlni, ha kiemelten fontos a megbzhat adattovbbts.
Most egy kicsit elkalandozok a megszokott trgyalsi mdtl. Egy valloms
kvetkezik.
Mikzben rtam ezt a knyvet, meglehetsen linerisan
tanuls/megemszts/megrs vonalon. Nekifut, dobbant, elugrik.
Ez a linearits itt, ennl a rsznl torpant meg.
haladtam
A parszerem nem brt megbrkzni a TCP stream jellegvel. A j g ldja meg, hiszen
eddig itt mindent dobozoltunk. Hogyan mondhatjuk ki egy alapveten diszkrt
doboz tartalmra, hogy az folyamatos adatram?
Napokig olvasgattam, trtam a netet.
Aztn hagytam a fenbe az egszet, hirtelen kzbejtt egy csom egyb problma.
Hrom nap mlva ltem le megint a kzirathoz - s nem rtettem, mit nem rtettem
korbban. Az agy egy hihetetlenl rdekes szerkezet.
Plda. Egyszeren gy kell elkpzelni a dolgot, hogy mondjuk szp lassan
hmplyg a Duna. Igenm, csakhogy a Vaskapunl zembelltottak egy gtat, arra
szereltek egy futszalagot, mely csak dobozokat kpes szlltani. A futszalag elejn
a szakik villmgyorsan bedobozoljk a vizet, rfirkantanak egy azonost szmot s
mr mehet is a szalagra. A tloldalon pedig sorbarendezik a dobozokat a szmok
alapjn, kibortjk bellk a vizet, az res dobozra rrjk, hogy a csomag rendben
megrkezett, majd visszakldik a futszalag elejre.
A Duna a futszalag eltt a felad alkalmazs, a Duna a futszalag utn a fogad
alkalmazs. A futszalag pedig maga a hlzati infrastruktra.
J-j, de mirt tennnek ilyen rltsget a romn vzgyes szakik?
Nos, innentl sntt a hasonlat. Javaslom, trjnk is vissza az informatika vilgba.
Itt a krds mshogyan hangzik el: krem szpen, hogyan is lehetne mskpp?
~ 233 ~

Gondoljunk bele: eddig minden rteg ismert, jl definilt rtegtl vette t az
informcit tartalmaz dobozt. Szabvny szerint tudtuk, hogy az IP csomagban a
payload csak ICMP/IGMP, illetve a Transport rtegtl szrmaz csomag lehet. Ms
nem. Mintha minden tipusnak lenne egy ms beoszts fakkos doboza.
De a szegny, szerencstlen TCP-nek mr az alkalmazstl kell elvennie az
informcit. Azt kellene szpen fakkokra osztott dobozba raknia. Tudnnk annyi
fajta fakkos dobozt hasznlni, ahny fle alkalmazs van? Mg akkor sem, ha csak
kommunikcis szabvnyokra pl alkalmazsaink lennnek. Mihez kezdennk
akkor egy egyedi alkalmazssal, mely mondjuk az 1964-es porton a sajt egyedi
protokolljn keresztl kommunikl? Remnytelen. Egsz egyszeren nincs rtelme
annak, hogy a TCP protokoll nekilljon parszolni a belje rkez informcit.
Egyszeren fog egy res dobozt, beleszrja az rkez folyam bitjeit s tovbblki azt
az IP rtegnek. Majd parszol a tloldalon lv alkalmazs - feltve, hogy megkapott
minden dobozt.
Ok. De mi van akkor az UDP-vel? Az is szlltsi protokoll... s mgsem stream.
Hogyan tudja megugrani az a cseles UDP ezt az akadlyt?
gy, hogy az UDP zenet belefr egy csomagba. Egyszeren muszj7475 neki, mivel
UDP-n bell nincs sorszmozs, nincs visszajelzsi mechanizmus. Termszetesen az
UDP sem fogja parszolni a megkapott zenetet. (Szpen is nznnk ki, ha mondjuk a
DNS Name Query Response megvltoztatsa magval vonn az UDP szabvny
megvltoztatst is.)
Nzzk meg ezt kt brn.
74
75
muss sein
Eddig brtam fken tartani a npmvelt.
~ 234 ~
5.5. BRA E GY UDP CSOMAG
Az UDP csomag teljesen ki van bontva. Lthat, hogy a csomagban lv informci

teljes, a monitoroz szoftver parszere kpes volt rtelmezni.
gy is mondhatnm, hogy az UDP tulajdonkppen egy annyira rvid stream, hogy
belefr egy csomagba. Ezrt diszkrt.
~ 235 ~
5.6. BRA E GY TCP CSOMAG
Itt viszont megfekdt a Wireshark parszer. Ugyanis a TCP szegmensben egy

adatfolyam egy darabja utazott, melyet nllan kptelen volt rtelmezni. Lthat,
hogy csak annyit tudott rmondani, hogy ez egy TCP szegmensnek az adata. Alul, a
Packet Bytes rszen pedig ltjuk, hogy ez valami j nagy zagyvasg. Szerencsre nem
is neknk szl, hanem a tloldali alkalmazsnak.
TCP:
http://en.wikipedia.org/wiki/Transmission_Control_Protocol
~ 236 ~

Vgl lljon itt egy sszefoglal tblzat a ktfajta szlltsi protokollrl:
5.1. TBLZAT
Kapcsolat
Megbzhatsg
Puffer
Trdels
Folyamatszablyozs
Tbbnejsg
Sebessg
Hatkonysg
UDP
Kapcsolatmentes.
A felad elkldi a csomagot, a cmzett
megkapja. Ezen a tranzakcin kvl semmit
nem beszlgetnek.
Megbzhatatlan.
A kld/fogad alkalmazsokra bzza,
hogy vegyk szre a csomagvesztst.
Nincs.
A kld alkalmazs egybl kldi a
csomagot s az ahogy megrkezik, egybl
megy is tovbb a fogad alkalmazshoz..
Nincs.
Az UDP kln nem foglalkozik vele. Ha a
csomag nagyobb lett az MTU-nl, akkor
majd trdel az IP rteg. A maximlis
mrete 64 KB.
Nincs.
Nem tudja rzkelni, hogy dug van s
lasstania kellene. Hasonlkppen azt sem,
hogy szabad a plya, lehet gyorstani.
Poligm
Kpes a pont-multipont kapcsolatra.
Multicast kommunikcinl csak UDP
jhet szba.
Gyors
Mivel nincs benne ez a sokfajta vdelem,
meg ellenrzs.
J
A csomagok tartalmhoz kpest nem tl
nagy a vzfej.
TCP
Kapcsolatcentrikus.
Mg a tnyleges adatklds eltt a felek
kiptenek egy kapcsolatot s azt poljk
is.
Megbzhat.
Az adatfolyam darabjai szmozottak s
azokat leltr szerint t kell vennie a
fogad flnek.
Van.
Mind kld oldalon, mind fogad oldalon
ltezik egy tmeneti trolhely, mely
segt a csomagok elrendezsben.
Van.
A TCP kpes kommuniklni az IP
rteggel s a csomagok sszeraksnl
figyelembeveszi az MTU rtkt.
Van.
Rendszeresen
mri
a
csomagok
berkezsi idejt s ehhez hangolja a
sebessget.
Monogm
Csak
pont-pont
kapcsolatra
j,
multicasthoz hasznlhatatlan.
Lass.
Mivel ebben viszont benne van az a
sokfajta vdelem, meg ellenrzs.
Gyenge
Mind a csomagok fejlct, mind az extra
elkldtt csomagokat tekintve nagy a
vizfej.
~ 237 ~

Ok, trjnk vissza a megszokott, bitbvr mederbe.
Nzzk meg, hol is helyezkedik el a TCP a nagy csomagon bell.
5.7. BRA A TCP SZEGMENS ELHELYEZKEDSE A CSOMAGBAN
s akkor a TCP fejlc.
5.8. BRA A TCP FEJLC
~ 238 ~

SOURCE PORT: Az a port, amelyikrl a kld alkalmazs kldi a csomagot.
DESTINATION PORT: Az a port, amelyiken a fogad alkalmazs fogadja a csomagot.
Megjegyzs:
A korrekt cm, melynek minden eleme meg kell legyen ahhoz, hogy a csomag
a megfelel helyen landoljon, az az IP cm s a portszm - egytt. Ez egy
annyira fontos elem, hogy kln neve is van: socket. Dacra annak, hogy az IP
cm az IP headerben tallhat, a portszm pedig a TCP/UDP headerben.
Termszetesen kln beszlnk source, illetve destination socket-rl.
SEQUENCE NUMBER: 4 bjt, azonost szm. Mint a neve is mutatja, ez alapjn fogja a
fogad sorbarendezni a csomagokat. Ha a ksbb bemutatand SYN flag rtke
magas, akkor az inicializl csomagrl beszlnk, az ehhez tartoz sorszmot pedig
INITIAL SEQUENCE NUMBER -nek nevezzk. (ISN)
ACKNOWLEDGEMENT NUMBER: Szintn 4 bjt. A neve alapjn ez szolglna a csomag
megrkezsnek
azonostsra.
De
ksbb
ltni
fogjuk,
hogy
a
sorbarendezs/visszajelzs funkcikat a kt szm kzsen, egyttmkdve valstja
meg.
DATA OFFSET: A nvad csoport megint nem volt cscsformban. Ez ugyanis
gyakorlatilag a TCP header mrett tartalmazza76. Persze nem ilyen egyszeren,
hogy odarjuk, oszt annyi: az IP csomagnl megszokott mdon ide a szavak szmt
rjk.
Eddig az ilyen adatokat valamilyen LENGTH nvvel illettk. A TCP-s fik szaktottak ezzel a
szemllettel, k azt mondtk, hogy ez a szm azt jelenti, hogy honnan kezddik a DATA. gy
pontosabb nv r az OFFSET. A lelkk rajta. Az eredmnye a kt megkzeltsnek mindenesetre
ugyanaz.
76
~ 239 ~
5.9. BRA DATA OFFSET
Ezen egyszer gyis tl kell esnnk: nzzk meg, konkrtan hogyan is szmtdik ki
ez az rtk. A Wireshark szolglatkszen mr a vgeredmnyt mutatja, azt, hogy a
header hossza 20 bjt. De mi van legalul? Amikor rllunk a HEADER LENGTH sorra
(melyrl persze tudjuk, hogy ez az igazi Trebitsch a DATA OFFSET), akkor azt ltjuk,
hogy 50. Iz. Ezmiez?
Mivel a Packet Bytes rsznl ltjuk, gy nyilvn egy hexadecimlis rtk. Decimlisra
tszmolva 80 - melynek megint nincs tl sok rtelme. Nem is lehet, hiszen csak mi,
elkorcsosult tzujj emberek szmolunk tizes szmrendszerben. Vltsuk t a szmot
binrisba: 01010000. Ha megnzzk az brt (5.8. bra A TCP fejlc), lthatjuk, hogy
a bjt als fele a RESERVED rtk s ktelezen nulla. Marad a 0101 rtk, mely
egsz pontosan annyit tesz emberl, hogy 5. (Meg hexban is.) Teht ez a szm van
letrolva a mezben. Hogyan lesz ebbl 20? gy, hogy mivel ez a szavak szmt
jelenti, s egy sz az 32 bit, gy a vgeredmny 5*32, azaz 160 bit, azaz 20 bjt.
RESERVED: Mint korbban is kiderlt, ksbbi clokra fenntartott mez, rtke nulla.
RFC 793, 3168
FLAGS: 8 kicsi zszlcska. Szoktk ezeket control biteknek is nevezni. A TCP kapcsolat
kiptsben s kezelsben jtszanak fontos szerepet. Ott is lesznek rszletesen
bemutatva.
WINDOW: Ez tulajdonkppen egy adatmret. Azt mutatja meg, hogy a fogad mekkora
adatkupacot kpes egyszerre elfogadni a kvetkez csomagban. Az rtke nem
lland, a fogad a terhelstl fggen vltoztatja. Ha pldul 0, akkor a fogad
egyelre bezrta az ajtt. Majd szl - kld egy csomagot, nulltl eltr WINDOW
rtkkel - amint jra kinyitott.
~ 240 ~

CHECKSUM: Ellenrz rtk, ahol a kiszmts alapja a TCP header s a szegmens.
Megsgom, itt is hasznlni fogunk pszeudo headert:
5.10. BRA TCP P SEUDO H EADER
Rnzsre teljesen olyan, mint az UDP pseudo header (5.4. bra UDP Pseudo
Header), az egyetlen klnbsg, hogy itt a PROTOCOL mez rtke 6 (TCP), ott pedig
17 (UDP). A szerepe is hasonl: sszekti az IP headert s a TCP headert, gy, hogy a
pszeudo headert is hozzcsapja a TCP header s a szegmens mell, amikor a CRC-t
kiszmolja.
URGENT POINTER: Egy mutat, mely megmutatja, hol van a szegmensen bell
rendkivli srgsggel szlltand adat.
Nem tudod elkpzelni, mi? Elszr n se tudtam. Most akkor mi van? A srgsggel
szlltand adat kitr a dobozbl s beelzi a csomagot?
Majdnem, majdnem.
Lteznek olyan informcik, melyek az adott - alkalmazs szint - protokoll
vezrlshez szksgesek. Ezek az informcik - hiba az adatok kztt utaznak - de
kiemelten fontosak az alkalmazs szempontjbl. Ezeket a vezrl informcikat
szoktk out-of-band adatoknak is nevezni. Ilyesmit ktflekppen lehet sszehozni:
Kln TCP csatorna. Ezt az utat vlasztotta az FTP: van egy adatcsatornja,
ahol hossz tmtt sorokban hmplygnek a bitek s van egy
kontrollcsatornja, ahol a vezrl informcik utaznak.
Egy TCP csatornn utazik minden. Ekkor a vezrl informcikat az Urgent
Pointer hastja ki a szegmensbl. Termszetesen az adat nem fogja beelzni a
csomagot, de amint berkezik a TCP pufferbe, egybl feldolgozsra is kerl.
gy mkdik a Telnet.
RFC 793, 1122
~ 241 ~

A kihastst pedig gy kell elkpzelni, hogy a vezrlinformcik mindig a szegmens
elejn utaznak, a pointer pedig oda mutat, ahol a vezrlinformciknak vge van.
Vagy ahol a nem srgs adatok kezddnek. Itt ugyanis trtnt egy tragikus
flrerts: az egyik RFC az egyiket rta el, a msik a msikat. tjrs nincs: habr a
klnbsg mindsszesen egy bjt, de ez pp elg ahhoz, hogy az egyik
implementci ne ismerje fel a msik ltal kldtt informcit.
A vezrlinformcik kezelshez az URGENT POINTER nmagban nem elg, a
csomagban magasra kell lltani az URG flag-et is. Ez jelzi azt, hogy komolyan
gondoltuk a pointert.
OPTIONS: Az IP OPTIONS mezhz hasonlan ez egy olyan mez, ahov rengeteg
addicionlis funkcit ptettek be. Ezekkel is tallkozni fogunk ksbb.
s most vagyok megint zavarban. Itt volt a msodik nagy megbicsakls az anyag
feldolgozsban. Egyszeren kptelen voltam megrteni a Sequence Number (SN) s
az Acknowledgement Number (ACK) rtkek kztti sszjtkot. Egsz pontosan
nem talltam sem az alanyt, sem az lltmnyt. Nem tudtam, hogy ami trtnik, azrt
trtnik-e, mert a node-oknak szabad akaratuk van, vagy inkbb egymsra
knyszertenek dolgokat? Ha az utbbi, akkor ki kire? s mit?
Nyilvn van rengeteg rs a neten. Egyik homlyosabb, mint a msik. Rendszeresen
visszatr fordulat volt, hogy az ACK egy olyan rtk, melyre a node szmt.
Knyrgm, mi az, hogy szmt? Elmegy a jsnhz?
Nyilvn meg tudom sniffelni a sajt gpem forgalmt s megprblhatok valamit
kiokoskodni a capture fjlbl. De itt a Wireshark sajnos inkbb htrltatott: roppant
szolglatkszen jval tbbet mutatott, mint amennyit rtelmezni tudtam. Ez egy
profinak nyilvn j - de annak, aki ebbl akarja megrteni a mkdst, felettbb
zavar.
Vgl egy hekker oldalon talltam egy kellen mly, de azrt szjbarg lerst- s
sikerlt megrtenem a szisztmt. Viszont belinkelni nem fogom. (-;
Mondjuk ez sem rossz:
http://www.firewall.cx/tcp-analysis-section-2.php
De mg ekkor is maradt egy megoldand problma. A kvetkez nagyobb tma a

TCP opcik bemutatsa lenne - de azoknak gy nekiszaladni, hogy nem rtjk az
SN/ACK pingpongmeccset, nem rdemes. Viszont az SN/ACK rendszert meg a TCP
~ 242 ~

kapcsolatok boncolgatsnl lehetne rendesen bemutatni - csakhogy ahhoz meg kell
a TCP opcik ismerete.
J kis csapdahelyzet.
Vgl gy hidaltam t, hogy most rszletesen vgigmegynk egy pldn. Ugyan
ltjuk benne, hogyan pl ki egy TCP kapcsolat, futlag meg is lesznek emltve benne
ismeretlen dolgok - de elssorban az SN/ACK kommunikcit fogom benne
rszletezni.
A plda utn jn majd egy TCP opcikat bemutat rsz, vgl jhet a TCP kapcsolat
mkdst rszletez fejezet. Igaz, itt mr lesz egy kis redundancia, hiszen a
kapcsolat kialakulst mr a pldban is lthattuk - de inkbb redundancia legyen,
mint hiny.
~ 243 ~

5.2.1 A S EQ U EN C E N UM B E R
S A Z
A CK N O W L ED G M E N T N U M B ER
P I N G P O N G CS AT A
A kvetkezkben bemutatom, hogyan pl ki egy TCP csatorna s hogyan indul be

rajta a forgalom. A trtnet a kvetkez: a 192.168.1.101-es IP cmmel rendelkez
kliens szmtgp le akar tlteni a 212.40.96.130-as IP cmmel rendelkez
webszerverrl egy weblapot.
5. 2 .1 . 1 1. L P S : S Y N
5.11. BRA P ACKET #08
5.12. BRA SYN
A kliens gp elindtja az n. hromlpses kzrzst, avagy a csip-csip-cskt77. Az

els lpsben magasra lltja a SYN flag-et s elkldi a kezd SN-t. Ugye tudjuk, ha a
77
Copyright by Fti Marcell.
~ 244 ~

SYN flag magas, akkor az SN egyben ISN is. Ebben az esetben az ACK mg
rtelmezhetetlen.
Jogos lehet a krds, mirt pont nulla az ISN? Egyltaln, mindig nulla?
TCP Connection Establishment Sequence Number Synchronization and Parameter Exchange:
http://www.tcpipguide.com/free/t_TCPConnectionEstablishmentSequenceNumberSynchroniz.htm
Az interneten meglehetsen sok cikk foglalkozik vele, mirt okoz komoly

problmkat, ha egy opercis rendszerben mindig ugyanaz az ISN. A Sequence
Number rtkek generlsa ugyanis egy algoritmus szerint trtnik. Ez az
algoritmus opercis rendszerenknt vltozik. Viszont ha a rosszfi ismeri egy
kapcsolat esetn az ISN-t, ismeri az opercis rendszert, azaz a hasznlt algoritmust,
akkor simn el tudja trteni egy kapcsolat felptst, hiszen tudni fogja, milyen
szmsorozatot kvetnek az ACK rtkek, teht tudja, milyen SN rtkeket kell
visszavlaszolnia.
Szval semmikppen sem illik, hogy mindig ugyanaz legyen az ISN, az meg vgkpp
nonszensz, hogy mindig nulla.
Ehhez kpest a Microsoft kt zszlshajjnl78 - a capture fjlok alapjn - az ISN
mindig nulla.
Iz. Hogy is van ez?
Ht gy, hogy megint a Wireshark volt tlsgosan is szolglatksz. A megolds ismt
a Packet Bytes rszen rejtzik.
78
J-j, mire ez a knyv megjelenik, az egyik mr nem lesz zszls. De most mg az.
~ 245 ~
5.13. BRA A TRKKS K LIENS ISN
Nzzk csak meg. Azt mondja, hogy az ISN rtke nulla. (Becsletre legyen mondva,
figyelmeztet, hogy ez relative ISN.)
De a helyes rtket akkor kapjuk meg, ha a Packet Bytes rszre vetjk a
pillantsunkat:
92 EA 06 F1 - azaz 2464810737. Szp nagy szm. Knnyen bele is lehet zavarodni.
Mivel a ksbbi SN/ACK rtkek ennl csak nagyobbak lesznek, a Wireshark nemes
egyszersggel csak a nvekmnyeket jelzi ki.
Hogy kvethetek legyenek a szmok, az brkon klnbz sznekkel jelltem,
hogy mikor melyik alap nvekvnyrl lesz sz. A bord jelli a kliens oldalt, teht
ha azt ltjuk, hogy ACK=1, akkor az gyakorlatilag azt jelenti, hogy ACK= ISNkliens + 1,
azaz 2464810737+1.
Na, ez az ISN rtk mr nem nulla. Meg nem is tnik tl szablyosnak sem. Nem is az.
Windows Server 2008/Vista esetn ugyanis az ISN egy megszott, megfszerezett,
generlt vletlenszm.
~ 246 ~
5. 2 .1 . 2 2. L P S : S Y N -A C K
5.15. BRA SYN-ACK
A webszerver - mely egyltaln nem biztos, hogy Windows - szintn generl

magnak egy Sequence Number rtket. Nzzk csak... a SYN flag magas, teht ez is
ISN. Ez konkrtan a webszerver ISN-je.
~ 247 ~
5.16. BRA A TRKKS W EBSZERVER ISN
Csak a teljessg kedvrt: ez sem nulla. C2 E7 8A DD, azaz 3269954269. Az elz

ponthoz hasonlan a szerver oldali ISN-hez kpest rtelmezett nvekmnyeket a
kk szn jelli az brkon.
jdonsg, hogy a csomagban mr nem csak a SYN flag magas, hanem az ACK flag is.
Ez azt jelzi, hogy tessk figyelni, mert az Acknowledgment Number meznek mr
van rtke.
Mit takar ez az rtk?
Visszajelzs? De krem, hova? Kinek?
Nem, nem.
Ez egy mandiner. Azt mondja, hogy kldk neked egy rtket az ACK mezben. Ha
rendben megkaptad a csomagot, akkor a kvetkez kldemnyed SN rtke legyen az,
mint amit n neked most ebben az ACK mezben elkldtem.
Mennyi az rtke? Az brn 1... de tudjuk, hogy ez relatv. A szn bord, teht ez az
rtk most egsz pontosan: ISNkliens + 1.
Mirt pont ennyi? Trelem, ksbb minden kiderl. Pontosabban, mg bonyolultabb
lesz. Igaz, logikusabb is.
~ 248 ~
5. 2 .1 . 3 3. L P S : AC K
5.18. BRA ACK
A kliens megkapta a csomagot, majd jfihoz mltan az SN mezbe a krt rtket

tette. De hogy is tudja ellenrizni azt, hogy a webszerver is megkapott-e minden
csomagot, is kld egy ACK rtket. (Termszetesen az ACK flag magas.)
s ez az ACK mennyi? Nyilvn ez sem 1. A szn kk, az rtk pedig egsz pontosan
most az ISNwebszerver + 1.
Azaz az a csfsg esett meg, hogy az brn mind az SN, mind az ACK rtke
ugyangy 1, a valsgban viszont a kt szm teljesen klnbz.
~ 249 ~
5. 2 .1 . 4 4. L P S : G E T
Vegyk szre, fontos dolog trtnt. Megtrtnt a hromfogsos kzrzs, kiplt a

csatorna. Indulhat rajta a forgalom.
5.20. BRA GET
Nocsak. Megint a kliens akcizott. Persze ez logikus, hiszen az egsz trtnet gy

indult, hogy a kliens akart valamit a webszervertl. Elszr termszetesen kiptik a
csatornt, s mivel az 3 lpsbl ll, gy mindig a kliens fejezi be, majd HTTP
esetben utna mondja csak meg, hogy mit is akart. Jelen esetben elkldtt egy
krst a webszervernek, miszerint szeretne letlteni egy weblapot.
~ 250 ~

Ebben a krsben sem resek az SN/ACK rtkek, de nem is vltoztak, hiszen az
elz csomaghoz kpest nem trtnt vltozs. (Ugyangy a kliens kld.)
Azrt egy rdekessg van, a flag-ek kztt megjelent a PSH flag. Ezzel majd ksbb
fogunk tallkozni, most elg annyi rla, hogy ez kirti a fogad lloms puffert azaz a krs egybl felkerl az alkalmazshoz.
~ 251 ~
5. 2 .1 . 5 5. L P S : AC K
5.22. BRA ACK
Kezd bevadulni a kommunikci. A webszerver az SN mezbe mg a megkvnt

ISNwebszerver+1 rtket rja, de az ACK-be mr feladja a leckt: a kvetkez csomagban
krek egy ISNkliens+475-s SN rtket. (Hogyan jtt ez ki neki? A fene tudja. Azt se
tudom, milyen opercis rendszer fut rajta, honnan tudnm akkor a generl
algoritmust?)
Vigyzat, hazudok.
~ 252 ~
5.23. BRA A HTTP KRS TARTALMA
Egyfell a 15-s csomagbl tudom, hogy egy Apache webszerver szolglt ki, ami
azrt behatrolja az opercis rendszert.
De nem ez volt a legnagyobb hazugsg. Hanem az, hogy nem tudom, mirt pont 475.
Nzzk csak meg a korbbi (13-as csomag) GET krsnket a Packet Bytes rovatban
a fenti brn. Ez egy szp nagy adatkupac. Mekkora? Azt mondja, 16 oszlop, 30 sor,
az annyi mint 480 bjt, ebbl lejn az els hat, mert az nincs bemeszelve, akkor az
pont 474. Azaz ennyi a TCP payload, azaz a TCP szegmens. Ez az rtk nem utazik
ugyan a csomagban, de a Wireshark szolglatkszen kijelzi a TCP sszegz sorban.
Pr oldallal ezeltt problmztam azon, hogy mirt pont annyi az ACK, amennyi.
Nos, ezrt. A fogad azt mondja, hogy megkaptam tled az Y SN rtk csomagban X
bjt payload-ot, a kvetkez csomagnak teht Y+X+1-tl kell indulnia - azaz erre a
Sequence Number rtkre fogok szmtani.
Nzzk meg, milyen ACK-et kld vissza a webszerver? ACK=475. Azaz t krem
legkzelebb SN-knt. s akkor n is knnyebben tudom sorbarakni a csomagokat.
~ 253 ~
5. 2 .1 . 6 6. L P S : H TT P
5.25. BRA HTTP
Most megint valami nem vrt dolog trtnt: ismt a webszerver kldtt egy
csomagot. Mirt is? Nos, az elz, azaz a 13-as csomag gyakorlatilag res volt,
pusztn egy ACK volt benne. Az igazi vlasz, azaz a kliens ltal krt weblap a mostani
csomagban megy vissza.
Mirt nem lehetett egyszerre, egy csomagban leackolni a kliens krst s rgtn
abba bele is rakni a vlaszt?
~ 254 ~

Ezen most el fogunk agyalni egy kicsit, ugyanis a TCP egyik sarkalatos pontjt
csptk meg. Mikor kell leackolni egy csomagot? Mindig? Minek?
Gondolj bele, ott van egy bszme nagy weblap - mondjuk a www.index.hu - vagy egy
300 MB mret HP printer driver. n meg mezei Ethernet hlzaton vagyok, 1460
bjtos MSS rtkkel. Ez testvrek kztt is 215460 ACK csomag kldst jelenten
tlem a printer driver esetben. Csak gy parasztosan megszmoltam a 14-es
csomagban - mely egy res ACK - a bjtokat, az jtt ki, hogy 76. Azaz a 300 MB
mret driver letltshez nekem 15.6 MB ACK csomagot kellene feltltenem.
Nem hangzik tl jl.
Mit lehetne kitallni, hogy cskkenjen ez a vzfej?
Pldul ltrehozunk a fogad oldalon egy ablakot. Azt mondjuk, hogy ez az ablak
befogad mondjuk 10 csomagot, ha betelt, csak akkor kldnk majd vissza egy ACKet. Mris csak 1,5 MB a plusz forgalom.
Csakhogy. Gondolkozzunk, Blim.
Egy kicsit elrerohanok. (Ksbb jobban is ki lesz trgyalva ez a rsz. )
A helyzet az, hogy nem csak fogad oldalon van egy puffer, hanem kld oldalon is,
mghozz a kld oldali eleinte kisebb, mint a fogad oldali s ksbb is csak
maximum egyenlek lehetnek. A kld oldali puffer paramtere a Send Window, ami
azt a mretet jelenti, amg a feladnak nem kell vrnia a visszakldtt ACK-re.
Az egyszersg kedvrt ttelezzk fel, hogy a Send Window rtke 5 csomag.
(Figyelem, valjban itt bjtokban mrnk, de most a szemlltets a cl.)
Ekkor kldnk s csak kldnk. A fogad meg csak vr s vr, mert azt mondtuk
neki, hogy 10 csomag utn ackoljon. A felad viszont 5 csomag utn lell, mert
megtelt a Send Window. s azta is vrtak, mg meg nem haltak.
Egy msik lehetsges epic fail ebben az esetben az, ha a kldend csomag mrete
nem ri el fogad puffer mrett. A felad befejezte a kldst, a fogad meg nem
igazol vissza, mert mg nem rte el a mennyisg a 10 csomagot.
Szval ez gy nem mkdik.
Marad a csomagonknti ACK, a j 5%-os vzfejjel.
~ 255 ~
RFC 1122
Illetve egy picit lehet mg kozmetikzni rajta. Ezt nevezik gy, hogy delayed ACK.
Nem egybl vlaszolunk vissza a feladnak, hanem vrunk egy kicsit. Ha 0,5
msodpercen bell79 megy vissza valamilyen adatcsomag, akkor nyertnk, mert
ennek a csomagnak a nyakba ltetjk (piggyback) az ACK-et.
Ezt a csomagot ltjuk ebben az alfejezetben.
Igen, rzem n is, hogy sntt egy kicsit a plda - hiszen egyszer mr leackoltuk a
csomagot (14), mirt kell most mg egyszer?
szintn szlva, nem tudom. Mivel ez egy piggyback ACK - azaz nem jelent
szmottev terhelst a forgalomban - csak arra tudok gondolni, hogy a fogad oldali
implementci inkbb nem vizsglgatott, hanem sz nlkl rnyomta mg egyszer
az ACK-et, ha mr gyis ment ppen arra egy csomag.
De ha mr itt jrunk, emltsnk meg mg nhny trkkt. Pl. nagymret
adatmennyisg kldsnl megelgsznk a kt csomagonknti ACK-kel, ezzel rgtn
felre reduklva a visszirny forgalmat. Vagy PSH flag-gel elltott csomagot nem
kell egybl ackelni. Aztn vannak olyan esetek, amikor korbban elveszett
csomagokat kldnk t jra (SACK), ilyenkor a tbb csomagbl ll bercsomaghoz
mr csak egy ACK jr. Vagy ha mr cifrzzuk: pldul kldenek neknk egy hat
csomagbl ll vonatot, de mondjuk az els csomag elveszik. Ekkor hiba kapjuk
meg a tbbi tt, nem tudjuk leackolni. Majd amikor lejr az id s a felad nem kap
semmit s emiatt jrakldi mind a hat csomagot s vgre fogad oldalon sszell a
csomag - ekkor az utols csomag leackolsa automatikusan visszaigazolja mind a hat
csomagot. (Kleine Fische, gute Fische - nem egy nagy sprolsok, de sok kicsi sokra
megy.)
De most mr tnyleg nagyon elrerohantam, trjnk vissza a pingpongmeccshez.
79
Az RFC szerint 0,5 sec. Windows Server 2008 s Vista esetben ez konkrtan 0,2 sec.
~ 256 ~
5. 2 .1 . 7 7. L P S : FI N -AC K
5.27. BRA FIN-ACK
A kliens megkapta a krt tartalmat - s mivel egyelre msra nincs szksge,

kezdemnyezte is a kapcsolat bontst. Ezt jelenti a FIN flag bebillentse.
Ami sokkal izgalmasabb, hogy a kzps dobozban begerjedtek a szmok. Mivel a
szerver az elz ACK-ben a 475-s rtket krte, gy ez is lett a Sequence Number.
Csakhogy a szerver ltal kldtt TCP payload-nak is volt egy mrete (5.25. bra
HTTP), egsz pontosan 569 bjt. Ezrt a kliens azt krte a szervertl, hogy az
kvetkez SN rtke 570 legyen.
~ 257 ~
5. 2 .1 . 8 8. L P S : AC K -F I N
5.29. BRA ACK-FIN
Folytatdik a kapcsolat bontsa. A szerver leackolja a kliens bontsi krelmt - majd

is elkezdi lebontani a tle kiindul kapcsolatot. (A ktirny kapcsolatot kt
irnybl kell bontani is.) Az SN rtelemszeren a krt rtk, s mivel az elz
csomagban a payload rtke 0 volt, gy csak eggyel lptette az ACK rtkt.
~ 258 ~
5. 2 .1 . 9 9. L P S : AC K
5.31. BRA ACK
Itt van vge a trtnetnek. A kliens visszaigazolja a szerver bontsi krelmt, a

kapcsolat elillant. Az SN mezbe a megkrt rtk kerlt, st, egy knyszeres
mechanizmus folytn a kliens mg megad egy elvrt ACK-et is (res payolad, azaz
ACK+1), de ez mr valjban rdektelen.
~ 259 ~

Az egsz folyamatot megtekinthetjk egy sszefoglal brn is.
5.32. BRA SN/ACK P ATTOGTATS SSZEFOGLAL BRA
Vgl egy megjegyzs:

Senkit ne zavarjon meg, hogy a capture kpernykn idnknt feltnik egy Next
Sequence Number nev mez. Ez a Wireshark knyelmi szolgltatsa: kiolvassa a
lncbl s odateszi, hogy lssuk. A csomag keletkezsnek pillanatban
rtelemszeren ez az rtk mg nem ltezik.
~ 260 ~

5.2.2 TCP O P T I O N S
Annyi elnynk mr van, hogy ismerjk az IP Options szerept, felptst.
Nagyjbl hasonlra szmthatunk itt is.
5.33. BRA TCP O PTIONS LTALNOS SZE RKEZET
Lesz egy opci azonost, lesz egy 1 bjtos rtk, mely az opci hosszt jelli - s
utna jhetnek az opcispecifikus adatok.
5. 2 .2 . 1 E N D O F O P T I O N L I S T S N O O P E R A T I O N
Mindkett 1 bjtos TCP opci.
No Operation : Ez az opci hatrolja el egymstl a TCP opcikat. (Option

Kind=0)
End Of Option List : Ez pedig zrja a sort. (Option Kind=1)
~ 261 ~
5. 2 .2 . 2 M A X I M U M S E G M E N T S I Z E O P T I O N
A maximum segment size (MSS) azt a legnagyobb szegmensmretet jelenti, melyet

trdels nlkl lehet belerakni egy csomagba. A kiszmolsa teljesen logikus: fogjuk
az MTU-t, levonjuk belle mind az IP headert, mind a TCP headert - s mr meg is
van. Vegynk egy teljesen ltalnos esetet: legyen az MTU 1500 bjt, se az IP, se a
TCP headerben ne legyen semmilyen opci - ekkor mindegyik 20-20 bjt - azaz az
MSS 1460 bjt lesz.
Egy kapcsolat kiptsnl a legels lpsekben trtnik meg az MSS belvse,
mghozz gy, hogy amikor a SYN flag magas80, abban a csomagban kerl tadsra
az MSS rtke is - pont az MSS Option rvn. Az Option Kind rtke: 2.
Ha valami furcsa vletlen folytn a kt fl nem ugyanazt az MSS rtket kzln a
msikkal, akkor a kisebb fog nyerni.
80
Ez ugye az els kt csip a csip-csip-cskban.
~ 262 ~
5. 2 .2 . 3 TC P W I N D O W S C A L E O P T I O N
Mint a TCP header trgyalsnl is lttuk, a WINDOW mez mrete 2 bjt. Ez azt
jelenti, hogy a receive window maximlis mrete 65535 bjt. Ez a szabvny
ksztsekor maximlisan elegendnek tnt81, de azta haladt valamennyit elre a
vilg. Gigabites kapcsolatoknl mirt ne lehetne bszme nagy ablakokat hasznlni a
folyamatos kommunikci vgett?
Ha nagyobb window mretet szeretnnk, akkor knytelen lesznk hasznlni a TCP
Windows Scale opcit. Az Option Kind rtke: 3. Az opci adatmezjben egy szm
fog utazni, melynek maximlis rtke 14 lehet. Valjban ez a szm egy
hatvnykitev, ahol a hatvnyozs alapja 2. Az eredmnyl kapott szmmal pedig
meg kell szorozni az eredeti maximlis ablakmret rtkt, hogy az jat megkapjuk.
Ebbl kifolylag az opcikkal megsegtett maximlis ablakmret:
216 * 214 = 230 = 1073741824 bjt. Kzismertebb nevn 1 GB.
81
"640 kbyte mindenre elegend lesz!"
~ 263 ~
5. 2 .2 . 4 S E L E C T I V E A C K N O W L E D G M E N T (SAC K) O P T I O N
Esett mr sz rla, hogy mi van akkor, amikor kimarad egy ACK a cmzettl. A felad
kldi a csomagokat, a cmzett makacsul nem ackol, aztn feltelik a kld oldali
puffer, vgl megmerevednek a frontok. Nagy sokra letelik az ACK vrsra
fenntartott id, a kld jra elkldi a le nem ackolt csomagokat.
De mi van akkor ha gigabites vonalon nyomtuk, j nagy ablakmretekkel (long fat
pipe)? Kldjk jra az sszes csomagot? Amikor - lttuk - az ablak akr 1 GB mret
is lehet?
Ilyen nagy ablakmreteknl mr rdemes hasznlni a selective ACK, azaz SACK
opcikat. A tbbes szm nem vletlen, ilyen opcibl ugyanis kett is van:
SACK-Permitted Option (Option Kind=4)
SACK Option (Option Kind=5)
A SACK-Permitted opci jelzi a partnernek, hogy tudom kezelni, ha SACK
visszajelzst kapok. Ezt az informcit szintn a SYN csomagokban egyeztetik a
felek.
A SACK opciban pedig konkrt szmok utaznak. Itt szerepelnek azok a Sequence
Number rtkek, melyeket a fogad nem kapott meg. Ilyenkor a felad csak ezeket
kldi jra.
~ 264 ~
5. 2 .2 . 5 TC P T I M E S T A M P S O P T I O N
Rgtn vezessnk be kt fogalmat:

Retransmission Time-Out (RTO): Az az id, melynek letelte utn, ha nem
rkezett visszajelzs, akkor jrakldjk a csomagot.
Round-Trip Time (RTT): A csomag elkldse s a visszajelzs megrkezse
kzti idtartam.
Az RTO finomhangolsa rdekben a TCP folyamatosan figyeli az RTT alakulst. A
"folyamatosan" kifejezst persze nem kell szszerint rteni, ltalban egy Send
Window-n bell egy RTT mrs trtnik.
Akadnak olyan kiszmthatatlanul ingadoz hlzatok, ahol ez kevs. Ekkor kell
rknyszerteni a TCP-t, hogy srbben szmolgasson RTT-t. Erre j a TCP
Timestamp opci. (Option Kind=8)
A jtkban mindkt flnek rszt kell vennie. Brmelyik is kld egy csomagot, a TCP a
helyi gpidbl kikalkull egy rtket (TS Value) s belerakja a TCP Timestamp
opci adatmezjbe, mell pedig belerakja, hogy mennyi volt a msik flre
vonatkoz legutbbi idrtk (TS Echo Reply), azaz az a TS Value, amit legutoljra a
msik fltl kapott.
~ 265 ~
5. 2 .2 . 6 P L D K
Nzzk meg, hogyan is nznek ki a TCP opcik a valsgban.
5.34. BRA TCP O PTIONS - SYN
Ez a korbban mr kitrgyalt folyamat els csomagja, az, amelyikben a kliens a

webszerverhez fordul. A SYN flag szemmel lthatan magas - s mint utaltam is r,
ebben az els csomagban kzl a kliens a TCP opcikon keresztl egy csom fontos
adatot is a szerverrel.
5.35. BRA TCP O PTIONS - MSS
Koncentrljunk a Packet Bytes mezre. Lthat, hogy az OPTION Kind 2, az opci

mrete 4 bjt (stimmel), a kt utols bjt pedig az MSS rtke hexadecimlis
formban.
~ 266 ~
5.36. BRA TCP O PTIONS - N O O P
A j reg No Operation TCP opci. Mondtuk rla, hogy elvlaszt (stimmel), mondtuk
rla, hogy 1 bjt s mondtuk rla, hogy az rtke 1.
5.37. BRA TCP O PTIONS - W INDOWS S CALE
TCP Window Scale opci. Az Option Kind rtke 3, az opci mrete 3 bjt, az adat
pedig 2. Mennyi is akkor a kliensem maximlis fogad ablaka? 216 * 22 = 218 = 256 KB.
5.38. BRA TCP O PTIONS - SACK
SACK-Permitted opci. Az Option Kind rtke 4, az opci mrete 2 bjt. Adattartalma

nincsen, hiszen ez csak jelzi, hogy kpes rtelmezni a szelektv ACK-ot.
s ennyi. Micsoda? Hogy hinyzik valami? Nem ltod az End Of Option List opcit?
Ht, azt bizony nem.
Nagyon trkksen lett megkerlve. Taln feltnt az brn (5.34. bra TCP Options SYN), hogy egyms utn kt NOP is jn. Ez a duplzs kellett ahhoz, hogy a TCP
opcik ltal elfoglalt mret nggyel oszthat legyen. Ilyenkor nem kell kln lezrni.
(Mirt fontos a nggyel oszthatsg? Azrt, mert a header mrett szszmban
troljuk - lsd a DATA OFFSET mez rszletezst.)
~ 267 ~

Persze a kommunikci nem csak ennyibl ll: a szerver vlaszban is magas a SYN
flag, teht is elkldi magrl a fontosabb rtkeket.
5.39. BRA TCP O PTIONS - SYN-ACK
Ezt mr nem rszleteznm annyira mlyen. Maximum arra hvnm fel a figyelmet,
hogy ebben a csomagban mr magas az ACK flag, durvn be is jtt annyi csomag,
amennyi egy Send Window-ban elfr - teht tudunk RTT rtket visszakldeni.
~ 268 ~

5.2.3 TCP
F LA G - EK
Kutyafuttban mr esett rluk sz, de most menjnk vgig rszletesebben is a

vlasztkon. Azt lttuk, hogy 1 bjt helyet foglalnak - ebbl a fejszmol olvask mr
ki is tallhattk, hogy nyolc darab flag-rl lesz sz.
Sorrendben:
CWR | ECE | URG | ACK | PSH | RST | SYN | FIN
ECE, AZAZ ECN-ECHO: Habr a msodik a sorban, de rdemes mgis ezzel kezdeni. Azt
jelenti, hogy a kld ismeri az ECN-t, illetve akkor is magas lesz, ha az ECN
tnylegesen be is kvetkezik - azaz az IP headerben bejelez az ECN mez. (ECN:
Explicit Congestion Notification, azaz hatrozott visszajelzs tlterhelsrl. Ha
esetleg nem ugrana be: 4.1.1 Az IP Header.)
RFC 3168
A TCP opcik egy rszhez hasonlan az ECN, mint ismert kpessg szintn
kapcsolatfelvtelkor (magas SYN flag) megy t.
CWR, AZAZ CONGESTION WINDOW REDUCED: A felad visszajelzse, hogy vette az ECE
jelzst, le fogja cskkenteni a congestion window mrett. (Ksbb lesz rla sz.)
URG, AZAZ URGENT: Jelzi, hogy a szegmensben srgs anyag van, tessk komolyan
venni az URGENT POINTER rtkt.
ACK, AZAZ ACKNOWLEDGMENT: Jelzi, hogy az Acknowledgment mezbe rt szm nem
viccbl van ott. (A gyakorlatban az ACK flag szinte mindig magas.)
PSH, AZAZ PUSH: Mit is rtam a megrkezett csomagokrl? Mi is trtnik akkor, amikor
megrkezik egy csomag a cmzetthez? A TCP rgtn felkldi az alkalmazs rtegnek?
Ugyan, nem UDP ez. Szpen gyjtgeti az adatokat a receive pufferben. Aztn amikor
a puffer megtelt, vagy ppen a kapcsolatkezel eljrs gy rzi, hogy itt az id, akkor
a kztes trolbl tkerl az adat az alkalmazshoz. (Feltve, hogy nincs hinyz
csomag a sorban.)
Ezt a folyamatot rgja fel a PSH flag. Ha ilyen csomag rkezik, az olyan, mint HKSz
riad a seregben: mindenki sszekapkodja a harci felszerelst s kirohan a
szobbl. (A 'ne legyen hinyz csomag' kritrium ettl fggetlenl itt is l.)
~ 269 ~

RST, AZAZ RESET: Ksznjk, ennyi. A kapcsolatnak vge. Mghozz nem is bartsgos
mdon - az RST sokkal inkbb erszakos bontst jelent. Mind a send, mind a receive
pufferbl trldni fognak a kapcsolat adatai. Ugyanezt kapjuk, ha egy kapcsolat mr
eleve ltre sem jtt. (Tipikusan amikor egy tzfal vgja pofn a bimbz
kapcsolatunkat.)
SYN, AZAZ SYNCHRONIZE: Jelzi, hogy egy kapcsolat van kialakulflben. Amikor ez a flag
magas, akkor kldi t az egyik fl a kapcsolat ltrehozshoz szksges adatokat a
msiknak.
FIN, AZAZ FINISH: Ennek a kapcsolatnak is vge - de azrt bartok maradtunk. A
kapcsolat normlisan csak akkor sznhet meg, ha mindkt fl elkldte az elbocst
szp zenetet (FIN), majd mind a kett vissza is igazolta.
~ 270 ~

5.2.4 TCP
K AP C SO LA T O K K EZ E L S E
Egy kapcsolatnak alapveten hrom fzisa lehet:

Bimbz
Stabil
Szakt
Jelzem, ez egy nagyon rvid fejezet lesz, hiszen korbban mr jcskn kivesztk a
folyamatot. (5.2.1 A Sequence Number s az Acknowledgment Number pingpongcsata)
5. 2 .4 . 1 E G Y TC P K A P C S O L A T K I A L A K U L S A
Amirl ott nem rtam: milyen informcik utaznak mg a SYN-nel jelzett

csomagban?
Elszr is a felad ISN-je. (Ezt tudtuk.)
A kezdemnyez receive windows rtke.
A kezdemnyez MSS (Maximum Segment Size) rtke.
A lista, hogy a kezdemnyez milyen TCP opcikat tmogat.
Pusztn csak ismtlsknt jegyzem meg, hogy ilyen rtelemben a SYN
kapcsolatfelvtelre jv SYN-ACK vlasz is SYN csomagnak szmt: azaz a vlaszol
is kzli mindezen informcikat magrl a hromlpses kzfogs msodik
lpsben.
Hogy mgse legyen olyan rvid ez a fejezet, meg legyen egy kis pihen is a szraz
tananyagban, emltsk meg a SYN Attack nven ismeretes tmadsi formt. Nem,
nem kell idegesen krbenzned, eszembe sem jut megrontani az ifjsgot. A SYN
Attack annyira reg dolog, hogy ma mr minden normlisabb rendszer le tudja
kezelni.
Szval. Elindul egy kapcsolat. A kezdemnyez kld egy SYN csomagot. A szerver
boldogan vlaszol egy SYN-ACK csomaggal. A kezdemnyez a nyugtz ACK helyett
viszont egy jabb SYN csomagot kld, egy msik portra. A szerver, ha lehet, mg
boldogabb. Micsoda npszersg! - gondolja. Termszetesen erre is vlaszol egy
SYN-ACK csomaggal. s gy tovbb. Gondolom, lthat a minta. Aztn mivel a szerver
a le nem zrt kapcsolatokat elrakja a memrijba, elbb-utbb az betelik. A szerver
nyladz mosollyal a szja szln csuklik ssze.
~ 271 ~
5. 2 .4 . 2 E G Y TC P K A P C S O L A T F E N N T A R T S A
Ha ppen nincs forgalom egy kapcsolaton keresztl, de az nem lett se bksen, se

harcosan lezrva, akkor valsznleg a feleknek mg szksgk lesz r. Ilyenkr jn
az, hogy res ACK csomagokkal jeleznek egymsnak, nehogy azt higyje a msik, hogy
valahol elrgta a macska a kbelt.
Persze ez sem ilyen egyszer. Mi trtnik kzben az SN/ACK szmokkal?
Az, hogy aki a keep-alive ACK csomagot kldi, eggyel kisebb SN rtket r bele, mint
amekkorra a msik fl - az ltala korbban kldtt ACK alapjn - szmt. A fogad
veszi a lapot, rzkeli, hogy ez csak keep-alive, visszakldi a korbbi ACK-ot - s
most mr azt is fogja visszakapni a kvetkez lpsben.
- Mirl prdiklt a Tisztelend Atya?
- A bnrl.
- s mit mondott rla?
- Ellenezte.
Azaz eddig rtam a keep-alive folyamatrl. Arrl a folyamatrl, melyet a Windows

Server 2008 / Vista alapbl tilt82. Mert biztos szp s biztos j dolgok ezek, de
leginkbb ri huncutsgnak tnnek.
Hadd hulljon a frgese.
82
Engedlyezni Winsock API fggvnyhvsbl lehet.
~ 272 ~
5. 2 .4 . 3 E G Y TC P K A P C S O L A T F E L B O M L S A
5.2 .4 .3 .1 A B K S E B B V E R Z I : F IN
A FIN flag szerepe nagyban hasonlt a SYN flag szerepre. Mg a SYN

kapcsolatfelvteli szndkot jelez, addig a FIN ppen ellenkezleg: kapcsolatbontsi
szndkot. Csakhogy itt a kzrzsnak nem hrom fzisa van, hanem ngy:
A bontani szndkoz jelez: FIN1-ACK1
A partnere visszaigazol: ACK2
A partner is lebontja a csatornt: FIN3-ACK3
A kezdemnyez visszaigazolja: ACK4
A fenti folyamatot illusztrlja az albbi bra.
5.40. BRA E GY KAPCSOLAT BKS VGE
Nagyon szpen ltszanak az SN/ACK szmokkal trtn jtkok is.
~ 273 ~
5.2 .4 .3 .2 A V A D A B B V E R Z I : R S T
Nagy pofont szeretnnk? Telneteljnk r az index.hu-ra!
5.41. BRA E GY KAPCSOLAT DURVA VGE
Szemmel lthatan nem rltek neknk. Meg szerettk volna rzni a kezket, olyan
j hromlpses formban - de mr a kinyjtott keznket sem fogadtk el. Elkldtk
a SYN csomagunkat, gy ahogy kell (SNrel=0, RecWin=8192, szegmensmret=0,
MSS=1460 s Window Scale=2 ) - de csak egy zord RST-ACK jtt vissza.
Mivel nagyapnktl azt tanultuk, hogy ne ljnk fl olyan szekrre, ahol nem ltnak
minket szvesen, tudomsul vettk az RST-t - hrom prblkozs utn abbahagytuk.
RST-t nem csak kapcsolat ltrehozsakor kaphatunk. Ugyanide jutunk, ha egy mr
meglv kapcsolaton keresztli forgalomban rtelmezhetetlen paramtert tall a
TCP fejlcben valamelyik host. Ilyenkor a kapcsolat sszes adata elvsz, melyeket az
alkalmazs mg nem olvasott fel a receive pufferbl.
~ 274 ~
5. 2 .4 . 4 A TC P K A P C S O L A T O K L L A P O T A I
A TCP kapcsolatok egyes lpseit llapotoknak nevezzk. Ezeket az llapotokat

tartalmazza az albbi tblzat:
5.2. TBLZAT
llapot
CLOSED
LISTEN
SYN SENT
SYN RCVD
ESTABLISHED
FIN WAIT-1
FIN-WAIT-2
CLOSING
TIME WAIT
CLOSE WAIT
LAST ACK
Lers
Az gegyadta vilgon nem trtnik semmi.
Egy alkalmazs szint protokoll elkezdett figyelni egy porton.
Egy alkalmazs szint protokoll kapcsolatot kezdemnyezett, azaz elkldtt egy SYN csomagot.
A SYN csomag megrkezett, ment is vissza a SYN-ACK.
Megrkezett a SYN-ACK utni ACK, a kapcsolat ltrejtt.
A kapcsolat bontst kezdemnyez els FIN-ACK csomag elment.
Megjtt az ACK a kezdemnyez FIN-ACK csomagra.
Ez egy ilyen lebeg llapot, megkaptuk a FIN-ACK csomagot, de mg nem kldtk el az ACK-et.
Mindenki megkapott minden csomagot, mely a kapcsolat ktirny lezrshoz szksges volt.
Ekkor mg eltelik egy bizonyos id, amg j kapcsolatot lehet nyitni.
Megkaptuk a FIN-ACK csomagot s kldnk is egy FIN-ACK csomagot.
Megkaptuk az ACK csomagot a FIN-ACK csomagunkra.
Akrhogy is nzem, nem teljesen kerek a trtnet. Pldul mi lehet a klnbsg a

LAST ACK s a FIN-WAIT2 llapotok kztt? A tblzat alapjn pldul semmi.
Ezrt van itt ez az bra.
~ 275 ~
5.42. BRA E GY KAPCSOLAT LLAPOTAINAK
TRKPE
(W IKIPEDIA )
Mint lthat, a lezrsnl van egy aktv folyamat s van egy passzv. Az aktv
folyamat azokbl az llapotokbl ll, amelyeken a bontst kezdemnyez fl megy
t, mg a passzv folyamat azokbl az llapotokbl, amelyeken a partner. Ergo a FIN
WAIT-2 llapotban a bontst kezdemnyez fl kapja meg az ACK csomagot a FINACK krsre, mg a LAST ACK llapotban a tloldali fl kapja meg az ACK-et az
FIN-ACK csomagjra vlaszul.
~ 276 ~

5.2.5 TCP
AD AT FO L Y A M
Teht, a bitek folynak - mint azt korbban mr tisztztuk. Jnnek befel, gylnek a
receive pufferben, majd az alkalmazs felkapkodja. A msik oldalon az alkalmazs
tolja bele a send pufferbe, ahonnan a TCP talicskzza kifel.
De egsz pontosan, milyen llapotai is lehetnek egy csomagnak? Hogyan
viszonyulnak ehhez a Send/Receive ablakok? s mirt ll meg a kzlekeds nlunk,
ha leesik egy centi h?
Habr az eddig lertakbl - majdnem - minderre meg lehet tallni a vlaszt, gy
gondolom, egy grafikus szemltets mindig jl jhet83.
5. 2 .5 . 1 S E N D W I N D O W
Igen, ksznm, vettem a krdsedet. Mi is az a Send Window, amelyrl eddig csak

gy itt-ott elptygtetve esett sz?
Beszljnk inkbb elszr a Receive Window-rl, mert azt mr ismerjk. Ez az az
rtk, melyet a fogad fl minden ACK csomagban elkld a feladnak. Ebben mondja
meg, hogy bartom, momentn ennyi adatot tudok fogadni egyszerre, ennl tbb
pillanatnyilag nem fr be a szobba84. Ad abszurdum, ha a fogad 0 mret Receive
Window rtket jelez vissza, a felad teljesen le is ll - addig, amg nem kap egy
nullnl nagyobb rtket.
Most, miutn a Send Window fejezetben ilyen jl kitrgyaltuk a Receive Window
jelentst, nem rtana magval a Send Window-val is foglalkozni. Nos, a helyzet az,
hogy a Send Window a Receive Window h trsa. A teleport lloms, ahonnan a
csomagok indulnak a cmzett teleport llomsba. Ha nincs forgalom a levegben s mr korbban beindult a kapcsolat - akkor a Receive s a Send Window mrete
megegyezik. Gyakorlatilag a felad a Send Window-ban adminisztrlja, mi is a
helyzet a feladott csomagokkal, a fogad pedig a Receive Window-ban kveti
nyomon, hogyan llnak a fogadott csomagok.
Szoktk gy is meghatrozni a Send Window-t, hogy az az ablakmret, amg
kldhetnk csomagokat, anlkl, hogy meg kellene vrnunk a visszaigazolst. Azaz
kldnk, kldnk, kldnk... s ahogy jnnek vissza a visszaigazolsok, gy lpnk
egyet-egyet elre az ablakkal. Ha nem jnnek a visszaigazolsok, akkor betelik az
ablak s megll - egszen addig, amg le nem telik az id s jra nem kezdjk kldeni
a vissza nem igazolt szegmenseket.
83
84
Klnben is, mrnkember mindig rajzol. Vegyipari Gpszek Krusa, Veszprm.

My hovercraft is full of eels. (http://www.omniglot.com/language/phrases/hovercraft.htm)
~ 277 ~
5.43. BRA S END W INDOW
Mint az brn is lthat, ngy kategriba soroltuk a csomagokat:

Sent/ACKed: Ezek azok a csomagok, amelyekkel a tovbbiakban az gegyadta
vilgon semmi dolgunk sincs. Elkldtk ket, megkaptuk a visszajelzst, a csomagok
kicssznak a balfenken.
Sent/UnACKed: Belptnk a Send Window terletre. Itt vannak a mr elkldtt, de
mg vissza nem igazolt csomagok.
Unsent/Inside: Ez az a terlet, ahov az alkalmazs mr lepakolta a csomagokat,
azok mr bekerltek az elkldendk kz (inside), de mg nem lettek elkldve.
Unsent/Outside: Ezek azok a csomagok, melyek csak lmodoznak rla, hogy el
lesznek kldve - de egyelre mg csak sorballnak a teleport lloms eltt.
Az mr csak szemllet krdse, ki hogyan kpzeli el:
Vagy az ablak ll egy helyben s a csomagok vndorolnak jobbrl balra.
Vagy a csomagok llnak egy helyben s az ablak - birodalmi lpegetknt halad balrl jobbra.
Az utbbi hasonlat mr csak azrt is szemlletes, mivel tudjuk, hogy az ablak mrete
nem lland. Ez egy imbolyg, dlngl ablak.
~ 278 ~
5. 2 .5 . 2 R E C E I V E W I N D O W
Most pedig tszkkennk a fogad oldalra.
5.44. BRA R ECEIVE W INDOW
Received/ACKed/Retrieved: Baloldalt megint azokat a csomagokat ltjuk, akik mr

tl vannak a dolgon. A csomagok megrkeztek, a visszaigazols elment, a fogad
alkalmazs felkapkodta a dobozokat.
Received/ACKed/Not Retreived: Megrkeztek, visszaigazoltuk - de az alkalmazs
mg nem ugrott be a csomagokrt.
Received/UnACKed: Megrkeztek, de mg nem igazoltuk vissza.
Not Received/Inside: Ez egy trkks meghatrozsa a semminek. Azt mondja, hogy
mg az ablakon bell vagyunk, de ide mg nem rkezett semmi. Azaz a teleport
llomson az res vegcsvek. Ide vrjuk a csomagokat feldolgozsra.
Not Received/Outside: A csomagok, melyek majd valamikor meg fognak jnni.
Jelenlegi tartzkodsi helyk: fldn, vzen, levegben.
Nyilvn szrevetted. Itt t rszre osztottuk fel a futszalagot, mikzben a Send
Window esetben elg volt ngy rsz. Gondolom, azt is ltod, hogy a kavarst a
Maximum Receive Window okozza. Mi is ez - s mirt van szksg kt ablakra?
A megolds kulcsa a billegs. A Send Window-nl mondtam, hogy llandan vltozik
a mrete, azaz lpegetknt billeg. Itt ez a viselkeds a Current Receive Window-ra
igaz. Ez ugyanis a pillanatnyi mrett jelenti a fogad ablaknak. (Ezt a pillanatnyi
rtkt kldi vissza az ACK csomagban.) A Maximum Receive Window mrete ezzel
szemben egy fix rtk... a maximum, melyet a fogad egyltaln be tud fogadni. (Ha a
Current Receive Window mrete nem ri el a maximumot, logikus, hogy a
feldolgozs utols fzisban lv csomagok helyezkedjenek el a kett kztti
terleten.)
~ 279 ~

Ezt a kt, csszkaknt mozg ablakot (Send/Receive) nevezzk sszefoglal nven
TCP Sliding Windows-nak.
rtam a grafikus szemlltets hasznossgrl. Prbltam rajzolgatni is, de ezt a
folyamatot igazbl egy animci mutathatn be a legjobban.
Szerencsre van is ilyen a neten.
http://www.osischool.com/protocol/Tcp/slidingWindow/index.php
Szvem szerint bele is illesztenm ebbe a knyvbe, annyira j. Habr az animci

elsdleges clja a ksbb trgyaland Slow Start algoritmus bemutatsa, de remekl
ltszik, hogyan dolgozik prhuzamosan a kt TCP Sliding Window. (Egy apr
nomenklatra pontosts. Az n fogalmaim szerint mind a kt ablak - Send Window,
Receive Window - a TCP Sliding Windows kategriba esik, addig az animci a
Receive Window-t nevezi Advertised Window-nak, a Send Window-t meg Sliding
Window-nak.)
Illetve rdemes elcsemegzni az oldal tbbi animcii kztt is.
http://www.osischool.com/protocol/Tcp/
J krds lehet, hogy a Receive Window most akkor egy fix mret, vagy dinamikusan
vltoz? Mikor hogy. Valamikor fix rtk volt (a Windowsban nyilvn registryben
trolva), de a Windows Server 2008 / Vista esetben mr gynevezett autotuning
hangolja, a konkrt vonal svszlessgnek s forgalmnak fggvnyben. (Emiatt
szoktk felhvni a figyelmet arra, hogy a fenti opercis rendszereknl tnyleg
figyeljnk oda a QOS-re: ugyanis innentl a TCP sokkal hatkonyabban tmi ki a
drtot - azaz ha van valami alkalmazs, mely fix, minimlis svszlesg ignnyel br,
akkor ezt foglaljuk is le a szmra. Hulladkknt mr nem fog neki annyi
megmaradni, mint korbban.)
~ 280 ~

5.2.6 A Z
JR AK L D SE K R EN DS Z E RE
A TCP mkdse eddig teljesen logikus volt, mg ha egy kicsit bonyolult is.
Na, ez vltozik meg innentl.
Nem, nem a logikval lesz baj. s egyszersdni sem fog a helyzet.
Azt lltottam a TCP-rl, hogy megbzhat. Ez bizony nem csak abbl ll, hogy
sorszmozza a csomagokat s ellenrzi a megrkezsket: szksg esetn jra is kell
kldenie az elveszett csomagokat.
Istenem, milyen szp dolog is a nyelv. A fenti mondat gy helyes, ahogy van,
mindenki blogat - pedig kt helyen is bele van kdolva a rejtett akna: mi az, hogy
'szksg esetn'... s mi az, hogy 'elveszett'?
A TCP kulcskrdshez jutottunk el. Mikor kldjnk jra egy csomagot?
Ha tl sokig vrunk, akkor lass lesz az tvitel - hiszen ezt az idt minden
visszaigazols eltt ki kell vrni.
Ha tl hamar jrakldjk, akkor borzasztan rossz lesz a hatkonysg hiszen anyag megy ugyan t a kapcsolaton, csak sokszor ugyanaz mg
egyszer.
Igen rzkeny optimumot kell eltallni - radsul szdletesen vltoz
krnyezetekben. Egyltaln nem mindegy, hogy gigabites LAN-on vagyunk (ahol
minden belefr), mholdas WAN-on (ahol nagy a svszlessg, de a hiba is rengeteg)
vagy ppen egy betrcszs ISDN-en (ahol nysztnk minden egyes kbps-rt).
Emellett egyltaln nem mindegy, hogy a kommunikl felek a TCP mely
huncutsgait ismerik s melyeket nem.
Rengeteg trkk, apr sszersts ltezik a TCP-ben, hogy a mkdse mindenhol
optimum kzelben legyen. Nem fogom mindegyiket bemutatni ebben a fejezetben,
inkbb csak mazsolzgatok.
Elszr is, ismerkedjnk meg az jraklds alapelemeivel. Az RTO/RTT prosrl
mr ejtettem pr szt, de igazbl ebben a fejezetben rzik magukat otthon.
RTT (Round Trip Time): Az az id, mely a csomag feladsa s a visszaigazols
megrkezse kztt telik el. Ezt a TCP folyamatosan mri.
RTO (Retransmission Time Out): Az az idkorlt, mely utn egy csomag
elveszettnek tekintend, azaz a felad jrakldi. A TCP bizonyos
rendszeressggel az RTT rtkekbl szmolja ki.
~ 281 ~

J. s hogyan?
RFC 793
Az eredeti RFC szerint gy:
Measure the elapsed time between sending a data octet with a particular sequence number
and receiving an acknowledgment that covers that sequence number (segments sent do not
have to match segments received).
This measured elapsed time is the Round Trip Time (RTT). Next compute a Smoothed Round
Trip Time (SRTT) as:
SRTT = ( ALPHA * SRTT ) + ((1-ALPHA) * RTT)
and based on this, compute the retransmission timeout (RTO) as:
RTO = min[UBOUND,max[LBOUND,(BETA*SRTT)]]
where UBOUND is an upper bound on the timeout (e.g., 1 minute), LBOUND is a lower bound on
the timeout (e.g., 1 second), ALPHA is a smoothing factor (e.g., .8 to .9), and BETA is a
delay variance factor (e.g., 1.3 to 2.0).
Ez egy szp kplet, kr, hogy a gyakorlatban nem vlt be.

RFC 1122
Jtt helyette egy msik, mely az RFC 1122-ben lett lerva. Ez egy nagyon szp, tbb
oldalas eljrs, felttelekkel, kiegsztsekkel bven megtmogatva. Ha nem
haragszol, mlyebben nem mennk bele.
Ugyanis ezzel mg nincs vge. A fenti eljrs remekl mkdik akkor, ha alapveten
kicsik az ablak mretek. De a gigabites vonalakon nem ez a jellemz. Viszont ha
nagyok az ablakok, akkor kevs az ACK - azaz nem mrvad az RTT mrse sem.
Ekkor jn be a kpbe a korbban mr emltett TCP Timestamp TCP opci. (Csak
ismtlskppen: az opci adatterletn bell mindkt host elkldi a sajt bels
rjnak az rtkt.) Ilyen esetekben az RTO-t mr nem az RTT-bl szmoljk a
felek, hanem ezekbl a bels rk ltal mutatott rtkekbl
Szp, mi? s ez mg csak az RTO szmts. Hogy a felek mely RFC-ket ismernek?
Egyltaln, mely TCP opcikat? Az eszkzknek nincs ms vlasztsa: bznak... s
prblkoznak.
~ 282 ~

Akkor jjjenek a klnbz megfontolsok, illetve trkkk.
TCP Tuning:
http://en.wikipedia.org/wiki/TCP_tuning
Hogyan veszhetnek el tkzben csomagok? Elmletileg nem kizrt, hogy ppen arra
jrt a balts gyilkos s aprra hastotta az ethernet kbelt - de a gyakorlatban inkbb
a tlterhelt routerek szoktk eldoblni a csomagjainkat. Nyilvn visszajelzs nlkl,
hiszen tlterheltek. Hogyan vdekezhetnk ez ellen? Ha felismernnk, hogy router
tlterhelsrl van sz, akkor pldul megnvelhetnnk az RTO-t. Ez tulajdonkppen
automatikus is, hiszen megn az RTT, teht meg fog nni az RTO. Fog. Csak ppen
pr tempval ksbb, hiszen az RTO a korbbi RTT-kbl ll ssze. Azaz mr nagy az
RTT, de az RTO mg a korbbi, kisebb RTT-k alapjn ll ssze -> hirtelen nagyon
megugrik az eldobott csomagok szma -> hirtelen beindul egy nagyobb llegzet
jraklds. Mindez akkor, amikor a router egybknt is be van havazva.
5. 2 .6 . 1 S L O W S T A R T A L G O R I T M U S
RFC 2581, 3465

Erre a problmra az egyik vlasz az n. Slow Start algoritmus. (A Windows Server
2003 / XP a korbbi RFC-t ismeri, a Windows Server 2008 / Vista a ksbbit.)
Ehhez bevezetjk az n. Congestion Window (cwind) vltoz fogalmt. Gyakorlatilag
ezzel a Send Window mrett befolysoljuk: amennyiben a cwind rtke kisebb,
mint az aktulis Receive Window rtke, akkor a felad inkbb a cwind-et hasznlja
a Send Window mretnek belltshoz.
gy finoman tudjuk szablyozni egy kapcsolat beindulst, illetve felprgetst.
Elsre a cwind-et jval kisebbre szoktk venni, mint a Receive Window. (Tipikus
rtk: MSS*2.) Ha nem veszett el a csomag, jhet a duplzs: MSS*4. s gy tovbb,
amg el nem rjk a Receive Window rtkt.
Utalnk megint a korbbi animcira:
~ 283 ~
5. 2 .6 . 2 C O N G E S T I O N A V O I D E N C E A L G O R I T M U S
Kicsit hasonl az elz algoritmushoz, ugyangy a cwind vltozval operl. Azt

mondja, hogy amikor elveszik egy csomag - azaz a felad nem kapja meg a
visszajelzst, akkor a cwind rtkt belltja a pillanatnyi Receive Window
rtknek a felre, majd nekill szp fokozatosan nvelni azt. (Lpsenknt 1 MSS
rtkkel.)
Vegyk szre, hogy a kt eljrs kztti klnbsg gyakorlatilag csak a kezdpont
kivlasztsa s a nvekeds mrtke. Hogy a kett kzl melyiket fogja hasznlni a
TCP, az egy sstresh nev vltoz rtktl fgg - de ennyire mlyen mr nem
szndkozom belemenni a tmba.
5. 2 .6 . 3 A Z J R A K L D S L L E K T A N A
Tegyk fel, elveszett egy csomagunk. Letelt a vrakozsi id, s mi, mint feladk nem
kaptuk meg a visszaigazolst. Nyilvn jbl el fogjuk kldeni. Hnyszor? Mg
egyszer egszen biztosan. s ha arrl sem jn meg a visszaigazols? Trelmes
emberek vagyunk, egyszer mg megprbljuk. Ha arrl sem jn meg az ACK, akkor
hagyunk fel csak a kldssel.
Mennyi id teljen el kt klds kzben? Ez nyilvn az RTO-tl fgg, hiszen annyit
vrunk, amg a csomagot elveszettnek nem nyilvntjuk. J neknk az, ha mindig
ugyanannyi RTO-val szmolunk? Nem. Az alkalmazott logika az, hogy az
jrakldseknl megduplzzuk a korbbi RTO-t. Konkrtan Windows Server 2008
esetn a tipikus plda kapcsolat felptsekor: kezd RTO 3 sec, jranyits 6 sec,
utols prblkozs 12 sec. Azaz egy nem mkd kapcsolat felismerse 21 sec
sszesen.
5. 2 .6 . 4 D E A D G A T E W A Y F E L I S M E R S
Az elbb nagyon gyorsan lezrtuk a szlat, amikor azt mondtuk, hogy abbahagyja a
kldst - s ksz. Nem egszen.
Ha ugyanis a kldsi irny a default gateway fel mutatott, s gy veszett el - egyms
utn hromszor - a csomag, akkor a host gy fogja kezelni, hogy ez a default gateway
megdgltt. s igen, most jn el az, hogy mirt lehet egy hlzati krtya
konfigurcijnl tbb DGW-t is megadni. Nem, nem azrt, hogy az egyik irnyhoz
erre, a msik irnyhoz meg amarra menjenek a csomagok85. Arra a route tbla val.
85
MCP vizsgk egyik beugrat krdse.
~ 284 ~

Ellenben, ha tbb DGW-t vesznk fel, akkor ilyenkor, egy Dead Gateway
detektlsakor teszi a TCP automatikusan a msodikat az els helyre. Ha ez is
meghal, akkor jn a harmadik - amennyiben van.
Mikor j ez? Ha pldul van egy kzponti irodnk s van egy vidki telephelynk,
amelyhez a biztonsg kedvrt kt klnbz vonalat is kiptettnk. A telephelyen
az egyik router az els DGW, a msik router a msodik DGW.
A detektlsnak van egy rdekes vonzata is. Ugyanis visszajelzs nem csak akkor
nem jhet, ha a default gateway, azaz a routernk dobta fel a portjait - hanem akkor
sem, ha az tvonal brmelyik eleme llt le, azaz brmelyik host a router mgtti
ismeretlen vilgban. A Dead Gateway felismers - s a DGW csere ekkor is
megtrtnik.
5. 2 .6 . 5 F O R W A R D RT O - R E C O V E R Y (F-R TO)
Bejelentkezik a tske. Egy pillanatra elromlik a vonal, egy csomagnl megn az RTT.
Ttelezzk fel, hogy ppen egy sok szegmensbl ll nagy ablak szegmenseinek
kldse kzben vagyunk, mondjuk az elejn. Az egyik szegmensnl lejr az RTO, gy
nem kapjuk meg a visszaigazolst - mikzben meglehetsen nagy valsznsggel a
csomagok megrkeztek, csak a vonal pillanatnyi belassulsa miatt a visszaigazols
nem. Hivatalosan most jra kellene kldennk az sszes csomagot, melyeket a nem
visszaigazolt csomagtl egszen a Send Window vgig kldtnk - valsznleg
feleslegesen.
Ilyenkor lp letbe az F-RTO algoritmus.
RFC 4138
A felad elszr csak az ablak els olyan szegmenst kldi jra, amelyiknl lejrt az
RTO. Megvrja a visszaigazolst. Ha ez megjtt, akkor gy csinl, mintha nem trtnt
volna semmi s elkldi az ablak _utni_ els szegmenst. (Feltve, hogy a tloldali
Receive Window-ban van mg szabad hely.) Ha erre is megjtt a visszaigazols, az
csak gy lehetsges, ha az egsz ablak tartalma korbban mr megrkezett a
tloldalra. (Ugyanis ha lenne benne lyuk, akkor a fogad nem igazoln vissza az
utbbi csomagot.)
Megksznjk, mehetnk tovbb.
Mire is j ez? Tipikusan a wifi-re. Amikor megy szpen a hlzat, de
kiszmthatatlanul fordulhatnak el pillanatnyi lassulsok.
~ 285 ~
5. 2 .6 . 6 S E L E C T I V E A C K N O W L E D G E M E N T (SAC K)
Errl mr volt sz korbban a TCP opciknl, a kp teljessge miatt vettem csak bele
a felsorolsba. (Ismtls: ha a cmzett nem kapott meg minden szegmenst egy
ablakbl, vissza tudja jelezni, hogy mely szegmensek hinyoznak. A felad ezutn
csak azokat kldi jra s nem az egsz ablakot.)
5. 2 .6 . 7 K A R N A L G O R I T M U S
Az algoritmus kidolgozsa Phil Karn nevhez ktdik86. Ha nagyon tmren akarom

sszefoglalni, akkor arrl van sz, hogy van j RTT, amelybl lehet RTO-t szmolni s van rossz, amelybl meg nem.
Nzznk az utbbira egy pldt. Elkldtnk egy csomagot - ezzel le is nyomtuk a
stopperra gombjt. Nem kaptunk visszaigazolst az RTO-n bell, gy megduplztuk
az RTO-t, elkldtk mg egyszer a csomagot. Ez mr bevlt, megjtt a visszaigazols.
Csakhogy. Az RTT-t mr stopper definci szerint csak most, az ACK
megrkezsekor llt le. Nos? J ez az RTT rtk RTO szmolshoz? Nem igazn.
Karn azt javasolta ehelyett, hogy ha ilyen szituci fordul el, akkor ne hasznljuk az
jrakldtt csomag RTT rtkt az RTO szmtshoz: nemes egyszersggel csak
hagyjuk ott, ahol volt. (Ez ugye az eredeti RTO*2.)
A Karn algoritmus:
http://en.wikipedia.org/wiki/Karn%27s_Algorithm
http://www.cs.utk.edu/~dunigan/tcptour/javis/tcp_karn.html
5. 2 .6 . 8 F A S T R E T R A N S M I T
RFC 2581
Beesik a vrba egy kbor lovag. Ht te melyik sereghez tartozol?
A fogad egyszer csak kap egy csomagot, melynek az SN rtke nem illik a sorba. Ez
egy kbor csomag, mely eddig bklszott valahol a hlzaton. A fogad knjban
visszaigazolja, mghozz az ACK mezbe azt a Sequence Number rtket rja, melyre
egybknt szmtott. Ezzel viszont a feladt hozza zavarba: szegny szerencstlen
kt ugyanolyan ACK rtk visszaigazolst fog kapni. s ha mg csak kettt.
Karn, P. and C. Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols",
(SIGCOMM 87).
86
~ 286 ~
5.45. BRA GY KELLENE MENNIK A DOLGOKNAK
Szpen megy a csomag, jn a visszaigazols. Mindenki boldog.
5.46. BRA B AJ VAN
Itt trtnt valami vratlan dolog: megjelent a csomagelkap man valamelyik

routeren: az 1-es TCP szegmens nem rkezett meg. Emiatt a cmzett gy rzkeli,
hogy a 2-es TCP szegmens egy ksza szegmens - hiszen nem r szmtott. Gyorsan
kld is vissza egy ACK-ot, mghozz azzal az rtkkel, mely tulajdonkppen a vrt
~ 287 ~

Sequence Number. Ekkor jn meg a 3-as TCP szegmens, mely ugyanolyan ksza
csomag elbrlsban rszesl... s ez gy megy tovbb az RTO lejrtig.
5.47. BRA A GYORS MEGOLDS
Pedig nem kellene, ugyanis a minta knnyen szrevehet: dlnek sorban a

visszaigazolsok, ugyanazzal az ACK rtkkel.
Itt jelenik meg a Fast Retransmit. Azt mondja, hogy ha hromszor kapunk vissza
ugyanolyan ACK rtkkel visszaigazolst, akkor krs nlkl elkldjk jra az ACK
rtkhez tartoz TCP szegmenst, jelen esetben az 1-est. Innentl sorfolytonosak
lesznek a csomagok a cmzett pufferben, mehet tovbb az let.
Megoldottuk a problmt RTO-n bell.
Mg egy dolgot kell megmagyarznom: mirt pont 3?
Azrt, mert egy, vagy kt dupliklt ACK akkor is elfordulhat, ha a csomagok nem a
megfelel sorrendben rkeznek. A hrom viszont mr tbb, mint gyans.
~ 288 ~
AZ ALKALMAZS RTEG PROTOKOLLJAI, SZOLGLTATSOK
6 A Z ALKALMAZS RTEG PROTOKOLLJAI , SZOLGLTATSOK

Nos, nzzk, hogyan llunk.
Ltrehoztuk a postt. Tmrdek posts ll kszenltben, kempingbiciklin ldglve,
kismotorjt brummogtatva vagy zld furgonban cigarettzva - alig vrjk, hogy
elszlltsk a leveleket.
Kitalltuk a cmeket. Kitalltuk, hogy legyenek vrosok, legyenek utck, a hzakon
legyenek szmok s a bennk lak embereknek legyenek neveik. Kitalltuk azt is,
hogy a cmeket hov rjuk a kldemnyeken.
Kitalltunk szlltsi mdszereket. Gyorsat, lasst, megbzhatt, megbzhatatlant.
Most mr csak azt a nyomorult levelet kellene megrnunk.
Elmletileg ezeket mr rhatnnk spontn is. Rengeteg alkalmazs van, mely egyedi
protokollokat, egyedi portokat hasznl informcitovbbtsra. De az evolci
ltrehozott rgztett protokollokat is. Hiszen mirt kellene minden egyes feladat
megoldsnl jra s jra felfedeznnk a spanyolviaszkot?
A szabvnyostott (RFC, ugye) protokollok viszont rgztett portokon
kommuniklnak. Persze ne gondoljon senki kbevssre, minden tovbbi nlkl
zemeltethetek webszervert, mely nem a 80-as porton mkdik - csak ppen
elvesztek mindenkit, aki olyan cges tzfal mgl jn, ahol csak a 80-as portot
engedlyeztk bngszsre.
Ezeket a szabvnyos, de legalbbis ersen ajnlott portokat nevezik wellknown
portoknak.
~ 289 ~
6.1. BRA T RKP AZ ALKALMAZS RTEGHEZ
Termszetesen nem teljes. Irgalmatlanul nem teljes. Nyilvn nem csak ennyi
protokoll ltezik. Nyilvn nem csak a bngsz hasznlja a DNS-t. A Total
Commander nyilvn nem csak az SMB-t hasznlja - ha nevet kell feloldania, fordulhat
DNS-hez s WINS-hez is. A fokonyv.exe-rl meg legtbbszr a fejlesztje sem tudja,
mit is hasznl pontosan.
Ezekbl a rgztett, alkalmazs-rtegbeli protokollokbl mutatok be ebben a
fejezetben kettt. A lista bven a teljessg ignye nlkl kszlt - ezekbl a
protokollokbl ugyanis meglehetsen rengeteg van. (Rszletesebben a msodik
ktet fog foglalkozni velk.)
~ 290 ~
6.1 D YNAMIC H OST C ONFIGURATION P ROTOCOL (DHCP)

RFC 2131, 2132
Tapasztalatom szerint az egyik leginkbb misztikusnak tartott alap hlzati
szolgltats. Hde, hogyanmr... nincs IP cme, oszt mgis dzsal a hlzaton?
Bizony, bizony.
Aztn van itt mg homly. Minden hlzati szakknyv megemlti, hogy egy DHCP
szerveren tbb znt is ltre tudunk hozni. Na, de... amikor beesik a kliens, mi
alapjn dl el, hogy melyik znbl kap IP cmet? Ha tbb hlzati krtya van a
DHCP szerverben, akkor mg rthet is a dolog, hiszen ezek nyilvn ms subnetbe
lgnak bele, teht a szervernek csak azt kell figyelnie, hogy az egyes hlzati krtyi
mely znkhoz tartoznak. De mi van akkor, ha a DHCP szerverben csak egy krtya
van, ennek ellenre alhlzataink szmosak?
6.2. BRA DHCP SZERVER SSZETETT HLZATBAN
Habr a helyzet vlsgos, de nem remnytelen. A fejezet sorn fny derl a titokra.
~ 291 ~

Elszr fussuk meg a ktelez krket. Milyen tipus zenetekbl llnak ssze a
DHCP folyamatai?
1. DHCPDISCOVER (FELFEDEZS): A DHCP kliens kldi, amikor keresi a DHCP
szervert.
2. DHCPOFFER (AJNLAT): A DHCP szerver kldi, amikor a DHCP kliens felfedezi.
Maga az ajnlat egy csomag, benne egy felknlt IP cmmel s egyb hlzati
paramterrel.
3. DHCPREQUEST (IGNY): A DHCP kliens kldi, ha elfogadja a szerver ajnlatt.
Ezzel egyben vissza is utastja a tbbi szerver ajnlatait.
4. DHCPACK (ELFOGADS, VISSZAIGAZOLS): A DHCP szerver tudomsul veszi a
kliens dntst - s adminisztrl.
5. DHCPNAK (NO ACK, NEM ELFOGADS): A DHCP szerver kldi a kliensnek a
DHCPREQUEST-re vlaszul, amennyiben a kliens ltal ignyelt IP cmmel
balh van. (Pldul a kliens meg akarja jtani az IP cmt, de az mr lejrt
vagy maga a kliens msik alhlzatba kltztt.)
6. DHCPDECLINE (VISSZAUTASTS): A DHCP kliens kldi a DHCP szervernek, ha
hasznlhatatlan IP cmet kap.
7. DHCPRELEASE (ELENGEDS): A DHCP kliens kldi a szervernek, amennyiben le
akar mondani az eddig hasznlt IP cmrl.
8. DHCPINFORM (INFORMCI): A DHCP kliens kldi a szervernek, amennyiben
az alap hlzati csomaghoz kpest plusz belltsokat is szeretne.
Most pedig csapongjunk t a DHCP csomag szerkezetre. Ha netn hinyrzeted
lenne, a fenti zenetek ksbb rendesen is ki lesznek bontva.
DHCP Basics:
http://support.microsoft.com/kb/169289
~ 292 ~

6.1.1 C SO M A GS Z ER K E Z ET
6.3. BRA A DHCP CSOMAG FELPTSE
Szp nagy. Meg tudnd mutatni rajta a jl megszokott tagolst: header s payload?
Bizony, nem.
Nincs. A legfels szinten vagyunk. Vagy ms nzpontbl, ez a legkisebb Matrjoska
baba. Itt mr minden payload, mg a header is. Ms szval a kisrinformcik is
rszei a protokollnak.
MESSAGE OP CODE: Request(1) vagy Reply(2)
HARDWARE ADDRESS TYPE: Hirtelen leszaladunk a fldszintre. Hardware Address?
Utoljra ilyen csnya szavakat a Network Interface rtegben hallottunk, amikor az
ARP folyamatot boncolgattuk. (3.14. bra ARP keret) Itt is ugyanarrl van sz: itt
azonostjuk be, hogy egyltaln milyen hardvert, milyen hlzati csatlakozst
hasznl a kliens. (Az Ethernet kdja 1, a Token Ring kdja 4, az EUI64 kdja meg 27.)
Hogy mg rthetbb legyen: ez a kd azt adja meg, milyen tipus MAC addressre
szmthatunk a CLIENT HARDWARE ADDRESS mezben.
~ 293 ~

HARDWARE ADDRESS LENGTH: Milyen hossz a CLIENT HARDWARE ADDRESS mezben
tallhat cm. Ethernet esetn a MAC Address 6 byte, teht ez az rtk 6.
HOPS: Hny darab DHCP Relay Agent-en87 megy keresztl a DHCP krs. RFC szerint
a maximlis rtk 16, de a Windows Server 2008 esetben ez lecskkent 4-re.
TRANSACTION ID: Vletlenszeren kivlasztott 4 bjtos rtk, ez azonostja az egy
folyamathoz tartoz zeneteket.
SECONDS: Hny msodperc telt el azta, hogy a DHCP kliens elindtotta a folyamatot.
FLAGS: Kt bjtos mez. A bal szls flag az gynevezett broadcast flag. A tbbi 15
flag ktelezen nulla, rtelmk majd valamikor a jvben lesz definilva. (Azrt
ltszik, hogy mg mindig hullanak a forgcsok.) Kliens oldali krsnl a broadcast
flag azt jelzi, hogy a kliens tud fogadni unicast mdon cmzett csomagot (0) vagy
csak a broadcast (1) j. A Windows Server 2008 / Vista DHCP kliensknt az utbbi
rtket szokta belltani.
CLIENT IP ADDRESS: A kliens IP cme, ahogy tudja.
YOUR IP ADDRESS: A kliens IP cme, ahogy a DHCP szerver tudja.
Server IP Address: A DHCP szerver cme.
GATEWAY IP ADDRESS: A krst legelszr elkap88 DHCP Relay Agent IP cme.
CLIENT HARDWARE ADDRESS: 16 bjt, a DHCP kliens hardver azonostja, Ethernet
esetben ez a 6 bjtos MAC Address. Lthat, hogy itt jn be a kpbe a korbbi kt
HARDWARE ADDRESS mez.
SERVER HOST NAME: A DHCP szerver neve. A Windows Server 2008 nem foglalkozik
ezzel a mezvel.
BOOT FILE NAME: 128 bjt, gyakorlatilag tk feleslegesen. Itt lehet trolni egy BOOTP
image elrhetsgi tjt. (A BOOTP volt a DHCP eldje.) Manapsg a DHCP mr nem
hasznlja ezt a mezt.
OPTIONS: A megszokott gumimez. Gyakorlatilag minden, ami nem frt bele az eddig
rubrikkba.
87
88
Nocsak. Alakul a magyarzat a subnetelt DHCP rendszerre.

Naa??
~ 294 ~

Remlhetleg kezd tisztulni a helyzet a sok alhlzatos pldval kapcsolatban.
6.4. BRA DHCP R ELAY A GENT KONFIGURCI
A megolds kulcsa a DHCP Relay Agent-ek megjelense. Ehhez nem kell felttlenl
plusz hardver, az brn is igyekeztem rzkeltetni, hogy meg lehet oldani a feladatot
gy is, hogy maga a hlzati eszkz - router clhardver - tudja a DHCP Relay
funkcit... de meg lehet oldani gy is, hogy az rintett alhlzaton valamelyik
Windows szerverre felrakjuk az RRAS funkcit s azon bell lltjuk be a DHCP Relay
Agent szerepkrt.
Mi is trtnik ekkor?
Az alhlzaton a kliens IP cmet szeretne krni, ezrt elkld egy DHCPDISCOVER
zenetet. Ezt a Relay Agent kapja el s kldi tovbb a DHCP szervernek - de kzben
a HOPS mezben tallhat rtket megnveli eggyel, a GATEWAY IP ADDRESS mezbe
pedig berja a sajt IP cmt - mgpedig azt, amelyik egy alhlzaton van a krst
kld klienssel. Ebbl fogja tudni a tvoli subneten lv DHCP szerver, hogy melyik
znbl adjon IP cmet a kliensnek.
~ 295 ~

6.1.2 DHCP O P T I O N S
Megint matekozssal kezdnk. Tudni kell, hogy a DHCP szigoran UDP-t hasznl
csomagszlltsra. (A kliens a 67-es porton figyel, a szerver a 68-ason.) Mit is rtunk
errl a szlltsi mdrl? Azt hogy dobozban szlltunk teljes csomagokat - azaz egy
DHCP zenetnek bele kell frnie az MTU ltal meghatrozott csomagmretbe.
Ha sszeadjuk az elbbi brn lthat rtkeket, akkor ltszik, hogy 236 bjt
biztosan lesz, ehhez jnnek majd a DHCP Options mezben tallhat adatok.
Konkrt plda: Ethernet csomag esetn az MTU 1500 bjt, a minimlis IP header 20
bjt, az UDP header 8 bjt... azaz a DHCP opcik szmra maximum 1236 bjt marad.
6.5. BRA DHCP O PTIONS
A DHCP opcik szerkezete a jl ismert smt kveti, nem is rszleteznm jobban.

Tpus, a blokk hossza, a blokk adatai... aztn jhet az jabb blokk. Amg van abbl az
1236 bjtbl.
DHCP Option Format:
http://www.tcpipguide.com/free/t_DHCPOptionsOptionFormatandOptionOverloading-2.htm
~ 296 ~
6.1. TBLZAT
Option
Option Name
Type
0
Pad
1
Subnet Mask
3
Router
6
12
15
31
33
43
44
Domain Name
Servers
Host Name
DNS Domain Name
Perform Router
Discovery
Static Route
Vendor-specific
information
WINS/NBNS Servers
Option
Length
4 bjt
Vltoz
(4*x bjt)
Vltoz
(4*x bjt)
Vltoz
Vltoz
1 bjt
Vltoz
(8*x bjt)
Vltoz
Vltoz
(4*x bjt)
1 bjt
46
NetBIOS Over
TCP/IP Node Type
47
50
51
53
NetBIOS Scope ID
Requested Address
Lease Time
DHCP Message Type
Vltoz
4 bjt
4 bjt
1 bjt
54
55
4 bjt
Vltoz
58
Server Identifier
Parameter Request
List
Renewal Time (T1)
59
Rebinding Time (T2)
4 bjt
61
81
Client Identifier
Dynamic DNS
Update
Classless Static
Route
Classless Static
Route
End
Vltoz
Vltoz
121
249
255
Magyarzat
1 bjt, az rtke 0. Elvlasztjel.
A kiajnlott cm alhlzati maszkja.
A kliens hlzatn a routerek IP cmei. Az els a Default
Gateway.
A DNS szerverek IP cmei
A kliens neve
A tartomny neve, amelyikbe a kliens tartozik.
A kliensnek a Router Discovery IP opcit kell hasznlnia a
routerek feldertshez.
Classful bejegyzsek a kliens loklis route tbljba. 4 bjt IP
cm, 4 bjt router IP cm.
Brmi, ami gyrtspecifikus.
A WINS szerverek listja.
Vltoz
A kliens NetBIOS tipusa:

1 (0001) - B node (Broadcast)
2 (0010) - P node (Point-to-Point)
4 (0100) - M node (Mixed)
8 (1000) - H node (Hybrid)
RFC 1001/1002
A krt, illetve elutastott IP cm
A brlet ideje msodpercben
A DHCP zenet tipusa
1. DHCPDISCOVER
2. DHCPOFFER
3. DHCPREQUEST
4. DHCPDECLINE
5. DHCPACK
6. DHCPNAK
7. DHCPRELEASE
8. DHCPINFORM
A DHCP szerver IP cme
Mely DHCP opcikat kri a kliens. (A Windows Server 2008 /
Vista ltal krt opcikat narancssrgval jelltem.)
Az az idtartam (sec), amelyen bell a kliensnek meg kell
jtania a brlett.
Idtartam (sec), melynek letelte utn a kliens Rebind llapotba
kerl.
A DHCP klienst azonostja. Ethernet esetben ez a MAC Address.
A kliens teljes neve (FQDN). Ezt fogja hasznlni a DHCP, ha be
kell regisztrlnia a nevet a DNS-be.
Komplett Classless bejegyzsek a kliens route tbljba: prefix,
subnet mask, next hop.
Ugyanaz, mint a 121-es.
A DHCP opcik vge. (Csupa egyesekbl ll bjt.)
4 bjt
Vltoz
Ha alaposabban megnzed, lthatod, hogy vannak mg lyukak. Ez abbl kvetkezik,

hogy a Windows alap DHCP szerverek nem tmogatjk az sszes DHCP opcit. A
teljes listt az albbi linken tallhatod.
Az sszes DHCP opci:
http://www.iana.org/assignments/bootp-dhcp-parameters/
~ 297 ~

6.1.3 DHCP
FO LY A MA T O K
6. 1 .3 . 1 E G Y N O R M L I S C M B R L S N Y L B E T S E
6.6. BRA DHCP CMBRLS
Ha nekem nem hiszel, itt van egy fot a capture fjlrl.
6.7. BRA DHCP CMBRLS
Itt fogunk vlaszt kapni az els krdsnkre: hogyan tud kommuniklni egy kliens a
hlkzaton IP cm nlkl? Az brn valami gyansat mr lthatsz is: egy csupa nulla
IP cm valami kld egy vilgmret broadcast zenet a subnetre (3. csomag), a
DHCP szerver visszabroadcastol (5. csomag), majd jbl jn a csupanulla (6.
csomag), aztn megint a DHCP szerver (7. csomag) - s a ngy zenetbl ngy
broadcast. Nos, igen. Amg nincs IP cmem, addig csak broadcasttal lehet megtallni.
(Hogyan is? gy, hogy habr mindenki felkapja a MAC/IP szint broadcast
csomagokat, de a forrsoldali MAC cmek minden csomagban benne vannak,
emellett a Transaction ID s a DHCP csomag tartalma egyrtelmv teszi, hogy kik a
trsalgsban rsztvev felek s melyek az ppen aktulis tnclpsek.)
Nzzk ezeket a lpseket. Mindenhol egy-egy csomagot fogunk boncolgatni,
mghozz gy, hogy az eredeti informcikat kln sznnel emeltem ki. Ezek kz
fogom beirklni a megjegyzseimet.
~ 298 ~
6.1 .3 .1 .1 DHC P D IS CO VER

6.2. TBLZAT
No. Time
3
0.152014
Source
0.0.0.0
Destination
255.255.255.255
Protocol
DHCP
Info
DHCP Discover - Transaction ID 0x81c0d341
Frame 3 (342 bytes on wire, 342 bytes captured)

Ethernet
II,
Src:
AsustekC_ab:37:2e
(00:1e:8c:ab:37:2e),
Dst:
Broadcast
(ff:ff:ff:ff:ff:ff)
Internet Protocol, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255 (255.255.255.255)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 328
Identification: 0x5411 (21521)
Flags: 0x00
Fragment offset: 0
Time to live: 128
Protocol: UDP (0x11)
Header checksum: 0xe594 [correct]
Source: 0.0.0.0 (0.0.0.0)
Destination: 255.255.255.255 (255.255.255.255)
Az IP fejlcbl ltjuk, hogy igen, tnyleg broadcast s tnyleg UDP. De ltunk mst is:
az Ethernet frame-ben benne van a MAC cmnk, a krds-felelet csomagokat pedig
sszekti a Transaction ID.
User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67)
Source port: bootpc (68)
Destination port: bootps (67)
Length: 308
Checksum: 0x87a6 [correct]
Mint ahogy rtam, a kliens a 68-as portot hasznlja (bootp client), a szerver pedig a
67-est (bootp server). Azaz a forrs a kliens, a cl a szerver.
Bootstrap Protocol
Message type: Boot Request (1)
Hardware type: Ethernet
Hardware address length: 6
Krsrl van sz. Ethernet krtya, azaz 6 bjtos MAC Address.

Hops: 0
Nincs DHCP Relay Agent.

Transaction ID: 0x81c0d341
Seconds elapsed: 0
Bootp flags: 0x8000 (Broadcast)
1... .... .... .... = Broadcast flag: Broadcast
.000 0000 0000 0000 = Reserved flags: 0x0000
Igen, a broadcast flag. A Vista kliensem jelezte, hogy kptelen unicast vlaszt fogadni,
csak a broadcast a j.
~ 299 ~

Client IP address: 0.0.0.0 (0.0.0.0)
Your (client) IP address: 0.0.0.0 (0.0.0.0)
Next server IP address: 0.0.0.0 (0.0.0.0)
Relay agent IP address: 0.0.0.0 (0.0.0.0)
Client MAC address: AsustekC_ab:37:2e (00:1e:8c:ab:37:2e)
Ez a MAC Address-em. Minden ms rtk res.

Server host name not given
Boot file name not given
Ez ugye az a nagy bds (128 bjtnyi) semmi.

Magic cookie: (OK)
Itt fogtunk valamit. Errl a mgikus stirl eddig mg nem esett sz.
RFC 951, 1048
Az RFC 951 rja le a BOOTP (BootStrap) protokoll mkdst. Ennek kiegsztse az
RFC 1048, amelyben a vendorfggetlen BOOTP implementcit igyekeznek
definilni. Itt mondjk ki, hogy ahhoz, hogy egy BOOTP megvalsts gyrtfggetlen
legyen, az Options meznek a kvetkez szmsorozattal kell kezddnie:
99.130.83.99. (63.82.53.63 hexadecimlisan.)
6.8. BRA M AGIC C OOKIE
Kompatibilitsi okbl a DHCP-t gy raktk ssze, hogy azt a BOOTP

vendorfggetlennek lssa - rtelemszeren emiatt a DHCP Options blokk ktelezen
ezzel a szmsorozattal kell induljon. Ez a magic cookie.
Option: (t=53,l=1) DHCP Message Type = DHCP Discover
Option: (53) DHCP Message Type
Length: 1
Value: 01
53-as opci, az zenet tipusa. Discovery. Mg j.
~ 300 ~

Option: (t=116,l=1) DHCP Auto-Configuration
Option: (116) DHCP Auto-Configuration
Length: 1
Value: 01
Megint fogtunk valamit. Ez az rtk nem szerepel a tblzatban.

RFC 2563
Az autokonfigurcirl esett mr sz, az IPv6-os rszben. Ez persze nem jelenti azt,
hogy az IPv4-ben semmi ilyesmi nem lenne. Windows krnyezetben ott van ugye az
Automated Private Addressing, azaz APIPA (169.254.0.1-169.254.255.254).
Maga a 116-os DHCP opci arrl szl, hogy poljuk valahogy a DHCP kliens lelkt, ha
nem kapott IP cmet, amikor pedig krt.
Mindegyik kliens a DHCPDISCOVER zenetben jelzi, hogy kpes-e az
autokonfigurcira, vagy sem. Jelen esetben a 01 rtk azt jelzi, hogy az enym igen.
(Nan: APIPA.) Amennyiben a DHCP szerver valamirt nem tud neki IP cmet
osztani, akkor kt dolgot tehet. Amennyiben a kliens mr jelezte, hogy kpes
nmagt konfigurlni, akkor a szerver nem foglalkozik vele. Majd megoldja.
Amennyiben viszont a kliens azt jelezte, hogy nincs autokonfigurcis
mechanizmusa, akkor a szerver visszakld neki egy DHCPOFFER csomagot, ahol is a
116-os opciban az rtk 0 - azaz DoNotAutoconfigure. Innentl kezdve a kliensre
van bzva, hogy gyorsan fejlesszen ki magnak valamilyen nmenedzsel
kpessget, ha kommuniklni akar - mert a DHCP szerver nem foglalkozik vele.
(Amennyiben a DHCP kliensben a 116-os opci rtke DoNotAutoconfigure, azaz 0
volt... s nem kap vlaszt a DHCPDISCOVER krdsre - az azt jelenti, hogy nincs
DHCP szerver a krnyken.)
Option: (t=61,l=7) Client identifier
Option: (61) Client identifier
Length: 7
Value: 01001E8CAB372E
J, megint a MAC cmnk.

Option: (t=50,l=4) Requested IP Address = 192.168.1.103
Option: (50) Requested IP Address
Length: 4
Value: C0A80167
Option: (t=12,l=2) Host Name = "hq"
Option: (12) Host Name
Length: 2
Value: 6871
Rgi IP cm, rgi nv.

Option: (t=60,l=8) Vendor class identifier = "MSFT 5.0"
Option: (60) Vendor class identifier
~ 301 ~

Length: 8
Value: 4D53465420352E30
Option: (t=55,l=12) Parameter Request List
Option: (55) Parameter Request List
Length: 12
Value: 010F03062C2E2F1F2179F92B
1 = Subnet Mask
15 = Domain Name
3 = Router
6 = Domain Name Server
44 = NetBIOS over TCP/IP Name Server
46 = NetBIOS over TCP/IP Node Type
47 = NetBIOS over TCP/IP Scope
31 = Perform Router Discover
33 = Static Route
121 = Classless Static Route
249 = Classless Static Route (Microsoft)
43 = Vendor-Specific Information
End Option
Padding
Itt azt kell ltni, hogy a Parameter Request List/Value mezben egy-egy bjt jelli a
szksges paramter azonostjt. Pldul a 'NetBIOS over TCP/IP Scope'-hoz a
0x2F azonost tartozik, mely emberi nyelvre fordtva 47.
6.1 .3 .1 .2 DHC P OF F ER
6.3. TBLZAT
No. Time
5
1.150481
Source
192.168.1.1
Destination
255.255.255.255
Protocol
DHCP
Info
DHCP Offer - Transaction ID 0x81c0d341

Ethernet
II,
Src:
Cisco-Li_f1:34:0a
(00:18:f8:f1:34:0a),
Dst:
Broadcast
(ff:ff:ff:ff:ff:ff)
User Datagram Protocol, Src Port: bootps (67), Dst Port: bootpc (68)
Bootstrap Protocol
Message type: Boot Reply (2)
Igen, ez egy vlasz.

Hops: 0
Seconds elapsed: 0
.000 0000 0000 0000 = Reserved flags: 0x0000
Nos, a szerver is csak broadcastot tud fogadni.

Hoh! Itt van a szerver ltal felajnlott IP cm!
~ 302 ~

Magic cookie: (OK)
Option: (t=53,l=1) DHCP Message Type = DHCP Offer
Length: 1
Value: 02
Option: (t=1,l=4) Subnet Mask = 255.255.255.0
Option: (1) Subnet Mask
Length: 4
Value: FFFFFF00
Option: (t=3,l=4) Router = 192.168.1.1
Option: (3) Router
Length: 4
Value: C0A80101
Option: (t=6,l=8) Domain Name Server
Option: (6) Domain Name Server
Length: 8
Value: 54022C0154022E01
IP Address: 84.2.44.1
Option: (t=51,l=4) IP Address Lease Time = 1 day
Option: (51) IP Address Lease Time
Length: 4
Value: 00015180
Option: (t=54,l=4) Server Identifier = 192.168.1.1
Option: (54) Server Identifier
Length: 4
Value: C0A80101
Itt pedig az ajnlat tbbi paramterei.

End Option
Padding
~ 303 ~
6.1 .3 .1 .3 DHC P R E QU ES T
6.4. TBLZAT
No. Time
6
1.150913
Source
0.0.0.0
Destination
255.255.255.255
Protocol
DHCP
Info
DHCP Request - Transaction ID 0x81c0d341

Ethernet
II,
Src:
AsustekC_ab:37:2e
(00:1e:8c:ab:37:2e),
Dst:
Broadcast
(ff:ff:ff:ff:ff:ff)
User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67)
Bootstrap Protocol
Message type: Boot Request (1)
Hops: 0
Seconds elapsed: 0
.000 0000 0000 0000 = Reserved flags: 0x0000
Magic cookie: (OK)
Option: (t=53,l=1) DHCP Message Type = DHCP Request
Length: 1
Value: 03
Itt jelezzk, hogy ez mr egy hatrozott krs, azaz request. Eddig csak
rdekldtnk.
Option: (t=61,l=7) Client identifier
Option: (61) Client identifier
Length: 7
Value: 01001E8CAB372E
Option: (t=50,l=4) Requested IP Address = 192.168.1.103
Option: (50) Requested IP Address
Length: 4
Value: C0A80167
Length: 4
Value: C0A80101
Option: (t=12,l=2) Host Name = "hq"
Option: (12) Host Name
Length: 2
Value: 6871
Option: (t=81,l=5) Client Fully Qualified Domain Name
Option: (81) Client Fully Qualified Domain Name
Length: 5
Value: 0000006871
Flags: 0x00
~ 304 ~

0000 .... = Reserved flags: 0x00
.... 0... = Server DDNS: Some server updates
.... .0.. = Encoding: ASCII encoding
.... ..0. = Server overrides: No override
.... ...0 = Server: Client
A-RR result: 0
PTR-RR result: 0
Client name: hq
s ezeket az rtkeket szeretnnk.

(Az utols opci - 81 - tartalma meglep egy kiss. A tblzatban viszonylag rviden
el lett intzve - itt viszont lthatjuk, hogy van benne inf bven.)
Option: (t=60,l=8) Vendor class identifier = "MSFT 5.0"
Option: (60) Vendor class identifier
Length: 8
Value: 4D53465420352E30
Option: (t=55,l=12) Parameter Request List
Option: (55) Parameter Request List
Length: 12
Value: 010F03062C2E2F1F2179F92B
1 = Subnet Mask
15 = Domain Name
3 = Router
6 = Domain Name Server
44 = NetBIOS over TCP/IP Name Server
46 = NetBIOS over TCP/IP Node Type
47 = NetBIOS over TCP/IP Scope
31 = Perform Router Discover
33 = Static Route
121 = Classless Static Route
249 = Classless Static Route (Microsoft)
43 = Vendor-Specific Information
End Option
6.1 .3 .1 .4 DHC P AC K
6.5. TBLZAT
No. Time
7
1.151844
Source
192.168.1.1
Destination
255.255.255.255
Protocol
DHCP
Info
DHCP ACK - Transaction ID 0x81c0d341

Ethernet
II,
Src:
Cisco-Li_f1:34:0a
(00:18:f8:f1:34:0a),
Dst:
Broadcast
(ff:ff:ff:ff:ff:ff)
User Datagram Protocol, Src Port: bootps (67), Dst Port: bootpc (68)
Bootstrap Protocol
Message type: Boot Reply (2)
Hops: 0
Seconds elapsed: 0
.000 0000 0000 0000 = Reserved flags: 0x0000
~ 305 ~

Magic cookie: (OK)
Option: (t=53,l=1) DHCP Message Type = DHCP ACK
Length: 1
Value: 05
Visszaigazoltuk. Tid a cm.

Option: (t=1,l=4) Subnet Mask = 255.255.255.0
Option: (1) Subnet Mask
Length: 4
Value: FFFFFF00
Option: (t=3,l=4) Router = 192.168.1.1
Option: (3) Router
Length: 4
Value: C0A80101
Option: (t=6,l=8) Domain Name Server
Option: (6) Domain Name Server
Length: 8
Value: 54022C0154022E01
Option: (t=51,l=4) IP Address Lease Time = 1 day
Option: (51) IP Address Lease Time
Length: 4
Value: 00015180
Length: 4
Value: C0A80101
End Option
Padding
~ 306 ~
6. 1 .3 . 2 E G Y C M E L E N G E D S E
Ez mr nem lesz olyan bonyolult koreogrfij trsastnc, mint az elz. A kliens

kijelenti, hogy el akar szakadni az IP cmtl - majd elszakad.
6.9. BRA DHCP R ELEASE
~ 307 ~
6. 1 .3 . 3 R E N E W S R E B U I L D
Kezdjk ott, hogy mi a klnbsg?

6.1 .3 .3 .1 R E N E W
ltalban a brleti id felnl - egsz pontosan az 58-as DHCP opciban megadott T1

id eltelte utn - a kliensnek meg kell jtania az IP cmt. Ez egy gyors tsvltssal
trtnik: jn egy DHCPREQUEST a klienstl, amire jn egy katons DHCPACK a
szervertl. Radsul ekkor mg van a kliensnek IP cme is, azaz nem kell
broadcastolni. (Legalbbis nem mindig.)
6.10. BRA DHCP R ENEW - IP CMMEL
Szpen lthat a DHCP Request s a DHCP ACK vlasz - ahol mind a kt csomagnak
rendes cmzettje s feladja van. Sz sincs semmifle broadcastrl.
~ 308 ~
6.1 .3 .3 .2 R E B U I L D
Egy kicsit cifrbb dologrl van sz. Letelt a T1 idtartam, a kliens eszeveszetten
szeretn megjtani a brlett - de a DHCP szerver nem rhet el. Terroristk
felrobbantottk. Lentttk kakaval. Elvitte a cica. Brmi. A kliens prblkozik,
prblkozik... majd ha letelt az 59-es opciban megadott T2 idtartam, akkor feladja:
jrakezd egy DHCPDISCOVERY zenettel, htha tall msik DHCP szervert.
6.11. BRA DHCP R EBUILD (F ORRS : T HE TCP/IP G UIDE , www.tcpipguide.com)
Renew and Rebind:

http://www.tcpipguide.com/free/t_DHCPLeaseRenewalandRebindingProcesses-2.htm
~ 309 ~
6. 1 .3 . 4 S U B N E T V L T S
Lttuk, mi trtnik, ha a szerver hagyja cserben a klienst. De mi van akkor, ha a

brls kells kzepn a klienst tdugjuk egy msik subnetbe? (Azok a kollgk, akik
menedzselnek llandan ton lv, telephelyek kztt cikz, laptopos gynki
hlzatot, gondolom, most megrten blogatnak.)
Nos, ez trtnik.
6.12. BRA DHCP S S UBNET VLTS
A cska T1 utn szeretn megjtani az IP cmt. El is kldi a DHCPREQUEST krst,

benne az ignyelt, de mr nem j IP cmmel - amire a szerver pofnvgja egy
DHCPNAK zenettel. Ettl a kliens megcondolodik s bklkeny hangnemben
elindt egy klasszikus DHCPDISCOVER zenettel kezdd brletkrsi folyamatot.
~ 310 ~

6.1.4 DHCP V 6
RFC 3315
Az IPv6 esetben mr egy kicsit cifrbb a helyzet. Itt ugyanis a kliensek mr egsz jl
el tudnnak boldogulni DHCP szerver nlkl is, hiszen lttuk, megvannak az
algoritmusaik ahhoz, hogy a semmibl IP cmeket kreljanak maguknak, routereket
fedezzenek fel, megljenek a jg htn.
Nyilvnval, hogy itt valahogyan rendet kell vgni, ne keveredjenek az eljrsok.
Erre a clra kt flag-et fogtak be, mely flag-ek a Router Advertisement zenetben
utaznak. (4.2.1.6 Autokonfigurci)
M FLAG (MANAGED ADDRESS CONFIGURATION FLAG): Ha magas, akkor arra utastja a
hostot, hogy az eloszt kzpontbl krjen magnak IP cmet.
O FLAG (OTHER STATEFUL CONFIGURATION FLAG): Ha magas, akkor arra utastja a
hostot, hogy az eloszt kzpontbl krje le a kiegszt hlzati konfigurcis
adatokat.
A kt flag-bl logikusan ngy szituci kvetkezik:
MINDKETT ALACSONY. Ekkor nincs DHCP a hlzaton, boldoguljon mindenki,
ahogyan tud.
MINDKETT MAGAS. A DHCP a kirly, mindent oszt. Ezt a figurt hvjk
DHCPv6 Stateful llapotnak.
O MAGAS, M ALACSONY. A hostok az IP cmeket a routerektl tudjk meg. Minden
egyb kiegszt paramtert a DHCP szerverektl. Ezt nevezik DHCPv6
Stateless llapotnak.
O ALACSONY, M MAGAS. A DHCP osztja az IP cmeket, az egyb paramterek
pedig... ht, azok a fasorban sincsenek. Ennek az opcinak inkbb csak
matematikai lehetsge van, a gyakorlatban rtelmetlen.
~ 311 ~

Menjnk bele a DHCPv6 zenetek szerkezetbe. Elljrban mit vrsz? Mondjuk,
kiindulva a korbbi brbl? (6.3. bra A DHCP csomag felptse)
Meg fogsz lepdni. Ugyanis ennyi:
6.13. BRA A DHCP V 6 ZENET SZERKEZETE
A vltozs oka, hogy a DHCPv4 igyekezett kompatibilis lenni a korbbi BOOTP

szerkezettel. (Lsd tk felesleges, risi mezk.) A DHCPv6 mr nem tztt ki maga
el ilyen clokat - gy lehetsg addott ramvonalastani a modellt, egszen addig,
amg ilyen cseppforma nem lett belle.
MSG-TYPE: Itt jelezzk, hogy milyen tipus DHCPv6 zenetrl van sz.
6.6. TBLZAT
Msgzenet
Type
1
Solicit
2
Advertise
3
Request
4
Confirm
5
6
7
Renew
Rebind
Reply
8
9
Release
Decline
10
Reconfigure
11
12
InformationRequest
Relay-Forward
13
Relay-Replay
~ 312 ~
Lers
A kliens keresi a szervert
A szerver vlaszol a Solicit krsre
A kliens konkrtan elkri az adatokat
A kliens krberdekldik az sszes DHCP szervernl, hogy amit
kapott, az j-e
Cm megjts
Cmeldobs, amennyiben nem sikerlt a Renew
A szerver visszaigazolja a krseket (request, confirm, rebind,
reply)
A kliens zeni, hogy p, kisaranyom.
A kliens zeni a szervernek, hogy az rossz anyagot szlltott ilyen cm mr van.
A szerver zeni a kliensnek, hogy vltoztak a konfigurcis
adatai, nzzen be jra. A kliens ilyenkor vagy Renew, vagy
Information-Request zenettel prblkozik.
A kliens konfigurcis informcikat kr. (De IP cmeket nem.)
A DHCP Relay Agent kldi az eredeti DHCP krst, DHCPv6
Relay-Message zenetbe csomagolva.
A DHCP szerver vlaszol a Relay Agent-nek, szintn RelayMessage zeneten keresztl.
DHCPv4
megfelelsg
DHCPDiscover
DHCPOffer
DHCPRequest
DHCP Request
DHCPRequest
DHCPRequest
DHCPAck
DHCPRelease
DHCPDecline
DHCPInform
-

TRANSACTION-ID: A szoksos folyamat azonost.
OPTIONS: Ebben a vltoz mret mezben tallhat a lnyeg. A megszokott mdon, azaz blokkokra bontva - itt van minden, amit a felek kzlni szeretnnek egymssal.
6.14. BRA DHCP V 6 O PTIONS
OPTION CODE: Az opci azonostja

OPTION-LEN: Az opci mrete bjtban.
OPTION-DATA: Ebben a vltoz mret mezben jnnek az adatblokkok.
A 6.11. tblzatban megemltettem egy eddig mg nem trgyalt zenettpust, a DHCP
Relay-Message zenetet. Valamirt gy gondoltk az RFC alkoti, hogy a Relay
Agent-en keresztli kommunkcit nem DHCPv6 opcikon keresztl valstjk meg,
hanem kln zenettpust vezetnek be erre a clra.
6.15. BRA DHCP V 6 R ELAY -M ESSAGE
MSG-TYPE: Ez ugyanaz, mint a msik tipusnl.

HOP-COUNT: Hny Agent-en keresztl rkezett meg a krs a szerverhez.
LINK-ADDRESS: A Relay Agent azon IP cme, amelyikkel arra a hlzatra nz, ahol a
krst kezdemnyez DHCP kliens lakik.
~ 313 ~

PEER-ADDRESS: Vagy a DHCP kliens, vagy az elz Relay Agent IP cme.
OPTIONS: A Relay-Message opcik adatblokkjai.
Vgezetl fussuk t, hogyan is trtnik egy stateful s egy stateless DHCP
cmkiosztsi folyamat.
Stateful, azaz az M s az O flag-ek is magasak, mindent a DHCP szerver oszt:
A kilens kld egy Solicit zenetet, hogy rtalljon a szerverre.
A szerver kld egy Advertise zenetet, miszerint nla van olyasmi, amit a
kliens keres.
A kliens visszakld egy Request zenetet, immr a konkrt szervernek,
miszerint kell neki az anyag.
A szerver egy Reply zenetben elkldi a krt adatokat.
Stateless, azaz csak az O flag magas, a DHCP szerver IP cmet nem, csak egyb
konfigurcis adatokat (domain nv, netbios nvfelolds tipusa, stb...) oszt:
A kliens kld egy Information-Request zenetet, konkrtan a szervernek.
A szerver egy Replay zenetben elkldi a krt adatokat.
~ 314 ~
6.2 D OMAIN N AME S YST EM (DNS)

Az elz fejezetben a MAC Address - IP cm sszerendelsen prgtnk, a mostani
fejezetben feljebb lpnk a hierarchiban: az 'IP cm - mindenfle tartomnyi nevek'
(FQDN) sszerendelssel fogunk foglalkozni.
Ezt az sszerendelst nevezik DNS-nek - az adminisztrlst pedig DNS szerverek
vgzik. DNS kliensnek neveznk mindenkit, akinek valamilyen foly gye van a DNS
szerverekkel: cmet szeretne beregisztrlni, trlni, lekrni... vagy elkrni egy teljes
zna adatait. Ilyen rtelemben a DNS szerver is lehet ms irnyban DNS kliens.
A kommunikci DNS zenetek formjban megy, az 53-as porton. Ez alkalomtl
fggen vagy UDP vagy TCP szlltsi protokollon keresztl trtnhet.
De mi is ez az alkalom?
Nos, megint a mret a lnyeg.
Tudjuk, hogy ha egy zenetet az UDP-re bzunk, akkor annak ktelezen bele kell
frnie egy csomagba. Ez a DHCP-nl nagyjbl tarthat is volt - ezzel szemben a
DNS-ben a mezk tbbsge rugalmas mret, radsul a kommunikci jellegbl
kvetkezen nagy mennyisg adat is utazhat a csomagban - gondoljunk bele
pldul egy znatranszferbe.
Innentl viszonylag egyszer az algoritmus: ha belefrnk egy csomagba, akkor
UDP, ha nem frnk bele, akkor TCP. Ebbl jn az, hogy a znatranszfer nagy esllyel
TCP-n keresztl megy, mg a lekrdezsekhez elg az UDP is.
Ngy zenettpust klnbztetnk meg:
DNS NAME QUERY REQUEST: A DNS kliens kldi a szervernek, gyakorlatilag egy
nvfeloldsi krelem.
DNS NAME QUERY RESPONSE: A DNS szerver kldi a kliensnek, vlaszul a
nvfeloldsi krelemre.
DNS UPDATE: A DNS kliens kldi a szervernek, be szeretne jegyezni egy
rekordot.
DNS UPDATE RESPONSE: A szerver kldi a kliensnek, mi trtnt a bejegyzsi
krelmvel.
~ 315 ~

6.2.1 DNS N A ME Q UE R Y R E Q U EST
N AM E Q U E RY R E SP O N S E
Z EN ET EK
Nagy vonalakban mindkt zenettpus gy nz ki:
6.16. BRA DNS N AME Q UERY R EQUEST S N AME Q UERY R ESPONSE
Habr itt mr nem kellene header+payload formban kettszedni a csomagot, de

nem is tilos. A protokoll tervezi gy gondoltk, a fix mret rszt header-nek
nevezik, a vltoz mreteket meg... sehogy. Azok egyszeren csak mezk.
Mg valami. Mit is takar az RR rvidts? Resource Record - azaz egy bejegyzs a
DNS szerveren. Nagyon sokszor fog szerepelni a fejezetben.
~ 316 ~
6. 2 .1 . 1 D NS Q U E R Y H E A D E R
6.17. BRA DNS H EADER A FKUSZBAN
A 12 bjtnyi rsz a kvetkezkppen tagozdik tovbb.
6.18. BRA DNS H EADER (N AME Q UERY R EQUEST / N AME Q UERY R ESPONSE )
TRANSACTION ID: A DHCP-nl megismert azonost. A kliens generlja, mindenki ms

mr csak bemsolgatja.
~ 317 ~

FLAGS: A szoksos tudatmdost zszlcskk.
6.19. BRA A FLAGS MEZ
REQUEST / RESPONSE: Request(0) vagy Response (1)

OPERATION CODE: Pontosan mit is csinl a szerver a csomaggal. Jelen esetben az rtke
0, ez a query kdja.
AUTHORITATIVE ANSWER: rtke 1, amennyiben a vlasz a znra nzve autoritatv
szervertl jtt. (Azaz a szerver kezeli a znt, nem kellett tovbbmennie ms DNS
szerverekhez krdezskdni.)
TRUNCATION: Ezen a flag-en keresztl jelezzk, hogy balh van. Nem frtnk bele az
UDP csomagba. Az zenet els adagja mg elment UDP-n, de innentl a felek TCP
kapcsolatot nyitnak s azon folytatjk tovbb a kommunikcit.
RECURSION DESIRED: Amikor a krdez eldnti, hogy rekurzv query-t szeretne (1) azaz ha a DNS szerver nem autoritativ a krdezett nv znjra nzve, akkor menjen
utna a krsnek s keresse meg a znt valamelyik egyb DNS szerveren - vagy
csak dobja vissza azon DNS szerverek listjt (0), amelyeken j esllyel ott lesz a
keresett zna.
RECURSION AVAILABLE: A szerver jelzi vissza a Query Response-ban, hogy egyltaln
kpes-e rekurzv keresst vgrehajtani. (1 az igen, 0 a nem.)
RESERVED: Elspjzoltunk nmi bitet rosszabb idkre.
RETURN CODE: A Query Response-ban jtszik szerepet. Jelzi, hogy mi is trtnt
tulajdonkppen a krssel.
~ 318 ~
A teljessg ignye nlkl.

6.7. TBLZAT
Kd
0
1
2
3
4
5
6
7
8
9
10
Lers
Siker
Format Error
Szerverhiba
Nemltez domain
Not implemented
Query elutastva
Ltez nv, mely nem ltezhetne
RR, mely nem ltezhetne
RR, melynek lteznie kellene
A szerver nem autoritatv a znra
A nv nincs a znban
Ok, kijttnk a FLAGS mezbl, folytassuk tovbb a DNS header boncolgatst.

QUESTION ENTRY COUNT: Hny bejegyzs lesz a Question Entry mezben.
ANSWER RR COUNT: Hny bejegyzs lesz az Answer RR mezben.
AUTHORITY RR COUNT: Hny bejegyzs lesz az Authority RR mezben.
ADDITIONAL RR COUNT: Hny bejegyzs lesz az Additional RR mezben.
~ 319 ~
6. 2 .1 . 2 Q U E R Y Q U E S T I O N E N T R I E S
6.20. BRA F KUSZBAN A Q UESTION E NTRY
Valahogy gy nz ki a mezn belli adatszerkezet.
6.21. BRA Q UESTION E NTRIES
QUESTION NAME: Vltoz mret mez. Itt utazik maga a krds. A cm, aminek a
feloldsra vlaszt szeretnnk kapni. A kdolsa... minimum bjos.
6.22. BRA Q UESTION N AME
A fenti kpen az ltszik, hogy megkrdeztem a DNS szerveremet, vajon mi a

www.index.hu host IP cme. Eddig rendben is van... de vessnk mr egy pillantst a
Packet Bytes rszre! Hogy is van ez?
~ 320 ~

gy. A sorozat els bjtja az els cimke hosszt jelzi. Jelen esetben ez a www, azaz
hrom bjt. Lthatod is: 03 77 77 77, ahol a hexadecimlis 77 (decimlisan 119) a
'w' bet ASCII kdja. A kvetkez cimke t bet - index - , teht 05 69 6e 64 65 78
lesz a kd. Vgl hasonl logikval jn a vge: ktbets cimke - hu - azaz 02 68 75.
QUESTION TYPE: Kt bjt. A Resource Record tipusa.
6.8. TBLZAT
Tipus
0x01
0x02
0x05
0x06
0x0C
0x0F
0x1C
0x21
0xFB
0xFC
0xFF
Nv
Host Address (A) rekord
Name Server (NS) rekord
Alias (CNAME) rekord
Start of Authority (SOA) rekord
Reverse-lookup (PTR) rekord
Mail Exchanger (MX) rekord
IPv6 host (AAAA) rekord
Server Selection (SRV) rekord
Incremental Zone Transfer (IXFR) rekord
Standard Zone Transfer (AXFR) rekord
All records
A fenti kpen (6.22. bra Question Name) lthat (00 01), hogy 'A' rekordot krtem
le.
Question Class: Kt bjt. DNS esetben mindig 1. Ez jelzi az (IN) class-t.
~ 321 ~
6. 2 .1 . 3 Q U E R Y E R F O R R S R E K O R D O K
6.23. BRA F KUSZBAN AZ ERFORRS REKORDOK
Mivel formailag teljesen megegyeznek, gy nincs rtelme kln trgyalni ezt a hrom
mezt.
6.24. BRA DNS RR FORMTUM A Q UERY R ESPONSE CSOMAGBAN
RR NAME: A feloldott nv FQDN-je. Br van, amikor kicsit trkks maga az adat

trolsa.
Nzzk csak meg az albbi brt! Mutatni azt mutatja a Wireshark, hogy a
visszaadott FQDN a www.index.hu - de a Packet Bytes rszben csak annyit ltunk,
hogy C0 0C. Bartom, micsoda tmr trols mr!
De hogyan lehet ezt visszakdolni? nmagban sehogy. Ez ugyanis jelen esetben egy
pointer s azt mutatja meg, hogy csomagon bell hol szerepel mr egyszer ez a nv.
Hol is? Nem sokkal felette. A Query blokkjn bell a Question Name mezben.
Mghozz gy, hogy a hosszt sem kell ismernnk, hiszen minden cimke eltt ott
van a konkrt bjtok szma.
~ 322 ~
6.25. BRA RR N AME MEZ TROLSA
Akik szeretnek matekozni, azokat valsznleg rdekelni fogja, mirt pont c0 0c lett
ez a pointer.
Ez ugye kt bjt. rjuk fel binris formban:
11000000 00001100
Az els kt bit jelzi, hogy ez pointer lesz. Azokat le is kaphatjuk a tblrl.
000000 00001100
Mennyi is ez decimlisban? 12.
6.26. BRA RR N AME TMRTVE
Kezdjnk el szmolni. Jelen esetben a bemeszelt rsz a DNS csomag, azon bell kell
megkapnunk a Question Name kezd bjtjnak a szmt. Aszongya, 1, 2, 3, ..., 13.
Iz.
Neknk meg 12 jtt ki.
~ 323 ~

Szmoljuk jra, de most mr gy, hogy a nulla is jtszik89: 0, 1, 2, 3, ..., 12.
gy mr j.
RECORD TYPE: A 6.8. tblzat alapjn megadott kd.
RECORD CLASS: Ugyangy 1, azaz (IN), mint a krdsnl.
TIME TO LIVE: Ennyi ideig lehet cache-ben trolni a feloldott rtket.
RESOURCE DATA LENGTH: A vlaszknt visszaadott rtk mrete.
RESOURCE DATA: A vlaszknt visszaadott rtk.
89
Informatikusok vagyunk, vagy mi a szsz?
~ 324 ~

6.2.2 DNS U P DA T E
U P DA T E R E SP O N S E
Z EN ET E K
Eddig krdezgettnk s vlaszolgattak. Csakhogy azokat az rtkeket be is kell rakni

a DNS adatbzisba (znafjl), st, karban is kell tartani.
Errl fog szlni a fejezet.
6.27. BRA DNS U PDATE S U PDATE R ESPONSE CSOMAGSZERKEZETEK
Egy dzsa v, mi? Deht jl bevlt formn ne vltoztass, gondolhattk a tervezk.
~ 325 ~
6. 2 .2 . 1 D NS U P D A T E S U P D A T E R E S P O N S E H E A D E R
6.28. BRA DNS H EADER A FKUSZBAN
A fejlc szerkezete szintn nagyon hasonl.
6.29. BRA DNS U PDATE S U PDATE R ESPONSE HEADER
TRANSACTION ID: t mr ismerjk.
~ 326 ~

FLAGS: Itt mr nincs olyan sok.
6.30. BRA A FLAG MEZ SZERKEZETE A DNS U PDATE S U PDATE R ESPONSE FEJLCBEN
REQUEST / RESPONSE: Update (0), Response (1).

OPERATION CODE: Hasonl, mint a DNS Query Flag mezjben, csak az Update kd
rtke 5.
RESERVED: A jvnek tartogatva.
RETURN CODE: A Response zenetben jelzi, mi lett az akci vgkimenetele.
6.9. TBLZAT
Return
zenet
Code
0
Az update sikeres volt.
1
Format error: a DNS szerver nem tudott mit kezdeni a krssel
2
A DNS szerver begolyzott.
3
A nv, amelyiknek lteznie kellene, nem ltezik.
4
A DNS szerver nem tudja rtelmezni a megadott Operation Code-ot.
5
A DNS szervernek nincs kedve elvgezni a krt nvfeloldst.
6
A nv, melynek nem lenne szabad lteznie, ltezik.
7
Egy RR set, amelynek nem lenne szabad lteznie, ltezik.
8
Egy RR set, amelynek lteznie kellene, nem ltezik.
9
A DNS szerver nem autoritatv a krt znra nzve.
10
A nv, melyet megadtunk a Prerequisite illetve Update mezkben, nem tallhat meg a Zone
Entries mezben.
A FLAGS mez ismertetse utn trjnk vissza a header mezihez.

ZONE ENTRY COUNT: A Zone Entry mezben az elemek szma.
PREREQUISITE RR COUNT: A Prerequisite RR mezben az elemek szma.
UPDATE RR COUNT: Az Update RR mezben az elemek szma.
ADDITIONAL RR COUNT: Az Additional RR mezben az elemek szma.
~ 327 ~
6. 2 .2 . 2 U P D A T E Z O N E E N T R I E S M E Z
6.31. BRA F KUSZBAN A Z ONE E NTRIES MEZ
A mez adatszerkezete a kvetkezkppen nz ki.
6.32. BRA Z ONE E NTRY ADATSZERKEZET
ZONE NAME: Vltoz mret mez, a zna teljes neve. Az adatok brzolsa a
korbban megismert mdon (szm, cimke, szm, cimke, stb...) trtnik.
ZONE TYPE: Fix 6-os. A 6.8. tblzat szerint ez a SOA kdja.
ZONE CLASS: 1, azaz (IN).
~ 328 ~
6. 2 .2 . 3 U P D A T E E R F O R R S R E K O R D O K
Ez a plya.
6.33. BRA E RFORRSREKORDOK A F KUSZBAN
RFC 2136
A Prerequisite Resource Records mezben tulajdonkppen erforrs rekordokra
vonatkoz elfeltteleket adhatunk meg. Ezt gy kell rteni, hogy az update csak
akkor trtnhet meg, ha ezen felttelek mindegyike igaz.
A felttelek konkrt megadsa nem knnyen lthat t. Ebbe a mezbe ugyanis
Resource Record-okbl ll set-ek kerlnek, mghozz a normlistl nmileg eltr
feltltssel. (A Resource Record felptst az albbi bra mutatja: 6.24. bra DNS RR
formtum a Query Response csomagban.) Attl fggen, hogyan varilom meg a
feltltsi szintaxist, t feltteltipust hasznlhatunk:
Az erforrs rekord csomagban lv erforrs rekordok kzl legalbb az
egyik ltezik a szerveren.
Az erforrs rekord csomagban lv sszes erforrs rekord ltezik a
szerveren.
Az erforrs rekord csomagban lv egyik erforrs sem ltezik a szerveren.
A megadott nvvel legalbb egy erforrs rekord ltezik a szerveren.
A megadott nvvel egy erforrs rekord sem ltezik a szerveren.
Az Update Resource Records mezben azokat az erforrs rekordokat talljuk,
melyeket vagy hozz kell adni az rintett znkhoz, vagy ki kell trlni bellk.
Az Additional Resource Records mezben pedig az update-hez tartoz egyb
erforrs rekordok utaznak.
~ 329 ~

6.2.3 DNS
F O L Y A M AT O K
A szraz felsorolsok utn jjjenek a jval izgalmasabb pldafolyamatok. Kezdjk a

legsrbben hasznlt folyamattal, a nvfeloldssal.
6. 2 .3 . 1 N V F E L O L D S
6.34. BRA DNS Q UERY
Ez ilyen egyszer dolog. Egy csomag oda, egy csomag vissza.

6.10. TBLZAT
No.
Time
3
0.036883
Source
192.168.1.104
Destination
84.2.44.1
Protocol
DNS
Info
Standard query A www.index.hu

Ethernet
II,
Src:
Intel_d6:a9:4f
(00:0e:35:d6:a9:4f),
Dst:
Cisco-Li_f1:34:0a
(00:18:f8:f1:34:0a)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 58
Identification: 0x4673 (18035)
Flags: 0x00
Fragment offset: 0
Time to live: 128
Protocol: UDP (0x11)
Header checksum: 0xb22c [correct]
Source: 192.168.1.104 (192.168.1.104)
Destination: 84.2.44.1 (84.2.44.1)
Az IP fejlcben tl sok rdekessg nincs, az n IP cmem 192.168.1.104, a DNS

szerverem pedig 84.2.44.1.
User Datagram Protocol, Src Port: audio-activmail (1397), Dst Port: domain (53)
Source port: audio-activmail (1397)
Destination port: domain (53)
Length: 38
Checksum: 0xeb42 [correct]
Ezt egy kicsit benzte a Wireshark, de nem ezrt szeretjk. Tudjuk, hogy a kliens
hogyan kapcsoldik a szerverhez: forrsknt n. kliens portot (1024-65535)
hasznl, cmzettknt meg az n well-known portot, mely a protokoll RFC-jben kerl
ajnlsra. Az UDP 53 a szerver oldalon rendben is van - de a kliens oldalon lv,
vletlenszeren kivlasztott user port pont megegyezik egy ritkn hasznlt
~ 330 ~

protokoll ajnlott portszmval. gy "ismerte" fel a program audio-activmail
kommunikcinak a nvfeloldsi krelmet.
Domain Name System (query)
[Response In: 4]
Transaction ID: 0x0002
Ezt generlta a kliensem ktbjtos tranzakciazonostnak. Nem erltette meg

magt.
Flags: 0x0100 (Standard query)
0... .... .... .... = Response: Message is a query
.000 0... .... .... = Opcode: Standard query (0)
.... ..0. .... .... = Truncated: Message is not truncated
.... ...1 .... .... = Recursion desired: Do query recursively
.... .... .0.. .... = Z: reserved (0)
.... .... ...0 .... = Non-authenticated data OK: Non-authenticated
unacceptable
data
is
Semmi extra, a korbbi fejezet alapjn minden flag knnyen rthet.

Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Egy cmet szeretnk feloldani. Az RR mezk logikusan resek, hiszen ezek a vlaszok
szmra vannak fenntartva.
Queries
www.index.hu: type A, class IN
Name: www.index.hu
Type: A (Host address)
Class: IN (0x0001)
A j hossz bevezet utn lssuk vgre magt a krdst is. A feloldand nv a

www.index.hu (emlksznk mg arra a bjos kdolsra), ez egy 'A' rekord,
mghozz az IN osztlyban.
~ 331 ~

Jhet a vlasz.
6.11. TBLZAT
No. Time
4
0.051583
Source
824.2.44.1
Destination
192.168.1.104
Protocol
DNS
Info
Standard query response A 217.20.130.97

Ethernet
II,
Src:
Cisco-Li_f1:34:0a
(00:18:f8:f1:34:0a),
Dst:
Intel_d6:a9:4f
(00:0e:35:d6:a9:4f)
User Datagram Protocol, Src Port: domain (53), Dst Port: audio-activmail (1397)
Source port: domain (53)
Destination port: audio-activmail (1397)
Length: 113
Checksum: 0x1bc7 [correct]
Igen, mg mindig audio-activmail.

Domain Name System (response)
[Request In: 3]
[Time: 0.014700000 seconds]
Transaction ID: 0x0002
Azonost: stimmel.
Flags: 0x8180 (Standard query response, No error)
1... .... .... .... = Response: Message is a response
.000 0... .... .... = Opcode: Standard query (0)
.... .0.. .... .... = Authoritative: Server is not an authority for domain
.... ..0. .... .... = Truncated: Message is not truncated
.... ...1 .... .... = Recursion desired: Do query recursively
.... .... 1... .... = Recursion available: Server can do recursive queries
.... .... .0.. .... = Z: reserved (0)
.... .... ..0. .... = Answer authenticated: Answer/authority portion was not
authenticated by the server
.... .... .... 0000 = Reply code: No error (0)
Megint nincs semmi rdekes a zszlcskk krnykn.

Questions: 1
Answer RRs: 1
Authority RRs: 2
Additional RRs: 1
Itt viszont hirtelen megszaporodtak az adatok.

Queries
www.index.hu: type A, class IN
Name: www.index.hu
Class: IN (0x0001)
Answers
www.index.hu: type A, class IN, addr 217.20.130.97
Name: www.index.hu
Class: IN (0x0001)
Time to live: 7 minutes, 33 seconds
Data length: 4
Addr: 217.20.130.97
~ 332 ~

Egyfell lthatjuk az eredeti krdsnket a Queries mezben, de lthatjuk a vlaszt mit vlaszt, vlaszrengeteget - is az RR mezkben. A legfontosabb: itt van a krt IP
cm. Mghozz precz hasznlati utastssal: egsz pontosan 7 perc 33 msodpercig
tarthatom bent a DNS gyorstramban. (Emlksznk? Itt szoktk a nevet pointerrel
kivltani.)
Authoritative nameservers
index.hu: type NS, class IN, ns ns.index.hu
Name: index.hu
Type: NS (Authoritative name server)
Class: IN (0x0001)
Data length: 5
Name server: ns.index.hu
index.hu: type NS, class IN, ns ns.inventra.hu
Name: index.hu
Type: NS (Authoritative name server)
Class: IN (0x0001)
Data length: 14
Name server: ns.inventra.hu
Jnnek az extrk. Az Authority RR mezbl pldul megtudhatom, mely DNS

szerverek tekinthetk autoritatvnak az index.hu znra nzve.
(Ezeket lehet DOSolni9091.)
Additional records
ns.index.hu: type A, class IN, addr 195.56.65.172
Name: ns.index.hu
Class: IN (0x0001)
Time to live: 18 hours, 59 minutes, 50 seconds
Data length: 4
Addr: 195.56.65.172
Ez pedig mr az abszolt extra: az index.hu DNS szervernek 'A' rekordjt is

lthatjuk.
90
91
Vicc volt.
Rossz vicc.
~ 333 ~
6. 2 .3 . 2 R E V E R Z N V F E L O L D S
Ez az elz nvfelolds fordtottja: tudunk egy IP cmet, de nem tudjuk, milyen

nvhez tartozik. Termszetesen ezt is megkrdezhetjk. A folyamat teljesen hasonl,
nem is mennk tlzottan rszletesen bele.
6.35. BRA R EVERZ NVFELOLDS , Q UERY
Lthat, hogy nv helyett a Question Name mezben most egy IP cm, pontosabban
egy IP cmbl kpzett elnevezs ll. (Az egyes cimkk tovbbra is ASCII kdokkal
troldnak.) A tpus is ms egy kicsit, most nem 'A' rekordra vadszunk, hanem
'PTR'-re. De minden ms stimmel.
~ 334 ~
6.36. BRA R EVERZ NVFELOLDS , Q UERY R ESPONSE
Szpen vissza is kaptuk, hogy az IP cmhez tartoz reverz bejegyzs a sportgeza.hu.

Nmileg fura lehetne, mivel mi az index.hu cmre szmtottunk... de vglis nem az.
Ilyesmi simn elfordul mg a jobb csaldokban is.
~ 335 ~
6. 2 .3 . 3 H O G Y A N C S I N L J U N K H L Y T M A G U N K B L ?
A vge fel kzelednk, itt mr egy kicsit elengedhetjk magunkat. Mindenki dljn
htra a szkben92, helyezze magt knyelembe. Meslni fogok.
Egyik gyfelnk frissen bezemelt alternatv levelezsi kijratval baj volt. Ha azon
ment ki egy levl, akkor nagy valsznsggel nem rkezett meg a cmzetthez,
radsul hibazenet sem rkezett vissza. Nem kicsit volt knos, az gyfl zleti
tevkenysge ugyanis ersen emailfgg.
ltalban mikor nem rkezik hibazenet? Ha a tloldalon lv levelezszerver
szpemnek tekinti a kldemnyt. Hlye lenne a szpemmert informcikkal tmni.
De mirt tekintettek minket szpemmernek? s mirt csak nhnyan?
Nmi nyomozs utn kiderlt, hogy azokkal a cmzettekkel volt baj, ahol az
gyfelnk levelezsi kijratt reverz DNS vizsglattal ellenriztk. Ez abbl ll, hogy
megnztk, milyen IP cmrl rkezett meg a levl, rkrdeztek, hogy ehhez az IP
cmhez milyen FQDN tartozik - s ha talltak ehhez tartoz MX rekordot az gyfl
znjban, akkor a levl nem volt szpem. Feltehetleg.
Innentl mr snen voltam: elkezdtem tesztelni a kijratra vonatkoz nvfeloldst.
Elkesert eredmnyt kaptam: mind a nagyvilgban, mind a magyar neten teljesen
vletlenszer volt, hogy mely DNS szervereknl mkdik a reverz lekrdezs s
melyeknl nem.
Jobb hjn sszelltottam egy terjedelmes lerst a jelensgrl, elkldtem az gyfl
DNS szolgltatjhoz. Nzzk meg, oldjk meg... csinljanak valamit.
(A kvetkez oldalon az index.hu pldjn mutatom be a hlyesgemet.
Termszetesen az eredeti gyfl _nem_ az index.hu volt. Jl is nznk ott ki a
Windows-os tudsommal.)
92
Aki ilyen derkgygysz bszme gumilabdn l, az inkbb ne.
~ 336 ~

Idemsolom, hogy n mit lttam hibnak.
6.37. BRA E GY NORMLIS , ODA - VISSZA NVFELOLDS
6.38. BRA E Z MEG MI ?
Vletlenszeren kivlasztottam az Externet DNS szervert, elkezdtem a reverz

nvfeloldst - s azt kaptam, hogy a DNS szerver szerint nincs ilyen rekord.
- Ez az! - gondoltam - Most megvagy!
~ 337 ~

A szolgltat visszahvott, hogy nem ltja a problmt. Mit nem lt? - jttem
zavarba - vilgosan ott van, hogy "no records"? Az nem szmt, legyintettek r. Aztn
turkltak valamit, javtgattak valamit93, majd azt mondtk vrjak pr hetet, oszt j
lesz.
Eltelt pr ht. Lefuttattam a fenti prbt, ugyangy elhasalt. Ekkor rtam egy kedves,
de azrt kicsit vitriolos levelet, hogy ez mg mindig nem j. Erre a szolgltat
kedvesen ugyan, de elkldtt a wikipedia DNS-sel foglalkoz oldalra. Engem. Aki
ppen hlzati szolgltatsokrl is szl knyvet rt.
Forrt bennem a harag. A levelezkliensem Draft folderben mr formldott a
vlaszlevl, mely mr egyltaln nem volt kedves, cserbe egy kicsivel tbb vitriol
jutott bele.
Itt jrtunk, amikor elkezdtem mlyebben foglalkozni jelen fejezettel. s megtalltam.
Amikor megrtettem, nem gyztem szgyenemben a pokrc al bjni.
6.39. BRA 2. PRBLKOZS , Q UERY
Tessk megnzni az brt. Ez ugye az n. sikertelen feloldshoz vezet folyamat els

lpse, a lekrdezs. Az IP cm, akinek kldtem, az a prins.externet.hu, a lekrdezett
IP cm, amelyhez a nevet kerestem, az a 217.20.130.97. A flag-ek alapjn rekurzit
krtem (recursion desired), azaz azt, hogy ha a feloldand cmhez tartoz zna nincs
93
Pontosan tudom, mit javtottak, de ennyire nem akarom kiadni az gyfelet.
~ 338 ~

a megclzott DNS szerveren, akkor legyen kedves, jrjon mr utna, hogy hol van s
krje el a nevemben a nevet.
Ehhez kpest mi trtnt?
6.40. BRA 2. PRBLKOZS , Q UERY R ESPONSE
Ltsz a vlaszban feloldott nevet? Nem. A Queries mez utn rgtn az Authority RR
mez jn, nincs sehol Answer RR. Mirt nincs? A flag-eket kell megnzni. Ott ll
feketn-fehren a Recursion Available flag-ben, hogy "Server can't do recursive
queries". Ezt a DNS szervert gy konfigurltk, hogy ne dolgozzon ms helyett. Ha
rekurzv lekrdezsre utastjk, akkor visszadobja, hogy merre indulna el - s
ennyi. Ez az inf van az Authority RR mezben s ezt az inft dobja fel az brn
(6.38. bra Ez meg mi?) is.
Nzznk egy ellenprbt. Lthat, hogy a nagy magyar interneten volt olyan DNS
szerver is, mely kpes volt feloldani az gyfl cmt. (6.37. bra Egy normlis, odavissza nvfelolds)
~ 339 ~
6.41. BRA A SIKERES Q UERY R ESPONSE
Amikor ezt a szervert krdeztem, akkor mr teljesen ms lett a helyzet. A Recursion

Available flag rtke 1, azaz "Server can do recursive queries". s meg is csinlta,
lthatod, ott van a vlasz az Answer RR mezben.
Nos, ennyi. Amikor n elkezdtem jtszogatni akr a magyar, akr a klfldi DNS
szerverekkel, akkor attl fggen, hogy a helyi rendszergazda hogyan konfigurlta
azokat, vagy kaptam j vlaszt (ekkor a szerver j fi volt s megkereste helyettem
az rtket a neten) vagy nem (ekkor csak az elindulshoz kaptam segtsget).
Nyilvn ha n DNS szerver lettem volna, akkor az utbbi esetben nekem kellett volna
utnamennem az informcinak. De mivel nem az voltam, hanem csak egy
htkznapi, szomor Command prompt, gy a trtnet azzal vgzdtt, hogy "no
records".
Baromi nagy mzli, hogy azt a durvn papriks levelet vgl nem kldtem el. A
szolgltatnak ugyanis maximlisan igaza volt.
~ 340 ~

6.2.4 DNS
AZ
IP V 6- B AN
Tudom, vannak olyan rendszergazdk, akik fejbl tudjk a cgknl elfordul

sszes IP cmrl, hogy melyik ki. Amikor kicsi (200-250 fs) cgnl dolgoztam, ahol
mindenkinek fix IP cme volt, mi is tudtuk, mekkora prioritssal kellett kirontani az
IT szobbl, ha IP conflict zenet ugrott fel.
De... belegondoltl mr? Egy IPv6 cm ngyszer olyan hossz.
Mondjuk a jelenlegi gpem ilyen: fe80:0:0:0:21e:8cff:feab:372e. Meg se prblom
decimlisban lerni. Ki fogja ezeket fejbl tudni?
A DNS szerver. s rajta kvl ms senki.
Ezrt kiemelten fontos, hogy jl mkdjn.
Tegyk fel, hogy jl mkdik. Akkor hogyan fog kinzni benne egy IPv6 bejegyzs?
Hogyan fog belefrni 16 bjt a 4 bjtnyi rubrikba?
Sehogy.
RFC 1886
Be lett vezetve az IPv6 cmek szmra egy j rekordtpus, a quadA, azaz AAAA
rekord. (Azrt 4 darab 'A' mert a mrete pont ngyszerese az IPv4-ben lv 'A'
rekord mretnek.)
Ha nlam lenne itthon IPv6-ra felokostott DNS szerver, gy nzne ki a bejegyzsem:
hq.petrenyi.local
IN
AAAA
fe80::21e:8cff:feab:372e
Ok. s mi a helyzet a reverz nvfeloldssal. Belegondoltunk? Szrkl mr a
tekintetnk?
Hogy is nzett ez ki IPv4 alatt?
IP cm
: 192.168.1.103
A reverz zna neve : 1.168.192.in-addr.arpa
Bejegyzs
: 103 IN
PTR hq.petrenyi.local
A gpnv
: 103.1.168.192.in-addr.arpa
~ 341 ~

Az a reverz zna nv, az fog itt problmkat okozni. Elszr is, IPv6 esetben nem
fogunk visszavltani decimlisba. Az olyan gyerekes.
Elszr felrjuk az IP cmet, teljesen kibontva:
F.E.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.1.E.8.C.F.F.F.E.A.B.3.7.2.E
Aztn keresnk egy fix pontot, majd kiforgatjuk a sarkbl:

E.2.7.3.B.A.E.F.F.F.C.8.E.1.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F
s akkor mr csak az ismers farkat kell a vgre csapni:

E.2.7.3.B.A.E.F.F.F.C.8.E.1.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F.IP6.ARPA
Ez lesz a szmtgpem perverz reverz neve IPv6-ban. Bartsgos, mi?

Mg egy aprsgrl szeretnk szt ejteni. Ha n egy DNS szerverhez fordulok,
feloldand egy nevet, a szerver honnan fogja tudni, hogy n A vagy AAAA rekordot
szeretnk visszakapni? gy, hogy kln jelzem neki a Question Entries mezben, ha
kell az AAAA rekord is. Mghozz a megfelel helyen (6.8. tblzat - Question Type
rtkek) egy pontosan beszrt 0x1C (AAAA) illetve 0xFF (Any) rtkkel.
~ 342 ~
KIVEZETS
7 K IVEZETS
Minden normlis knyvben arra szokta buzdtani a szerz a kedves olvast, hogy ha
krdse van, akkor ne hezitljon, tegye fl btran.
Ez ilyen szempontbl is rendhagy knyv. n azt mondom, hogy eszed gban se
legyen tlem brmit is krdezni. Nem azrt, mert n egy undok vadmalac vagyok...
hanem azrt, mert ez egy alulrl korltos knyv.
Elmagyarzom.
Aki van annyira btor, hogy knyvet r, annak nagyon kell tudnia. Ezt a tudst
legtbbszr nem is tudja teljesen kirni magbl. Mr nyomdban van a knyv,
amikor eszbe jut, hogy ez is kimaradt, meg az se lett teljesen kibontva. Azaz ha
brki krdez valamit, ami nem kerlt bele a knyvbe, a szerz magtl rtetden el
tudja magyarzni.
Ez a fellrl korltos knyv. Ilyen volt az Exchange 2007-rl szl knyvem.
Ennek a mostani knyvnek mr a legelejn jeleztem, hogy rendhagy kisrletre
kszlk. Olyan terletrl rok, amelyhez nem rtek. Pontosabban rtek
valamennyire, de messze nem annyira, mint amilyen mlyen el akarok merlni a
tmban. Menetkzben tanulok... s a megrtett dolgokat gyermeki rmmel adom
t, mint megannyi jdonsgot.
Lertam mindent, amit tudok... st valjban tbbet is rtam le, mint amit
tnylegesen tudok. Hiszen a keretek s datagramok szerkezett, a szabvnyok
lnyegt n is kziknyvekbl, weblapokrl szedtem ssze.
Ergo ez egy alulrl korltos knyv.
Krdezni krdezhetsz, persze... de n is csak annyit tudok tenni, amennyi neked is
rendelkezsedre ll: gugli vagy bing.
Ellenben ha te a tma szakrtje vagy s csak a viccek miatt olvastad vgig a
knyvet, aztn gy talltl benne ordt hibkat - nos, te ne ttovzz, rd meg ezeket
egybl a jpetrenyi@gmail.com cmre. Az online megjelensnek ugyanis pont az az
risi elnye, hogy a tartalom mdosthat, aktualizlhat.
A vgre egy j hr: a knyv mkdik. Amikor gyjtttem az anyagot, szp lassan
kezdett rthet lenni a TCP/IP mkdse. Amikor rtam a knyvet, mr azt hittem,
hogy rtem - csak ekkor mg darabokban lttam mindent, hiszen ebben a fzisban a
rszletek kidolgozsa volt a jellemz. s amikor lektorlskor olvastam el egyben az
egszet, akkor llt csak ssze a teljes kp. De sszellt.
~ 343 ~
8 F ORRSOK , LINKEK
Ez a knyv gy kszlt, hogy elolvastam hozz RFC-ket, izmos kziratokat - majd
ahol gy reztem, hozzolvastam a netrl is. Rengeteg link gylt ssze a vgre.
Ezeket a linkeket talljtok meg a ebben a fejezetben, minimlisan strukturlva.
SZAKKNYVEK:
Alapveten ezekre az rott forrsokra tmaszkodtam:
Joseph Davies: Windows Server 2003 TCP/IP Fundamentals for Microsoft
Windows
Joseph Davies: Windows Server 2008 TCP/IP Fundamentals for Microsoft
Windows
Joseph Davies, Tony Northrup with the Microsoft Networking Team:
Windows Server 2008 Networking and Network Access Protection (NAP)
Joseph Davies: Windows Server 2008 TCP/IP Protocols and Services
Joseph Davies: Understanding IPv6
RFC
A tiszta forrs, ahol minden megvan:
http://tools.ietf.org/html/
http://www.rfc-editor.org/rfc.html
http://www.networksorcery.com/enp/
http://en.wikipedia.org/wiki/Request_for_Comments
KIEMELT LINKEK:
TCP/IP Guide:
http://www.tcpipguide.com
Internetworking Technology Handbook:
http://www.cisco.com/en/US/docs/internetworking/technology/handbook
/ito_doc.html
TCP/IP Networks:
Protocols Directory:
http://www.protocols.com/protocols.htm
Internetworking Guide:
~ 344 ~
FORRSOK, LINKEK
WINDOWS SERVER 2008 S VISTA
New Networking Features in Windows Server 2008 and Windows Vista
Windows Server 2008 Networking:
http://technet.microsoft.com/en-us/library/cc753940(WS.10).aspx
Windows Vista Networking Tecnologies:
http://en.wikipedia.org/wiki/Windows_Vista_networking_technologies
MLESZTETT LINKEK
Vgl mlesztve egy csom link abbl a segdfjlbl, ahov menetkzben szrtam a
hasznos infkat tartalmaz tallatokat.
http://www.itu.int/rec/T-REC-X/en
http://en.wikipedia.org/wiki/Ethernet
http://en.wikipedia.org/wiki/Frame_(telecommunications)
http://www.iana.org/assignments/ieee-802-numbers
http://www.erg.abdn.ac.uk/users/gorry/course/lan-pages/llc.html
http://www.techfest.com/networking/lan/token.htm
http://www.javvin.com/protocolFDDI.html
http://www.laynetworks.com/FDDI.htm
http://en.wikipedia.org/wiki/Point_to_Point_Protocol
http://www.cisco.com/en/US/docs/internetworking/technology/handbook/PPP.html
http://www.tcpipguide.com/free/t_PointtoPointProtocolPPP.htm
http://en.wikipedia.org/wiki/802.11
http://hu.wikipedia.org/wiki/Wi-Fi
http://hu.wikipedia.org/wiki/WPA
http://wifi.cs.st-andrews.ac.uk/wififrame.html
http://en.wikipedia.org/wiki/MAC_address
http://en.wikipedia.org/wiki/Media_Access_Control
http://www.leapforum.org/published/internetworkMobility/split/node12.html
http://www.wireless-center.net/Wireless-Internet-Technologies-andApplications/1923.html
http://www.iana.org/assignments/arp-parameters/
http://www.javvin.com/protocolARP.html
http://blogs.technet.com/networking/archive/2009/01/15/unable-to-connect-towindows-server-2008-nlb-virtual-ip-address-from-hosts-in-different-subnets-when-nlb-isin-multicast-mode.aspx
https://www.netacademia.net/tudastar/default.aspx?upid=2836
http://en.wikipedia.org/wiki/Address_Resolution_Protocol
http://sunsite.nus.sg/pub/slip/slip-vs-ppp.html
http://www.iana.org/assignments/ppp-numbers
http://en.wikipedia.org/wiki/Cryptographic_hash_function
http://en.wikipedia.org/wiki/Challenge-handshake_authentication_protocol
~ 345 ~
http://www.windowsnetworking.com/articles_tutorials/Windows-Server-2008Networking-Services.html
http://www.szabilinux.hu/trendek/trendek422.html
http://www.protocols.com/pbook/frame.htm
http://en.wikipedia.org/wiki/Frame_Relay
http://en.wikipedia.org/wiki/Maximum_transmission_unit
http://www.iana.org/assignments/ip-parameters
http://en.wikipedia.org/wiki/Routing
http://en.wikipedia.org/wiki/Routing_Information_Protocol
http://en.wikipedia.org/wiki/Distance-vector_routing_protocols
http://en.wikipedia.org/wiki/Open_Shortest_Path_First
http://www.iana.org/assignments/icmp-parameters
http://en.wikipedia.org/wiki/Ping_of_death
http://www.tcpipguide.com/free/t_ICMPv4DestinationUnreachableMessages-3.htm
http://www.networkcomputing.com/netdesign/1107icmp3.html?ls=NCJS_1107bt
http://en.wikipedia.org/wiki/Path_MTU_discovery
http://www.netheaven.com/pmtu.html
http://en.wikipedia.org/wiki/ICMP_Redirect_Message
http://www.networkdictionary.com/protocols/irdp.php
http://www.javvin.com/protocolESIS.html
http://tldp.org/HOWTO/Multicast-HOWTO-2.html
http://en.wikipedia.org/wiki/Distance_Vector_Multicast_Routing_Protocol
http://www.dataconnection.com/multicast/pimprotocol.htm
http://www.javvin.com/protocolMOSPF.html
http://en.wikipedia.org/wiki/Internet_Group_Management_Protocol
http://www.mbone.net/
http://en.wikipedia.org/wiki/Mbone
http://acs.lbl.gov/OldMisc/mbone/
http://www.cisco.com/en/US/tech/tk828/tech_brief09186a00800a4415.html
http://en.wikipedia.org/wiki/Multicast_address
http://www.networksorcery.com/enp/protocol/igmp.htm
http://www.javvin.com/protocolIGMP.html
http://www.iana.org/assignments/ipv6-multicast-addresses
http://www.tcpipguide.com/free/t_UDPMessageFormat-2.htm
http://en.wikipedia.org/wiki/User_Datagram_Protocol
http://en.wikipedia.org/wiki/Transmission_Control_Protocol
http://www.tcpipguide.com/free/t_TCPConnectionEstablishmentSequenceNumberSynchro
niz.htm
http://www.firewall.cx/tcp-analysis-section-2.php
http://en.wikipedia.org/wiki/Windows_Vista_networking_technologies
http://en.wikipedia.org/wiki/TCP_tuning
http://en.wikipedia.org/wiki/Karn%27s_Algorithm
~ 346 ~
FORRSOK, LINKEK
http://www.cs.utk.edu/~dunigan/tcptour/javis/tcp_karn.html
http://www.iana.org/assignments/bootp-dhcp-parameters/
http://support.microsoft.com/kb/169289
http://www.tcpipguide.com/free/t_DHCPLeaseRenewalandRebindingProcesses-2.htm
http://www.tcpipguide.com/free/t_DHCPOptionsOptionFormatandOptionOverloading2.htm
http://www.tcpipguide.com/free/t_TCPIPAddressResolutionForIPMulticastAddresses.htm
http://av.c3.hu/multicast/
http://www.firewall.cx/multicast-intro.php
http://www.tcpipguide.com/free/t_ProxyARP.htm
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080094a
db.shtml
http://www.osischool.com/protocol/Tcp
~ 347 ~
9 J AVTSOK
Habr az lenne a helynval, hogy egyenknt emltsek meg mindenkit, aki szrevett
valami hibt, vagy fogalmi zavart, de attl jelentsen olvashatatlan lenne ez a
javtsokat felsorol rsz. gy egyszerre szeretnk ksznetet mondani
mindenkinek, aki hozzjrult ahhoz, hogy a knyv korrektebb s rthetbb legyen.
9.1 2.1
VERZI ,
2011
PRILIS
Kt hozzszls rkezett az utbbi egy vben a knyvhz.
62. oldal: Kaptam pldt egy olyan esetre, amelyre korbban azt rtam, hogy
Windows krnyezetben nem trtnhet meg.
119. oldal: Habr a plda levezetse elmletileg helyes volt, egy kedves olvas
ki is prblta s kiderlt, hogy ami elmletben nem mkdik, az a
gyakorlatban - a krlmnyek fura sszjtka miatt - igen. Kiegsztettem a
fejezetet az eset lersval.
9.2 2.0
VERZI ,
2010
MRCIUS
Na, itt aztn rendesen belenyltam a knyvbe.
Az sszes link kattinthat lett.

A knyv tartalomjegyzke fa struktrban megjelenik a pdf fjl bal oldaln s kattinthat.
Rengeteg tfogalmazs, olvashatbb ttel, modorossgok irtsa.
Elgpelsek javtsa.
Az irodalmi idzet lecserlse.
Bevezetsben arc visszavtele.
A 2. fejezet tstrukturlsa.
Teljesen j 2.2 fejezet, ahov az alapfogalmak ismertetse kerlt. Ezeket a
szvegeket a korbbi elfordulsi helykrl kiszedtem.
A teljes szvegben javtottam a laza fogalomhasznlatot, a 2.2 fejezetnek
megfelelen.
Ahogy fel is hvtk r a figyelmemet, a Wireshark als mezje minden, csak
nem binris. A hivatalos elnevezse Packet Bytes. Vgig javtva.
21. oldal: A hub nem L2, hanem L1.
~ 348 ~
JAVTSOK
31 s 163 oldalak: A MAC Address I/G bitjnek rszletezse, a broadcast

tsorolsa.
36. oldal: Lbjegyzet: svszlessg vs. adattviteli sebessg.
37. oldal: Fontos lbjegyzet a broadcast s a collision domainekrl.
60. oldal: A BOOTP megkvetse.
60-62. oldalak: A Proxy ARP mlyebb kifejtse.
117. oldal: Volt egy kis elmatekols. Csodlkozom, hogy eddig senki nem
vette szre.
131-132 oldalak: A NAT fajtinak (NAT, PAT, SNAT, DNAT) rvid bemutatsa.
132. oldal: Az APIPA hozzraksa a privt tartomnyokhoz.
178. oldal: NAT htrnyai kiegsztve.
180. oldal: Megint az a frnya matek. A 128 bjt az nem 2128 lehetsg.
187. oldal: A unique-local IPv6 cm kpzsnek bvebb kifejtse.
191. oldal: IPv6 cmek sszefoglal tblzata. Szvsz meglehetsen fontos.
207. oldal: Megjegyzs a solicited IPv6 cmhez.
210. oldal: Egyrtelmbb fogalmazs az IPv6 stateless autokonfigurcinl.
215. oldal: A 4-63 bra cserje.
215-225. oldalak: Az IPv4-IPv6 konverzik gykeres jrarsa, konkrt
pldk, rszletesebb magyarzatok.
225. oldal: A Teredo alfejezet bvtse a Windows 2008 Server R2 miatt.
239-287 oldalak: Mr az oldalszmokbl is lthatod, hogy ez volt az egyik
legnagyobb v vltoztats a knyvben. Clozgattam r korbban is, hogy a
legnehezebben megrtett rsz szmomra a szegmensek ackolsa, az
adatfolyam szablyozsa s az jrakldsek optimalizlsa volt. Ez be is jtt,
mert kaptam egy levelet, melyben szelden elmagyarztk, mi mindent
rtettem meg rosszul ebben a tmakrben. Innentl az n dolgom mr csak
annyibl llt, hogy a pontosabb megrts fnyben jrafogalmazzam az
rintett rszeket. (A ponok maradtak.) Ezzel nem azt akarom mondani, hogy
jrartam 48 oldalt - csak azt, hogy elg sok helyen kellett belenylnom a
szvegbe ahhoz, hogy a vltoztatsokat egyenknt mr ne akarjam
kirszletezni ebben a listban.
289. oldal: Trkp az alkalmazs rteghez.
s nem utolssorban a msodik ktet megjelense.
9.3 1.1
VERZI ,
12. oldal
23. oldal
79. oldal
86. oldal
2009
DECEMBER
: Rtegek fogalmi zavarai javtva

: Az FCS, ami ugye nem hash.
: Az SSL - TLS tmenet tisztzsa
: PPPoE Discovery Phase pontostsa
~ 349 ~
86-87. oldal : A PPP, a PPPoE s az Ethernet struktrk egymshoz val

viszonynak tisztzsa, a 3.29 bra mdostsa
Vgl szmtalan elgpels javtsa
~ 350 ~
A SZERZ
10 A SZERZ
Itt szeretnk adni az rzsnek. Mrmint az exhibicionizmus nevnek.

Valamikor vegyszmrnknek kszltem, st, meglep mdon mg diplomt is
kaptam belle. Pr vnek kellett csak eltelnie s trsasgban mr azt bizonygattam,
hogy a kn-monoxid sokkal veszlyesebb, mint a kn-dioxid. Ha jt akarsz
magadnak, nem engem krdezel meg arrl, mely anyagok mrgezek.
Valjban soha nem is tekintettem magamat vegysznek: az utols kt vet a
veszprmi egyetem kibernetika tanszkn tltttem - s aki ismeri a helyet, tudja,
hogy akkoriban arrafel tanyztak az gszemek, az elhivatott rendszeresek... azaz
a Rendszermrnk szakos hallgatk. Gyakorlatilag neknk csak a testnevels s a
nyelvi rinkon nem volt matek - az sszes tbbin tisztn. Modelleztnk (matek),
optimalizltunk (lineris/nemlineris algebra), mindezeket szmtgpre vittk
(numerikus
matek),
elemeztk
(statisztika,
valsznsgszmts)...
kikapcsoldskppen ipari/ltalnos szmtstechnikt, ipari/kisgpes/nagygpes
programozsi nyelveket tanultunk. A hab a tortn a fizikai kmia volt, melyet
gondolom az egyetem vegyipari jellege miatt csempsztek bele lczskppen a
tanrendbe, de nlunk azt is statisztikus alapon oktattk.
Ehhez kpest az els munkahelyemen, a veszprmi IKV tvftsi rszlegn
mindsszesen egy darab C128-as szmtgp volt. Arra kellett gyviteli szoftvereket.
fejlesztenem. Mondjuk, mg j, hogy nem a fnk Casio menedzserkalkultorra94.
A geek vonal egybknt mr korn kitkztt. Az els programozhat zsebszmolgpem Stylandia, egy szgyentelen tajvani Sharp koppints - 48 lpst ismert. Erre gyrtottam klnbz
programokat, gy, hogy a gombnyomsokat cetlikre rtam fel. Klnsen bszke voltam a msodfok
egyenlet megoldkpletre - h, mondtam mr, hogy 48 lps? - s a Stirling formulval
megvalstott faktorilis szmolsra. Ez utbbi ugyanis kpes volt a 69-nl nagyobb szmok esetben
is faktorilist szmolni.
94
~ 351 ~

Aztn jtt a rendszervltozs, a tancsi rendszer felbomlott, az IKV szintn - s
ahogy a tvfts nll cg lett, megszabadultunk az sszes kontraszelektlt
idittl. Innentl kezdve tnyleg informatikval foglalkoztam, rendszerpts,
gyvitelszervezs, zemeltets, programozs (Clipper/Pascal), hlzat. Ahogy egy
kis cgnl szoks az ilyesmi.
Az OOP mr az zemeltetsi oldalon tallt95. Nem szndkosan lltam t, egyszeren
a kvetkez munkahelyemen erre a tudsra volt szksg. Ha fejlesztt kerestek
volna, akkor ma fejlesztenk.
A szakmai karrierem 2002-ben indult be igazn, amikor egy csoportos lepts
eljtkaknt kirgtak a munkahelyemrl. J tz hnapig kerestem j munkahelyet.
Ekkor fogadtam meg, hogy ilyesmit tbbszr nem engedlyezek a sorsnak.
Rgyrtam a szakmra, tanultam, mint az rlt, sorra nyomtam a - valdi - vizsgkat,
a cgemnl is szpen haladtam elre, kaptam az egyre izgalmasabb feladatokat.
2005 krl vgtam bele egy szakmai/civil blogba, az itteni szakmai rsok keltettk
fel ksbb a Microsoft figyelmt. gy lettem a Technet Magazin egyik rendszeres
szerzje. Innentl szpen aprnknt pltek egymsra a dolgok: cikkek,
blogbejegyzsek, oktatsi anyagok... kzben egy MVP cm... majd egy Exchange 2007
knyv, mely eredetileg Netacademia produkcinak indult, de a kzirat vgl a
Microsoft Magyarorszgnl landolt. Erre a mostani knyvre mr a Microsofttl
kaptam a megbzst - s ahogy most kinznek a dolgok, valsznleg nem ez lesz az
utols.
Vgl lljanak itt az elrhetsgek:
Szakmai blog:
EMAIL S A DETEKTVEK
:
MICROSOFT TECHNET PORTL :
http://emaildetektiv.hu
http://tinyurl.com/ydmbgdk
Privt blog
MI VAN VELEM?
http://mivanvelem.hu
Email:
jpetrenyi@gmail.com
95
Ha csak nem szmtjuk a kicsit bncska objektumorientlt Clippert, a CA-VO-t.
~ 352 ~

TCPIP Alapok-#1 MS PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TCPIP Alapok-#1 MS PDF

Uploaded by

Copyright:

Available Formats

Windows Server 2008

2009, Petrnyi Jzsef

"- Akkor beszljnk nyltan. Nem hinyzik magnak valami?

Tanulj velem! ________________________________________________________________________ 10

Hfehrke s a ht rteg _______________________________________________________ 12

Kinek szl az zenet? ______________________________________________________ 17

Subnet vs link ______________________________________________________________ 18

Azok a frnya dobozok ____________________________________________________ 19

Hlzati eszkzk __________________________________________________________ 21

A hlzati eszkz rteg protokolljai _______________________________________________ 22

LAN technolgik _______________________________________________________________ 23

Ethernet 802.3 ________________________________________________________ 32

Ethernet 802.3 SNAP _________________________________________________ 34

Token Ring: IEEE802.5 s IEEE 802.5 SNAP ____________________________ 36

Fiber Distributed Data Interface: FDDI __________________________________ 41

IEEE 802.11, azaz WIFI ____________________________________________________ 44

Alrteg protokollok: LLC s MAC _________________________________________ 47

Address Resolution Protocol, ARP ____________________________________________ 48

ARP nvfelolds ____________________________________________________________ 53

Dupliklt cm meghatrozs ______________________________________________ 56

Fekete lyuk detektlsa ___________________________________________________ 58

WAN technolgik ______________________________________________________________ 63

Point To Point Protocol, PPP ______________________________________________ 63

PPP konfigurls LCP-vel ____________________________________________ 67

Protokoll belltsok NCP-vel ________________________________________ 88

PPP over Ethernet ____________________________________________________ 92

Inverse ARP, Reverse ARP, Proxy ARP ___________________________________ 60

NBMA: Frame Relay _______________________________________________________ 95

Az internet rteg protokolljai ______________________________________________________ 96

Tredezettsg ________________________________________________________ 103

IP Options ____________________________________________________________ 107

let a hatron: Route, NAT, Proxy _______________________________________ 116

Route __________________________________________________________________ 121

RIP ____________________________________________________________________ 129

OSPF __________________________________________________________________ 130

NAT ___________________________________________________________________ 131

Proxy __________________________________________________________________ 134

ICMP, azaz a PING s a haverok __________________________________________ 135

ICMP Echo Request & Reply ________________________________________ 137

ICMP Destination Unreachable _____________________________________ 140

ICMP Source Quench ________________________________________________ 149

ICMP Redirect ________________________________________________________ 150

ICMP Router Discovery ______________________________________________ 153

ICMP Time Exceeded ________________________________________________ 157

ICMP Parameter Problem ___________________________________________ 158

ICMP Address Mask Request & Reply ______________________________ 159

IGMP, azaz egy kis Multicast _____________________________________________ 160

Egy szerver kldeni akar ____________________________________________ 166

Egy kliens fogadni akar ______________________________________________ 167

A router, aki sszehozza a feleket __________________________________ 168

IGMP v1 _______________________________________________________________ 169

IGMP v2 _______________________________________________________________ 171

IGMP v3 _______________________________________________________________ 174

IPv6 _____________________________________________________________________________ 179

Unicast cmek ________________________________________________________ 184

Multicast cmek ______________________________________________________ 190

Az IPv6 Csomag ______________________________________________________ 196

Neighbor Discovery, ND _____________________________________________ 206

Multicast Listener Discovery (MLD) _______________________________ 209

Autokonfigurci ____________________________________________________ 211

Alapok _____________________________________________________________________ 181

IPv4 -> IPv6 konverzik __________________________________________________ 213

Intra-Site Automatic Tunnel Addressing Protocol, ISATAP ______ 221