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

Átírás

1 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 mérnök Oláh István mestertanár Budapest 2010

2 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 értelemben 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, aláírás 2

3 Tartalomjegyzék Összefoglaló Abstract Bevezetés IPv6 elméleti alapok Internet Protokoll történeti áttekint IPv4 hiányosságai IPv6 újdonságai IPv4-IPv6 konverziók IPv6 elterjedését akadályozó tényez k A tanszék jelenlegi informatikai infrastruktúrája Fizikai és adatkapcsolati réteg Hálózati réteg Alkalmazási réteg Tesztkörnyezet összeállítása IPv4 beállítása Routing DNS DHCP Kliens oldali alkalmazások Kiszolgáló oldali alkalmazások IPv6 címosztási alapelvek

4 Dinamikus VLAN x autentikáció Stateless konguráció Stateful konguráció Tunneling kongurálása Stateless konguráció Router T zfal Kliensek Kiszolgálók Alkalmazások beállítása Stateful konguráció Router T zfal Kliensek Kiszolgálók Bevezetés az éles környezetben Eltérések a teszkörnyezett l Bevezetés lépései Üzemeltetés Továbblépési lehet ségek Köszönetnyilvánítás Irodalomjegyzék Ábrajegyzék Táblázatok jegyzéke Függelék

5 Ö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

6 Abstract The Internet Protocol version 6 is the next generation Internet Protocol. The born of the IPv6 was intended. 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 This is a serious problem because at this rate we are probably going to run out of IPv4 address ranges by 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

7 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

8 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

9 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

10 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é 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]. Az akkori hálózat összehasonlíthatatlanul kisebb volt a mai Internetnél. 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

11 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 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 IPv6 esetén a címzési tartomány megnégyszerez dött ( r l ra). Ez elméletileg szor több címet jelent. Összehasonlításképpen a Földön található atomok száma 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

12 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ámogatniuk kell a titkosítást. (AH é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 protokoll 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

13 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 ( ) anycast cím, ami a legközelebbi IPv4/IPv6 gateway-re mutat. [4] 13

14 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

15 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

16 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 /24, az I épületben a /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 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

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

18 A hálózat gerincét az alábbi tipsuú switchek alkotják: 3Com 3300XM 3Com Com Com 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 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 /24 Regisztrált gépek és szerverek 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

19 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 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 Megjegyzés BIND 9 Apache 2.2 el ny a https esetén az IPv4-hez képest Oracle 11g Windows AD IIS >6.0 Sendmail > táblázat. Kiszolgáló oldali szoftverek listája az AAIT tanszéken Alkalmazás IPv6 kompatibilitás Megjegyzés Internet Explorer >7 Firefox Outlook >2007 Windows Live Messenger 2.3. táblázat. Kliens oldali szoftverek listája az AAIT tanszéken 19

20 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

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

22 Az aut-switch.aut.bme.hu (kés bbiekben aut-switch) nev virtuális gép az Internetet szimulálja a tesztkörnyezet felé, míg az ns.aut.bme.hu (ns) nev gép a tanszéken található 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 IPv4 beállítása 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 /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 /252 címet kapja, míg a bels a /24-eset. Az aut-switch gép a /24-es tartomá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 /24. Ez az IP cím tartomány a nem regisztrált gépeknek szükséges, és az ns gép NAT-ol a 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

23 végezni 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 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 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 jelöltem ki, az egyik az egyetem által delegált a másik egy privát /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 Kliens oldali alkalmazások Az ns gép összeállítása utána kliens oldali teszt virtuális gépeket telepítettem. következ virtuális gépeket hoztam létre: A Windows XP Windows 7 Ubuntu Linux 23

24 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) 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 /24 tartományból), és ugyanúgy a 2.2 táblázatban szerepl programokat telepítettem, mint a kliensek esetében 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 ( ) címre 24

25 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 lehet 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

26 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

27 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) x 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

28 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

29 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 DUID (DHCPv6 uniqe identier) azonosítóját. A DUID egy valamilyen algoritmus által generált számsorozat (á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

30 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 kon- gurá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 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 felosztá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 6to4 tunnelinget, csak az alábbi sorokat kellett hozzáadni az interfaces állományhoz: 30

31 auto tun6to4 i f a c e tun6to4 i n e t 6 v4tunnel address : : D180 : 2 : : 1 netmask 64 endpoint any l o c a l gateway : : t t l 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 endpoint paraméter segítségével meghatározhatjuk, hogy milyen. A gateway annak az átjárónak az IPv6 címe, ami csatorna másik felén van. Az :: cím azt jelenti, hogy az interfész a IPv4 anycast címre továbbítja a csomagokat. tartozó IPv4 címet tartalmazza. A local mez a csatorna helyi gépéhez 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 :~ $ t r a c e r o u t e 6 ipv6. g o o g l e. com t r a c e r o u t e to ipv6. g o o g l e. com (2 a00 : : : : 6 9 ), 30 hops max, 80 byte packets : : d180 : 1 : : 2 ( : : d180 : 1 : : 2 ) ms ms ms : c 3 6 f : 6 1 c0 : : 1 ( : c 3 6 f : 6 1 c0 : : 1 ) ms ms ms 3 c6513. vh. hbone. hu ( : : : 4 ) ms ms ms : : : 1 7 : : 1 ( : : : 1 7 : : 1 ) m... TTL módosítás nélkül: benjoe@ns :~ $ t r a c e r o u t e 6 ipv6. g o o g l e. com t r a c e r o u t e to ipv6. g o o g l e. com (2 a00 : : : : 6 3 ), 30 hops max, 80 byte packets : : d180 : 1 : : 2 ( : : d180 : 1 : : 2 ) ms ms ms t e l i a s o n e r a. tsd. cw. net ( : : : 9 : : 2 ) ms 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

32 2002:9842:D180:1::2/64-et. Ezután már lehetett pingelni tetsz leges publikus IPv6 címet: ping6 ipv6. g o o g l e. com PING ipv6. g o o g l e. com(2 a00 : : : : 6 8 ) 56 data bytes 64 bytes from 2 a00 : : : : 6 8 : icmp_seq=1 t t l =55 time =60.5 ms 3.4. Stateless konguráció A 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ó 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 IP címet jelent szerverenként. Ezzel összesen 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: i n t e r f a c e eth0 { AdvSendAdvert on ; AdvManagedFlag o f f ; AdvOtherConfigFlag on ; MinRtrAdvInterval 5 ; MaxRtrAdvInterval 1 5 ; p r e f i x : : D180 : : / 6 4 { AdvOnLink o f f ; 32

33 3.2. ábra. Stateless kongurációval kiépített IPv6 hálózat Tartomány Felhasználás 2002:9842:d180::xxxx:xx:fexx:xxxx 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 Nem regisztrált gépek 3.2. táblázat. Stateless konguráció esetén IP cím tartományok 33

34 AdvAutonomous on ; } ; } ; Az állomány struktúrája hasonlít az ISC DHCP szerver struktúrájához. Minden hálózati csatolót külön kell kongurálni interface blokkok segítségével. A szervernek csak egy csatolója lóg be a teszthálózatba ezért elég egy interface entitást létrehozni. Az AdvSendAlert engedélyezi az RA üzenetek kiküldését, az AdvManagedFlag és a AdvOtherCongFlag opciók a már tárgyalt M és O agekenek felel meg. Jelen esetben csak az O ag on, mivel nem szeretnénk a DHCP szervernek delegálni a címosztást. A 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 klienseknek, 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 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

35 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 Regisztrált Nem regisztrált Szerverek cél kliensek kliensek BMENET Szerverek minden semmi semmi minden Regisztrált https, http minden semmi semmi kliensek smb, ftp, rdp Nem regisztrált kliensek http,https semmi semmi http,https BMENET minden semmi semmi semmi 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 á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

36 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 : : 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 2 64 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

37 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 i n t e r f a c e ipv6 i n s t a l l 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 i n t e r f a c e ipv6 s e t privacy e d i s a b l e d netsh i n t e r f a c e ipv6 s e t g l o b a l 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 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

38 analóg az IPv4 beállításokkal 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 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ó 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: i n t e r f a c e eth0 { AdvSendAdvert on ; AdvManagedFlag o f f ; AdvOtherConfigFlag on ; MinRtrAdvInterval 5 ; MaxRtrAdvInterval 1 5 ; } ; Jól látható, hogy kikerült az egész prex blokk a kongurációs fájlból. Az el z fejezetben volt szó az AdvAutonomous 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