in113
Download
Skip this Video
Download Presentation
in113

Loading in 2 Seconds...

play fullscreen
1 / 48

in113 - PowerPoint PPT Presentation


  • 128 Views
  • Uploaded on

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)

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' in113' - aliza


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
in113

in113

kommunikasjon (del 2)

nettoppsett maskin
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)
ytelse
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
slide4
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
ytelsesproblem
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.)
brudd utilgjengelighet
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”
diagnose
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
slide8
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)
internett
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)
internett nettadresser
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
typer og notasjon
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)

slide12
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
type a adresserom
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

slide14
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

loopback
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)
slide16
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
adresseforvaltning
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)
slide18
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
slide19
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
slide20
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
slide21
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”
slide22
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”
slide23
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)
slide24
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
slide25
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
slide27
DHCP
  • sentralisert konfigurasjon i et domene
  • en DHCP-tjener deler ut nettparametre
    • nettadresse
    • default ruter (gateway)
    • nettmaske
    • annet
dhcp klient
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)
slide29
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
dhcp tjener
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.
slide31
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
slide32
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
slide33
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
slide34
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.)
slide35
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
slide36
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”
slide37
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
slide38
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
slide39
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
delegering
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)
slide41
svar
  • autoritet
    • authoritative: svar fra den som har ansvaret for domenet
    • non-authoritative: svar fra noen som ikke har direkte ansvar (caching-only, secondary)
videreformidling
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
slide43
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
eksempel
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

innhold i sonefil en sone per subnett
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 ...
sikkerhet
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)
slide47
logging
    • hendelseslogg (auditlogg)
    • i W2K: %systemroot%\system32\dns
  • overvåkning
slide48
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