SZAKDOLGOZAT ÓBUDAI EGYETEM. Neumann János Informatikai kar Alba Regia Egyetemi Központ

Átírás

1 - 1 - ÓBUDAI EGYETEM Neumann János Informatikai kar Alba Regia Egyetemi Központ SZAKDOLGOZAT OE-NIK Hallgató neve: Berencsi Gergő Zsolt Törzskönyvi száma: T /FI38878/S-N

2 - 2 -

3 - 3 - I. Tartalomjegyzék

4 - 4 - II. Tartalmi összefoglaló 1. A megoldandó probléma megfogalmazása A feladat annak megoldása, hogy az időnként a szolgáltatótól más-más IP-címet kapó szerver gépek, ugyanazon a domain címen legyenek elérhetőek. Ezen belül megoldandó az aldomainek regisztrációja, azok dinamikus frissítése az aktuális IP címre és a felhasználói jogosultságok kezelése. A dolgozat bemutatja a felhasznált technológiákat, a tervezési megfontolásokat, az adatbázis felépítését, a programot és a felhasználói, illetve programozói dokumentációt. III. A probléma elemzése, specifikáció kidolgozása 1. A DNS azaz a Domain Name System (Domain Név Rendszer) működése. A DNS egy hierarchikus, osztott elnevezési rendszer, számítógépek, szolgáltatások, illetve bármilyen más hálózatra kötött erőforrás számára amelyet 1983-ban Paul Mockapetris alakított ki [1]. A rendszer lényege, hogy ne kelljen a felhasználónak megjegyeznie, és állandóan beírnia a kapcsolódási szándékából következő cél szerver IP címét (pl.: ), hanem egyszerűen egy névvel hivatkozni tudjon az adott rendszerre. Ezt valósítja meg a DNS oly módon, hogy az erre kijelölt DNS névfordító gépek feloldják a domaint a náluk meglévő IP címmé és így kiszolgálhatóvá teszik a kérést. Ez alapján például a w5.hu gépnévhez a IP cím tartozik (1.1 ábra). [1] Forrás:

5 - 5 - (1.1 ábra Névfeloldás) A DNS feloldáshoz nem szükséges egy központi fordító állomást állandóan üzemeltetni. A név feloldáshoz először a fő névkiszolgálókhoz fordulnak a gépek (amennyiben a saját névkiszolgálója nem tartalmazza a szükséges bejegyzést). Ezek szolgáltatják az országos domain neveket (pl.:.hu.org.info) és tartalmazzák a további névfordítókat. Így tulajdonképpen egy fa struktúrát alakítanak ki, amely ágain haladva könnyen feloldhatóak a címek. Lássunk erre egy példát. Valamely számítógép keresi a houston.debilinux.hu címét. Először a.hu feloldásáért felelős gépet keresi meg, majd ezután fordul a debilinux.hu fordításáért felelős géphez, majd így fordított sorrendben végighaladva eljut addig a gépig amely szolgáltatni fogja neki a houston.debilinux.hu IP címét. A névfeloldáshoz a bejegyzéseket a névszerverek úgynevezett zónákban tárolják. A zónák tartalmaznak egy FORWARD és egy REVERSE nevű részt. A forward részben vannak azok a bejegyzések, amelyek a domain-t IP címmé alakítják, míg a reverse rész az adott IP címhez szolgáltat domain nevet. 2. A DNS zónák felépítése A zóna bejegyzés: A DNS zóna definiálásakor (amely a névszerver kofigurációjában történik) meg kell adni a zóna típusát (master vagy slave amelynél a slave a masterről frissíti az információit), a filet amely tartalmazza a zóna tulajdonságait és bejegyzéseit, illetve egy bejegyzést arról, hogy honnan elérhető az adott zónafájl (any esetén bárhonnan). A

6 - 6 - reverse zóna neve adott. Ezt meghatározza a tartomány neve, amely formátuma az IP cím nem változó részei fordított sorrendben pontal elválasztva, majd az in-addr.arpa felirat. Pl.: Ha egy lokális zónát definiálunk a /24 -es hálózatra akkor a reverse zóna neve in-addr.arpa. A konfigurációban így néz ki egy zóna bejegyzés: zone tesco { type master; file /etc/bind/tesco; allow-transfer {any;}; }; zone in-addr.arpa { type master; file /etc/bind/tescorev ; }; Ez a minimális követelmény egy zóna bejegyzésére.ezekután nézzünk egy példát a zónafájlok felépítésére is.

7 A forward zóna: (1.2 ábra A forward zóna) A forward zóna (1.2 ábra) egy TTL (Time To Live) értékkel kezdődik, amely meghatározza, hogy mennyi ideig érvényes a belőle kinyert információ. Ez után következik egy SOA rekord. Ebben kell definiálni a zóna alapvető tulajdonságait. jel a zóna nevére illeszkedik, így nem kell mindig kiírni azt. A localhost. az elsődleges névszervert határozza meg, a root.localhost pedig egy cím, amely elválasztó helyett pontot alkalmaz. Ezek után következik 5db szám, melyekből az elsővel szokás jelölni az utolsó módosítás dátumát. Alapesetben ez csak egy növelendő szám, amely alapján ellenőrzik a slave-ek, hogy történt-e módosítás a zónában, de ha a dátumot írjuk bele az információval szolgálhat a későbbiekben. A második szám a Refresh. Ez határozza meg, hogy mennyi időnként ellenőrizzék a slavek, hogy történt-e módosítás. A retry határozza meg, hogy ha nem elérhető a névszerver, akkor ennyi időnként próbálkozzanak újra. Az utolsó előtti expire szám azt adja meg, hogy mennyi ideig szolgáltathatják a zónát a slavek ha az elsődleges névszerver nem elérhető. A Negative Cache TTL adja meg mennyi ideig cache-elhessen egy bejegyzést. A számok minden esetben másodpercben értendők.

8 - 8 - A következő rekord (@ IN NS localhost.) a névszerver rekord. Ez határozza meg, hogy milyen címen érhető el a névszerver. Jelen esetben localhost tehát a saját névszerverét használja. Megadható több ilyen rekord is, ilyen esetben terhelés-megosztással működik a feloldás. Az ezt követő (@ IN A ) rekord egy A típusú rekord, amely IP címet képes rendelni egy adott domain névhez. A domain név itt a zóna neve miatt. A felépítés tehát láthatóan a következő: <domainnév> IN A <ip cím>. A következő egy CNAME típusú rekord (geery IN Ennek a típusnak a lényege hogy domaint képes rendelni egy másik domainhez, tehát a feloldás során egy másik domain nevet kapunk vissza. Ez akkor lehet hasznos, ha például van egy domain nevünk ami automatikusan frissül (mert például a mi névszerverünk frissíti) és van egy amit bérlünk. Ha a béreltet egy CNAME rekorddal a mi domain-ünkre állíttatunk nem kell mindig átirattatni az IP címet amire mutat. Az utolsó bejegyzésbe található AAAA rekord szinte teljes mértékben megegyezik az A rekorddal, csak annyi a különbség, hogy ezt használhatjuk Ipv6-os címek fordítására. Még létezik egy fontos rekord típus, az MX rekord. Ez az forgalom lebonyolításáért felelős, mert mint például itt is a tesco domaint a névszerver re oldja fel, de így ha levélről van szó (pl.: geery@tesco) akkor ebben a bejegyzésben található címet fogja fordítani. Több ilyen rekorddal biztosítható, hogy ne vesszenek el a levelek, mert ha például egy másik átveszi akkor onnantól ő próbálja továbbítani az elsődlegesnek. Az MX rekordok súlyozhatóak. Mindig a kisebb súlyú értékkel próbálkozik először.

9 A reverse zóna: (1.3 ábra A reverse zóna) A reverse zóna (1.3 ábra) egy ugyan olyan SOA rekorddal kezdődik mint a forward és a működése is ugyanaz. Egy dologban tér el, mégpedig abban, hogy itt kell definiálni az úgynevezett PTR rekordokat. Ezek határozzák meg, hogy adott IP-t milyen domainnévre oldjon fel a névszerver. Mivel a definícióban a már meg van adva, itt elegendő a 2 IN PTR asus-geery. bejegyzés. Ha ig lett volna csak, abban az esetben 2.0-t kellene megadni, tehát itt is fordított sorrendben. 3. A DNS problémája A DNS rendszer működése felvet bizonyos problémákat. Az egyik ilyen nagyobb közülük az internet szolgáltatók megoldásaiban rejlik. Némelyik szolgáltató (főleg a DSL-ekre jellemző) 24 óránként bontja az internet kapcsolatot és másik IP címet oszt ki az ügyfélnek. Amennyiben az ügyfél valamilyen (pl.: VNC) szolgáltatást üzemeltet, ez az IP változás problémákat vet fel. A DNS látszólag megoldás erre, de viszont fontos dolog hogy a domain nevek frissüljenek az adott IP-re a lehető leggyorsabban. Amennyiben ez nem történik meg minél hamarabb, a VNC kliens a domain névvel sem tudja megtalálni az adott gépen futó szolgáltatást. Így a szolgáltatás elérhetőségi szempontból nagyon gyenge lesz. Erre a problémára kellene valamiféle gyors, megbízható, dinamikus megoldást találni.

10 IV. Lehetséges megközelítési módok 1. Igénylő rendszer kialakítása a frissítéshez Az igénylő rendszer egy olyan rendszer, amelyben a felhasználók egy adott helyen jelzik IP cím változási problémájukat, majd a másik oldalon ezt egy adminisztrátor fogadja. Az adminisztrátor ezek után átállítja a kérés alapján a megfelelő domaint a megfelelő helyre A rendszer előnyei: A rendszer előnye, hogy az adminisztrátor ellenőrizhet minden kérést és így nem terhelik a rendszert a felhasználó által rosszul megadott kérések A rendszer hátrányai: Az egyik nagyon nagy hátránya ennek a megközelítésnek a sebesség. A kérésnek ugyanis idő kell ahhoz, hogy eljusson az őt kiszolgáló személyhez, így nem történhet meg azonnal a módosítás. A másik probléma, hogy ezzel emberi tényezőt viszünk a rendszerbe, ami felmerülhet később mint hibaforrás (pl.: valamit elír az adminisztrátor), továbbá nagyon magas költséggel is jár.

11 Dinamikus DNS kiszolgáló szerver fejlesztése A dinamikus DNS kiszolgáló szerver egy olyan szolgáltatást nyújt, amelyben a felhasználók a saját domainjeiket, saját maguk kezelhetik. Ilyen rendszerek több helyen léteznek már és használhatók is, ám vagy fizetősek, vagy korlátozottak. Egy saját dinamikus DNS kiszolgáló fejlesztése tehát hosszú távon jó befektetés lehet A rendszer előnyei: A rendszer előnye, hogy adott változtatás azonnal életbe lép, így nincs szolgáltatás kiesés. A másik nagy előny, hogy a felhasználók a szerveken futó (már létező és több helyről ingyen letölthető) IP frissítő kliens programokkal automatikusan frissíthetik a szervereik IP címét. További előny még, hogy egy jól megírt kiszolgáló képes jogosultságokkal korlátozni a felhasználókat, hogy csak a hozzájuk tartozó domainekhez férjenek hozzá A rendszer hátrányai: A fejlesztés költséges lehet, és a rendszert karbantartani is kell. Otthoni kisgépes környezeben nem hatékony, érdemes szerverre telepíteni.

12 V. Módszer kiválasztása, a választás indoklása A módszer kiválasztásánál összevetettem az előnyöket illetve hátrányokat és arra a következtetésre jutottam, hogy a saját DynDNS rendszer a legjobb választás. Ennek az oka, hogy minimális hátránnyal rendelkezik a statikus átírással szemben, a létező bérléssel szemben pedig annyiban jobb, hogy a fejlesztési költséget egyszer kell megfizetni, amely idővel megtérül.

13 VI. A program részletes specifikációja 1. A programmal szemben támasztott követelmények: Felhasználó szintű azonosítás jelszóval védve Felhasználónév Jelszó (tárolás kódolva) Teljes név cím Regisztráció dátuma Admin jogosultság adása védett módon (felhasználói felületről ne lehessen) Megjegyzés Fő domainek tárolása, melyekhez aldomainek regisztrálhatók Domain neve Létrehozó tárolása Létrehozás dátumának tárolása Megjegyzés Lehessen pulikussá tenni domaint, amihez bárki felvehet aldomaint

14 Aldomainek tárolása Melyik fődomainhez tartozik Mi az amihez hozzárendelünk Mit rendelünk hozzá Milyen típusú az adott hozzárendelés (A,AAAA,MX,CNAME) Létrehozó tárolása Létrehozás dátuma Megjegyzés Lehetőség legyen adott domainhez adott usernek jogot adni Domain amihez a jogosultság tartozik Felhasználó aki kapja a jogosultságot Jogosultság létrehozójának tárolása Jogosultság keletkezésének dátuma Megjegyzés Adminisztrációs felület ahol az adminok karbantarthatják az egyes táblákat Felhasználók karbantartása (hozzáadás,törlés,módosítás) Domainek karbantartása (hozzáadás,törlés,módosítás) Aldomainek karbantartása (hozzáadás,törlés,módosítás) Jogosultságok karbantartása (hozzáadás,törlés,módosítás)

15 Egyéb elvárt funkciók Adminisztrációs felületen törlés esetén ha vannak kapcsolódó rekordok más táblákban, csak figyelmeztetés után lehessen törölni (ilyenkor a kapcsolódó rekordok is törlődnek) Adott felhasználó csak azokhoz a domainekhez férhessen hozzá amelyekhez van jogosultsága, vagy pulikusak Adott felhasználó korlátlan számú aldomaint vehessen fel A felhasználó módosíthassa a saját jelszavát (ezen kívül semmi mást) Az adminisztrátor ne férhessen hozzá más jelszavához, csak módosítani tudja azt A felhasználó a már létező felépítésű IP frissítő kliensel aktualizálni tudja az IP címét

16 VII. A tervezés során végzett munkafázisok 1. Megvalósítási mód kiválasztása 1.1. Operációs rendszer választása: Első dolog a megvalósítás kiválasztása során a futtatási környezet kiválasztása. Két lehetőség jött szóba operációs rendszer szinten, hogy Windows vagy Linux környezet alól üzemeltessem-e a szerver oldali programot. Megbízhatósági megfontolásból a Linuxos környezetet választottam, illetve azon okból is mert a Linux disztribúció ingyenes amely csökkenti az üzembe helyezés költségeit. Ha meg kellene vásárolnom az operációs rendszert és még hozzá az adatbáziskezelőt is, a költségek nagyon magasak lennének Adatbázis kiválasztása: Linux operációs rendszer alatt több stabilan működő adatbázis kiszolgáló működik. Ilyenek például a PostgreSQL, a MySQL és még az OracleSQL is feltelepíthető bizonyos Linux disztribúciókra. Az adatbázis kiválasztásánál fontos tényező, hogy a bonyolultságnak megfelelő adatbázist válasszunk. Mivel az adatbázisban nincs szükségünk különleges képességekre ezért talán a legjobb a választás a MySQL. A MySQL egy többfelhasználós, többszálú, SQL-alapú relációs adatbázis-kezelő szerver, amely az egyik legelterjedtebb azon oknál fogva, hogy a teljesen nyílt forráskódú LAMP (Linux-Apache-MySQL-PHP) összeállítás részeként költséghatékony és egyszerűen beállítható megoldást ad a dinamikus webhelyek szolgáltatására. [2] [2] Forrás:

17 Futtatói környezet kiválasztása: A futtatói környezet kiválasztása volt talán az egyik legegyszerűbb feladat. Az adatbázis kiválasztását követően egyértelmű, hogy a MySQL az Apache webkiszolgálóval, és a PHP programnyelvvel képes a leghatékonyabban együtt dolgozni. Az Apache HTTP Server (röviden Apache) nyílt forráskódú webkiszolgáló alkalmazás, szabad szoftver, mely kulcsfontosságú szerepet játszott a World Wide Web elterjedésében. A projekt célja olyan webszerver program létrehozása, karbantartása, és fejlesztése, amely megfelel a gyorsan változó Internet követelményeinek, biztonságos, üzleti, vállalati felhasználásra is megfelelő és szabadon használható. [3] Tehát az Apache webszerver egy jó választás a megvalósításra. A PHP (Hypertext Preprocessor) Rasmus Lerdorf által 1994-ben megalkotott nyílt forráskódú, számítógépes szkriptnyelv, legfőbb felhasználási területe a dinamikus weboldalak készítése és ingyenesen telepíthető a legtöbb operációs rendszerre. [4] 2. Adatbázis szerkezet felépítése A következő fázis az adatbázis felépítése volt. Ezen folyamatot először megpróbáltam teljesen a specifikáció alapján elkészíteni, de ki kellett egészíteni később a programozás logikájából következő mezőkkel. Az adatbázis táblák tehát a következő képpen alakultak: [3] Forrás: [4] Forrás: