7.1.1. En lille formaning

Fordi du nu bruger Linux, kommer du til at have fingrene lidt længere nede i netværksmaskineriet end med andre styresystemer. Derfor bliver du nødt til at lære lidt mere om, hvordan det hele er skruet sammen i stedet for bare at skrive en stribe magiske tal i nogle dialogbokse.

Du kan i mange tilfælde teste tingene på din egen maskine uden at være forbundet til et eksternt netværk og dermed undgå at genere andre. Vær frem for alt ikke bange for at lege med tingene - du kan kun blive klogere af det!

7.1.2. Netværksadresser

Et computernetværk består af et antal forbundne computere, i denne sammenhæng ofte kaldet værter (eng. "hosts"). Flere forbundne netværk kaldes et internet.

Alle computerne i et netværk bør i princippet kunne komme i kontakt med hinanden. For at kommunikationen mellem alle de forbundne computere skal fungere kræves det, at alle følger et fælles sæt tekniske spilleregler - såkaldte protokoller. TCP/IP udgør i Internettets tilfælde dette sæt spilleregler.

Der er som sagt brug for, at hver computer på netværket kan kontaktes af enhver anden computer på det samme netværk. Hver maskine har mindst en netværksadresse. Det er i sagens natur nødvendigt, at alle adresserne i et netværk er forskellige - ligesom postadresser i virkelighedens verden, ellers risikerer man, at oplysningerne bliver afleveret det forkerte sted.

En adresse i et TCP/IP-netværk er ret beset bare et tal. Computere har som bekendt ingen problemer med at arbejde med endog meget store tal, men vi stakkels mennesker kan godt have brug for at få tingene præsenteret på en lidt mere fordøjelig måde. De fleste af os ville formodentlig betakke os for at skulle skrive tallet 3333866547 i vores web-browser, når vi fik lyst til at surfe hen og tage et kig på http://www.linux.org.

Selv om det ved første øjekast kan virke ret uoverskueligt at arbejde med netværksadresserne som tal, kan det imidlertid godt betale sig at kigge lidt nærmere på systemet - for der er faktisk system i tingene.

Du har formodentlig hørt om, at computere i virkeligheden arbejder med tallene i binær form. Det betyder simpelthen, at den kun anvender cifrene 0 og 1 til at bygge tal op af. Vi er vant til at læse og skrive tallene med det decimale system, altså med de almindelige ti cifre 0-9. Det viser sig da også, at det meget hurtigt går helt galt med overskueligheden, når man skriver tallene i binær form. Det lange - men dog stadig nogenlunde læselige tal fra eksemplet ovenfor - ser sådan her ud som binært tal:

11000110101101101100010000110011

Tallet fylder hele 32 binære cifre eller bits og er stort set umuligt at overskue for det menneskelige øje. Det hjælper dog lidt, hvis man deler de 32 bits op i fire grupper med otte i hver:

11000110 10110110 11000100 00110011

En gruppe på otte bits kaldes en byte (på datalog-dansk: "en oktet") og kan bruges til at skrive tal mellem 0 og 255. Hvis du nu i stedet for at skrive, hvad alle de 32 bits tilsammen bliver til som decimaltal (3333866547), skriver hver af de fire bytes for sig:

11000110 = 198 decimal

10110110 = 182 decimal

11000100 = 196 decimal

00110011 = 51 decimal

og adskiller de fire bytes med punktummer, kommer det til at se sådan her ud:

198.182.196.51

Denne skrivemåde, som på engelsk kaldes "dotted quad notation", er langt den mest anvendte, når man har brug for at skrive netværksadresser som tal. Du har sikkert set systemet anvendt, hvis du på et tidspunkt har oprettet en forbindelse til en internetudbyder.

Når du skriver adressen på denne måde (og ved, hvad du skal kigge efter), fremgår det pludselig klart, at:

• det er et klasse C netværk

• det er en adresse på netværket 198.182.196.0

• det er vært nummer 51 på netværket

Og hvad betyder så det, og hvordan får man øje på det? Der findes tre almindeligt anvendte klasser af netværk, kaldet A, B og C.

• klasse A er netværk, hvis første byte er mellem 1 og 126. Første byte er netværksnummeret. Værtsnummeret udgøres af de tre sidste bytes

• klasse B er netværk, hvis første byte er fra 128 til 191. Netværksnummeret er de første to bytes. Værtsnummeret er de sidste to bytes

• klasse C er netværk, hvis første byte er mellem 192 og 223. Netværksnummeret er de første tre bytes. Værtsnummeret er den sidste byte

Tag et kig på de navneserveradresser (DNS), du har fået fra din internetudbyder. Du vil med stor sandsynlighed finde ud af, at det er adresser på et klasse C netværk.

7.1.3. Sammenkobling af flere netværk

Som nævnt ovenfor kan alle computere i et netværk umiddelbart komme i kontakt med hinanden. Som eksempel kan vi forestille os, at vi har et klasse C netværk 192.168.100.0 (vært nummer 0 henviser ikke til en computer - men til hele netværket) med tre computere med flg. adresser:

De er allesammen på samme netværk og kan derfor hver især umiddelbart komme i kontakt med hinanden. Men lad os nu forestille os, at der i samme bygning er et andet lille netværk 192.168.200.0, som også består af tre maskiner:

Nu viser det sig, at brugerne på de to netværk gerne vil i kontakt med hinanden via netværket. Man kunne så forestille sig, at man bare slog de to netværk sammen til et enkelt og delte nye netværksadresser ud, så alle kunne kontakte hinanden direkte. Det kunne også sagtens lade sig gøre, men vil måske komme på tværs af den måde, de to netværk administreres på.

Normalt gør man i stedet det, at man vælger en enkelt maskine, der tildeles adresser på begge netværk. I eksemplet ovenfor kunne det være computeren svend (192.168.200.1), der blev udstyret med et ekstra netværkskort og forbundet til netværket 192.168.100.0. Den kunne så passende blive tildelt værtsnummeret 4 på dette netværk og har så to adresser.

En maskine, der på den måde forbinder to netværk, kaldes en gateway. Computeren svend kan nu kontakte alle maskinerne på begge netværk direkte, og hvis vi fortæller de andre maskiner, at de skal lade henvendelser til det andet netværk gå igennem svend, kan alle i dette lille internet komme i kontakt med hinanden. Man fortæller altså, hvilken rute der skal bruges for at komme frem til en bestemt computer eller netværk, og det kaldes derfor rutning. Med det grafisk baserede program netcfg, der følger med Red Hat Linux, er det forholdsvis enkelt at konfigurere rutning.

Hvis vi nu forestiller os, at alfa (192.168.100.1) er forbundet videre ud til den store verden, begynder det at blive rigtig interessant. Knud (192.168.200.2) vil gerne i kontakt med 192.168.30.1. Det er ikke en adresse på knuds eget netværk, så den sender sagen videre til svend, der konstaterer, at den heller ikke kan komme i direkte kontakt med netværket 192.168.30.0. Den overlader problemet til alfa (192.168.100.1), der enten kan komme i direkte kontakt med 192.168.30.1 eller ved, hvem den kan give sorteper videre til.

7.1.4. DNS

For at gøre det muligt at bruge navne i stedet for tal, når du skal arbejde med netværksadresser, kræves der i sagens natur et verdensomspændende system, der kan oversætte fra navne til tal og omvendt. Dette system kaldes DNS (Domain Name Service) og vedligeholdes af utallige administratorer i forskellige organisationer verden over. Systemets opbygning sikrer, at de enkelte dele af den gigantiske navnedatabase kan ændres og udbygges efter behov.

Fig. 1

+(rod)
|
+ .com
|   |
|   + .yahoo
|   |    |
|   |   www
|   |
|   + .alta-vista
|   |     |
|   |    www
|   |
|   + .hacker
|         |
|        www
|
+ .dk
|   |
.   + .jubii
.   |    |
.   |   www
    |
    + .uni-c
       /  \
     www  danpost

DNS består af et hierarki af domæner. Fig. 1 viser en lille del af DNS. Ved hver '+' sidder en navneserver, som ved alt om det givne domæne, således ved [+ .uni-c] alt om domænet uni-c.dk.

Når en pc skal finde ud af IP-adressen på www.uni-c.dk, spørger den sin lokale navneserver (Følg med på fig 2). Denne navneserver ved, hvilke navneservere der bestyrer domænet [+(rod)]. Den spørger så navneserverne for (rod): "Hvad er IP-adressen på www.uni-c.dk?". (Rod)-serverne svarer: "Det ved jeg ikke, men jeg ved hvem, der bestyrer .dk". Den lokale navneserver spørger nu .dk-serverne: "Hvad er IP-adressen på www.uni-c.dk?". .dk-serverne svarer: "Det ved jeg ikke, men jeg ved, hvem der bestyrer uni-c.dk". Den lokale nameserver spørger nu .uni-c.dk-serverne: "Hvad er IP-adressen på www.uni-c.dk?". .uni-c.dk-serverne svarer: "Adressen på www.uni-c.dk er ...". Til slut svarer den lokale navneserver PCen: "Adressen på www.uni-c.dk er ...".

Fig. 2

[PC]       --> [Lokal NS]     www.uni-c.dk?
[Lokal NS] --> [(rod) NS]     www.uni-c.dk?
[Lokal NS] <-- [(rod) NS]     NS for .dk er .dk-NS
[Lokal NS] --> [.dk-NS]       www.uni-c.dk?
[Lokal NS] <-- [.dk-NS]       NS for .uni-c.dk er .uni-c.dk-NS
[Lokal NS] --> [.uni-c.dk-NS] www.uni-c.dk?
[Lokal NS] <-- [.uni-c.dk-NS] Adressen på www.uni-c.dk er ...
[PC]       <-- [Lokal NS]     Adressen på www.uni-c.dk er ...

Da ovenstående procedure kan tage lang tid, bliver alle resultater cachet af din lokale navneserver. Næste gang, den bliver spurgt om www.uni-c.dk, behøver den altså ikke at kontakte alle de andre navneservere igen, men kan give svaret omgående:

[PC]       --> [Lokal NS]     www.uni-c.dk?
[PC]       <-- [Lokal NS]     Adressen på www.uni-c.dk

Resultater bliver kun cachet et vist stykke tid, kaldet TTL (Time To Live). TTL er bestemt af domænets navneservere. Med andre ord: navneserverne for .uni-c.dk bestemmer, hvor længe din lokale navneserver må gemme informationen.

Som et konkret eksempel på et DNS opslag kan vi f.eks. bede om SSLUG's IP-adresse. Til dette bruger vi kommandoen nslookup.

[daisy@linus daisy]$  nslookup www.sslug.dk
Server:  danpost.uni-c.dk
Address:  129.142.6.64

Non-authoritative answer:
Name:    sslug.sslug.dk
Address:  192.38.71.98
Aliases:  www.sslug.dk

Vi kan i eksemplet se, at vi beder danpost.uni-c.dk med IP-adresse 129.142.6.64 om adressen på SSLUGs webserver. SSLUG har IP-adressen 192.38.71.98, og maskinen er åbenbart også kendt som sslug.sslug.dk. Svaret er "Non-authoritative", idet danpost-DNS serveren ikke er herre over sslug-domænet, men har fået informationen fra en anden navneserver.

DNS indeholder også andre informationer end IP-adresser. I DNS-sprog sætter man et punktum bag navnene for at angive, at disse er absolutte. Normalt kan man dog ignorere det sidste punktum.

DNS er baseret på filer. Disse filer indeholder zone-data. I mange tilfælde indeholder hver fil/zone ét domæne, i det følgende kan man derfor blot betragte "zone" som et synonym for "domæne".

Nameserverne for en zone listes ved:

[daisy@linus daisy]$  host -t ns sslug.dk
sslug.dk name server ns-soa.darenet.dk
sslug.dk name server ns.sslug.dk
sslug.dk name server ptah.dkuug.dk

For at finde mailserverne for et domæne skal man kende en af navneserverne for domænet. Derefter spørger man denne navneserver:

[daisy@linus daisy]$  host -t mx domæne.dk navneserver.for.domæne.dk

Den ansvarlige administrator for en zone findes i zonens SOA-record (Start Of Authority). SOA-recorden findes med:

[daisy@linus daisy]$  host -t soa domæne.dk navneserver.for.domæne.dk

Nogle navne er blot et alias for et andet navn: de har et kanonisk navn (eng: "canonical name"). Dette kan ses ved at spørge navneserveren for domænet om alt, hvad den ved om et givent navn:

[daisy@linus daisy]$  host -t any dette.navn.domæne.dk nameserver.for.domæne.dk

Til nogle domæner er knyttet tekst-information. Denne kan kaldes frem med:

[daisy@linus daisy]$  host -t txt navn.med.info.domæne.dk

Da DNS ikke er helt simpelt at sætte op korrekt, kan de ovenstående eksempler bruges, hvis du skal debugge din egen DNS. De kan også bruges til at finde ud af, hvorfor netværksfejl opstår eller til at finde en ansvarlig for et domæne, som man har modtaget reklame-emails fra.

I forbindelse med installationen af Red Hat Linux (eller senere) kan du vælge pakken "caching-nameserver". Pakken foretager en simpel opsætning af navneserveren bind. Fra starten kender den ikke selv svaret på navneopslag, men sender blot spørgsmålet videre og husker svaret (som beskrevet ovenfor). Den glemmer desværre alt, hvad den har lært, når maskinen lukkes ned, så du får mest glæde af en caching navneserver, hvis den kører på en maskine, der er i gang altid - f.eks. en server på et lille lokalnetværk. Den kan selvfølgelig sagtens bruges som navneserver for Windows pc'er på netværket.

Hvis du vil bruge Linux på en server i et mindre netværk, kan du have glæde af at lade den fungere som navneserver for et lokalt domæne. Opsætningen af dette er ikke det første Linux-eksperiment, du skal starte med, så eventuelle interesserede henvises til den detaljerede beskrivelse i DNS-HOWTO (under Red Hat, se /usr/doc/HOWTO/DNS-HOWTO).