Az előadás letöltése folymat van. Kérjük, várjon

Az előadás letöltése folymat van. Kérjük, várjon

DNS, DHCP és 3G UMTS Mobil és vezetéknélküli hálózatkezelés Linux és * BSD operációs rendszerek alatt Bokor László BME-HT

Hasonló előadás


Az előadások a következő témára: "DNS, DHCP és 3G UMTS Mobil és vezetéknélküli hálózatkezelés Linux és * BSD operációs rendszerek alatt Bokor László BME-HT"— Előadás másolata:

1 DNS, DHCP és 3G UMTS Mobil és vezetéknélküli hálózatkezelés Linux és * BSD operációs rendszerek alatt Bokor László BME-HT

2 DNS, DHCP és 3G UMTS2 Áttekintés  DNS –Alapok –Szolgáltatások –Hierarchia –Névfeloldás  DHCP –Alapok –Működés  3G UMTS –Mobil telekommunikáció generációinak fejlődése –PPP alapok –3GPP UMTS architektúra –Fontosabb fogalmak –BME-MIK 3G UMTS tesztrendszer

3 DNS, DHCP és 3G UMTS3 DNS – Alapok I.  Egy forrás és cél host közti IP alapú kommunikációhoz mindkét állomásnak érvényes IP címmel kell rendelkeznie –Probléma: az IP-címek az emberek számára nehezen memorizálhatók –Megoldás: könnyen olvasható tartomány- és állomásnevek (pl. melyek az emberek számára sokkal kényelmesebb azonosítók  A könnyen megjegyezhető tartomány/állomásnevek és a hálózati réteg működésében nélkülözhetetlen (de nehezen memorizálható) IP címek fordítását a hálózati névfeloldó- rendszerek végzik.

4 DNS, DHCP és 3G UMTS4 DNS – Alapok II.  Az Internet hajnalán az IP-címek és állomásnevek egyetlen adminisztrációs szerveren, a központilag tárolt HOSTS nevet viselő állományban voltak egymáshoz rendelve.  Ez az állomány tartalmazta az internetre kötött összes állomás nevét és IP-címét. Az állomásnév megadása után a küldő fél a HOSTS állomány letöltött példányából kereste ki a cél IP-címét.  Ez a HOSTS állomány eleinte ki tudta elégíteni az internetre csatlakoztatott számítógépek igényeit, ám az IP terjedésével az állomásnév-cím feloldást igénylő hostok száma nagyon megnőtt, így a HOSTS alapú működés fenntarthatatlanná vált, új megoldás kellett.  A megoldás neve a Domain Name Service (DNS): a DNS szerverek elosztott alapú működéssel oldják meg névfeloldást.  Egy darabka múlt: napjainkban is minden állomás TCP/IP stack-je kezel egy HOSTS állományt. A feloldási folyamat elején, annak részét képezve a DNS szolgáltatás igénylése előtt az állomás a helyi HOSTS állományban keres először. Szerpe: –Hibakeresés –DNS ideiglenes helyettesítése –DNS folyamat – korlátozott képességű – gyorsítása

5 DNS, DHCP és 3G UMTS5 Példa HOSTS fájlra mik:/home/goodzi# cat /etc/hosts localhost mail oxserver samba.mik.bme.hu MIK ocmpvideo # The following lines are desirable for IPv6 capable hosts #::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters ff02::3 ip6-allhosts

6 DNS, DHCP és 3G UMTS6 DNS információ lekérése - dig mik:/home/goodzi# dig ; > DiG P3 > ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 8 ;; QUESTION SECTION: ;www.index.hu. IN A ;; ANSWER SECTION: 214 IN A ;; AUTHORITY SECTION: hu IN NS NS2.NIC.FR. hu IN NS NS1.NIC.hu. hu IN NS NS-COM.NIC.hu. hu IN NS NS3.NIC.hu. hu IN NS NS-SE.NIC.hu. hu IN NS NS2.NIC.hu. hu IN NS NS.NIC.hu. ;; ADDITIONAL SECTION: NS2.NIC.FR IN A NS1.NIC.hu. 863 IN A NS-COM.NIC.hu. 863 IN A NS3.NIC.hu. 863 IN A NS-SE.NIC.hu. 863 IN A NS2.NIC.hu. 863 IN A NS.NIC.hu IN A NS2.NIC.FR IN AAAA 2001:660:3005:1::1:2 ;; Query time: 5 msec ;; SERVER: #53( ) ;; WHEN: Wed Mar 17 14:40: ;; MSG SIZE rcvd: 326

7 DNS, DHCP és 3G UMTS7 DNS információ lekérése - nslookup mik:/home/goodzi# nslookup Server: Address: #53 Non-authoritative answer: Name: Address:

8 DNS, DHCP és 3G UMTS8 Inverz lekérés – dig -x mail:/home/goodzi# dig -x ; > DiG P3 > -x ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4487 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ; in-addr.arpa. IN PTR ;; ANSWER SECTION: in-addr.arpa IN PTR sportgeza.hu. ;; AUTHORITY SECTION: in-addr.arpa IN NS ns.index.hu in-addr.arpa IN NS ns.inventra.hu. ;; ADDITIONAL SECTION: ns.index.hu IN A ns.inventra.hu IN A ;; Query time: 72 msec ;; SERVER: #53( ) ;; WHEN: Wed Mar 17 14:42: ;; MSG SIZE rcvd: 177

9 DNS, DHCP és 3G UMTS9 DNS – Alapok III.  Erőforrás bejegyzés és domainnév-tartomány –Az erőforrás bejegyzés (resource record) egy bejegyzés az adott DNS zóna adatbázis állományában. A bejegyzés azonosítja az állomás típusát, IP-címét vagy a DNS adatbázis vonatkozó paraméterét. –A domainnév-tartomány több al-tartományból vagy csoportból, és azokon belüli újabb erőforrás bejegyzésekből jön létre. Célja, hogy biztosítsa az erőforrások hierarchikus felépítését.  DNS szerver –A DNS szerverek tartják karban az erőforrás bejegyzéseknek és a domainnév-tartomány információinak adatbázisát. A DNS szerverek a beérkezett kéréseket először megpróbálják a saját zónájuk adatbázisában tárolt bejegyzések alapján feloldani. Ha az adott DNS szerver nem rendelkezik a kért információval, akkor további, előre meghatározott DNS szerverek bevonásával válaszolja meg a kérést.  Névfeloldó –A névfeloldó (resolver) olyan alkalmazás (esetleg rendszerfunkció), mely az ügyfeleken és a szervereken egyaránt fut. Az ügyfeleken egy tartománynév használatba vételekor betöltődik, és indít egy DNS kérést a szerver felé. A szervereken – ha az nem rendelkezik a kért információval egy beérkező kérés megválaszolásához – továbbítja a kérést egy másik DNS szerverhez.

10 DNS, DHCP és 3G UMTS10 DNS beállítások a kliens gépen mik:/home/goodzi# cat /etc/resolv.conf domain bme.hu search hit.bme.hu nameserver nameserver nameserver nameserver 2001:738:2001:21a0:217:34ff:fe05:f75c mik:/home/goodzi# cat /etc/host.conf order hosts,bind multi on

11 DNS, DHCP és 3G UMTS11 DNS – Hierarchia I.  A DNS rendszer felépítése hierarchikus és az egész Internetre elosztott.  A hierarchiához DNS tartománynevek segítségével biztosítható használ amely kisebb, könnyen kezelhető zónákra osztható. A DNS szerverek jól körülhatárolt fennhatóságú adatbázist kezelnek és csak a DNS rendszer kis részéért felelősek.  Ha egy DNS szerver olyan névre kap kérést, mely név nem a saját zónájához tartozik, akkor egy másik, a megfelelő zónát kezelő szerverhez továbbítja beérkező feloldási igényt.  Ennek köszönhetően a DNS egy jól bővíthető rendszer!

12 DNS, DHCP és 3G UMTS12 DNS – Hierarchia II.  A DNS hierarchia egy olyan, fordított fához hasonlít, melynek a felül van a gyökere és alul az ágai.  A DNS hierarchia tetején a gyökér (root) szerverek tartják karban a legmagasabb szintű (top-level) tartományok elérhetőségéről tárolt információkat, melyek aztán legtöbbször visszamutatnak a második szintű (second level) tartományok szervereire.  A top-level tartományok a hozzájuk tartozó szervezetek típusát vagy országát jelentik. Pl.: –.com –üzleti vállalat –.hu – Magyarország –.au – Ausztrália –.org – nonprofit szervezet  A top-level tartományok alatt a második (majd még alacsonyabb) szintű tartományok találhatók: –.bme.hu – BME –.mik.bme.hu – BME-MIK –mail.mik.bme.hu – levelezőszerver a BME-MIK szervezetén belül

13 DNS, DHCP és 3G UMTS13 DNS – Hierarchia III.  A DNS hierarchia gyökerében lévő (root) DNS szerver nem feltétlenül tudja, hogy pontosan hol vannak az ágak (pl. a mail.mik.bme.hu) de vannak rekordjai a top-level tartományról (pl. a.hu top-level tartományról). A.hu tartományba tartozó szerverek szintén nem biztos, hogy ismerik a mail.mik.bme.hu címét, de van bejegyzésük a bme.hu tartományról. Hasonlóan, a bme.hu tartománynak van bejegyzése a mik.bme.hu-ról, a mik.bme.hu névszervere pedig már fel fogja tudni oldani a mail.mik.bme.hu IP- címét.  Látható, hogy a DNS szolgáltatás erősen decentralizált kiszolgáló hierarchián alapul. Az erőforrás bejegyzések tartalmazzák azokat a tartományneveket, melyeket a DNS szerverek feloldanak és ezeket az információkat más szerverek szintén lekérdezhetik tőlük.  A mail.mik.bme.hu egy ún. teljesen minősített tartománynév (FQDN – Fully Qualified Domain Name): megadja az adott állomás pontos helyét a hierarchikus DNS névtartományban.

14 DNS, DHCP és 3G UMTS14 DNS – Névfeloldás I.  Ha egy állomás DNS névfeloldást indít, akkor a resolver segítségével fog kapcsolatba lépni a tartományán belüli DNS szerverrel (a resolver ismeri a DNS szerver IP-címét, ez az adat része az állomás alapvető konfigurációs paramétereinek).  Amikor a DNS szerver kérést kap egy ügyfél resolver-től, akkor a kérést először a helyi DNS bejegyzések gyorstárjában (cache) lévő adatok alapján próbálja megválaszolni. Ha a cache-ben nincs válasz, akkor a szerver resolver funkciója a kérést egy másik DNS szerver felé közvetíti. A folyamat egészen addig folytatódik, amíg a kérés válasza elő nem áll, majd a válasz (vagyis a névfeloldási információ) visszakerül az eredeti szerverhez, ami válaszol az ügyfélnek.  A DNS névfeloldás folyamatai alatt valamennyi DNS szerver eltárolja a kérésekre érkezett válaszokat a cache-ben. A gyorstárban tárolt adatokat használva a DNS szerver gyorsíthat az válaszadás folyamatán, mert a szerver először mindig a cache- ben lévő adatok alapján kísérli meg a válaszadást.  A DNS szerverek csak egy adott ideig tárolják az információt gyorstárjaikban, hiszen az állomásnév bejegyzések időről-időre változhatnak, tehát a cache adatai elévülhetnek.

15 DNS, DHCP és 3G UMTS15 A DNS névfeloldás csomagszekvenciája mik:/home/goodzi# nslookup mik:/home/goodzi# tshark -i eth1 -R dns > DNS Standard query A origo.hu > DNS Standard query response A mik:/home/goodzi# nslookup ipv6.google.com mik:/home/goodzi# tshark -i eth1 -R dns > DNS Standard query AAAA ipv6.google.com > DNS Standard query response AAAA 2a00:1450:8001::68

16 DNS, DHCP és 3G UMTS16 DNS – Dinamikus frissítés  A DNS korai implementációiban az erőforrás bejegyzések felvitele és módosítása csak kézzel történhetett. A DNS zónák kezelésének és karbantartásának megkönnyítésére a DNS protokollt úgy módosították, hogy az egyes állomások saját bejegyzéseiket dinamikusan frissíthessék.  A dinamikus frissítéssel a DNS ügyfelek adataikban bekövetkezett változásai esetén azonnal frissíthetik saját DNS bejegyzéseiket. Ezt a speciális funkciót a DNS szervernek, a DNS kliensnek és a DHCP szervernek egyaránt támogatnia kell. A legtöbb, napjainkban elterjedt operációs rendszer támogatja a dinamikus frissítés funkcióit.

17 DNS, DHCP és 3G UMTS17 DNS - Zónák  A DNS szerverek a teljes DNS hierarchia csak egyetlen, meghatározott szeletének zóna adatbázisát kezelik (az adott szelet erőforrás bejegyzései a DNS zónában kerülnek tárolásra).  A DNS zónák címkeresési (forward lookup) vagy névkeresési (reverse lookup) zónák lehetnek, és ezeken belül megkülönböztetünk elsődleges vagy másodlagos címkeresési, ill. névkeresési zónákat.  Címkeresési zóna –Hagyományos DNS zóna, mely egy FQDN-t old fel IP-címre. Egy weboldal URL-jének (például böngészőbe való bevitele egy rekurzív kérést indít helyi DNS kiszolgálóhoz a név feloldására.  Névkeresési zóna –A névkeresési zóna IP címeket old fel FQDN tartománynevekre. Bizonyos alkalmazások – biztonsági célokból – névkeresést használnak a velük kommunikáló állomások azonosítására.  Elsődleges zóna –Az elsődleges DNS zóna módosítható: ha új erőforrás bejegyzést kell felvenni vagy egy létezőt kell módosítani vagy törölni kell akkor az elsődleges zónát szerkesztik. Minden DNS tartományban egyetlen elsődleges zóna lehet (illetve egyetlen elsődleges címkeresési és egyetlen elsődleges névkeresési zóna).  Másodlagos zóna –A másodlagos zóna biztonsági célokat szolgál: ez egy csak olvasható tartalék zóna, melyet az elsődleges zónától fizikailag is elkülönítve (külön szerveren) tárolni. A másodlagos zóna tulajdonképpen az elsődleges zóna másolata és az elsődleges zónából frissül. Másodlagos zónából is létezhet címkeresési és névkeresési zóna is.

18 DNS, DHCP és 3G UMTS18 Példa címkeresési zónafájlra mik:/home/goodzi# cat /etc/bind/master/mik.bme.hu $TTL SOA ns.mik.bme.hu. dns-admin.mik.bme.hu. ( H 3H 7D 600 ) NS ns.mik.bme.hu. NS pavo.hit.bme.hu. NS ara.hit.bme.hu. MX 10 mail MX 20 www2 kamu NS backup.mik.bme.hu. exchange NS A ns A mail A gallery A qoe A opensbc A calendar A location A samba A wlan A www A home A home AAAA 2001:738:2001:20a0:216:35ff:fe04:f76c test A ibm1 A ibm2 A gep4 A gep5 A wlan1 A wlan2 A

19 DNS, DHCP és 3G UMTS19 Példa IPv4-es névkeresési zónafájlra mik:/home/goodzi# cat /etc/bind/master/ in-addr.arpa $TTL in-addr.arpa. IN SOA ns.mik.bme.hu. dns-admin.mik.bme.hu. ( ;Serial number ;Refresh 3600 ;Retry ;Expire 86400) ;Minimum TTL NS ns.mik.bme.hu. NS pavo.hit.bme.hu. NS ara.hit.bme.hu. 2 IN PTR ns0.mik.bme.hu. 3 IN PTR miksolaris.mik.bme.hu. 4 IN PTR ibm1.mik.bme.hu. 5 IN PTR ibm2.mik.bme.hu. 6 IN PTR gep4.mik.bme.hu. 7 IN PTR gep5.mik.bme.hu. 8 IN PTR wlan1.mik.bme.hu. 9 IN PTR wlan2.mik.bme.hu. 10 IN PTR wlan3.mik.bme.hu. 11 IN PTR wlan4.mik.bme.hu. 12 IN PTR wlan5.mik.bme.hu. 13 IN PTR switch1.mik.bme.hu. 14 IN PTR switch2.mik.bme.hu. 15 IN PTR switch3.mik.bme.hu. 16 IN PTR switch4.mik.bme.hu. 17 IN PTR switch5.mik.bme.hu. 18 IN PTR gep16.mik.bme.hu.

20 DNS, DHCP és 3G UMTS20 Példa IPv6-os névkeresési zónafájlra mik:/home/goodzi# cat /etc/bind/master/ IP6.ARPA $TTL IP6.ARPA. IN SOA ns.mik.bme.hu. dns- admin.mik.bme.hu. ( ;Serial number ;Refresh 3600 ;Retry ;Expire 600) ;Minimum TTL NS ns.mik.bme.hu. NS pavo.hit.bme.hu. NS ara.hit.bme.hu. d.6.7.f.4.0.e.f.f.f IN PTR ns.mik.bme.hu. 1.c e.f.f.f.d.5.b IN PTR mnn1-eth.anemone.mik.bme.hu IN PTR gw.anemone.mik.bme.hu a.2.e.f.f.f.f IN PTR sun-gw.anemone.mik.bme.hu IN PTR sun-ha.anemone.mik.bme.hu IN PTR mr1-hoa.anemone.mik.bme.hu IN PTR pc1.anemone.mik.bme.hu.

21 DNS, DHCP és 3G UMTS21 DHCP - Alapok  A DHCP (Dynamic Host Configuration Protocol) a TCP/IP hálózatra csatlakozó kliens végpontok hálózati beállításainak automatikus konfigurációjára való. Segítségével a kliens megtudhatja az alábbiakat: –IP-cím –hálózati maszk –alapértelmezett átjáró –DNS szerver címe  A DHCP kliens-szerver alapú, működése a kliensek által küldött kérésekből, és a DHCP szerver által küldött válaszokból áll.  A DHCP segítségével dinamikusan oszthatók ki IP-címek, ami a rendelkezésre álló tartomány gazdaságos felhasználását teszi lehetővé (a hálózatról lecsatlakozó végpontok IP-címeit megkaphatják a hálózatra újonnan felcsatlakozók).  Három féle IP-cím kiosztás: –automatikus (DHCP-vel osztható IP-tartomány megadásával) –kézi (MAC cím alapján) –dinamikus (olyan IP-tartomány megadásával, ahol az IP címek „újrahasznosíthatók”)

22 DNS, DHCP és 3G UMTS22 DHCP - Működés  Mikor egy végpontot először állítunk be a hálózatba, az még nem rendelkezik IP címmel, alhálózati maszkkal, alapértelmzett átjáróval vagy DNS szerver címmel.  Ezeket, a hálózati működéshez szükséges a beállítási paramétereket a végpont DHCP kliensként, a DHCP szervertől szerzi be.  A DHCP szervert úgy állítják be, hogy bírjon az IP címeknek egy olyan tartományával, melyből oszthat az ügyfeleknek.  A működés: –A beállításokat igénylő kliens egy DHCP felderítés (DHCP Discover) üzenetet küld cél IP, és FF-FF-FF-FF-FF-FF cél MAC címmel. –A hálózat valamennyi állomása fogadja ezt a szórásos DHCP keretet, de csak a DHCP szerver fog válaszolni rá: egy felajánlást (DHCP Offer) küld a kliensnek, melyben ajánl egy IP címet. –A kliens állomás ezután egy igénylést (DHCP Request) küld a szervernek, kérve, hogy használhassa a felajánlott címet. –A szerver egy jóváhagyással (DHCP Acknowledgement) fejezi be a négy üzenetből álló mechanizmust.

23 DNS, DHCP és 3G UMTS23 DHCPv4 használata a kliens gépen mik:/home/goodzi#dhclient eth2 Internet Systems Consortium DHCP Client V3.0.4 Copyright Internet Systems Consortium. All rights reserved. For info, please visit Listening on LPF/eth2/00:14:4f:2a:03:8a Sending on LPF/eth2/00:14:4f:2a:03:8a Sending on Socket/fallback DHCPDISCOVER on eth2 to port 67 interval 4 DHCPOFFER from DHCPREQUEST on eth2 to port 67 DHCPACK from bound to renewal in seconds. mik:/home/goodzi#tshark -i eth > DHCP DHCP Request - Transaction ID 0xf > DHCP DHCP ACK - Transaction ID 0xf

24 DNS, DHCP és 3G UMTS24 A mobil távközlés generációi

25 DNS, DHCP és 3G UMTS25 Kitekintés: 3G és B3G

26 DNS, DHCP és 3G UMTS26 A 3GPP UMTS architektúra (Release 6)

27 DNS, DHCP és 3G UMTS27 3G User Plane protokoll stack

28 DNS, DHCP és 3G UMTS28 Fontosabb fogalmak  PDP (Packet Data Protocol) kontextus –A mobil PDP kontextusának aktiválásakor az SGSN és a GGSN létrehozza az adott kommunikációs folyamat (session) kezeléséhez szükséges információkat (IP cím, QoS) tartalmazó adatstruktúrát (kontextust)  APN (Access Point Name) –GGSN-hez tartozó logikai név, mely egy külső hálózatot is azonosít (Az SGSN DNS lekéréssel találja meg a mobil által igényelt APN-hez tartozó kiszolgáló GGSN-t)  GTP (GPRS Tunneling Protocol) –UDP/IP alapú alagutazó protokoll mely a külső csomagkapcsolt hálózat és a GPRS hálózaton belüli mobil egység közti kapcsolatért felel

29 DNS, DHCP és 3G UMTS29 Állapottartó IPv4/IPv6 auto- konfiguráció UMTS hálózatokban

30 DNS, DHCP és 3G UMTS30 Állapotmentes IPv6 auto-konfiguráció UMTS hálózatokban

31 DNS, DHCP és 3G UMTS31  A Point-to-Point Protocol (PPP) egy alapvetően soros összeköttetések számára tervezett adatkapcsolati protokoll  Az adatkapcsolati rétegben működik, de itt újabb alrétegeket (alprotokollokat) definiál, melyek segítségével képes multi-protokoll adatcsomagok beágyazására és átvitelére is a létrehozott pont-pont kapcsolatokon keresztül  A PPP protokoll rögzített és nyílt szabványokon (RFC 1661, 2153, stb.) alapul, ezért lehetővé teszi a különböző gyártóktól származó készülékek közötti kommunikációt is PPP alapok I.

32 DNS, DHCP és 3G UMTS32 PPP alapok II.  A PPP két alprotokollt definiál: –Kapcsolatvezérlő protokoll (Link Control Protocol, LCP): a pont-pont kapcsolatok felépítését, fenntartását és lebontását menedzseli. –Hálózatvezérlő protokoll (Network Control Protocol, NCP): a különböző hálózati protokollokkal való együttműködést biztosítja.

33 DNS, DHCP és 3G UMTS33 PPP - Kapcsolatvezérlő protokoll (LCP)  Az LCP a pont-pont összeköttetések létrehozására, fenntartására, tesztelésére és terminálására használatos. Az LCP legfontosabb feladatai: –tömörítés –hibafelismerés –hitelesítés (authentication) –több kapcsolat (multilink) –konfigurációs hibákat észlelése –különböző méretű csomagok kezelése –kapcsolatdiagnosztika

34 DNS, DHCP és 3G UMTS34 PPP - Hálózatvezérlő protokoll (NCP)  Az NCP a különböző hálózat rétegbeli protokollok beágyazására használatos (így eltérő hálózati protokollok, mint pl. IPv4 és IPv6, is képesek ugyanazon kommunikációs kapcsolatot használni).  A PPP kapcsolatokon használt valamennyi hálózati protokollnak saját hálózatvezérlő alrétegre (protokollra) van szüksége a PPP-n belül. Az IP az IP vezérlőprotokollt (IPCP, IP6CP), az IPX pedig az IPX vezérlőprotokollt (IPXCP) használja.

35 DNS, DHCP és 3G UMTS35 PPP - Működés  A PPP-kapcsolatok létrehozásának folyamata három fázisra bontható  Az összeköttetés létrehozása (kapcsolatfelépítés) –A PPP LCP keretekkel teszteli és konfigurálja az adatkapcsolatot. Az LCP-keretek konfigurációs mezőjét használva van mód például a maximális átviteli egység (MTU) méretének, a tömörítés típusának és a használt hitelesítési típusnak az egyeztetésére. A kapcsolat hitelesítési típusának egyeztetése és az átviteli minőség tesztelése opcionálisak. A kapcsolatfelépítés fázisa akkor tekinthető befejezettnek, ha a végponti berendezések megkapták az aktuálisan használandó konfigurációt nyugtázó LCP keretet.  Hitelesítés (opcionális) –Ez a fázis jelszavas védelmet biztosít a kapcsolódó végpontok azonosításához (pl. PAP, CHAP). A hitelesítésre a végpontok kapcsolatparamétereinek elfogadása után, de még az NCP egyeztetési fázis kezdete előtt kell sort keríteni.  NCP egyeztetés –A PPP NCP csomagok segítségével választ ki és konfigurál egy vagy több hálózati rétegbeli protokollt (pl. IPv4-et, IPv6-ot). Ha az LCP bontja a kapcsolatot, akkor értesíteni kell a hálózati rétegbeli protokollokat is, hogy azok végrehajthassák a megfelelő műveleteket. Egy létrejött PPP kapcsolat mindaddig aktív marad, amíg az LCP vagy az NCP nem bontja a kapcsolatot (vagy le nem jár a kapcsolat élettartama). Természetesen a felhasználók is inicializálhatják a PPP kapcsolatok befejezését.

36 DNS, DHCP és 3G UMTS36 Modem vezérlése: AT parancsok  PIN –Command: AT+CPIN? Response: +CPIN: –Command: AT+CPIN= [, ] Response: OK | +CME ERROR:  PDP (Packet Data Protocol) context –Command: AT+CGDCONT= [, [, [, [, [,

37 DNS, DHCP és 3G UMTS37 AT parancsok kiadása: wvdial cat /etc/wvdial.conf [Dialer nokia6] #Init1 = AT+CPIN=1234 Modem = /dev/ttyACM0 Carrier Check = no Auto DNS = 0 Init2 = AT+CGDCONT=1,"IPV6","test6",,0,0 Phone = *99# New PPPD = yes Username = a Password = a Baud = Stupid mode = 1

38 DNS, DHCP és 3G UMTS38 BME-MIK 3G UMTS architektúra

39 DNS, DHCP és 3G UMTS39 A demonstráció során használt fontosabb rendszerelemek  User Equipment –Nokia N93i –Symbian OS v9.1, S60 3rd edition felhasználói interfész, V firmware  GGSN (APN=test, IPv4) –Cisco 7206, IOS 12.4 c7200-adventerprisek9_mw-mz T3.bin –Cisco GGSN Release 6.0  GGSN (APN=test6, IPv6) –OpenGGSN 0.84 továbbfejlesztése OpenGGSN 0.84_v6_03 –SunFire X4200 hardveren fut, Ubuntu Server 7.04 operációs rendszeren, as kernelen –Fejlesztése jelenleg is folyik a MIK berkein belül

40 DNS, DHCP és 3G UMTS40 A wvdial futtatása (natív IPv6 3G) wvdial nokia6 --> WvDial: Internet dialer version > Cannot get information for serial port. --> Initializing modem. --> Sending: ATZ ATZ OK --> Sending: AT+CGDCONT=1,"IPV6","test6",,0,0 AT+CGDCONT=1,"IPV6","test6",,0,0 OK --> Modem initialized. --> Sending: ATDT*99# --> Waiting for carrier. ATDT*99# CONNECT } }*} } g}%~ --> Carrier detected. Starting PPP immediately. --> Starting pppd at Mon Nov 3 11:58: > Pid of pppd: > Using interface ppp0 --> Authentication (PAP) started --> Authentication (PAP) successful

41 DNS, DHCP és 3G UMTS41 A hoston létrejött ppp interfész ifconfig ppp0 Link encap:Point-to-Point Protocol inet6 addr: 2001:738:2001:20a9:1234:1234:1234:1234/64 Scope:Global inet6 addr: fe80::1234:1234:1234:1234/10 Scope:Link UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:17 errors:0 dropped:0 overruns:0 frame:0 TX packets:4 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:1304 (1.2 KiB) TX bytes:56 (56.0 b)

42 DNS, DHCP és 3G UMTS42 pppd logok: a 3G kapcsolat kiépítése tail -f 40 /var/log/syslog | grep pppd Nov 3 11:56:34 anemone-mnn2 pppd[6019]: pppd started by anemone, uid 1000 Nov 3 11:56:34 anemone-mnn2 pppd[6019]: using channel 2 Nov 3 11:56:34 anemone-mnn2 pppd[6019]: Using interface ppp0 Nov 3 11:56:34 anemone-mnn2 pppd[6019]: Connect: ppp0 /dev/ttyACM0 Nov 3 11:56:34 anemone-mnn2 pppd[6019]: sent [LCP ConfReq id=0x1 ] Nov 3 11:56:34 anemone-mnn2 pppd[6019]: rcvd [LCP ConfRej id=0x1 ] Nov 3 11:56:34 anemone-mnn2 pppd[6019]: sent [LCP ConfReq id=0x2 ] Nov 3 11:56:34 anemone-mnn2 pppd[6019]: rcvd [LCP ConfAck id=0x2 ] Nov 3 11:56:35 anemone-mnn2 pppd[6019]: rcvd [LCP ConfReq id=0x0 ] Nov 3 11:56:35 anemone-mnn2 pppd[6019]: sent [LCP ConfAck id=0x0 ] Nov 3 11:56:35 anemone-mnn2 pppd[6019]: sent [PAP AuthReq id=0x1 user="a" password= ] Nov 3 11:56:35 anemone-mnn2 pppd[6019]: rcvd [PAP AuthAck id=0x1 ""] Nov 3 11:56:35 anemone-mnn2 pppd[6019]: PAP authentication succeeded Nov 3 11:56:35 anemone-mnn2 pppd[6019]: sent [IPV6CP ConfReq id=0x1 ] Nov 3 11:56:35 anemone-mnn2 pppd[6019]: rcvd [IPV6CP ConfReq id=0x0 ] Nov 3 11:56:35 anemone-mnn2 pppd[6019]: sent [IPV6CP ConfNak id=0x0 ] Nov 3 11:56:36 anemone-mnn2 pppd[6019]: rcvd [IPV6CP ConfNak id=0x1 ] Nov 3 11:56:36 anemone-mnn2 pppd[6019]: sent [IPV6CP ConfReq id=0x2 ] Nov 3 11:56:36 anemone-mnn2 pppd[6019]: rcvd [IPV6CP ConfReq id=0x1 ] Nov 3 11:56:36 anemone-mnn2 pppd[6019]: sent [IPV6CP ConfAck id=0x1 ] Nov 3 11:56:36 anemone-mnn2 pppd[6019]: rcvd [IPV6CP ConfAck id=0x2 ] Nov 3 11:56:36 anemone-mnn2 pppd[6019]: local LL address fe80::1234:1234:1234:1234 Nov 3 11:56:36 anemone-mnn2 pppd[6019]: remote LL address fe80::154c:bcf1:77d4:80e5 Nov 3 11:56:36 anemone-mnn2 pppd[6019]: Script /etc/ppp/ipv6-up started (pid 6021) Nov 3 11:56:36 anemone-mnn2 pppd[6019]: Script /etc/ppp/ipv6-up finished (pid 6021), status = 0x0

43 DNS, DHCP és 3G UMTS43 Forgalom a felépült GTP alagútban > GTP Create PDP context request > GTP Create PDP context response fe80::1234:1234:1234:1234 -> ff02::2 GTP Router solicitation fe80::3412:3412:1234:1234 -> ff02::1 GTP Router advertisement :738:2001:20a9:1234:1234:1234:1234 -> 2001:6b0:1:ea:202:a5ff:fecd:13a6 GTP > www [SYN] Seq=0 Len=0 MSS=1340 TSV= TSER=0 WS= :6b0:1:ea:202:a5ff:fecd:13a6 -> 2001:738:2001:20a9:1234:1234:1234:1234 GTP www > [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1440 WS=1 TSV= TSER= :738:2001:20a9:1234:1234:1234:1234 -> 2001:6b0:1:ea:202:a5ff:fecd:13a6 GTP > www [ACK] Seq=1 Ack=1 Win=48240 Len=0 TSV= TSER= :738:2001:20a9:1234:1234:1234:1234 -> 2001:6b0:1:ea:202:a5ff:fecd:13a6 HTTP GET / HTTP/ :6b0:1:ea:202:a5ff:fecd:13a6 -> 2001:738:2001:20a9:1234:1234:1234:1234 GTP [TCP segment of a reassembled PDU] :6b0:1:ea:202:a5ff:fecd:13a6 -> 2001:738:2001:20a9:1234:1234:1234:1234 GTP [TCP segment of a reassembled PDU] :738:2001:20a9:1234:1234:1234:1234 -> 2001:6b0:1:ea:202:a5ff:fecd:13a6 GTP > www [ACK] Seq=370 Ack=2657 Win=47808 Len=0 TSV= TSER= :6b0:1:ea:202:a5ff:fecd:13a6 -> 2001:738:2001:20a9:1234:1234:1234:1234 GTP [TCP segment of a reassembled PDU] :6b0:1:ea:202:a5ff:fecd:13a6 -> 2001:738:2001:20a9:1234:1234:1234:1234 TCP [TCP segment of a reassembled PDU] :738:2001:20a9:1234:1234:1234:1234 -> 2001:6b0:1:ea:202:a5ff:fecd:13a6 GTP > www [SYN] Seq=0 Len=0 MSS=1340 TSV= TSER=0 WS= :6b0:1:ea:202:a5ff:fecd:13a6 -> 2001:738:2001:20a9:1234:1234:1234:1234 GTP www > [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1440 WS=1 TSV= TSER= :738:2001:20a9:1234:1234:1234:1234 -> 2001:6b0:1:ea:202:a5ff:fecd:13a6 GTP > www [ACK] Seq=370 Ack=4703 Win=48418 Len=0 TSV= TSER= :738:2001:20a9:1234:1234:1234:1234 -> 2001:6b0:1:ea:202:a5ff:fecd:13a6 GTP > www [ACK] Seq=1 Ack=1 Win=48240 Len=0 TSV= TSER= :738:2001:20a9:1234:1234:1234:1234 -> 2001:6b0:1:ea:202:a5ff:fecd:13a6 HTTP GET /ipv6.org.css HTTP/ :6b0:1:ea:202:a5ff:fecd:13a6 -> 2001:738:2001:20a9:1234:1234:1234:1234 GTP [TCP segment of a reassembled PDU] :6b0:1:ea:202:a5ff:fecd:13a6 -> 2001:738:2001:20a9:1234:1234:1234:1234 HTTP HTTP/ OK (text/css) :738:2001:20a9:1234:1234:1234:1234 -> 2001:6b0:1:ea:202:a5ff:fecd:13a6 HTTP GET /IPv6-logo.png HTTP/1.1

44 Köszönöm a figyelmet! Bokor László BME-HT


Letölteni ppt "DNS, DHCP és 3G UMTS Mobil és vezetéknélküli hálózatkezelés Linux és * BSD operációs rendszerek alatt Bokor László BME-HT"

Hasonló előadás


Google Hirdetések