in115

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 • 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 • 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: 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 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: 7+24 • 27 – 2 = 126 nettadresser og • 224 –2 = ”veldig mange” vertsadresser • type B: 14+16 (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 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 nettadresser fra 1.0.0.0/8 til 126.0.0.0/8

14. vertsadresser innen et type A nett, 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 nett 13.0.0.0/8 13.0.0.1 til 13.255.255.254 13.0.0.0 brukes til nettets egenreferanse 13.255.255.255 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 127.0.0.1 • nett: 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 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 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 (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: 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. 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 www.himolde.no.

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

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

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