In113
This presentation is the property of its rightful owner.
Sponsored Links
1 / 48

in113 PowerPoint PPT Presentation


  • 90 Views
  • Uploaded on
  • Presentation posted in: General

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)

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


In113

  • 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


In113

  • 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)


In113

  • 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


In113

  • 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)


In113

  • 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)


In113

  • 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


In113

  • 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


In113

  • 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


In113

  • 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”


In113

  • 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”


In113

  • 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)


In113

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


In113

  • 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


In113

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


In113

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)


In113

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


In113

  • 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


In113

  • 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


In113

  • 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


In113

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


In113

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


In113

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”


In113

  • 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


In113

  • 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


In113

  • 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)


In113

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


In113

  • 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)


In113

  • logging

    • hendelseslogg (auditlogg)

    • i W2K: %systemroot%\system32\dns

  • overvåkning


In113

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


  • Login