Szakdolgozat. IPv6 hálózatok kialakítása és üzemeltetése. Budapesti M szaki és Gazdaságtudományi Egyetem. Bendzsák András

Budapesti M¶szaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Automatizálási és Alkalmazott Informatikai Tanszék

Szakdolgozat

IPv6 hálózatok kialakítása és üzemeltetése Bendzsák András

KONZULENS Kardos Gergely

Oláh István

mérnök

mestertanár

Budapest 2010

Hallgatói nyilatkozat

Alulírott, szigorló hallgató kijelentem, hogy ezt a szakdolgozatot meg nem engedett segítség nélkül, saját magam készítettem, csak a megadott forrásokat (szakirodalom, eszközök, stb.)

használtam fel.

Minden olyan részt, melyet szó szerint, vagy azonos ér-

telemben de átfogalmazva más forrásból átvettem, egyértelm¶en, a forrás megadásával megjelöltem. Tudomásul veszem,

hogy az elkészült szakdolgozatban található eredményeket a

Budapesti M¶szaki és Gazdaságtudományi Egyetem, a feladatot kiíró egyetemi intézmény saját céljaira felhasználhatja.

Kelt: Budapest, 2010. 03. 28.

................................. aláírás

2

Tartalomjegyzék

Összefoglaló . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

Bevezetés

9

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1. IPv6 elméleti alapok

10

1.1.

Internet Protokoll történeti áttekint®

. . . . . . . . . . . . . . . . . . . . .

10

1.2.

IPv4 hiányosságai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

1.3.

IPv6 újdonságai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

1.4.

IPv4-IPv6 konverziók . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

1.5.

IPv6 elterjedését akadályozó tényez®k . . . . . . . . . . . . . . . . . . . . .

14

2. A tanszék jelenlegi informatikai infrastruktúrája

16

2.1.

Fizikai és adatkapcsolati réteg . . . . . . . . . . . . . . . . . . . . . . . . .

16

2.2.

Hálózati réteg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

2.3.

Alkalmazási réteg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

3. Tesztkörnyezet összeállítása 3.1.

3.2.

20

IPv4 beállítása

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

3.1.1.

Routing

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

3.1.2.

DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

3.1.3.

DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

3.1.4.

Kliens oldali alkalmazások

. . . . . . . . . . . . . . . . . . . . . . .

23

3.1.5.

Kiszolgáló oldali alkalmazások . . . . . . . . . . . . . . . . . . . . .

24

IPv6 címosztási alapelvek

. . . . . . . . . . . . . . . . . . . . . . . . . . .

24

3

IPv6 hálózatok kialakítása és üzemeltetése

3.2.1.

Dinamikus VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

3.2.2.

802.1x autentikáció . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

3.2.3.

Stateless konguráció . . . . . . . . . . . . . . . . . . . . . . . . . .

28

3.2.4.

Stateful konguráció

. . . . . . . . . . . . . . . . . . . . . . . . . .

29

3.3.

Tunneling kongurálása

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

3.4.

Stateless konguráció . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

3.4.1.

Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

3.4.2.

T¶zfal

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

3.4.3.

Kliensek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

3.4.4.

Kiszolgálók

37

3.4.5.

Alkalmazások beállítása

3.5.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

3.5.1.

Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

3.5.2.

T¶zfal

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40

3.5.3.

Kliensek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

3.5.4.

Kiszolgálók

42

Stateful konguráció

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4. Bevezetés az éles környezetben 4.1.

Eltérések a teszkörnyezett®l

4.2.

Bevezetés lépései

43

. . . . . . . . . . . . . . . . . . . . . . . . . .

43

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

4.3.

Üzemeltetés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

4.4.

Továbblépési lehet®ségek . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

Köszönetnyilvánítás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

Irodalomjegyzék . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

Ábrajegyzék . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50

Táblázatok jegyzéke

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

Függelék . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

4

Összefoglaló

Az

Internet Protocol version 6

(IPv6)

a

következ®

generációs

IP

protokoll.

Megszületésének oka, hogy a világviszonylatban jelenleg legelterjedtebb IPv4 protokollnak korlátozott a megcímezhet® tartománya, ezáltal a hálózatra csatlakoztatott eszközök is száma is er®sen korlátolt. A 4. generációs Internet protokoll megszületése a '70-es évekre tehet®, amikor az alkotók fejében még nem egy világméret¶ a mai Internethez hasonló hálózat járt. Ezt már a kilencvenes években felismerték, és elkezdtek dolgozni az IPv6-on, de sajnos az IPv6 elterjedtsége 2010-ben is elhanyagolható méret¶. Ez azért óriási probléma, mert a szabad IPv4-es tartományok 2012-re el®reláthatólag elfogynak. Az AAIT tanszék mindig is élen járt az új technológiák terén, nincs ez másként az IPv6 bevezetésével kapcsolatban sem. A szakdolgozatom témája az IPv6 bevezetés el®készítése a tanszék éles hálózatában.

Els® lépésként megismerkedtem az IPv6-os szabvánnyal és

az újdonságokkal. A következ® lépés a tanszéki hálózat feltérképezése és dokumentálása volt. A tanszéki hálózat felmérése után egy tesztkörnyezetet állítottam össze, ahol megvizsgáltam, hogy milyen módon tudnánk a tanszéki infrastruktúrával kompatibilis IPv6 hálózatot kialakítani.

Végül elkészítettem az éles bevezetésr®l készült tervet, ügyelve,

hogy kisebb változtatásokkal máshol is alkalamazható legyen.

5

Abstract

The

Internet Protocol version 6

of the IPv6 was intended.

is the next generation Internet Protocol. The born

The currently world-wide used IPv4 standard has a limited

number of addressable ranges and devices wich has brought IPv6 to existence. The fourth generation was created in the 70th when the creators were not thinking of a world-wide network such as today's Internet. During the nineties this was realised so they started to work on IPv6 but unfortunately it is still not widely used in 2010. This is a serious problem because at this rate we are probably going to run out of IPv4 address ranges by 2012. The AAIT department has always used bleeding edge technologies. IPv6 is not any dierent. The subject of my thesis is preparing the introduce on the departments production environment. First I became acquainted with IPv6 standard and its new features. The next step was exploring and documenting the departments network system. Finally I created a production environment design After exploring the network I set up a test environment where I observed the opportunities of building an IPv6 network infrastructure compatible with the departments current system. Lastly I created a production environment design. This should be applicable with slight changes in dierent environments.

6

Bevezetés

Az Internet térhódítása a '80-es években kezd®dött, a fejl®dés üteme az elmúlt két évtizedben évr®l-évre fokozatosan n®. A fejl®dés mozgató rugója, hogy a környezetünkben lév® eszközök egyre nagyobb hányadát szeretnék hálózatba kötni. Például tudni akarjuk, hogy éppen mennyi friss élelmiszer van a h¶t®nkben, ezért csatlakoztatjuk az Internetre. Ugyanezt tesszük a az autónkkal, mobiltelefonunkkal. A világviszonylatban egyeduralkodó IPv4 protokoll nem alkalmas ekkora méret¶ hálózat kezelésére: el®reláthatólag a még kiosztható IP tartományok 2012-re elfogynak. A megoldást az újgenerációs szabványra, az IPv6 protokollra átállás jelenti. Jelenleg az IPv6 elterjedtsége nagyon alacsony. Ha a közeljöv®ben ez nem változik meg drasztikusan, az komoly fékez®er®t jelent az Internet terjedésének, ami kihathat az egész IT szektorra.

A szakdolgozatomnak otthont adó tanszék els®ként a BME-n szeretné bevezetni natívan az IPv6-ot a saját bels® informatikai rendszerében. Kutatóprojektek korábban is voltak a BME-n, de a teljes hálózatra kiterjed® átállás sehol nem történt. Mivel ez egy kísérleti projekt, ezért semmilyen korábbi terv nem állt rendelkezésre a cél eléréséhez. Az Interneten megtalálható dokumentumok túl általánosak voltak, nem tartalmaztak konkrét lépéseket, nem igazodtak a tanszéki igényekhez. Mint a bevezet®ben említettem, az IPv6 jelenlegi elterjedtsége meglehet®sen alacsony, ezért bizonyos területeken csak kísérleti technológiák használatával lehet teljesíteni az IPv4-nél jelen lév®, és a hálózatüzemeltet®k által megkövetelt specikációkat.

A szakdolgozatom témája egy esettanulmány elkészítése az IPv6 bevezetésér®l az Automatizálási és Alkalmazott Informatikai tanszéken (továbbiakban AAIT). A tervet a kiírásnak megfelel®en úgy készítettem el, hogy tetsz®leges szervezeti egységben (tanszék,

7


intézmény, vállalat) is hasznosítható legyen.

Természetesen a szakdolgozat kerete nem

teszi lehet®vé, hogy a dokumentum minden helyzetben változtatás nélkül alkalmazható legyen, de jó alapot szolgáltathat egy hasonló projekt elvégzéséhez. Az IPv6 bevezétese után a tanszéki hálózatnak a következ® követelményeknek kell megfelelniük:

•

Minden tanszéki kliensnek globális IPv6-os címmel kell rendelkeznie

•

Minden a tanszéki hálózatra kötött, de nem tanszéki felügyelet alatt álló számítógépnek lehet®séget kell biztosítani, hogy IPv6-os címet kapjon és onnan elérje a bels® hálózatot és a világhálót

•

Minden szerver rendelkezzen IPv6-os címmel és a rajta futó szolgáltatások elérhet®ek is legyenek ezeken a címeken. (Dual-stack konguráció)

•

A kialakított struktúra lehet®séget adjon, hogy kés®bb a hálózatra köthet®ek legyenek IPv6-only eszközök.

•

A hálózat biztonsági szintje ne csökkenjen a bevezetés után.

•

Az átalakítás minimális mértékben vagy egyáltalán ne akadályozza a tanszéki munkát.

Az utolsó pont élvezi a legnagyobb prioritás, hiszen a napi munkát egy kísérleti projekt semmiképpen sem befolyásolhatja.

Áttekintés A szakdolgozat elkészítése során az alábbi terv szerint haladok a cél felé:

•

IP alapú hálózatok különösen IPv6 mélyebb megismerése, irodalomkutatás.

•

A tanszék jelenlegi infrastruktúrájának feltérképezése.

•

A választott címosztási struktúra kidolgozása.

•

A tanszékit jól modellez® tesztrendszer felállítása.

8


•

Tesztkörnyezeten az IPv6 hálózat felállítása, funkcionális tesztek elvégzése.

•

A tesztelés tanulságainak levonása, az éles környezet migrációs tervének elkészítése.

Nem mellékes cél, hogy a szakdolgozat elkészítése közben olyan ismeretekre tegyek szert, amellyel tetsz®leges IPv6 implementálással, üzemeltetéssel kapcsolatos feladatot el tudjak látni.

9

1. fejezet

IPv6 elméleti alapok

Az els® fejezet témája egy b® áttekint® az IPv6 protokollról. A szakdolgozat feltételez alapfokú hálózatismereti tudást az olvasótól, terjedelme miatt az IPv4 protokoll ismertetése is csak részlegesen történik meg, kiemelve azokat a hiányosságokat, amik az új generációs protokoll kifejlesztését tették szükségessé.

1.1. Internet Protokoll történeti áttekint® Az Internet Protocoll egy ISO 3. rétegbeli szabvány. A szabvány legutolsó változata 1981-ben jelent meg [2]. Internetnél.

Az akkori hálózat összehasonlíthatatlanul kisebb volt a mai

A protokoll a 90'-es évekre egyeduralkodóvá vált, gyakorlatilag eltüntetve

az összes 3. rétegbeli szabványt (pl. IPX, Appletalk stb.). Az els® komolyabb probléma a protokollal a '90-es évek elejére datálódik:

ekkor kezdték a vállalatok felismerni az

Internetben rejl® lehet®ségeket és hatalmas címtartományokat igényeltek a regionális regiszterekt®l. A szabad A és B osztályú tartományok rohamosan fogyni kezdek, ezért lépni kellett: bevezették a CIDR típusú osztály nélküli címtartományokat [1]. Ez sokat javított a helyzeten, de nyilvánvaló volt, hogy ez csak részleges megoldás, ezért a szabványalkotók már elkezdtek dolgozni a következ®, 6. generációs protokoll megalkotásán (létezett 5. generációs IP szabvány is, de az egy streaming protokoll volt 1979-ben, érthet® okokból sosem terjedt el).

10


1.2. IPv4 hiányosságai A következ® hiányosságok indokolják a leváltását:

•

Korlátozott méret¶ címtartomány

•

Titkosított kapcsolat támogátasa

•

Streaming protokollok gyenge támogatása

Az els® pont a legproblémásabb és egyben legkritikusabb kérdés. A kiosztható címek fogyóban vannak, becslések szerint 2012-ben elfogynak a kiosztható tartományok.

Igaz

léteznek címfordító technikák (pl. NAT), amikkel a címtartomány megnövelhet®, de ez megnehezíti bizonyos alkalmazások implementálását: csak az IP rétegben történik címfordítás, az alkalmazás rétegben megmarad az eredeti IP cím. Titkosított kapcsolatokat létre lehetett hozni IPv4 felett is, de a különböz® címfordító technikák módosították az IP fejlécet, ezzel megtörve a validációs eljárást.

1.3. IPv6 újdonságai Az alábbi lista tartalmazza az IPv6 f®bb újdonságait:

Új fejléc formátum

Az IPv6 szabvány új típusú, szabadon b®víthet® fejlécet deniált

(1.1 ábra). Az IPv4-el ellentétben itt a fejléc hossza x 10 szó, amely tartalmazza a csomag alapvet® információit. Ez nagy segítség a routereknek, mert a x fejléchossz könnyebb feldolgozást tesz lehet®vé.

Az 1.1 ábra mutatja az IPv6-os fejléc

felépítését.

Nagyobb címtartomány r®l

2128 -ra).

32 IPv6 esetén a címzési tartomány megnégyszerez®dött (2 -

Ez elméletileg

296 -szor

Földön található atomok száma

2170 .

több címet jelent.

Összehasonlításképpen a

A nagyobb címtartomány szükségtelenné teszi

a címfordító technikákat, megoldja a HTTP Virtualhost problémáját SSL kapcsolat esetén.

Növeli a hálózat biztonságát, azáltal, hogy támadóknak sokkal nagyobb

címtartományt kell végigpásztázni a támadható kliensek felkutatásáért.

11


1.1. ábra. IPv6 fejlécformátum (en.wikipedia.org)

Stateless és statfull IP címosztás

A dinamikus cím allokáció elméletileg egyszer¶bbé

vált: a kliens DHCP szerver nélkül is képes globális címet generálni magának. Ez sajnos a gyakorlati alkalmazásoknál inkább hátrányként jelenik meg. Az IP címek allokálásával a 3.2 fejezet foglalkozik, ezért itt eltekintek a részletes ismertetését®l.

IPSec fejléc támogatás

Az

IPSec kötelez® eleme lett az IPv6 fejlécnek.

Ez nem jelenti,

hogy a csomagok automatikusan titkosítva vannak, az alkalmazásoknak támogat-

AH

niuk kell a titkosítást. (

és

ESP

ag)

Priorizált csomagtovábbítás jobb támogatása

Az új

Flow Label

fejléc segítségével

jelezni tudjuk, hogy a csomag egy folyam része, és az útválasztók kiemelten tudják kezelni ezeket a csomagokat még abban az esetben is, ha azok titkosítva vannak.

Új protokoll a helyi hálózaton belüli gépek elérésre

Neighbour Discovery proto-

koll az IP cím MAC cím hozzárendelést valósítja meg IPv6 esetén. El®nye az ARPvel szemben, hogy mulitcast címzést használ broadcast helyett, ezzel csökkentve a kliensek terhelését.

B®víthet®ség

Az új szabadon b®víthet® fejlécformátumnak köszönhet®en lehet®ség

nyílik a jöv®ben további funkciók implementálására egyénien deniált 40 bájt hosszú fejlécekkel. A fejlécek számának csak az IP csomag mérete szab határt.

12


1.4. IPv4-IPv6 konverziók

1.2. ábra. IPv6 csatornázás

A bevezet® fejezetekben többször is említettem, hogy az átállás nem egyik pillanatról a másikra történik, ezért szükég van kösztes lépcs®kre. Ilyen lépcs®nek tekinthetjük azt esetet, amikor két IPv6-only számítógép szeretne kommunikálni egy olyan hálózaton, ahol részben vagy egészben csak az IPv4-es protokoll támogatott. Ekkor jönnek jól a különböz® tunneling (csatornázó) technológiák. Minden tunneling technológia alapja, hogy az IPv6 csomagot az IPv6/IPv4 átjáró bekapszulázza egy IPv4-es csomagba, az IPv4/IPv6 átjáró pedig kicsomagolja és úgy juttatja el a címzetthez. Az átjáró nem minden esetben jelent különálló zikai entitást a hálózaton, sok esetben a kliensek közvetlenül, automatikusan építenek ki csatornákat egymás között. Ez alapján megkülönböztetünk manuális illetve automatikus csatornázást. A manuális tunneling m¶ködését az 1.2 ábrán lehet nyomon követni.

Intra-Site Automatic Tunnel Addressing Protocol

Mint a nevéb®l is látszik ez

csak telephelyen belül használható csatornázási technológia. Helyi típusú (fe80::/64) címek képz®dnek egy meghatározott algoritmussal a résztvev® felek IPv4-es címéb®l. Nagyon ritkán használt eljárás.[3]

6to4

Ez

manuálisan

és

automatikusan

is

kiépíthet®

csatornázási

technológia.

M¶ködésének feltétele a publikus IP cím, NAT-on keresztül egyáltalán nem m¶ködik. Cserébe minden publikus IPv4-es címhez tartozik egy globális /48-as tartomány, tehát akár egy átjáróval is el lehet látni egy nagyobb méret¶, több telephelyes vállalatot IPv6-os címekkel. Az IPv6 tartomány 2002:{IPv4 cím}::/48 alakú, ahol z IPv4-es cím az átjáró publikus IP címe. A csatorna másik pontja, egy speciális (192.88.99.1) anycast cím, ami a legközelebbi IPv4/IPv6 gateway-re mutat. [4]

13


Teredo

A Teredo tunneling m¶ködik NAT-on keresztül is, cserébe ez a legbonyolultabb

az összes csatornázási technológia közül. Els® körben az IPv6 csomagot nem közvetlenül az IPv4-es csomagba kapszulázza, mert ezt sok t¶zfal blokkolja, hanem egy UDP csomagba. Ráadásul nem elég két pont a kommunikációhoz, szükség van egy Teredo szerverre a megfelel® IPv6 címek kiszámításához. Itt ez azért szükséges mert helyi címb®l szeretnénk globálisat képezni. A következ®képpen épül fel egy Teredo IPv6 cím: 2001:0000:{Teredo szerver IPv4 címe}:{16 bit ag}:{küls® port}:{küls® IPv4 cím}. A küls® port azt az UDP portot jelenti, amelyre a NAT-nak fordítania kell a kommunikációt.

A agek részletezése megtalálható az RFC-ben.

A többi

mez® értéke triviális. [5]

1.5. IPv6 elterjedését akadályozó tényez®k Az IPv6 elterjedtsgér®l 2010-ben kiadott hivatalos dokumentum [6] szerint jelenleg a globálisan m¶köd® 1800 úgynevezett autonóm rendszernek csak az 5,5 százaléka képes az IPv6-os adatok továbbítására. Ez a szám annak tükrében alacsony, hogy a végfelhasználók operációs rendszereinek több mint 90 százaléka már tartalmazza az IPv6 támogatást. A dokumentum az alacsony elterjedtség f® okaként azt jelölte meg, hogy a tartalomszolgáltatók számára gyakorlatilag ismeretlen fogalom az IPv6. A világ ezer legnépszer¶bb honlapjának csupán 1,45 százaléka támogatja az IPv6-ot. Ha az egymillió legnépszer¶bb oldalt vesszük alapul, akkor ez az érték csak 0,15 százalék. Az Internet központi részében lév® hálózati eszközök közel egynegyede már támogatja az új protokollt, de a ma kapható SOHO eszközök nagy részében még hiányzik ez a támogatás. A dokumentum arról számol be, hogy növekedés tapasztalható az elterjedtségben, de ez a növekedés túl lassú, ahhoz, hogy 2012-re (az IPv4-es címtér telít®désére) megfelel® szinten elterjedjen. Problémát jelent, hogy a kiosztott IPv4-es tartományok politikai és gazdasági okokból nem egyenletesen lettek elosztva, és az USA-ban lényegesen kés®bb fogynak el a szabad IP címek összehasonlítva például az Ázsia térséggel. A nagy tartalomszolgátatok

14


még mindig inkább az európai és amerikai piacra koncentrálnak, ezért nem siettetik az átállást, számukra még az átállás nem jár gazdasági el®nnyel. Szerencsére az IPv4 címek elfogyásával párhuzamos az IPv6 elterjedtsége is exponenciálisan növekv® pályán van, és ez id®vel kényszeríteni fogja a tartalomszolgáltatókat és hálózati eszközök gyártóit, hogy tegyék meg a megfelel® lépéseket a zökken®mentes átállás érdekében.

15

2. fejezet

A tanszék jelenlegi informatikai infrastruktúrája

Az AAIT tanszék két épületben helyezkedik el. A két épület között nincs kiépített közvetlen kapcsolat, csak az egyetemi hálózat köti össze ®ket. A tanszék két darab C osztályú publikus címtartománnyal gazdálkodik: a V2 épületben a 152.66.70.0/24, az I épületben a 152.66.251.0/24 tartomány érhet® el. A két telephely felépítése a mi szempontunkból semmilyen különbség nincs, ezért a kés®bbiekben csak a V2-es infrastruktúrát ismertetem. Ha valahol mégis a téma szempontjából fontos különbség van arra külön kitérek. A V2-es hálózat felépítését a 2.1 ábra szemlélteti.

2.1. Fizikai és adatkapcsolati réteg A hálózat határán egy PC alapú útválasztó található, amelynek az egyik interfésze az egyetemi hálózatba, a másik a bels® hálózatba van kötve. Ez a szerver (továbbiakban ns.aut.bme.hu) négy feladatot lát el:

•

Routolás az küls®, a publikus bels® és a NAT-olt tartomány között.

•

T¶zfal funkciók

•

Névkiszolgálás (DNS)

•

Dinamikus IP cím kongurálás (DHCP)

16


2.1. ábra. AAIT hálózati topológiája

17


A hálózat gerincét az alábbi tipsuú switchek alkotják:

•

3Com 3300XM

•

3Com 33004

•

3Com 4226

•

3Com 4250

Ezekhez az eszközökhöz további különböz® típusú távolról nem menedzselhelt® switchek csatlakoznak.

A hálózat pontos topológiáját a 2.1 ábra nem tartalmazza, az

összes ilyen eszközt egyetlen switch elem segítségével ábrázoltam.

A pontos topológia

irreleváns az IPv6 bevezetése szempontjából. A felsorolásból kimaradt eszközök jó része nem kezel VLAN-okat, ezért a hálózat egyetlen logikai LAN-ból áll.

Mivel a végpontokra csatlakozó számítógépek különböz®

bizalmi szinteken helyezkednek el, ezért ezek szeparálását a VLAN-ok hiánya matt eggyel magasabb rétegben kell megvalósítani.

2.2. Hálózati réteg A hálózati réteg a számítógépeket 3 logikai részre bontja: regisztrált, nem regisztrált kliensek, illetve szerverek. A regisztrált gépek a tanszéken állandóan jelenlév®, a tanszék vagy az alkalmazottak tulajdonában lév® számítógépek. Ezek a gépek publikus, C osztályú címet kapnak, a küls® elérésüket er®sen korlátozza a t¶zfal, b®vebben lásd 2.1 táblázat. IP címet a DHCP szervert®l MAC cím alapján kapnak. Tartomány

Felhasználás

152.66.70.0/24

Regisztrált gépek és szerverek

192.168.1.x/24

Nem regisztrált gépek

2.1. táblázat. IPv4 címek a tanszéken

A nem regisztrált gépek rendelkeznek publikus IPv4 címmel, helyette egy nem regisztrált tartomány van számukra fenntartva, ami NAT-olva van az egyetemi hálózat felé. Fontos, hogy ezek a gépek a tanszéki bels® hálózat szempontjából egyetemi gépeknek

18


számítanak, tehát ugyanazok a szabályok vonatkoznak rájuk, mint egy tetsz®leges nem tanszéki gépre. A szerverek szinte kivétel nélkül x, publikus hálózati címmel rendelkeznek, a szerverre vonatkozó t¶zfalszabályok változóak, a szerver funkciójától függenek.

2.3. Alkalmazási réteg A tanszéken hálózatot használó programokat is két részre lehet bontani:

kliens és

szerveroldali alkalmazások. A 2.3 táblázat tartalmazza a kliens és a 2.2 a szerver oldali alkalmazásokat. A tanszék méretéb®l adódóan nem tudtam minden programot feltérképezni, ezért csak a leggyakrabban használtak szerepelnek a listában. Alkalmazás

IPv6 kompatibilitás

BIND 9

3 3 3 3 3 3

Apache 2.2 Oracle 11g Windows AD IIS >6.0 Sendmail >8.3

Megjegyzés

el®ny a https esetén az IPv4-hez képest

2.2. táblázat. Kiszolgáló oldali szoftverek listája az AAIT tanszéken

Alkalmazás

IPv6 kompatibilitás

Internet Explorer >7

3 3 3 7

Firefox Outlook >2007 Windows Live Messenger

Megjegyzés

2.3. táblázat. Kliens oldali szoftverek listája az AAIT tanszéken

19

3. fejezet

Tesztkörnyezet összeállítása

Mint a bevezet®ben említettem, a megfogalmazott kritériumok közül a legfontosabb, hogy csak minimális mértékben befolyásolja az átállás a napi munkát. Ezért egy olyan tesztkörnyezet kialakítása mellett döntöttem, amely lehet®ség ad a különböz® IPv6 topológiák tesztelésére. Az alábbi kongurációjú szerveren került kialakításra a tesztkörnyezet:

•

Sun Fire V40z

•

2xAMD Opteron 248 CPU

•

11 GB RAM

•

2x73 GB és 1x146 GB HDD

A gép a Schönherz Zoltán Kollégiumban került elhelyezésre, ahol egy zikai végponton keresztül csatlakozik az egyetemi hálózatra. A kiszolgálóra VMWare ESXi 4.0 virtualizációs platformszoftvert installáltam, amiben kialakításra kerültek a teszt operációs rendszerek. Az AMD Opteron 248-as processzor nem tartalmaz hardveres virtualizációs kiegészítést (AMD-VT), ezért csak ez a szerver virtualizációs szoftver jöhetett számításba. A kialakított teszthálózatot a 3.1 ábra mutatja. Látható, hogy az

aut-switch.aut.bme.hu gép kivételével a topológia hasonló a valódi

hálózatot ábrázoló modelléhez.

20


3.1. ábra. Teszthálózat IPv4-es kongurációja

21


Az

aut-switch.aut.bme.hu

(kés®bbiekben

szimulálja a tesztkörnyezet felé, míg az

aut-switch )

nev¶ virtuális gép az Internetet

ns.aut.bme.hu (ns ) nev¶ gép a tanszéken talál-

ható routerként funkcionáló PC virtuális mása.

A különbség, hogy a zikai gépen egy

Fedora Core 2 (2004) Linux fut, míg a tesztkörnyezetben az Ubuntu Linux legfrissebb, 9.10-es változata fut. A választásom azért esett erre a disztribúcióra, mert err®l vannak a legb®vebb ismereteim, eddigi munkáim során ezt használtam a legtöbb alkalommal. A Fedora Core 2 és az Ubuntu 9.10 is 2.6-os kernelt tartalmaz, tehát a router funkciói szerint nincs különbség a két disztribúció között.

3.1. IPv4 beállítása 3.1.1. Routing Az

aut-switch

szervernek két hálózati csatlakozója van.

A küls® lába egy valódi

publikus IP címmel rendelkezik, míg a bels® lábán a zikai eszközhöz hasonlóan a 152.66.70.2/252-es IP cím van kongurálva. A gép bels® lába közös switchen helyezkedik el az

ns

szerverrel. Az

ns

szervernek is két interfésze van: a küls® láb a 152.66.70.1/252

címet kapja, míg a bels® a 152.66.70.4/24-eset. Az

aut-switch gép a 152.66.70.0/24-es tar-

tományt NAT-olja az Internet felé. Éles rendszereknél szigorúan csak helyi tartományokat szabad NAT-olni, mivel így nem lehet elérni azt a tartományt az Interneten a NAT-olt hálózatból. Itt ez nyugodtan megtehet®, s®t megvan az az el®nye, hogy a NAT-olt hálózaton belül mindenhol ugyanazokat a routing és t¶zfal szabályokat tudjuk alkalmazni, mint az éles környezetben. Az ns gép bels® lábának van még egy IP címe, ez a 192.168.1.1/24. tartomány a nem regisztrált gépeknek szükséges, és az

ns

Ez az IP cím

gép NAT-ol a 152.66.70.1 cím

felé. Ez azt jelenti, hogy kétszeres NAT mögött helyezkedik egy nem regisztrált klienst szimuláló virtuális munkaállomás, ellentétben az elés rendszerrel, de ez úgy gondolom semmilyen problémát nem jelent jelen helyzetben. Hogy ezeket megvalósítsam, mindkét gépen engedélyezni kellett az IP forwardingot és egy iptables szabályt deklalárni, ami a NAT-olást végzi. Az

aut-switch

gépen IPv4 tekintetében semmilyen egyéb kongurációt nem kellett

22


végezni.

3.1.2. DNS A routing beállítása után a teszthálózaton belül tökéletesen m¶ködött a névfeloldás egy küls® DNS szerverrel, de ahhoz, hogy a kés®bbiekben az AAAA recordokat be tudjam jegyezni, szükség volt egy saját DNS szerverre. Az iparban els®számú és a tanszéken is használt BIND DNS szervert válaszottam. A telepítés egyszer¶en csomagból történt. Létrehoztam az aut.bme.hu tartományhoz tartozó NS rekordokat, néhány A rekordot (tipikusan a hálózatban szerepl® tesztszerverek), és az aut.bme.hu doménhez tartozó MX rekordot. Ezen kívül még szükség van egy reserve DNS zóna a 152.66.70.0 tartományra. Az éles infrastruktúrában a tartományi vezérl® képes dinamikus DNS segítségével bejegyezni a tartomány m¶ködéséhez szükséges rekordokat. A tesztkörnyezetben nincs kiépített Windows AD környezet, ezért a dinamikus DNS nincs bekongurálva.

3.1.3. DHCP DHCP szervernek az ISC szerverét használtam: ezt ismertem a legjobban és a tanszéken is ezt alkalmazzák. Természetesen ez is az

ns

szerverre települt. Két tartományt je-

löltem ki, az egyik az egyetem által delegált 152.66.70.0 a másik egy privát 192.168.0.0/16 tartomány. El®bbi tartományból MAC címe alapján kap minden regisztrált x IP címet a DHCP szervert®l, utóbbi egy szabad tartomány a nem regisztrált gépek számára.

3.1.4. Kliens oldali alkalmazások Az ns gép összeállítása utána kliens oldali teszt virtuális gépeket telepítettem.

A

következ® virtuális gépeket hoztam létre:

•

Windows XP

•

Windows 7

•

Ubuntu Linux

23


Minden gép egy hálózati csatolóval csatlakozik a bels® hálózatra, és DHCP-vel kapnak IP címet. (Ez az alapértelmezett beállítás kliens operációs rendszerenként) Minden rendszerb®l két darab van: egy regisztrált MAC cím¶, és egy nem regisztrált.

Ez lefedi a

tanszéki gépek 95%-át. Minden rendszer tartalmazza a tanszéken használt szoftvereket. (2.3 táblázat)

3.1.5. Kiszolgáló oldali alkalmazások A teszthálózat tartalmaz szerver funkciójú gépeket, szám szerint hármat:

•

Windows 2008 Server

•

Windows 2003 Enteprise

•

Ubuntu Linux 9.10 Server Edition

Pre-Windows 2003 szerver nem található a tanszéki infrastruktúrában, Windows 2008 R2 pedig csak 64-bites verzióban létezik, viszont a Sun Fire V40z szerverben lév® központi egység nem képes 64-bites vendég operációs rendszereket futtatni, ezért tesztelni sem tudtam 2008 R2-t. A szerverek x IP címet kaptak (a 152.66.70.0/24 tartományból), és ugyanúgy a 2.2 táblázatban szerepl® programokat telepítettem, mint a kliensek esetében.

3.2. IPv6 címosztási alapelvek Az IPv6-os címeket hasonlóan az IPv4-eshez két részre lehet bontani: alhálózati maszk (network mask) és egy egyéni azonosító (host-id). IPv6 esetén az ajánlott alhálózati maszk /64. Ett®l el lehet térni és el is szoktak bizonyos esetekben de a kisebb illetve nagyobb hálózatokban a stateless konguráció nem használható. Az elméleti résznél említettem, hogy IPv6 esetében máshogy m¶ködik az automatikus IP cím konguráció, mint azt megszokhattuk az IPv4-nél.

Ebben fejezetben részletes

elemzésre kerülnek a különböz® címosztási stratégiák. IPv4 esetén a következ®képpen néz ki az automatikus IP cím konguráció: 1. A

kliens

elküld

egy

DHCPDISCOVER

üzenetet

a

globális

broadcast

(255.255.255.255) címre

24


2. A DHCP szerver válaszol egy DHCPOFFER üzenetben, amelyben elküldi a szükséges információkat (IP cím, alhálózati maszk, DNS szerverek, alapméretezett átjáró stb.)

3. A kliens válaszol (DHCPREQUEST), hogy elfogadja-e a beállítást.

4. A szerver jóváhagyja (DHCPACK) a kliens kérését

A folyamatból jól látszik, hogy egészen a legutolsó pontig broadcast üzenetekkel folyik a kommunikáció, (Ez nem teljesen igaz: a kommunikációban részt vev® felek már korábban is unicastra válthatnak, de ez nem elterjedt.) IPv6 esetén így néz ki az autokonguráció:

1. A kliens generál magának egy link-local IP címet (fe80::/64).

2. Elküld egy Router Solicitation üzenetet a

minden-router multicast (01::2)

címre.

3. A router(ek) válaszként küld(enek) egy Router Advertisment üzenet, ami tartalmaz M (Managed) és O (Other) aget, ami szerint a kliens különböz® eljárásokat követ:

O és M ag alacsony

A hálózaton nem található DHCP szerver, a kliens az RA

üzenetben kapott kongurációt használja

O magas, M alacsony

A hosztok az IP címüket a RA üzenetben kapott prexb®l

generálhatják, de a további beállításokat (pl. DNS) a DHCP szervert®l kapják

O és M ag magas

A kliens a globális IP címét és az egyéb beállításokat is a

DHCP szervert®l kapja

O alacsony, M magas

A kliens a DHCP szervert®l kap IP címet. Elméleti lehe-

t®ség, gyakorlatban sosem implementálják

4. A DHCPv6 szerverrel a kommunikáció hasonló módon zajlik, mint a IPv4 esetében, annyi különbséggel, hogy a kommunikáció broadcast üzenetek lehet®ségének hiánya miatt

minden DHCPv6 szerver (02::1:2)

címen keresztül történik.

A folyamatból kit¶nik, hogy van egy hatalmas hibája a stateless kongurációnak: az RA üzenet nem tartalmazza a DNS szerver címét.

DNS nélkül egy munkaállomás

25


nem alkalmas semmilyen hálózati munkára, tekintve az IPv6-os címek megjegyezhetetlen hosszára. Tehát mindenféleképpen szükséges egy DHCPv6 kongurálása a hálózaton. Stateless kongurációnál az IP cím host-id részét (az utolsó 64 bit) valahonnan generálja a kliens. Két elterjedt módszer van:

EUI64

A hálózati interfész MAC címéb®l generálódik a következ®képpen: {MAC cím

els® 24 bitje}:fe:{MAC cím második 24 bitje}. [7]

Véletlenszám

Az operációs rendszer véletlenszer¶en generálja a host-id-t. [8]

Az eredeti koncepció szerint az EUI64 címgenerálás volt az ajánlott, ezt követi a Windows XP, a legtöbb Linux disztribúció és a MAC OS X is. Ez a módszer felvet bizonyos adatvédelmi kérdéseket: a MAC címb®l generált host-id világszinten egyedi lesz a MAC cím miatt (mobil eszközöknél biztosan), ezért például a tartalomszolgáltók a felhasználókat követni tudják, bárhonnan érik el a világhálót. Ezért a Microsoft a Windows Vista és 7 esetében véletlenszám-generátorral allokál magának host-id-t. Ennek a módszernek az a hátulüt®je, hogy megnehezíti a kliensek azonosítását és a privilégiumok hozzárendelését pusztán a munkaállomás IP címe alapján. A másik komoly gond a regisztrált és nem regisztrált gépek szeparálásánál van. A 2. fejezetben leírtak szerint a tanszéken a nem regisztrált és regisztrált gépeket különböz® címtartományokba sorolással szeparálják.

Ezt a szétválasztást a DHCP szerver végzi:

a regisztrált gépek MAC cím alapján x IP címet kapnak, minden egyéb gép a privát címtartományból kap címet. IPv6 esetén ilyen jelleg¶ szeparációra nem találtam optimális megoldást, ezért több variációt dolgoztam ki, amelyek mindegyike kompromisszumokat tartalmaz. Ezek között az implementálást végz®knek és az üzemeltet®knek kell kiválasztani a számukra optimális megoldást. Az els® két megoldási javaslat az IPv6 bevezetését®l függetlenül is növelné a hálózat biztonságát, de ezekhez egyrészt a hálózati eszközök egy részét le kell cserélni, másrészt kényelmetlenebbé teszik az egyszeri felhasználók számára a tanszéki hálózat használatát.

26


3.2.1. Dinamikus VLAN Lényegesen nagyobb biztonságot tudunk elérni, ha már a 2. rétegben különválasztjuk a nem regisztrált gépeket. Ebben az esetben arról van szó, hogy a switch-ek egy porton a forgalmazás kezdetén eldöntik, hogy az éppen forgalmazni kívánó MAC cím melyik VLAN-ba tartozzon.

El®nye •

Magasabb szint¶ biztonság, mint a 3. rétegbeli szétválasztás esetén.

•

IPv4 és IPv6 esetén is m¶ködik.

Hátránya •

A tanszéken lév® hálózati eszközök nem támogatják a protokollt,

•

Csak CISCO által támogatott technológia.

•

Minden támadás ellen nem nyújt védelmet (pl. MAC cím átírása).

3.2.2. 802.1x autentikáció A Dinamikus VLAN továbbgondolásaként született.

Port szint¶ autentikációt tesz

lehet®vé hasonlóan az el®djéhez, de itt a kliens csak abban az esetben tud kommunikálni ha jelszóval vagy privát kulccsal autentikált a központi szerverrel.

El®nye •

Jelenleg elérhet® legnagyobb biztonság.

•

IPv4 és IPv6 esetén is m¶ködik.

Hátránya •

A tanszéken lév® hálózati eszközök nagy része nem támogatja a protokollt.

•

Nehézkes a használata, kliens oldali kongurációt igényel, igazán csak tartományi gépek esetén használható.

27


3.2.3. Stateless konguráció Stateless konguráció esetén a címkongurációhoz nincs szükség DHCP szerverre, viszont DNS szervert hirdetni csak DHCP klienssel lehet. Bár még dual-stack konguráció az els®dleges cél, ahol az IPv4-es DNS szerver is képes AAAA rekordokat szolgáltatni, de semmilyen hátránnyal nem jár, ha már most fut egy DHCP szerver, ami az IPv6 DNS szerverek elérhet®ségét hirdeti. Stateless kongurációnál a legnagyobb probléma a nem regisztrált és regisztrált gépek szeparációjánál van. Szeretnénk, ha eltér® szint¶ t¶zfal szabályok vonatkoznának a különböz® státuszú gépekre. Az RA üzentek minden géphez eljutnak, tehát nem tudunk más IP tartományt rendelni. Egyetlen megoldás, ha valamilyen módon a t¶zfal segítségével választjuk szét a forgalmat. Az

AdvOnLink

aget az RA üzenetben bekapcsolva a lokális LANon belüli forgalom is

átmegy a routeren. A regisztrált gépek számára létre kell hozni a t¶zfalszabályokat. Ennek szükséges feltétele az EUI-64 formátumú IP cím, tehát a Windows Vista/7 klienseken ki kell kapcsolni a véletlen címgenerálást.

Ezen kívül szükséges egy olyan t¶zfalszabály,

amely minden nem regisztrált IP címre triggerel, és az IPv4-es NAT-olt rendszerekre vonatkazó szabályok vonatkoznak rá. Fontos, hogy a szervereket úgy konguráljuk, hogy a link-local címen ne gyeljen semmilyen szolgáltatás, mert link-local címekkel közvetlenül elérik egymást a gépek a zikai LAN-on, megkerülve ezzel a t¶zfalat.

El®nye •

Minimális kliensoldali kongurációt igényel.

•

Jelenlegi hálózati eszközökkel használható.

Hátránya •

Regisztrált Windows 7/Vista esetén kliensoldali kongurációt igényel.

•

Az útválasztónál sávszélesség és er®forrás problémák léphetnek fel.

•

Nem regisztrált gépek Reverse DNS bejegyzése nem lehetséges.

28


3.2.4. Stateful konguráció A stateful kongurációnál hasonló sémát követhetünk mint az IPv4 esetén, szét kell bontani a /64-es tartományt három kisebb tartományra: szerverek, regigsztrált és nem regisztrált kliensek. A kliensek a DHCPDISCOVER üzenetben elküldenek a szervernek a uniqe identier) azonosítóját.

A

DUID

DUID (DHCPv6

egy valamilyen algoritmus által generált szám-

sorozat (általában a MAC címb®l és egy véletlen számból áll), ami a DHCP kliensre és nem a hálózat csatolóra vonatkozóan egyedi azonosító. Ennek hátulüt®je, hogy operációs rendszer újratelepítésekor új azonosító generálódik, el®nye viszont, hogy hálózati kártya cseréje után is megmarad az azonosító. Minden regisztrált gép

DUID -jához

hozzá kell rendelni egy címet, hasonlóan mint

ahogy a MAC címek az IPv4 címekhez vannak rendelve. A nem regisztrált gépeknek egy külön tartományt érdemes a DHCP szerverben kongurálni. A szerverek és a regisztrált gépek közvetlenül elérik egymást (mivel megegyezik az alhálózati maszkjuk, a nem regisztrált gépek a tanszéki infrastruktúrát csak a routeren keresztül érik el, tehát megfelel® t¶zfal szabályokkal elszeparálhatjuk a tanszéki gépekt®l. A Windows XP nem tartalmaz DHCPv6 klienst, küls® program telepítése szükséges. A legtöbb Linux disztribúció csomagként szállítja a szükséges komponenst, de alaptelepítésben nagyon ritka és általában a grakus hálózati kezel® program sem tartalmaz frontendet ehhez.

El®nye •

Kevesebb t¶zfalszabály mint stateless konguráció esetén, ezáltal kisebb er®forrásigény.

•

Minimális kliensoldali konguráció.

Hátránya •

Windows XP esetén küls® DHCPv6 kliensprogram telepítése szükséges

•

Regisztrált gépek esetén a

DUID -t kézzel be kell állítani az operációs rendszer

újratelepítése után.

29


•

Az útválaszónál sávszélesség problémák léphetnek fel.

A következ® néhány alfejezetben a tesztrendszerben az IPv6 bevezetésr®l lesz szó, kongurácós állományokkal és azok részletes magyarázatával. A stateless és stateful kongurációval két külön alfejezet foglalkozik, mert nagyon sok helyen eltér® beállításokat kell alkalmazni. A tunneling kongurálása viszont mindkét esetben teljesen megegyezik, így az nem kerül kétszer ismertetésre.

3.3. Tunneling kongurálása A tesztgép egy olyan hálózatban került elhelyezésre, amely nem rendelkezik publikus IPv6 címmel, ezért valamilyen tunneling protokoll segítségével kapszulázni kell az IPv6-os csomagokat, majd továbbítani egy átjáró felé, amely rendelkezik IPv6 és IPv4 eléréssel is. Az 1.4 alfejezetben részletesen ismertettem a csatornázási technológiákat, ezért erre itt most nem térek ki. Az átjáró szerver (aut-switch) rendelkezik publikus IPv4 címmel ezért a

6to4

alagutazást választottam. Tartomány

Felhasználás

2002:9842:d180:2::/64

Csatornázáshoz szükséges

2002:9842:d180:1::/64

aut-switch és ns szerver közötti kapcsolat

2002:9842:d180::/64

Teszthálózat felé delegált tartomány

3.1. táblázat. Teszkörnyeztben használt IPv6 tartományok

A rendelkezésünkre álló /48-as címtartomány a következ®képpen áll el®: 2002 az els® négy bájt (ez jelöli, hogy

6to4

tunnelingr®l van szó), az utána lév® 32 bit a publikus IPv4

címe a szervernek. A maradék 80 bit az a bizonyos tartomány, ami szabadon kiosztható illetve delegálható az altartományok számára. A 3.1 táblázat tartalmazza az 2002:9842:d180::/48 tartomány felosztását.

A felosz-

tás során csak /64-es tartományt használtam fel, a teszthálózat felé pedig csak egyet delegáltam, mivel nem kiszámítható, hogy az éles környezetben mekkora tartomány áll rendelkezésre. Az Ubuntu Linux alapértelmezetten támogatja a sorokat kellett hozzáadni az

interfaces

6to4

tunnelinget, csak az alábbi

állományhoz:

30


auto

tun6to4

iface

tun6to4

inet6

v4tunnel

address

2 0 0 2 : 9 8 4 2 : D180 : 2 : : 1

netmask

64

endpoint local

gateway ttl

any

152.66.209.128 ::192.88.99.1

65

Az els® két sor a tunneling csatoló inicializálásához szükséges információkat tartalmazza. Az

address

és a

netmask

mez® a csatorna helyi IPv6-os címét és a hozzá tartozó

alhálózati maszkot jelenti. Ennek a megválasztása közömbös, lényeg, hogy ezt a tartományt máshol nem használhatjuk a hálozatunkon belül. Az gével meghatározhatjuk, hogy milyen. A

gateway

endpoint

paraméter segítsé-

annak az átjárónak az IPv6 címe, ami

csatorna másik felén van. Az ::192.88.99.1 cím azt jelenti, hogy az interfész a 192.88.99.1 IPv4 anycast címre továbbítja a csomagokat.

A

local

mez® a csatorna helyi gépéhez

tartozó IPv4 címet tartalmazza. A TTL felülbírására azért van szükség, mert az aut-switch-en áthaladva a TTL kett®vel csökken (TTL inherintance b®vebben a [9] forrásban). Ez általában nem okoz fennakadást, viszont a traceroute eljárás során egy lyuk keletkezik a visszakapott adatokban. Egy, az ns gépr®l indított traceroute-tal illusztrálom a problémát: benjoe@ns :~ $ traceroute

to

traceroute6

i p v 6 . g o o g l e . com


( 2 a00 : 1 4 5 0 : 8 0 0 4 : : 6 9 ) ,

30

hops

max ,

80

byte

packets 1

2 0 0 2 : 9 8 4 2 : d180 : 1 : : 2

2

2 0 0 2 : c 3 6 f : 6 1 c0 : : 1

( 2 0 0 2 : c 3 6 f : 6 1 c0 : : 1 )

( 2 0 0 2 : 9 8 4 2 : d180 : 1 : : 2 )

1.581

3

c 6 5 1 3 . vh . h b o n e . hu

(2001:738::4)

ms

4

2001:2000:3080:17::1

2.030

(2001:2000:3080:17::1)

0.824 ms

2.187

ms

0.791

1.577 ms

40.587

ms

2.249

ms

0.770

1.578

ms

ms

ms

m

. . .

TTL módosítás nélkül: benjoe@ns :~ $ traceroute

to

traceroute6



( 2 a00 : 1 4 5 0 : 8 0 0 4 : : 6 3 ) ,

30

hops

max ,

80

byte

packets 1

2 0 0 2 : 9 8 4 2 : d180 : 1 : : 2

2

5

∗ ∗ ∗ ∗

6

t e l i a s o n e r a . t s d . cw . n e t

3 4

∗ ∗ ∗ ∗

( 2 0 0 2 : 9 8 4 2 : d180 : 1 : : 2 )

0.861

ms

0.828

ms

0.804

ms

∗ ∗ ∗ ∗

40.905

(2001:5000:200:9::2)

40.993

ms

40.753

ms

ms

. . .

Az ns és az aut-switch eszközökön a 3.1 táblázat alapján elvégeztem a kongurációkat: az aut-switch gép bels® csatolója az 2002:9842:D180:1::2/64 IP címet kapta, az ns pedig a

31


2002:9842:D180:1::2/64-et. Ezután már lehetett pingelni tetsz®leges publikus IPv6 címet: r o o t @ n s :~# PING 64

ping6


i p v 6 . g o o g l e . com ( 2 a 0 0 : 1 4 5 0 : 8 0 0 5 : : 6 8 )

bytes

from

2 a00 : 1 4 5 0 : 8 0 0 5 : : 6 8 :

56

data

i c m p _ s e q=1

bytes

t t l =55

time =60.5

ms

3.4. Stateless konguráció A 3.2.3 alfejezetben már szó volt a stateless címosztásról elméletben. Ez a fejezet a tényleges implementálással foglalkozik. A 3.2 ábrán a kiépített IPv6 hálózat látható.

3.4.1. Router A 2002:9842:d180::/64-es tartomány felbontását a 3.2 táblázat tartalmazza. Minden szerver kap egy /112-es tartományt, ami 65536 IP címet jelent szerverenként. Ezzel összesen 655532 szerver kaphat IP címet a jelenleg kiosztott tartományok szerint. Ennyi gép zikailag nem fér el a tanszéken, de a tartomány természetesen tovább növelhet®. Azért választottam a /64-es tartomány elejét, mert ezeket az IP címeket kézzel kell beállítani, és egyszer¶en így a legrövidebbek a címek.

Router Advertisment Daemon A Router Advertisment Daemon (továbbiakban RAD) hirdeti a hálózatban használható prexeket és a hozzájuk tartozó információkat. Az ns szerverre a

radvd

nev¶ daemont telepítettem, mert ez egy általánosan használt

program Linux környezetben. A kongurációt a

radvd.conf

fájlban kell végezni. Íme a

kongurációs fájl tartalma: interface

eth0

{ AdvSendAdvert AdvManagedFlag

on ; off ;

AdvOtherConfigFlag

on ;

MinRtrAdvInterval

5;

MaxRtrAdvInterval

15;

prefix

2 0 0 2 : 9 8 4 2 : D180 : : / 6 4

{ AdvOnLink

off ;

32


3.2. ábra. Stateless kongurációval kiépített IPv6 hálózat

Tartomány 2002:9842:d180::xxxx:xx:fexx:xxxx

Felhasználás Regisztrált gépek (ahol az x a regisztrált gépek MAC címe)

2002:9842:d180::/96

Szerverek

Minden egyéb, tarományon belül


3.2. táblázat. Stateless konguráció esetén IP cím tartományok

33


AdvAutonomous

on ;

}; };

Az állomány struktúrája hasonlít az ISC DHCP szerver struktúrájához. hálózati csatolót külön kell kongurálni

interface

blokkok segítségével.

csak egy csatolója lóg be a teszthálózatba ezért elég egy Az

AdvSendAlert

engedélyezi az RA üzenetek kiküldését, az

AdvOtherCongFlag

A szervernek

entitást létrehozni.

AdvManagedFlag

opciók a már tárgyalt M és O agekenek felel meg.

és a

Jelen eset-

on, mivel nem szeretnénk a DHCP szervernek delegálni a címosztást.

ben csak az O ag A

interface

Minden

MinRtrAdvInterval

és a

MaxRtrAdvInterval

az RA üzenetek gyakoriságát szabályozza,

nincs komoly jelent®sége. A következ® prex blokkban a hálózatunk prexének deklarációja látható. Az

AdvOnLink

opciónak nagyon fontos szerepe van:

o

beállítás esetén

tájékoztatja a klienseket, hogy nem minden IP cím található meg a hálózaton, ezért állítsa úgy beállítani a routing táblát, hogy az alhálózaton belüli forgalom is routeren keresztül zajlódjon.

Ezt arra használjuk, hogy megsz¶rjük a bels® forgalmat, IP cím szerint

szeparáljuk a klienseket. Az

AdvAutonomous

egy engedélyez® ag, ami megengedi a kli-

enseknek, hogy saját címet generálhassanak maguknak. Természetesen

on

állásban van.

A daemont elindítva a klienseinknek már van globális IPv6 címük, csak egyel®re a routeren túl nem látnak. A t¶zfal kongurálása után, már engedélyezhetjük az

ns

szerveren

az IP forwardingot.

3.4.2. T¶zfal A hálózat biztonságának alapköve a router helyes kongurálása. Ez különösen igaz az esetünkben, ahol még a bels® forgalom is a t¶zfalon megy a keresztül. A tanszéki hálózaton m¶köd® t¶zfalról csak részleges ismereteim vannak, ezért az általam megalkotott szabályok csak nagy vonalakban egyeznek meg a valódi IPv4-es t¶zfal szabályokkal. Az IPv6-os szabályok pontos kialakítása csak az IPv4-es szabályok ismeretével lehetséges, amire csak az éles környezetben lesz lehet®ség. A stateless táblázat tartalmazza forrás-cél mátrixként, hogy mely típusú végpontokra milyen szabály vonatkozik. A

semmi

tagot nem szabad szó szerint érteni, mert a TCP

kapcsolatok esetén szükséges mindkét irányba engedni a forgalmat. Ebben az esetben a

34


TCP csomagok fejlécét is vizsgálni kell. A Linux kernelbe épített netlter állapottartó t¶zfal kezelni tudja a fent említett esetet. Ugyanígy a

minden

esetén is a nem érvényes

csomagokat érdemes sz¶rni. forrás cél Szerverek Regisztrált kliensek Nem regisztrált kliensek BMENET

Regisztrált

Nem regisztrált

kliensek

kliensek

minden

semmi

semmi

minden

semmi

semmi

http,https

semmi

semmi

http,https

minden

semmi

semmi

semmi

Szerverek

BMENET minden https, http smb, ftp, rdp

3.3. táblázat. AAIT t¶zfal szabályok

A függelékben szerepel egy általam írt t¶zfal konguráció, amit a teszteléshez használtam.

A t¶zfal részletes ismertetésére terjedelmi okokból nincs lehet®ség, de a 3.3

folyamatábra jól szemlélteti a t¶zfal m¶ködösét.

3.3. ábra. T¶zfal szabályok m¶ködési ábrája

Els® körben azt vizsgálja a t¶zfal, hogy mi a csomag forrása, majd aszerint irányítja a csomagot az egyénien generált láncokba. A láncokból nincs lehet®ség visszatérésre, a csomagsz¶r® megvizsgálja a portokat, cél IP-t és aszerint dönt a sorsáról (visszautasít vagy engedélyez).

35


A regisztrált IP címeket egy szöveges fájlból olvassa és egy for ciklus segítségével tölti be az aktuális táblába. Már az elméleti résznél hátrányként szerepelt, hogy a sok szabály miatt er®forrásproblémák léphetnek fel a t¶zfal esetében. Sajnos a t¶zfal valóban megbukott a volume teszten:

1000 regisztrált cím esetén már percekig tartott csak a

script futtatása, és a másodpercenkénti csomagszám (pps) is a töredékére esett vissza. Esetleg más struktúrával lehet csökkenteni a terhelést, de mindenféleképpen lineárisan fog csökkenni a pps a regisztrált IP címek növekedésével.

DHCP DHCPv6 szervernek a WIDE-féle [10] implementációt választottam, ez jelenleg a legelterjedtebb és ehhez érhet® el a legjobb közösségi támogatás. A DHCP szerver feladata stateless konguráció eseten kimerül a DNS címek hirdetésében, ezért a kongurációs állomány rendkívül egyszer¶, mindössze egy sort tartalmaz: option

domain

−name− s e r v e r s

2 0 0 2 : 9 8 4 2 : d180 : : 1 ;

Itt minden magáért beszél. Lehet®ség van még egyéb szerverek (ntp, sip), de ezek még csak kísérleti opciók és hiányos a kliensoldali támogatottságuk is.

DNS Az általam telepített BIND DNS szerver minden további konguráció nélkül képes IPv6-on kommunikálni, ilyen jelleg¶ kongurációt nem kellett végezni. Az alábbi AAAA és PTR rekordokat kellett bejegyezni:

1. Minden szerverhez annyit, ahány IPv6-os címe volt.

2. Minden regisztrált kliens

A nem regisztrált gépekhez nem jár sem AAAA, sem PTR rekord, mert a nem regisztrált gépek egy

264

méret¶ tartományban helyezkednek el, és ekkora méret¶ tartományhoz

tartozó reverse DNS tárolása lehetetlen. A aroblémára lehetséges megoldásokat egy RFC draft [11] már tartalmaz, de azok biztonsági okokból (Dinamikus DNS) vagy m¶köd® implementáció hiánya ("On the y" generálás) miatt nem használhatóak.

36


3.4.3. Kliensek A klienseknél az eddig használt csoportosításon túl meg kellett különböztetnünk a tartományba léptetett és csak munkacsoportos klienseket. El®bbieknél a csoportos házirendek segítségével automatikusan elvégezhetjük, utóbbiaknál biztosítani kell a megfelel® batch állományokat. A tesztkörnyezetben tartományt nem hoztam létre, a megfelel® indító scripteket a helyi házirendeken teszteltem.

Windows XP A következ® paranccsal tudjuk installálni az IPv6 támogatást Windows XP SP2 esetén: netsh

interface

ipv6

install

A Windows XP nem támogatja a DNS szerverek elérését IPv6 felett, és sok protokoll köztük például CIFS sem támogatott, ezért csak dual-stack környezetben használható.

Windows Vista/7 Windows Vista és 7 esetében a regisztrált gépek nyomon követhet®sége érdekében ki kell kapcsolni az ideiglenes (temporary) IP címet és az IP cím véletlenszer¶ generálását: netsh

interface

ipv6

set

privacy

netsh

interface

ipv6

set

global

edisabled r a n d o m i z e i d e n t i f i e r s =d i s a b l e d

A nem regisztrált gépek esetén ezeknek a kikapcsolása nem szükséges, anélkül is el tudják érni a világhálót.

Linux A legtöbb Linux disztribúcióban alapértelmezetten engedélyezve van az IPv6 támogatás és EUI64 típusú címet is generálnak, tehát semmilyen el®zetes kongurációt nem igényel.

Ahhoz, hogy a DNS lekérdezések is IPv6 felett történjenek, telepíteni kell egy

DHCPiv6 klienst. Telepítés után automatikusan elindul a szükséges démon, ami beírja az ns szerver IPv6-os címét az

resolv.conf

fájlba.

3.4.4. Kiszolgálók Kiszolgálók esetében sok kongurációra nem volt szükség.

Mind az Ubuntu Linux

Server mind a Windows Server 2003/2008 esetében a manuális IP cím beállítás teljesen

37


analóg az IPv4 beállításokkal.

3.4.5. Alkalmazások beállítása A tanszéken futó szoftverek száma olyan nagy, hogy a szakdolgozat keretén b®ven túlmutatna minden alkalmazás IPv6 kompatibilitásának vizsgálata. A tesztkörnyezetben csak az általam felmért alkalmazások m¶ködésékét vizsgáltam, az eredményeket a 2.3 és a 2.2 táblázat tartalmazza. Terjedelmi okokból részletes kongurációt nem tudok közölni, mert bizonyos esetekben nem volt szükség (pl. böngész®k), más esetben az adott szoftver dokumentációja részletes és világos segítséget nyújt a kongurációhoz.

3.5. Stateful konguráció A stateful konguráció sok esetben megegyezik a stateless kongurációval, ezért ebben a szekcióban csak a különbségekr®l lesz szó.

3.5.1. Router A 3.4 táblázat tartalmazza az IP tartományokat. A különbség, hogy a regisztrált és nem regisztrált gépek is a DHCP szervert®l kapnak IP címet, természetesen különböz® tartományból. subsubsectionRouter Advertisment Daemon A

radvd.conf

az alábbiak szerint

módosult: interface

eth0

{ AdvSendAdvert

on ;

AdvManagedFlag

off ;

AdvOtherConfigFlag

on ;

MinRtrAdvInterval

5;

MaxRtrAdvInterval

15;

};

Jól látható, hogy kikerült az egész prex blokk a kongurációs fájlból. fejezetben volt szó az

AdvAutonomous

Az el®z®

agr®l, ami stateless kongurációt engedélyezi

illetve tiltja az adott prexnél. Logikus lett volna csak azt

o

állásba kapcsolni. Hogy

mégsem ez történt, annak az az egyszer¶ oka, hogy ha egy adott prexen belül mindkét

38


3.4. ábra. A teszthálózat felépítése stateful konguráció esetén

Tartomány

Felhasználás

2002:9842:d180::1:0:0/118

Regisztrált gépek

2002:9842:d180::/96

Szerverek

2002:9842:d180::2:0:0/118


3.4. táblázat. Stateless konguráció esetén IP cím tartományok

39


Adv*

o

ag

állásban van, akkor a kliens berakja a prexet a route táblába úgy, hogy az

átjáró meg fog egyezni az alapértelmezett átjáróval. Kernel

IPv6

routing

table

Destination

Next

Hop

If

[ . . . ] 2 0 0 2 : 9 8 4 2 : d180 : : / 6 4

2 0 0 2 : 9 8 4 2 : d180 : : 1

eth0

::/0

2 0 0 2 : 9 8 4 2 : d180 : : 1

eth0

[ . . . ]

Az els® sorban lév® bejegyzés semmilyen csomag routingját nem változtatja, nyugodtan kivehet®.

3.5.2. T¶zfal A t¶zfal szabályok semmit sem változtak a stateless kongurációhoz képest. Viszont a nem regisztrált és regisztrált gépek tartományba szorítása lecsökkentette a t¶zfalszabályok számát.

A függelékben megtalálható a módosított iptables script.

A script

tizedmásodpercek alatt lefutott és a routolási sebesség is nagyságrendekkel gyorsabb lett.

DHCP Amennyivel csökkent a

radv.conf

, annyival lett nagyobb a DHCP szerver kongurációs

állománya: option host

domain

−name− s e r v e r s

2 0 0 2 : 9 8 4 2 : d180 : : 1 ;

teszt { duid

00:01:00:06:13:6 a :4 a :40:00:0 c :29:26:0 a :49;

address

2 0 0 2 : 9 8 4 2 : d180 : : 0 : 1 : 0 : 1

infinity ;

};

interface

eth0

{

address

−p o o l

pool1

3600;

};

pool

pool1

{

range

2 0 0 2 : 9 8 4 2 : d180 : : 2 : 0 : 1

to

2 0 0 2 : 9 8 4 2 : d180 : : 2 : 0 : 4 0 0

;

};

Az els® sor változatlan, utána egy teszt nev¶ gép deniálunk a DUID-val és az IP címmel. Minden regisztrált tesztgéphez tartozik egy ilyen blokk, itt csak a példa kedvéért szerepel egy darab.

Az utána szerepl® két blokk a nem regisztrált gépeknek szánt tar-

tományt deniálja, ami a

pool1

nevet viseli. Ezeknek a neveknek semmi köze a kliensek

DNS címéhez, csupán a hivatkozást segíti a kongurációkor.

40


DNS Semmilyen változtatást nem kellett végrehajtani az alap BIND kongurációval, csupán a zónák szerkezete változott: a 2002:9842:d180::2:0:0/118-as tartományhoz tartozó AAAA és PTR rekordokat kellett bejegyezni, ami a nem regisztrált gépekhez tartozó 1024 rekordot jelenti.

3.5.3. Kliensek A kliensek kongurációja mer®ben más ebben az esetben, hiszen a DHCP kliens nélkül már nem lehet IPv6-os kapcsolatot kiépíteni.

Windows XP Installálni kellett az IPv6 támogatást ugyanúgy, mint stateless kongurációnál majd telepíteni egy küls® DHCPv6 klienst, mert az XP nem tartalmazza beépítetten. A

DHCPv6 Client

Dibbler

szoftver az egyetlen elérhet® DHCPv6 kliens XP-re, ezért ezt installál-

tam mindkét teszt XP-re. Speciális beállításokat nem igényel a kliens, szolgáltatásként automatikusan elindítva a szerverrel való kommunikáció után beállítja a kapott címet.

Windows Vista/7 A regisztrált Windows 7 és Vista esetén a DUID azonosítót meg kell változtatni olyan értékre, ami a DHCPv6 szerver kongurációjában is szerepel. Ezt a HKEY_LOCAL_MACHINE\SYSTEM\ C u r r e n t C o n t r o l S e t \ S e r v i c e s \ T c p i p 6 \ P a r a m e t e r s \ Dhcpv6DUID

registry bejegyzés módosításával lehet megtenni.

Nem szükséges kikapcsolni a véletlen

generált címeket (mivel RAD kongurációban megtiltottuk).

Linux Ubuntu Linux Desktop esetén installálni kell a dhcpv6 klienst, ami hasonlóan az XP-s társától, alapértelmezett beállításokkal IP címet kér a DHCPv6 szervert®l.

Itt is meg

41


kellett változtatnom a DUID-t, amit egy Internetr®l letöltött perl script segítségével meg is tettem. [12]

3.5.4. Kiszolgálók Kiszolgálók kongurációja független attól, hogy melyik megoldást választjuk, ezért nincs különbség a stateless kongurációhoz képest.

42

4. fejezet

Bevezetés az éles környezetben

4.1. Eltérések a teszkörnyezett®l Mint már korábban is utaltam rá, hogy legnagyobb igyekezetem ellenére a teszthálózat nem pontos modellje a valódi tanszéki infrastruktúrának. Ezt gyelembe kell venni a végleges hálózat kialakításakor. Pontokba szedve az alábbiak a f® különbségek:

Alkalmazott Linux disztribúciók

A tanszéken a Fedora a preferált disztribúció, de

el®fordulhatnak másfajta rendszerek is. A tesztelésnél csak Ubuntut használtam.

Windows AD

A tesztkörnyezet nem tartalmaz Windows tartományt, de a bevezetésnél

nagyban támaszkodok a csoportos házirendek nyújtotta szolgáltatásokra.

T¶zfal, Routing beállítások

Nem volt módom a t¶zfal- és routing szabályok alaposab-

ban megismernem, ezért az általam kreált szabályok csak nagyvonalakban egyeznek meg az éles környezetben alkalmazott megoldásokkal

Egyéb hálózati kapcsolattal rendelkez® eszközök

A tanszéken beágyazott rendsze-

rek fejlesztése folyik, amikre semmilyen rálátásom nem volt, tehát az IPv6 képességeiket sem tudtam tesztelni.

Ezeknek a különbségeknek nem tulajdonítottam komoly jelent®séget, mert sikerült olyan stratégiát kidolgoznom, amit követve a bevezetés során ezekb®l adódó hibák könnyedén orvosolhatók.

43


4.2. Bevezetés lépései A tanszéken a bevezetésnél nagyjából ugyanazokat a lépéseket kell követni, mint a tesztkörnyezet felállításánál, kiegészítve egy-két adminisztratív lépéssel és helyenként eltér® sorrendben a m¶ködési anomáliák elkerülése végett. (Pl. HTTP szervernek van érvényes AAAA DNS rekordja de nincs IPv6 címe, vagy a webszerver nem gyel azon az IP címen) Els® körben IPv6 tartományt kell igényelni az egyetemi Informatikai Osztálytól [13]. A honlapjukon közzétett információk szerint minden C osztályú IPv4 tartományhoz jár egy /64-es IPv6 tartomány. Függetlenül attól, hogy stateless vagy stateful címosztási elv lesz végül implementálva, egy darab /64 tartomány elegend® lesz az egész tanszéknek. El kell dönteni, hogy végül melyik címosztási módszer kerül bevezetésre, esetleg hajlandó az üzemeltet® kompromisszumot kötni, és valamelyik kritériumtól eltekinteni és ezzel megváltoztatva valamelyik általam javasolt módszert. Fel kell mérni, hogy tételesen milyen eszközök vannak a bels® hálózaton, illetve milyen az azokon futó szoftverek IPv6 támogatottsága. A 2.3 alfejezetben összeszedtem a leggyakrabban használt programokat, de lehetnek olyan sötét foltok a hálózaton, amir®l nem tudtam. Fontos, hogy a regisztrált gépekr®l és a szerverekr®l legyen egy lista, ami alapján IPv6, illetve AAAA DNS rekordot lehet jegyezni. A következ® immár tényleges implementációs lépés, hogy a kliensekre rá kell kényszeríteni a megfelel® IPv6 viselkedést. Ezzel a lépéssel sokat foglalkoztam a tesztkörnyezet kialakításakor, az ott leírt lépéseket kell végrehajtani azzal a különbséggel, hogy ahol lehet, ott használjuk az automatikus kongurációt (pl. csoportos házirendek). Fontos, hogy els® körben csak a gépek kis százalékán szabad tesztelni (laborban lév® számítógépek esetén például egy gépen laboronként), majd fokozatosan kiterjeszteni az összes kliensre. Most

már,

ns.aut.bme.hu

hogy

a

munkaállomások

egy

része

alkalmas

IPv6

forgalomra,

az

szerveren a következ® beállításokat kell elvégezni:

1. IPv6 routing

2. T¶zfal

3. Router Advertisment Daemon

44


4. DHCPv6 szerver

Ezekhez is nagy segítség a 3.5 vagy a 3.4 fejezet. A kiszolgálók kongurálása sok egyeztetést igényel a rendszergazdákkal: fel kell tértképezni a futó szolgáltásokat, és fel kell hívni az adott szervert üzemeltet® gyelmét, hogy a szerveren futó minden publikus szolgáltatást nyújtó szoftvernek támogatnia kell az IPv6ot, különben nem várt problémák léphetnek fel. Például HTTP szervernek van érvényes AAAA DNS rekordja de a webszerver nem gyel azon az IPv6 címen, emiatt nem érhet® el IPv6 hálózatból az adott weboldal.

Ha valamelyik szerveren olyan szolgáltatás fut,

ami nem támogatja az IPv6-ot, akkor ahhoz a géphez tartozó IP-re tilos AAAA rekordot bejegyezni! HTTP szerver esetén új tanúsítványokat kell gyártani a titkosított csatornán (pl https) is elérhet® szervereken. A DNS bejegyzések elkészítése a legutolsó lépése a bevezetésnek:

stateless címosz-

tás esetén minden regisztrált kliensek és a szerverek kapnak AAAA és PTR rekordokat, stateful esetén még a nem regisztrált gépekre is gondolni kell.

4.3. Üzemeltetés A bevezetés végeztével még viszonylag sok teend® akad.

Meg kell oldani a címek

adminisztrálását, gondolok itt a MAC cím regisztrációra, regisztráció törlésére. Ha van a tanszéken erre rendszeresített felület, akkor azt ki kell egészíteni az IPv6-os címek bejegyzésével DHCP, DNS esetleg a t¶zfalszabályok közé. Amennyiben nincs ilyen eszköz és kézzel történik a regisztráció, akkor az ezt leíró dokumentációt kell b®víteni az IPv6-os résszel. A biztonságra érdemesebb ezután sokkal jobban ügyelni: az IPv6 stack sokkal kevesebb helyen használt, ezért több javítatlan biztonsági rés is lehet benne, mint az IPv4-es implementációkban.

Ezért is fokozottan fontos a rendszeres frissítés mind a szerverek

mind a kliensek esetében.

45


4.4. Továbblépési lehet®ségek A feladatkiírás összes pontját sikerült teljesítenem, ennek ellenére a témát messze nem sikerült kimeríteni. Egyik irány a következ® evolucíós lépés: az IPv6-only számítógépek hálózatba integrálása. A másik irány a meglév® hálózaton a regisztrált és nem regisztrált gépek valamilyen 2. rétegbeli szétválasztását (802.1x, dinamikus VLAN) kidolgozni. A szakdolgozat elkészítése közben az a benyomásom támadt, hogy IPv6 biztonsággal kevesen foglalkoznak egyel®re, sok érdekes kutatási terület van, amelyek kés®bbi önálló labor illetve diplomamunka, szakdolgozat alapjául szolgálhat.

46

Köszönetnyilvánítás

Ezúton szeretnék köszönetet mondani konzulenseimnek

Oláh Istvánnak és Kardos

Gergelynek, hogy lelkiismeretes munkájukkal és bölcs tanácsaikkal hozzájárultak a szakdolgozatom elkészítéséhez.

Köszönöm

Fischer Eriknek

(Sun Microsystems) és

Farkas József nek

(Schönherz

KSZK), hogy megteremtették a technikai feltételeket a tesztek elvégzéséhez.

Végül, de nem utolsó sorban köszönöm

szüleimnek, hogy erkölcsi és anyagi támoga-

tást biztosítottak egyetemi éveim alatt, és mindvégig bíztak bennem.

47

Irodalomjegyzék

[1]

Classless Inter-Domain Routing http://en.wikipedia.org/wiki/CIDR

[2] RFC 791

Internet Protocol

http://www.faqs.org/rfcs/rfc791.html

[3]

Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) http://tools.ietf.org/html/rfc5214

[4] RFC 3056

Connection of IPv6 Domains via IPv4 Clouds

http://tools.ietf.org/html/rfc5214

[5] RFC 4380

Teredo: Tunneling IPv6 over UDP through Network Address Translations

(NATs) http://tools.ietf.org/html/rfc4380

[6] OECD,

[7]

Internet addressing: measuring deployment of IPv6, 2010.

Guidlines for 64-bit Global Identier (EUI64) Registration Authority http://standards.ieee.org/regauth/oui/tutorials/EUI64.html

[8] RFC 4941

Privacy Extensions for Stateless Address Autoconguration in IPv6

http://tools.ietf.org/html/rfc4941

[9] Iljitsch van Beijnum,

[10]

Running IPv6, pg42, Apress, Berkeley, 2006.

WIDE-DHCPv6 http://wide-dhcpv6.sourceforge.net/

48


[11]

Reverse DNS in IPv6 for Internet Service Providers http://ietfreport.isoc.org/idref/draft-howard-isp-ip6rdns/

[12]

Client DUID generator for WIDE-DHCPv6 http://www.ipv6.mtu.edu/wide_mkduid.pl

[13]

BME Telekommunikációs és Informatikai Osztály http://www.tio.bme.hu

49

Ábrák jegyzéke

1.1.

IPv6 fejlécformátum (en.wikipedia.org) . . . . . . . . . . . . . . . . . . . .

12

1.2.

IPv6 csatornázás

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

2.1.

AAIT hálózati topológiája . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

3.1.

Teszthálózat IPv4-es kongurációja . . . . . . . . . . . . . . . . . . . . . .

21

3.2.

Stateless kongurációval kiépített IPv6 hálózat . . . . . . . . . . . . . . . .

33

3.3.

T¶zfal szabályok m¶ködési ábrája . . . . . . . . . . . . . . . . . . . . . . .

35

3.4.

A teszthálózat felépítése stateful konguráció esetén . . . . . . . . . . . . .

39

50

Táblázatok jegyzéke

2.1.

IPv4 címek a tanszéken . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

2.2.

Kiszolgáló oldali szoftverek listája az AAIT tanszéken . . . . . . . . . . . .

19

2.3.

Kliens oldali szoftverek listája az AAIT tanszéken . . . . . . . . . . . . . .

19

3.1.

Teszkörnyeztben használt IPv6 tartományok

30

3.2.

Stateless konguráció esetén IP cím tartományok

3.3.

AAIT t¶zfal szabályok

3.4.

Stateless konguráció esetén IP cím tartományok

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

. . . . . . . . . . . . . .

39

51

Függelék

Stateless kongurációhoz tartozó t¶zfal script: #! / b i n / b a s h

ip6tables

−F −X −N −N −N −N

ip6tables

−A

ip6tables ip6tables ip6tables ip6tables ip6tables

server wan client nr

−c l i e n t

FORWARD

−p

icmpv6

−j

ACCEPT

#F o r r a s v i z s g a l a t ip6tables ip6tables

for

I

in

−A −A `

FORWARD FORWARD

cat

reg

−− s r c 2 0 0 2 : 9 8 4 2 : d 1 8 0 : : / 6 4 − j wan −− s r c 2 0 0 2 : 9 8 4 2 : d 1 8 0 : : / 9 6 − j s e r v e r

−c i m e k . t x t −− s r c

ip6tables

−A

FORWARD

ip6tables

−A

FORWARD

done ;

!

−j

nr

do

`; $I

−j

client

−c l i e n t

#WAN c h a i n

−− d s t 2 0 0 2 : 9 8 4 2 : d 1 8 0 : : / 9 6 − j ACCEPT −c i m e k . t x t ` ; do i p 6 t a b l e s −A wan −p t c p −− d s t $ I −m m u l t i p o r t −− s p o r t s 443 ,80 ,22 ,3389 ,445 ,21 −m s t a t e −− s t a t e ESTABLISHED − j

ip6tables

for

I

in

−A

`

cat

wan

reg

done ;

ip6tables

−A

−p t c p −m − j ACCEPT wan − j REJECT

wan

multiport

−− s p o r t s

443 ,80

−m

ACCEPT

state

−− s t a t e

ESTABLISHED ip6tables

#SERVER

for

I

−A

chain

in

`

cat

reg

−c i m e k . t x t ` ; do −− d s t $ I − j ACCEPT

ip6tables

−A

server

ip6tables

−A −A −A

server

done ;

ip6tables ip6tables

#CLIENT

server

−p t c p −− d s t 2 0 0 2 : 9 8 4 2 : d 1 8 0 : : / 9 6 − j ACCEPT ! −− s r c 2 0 0 2 : 9 8 4 2 : d 1 8 0 : : / 6 4 − j ACCEPT − j REJECT

client

−p

server

chain

ip6tables dports

−A

tcp

!

−− d s t −m

443 ,80 ,22 ,3389 ,445 ,21

2 0 0 2 : 9 8 4 2 : d180 : : / 6 4 state

−− s t a t e

−m

multiport

NEW, ESTABLISHED

−j

−− ACCEPT

52


ip6tables

−A

client


−A

−j

−− d s t

2 0 0 2 : 9 8 4 2 : d180 : : / 9 6

−m

state

−− s t a t e

NEW,

ACCEPT

client

−j

REJECT

−

#NR CLIENT CHAIN ip6tables

−A

− c l i e n t −p t c p −m − j ACCEPT c l i e n t − j REJECT

nr

multiport

−− d p o r t s

443 ,80

−m

state

−− s t a t e

NEW, ESTABLISHED ip6tables

−A

Stateful kongurációhoz tartozó t¶zfal script:

#! / b i n / b a s h

ip6tables

−F −X −N −N −N −N

ip6tables

−A

ip6tables ip6tables ip6tables ip6tables ip6tables

server wan client nr

−c l i e n t

FORWARD

−p

icmpv6

−j

ACCEPT

#F o r r a s v i z s g a l a t ip6tables ip6tables ip6tables ip6tables

−A −A −A −A

FORWARD FORWARD FORWARD FORWARD

−− s r c 2 0 0 2 : 9 8 4 2 : d 1 8 0 : : / 6 4 − j wan −− s r c 2 0 0 2 : 9 8 4 2 : d 1 8 0 : : / 9 6 − j s e r v e r −− s r c 2 0 0 2 : 9 8 4 2 : d 1 8 0 : : 1 : 0 : 0 / 1 1 2 − j − j n r− c l i e n t !

client

#WAN c h a i n

−− d s t 2 0 0 2 : 9 8 4 2 : d 1 8 0 : : / 9 6 − j ACCEPT −p t c p −− d s t 2 0 0 2 : 9 8 4 2 : d 1 8 0 : : 1 : 0 : 0 / 1 1 2 −m m u l t i p o r t −− sports 443 ,80 ,22 ,3389 ,445 ,21 −m s t a t e −− s t a t e ESTABLISHED − j ACCEPT i p 6 t a b l e s −A wan −p t c p −m m u l t i p o r t −− s p o r t s 4 4 3 , 8 0 −m s t a t e −− s t a t e ESTABLISHED − j ACCEPT i p 6 t a b l e s −A wan − j REJECT ip6tables

ip6tables

#SERVER

wan

wan

chain

ip6tables ip6tables ip6tables ip6tables

#CLIENT

−A −A

−A −A −A −A

server

−− d s t 2 0 0 2 : 9 8 4 2 : d 1 8 0 : : 1 : 0 : 0 / 1 1 2 − j ACCEPT −p t c p −− d s t 2 0 0 2 : 9 8 4 2 : d 1 8 0 : : / 9 6 − j ACCEPT ! −− s r c 2 0 0 2 : 9 8 4 2 : d 1 8 0 : : / 6 4 − j ACCEPT − j REJECT

client

−p

server server server

chain

ip6tables dports ip6tables

−A −A

client


tcp

!

−− d s t −m

−A

−j

−− d s t

2 0 0 2 : 9 8 4 2 : d180 : : / 6 4

−− s t a t e 2 0 0 2 : 9 8 4 2 : d 1 8 0 : : / 9 6 −m

443 ,80 ,22 ,3389 ,445 ,21

state

−m

multiport

NEW, ESTABLISHED state

−− s t a t e

−j

−− ACCEPT

NEW,

ACCEPT

client

−j

REJECT

−

#NR CLIENT CHAIN ip6tables

−A

− c l i e n t −p t c p −m − j ACCEPT c l i e n t − j REJECT

nr

multiport

−− d p o r t s

443 ,80

−m

state

−− s t a t e

NEW, ESTABLISHED ip6tables

−A

53

Szakdolgozat. IPv6 hálózatok kialakítása és üzemeltetése. Budapesti M szaki és Gazdaságtudományi Egyetem. Bendzsák András

Recommend Documents