Et lite kurs i IP-nettverk-4

738 total views, 1 views today

I denne fjerde delen av mitt lille kurs i IP-teknologi skal vi sy sammen en del enkeltdeler fra tidligere moduler og se hvordan de til sammen skaper mekanismer for forsendelse av IP-pakker i et nettverk. Denne posten vil derfor bestå av en del temaer med til dels løs sammenheng, men målet er å fylle inn en del hull og sprekker og for få de foregående delene til å passe sammen.

Dynamic Host Configuration Protocol (DHCP)

Jeg har i tidligere moduler forklart hvordan IP-adresser og prefiks skal tildeles til et endepunkt: Adressen skal ligge innenfor det subnettet som er tildelt linken endepunktet er koplet til. Dette kan gjøres av maskinens bruker, og krever at brukeren har admininistratorprivilegier og kunnskap om hvordan dette skal foregå. Det er mange grunner til at vi ønsker at slik konfigurasjon skal foregå automatisk:

Alle datamaskinene kan da gis samme konfigurasjon ved utlevering
Man kan enkelt flytte maskinen mellom nettverk uten behov for manuell rekonfigurering
Vi unngår en del manuelle feil, f.eks. duplikate adresser på linken.
Det blir behov for færre IP-adresser, siden IP-adressene kan resirkuleres.

DHCP gir en bruker muligheten for å ta med seg maskinen på kafé eller bibliotek, skru den på og skrive inn WiFi-passordet og deretter kommunisere med Internet. DHCP gir biblioteket muligheten for å ha et stort antall brukere innom nettet sitt, men allikevel ikke ha flere IP-adresser i subnettet enn antallet samtidige brukere.

DHCP er altså en tjeneste i det lokale nettet som er laget slik at en maskin som ennå ikke har en IP-adresse, allikevel kan sende en forespørsel om å bli konfigurert. Opplysningene som den mottar fra DHCP-tjenesten er typisk disse opplysningene:

IP-adresse og prefikslengde
IP-adressen til «default gateway», som er en rad i rutingtabellen
IP-adressen til DNS-tjenesten
Varigheten av “leieperioden”, ved utløpet av denne maskinen fornye lånet av IP-adressen eller slutte å bruke den.

Hvordan foregår tildelingen av IP-adresser?

En DHCP-transaksjon foregår slik (noe forenklet):

Discover: Maskinen sender en kringkastingsmelding på linken med spørsmål om det finnes det DHCP-tjener der. Siden maskinen ikke har IP-adresse, og den heller ikke vet subnett-adressen til linken den er koplet til, brukes IP-adressen 0.0.0.0, og rammen som sendes påføres MAC-adressen ff:ff:ff:ff:ff:ff (kringkastingsadressen)
Offer: Vi forutsetter nå at det finnes én DHCP-tjener på linken, og den svarer med en IP-pakke med mottageradresse 0.0.0.0 og MAC-adressen til maskinen som spør. Nå har den fått kunnskap om hvor DHCP-tjeneren befinner seg, men har fortsatt ingen IP-adresse eller annen nødvendig konfigurasjon.
Request: Maskinen ber nå DHCP-tjeneren om konfigurasjonsdata, fortsatt med avsenderadresse 0.0.0.0 i IP-pakken som brukes. MAC-adressen i rammen er kringkastingsadressen.
Ack: DHCP-tjeneren sender konfigurasjonsopplysninger til maskinen, en IP-pakke med dens tildelte IP-adresse som mottageradresse, og dens MAC-adresse i linkrammen. Først fra dette tidspunktet vil maskinen bruke denne IP-adressen som avsenderadresse i påfølgende IP-pakker. Etter utløpet av leietiden må maskinen gjøre en ny Request for å fornye lånet, eller levere IP-pakken tilbake tidligere om maskinen skrus av.

DHCP er en svært populær tjeneste fordi den sparer både bruker og nettverkseier for mye ekstra arbeid: Brukeren kan flytte seg rundt og bruke maskinen på ulike steder uten behov for manuell konfigurasjon. Nettverkseieren (biblioteket) kan tilby bruk av nettet uten å holde rede på tildelte og ledige IP-adresser. Derfor ser vi DHCP i nesten alle nettverk, manuell konfigurasjon av brukermaskiner forekommer nesten aldri.

Faste IP-adresser

Siden maskinen kan tildeles ulike IP-adresser hver gang er DHCP ikke egnet der den adressen må være kjent for andre, f.eks. i en Web-tjener som andre maskiner skal anrope og kople seg til. Disse maskinene kan enten konfigureres manuelt, eller de kan få reserverte adresser fra DHCP-tjeneren. Slike reserverte adresser er konfigurert i DHCP-tjeneren og er knyttet til en MAC-adresse. Når en forespørsel om konfigurasjon kommer fra en maskin med denne MAC-adressen vil den reserverte IP-adressen bli tildelt, altså den samme IP-adressen hver gang.

Regler for videresending av IP-pakker

I et IP-nettverk blir IP-pakkene sendt fra avsenderemaskinen, via et antall rutere, og frem til mottagermaskinen. I hvert slikt “hopp” kommer pakken fra en link og sendes videre på en annen link, valgt av ruteren. Begge disse linkene har sine subnettadresser og tilknyttede enheter. Når IP-pakken sendes videre må ruteren ikke bare bestemme hvilken link den skal sendes til, men også til hvilken annen maskin/ruter på denne linken. IP-adressen til denne ruteren kaller vi Neste IP.

Ta gjerne en titt på Figur 5 på modul 2 hvor vi første gang så på problemet med veivalg. Denne gangen skal jeg forklare denne mekanismen mer nyansert og utfyllende.

Hver ruter har sin egen rutingtabell, hvor hver rad har disse kolonnene:

Subnettadressen knyttet til et veivalg. Mottakerens IP-adresse må høre til dette subnettet
Angivelse av hvilken port IP-pakken skal sendes ut på
IP-adressen til neste hopp, dvs. neste ruter på veien mot mottakeren

Figur 1 viser et enkelt nettverk med to rutere og noen tilknyttede linker, og rutingtabellene til begge ruterne. Tabellene er satt opp slik at alle maskiner tilknyttet de fire svitsjene kan sende IP-pakker frem og tilbake mellom seg.

Figur 1: Nettverk med to rutere og rutingtabeller

Rutingtabellen skal sette ruteren i stand til å avgjøre “på hvilken port og til hvilken adresse skal jeg sende en IP-pakke med mottageradresse x.y.z.w?”. I IP-protokollen spiller det ingen rolle hvem avsenderen er, eller hvilken port pakken kom inn på. Det er kun mottakeradressen som blir vurdert. Slik gjøres det:

Ruteren søker gjennom rutingtabellen rad for rad og finner dem som passer til mottagerens IP-adresse, dvs. at subnettadressen (første kolonne) inneholder mottageradresse i sitt adresserom. Av de radene som passer, velges den med lengste prefix i subnettadressen.
Dersom “neste hopp” -kolonnen i den valgte raden er tom betyr dette at mottakeren befinner seg på linken som er knyttet til ruterporten (angitt i kolonne 2). Da skal mottakerens IP-adresse brukes som “neste IP”-verdi.
Dersom “neste hopp”-kolonnen er en IP-adresse, bruk denne adressen som “neste IP”.
Bruk ARP-protokollen til å bestemme MAC-adressen til “neste IP” (som enten er mottakerens IP-adresse eller IP-adressen til neste ruter på veien).
Bruk denne MAC-adressen til å lage en link-ramme som IP-pakken legges i.
Send rammen på den porten som angis i kolonne 2 i rutingtabellen.

Oppgave til leseren:

Du bør nå kontrollere at rutingtabellene i Figur 1 fungerer slik de skal og at alle IP-pakker blir sendt i riktig retning uansett hvor de kommer fra og hvor mottageren er. Du skal også forstå hvorfor rutingtabellen for R1 ikke har separate rader for subnettene 18.10.9.0/24 og 18.10.8.0/24, men én rad for dem begge med betegnelsen 18.10.8.0/23. Rutingtabellen for R2 har en litt annen variant, ved å la 10.128.0.0/10 og 10.192.0.0/10 betegnes av subnettet 0.0.0.0/0. Forklar hvordan prinsippet “Longest Prefix First” kommer til anvendelse her.

Raden i rutingtabellen med subnettet 0.0.0.0/0 kalles default gateway, og er en av dataelementene som mottas i en DHCP-konfigurasjon. I mange tilfeller er dette alt maskinen trenger å vite. Forklar hvorfor.

Forslag til praktiske oppgaver

Studentene setter seg sammen i grupper på tre personer. Tre PC’er skal koples sammen med ethernet-kabler i en kjede. Maskinen i midten må være en Windows-maskin og trenger to ethernet-adaptre, de andre én hver. Vi kalles maskinene A, B og C (B er i midten):

Kabelen mellom A og B skal ha subnettadressen 10.10.1.0/24, og kabelen mellom B og C skal ha 10.99.5.128/26.

Adapteret på A og det tilkoplete adapteret på B skal ha adresser fra det første subnettet, og tilsvarende fra det andre subnettet for C og det tilkoplete adapteret på B.

Maskin B må settes i stand til å oppføre seg som en ruter, dvs. den skal videresende IP-pakker dersom de ikke er adressert til den selv. Dette gjøres med programmet REGEDIT (startes fra CMD-konsollet). Nøkkelen som skal endres er HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\IPEnableRouter, og verdien skal settes til 1. Deretter må maskinen restartes. Brannvegg og annen sikkerhetsprogramvare som hindrer fri flyt av nettverkstrafikk må skrus av.

– Diskutere nå i gruppen og bli enige om hvilken ruting-informasjon trengs i disse tre maskinene for at alle skal kunne sende IP-pakker til hverandre. Lag også en plan for hvordan dere vil kontrollere/teste at denne informasjonen er korrekt.

Sett IP-adresser

Sett nå IP-adresser på de fire adaptrene (to stk på B, én på de to andre). Sjekk at linken kan brukes, ved å “pinge” adressen i andre enden av kabelen.

Ved å sette IP-adresser vil Windows/MacOS også sette noe rutinginformasjon for det tilkoplede subnettet (altså kabelen). Det er derfor kun nødvendig å legge til rutinginformasjon for subnett som ikke er tilkoplet, altså kabelen på motsatt side av B.

Du får se maskinens rutingtabell med kommandoen

Windows: route print -4 10*
MacOS: netstat -rn -f inet

Rutingtabeller

Her vises den ekstra rutinginformasjon som må skrives inn i hver maskin. Bruk et CMD-konsoll med admin-rettigheter. Dere må kontrollere at disse dataene er riktige!

Betegnelsen (f.eks.) 10.40.5.0/28 10.40.1.6 omsettes til kommandoen

Windows: route add 10.40.5.0/28 10.40.1.6
MacOS: sudo route -n add -net 10.40.5.0/28 10.40.1.6

Maskin A:
10.99.5.0/26 10.10.1.x (x gis verdien til motstående adapter)

Maskin B:
Ingen ekstra rutinginfo er nødvendig

Maskin C:
10.10.1.0/24 10.99.5.x

Testing av oppsettet

“Ping”-kommandoen er din venn. Test alle linker (naboforbindelser), deretter forbindelsen mellom A og C. Bruk Wireshark for å lokalisere evt. feil. Uten vellykket “ping” er det ikke vits i å gå videre. Ved problemer, pass på at dere feilsøker systematisk og at dere analyserer observasjonene dere gjør.

Bruk nå de samme teknikkene som vi har brukt tidligere, f.eks. web-tjeneren og web-leseren for å vise at også web-trafikk funker.

Avslutningsvis: Med Wireshark, sjekk MAC-adressene som brukes for å sende fra A til B, og den samme IP-pakken som videresendes fra B til C. Merk av IP-adressene ikke er endret, men MAC-adressene er det.