1 / 48

in113

in113. kommunikasjon (del 2). nettoppsett maskin. adresse til DNS-tjener (den som oversetter mellom logiske navn og nettadresser) unike nettadresser for hvert subnett en er tilkoblet default ruter maskinnavn, vertsnavn (ofte samme som DNS-navn en er registrert med)

aliza
Download Presentation

in113

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. in113 kommunikasjon (del 2)

  2. nettoppsett maskin • adresse til DNS-tjener (den som oversetter mellom logiske navn og nettadresser) • unike nettadresser for hvert subnett 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 • sendergjentar 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 • subnettadresse • vertsadresse

  11. typer og notasjon • bruker prefix for å indikere adressetype • variabel inndeling av de 32 bit: 5 typer (subnettadresse merket n, vertsadresse merket h) type A: 0nnnnnn hhhhhhhh hhhhhhhh hhhhhhhh type B: 10nnnnnnnnnnnnn hhhhhhhh hhhhhhhh type C: 110nnnnnnnnnnnnnnnnnnnn hhhhhhhh type D: 1110mmm mmmmmmmm mmmmmmmm mmmmmmmm type E: 11110xx xxxxxxxx xxxxxxxx xxxxxxxx • en bruker dotted decimal notation i ”dagligtale” 10011110 00100110 01000100 00011001(binær) 158 . 38 . 68 . 27 (desimal)

  12. reserverte adresser (ihht. IETF) • høyeste og laveste subnettadresse 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 subnett) • tilgjengelige adresser (hvis en følger IETF-std) • type A: 7+24 • 27 – 2 = 126 subnettadresser og • 224 –2 = ”veldig mange” vertsadresser • type B: 14+16 (mange subnett, mange verter) • type C: 21+8 (veldig mange subnett, 126 verter) • type D brukes til konferanseadresser (mange deler en adresse) • type E er til helt spesielle formål

  13. type A adresserom • subnettadresser 00000000 hhhhhhhh hhhhhhhh hhhhhhhh (res.) 00000001 hhhhhhhh hhhhhhhh hhhhhhhh (laveste) ... 01111110 hhhhhhhh hhhhhhhh hhhhhhhh (høyeste) 01111111 hhhhhhhh hhhhhhhh hhhhhhhh (res.) altså er ikke-reserverte subnettadresser fra 1.0.0.0/8 til 126.0.0.0/8

  14. vertsadresser innen et type A subnett, f.eks. 13.0.0.0/8 (13 desimalt=1101 binært, type A fordi prefix=0) 00001101 00000000 00000000 00000000 (res.) 00001101 00000000 00000000 00000001 (laveste) ... 00001101 11111111 11111111 11111110 (høyeste) 00001101 11111111 11111111 11111111 (res.) • altså er tilgjengelige vertsadresser innen subnett 13.0.0.0/8 13.0.0.1 til 13.255.255.254 13.0.0.0 brukes til subnettets egenreferanse 13.255.255.255 brukes til kringkasting innenfor subnettet

  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 127.0.0.1 • subnett: 127 (11111111), 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 subnettadresse og hvor mange som gjelder vertsadressen • sjekker så rutetabellen: leter etter subnettadressen

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

  18. organisasjon må • kjøpe/leie subnettadresser 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 • ytterligere subnett-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 158.38.68.27, netmask på 24 bit 10011110 00100110 01000100 00011001(IP-adr) AND 11111111 11111111 11111111 00000000 (netmask) = 10011110 00100110 01000100 00000000 (subnettadr.) • en sier: subnettadressen er 158.38.68, vertsadressen er 27. • ofte brukt notasjon: 158.38.68.27/24

  21. eksempel 2: labmaskin lpc136.himolde.no har IP-adresse 158.38.74.136/25 10011110 00100110 01001010 10001000 (IP-adr) 11111111 11111111 11111111 10000000 (netmask) 10011110 00100110 01001010 10000000 (subnettadr.) • en sier: ”subnettadresse er 158.38.74.128”, nettmasken er ”255.255.255.128” og vertsadresse er ”8”

  22. eksempel 3: Studorg’s webserver som.himolde.no har IP-adresse 158.38.74.50/25 10011110 00100110 01001010 00110010 (IP-adr) 11111111 11111111 11111111 10000000 (netmask) 10011110 00100110 01001010 00000000 (subnettadr.) • en sier: ”subnettadresse er 158.38.74.0”, nettmasken er ”255.255.255.128” og vertsadresse er ”50”

  23. Høgskolen forvaltet ”158.38.74”-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 (subnett, 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 subnett • bruker nettoppsett som passer til reserverte subnett (f.eks. Microsoft har et B-nett som W2K vil forsøke: 169.254/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. navn • 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, • maskin (host, vert) – fully qualified domain name • violet.tele.pitt.edu – her er ”tele” underdomene til ”pitt”, som er underdomene til ”edu”

  37. 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) • en velger selv navn innenfor det domenet en har ansvaret for – men, en er underlagt den navnepolitikk som gjelder

  38. 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

  39. 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 158.38.82 og 158.38.83 må det lages en FLZ for hvert av disse, navnet på RLZ blir reversert, og tillagt et suffix: • 82.38.158.in-addr.arpa og 83.38.158.in-addr.arpa

  40. 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)

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

  42. 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

  43. 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

  44. eksempel • lpc137 kjører Internet Explorer for en sluttbruker som ber om å se på www.tele.pitt.edu • 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 www.tele.pitt.edu ligger nå cachet hos darwin.tele.pitt.edu, namesrv.pitt.edu, ulke.himolde.no og lpc132

  45. innhold i sonefil (en sone per subnett) • 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 ...

  46. 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)

  47. logging • hendelseslogg (auditlogg) • i W2K: %systemroot%\system32\dns • overvåkning

  48. WINS • eldre navnetjeneste i tidligere Windows domenebegrep (Windows 3.x, NT) – støttes av W2K for bakoverkompatibilitet • dekkes ikke i kurset (ikke pensum) • hele kap. 18 (s. 408-425) • s. 350-352 • s. 452-455

More Related