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 goodzi@mcl.hu

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. www.index.hu), melyek az emberek számára sokkal kényelmesebb azonosítók www.index.hu  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 127.0.0.1 localhost mail oxserver 152.66.87.200 samba.mik.bme.hu MIK 10.0.2.2 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 www.index.hu ; > DiG 9.5.1-P3 > www.index.hu ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62793 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 8 ;; QUESTION SECTION: ;www.index.hu. IN A ;; ANSWER SECTION: www.index.hu. 214 IN A 217.20.130.97 ;; AUTHORITY SECTION: hu. 86597 IN NS NS2.NIC.FR. hu. 86597 IN NS NS1.NIC.hu. hu. 86597 IN NS NS-COM.NIC.hu. hu. 86597 IN NS NS3.NIC.hu. hu. 86597 IN NS NS-SE.NIC.hu. hu. 86597 IN NS NS2.NIC.hu. hu. 86597 IN NS NS.NIC.hu. ;; ADDITIONAL SECTION: NS2.NIC.FR. 86256 IN A 192.93.0.4 NS1.NIC.hu. 863 IN A 193.239.149.3 NS-COM.NIC.hu. 863 IN A 194.0.1.12 NS3.NIC.hu. 863 IN A 195.70.35.250 NS-SE.NIC.hu. 863 IN A 77.72.229.251 NS2.NIC.hu. 863 IN A 193.6.16.1 NS.NIC.hu. 41206 IN A 193.239.148.62 NS2.NIC.FR. 86256 IN AAAA 2001:660:3005:1::1:2 ;; Query time: 5 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Mar 17 14:40:47 2010 ;; MSG SIZE rcvd: 326

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

8 DNS, DHCP és 3G UMTS8 Inverz lekérés – dig -x mail:/home/goodzi# dig -x 217.20.130.97 ; > DiG 9.5.1-P3 > -x 217.20.130.97 ;; 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: ;97.130.20.217.in-addr.arpa. IN PTR ;; ANSWER SECTION: 97.130.20.217.in-addr.arpa. 3600 IN PTR sportgeza.hu. ;; AUTHORITY SECTION: 130.20.217.in-addr.arpa. 3600 IN NS ns.index.hu. 130.20.217.in-addr.arpa. 3600 IN NS ns.inventra.hu. ;; ADDITIONAL SECTION: ns.index.hu. 5673 IN A 195.56.65.172 ns.inventra.hu. 5673 IN A 217.20.130.10 ;; Query time: 72 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Mar 17 14:42:33 2010 ;; 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 127.0.0.1 nameserver 152.66.248.12 nameserver 152.66.249.12 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 www.origo.hu mik:/home/goodzi# tshark -i eth1 -R dns 41.423935 192.168.101.243 -> 152.66.87.200 DNS Standard query A origo.hu 41.424100 152.66.87.200 -> 192.168.101.243 DNS Standard query response A 195.228.240.145 mik:/home/goodzi# nslookup ipv6.google.com mik:/home/goodzi# tshark -i eth1 -R dns 199.465871 152.66.87.211 -> 152.66.87.200 DNS Standard query AAAA ipv6.google.com 199.466071 152.66.87.200 -> 152.66.87.211 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 www.mik.bme.hu) 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 600 @ SOA ns.mik.bme.hu. dns-admin.mik.bme.hu. (2010031002 12H 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 exchangeserver.mik.bme.hu. @ A 152.66.87.211 ns A 152.66.87.200 mail A 152.66.87.200 gallery A 152.66.87.200 qoe A 152.66.87.200 opensbc A 152.66.87.200 calendar A 152.66.87.200 location A 152.66.87.221 samba A 152.66.87.200 wlan A 152.66.87.200 www A 152.66.87.211 home A 152.66.87.200 home AAAA 2001:738:2001:20a0:216:35ff:fe04:f76c test A 152.66.87.2 ibm1 A 152.66.87.4 ibm2 A 152.66.87.5 gep4 A 152.66.87.6 gep5 A 152.66.87.7 wlan1 A 152.66.87.8 wlan2 A 152.66.87.9

19 DNS, DHCP és 3G UMTS19 Példa IPv4-es névkeresési zónafájlra mik:/home/goodzi# cat /etc/bind/master/87.66.152.in-addr.arpa $TTL 86400 87.66.152.in-addr.arpa. IN SOA ns.mik.bme.hu. dns-admin.mik.bme.hu. ( 2010031001 ;Serial number 10800 ;Refresh 3600 ;Retry 604800 ;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/8.0.2.1.0.0.2.8.3.7.0.1.0.0.2.IP6.ARPA $TTL 600 8.0.2.1.0.0.2.8.3.7.0.1.0.0.2.IP6.ARPA. IN SOA ns.mik.bme.hu. dns- admin.mik.bme.hu. ( 2008071501 ;Serial number 10800 ;Refresh 3600 ;Retry 604800 ;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.5.3.6.1.2.0.0 IN PTR ns.mik.bme.hu. 1.c.0.8.1.7.e.f.f.f.d.5.b.0.2.0.9 IN PTR mnn1-eth.anemone.mik.bme.hu. 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR gw.anemone.mik.bme.hu. 8.8.3.0.a.2.e.f.f.f.f.4.4.1.2.0.2 IN PTR sun-gw.anemone.mik.bme.hu. 0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.0.8 IN PTR sun-ha.anemone.mik.bme.hu. 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8 IN PTR mr1-hoa.anemone.mik.bme.hu. 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1 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 255.255.255.255 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 2004-2006 Internet Systems Consortium. All rights reserved. For info, please visit http://www.isc.org/sw/dhcp/ 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 255.255.255.255 port 67 interval 4 DHCPOFFER from 152.66.87.200 DHCPREQUEST on eth2 to 255.255.255.255 port 67 DHCPACK from 152.66.87.200 bound to 152.66.87.196 -- renewal in 13100 seconds. mik:/home/goodzi#tshark -i eth2 40.478696 0.0.0.0 -> 255.255.255.255 DHCP DHCP Request - Transaction ID 0xf8600839 40.479098 152.66.87.200 -> 152.66.87.196 DHCP DHCP ACK - Transaction ID 0xf8600839

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= [, [, [, [, [, { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.hu/9/2220605/slides/slide_36.jpg", "name": "DNS, DHCP és 3G UMTS36 Modem vezérlése: AT parancsok  PIN –Command: AT+CPIN.", "description": "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 anemone@anemone-mnn2:~$ 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 = 921600 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, V30.0.013 firmware  GGSN (APN=test, IPv4) –Cisco 7206, IOS 12.4 c7200-adventerprisek9_mw-mz.124- 15.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, 2.6.23-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) root@anemone-mnn2:/home/anemone# wvdial nokia6 --> WvDial: Internet dialer version 1.56 --> 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 ~[7f]}#@!}!} } }2}#}$@#}!}$}%\}"}&} }*} } g}%~ --> Carrier detected. Starting PPP immediately. --> Starting pppd at Mon Nov 3 11:58:30 2008 --> Pid of pppd: 6045 --> Using interface ppp0 --> Authentication (PAP) started --> Authentication (PAP) successful

41 DNS, DHCP és 3G UMTS41 A hoston létrejött ppp interfész root@anemone-mnn2:/home/anemone# 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 anemone@anemone-mnn2:~$ tail -f 40 /var/log/syslog | grep pppd Nov 3 11:56:34 anemone-mnn2 pppd[6019]: pppd 2.4.4 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 68.707483 192.168.11.1 -> 192.168.100.5 GTP Create PDP context request 68.707542 192.168.100.5 -> 192.168.11.1 GTP Create PDP context response 70.312330 fe80::1234:1234:1234:1234 -> ff02::2 GTP Router solicitation 70.312816 fe80::3412:3412:1234:1234 -> ff02::1 GTP Router advertisement 70.566687 2001:738:2001:20a9:1234:1234:1234:1234 -> 2001:6b0:1:ea:202:a5ff:fecd:13a6 GTP 54017 > www [SYN] Seq=0 Len=0 MSS=1340 TSV=3983484125 TSER=0 WS=0 70.607518 2001:6b0:1:ea:202:a5ff:fecd:13a6 -> 2001:738:2001:20a9:1234:1234:1234:1234 GTP www > 54017 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1440 WS=1 TSV=103039371 TSER=3983484125 70.770572 2001:738:2001:20a9:1234:1234:1234:1234 -> 2001:6b0:1:ea:202:a5ff:fecd:13a6 GTP 54017 > www [ACK] Seq=1 Ack=1 Win=48240 Len=0 TSV=3983676125 TSER=103039371 70.830538 2001:738:2001:20a9:1234:1234:1234:1234 -> 2001:6b0:1:ea:202:a5ff:fecd:13a6 HTTP GET / HTTP/1.1 70.923134 2001:6b0:1:ea:202:a5ff:fecd:13a6 -> 2001:738:2001:20a9:1234:1234:1234:1234 GTP [TCP segment of a reassembled PDU] 70.923224 2001:6b0:1:ea:202:a5ff:fecd:13a6 -> 2001:738:2001:20a9:1234:1234:1234:1234 GTP [TCP segment of a reassembled PDU] 71.432700 2001:738:2001:20a9:1234:1234:1234:1234 -> 2001:6b0:1:ea:202:a5ff:fecd:13a6 GTP 54017 > www [ACK] Seq=370 Ack=2657 Win=47808 Len=0 TSV=3984334625 TSER=103039403 71.474050 2001:6b0:1:ea:202:a5ff:fecd:13a6 -> 2001:738:2001:20a9:1234:1234:1234:1234 GTP [TCP segment of a reassembled PDU] 71.474097 2001:6b0:1:ea:202:a5ff:fecd:13a6 -> 2001:738:2001:20a9:1234:1234:1234:1234 TCP [TCP segment of a reassembled PDU] 71.627840 2001:738:2001:20a9:1234:1234:1234:1234 -> 2001:6b0:1:ea:202:a5ff:fecd:13a6 GTP 46699 > www [SYN] Seq=0 Len=0 MSS=1340 TSV=3984539125 TSER=0 WS=0 71.668688 2001:6b0:1:ea:202:a5ff:fecd:13a6 -> 2001:738:2001:20a9:1234:1234:1234:1234 GTP www > 46699 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1440 WS=1 TSV=103039478 TSER=3984539125 71.890942 2001:738:2001:20a9:1234:1234:1234:1234 -> 2001:6b0:1:ea:202:a5ff:fecd:13a6 GTP 54017 > www [ACK] Seq=370 Ack=4703 Win=48418 Len=0 TSV=3984794125 TSER=103039458 71.907932 2001:738:2001:20a9:1234:1234:1234:1234 -> 2001:6b0:1:ea:202:a5ff:fecd:13a6 GTP 46699 > www [ACK] Seq=1 Ack=1 Win=48240 Len=0 TSV=3984812875 TSER=103039478 72.010624 2001:738:2001:20a9:1234:1234:1234:1234 -> 2001:6b0:1:ea:202:a5ff:fecd:13a6 HTTP GET /ipv6.org.css HTTP/1.1 72.052547 2001:6b0:1:ea:202:a5ff:fecd:13a6 -> 2001:738:2001:20a9:1234:1234:1234:1234 GTP [TCP segment of a reassembled PDU] 72.052681 2001:6b0:1:ea:202:a5ff:fecd:13a6 -> 2001:738:2001:20a9:1234:1234:1234:1234 HTTP HTTP/1.1 200 OK (text/css) 72.070341 2001: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 goodzi@mcl.hu


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