Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

In115 kommunikasjon (del 2). nettoppsett maskin adresse til DNS-tjener (den som oversetter mellom logiske navn og nettadresser) unike nettadresser for.

Liknende presentasjoner


Presentasjon om: "In115 kommunikasjon (del 2). nettoppsett maskin adresse til DNS-tjener (den som oversetter mellom logiske navn og nettadresser) unike nettadresser for."— Utskrift av presentasjonen:

1 in115 kommunikasjon (del 2)

2 nettoppsett maskin adresse til DNS-tjener (den som oversetter mellom logiske navn og nettadresser) unike nettadresser for hvert nett en er tilkoblet default ruter maskinnavn, vertsnavn (ofte samme som DNS- navn en er registrert med) DHCP-tjener (hvis en bruker dynamisk oppsett) W2K: ipconfig viser nettoppsett (sammendrag)

3 ytelse lavere responstid gir høyere arbeidstakt en melding som går fra sender til mottaker har en forsinkelse p.g.a. at den skal gjennom maskiner og linker – jo høyere forsinkelse, jo lavere arbeidstakt forsinkelsen er et resultat av –kødannelser (meldingen sitter i bufre underveis, kommer ikke videre) –behandlingstid (ruting, feilkontroll, sending over et fysisk medium) – kan ikke gjøres raskere enn maskinvaren tillater minimal forsinkelse: når optimal rute er valgt, og køer er fraværende – begrenses kun av maskinvaren

4 en datalink har –et sendebuffer der meldingene venter før de sendes ut på fysisk medium (ved kø) –en fysisk avstand signalene må traversere gir fast forsinkelse mellom faste maskiner variabel forsinkelse mellom mobile maskiner –et mottaksbuffer der meldingene inn til neste hopp venter før de kan bli behandlet

5 ytelsesproblem bitfeil i datalink p.g.a. støy/dårlig kobling mye kollisjoner p.g.a. for mange samtidige maskiner tilkoblet og i gang på en datalink uheldige ruter valgt av nettlaget (burde styre unna belastede datalinker) fulle (for små) buffer hos mottakerprosess DNS-oppslag går tregt (for logiske adr.)

6 brudd/utilgjengelighet fysiske linker som graves over datalinkkort (maskinvare) som feiler nettlaget klarer ikke å rute (finner ingen vei) –adminstrativ sperre (sikkerhetsårsak) i en ruter –brudd i datalink el. fysisk lag –overfylte datalinkbufre (ikke plass) transportlaget mister kontakt med den andre enden for en gitt kanal –nettlaget kan feile (se over) –den andre enden (maskinen) kan ha feilet DNS er ”nede”

7 diagnose ønsker å sjekke –konnektivitet (mellom maskiner) –ytelse (forsinkelse mellom maskiner) ping xyz –sender en ICMP Echo Request til maskin –mottaker: returnerer ICMP Echo Reply umiddelbart (gjøres i os) –sender: beregner rundetid og skriver ut

8 traceroute til maskin xyz –sender: injiserer meldinger med TTL=1, 2,... med mottakers nettadresse satt til xyz –nettlaget (IP) – i hver maskin langs ruten reduserer TTL med 1 før videresending dropper melding hvis TTL har blitt 0, samt sender ICMP feilmelding tilbake til sender –sender skriver ut rundetid og nettadresse til maskin som sendte feilmelding –sender gjentar prosedyren for å få flere målinger på samme TTL (til samme maskin)

9 Internett nettlaget i Internett utgjøres av IP (Internet Protocol) – her skjer rutingen IP benytter Internet Control Message Protocol (ICMP) for feilmeldinger ved feil der en melding ikke kan videresendes, vil IP be ICMP om å sende en feilmelding –til avsender (for absolutte brudd som nettlaget har gitt opp på) –til andre rutere (hvis det f.eks. finnes bedre ruter, eller andre feilmeldinger som er internt for nettlaget)

10 Internett nettadresser 32 bit lang, kalles IP-adresse hver melding består av avsender’s og mottakers 32-bits IP-adresse (viktig for både nett og mottaker) IP-adressen inneholder –nettadresse –vertsadresse

11 typer og notasjon bruker prefix for å indikere adressetype variabel inndeling av de 32 bit: 5 typer (nettadresse merket n, vertsadresse merket h) type A:0nnnnnn hhhhhhhh hhhhhhhh hhhhhhhh type B:10nnnnn nnnnnnnn hhhhhhhh hhhhhhhh type C:110nnnn nnnnnnnn nnnnnnnn hhhhhhhh type D:1110mmm mmmmmmmm mmmmmmmm mmmmmmmm type E:11110xx xxxxxxxx xxxxxxxx xxxxxxxx en bruker dotted decimal notation i ”dagligtale” (binær) (desimal)

12 reserverte adresser (ihht. IETF) –høyeste og laveste nettadresse er reservert (mister 2) til hhv. egenreferanse og kringkasting (til alle subnett) –høyeste og laveste vertsadresse er reservert (mister 2) til hhv. egenreferanse og kringkasting (til alle verter innen et nett) tilgjengelige adresser (hvis en følger IETF-std) –type A: – 2 = 126 nettadresser og 2 24 –2 = ”veldig mange” vertsadresser –type B: (mange nett, mange verter) –type C: 21+8 (veldig mange nett, 126 verter) –type D brukes til konferanseadresser (mange deler en adresse) –type E er til helt spesielle formål

13 type A adresserom nettadresser hhhhhhhh hhhhhhhh hhhhhhhh (res.) hhhhhhhh hhhhhhhh hhhhhhhh (laveste) hhhhhhhh hhhhhhhh hhhhhhhh (høyeste) hhhhhhhh hhhhhhhh hhhhhhhh (res.) altså er ikke-reserverte nettadresser fra /8 til /8

14 vertsadresser innen et type A nett, f.eks /8 (13 desimalt=1101 binært, type A fordi prefix=0) (res.) (laveste) (høyeste) (res.) altså er tilgjengelige vertsadresser innen nett / til brukes til nettets egenreferanse brukes til kringkasting innenfor nettet

15 loopback de fleste os definerer en intern datalink som peker tilbake til seg selv sender en til loopback-datalink, kommmer meldingen tilbake til en selv har nettadresse –nett: 127 ( ), prefix passer ikke med noen av adressetypene i IETF-IP –vertsadresse: 1 (første ledige)

16 en ruter –ser på prefix og avgjør derved type slik at han vet hvor mange bit som gjelder nettadresse og hvor mange som gjelder vertsadressen –sjekker så rutetabellen: leter etter nettadressen

17 adresseforvaltning gjentar: –ruting bruker nettadresse for å avgjøre meldingens videre ferd –en organisasjon må ha unike nettadresser for hvert nett den ønsker tilkoblet internettet (hvorfor? for at ruterne skal klare å rute meldingene inn til organisasjonen)

18 organisasjon må –kjøpe/leie nettadresser fra adresseforvalter disse representerer et adresserom –planlegg/tildele adresser for hver maskin disse må tas fra adresserommet en har anskaffet Høgskolen ”får” adresserommet fra UNINETT, som igjen får det fra NIC i USA –en forvalter delegerer således utdrag av sitt adresserom til underforvaltere

19 en organisasjon (som adresseforvalter) kan selv dele inn sitt rom etter behov; ”subnetting” ytterligere nett-oppdeling mulig ved å bruker en nettmaske for å si hvilke bit av de 32 som gjelder subnett – de resterende er for vertsadresser i dag har alle IP-adresser en nettmaske på n bit assosiert; subnettadressen er da: IP-adresse AND nettmaske –logisk AND utføres for hver bitposisjon (se eks. senere) bare 1 AND 1 = 1... de tre andre kombin. gir 0

20 eksempel: Høgskolens maskin ”skrei”: IP- adresse , netmask på 24 bit (IP-adr) AND (netmask) = (subnettadr.) –en sier: subnettadressen er , vertsadressen er 27. –ofte brukt notasjon: /24

21 eksempel 2: labmaskin lpc136.himolde.no har IP-adresse / (IP-adr) (netmask) (subnettadr.) –en sier: ”subnettadresse er ”, nettmasken er ” ” og vertsadresse er ”8”

22 eksempel 3: Studorg’s webserver som.himolde.no har IP-adresse / (IP-adr) (netmask) (subnettadr.) –en sier: ”subnettadresse er ”, nettmasken er ” ” og vertsadresse er ”50”

23 Høgskolen forvaltet ” ”-nettet (fikk det i 1997 av UNINETT) – dette har 8 bit til vertsadresser de kunne ha brukt hele subnettet til 126 verter, men delte det i to: brukte en bit til å skille mellom subnettene, og 7 bit til vertsadresser (eksempel 2 og 3 ligger i hvert subnett)

24 ARP hver maskin har en/flere datalinker, –datalinkadresse (MAC adresse) –nettadresse (nett, vert) når nettlaget vil sende en melding ut –ber datalinklag sende til en nettadresse –datalinklaget må finne ut hva som er datalinkadresse til denne nettadressen –melding sendes ut på fysisk medium med mottakers datalinkadresse –mottaker kan nå identifisere den utsendte melding som ”sin” – og derfor plukke den opp

25 anta at vi har to maskiner med nettadresser og datalinkadresser (A, A.dl) og (B.B.dl) –A får beskjed om å sende en melding til B – A har ikke B registrert i sin ARP-cache ARP.request (B) –fra A.dl, til ”alle” (kringkastings.dl): ”Hvem har nettadresse B?” –alle maskiner (inkludert B) fanger opp meldingen og sjekker ARP.reply –fra B.dl til A.dl: ”Jeg har nettadresse B” –samtidig oppdaterer B sin ARP-cache med (A, A.dl) –B fanger oppmeldingen og oppdaterer sin ARP-cache med (B, B.dl) – HERVED VET BEGGE OM HVERANDRE

26 programmet arp gir oversikt over ARP- cache på en maskin (std. i alle Windows og UNIX)

27 DHCP sentralisert konfigurasjon i et domene en DHCP-tjener deler ut nettparametre –nettadresse –default ruter (gateway) –nettmaske –annet

28 DHCP klient under boot: –spør tjener om å få leie nettparametre for en leietid –hvis ingen tjener svarer, forsøk tidligere brukte leieavtaler der leietiden ikke er utgått eller, forsøk autokonfigurering under kjøring –forsøker å fornye leieavtalen etter en viss tid har ofte en liste over flere tjenere den kan kontakte (for dynamisk binding)

29 bruke tidligere leieavtale (ved boot) –finn ut om maskin er på samme subnett en ”ping” mot default ruter vil avsløre dette –forsøk autokonfigurasjon hvis en mener en har flyttet til et annet nett bruker nettoppsett som passer til reserverte nett (f.eks. Microsoft har et B-nett som W2K vil forsøke: /16) prøver seg frem med nettadresser innenfor dette subnett, bruker ARP request for å finne ut om nettadressen er i bruk

30 DHCP tjener deler ut adresser fra et adresserom (scope) –for leie, må fornyes, vil frigjøres etter leietid passer for klientmaskiner (PC, arbeidsstasjon) –reservert, ingen fornying, vil ikke frigjøres passer for tjenermaskiner (filtjener, webtjener...) klientbegrensning (tilgangskontroll) –hvilken datalink DHCP-tjener skal betjene –hvilke klienter den skal betjene –hvilken datalinkadresse som skal få en reservert adr.

31 adresserom (pool, scope) –range: ikke-overlappende lister som kan deles ut –exclusion range: deler av range som ikke kan deles ut –kan være unicast (type A, B, C) – kalt normal scope i W2K multicast (type D) – kalt multicast scope i W2K leietid (ofte satt i ”antall dager”) –for stor: kan gå tom for adresser selv om nettadressene står ubrukt –for liten: mere administrativt arbeid (flere DHCP-fornyelser pr. dag) –bør settes til litt mer (1.5x) enn det som er behøvelig leietid

32 DHCP-tjener bør undersøke at andre maskiner ikke bruker en nettadresse, før den tildeles en klient –”ping” er en grei måte –i W2K angir ”conflict detection attempts” antall ”ping” som må stå ubesvart før en deler ut nettadressen – denner er ved installasjon satt til 0, men bør økes feil oppstår lett (os krasj, produksjons-stopp på andre måter) hvis flere maskiner bruker samme nettadresse

33 sikkerhet avhenger av at en får nettoppsett fra korrekt DHCP-tjener –klient kan bli besvart av en imitator og få et oppsett som kan redusere sikkerhetsnivået –i et W2K domene vil en klientmaskin snakke med sin domenekontroller før den eventuelt aksepterer nettoppsettet den har fått

34 overvåking av DHCP-tjener –gjennomsnitts-statistikk vedr. tilgjengelighet og bruk av tjenesten –hendelser som har inntruffet (audit) W2K: en logg for hver dag, ligger vanligvis i %SystemRoot%\system32 kan endre loggeparametre (hvor ofte, hvor store logger, m.m.)

35 DNS når en maskin har fått et nettoppsett er det viktig at dette registreres i DNS –slik at andre kan nå maskinen på sin nye nettadresse –krever en DNS-tjener som tilbyr dynamiske oppdateringer, fra f.eks. DHCP-tjener –DHCP-tjener underretter DNS-tjener, og DNS- tjener registrerer endringen logisk navn ”x.y.z” assosiert med nettadresse a.b.c.d

36 Navnerom (namespace) Et navn brukes for å referere til et objekt (maskin, tjeneste, program, bruker,...) –Entydig og korrekt, ingen tvil om hvilket objekt det dreier seg om Organiseringen kan være –Flat og ustrukturert: Vanskelig å sikre entydighet (krever sentral kontroll) –Hierarkisk: Kan delegere ansvaret, entydigheten gjelder innenfor et undernivå

37 Domain Name System (DNS) domener –top-level domain: nasjonale koder (.no,.se,...) de opprinnelige koder (.edu,.org,.mil,.com...) endel nye som er tilkommet de senere år (.priv,.as...) –organizational domain pitt.edu, un.org, navy.mil, microsoft.com tele.pitt.edu, sis.pitt.edu,

38 Fully Qualified Domain Name (FQDN) maskin (host, vert) – fully qualified domain name –violet.tele.pitt.edu. – her er ”tele” underdomene til ”pitt”, som er underdomene til ”edu” Rotdomenet er en NULL-streng. I et FQDN vises dette etter siste ”.” (”dot”), men er da ”usynlig”.

39 Partially Qualified Domain Name (PQDN) Hvis navnet ikke termineres med NULL- streng inneholder det ikke rotdomenet. –F.eks. spc201 som av DNS-klient ekspanderes med suffix til FQDN spc201.himolde.no (se DNS-oppsettet i Linux/W2K) –www er et annet mye PQDN som ekspanderes til FQDN

40 domene opprettes hvis en trenger det (og det gjør en hvis en vil ”være med” i internettet) en får det oftest fra –sin Internet Service Provider (ISP), –nasjonalt organ (www.norid.no) som har fått delegering fra IANA (Internet Assigned Numbers Authority)www.norid.no en velger selv navn innenfor det domenet en har ansvaret for – men, en er underlagt den navnepolitikk som gjelder

41 DNS tjenere kan anta følgende typer –primary eller secondary (disse utveksler lokal DNS- registre periodisk, s.k. soneoverføringer, zone transfers) har cache og egen DNS-database, må likevel spørre andre hvis hverken cache eller lokal database har svaret det må ofte være minst en secondary –forwarding-only (caching): har cache, men ikke lokalt DNS-database, må alltid spørre andre hvis svaret ikke ligger i cache en klient kan og bør føre opp flere DNS-tjenere –bedre pålitelighet, og (kanskje) lastfordeling

42 DNS-database (ligger både hos primær og sekundær) –gjelder for en eller flere domener –for hvert subnett må det lages to sonefiler forward lookup zone (FLZ): navn til nettadresse reverse lookup zone (RLZ): nettadresse til navn –har en subnett og må det lages en FLZ for hvert av disse, navnet på RLZ blir reversert, og tillagt et suffix: in-addr.arpa og in-addr.arpa

43 delegering sett opp en DNS-tjener på maskin (a.b.c.d) som skal ha ansvar for et nytt domene krsund hos primær: –velg et av ansvarsdomenene (dette blir foreldredomenet), td. nettskolen.no –opprett en link mellom underdomene krsund og maskin a.b.c.d som nå kjører DNS-tjener for domenet krsund.nettskolen.no a.b.c.d skal heretter besvare spørsmål vedrørende dette domenet (svarene blir riktignok cachet en viss tid andre steder)

44 svar autoritet –authoritative: svar fra den som har ansvaret for domenet –non-authoritative: svar fra noen som ikke har direkte ansvar (caching-only, secondary)

45 videreformidling tjener videresender spørsmål den ikke kan besvare setter opp en tjener som lokal forwarder – denne spør andre DNS-tjenere utenfor domenet andre (primær, sekundær, forwarding-only) bør spørre samme lokale forwarder –denne forwarder vil ha ”sentral” cache for domenet, da alle spørsmål har gått via denne –større sjanse for å finne svaret hos forwarder, gir lavere responstid og høyere arbeidstakt hos klientene

46 spørsmål sendes ofte fra forwarder direkte til en rottjener –disse finnes få steder i verden (noen i USA, en i England, en i Sverige,...) –rottjener gir en referral til en DNS-tjener som klienten (d.v.s. lokal forwarder) kan bruke ikke-rekursive tjenere –svarer med referral (til ”andre tjenere”) istedetfor å kontakte disse selv –gjelder mest for tjenere som er høyt oppe (rot-tjenerne) –tjenere ”ute i felten” bør gjøre arbeidet selv og lagre svaret (i cache), før de svarer klienten

47 eksempel lpc137 kjører Internet Explorer for en sluttbruker som ber om å se på lpc137 spør sin tjener (som er lpc132) lpc132 vet ikke svaret, sender spørsmålet til ulke.himolde.no ulke.himolde.no vet ikke svaret, sender spørsmålet til en rottjener (ikke-rekursiv) som returnerer referral til domenet pitt.edu (f.eks. namesrv.pitt.edu) ulke.himolde.no spør namesrv.pitt.edu, (rekursiv) som vet hvem som er domeneansvarlig for tele.pitt.edu, og deretter spør denne (f.eks. darwin.tele.pitt.edu) – denne svarer tilbake til namesrv.pitt.edu namesrv.pitt.edu gir svar til ulke.himolde.no, som svarer tilbake til lpc132, som gir svar til lpc137 ligger nå cachet hos darwin.tele.pitt.edu, namesrv.pitt.edu, ulke.himolde.no og lpc132

48 innhold i sonefil (en sone per nett) soneinfo –SOA (start of authority) – en beskrivelse per sone (navn, ansvarlig, varighet/levetid på data fra sonen) –NS (name server): ett/flere navn på maskiner som innehar ”navneautoritet” i sonen navneinfo –A (navn til nettadresse) –PTR (nettadresse til navn, reverse lookup) –CNAME (alias til et navn) –MX (mail exch.): navn på domenets posttjener –annet...

49 sikkerhet begrense aksess til primærtjeners soneinformasjon –tilgangsliste med liste over andre maskiner som får overføre hvilke soner begrense hvilke nettadresser en ”svarer på” (hvis maskinen har flere datalinker)

50 logging –hendelseslogg (auditlogg) –i W2K: %systemroot%\system32\dns overvåkning


Laste ned ppt "In115 kommunikasjon (del 2). nettoppsett maskin adresse til DNS-tjener (den som oversetter mellom logiske navn og nettadresser) unike nettadresser for."

Liknende presentasjoner


Annonser fra Google