
<!doctype linuxdoc system>

<!-- This is the Linux NET-3-HOWTO. It describes how to install and configure
	networking support for Linux. Any comments or feedback should
	be directed to the maintainer, rubini@linux.it
     Swedish translation by Tomas Carlsson, md5tc@mdstud.chalmers.se

     Detta är Linux NET-3-HOWTO. Den beskriver hur man konfigurerar och
       installerar nätverksstöd för Linux. Alla kommentarer eller 
       feedback bör skickas till rubini@linux.it
     Svensk översättning av Tomas Carlsson, md5tc@mdstud.chalmers.se
 -->

<article>

<title>Linux NET-3-HOWTO, Linux Nätverk.
<author>Terry Dawson, VK2KTJ, Alessandro Rubini (maintainer), <tt/alessandro.rubini@linux.it/. 

Svensk översättning av Tomas Carlsson, 
<url url="mailto:md5c@mdstud.chalmers.se" name="md5tc@mdstud.chalmers.se">
<date>v1.3, 1 April 1998. Svensk version 14 Juni 1998

<abstract>
Linux har ett kärnbaserat nätverksstöd som är skrivet nästan helt från noll. 
TCP/IP-prestandan i de senaste kärnorna gör Linux till ett värdigt alternativ
även till de bästa av dess motståndare. Detta dokument beskriver hur man 
installerar och konfigurerar nätverksmjukvara och tillhörande verktyg i Linux.
</abstract>

<!-- Table of contents -->

<toc>

<!-- Begin the document -->
<sect><heading>Ändringar från version 1.2
<p>
<verb>
Tillägg:
	Lade till information om transproxy
	Mindre fixar här och där

Rättningar/Uppdateringar:
	Ny maintainer

ToDo (ej ändrad, tyvärr):
	Lägg till traffic shaper
	Beskriv ny routing algoritm
	Lägg till kompileringsalternativ i kärnan för IPv6
	Beskriv /proc/sys/net/* .
	WanRouter enhet
</verb>

<sect><heading>Introduktion.
<p>
Den första NET-FAQen skrevs av Matt Welsh och Terry Dawson för att besvara
ofta ställda frågor om nätverk för Linux, detta i en tid före Linux 
Documentation Project hade startat. Den täckte de tidiga utvecklingsversionerna
av Linux nätverkskärna. NET-2-HOWTO tog över från NET-FAQ och var ett av de 
första LDP HOWTO dokumenten, det täckte version 2, och senare version 3, av 
Linuxkärnans nätverksmjukvara. Detta dokument tar i sin tur över från 
NET-2-HOWTO och behandlar endast version 3 av Linux nätverkskärna.
<p>
Tidigare versioner av detta dokument blev ganska stora beroende på den enorma
mängd material som det skulle täcka. För att minska storleken har ett antal
HOWTO's producerats som behandlar specifika nätverksämnen. Detta dokument
kommer, där det är relevant,  att tillstå med referenser till dessa och 
behandla de ämnen som inte täcks i andra dokument.
<p>
I April 1998 slutade Terry Dawson att uppräthålla NET-3, pga sin höga 
belastning. Jag är ny i jobbet, men skall göra mitt bästa för att lyckas.

<sect1><heading>Feedback
<p>
Jag uppskattar alltid feedback och särskilt värdefulla bidrag. Var vänlig att
skicka alla bidrag till
<url url="mailto:rubini@linux.it" name="email">.

<sect1><heading>Översättarens kommentarer
<p>
Först skall sägas att jag inte är någon expert på att översätta dokument från engelska
till svenska. När dokumentet dessutom är fullspäckat med tekniska termer så blir det 
inte lättare. Jag har försökt att översätta de flesta termerna ändå och i de fall som
jag inte gjort detta så bör det vara klart vad som menas. I de fall som översättningen
är tveksam så har jag även nämnt den engelska termen. För övrigt så finns det många 
meningar som antagligen inte skulle göra något vidare intryck på en svenskalärare, men
jag hoppas att det går att förstå ändå.

På ett par ställen har jag lagt till ett par meningar, jag har då markerat detta med `(SvÖ)'.

I andra sektioner av detta dokument (förutom denna) så betyder `jag' originalförfattaren.

--Tomas Carlsson, 
<url url="mailto:md5c@mdstud.chalmers.se" name="md5tc@mdstud.chalmers.se">

<sect><heading>Så här använder man detta  HOWTO dokument (NET-3-HOWTO-HOWTO ?).
<p>
Formatet på detta dokument skiljer sig från tidigare versioner. Vi har 
grupperat om sektionerna så att det finns upplysande material i början som 
man kan hoppa över om man inte är intresserad, sedan kommer generellt material
som man måste förstå innan man fortsätter till de teknikspecifika delarna i 
resten av dokumentet.
<p>
<descrip>
<tag>Läs de generella sektionerna</tag>Dessa sektioner används i alla, eller
nästan alla, tekniker som beskrivs senare och det är viktigt att man förstår
dessa.
<p>
<tag>Se över sitt nätverk</tag>Man bör veta hur ens nätverk är, eller kommer
att vara, designat och exakt vilken hårdvara och teknik som man kommer att 
implementera.
<p>
<tag>Läs det teknikspecifika sektionerna som är relaterade till de krav man har</tag>
När man vet vad man vill ha så kan man ta sig an varje komponent i tur och 
ordning. De här sektionerna behandlar endast detaljer för en specifik teknik.
<p>
<tag>Gör konfigurationsarbetet</tag>Man bör försöka att konfigurera sitt nätverk
och noggrant notera alla problem man stöter på.
<p>
<tag>Leta efter ytterligare hjälp om det behövs</tag>Om man stöter på problem 
som detta dokument inte kan hjälpa till med så läs sektionen om var man kan 
hitta hjälp eller var man kan rapportera buggar.
<p>
<tag>Ha kul!</tag>Nätverk är roligt, njut av det.
</descrip>

<sect><heading>Generell Information om Linux Nätverk.
<p>
<sect1><heading>En kort historia om utvecklingen av Linux Nätverkskärna.

<p>
Att utveckla en helt ny implementering av TCP/IP protokollstacken i kärnan som 
skulle prestera lika bra som existerande implementeringar var inte en lätt
uppgift. Valet att inte porta en av de existerande implementeringarna gjordes
vid en tid då det rådde osäkerhet beträffande om de existerande 
implementeringarna kunde bli besvärade av restriktiva copyrights på grund av
ett rättsfall av U.S.L och då det fanns mycket entusiasm för att göra det 
annorlunda och kanske till och med bättre än det redan hade gjorts.
<p>
Den första frivilliga att leda utvecklingen av nätverkskoden var
Ross Biro <tt/&lt;biro@yggdrasil.com>/. Ross gjorde en enkel och inkomplett 
men mestadels användbar implementering, som utökades med en Ethernet-drivrutin
för ett WD-8003 nätverkskort. Detta räckte för att få många personer att testa
och experimentera med koden och några klarade till och med av att ansluta maskiner
till Internet med denna implementering. Trycket på nätverksstöd 
ökade i Linuxvärlden och till slut var kostnaden för orättvist tryck på Ross
större än vad han fick ut av projektet så han lade av som huvudutvecklare.
Ross ansträngningar för att få igång projektet och ta ansvar för att verkligen
producera någonting användbart under sådana kontroversiella omständigheter var
vad som drev på allt framtida arbete och var därför en viktig del av framgången
med den nuvarande produkten.
<p>
Orest Zborowski <tt/&lt;obz@Kodak.COM>/ producerade det första  
programmeringsgränssnittet för BSD sockets till Linuxkärnan. Detta var ett stort steg framåt
eftersom det tillät många av de existerande nätverksapplikationerna att bli 
portade till Linux utan omfattande modifiering.
<p>
Någon gång vid denna tid utvecklade 
Laurence Culhane <tt/&lt;loz@holmes.demon.co.uk>/ de första drivrutinerna för
Linux som stödde SLIP-protokollet. Dessa gjorde det möjligt för många människor
som inte hade tillgång till Ethernet-nätverk att experimentera med den nya 
nätverksmjukvaran. Återigen så tog några personer denna drivrutin och lyckades ansluta
sig till Internet. Detta gav många en smak av de möjligheter som kunde bli
realiserade om Linux hade fullt nätverksstöd och ökade antalet användare av
den existerande nätverksmjukvaran.
<p>
En av de som aktivt hade arbetat med uppgiften att implementera nätverksstöd
var Fred van Kempen <tt/&lt;waltje@uwalt.nl.mugnet.org>/. Efter en tid av 
osäkerhet efter Ross avhopp från positionen som huvudutvecklare så erbjöd Fred sin 
tid och insats. Fred hade några ambitiösa planer för vart han ville leda Linux
nätverksmjukvara och han började framskrida i den riktningen. Fred producerade
en serie nätverkskod som kallades 'NET-2' kärnkod ('NET'-koden var Ross) som
många kunde använda ganska användbart. Fred's NET-2 kod användes av ett hyfsat
stort antal entusiaster, som ökade allt eftersom ryktet spred sig att koden 
fungerade. Vid denna tid var nätverksmjukvaran fortfarande ett stort antal
patchar till standardversionen av kärnan och var inte inkluderad i den normala
versionen. NET-FAQ och NET-2-HOWTO beskrev då den ganska komplicerade rutinen
för att få allt att fungera. Freds mål var att utveckla nyheter till standard
implementeringen, och detta tog tid. Linuxvärlden väntade otåligt på något som
fungerade pålitligt och, precis som med Ross, så ökade trycket på Fred som 
huvudutvecklare.
<p>
Alan Cox <tt/&lt;iialan@www.uk.linux.org>/ föreslog en lösning till problemet.
Han föreslog att han skulle ta Freds NET-2 kod och debugga den, göra den 
pålitlig och stabil så att den skulle tillfredsställa de otåliga användarna och
samtidigt lätta på trycket på Fred så att han kunde fortsätta sitt jobb. Alan 
började med detta, med viss framgång och hans första version av nätverkskod 
kallades 'NET-2D(ebugged)'. Koden fungerade pålitligt i många typiska 
konfigurationer och användarna var nöjda. Alan hade egna ideer och färdigheter
att bidra med till projektet vilket ledde till många diskussioner relaterade till riktningen på NET-2 koden. Det skapades två olika läger i Linuxvärlden, en 
med filosofin 'få det att fungera, sen gör det bättre' och den andra 'gör det 
bättre först'. Linus stödde Alans utveckling och inkluderade
Alans kod i standarddistributionen av kärnkoden. Detta placerade Fred i en svår
situation. Fortsatt utveckling skulle sakna användning och testning av den
stora användarskaran och detta skulle betyda att det skulle bli svårt och gå
långsamt. Fred fortsatte att arbeta en kort tid men lade till slut av och Alan
blev den nya ledaren för Linux nätverksutveckling.
<p>
Snart avslöjade Donald Becker <tt>&lt;becker@cesdis.gsfc.nasa.gov></tt> sina 
talanger i lågnivåaspekterna för nätverk och producerade en enorm mängd av
Ethernet-drivrutiner, nästan alla de som finns i nuvarande kärnor är 
utvecklade av Donald. Det finns andra som har givit betydelsefulla bidrag, men 
Donalds arbete är produktivt och kräver speciell uppmärksamhet.
<p>
Alan fortsatte att förfina NET-2-Debugged koden en tid samtidigt som han 
arbetade på det som fanns på 'TODO'-listan. Då Linux <tt/1.3.*/ kärnkoden
hade växt till sig hade nätverkskoden gått över till NET-3 versionen som 
nuvarande versioner grundar sig på. Alan arbetade på många olika aspekter på 
nätverkskoden och med hjälp av en mängd talangfulla personer från Linuxvärlden
växte koden i alla möjliga riktningar. Alan producerade dynamiska 
nätverksenheter och de första standard AX.25 och IPX implementeringarna. Alan
har fortsatt att meka med koden, långsamt strukturerat om och förbättrat den 
till det tillstånd den är i idag.
<p>
PPP-stöd lades till av Michael Callahan <tt/&lt;callahan@maths.ox.ac.uk>/ och
Al Longyear <tt/&lt;longyear@netcom.com>/, detta var också kritiskt för att 
öka antalet personer som använde Linux för nätverk.
<p>
Jonathon Naylor <tt/&lt;jsn@cs.nott.ac.uk>/ har bidragit med att göra betydande
förbättringar av Alans AX.25 kod, lagt till stöd för NetRom och Rose protokoll.
AX.25/NetRom/Rose stödet i sig själv är ganska betydelsefullt, för att inget
annat operativsystem har inbyggt stöd för dessa protokoll förutom Linux.
<p>
Det finns naturligtvis hundratals andra personer som har givit betydelsefulla
bidrag till utvecklingen av Linux nätverksmjukvara. Några av dessa kommer att
nämnas senare i de teknikspecifika sektionerna, andra har bidragit med moduler,
 drivrutiner, buggfixar, förslag, testrapporter och moraliskt stöd. I alla 
dessa fall kan var och en säga att den varit del av utvecklingen. Linux 
nätverkskod är ett utmärkt exempel på de resultat som kan uppnås med Linux 
anarkistiska utvecklingsstil, om man inte är förvånad över detta än, så blir 
man det snart för utvecklingen har inte slutat än.


<sect1><heading>Var man hittar ytterligare information om Linux nätverk.
<p>
Det finns ett antal ställen där man kan hitta bra information om 
Linux nätverk.
<p>
Alan Cox, den nuvarande handhavaren av Linux nätrverkskod har en 
World Wide Web sida som innehåller höjdpunkter från utvecklingen av nätverkskoden:
<url url="http://www.uk.linux.org/NetNews.html"
	name="www.uk.linux.org">.
<p>
Ett annat bra ställe är en bok, <tt/Network Administrators Guide/, skriven av 
Olaf Kirch. Den tillhör 
<url url="http://sunsite.unc.edu/LDP/" name="Linux Documentatation Project">
och man kan läsa den online på 
<url url="http://sunsite.unc.edu/LDP/LDP/nag/nag.html"
	name="Network Administrators Guide HTML version">
eller hämta den i olika format via ftp från 
<url url="ftp://sunsite.unc.edu/pub/Linux/docs/LDP/network-guide/"
	name="sunsite.unc.edu LDP ftp archive">. Olafs bok är ganska omfattande och
ger en bra översikt av högnivåkonfiguration av nätverket i Linux.
<p>
Det finns en nyhetsgrupp i Linux nyhetshierarkin som är avsedd för nätverk och
dess relaterade ämnen, den är: 
<url url="news:comp.os.linux.networking" name="comp.os.linux.networking">
<p>
Det finns en mailing-lista som man kan prenumerera på där man kan fråga frågor 
relaterade till Linux nätverk. För att prenumerera skall man skicka ett e-post
meddelande:
<tscreen><verb>
To: majordomo@vger.rutgers.edu
Subject: anything at all
Message:

subscribe linux-net
</verb></tscreen>
<p>
På de olika IRC nätverken finns det ofta <tt/#linux/ kanaler på vilka personer
kan svara på frågor om Linux nätverk.
<p>
Kom ihåg att när man rapporterar ett problem så skall man inkludera så mycket relevanta 
detaljer om problemet som man kan. Speciellt så bör man specificera vilka versioner
av mjukvara man använder, särskilt kärnversionen, versionen på verktyg såsom
<em/pppd/ eller <em/dip/ och den exakta karaktären av problemet som man upplever.
Detta betyder bland annat att notera den exakta syntaxen på felmeddelanden som 
man får och alla kommandon som man använder.

<sect1><heading>Var man hittar generell nätverksinformation (icke Linux-specifik)
<p>
Om man vill ha grundläggande information om TCP/IP nätverk, så kan jag 
rekommendera följande dokument:
 
<descrip>
<tag>tcp/ip introduction
</tag>
detta dokument finns både som
<url url="ftp://athos.rutgers.edu/runet/tcp-ip-intro.doc"
	name="text version"> och som
<url url="ftp://athos.rutgers.edu/runet/tcp-ip-intro.ps"
	name="postscript version">.
<p><tag>tcp/ip administration
</tag>
detta dokument finns både som
<url url="ftp://athos.rutgers.edu/runet/tcp-ip-admin.doc"
	name="text version"> och som 
<url url="ftp://athos.rutgers.edu/runet/tcp-ip-admin.ps"
	name="postscript version">.
</descrip>

Om man vill ha mer detaljerad information om TCP/IP nätverk så kan jag rekommendera:

<tscreen><verb>
"Internetworking with TCP/IP"
av Douglas E. Comer

ISBN 0-13-474321-0
Prentice Hall publications.
</verb></tscreen>

<p>
Man kan också prova nyhetsgruppen
<url url="news:comp.protocols.tcp-ip" name="comp.protocols.tcp-ip">.
<p>
En viktig informationskälla när man är ute efter teknisk information relaterad till
Internet och TCP/IP protokollen är RFCs. RFC är en förkortning av 'Request For 
Comment' och är det standardiserade sättet att lämna ut och dokumentera 
protokollstandarder för Internet. Det finns många ställen att hämta RFCs från. 
Många av dessa är ftp-sajter och andra tillhandahåller World Wide Web sidor med
sökmotorer där man kan kan söka i RFC databasen med nyckelord.
<p>
En möjlig källa för RFCs är:
<url url="http://pubweb.nexor.co.uk/public/rfc/index/rfc.html"
	name="Nexor RFC database">.

<sect><heading>Generell Information om Nätverkskonfiguration
<p>
Följande delsektioner innehåller information som man måste förstå för att kunna
konfigurera sitt nätverk. Det är fundamentala principer som gäller oavsett
karaktären på nätverket som man skall använda.

<sect1><heading>Vad behöver man för att börja?
<p>
Innan man börjar bygga eller konfigurera sitt nätverk behöver man några saker.
De viktigaste är:

<sect2><heading>Källkoden för kärnan.
<p>
Eftersom kärnan som man kör nu inte nödvändigtvis ännu har stöd för de nätverk och
nätverkskort som man vill använda så behöver man antagligen källkoden för kärnan
så att man kan kompilera om den med lämpliga tillägg.
<p>
Man kan alltid hämta den senaste källkoden från:
<url url="ftp://ftp.funet.fi/pub/Linux/PEOPLE/Linus/v2.0" name="ftp.funet.fi">.
<p>
Vanligtvis så packas källkoden upp till katalogen <tt>/usr/src/linux</tt>. För
mer information om hur man lägger till patchar och hur man kompilerar kärnan så
bör man läsa <url url="Kernel-HOWTO.html" name="Kernel-HOWTO">. För information om
hur man konfigurerar kärnans moduler så bör man läsa 
<url url="Module-HOWTO.html" name="Module-HOWTO">.
<p>
Om inte annat sägs specifikt så rekommenderar jag att man håller dig till standardversionerna av kärnan (de med jämna nummer som andra siffra i versionsnummret).
Versioner under utveckling (de med udda andra siffra) kan ha strukturella eller 
andra ändringar som kan skapa problem med annan mjukvara i sitt system. Om man är
osäker på om man klarar av att lösa den typen av problem, så skall man inte använda de 
versionerna.

<sect2><heading>Nätverksverktyg (Network Tools).
<p>
Nätverksverktygen är de program som man använder för att konfigurera nätverksenheter
i Linux. Med dessa verktyg kan man tilldela adresser till enheter och konfigurera 
routes till exempel.
<p>
De flesta moderna Linuxdistributioner är utrustade med nätverksverktyg, så om 
man har installerat från en distribution och ännu inte installerat 
nätverksverktygen så bör man göra detta nu.
<p>
Om man inte har installerat från en distribution så behöver man källkoden för att
kompilera verktygen själv. Detta är inte svårt.
<p>
Nätverksverktygen handhas av Bernd Eckenfels och finns på:<url url="ftp://ftp.inka.de/pub/comp/Linux/networking/NetTools/"
	name="ftp.inka.de"> och är speglade på:
<url url="ftp://ftp.uk.linux.org/pub/linux/Networking/base/"
	name="ftp.uk.linux.org">.
<p>
Man skall vara noga med att välja en version som passar den kärna som man har tänkt att 
använda och med att följa instruktionerna i paketet för att installera.
<p>
För att installera den senaste versionen då detta skrivs så behöver man göra 
följande:
<verb>
#
# cd /usr/src
# tar xvfz net-tools-1.33.tar.gz
# cd net-tools-1.33
# make config
# make
# make install
#
</verb>

Dessutom, om man tänker konfigurera en brandvägg eller använda IP-maskering, 
så behöver man <em>ipfwadm</em> kommandot. Den senaste versionen finns
på: <url url="ftp:/ftp.xos.nl/pub/linux/ipfwadm" name="ftp.xos.nl">. Återigen så 
finns det ett antal versioner tillgängliga. Se till att välja den som passar bäst 
till din kärna.
<p>
För att installera den senaste versionen då detta skrivs så behöver man göra 
följande:
<verb>
#
# cd /usr/src
# tar xvfz ipfwadm-2.3.0.tar.gz
# cd ipfwadm-2.3.0
# make
# make install
#
</verb>

<sect2><heading>Applikationsprogram för nätverket
<p>
Applikationsprogrammen är program såsom <em>telnet</em> och <em>ftp</em> och deras
respektive serverprogram. David Holland <tt/&lt;dholland@hcs.harvard.edu>/ handhar
en distribution av de vanligaste av dessa. man kan hämta dem från:
<url url="ftp://ftp.uk.linux.org/pub/linux/Networking/base"
	name="ftp.uk.linux.org">.
<p>
För att installera den senaste versionen då detta skrivs så behöver man göra 
följande:
<verb>
#
# cd /usr/src
# tar xvfz /pub/net/NetKit-B-0.08.tar.gz
# cd NetKit-B-0.08
# more README
# vi MCONFIG
# make
# make install
#
</verb>

<sect2><heading>Adresser.
<p>
Internet Protokoll Adresser är uppbyggda av fyra bytes. Konventionen är att skriva 
adresser i vad som kallas 'punkterad decimal notation'. I denna formen är varje 
byte konverterad till ett decimalt tal (0-255), utan nollor i början, och skrivs 
med varje byte separerad med ett '.' tecken. Varje (nätverks-)gränssnitt hos en
värddator eller router har en IP-adress. I vissa fall är det tillåtet att ha samma
IP-adress på alla gränssnitt på en och samma maskin, men vanligtvis har varje
gränssnitt sin egen adress.
<p>
Internet Protokoll nätverk är kontinuerliga sekvenser av IP-adresser. Alla 
adresser inom ett nätverk har ett antal siffror i adressen gemensamma. Den del av
adressen som är gemensam för alla adresser inom ett nätverk kallas 'nätverksdelen' 
('network portion') av adressen. Antalet bitar som är delade av alla adresser inom
ett nätverk kallas 'nätmasken' ('netmask') och det är nätmaskens uppgift att 
avgöra vilka adresser som hör till nätverket som nätmasken tillhör och vilka som 
inte gör det. Beakta följande exempel:

<verb>
-----------------  ---------------
Host Address       192.168.110.23
Network Mask       255.255.255.0
Network Portion    192.168.110.
Host portion                  .23
-----------------  ---------------
Network Address    192.168.110.0
Broadcast Address  192.168.110.255
-----------------  ---------------
</verb>

Alla adresser som blir 'bitvis andade' med sin nätmask kommer att avslöja adressen
till nätverket som den tillhör. Nätverksadressen är därför den lägst numrerade 
adressen i den rad av adresser som finns i nätverket och har värddatordelen av
adressen satt till nollor.
<p>
Broadcastadressen är en speciell adress som varje värddator på nätverket lyssnar
till utöver sin egen unika adress. Till denna adress sänds datagram om det är tänkt
att alla maskiner på nätverket skall ta emot dem. Vissa typer av data såsom route 
information och varningsmeddelanden sänds till broadcastadressen så att alla 
maskiner på nätverket kan ta emot dem samtidigt. Det finns två vanligt förekommande
standarder för vad broadcastadressen skall vara. Den mest använda är att den 
högsta möjliga adressen i nätverket används som broadcastadress. I exemplet ovan 
skulle detta vara <tt>192.168.110.255</tt>. Av någon anledning använder vissa 
sajter nätverksadressen som broadcastadress. I praktiken spelar det ingen större
roll vilket man använder men man måste vara säker på att alla maskiner på nätverket
använder samma broadcastadress.
<p>
Av administrativa skäl någon gång tidigt i utvecklingen av IP-protokollet delades
adresserna in i några slumpvisa grupper av nätverk och dessa nätverk grupperades
i vad som kallas för klasser. Dessa klasser tillhandahåller ett antal nätverk av
standardstorlekar som kan bli allokerade. De allokerade är:

<verb>
----------------------------------------------------------
| Network | Netmask       | Network Addresses            |
| Class   |               |                              |
----------------------------------------------------------
|    A    | 255.0.0.0     | 0.0.0.0    - 127.255.255.255 |
|    B    | 255.255.0.0   | 128.0.0.0  - 191.255.255.255 |
|    C    | 255.255.255.0 | 192.0.0.0  - 223.255.255.255 |
|Multicast| 240.0.0.0     | 224.0.0.0  - 239.255.255.255 |
----------------------------------------------------------
</verb>

<p>
Vilka adresser som man skall använda beror på vad det är exakt man skall göra. Man
kan behöva använda en kombination av följande för att få de adresser man behöver:
<descrip>
<p><tag>Installera en Linuxmaskin på ett existerande IP-nätverk</tag>Om man vill 
installera en Linuxmaskin på ett existerande IP-nätverk så bör man kontakta den som
administrerar nätverket och fråga efter följande:
<itemize>
<item>IP-adress för värddatorn (Host IP Address)
<item>IP nätverksadress (IP Network Address)
<item>IP broadcastadress
<item>IP nätmask (IP Netmask)
<item>Routeradress
<item>DNS adress (Domain Name Server Address)
</itemize>
Man skall sedan konfigurera sin Linux nätverksenhet med de uppgifterna. man kan inte
hitta på dem och förvänta sig att det skall fungera.

<p><tag>Bygga ett helt nytt nätverk som aldrig skall anslutas till Internet</tag>
Om man bygger ett privat nätverk som man aldrig tänker ansluta till Internet så kan 
man välja vilka adresser man vill. Men, för säkerhets och konsistens skull så har 
vissa IP-adresser blivit reserverade speciellt för detta ändamål. De är 
specificerade i RFC1597 och är följande:

<verb>
-----------------------------------------------------------
|         RESERVED PRIVATE NETWORK ALLOCATIONS            |
-----------------------------------------------------------
| Network | Netmask       | Network Addresses             |
| Class   |               |                               |
-----------------------------------------------------------
|    A    | 255.0.0.0     | 10.0.0.0    - 10.255.255.255  |
|    B    | 255.255.0.0   | 172.16.0.0  - 172.31.255.255  |
|    C    | 255.255.255.0 | 192.168.0.0 - 192.168.255.255 |
-----------------------------------------------------------
</verb>

Man bör först bestämma hur stort nätverket skall vara och sedan välja så många
adresser som man behöver.
</descrip>

<sect1><heading>Var skall man skriva konfigurationskommandona?
<p>
Det finns några olika metoder för Linux systemstartprocedurer. Efter det att kärnan
bootar, så exekverar den alltid ett program som heter <em/init/. <em/init/ 
programmet läser sedan en konfigurationsfil som heter <tt>/etc/inittab</tt> och
inleder uppstartsprocessen. Det finns några olika versioner av <em/init/ och det 
är denna variationen som är den största orsaken till skillnad mellan distributioner
eller maskiner.
<p>
Vanligtvis så innehåller <tt>/etc/inittab</tt> filen en rad som ser ut någonting 
som liknar:

<tscreen><verb>
si::sysinit:/etc/init.d/boot
</verb></tscreen>

Denna raden specificerar namnet på det shell-script som verkligen utför uppstarten. 
Denna fil skulle kunna jämföras med filen <tt/AUTOEXEC.BAT/ i MS-DOS.
<p>
Vanligtvis finns det andra script som anropas av boot-scriptet och ofta så 
konfigureras nätverket i något av dessa.
<p>
Följande tabell kan användas som guide för ett system:

<verb>
-------------------------------------------------------------------------------
Distrib. |Interface Config/Routing                    |Server Initialisation
-------------------------------------------------------------------------------
Debian   |/etc/init.d/network                         |/etc/init.d/netbase     
         |                                            |/etc/init.d/netstd_init
         |                                            |/etc/init.d/netstd_nfs
         |                                            |/etc/init.d/netstd_misc
-------------------------------------------------------------------------------
Slackware|/etc/rc.d/rc.inet1                          |/etc/rc.d/rc.inet2 
-------------------------------------------------------------------------------
RedHat   |/etc/sysconfig/network-scripts/ifup-&lt;ifname>|/etc/rc.d/init.d/network
-------------------------------------------------------------------------------
</verb>

De flesta moderna distributioner har ett program med vilket man kan 
konfigurera många av de vanligaste sorterna av nätverksgränssnitt. Om man har 
en av dessa så bör man se om det kan göra det man vill innan man ger sig på 
manuell konfiguration.

<tscreen><verb>
-----------------------------------------
Distrib   | Network configuration program
-----------------------------------------
RedHat    | /sbin/netcfg
Slackware | /sbin/netconfig
-----------------------------------------
</verb></tscreen>
 
<sect1><heading>Att skapa sina nätverksgränssnitt.
<p>
I många Unix operativsystem så framträder nätverksenheterna i <em>/dev</em> 
katalogen. Så är inte fallet i Linux. I Linux skapas nätverksenheterna
dynamiskt i mjukvara och därmed måste inte enhetsfiler finnas.
<p>
I de flesta fall skapas nätverksenheterna automatiskt av drivrutinen när den
initialiseras och hittar din hårdvara. Till exempel så skapar 
Ethernetdrivrutinen <tt/eth&lsqb;0..n]/ gränssnitten sekvensiellt medan den
hittar din Ethernethårdvara. Det första Ethernetkortet som hittas blir 
<tt/eth0/, det andra <tt/eth1/ osv.
<p>
Men i några fall, tex <em/slip/ och <em/ppp/, så skapas nätverksenheterna genom
att något användarprogram körs. Samma sekvensiella numrering gäller, men 
enheterna skapas inte automatiskt vid systemstarten. Anledningen till detta är
att, till skillnad från Ethernetenheterna, så kan antalet aktiva <em/slip/ 
eller <em/ppp/ enheter variera under tiden systemet är igång. De här fallen gås
igenom mer noggrannt senare.

<sect1><heading>Att konfigurera ett nätverksgränssnitt.
<p>
När man har alla program man behöver och sina adress- och nätverksuppgifter så 
kan man konfigurera sina nätverksgränssnitt. När vi pratar om att konfigurera
ett nätverksgränssnitt så pratar vi om processen att tilldela en nätverksenhet
lämpliga adresser och att ge lämpliga värden till andra konfigurerbara parametrar
hos en nätverksenhet. Det mest använda programmet för detta är kommandot 
<em/ifconfig/ (interface configure).
<p>
Vanligtvis bör man använda ett kommando som liknar följande:
<tscreen><verb>
# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up
</verb></tscreen>
I detta fallet konfigurerar jag ett Ethernetkort <tt/eth0/ med IP-adressen
<tt/192.168.0.1/ och en nätmask <tt/255.255.255.0/.
Parametern <em/up/ som följer kommandot talar om för enheten att den skall
bli aktiv.
<p>
Kärnan förutsätter vissa förvalda värden när man konfigurerar gränssnitt. Till
exempel så kan man specificera nätverksadress och broadcastadress för ett 
gränssnitt. Men om man inte gör det, som i exemplet ovan, så gör kärnan 
rimliga gissningar baserade på nätmasken, och om man inte specificerat någon
nätmask så tittar kärnan på klassen av IP-adress. I exemplet ovan skulle 
kärnan anta att det är ett klass C nätverk som skall konfigureras och därmed
sätta nätverksadressen till <tt/192.168.0.0/ och broadcastadressen till 
<tt/192.168.0.255/.
<p>
Det finns många andra parametrar till <em/ifconfig/. De viktigaste
är:
<descrip>
<tag/up/ aktiverar ett gränssnitt.
<p><tag/down/ deaktiverar ett gränssnitt.
<p><tag/&lsqb;-]arp/ slår av eller slår på 'address resolution protocol' för 
gränssnittet.
<p><tag/&lsqb;-]allmulti/ slår av eller slår på mottagning av alla 
hårdvaru-multicastpaket. Hårdvaru-multicast låter grupper av maskiner att ta 
emot paket som är adresserade till speciella destinationer. Detta kan vara
viktigt om man använder applikationer såsom videokonferenssystem men används
normalt inte.
<p><tag/mtu N/ specificerar <em/MTU/ för enheten.
<p><tag/netmask addr/ specificerar nätmasken för nätverket som maskinen
tillhör.
<p><tag/irq addr/ denna parameter fungerar endast för viss hårdvara och sätter
IRQ för enheten.
<p><tag/&lsqb;-]broadcast &lsqb;addr]/ slår på mottagning av datagram som
skickas till broadcastadressen, eller slår av mottagning av dessa datagram.
<p><tag/&lsqb;-]pointopoint &lsqb;addr]/ sätter adressen på maskinen på 
andra änden av en punkt till punkt förbindelse som tex <em/slip/ eller 
<em/ppp/.
<p><tag/hw &lt;type> &lt;addr>/ sätter hårdvaruadressen för 
nätverksenheten. Oftast är detta inte användbart för Ethernet, men är 
användbart för andra typer av nätverk som tex AX.25.
</descrip>
Man kan använda kommandot <em/ifconfig/ på alla nätverksgränssnitt. Vissa 
användarprogram, tex <em/pppd/ och <em/dip/, konfigurerar enheterna automatisk
när de skapar dem, så manuell användning av <em/ifconfig/ är inte nödvändig.

<sect1><heading>Att konfigurera din Name Resolver.
<p>
<em/Name Resolver/n är en del av Linux standardbibliotek. Dess huvudsakliga 
funktion är att tillhandahålla en tjänst för att översätta människovänliga
datornamn som <tt/ftp.funet.fi/ till maskinvänliga IP-adresser som
<tt/128.214.248.6/.
<p>
<sect2><heading>Vad består ett namn av?
<p>
De flesta är antagligen bekanta med hur datornamn uppträder i Internet, men man kanske
inte vet hur de är konstruerade, eller rekonstruerade. Internet domännamn är 
av hierarkisk karaktär, dvs de har trädstruktur. En <em/domän/ är en familj, 
eller grupp av namn. En <em/domän/ kan brytas ned i <em/subdomäner/. En
<em/toppdomän/ är en domän som inte är en subdomän. Toppdomänerna är
specificerade i RFC-920. Några exempel på de vanligaste topdomänerna är:

<descrip>
<tag/COM/Kommersiella Organisationer
<p><tag/EDU/Utbildningsorganisationer
<p><tag/GOV/Regeringsorganisationer
<p><tag/MIL/Militärorganisationer
<p><tag/ORG/Andra Organisationer
<p><tag/NET/Internet-Relaterade Organisationer
<p><tag/Landskod/Detta är koder som består av två bokstäver och som representerar
ett visst land.
</descrip>

Alla dessa toppdomäner har subdomäner. Toppdomänerna baserade på landsnamn 
bryts sedan ned i subdomäner baserade på <tt/com/, <tt/edu/, <tt/gov/, 
<tt/mil/ och <tt/org/ domäner (detta är ju dock inte fallet i .se-domänen ännu.
Översättarens kommentar). Så till exempel blir det <tt/com.au/ och <tt/gov.au/
för kommersiella och regeringsorganisationer i Australien. Av historiska skäl
så används de domäner som tillhör de icke landsbaserade toppdomänerna 
mestadels av organisationer i USA, trots att USA har sin egen landskod 
<tt/.us/.
<p>
Nästa nedbrytningsnivå representerar oftast namnet på organisationen. 
Ytterligare subdomäner varierar i karaktär, oftast så baseras nästa nivå
på avdelningar inom organisationen, men den kan baseras på vilket kriterium som
helst som har någon betydelse för nätverksadministratörerna i organisationen.
<p>
Delen längst till vänster av namnet är alltid det unika namnet som värddatorn har 
och det kallas för <em/hostname/, den delen av namnet som finns till höger
om <em/hostname/ kallas för <em/domainname/ och hela namnet heter 
<em/Fully Qualified Domain Name/.
<p>
Med min egen emailvärddator som exempel, så är 
`Fully Qualified Domain Name' <tt/perf.no.itg.telstra.com.au/. Detta betyder
att hostname är <tt/perf/ och domainname är <tt/no.itg.telstra.com.au/.
Domännamnet är baserat på en toppdomän vilken är baserad på mitt land, Australien och 
eftersom min epostadress tillhör en komersiell organisation så har vi 
<tt/.com/ på nästa nivå. Företagets namn är (var) <tt/telstra/ och vår 
interna namnstruktur är baserad på den organisationella strukturen, i mitt fall
så tillhör maskinen Information Technology Group, Network Operations sektionen.

<sect2><heading>Vilken information behöver man.
<p>
Man behöver veta vilken domän datorns namn skall tillhöra. Name 
Resolvermjukvaran tillhandahåller namnöversättning genom att göra förfrågningar
till en <em/Domain Name Server/, så man behöver veta IP-adressen till en lokal
namnserver som man kan använda.
<p>
Det finns tre filer som man behöver editera, jag berättar om dem i tur och 
ordning.

<sect2><heading>/etc/resolv.conf
<p>
Filen <tt>/etc/resolv.conf</tt> är huvudfilen för att konfigurera 
namnöversättaren. Dess format är ganska enkelt. Det är en textfil med ett
nyckelord per rad. Det finns tre nyckelord som vanligtvis används, de är:
<descrip>
<tag/domain/detta nyckelord specificerar det lokala domännamnet.

<tag/search/detta nyckelord specificerar en lista med alternativa domännamn
att leta i efter ett datornamn.

<tag/nameserver/detta nyckelord, som kan användas flera gånger, specificerar
en IP-adress till en namnserver (<em/Domain Name Server/) att använda när
man översätter namn.
</descrip>
Ett exempel på <tt>/etc/resolv.conf</tt> kan se ut någonting som följande:<tscreen><verb>
domain maths.wu.edu.au
search maths.wu.edu.au wu.edu.au
nameserver 192.168.10.1
nameserver 192.168.12.1
</verb></tscreen>
Detta exempel anger att man lägger till domännamnet <tt/maths.wu.edu.au/ till
datornamn som ges utan domännamn, och om datorn inte hittas där så skall man 
leta även i <tt/wu.edu.au/ domänen. Två namnservrar är specificerade, som båda 
kan kontaktas av namnöversättaren när ett namn skall översättas.

<sect2><heading>/etc/host.conf
<p>
I filen <tt>/etc/host.conf</tt> kan man konfigurera hur namnöversättaren 
beter sig. Formatet för filen är beskrivet i detalj i manualsidan 
<tt/resolv+/. I nästan alla fall fungerar följande exempel:

<tscreen><verb>                          
order hosts,bind                                          
multi on  
</verb></tscreen>

Denna konfiguration talar om för översättaren att titta i filen 
<tt>/etc/hosts</tt> innan den försöker göra en förfrågning till namnservern och
att returnera alla giltiga adresser för en dator som den hittar i 
<tt>/etc/hosts</tt> och inte bara den första.

<sect2><heading>/etc/hosts
<p>
I filen <tt>/etc/hosts</tt> kan man lägga namn och IP-adresser för lokala 
maskiner. Om man placerar ett datornamn med respektive IP-adress i denna fil
så behöver man inte göra en förfrågan till namnservern för att få reda på dess
IP-adress. Nackdelen med detta är att man måste hålla filen uppdaterad själv 
ifall IP-adresserna ändras. I ett väl underhållet system så finns endast rader
med 'loopback' och lokala datornamn i denna fil.

<tscreen><verb>
# /etc/hosts
127.0.0.1      localhost loopback
192.168.0.1    this.host.name
</verb></tscreen>

Man kan ange mer än ett datornamn per rad som på den första raden i exemplet, 
vilket är standardutformningen för loopbackenheten.

<sect1><heading>Att konfigurera loopbackenheten.
<p>
<tt/loopback/-enheten är ett särskilt gränssnitt med vilket man kan göra 
anslutningar till sig själv. Det finns olika anledningar varför man skulle 
vilja göra detta, till exempel så kanske man vill testa någon nätverksmjukvara utan 
att störa någon annan på sitt nätverk. Av tradition så har IP-adressen
<tt/127.0.0.1/ reserverats speciellt för loopback. Så, oavsett vilken maskin
man går till, om man öppnar en telnet-anslutning till <tt/127.0.0.1/ så blir
man alltid ansluten till den lokala datorn.
<p>
Att konfigurera loopbackenheten är enkelt och man bör göra följande:

<tscreen><verb>
# ifconfig lo 127.0.0.1
# route add -host 127.0.0.1 lo
</verb></tscreen>

Vi pratar mer om <em/route/ kommandot i nästa sektion.

<sect1><heading>Routing.
<p>
Routing är ett stort ämne. Det skulle vara lätt att skriva stora mängder text 
om detta. De flesta kommer att ha hyfsat enkla krav på routingen, men vissa
har det inte. Jag kommer bara att behandla grunderna om routing. Om man är 
intresserad av mer detaljerad information så föreslår jag att man letar i 
referenserna som ges i början av detta dokument.
<p>
Låt oss börja med en definition. Vad är IP routing? Här följer den definition
som jag använder:
<p>
<quote>IP routing är processen där en dator med flera nätverksanslutningar
avgör vart den skall skicka IP datagram som den har tagit emot.</quote>
<p>
Det kan vara bra att illustrera detta med ett exempel. Antag en typisk
kontorsrouter, den skulle kunna ha en PPP-länk till Internet, ett antal 
Ethernetsegment som går till arbetsstationerna och en annan PPP-länk till ett
annat kontor. När routern tar emot ett datagram på någon av dess 
nätverksanslutningar, så är routing mekanismen den använder för att avgöra 
till vilken av nätverksanslutningarna som den skall skicka vidare datagrammet. 
Enkla datorer behöver också använda routing, alla Internetdatorer har åtminstone två 
nätverksenheter, en är loopbackenheten som beskrivs ovan och den andra är den 
som den använder för att 'prata' med resten av nätverket, kanske ett 
Ethernetkort, kanske ett PPP- eller SLIP-gränssnitt.
<p>
Hur fungerar routing? Varje dator har en speciell lista med routingregler som 
kallas för routingtabellen (routing table). Denna tabell innehåller rader som 
vanligtvis innehåller åtminstone tre fält, det första är en 
destinationsadress, det andra är namnet på gränssnittet som datagrammet skall
routas till och det tredje är IP-adressen på en annan maskin som skall ta 
datagrammet på sitt nästa steg genom nätverket. I Linux kan man se denna 
tabell genom att använda följande kommando:
<tscreen><verb>
# cat /proc/net/route
</verb></tscreen>
eller genom att använda något av följande kommandon:
<tscreen><verb>
# /sbin/route -n
# /bin/netstat -r
</verb></tscreen>
<p>
Routingprocessen är hyfsat enkel: ett inkommande datagram tas emot, 
destinationsadressen undersöks och jämförs med varje rad i tabellen. Den rad
som bäst matchar adressen väljs och datagrammet skickas vidare till det 
specificerade gränssnittet. Om gateway-fältet är ifyllt så skickas datagrammet
vidare till den maskinen via det specificerade gränssnittet, annars antas det
att destinationsadressen finns på nätverket som gränssnittet är kopplat till.
<p>
För att manipulera tabellen använder man ett speciellt kommando. Detta kommando
tar kommandoradsargument och konverterar dem till systemanrop vilka ber kärnan
att lägga till, ta bort eller ändra rader i routingtabellen. Kommandot är
<em/route/.
<p>
Ett enkelt exempel. Antag att man har ett Ethernetnätverk. Man har fått veta
att det är ett klass C nätverk med nätverksadressen <tt/192.168.1.0/. Man har 
fått IP-adressen <tt/192.168.1.10/ som man kan använda och man har fått veta att
<tt/192.168.1.1/ är en router som är ansluten till Internet.
<p>
Det första steget är att konfigurera gränssnittet som det beskrivits ovan. Man 
skulle använda ett kommando som:
<tscreen><verb>
# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
</verb></tscreen>
Man behöver nu lägga till en rad i routingtabellen för att tala om för kärnan
att datagram till alla adresser som passar <tt/192.168.1.*</tt> skall sändas 
till en Ethernet-enhet. Detta med ett kommando som:
<tscreen><verb>
# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
</verb></tscreen>
Notera <tt/-net/ parametern som används för att tala om för routingprogrammet
att denna rad är en nätverksroute. Det andra alternativet är en <tt/-host/ route som
är en route som är till en specifik IP-adress.
<p>
Med denna route kan man upprätta IP-anslutningar till alla datorer på sitt 
Ethernet-segment. Men vad händer med alla IP-datorer som inte finns på ens
Ethernet-segment?
<p>
Det skulle vara ett väldigt svårt jobb att behöva lägga till router till varje
tänkbart nätverk, så det finns ett specialtrix som används för att förenkla denna
uppgift. Trixet kallas för <tt/default/ route. <tt/Default/ routen passar
varje möjlig destination, men dåligt, så om det finns någon annan rad som 
passar den önskade adressen bättre så kommer den att användas istället för
<tt/default/ routen. Tanken med <tt/default/ routen är helt enkelt att man skall kunna
säga "och allt annat skall skickas dit". Så i exemplet som vi följt så bör man 
använda en rad som:
<tscreen><verb>
# route add default gw 192.168.1.1 eth0
</verb></tscreen>
Parametern <tt/gw/ talar om för route kommandot att nästa parameter är 
IP-adressen, eller namnet, på en gateway eller router dit alla datagram som 
passar denna rad skall skickas för vidare routing.
<p>
Så exemplets kompletta konfiguration skulle se ut så här:
<tscreen><verb>
# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
# route add default gw 192.168.1.1 eth0
</verb></tscreen>
Om man tittar noga i sina <tt/rc/-filer för nätverket så kommer man att hitta
åtminstone en som liknar detta. Detta är en väldigt vanlig konfiguration.
<p>
Låt oss nu titta på en något mer komplicerad routingkonfiguration. Antag att 
vi konfigurerar routern som vi tittade på tidigare, med en PPP-länk till 
Internet och några LAN-segment med arbetsstationer på kontoret. Antag att 
routern har tre Ethernet-segment och en PPP-länk. Vår routingkonfiguration 
skulle likna följande:
<tscreen><verb>
# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
# route add -net 192.168.2.0 netmask 255.255.255.0 eth1
# route add -net 192.168.3.0 netmask 255.255.255.0 eth2
# route add default ppp0
</verb></tscreen>
Varje arbetsstation skulle använda den enklare formen som beskrevs ovan, endast
routern behöver ange alla nätverksrouter separat eftersom hos arbetsstationerna
så tar <tt/default/ route mekanismen hand om allihop och låter routern sköta 
den 'riktiga' routingen. Man kanske undrar varför defaultrouten inte anger en
<tt/gw/. Anledningen är enkel, seriella länkprotokoll såsom PPP och SLIP har
alltid endast två maskiner på sitt nätverk, en i varje ända. Att ange maskinen
på andra sidan länken som gateway är meningslöst och redundant eftersom det 
inte finns något annat val, så man behöver inte ange någon gateway för den typen
av nätverksanslutningar. Andra nätverkstyper såsom Ethernet, arcnet eller 
Token Ring kräver att en gateway specificeras eftersom dessa nätverken stödjer
att ett stort antal datorer ansluts till dem.

<sect2><heading>Så vad gör programmet <em/routed/?
<p>
Routingkonfigurationen som beskrivs ovan passar bäst för enklare 
nätverksarrangemang där det endast finns en möjlig väg till varje destination.
När man har ett mer komplext arrangemang så blir det lite besvärligare. Som tur
är behöver de flesta inte bry sig om detta.
<p>
Det stora problemet med 'manuell routing' eller 'statisk routing' är att om en
maskin eller länk fallerar i nätverket så kan man endast dirigera om sina
datagram, om det finns någon annan väg, genom att manuellt ge lämpliga 
kommandon. Naturligtvis är detta klumpigt, långsamt, opraktiskt och felbenäget.
Olika tekniker har utvecklats för att automatiskt ändra routingtabeller om det
uppstår nätverksfel där det finns alternativa vägar att leda trafiken, alla 
dessa tekniker är löst samlade under termen 'dynamiska routing algoritmer'.
<p>
Man kanske har hört talas om några av de vanligare dynamiska routingalgorimerna.
De allra vanligaste är RIP (Routing Information Protocol) och OSPF (Open
Shortest Path First). RIP är väldigt vanlig i små nätverk som till exempel
små/mellanstora företagsnätverk. OSPF är modernare och mer kapabel att hantera 
stora nätverk och bättre anpassad till omgivningar där det finns ett stort 
antal möjliga vägar genom ett nätverk. Vanliga implementeringar av dessa är:
<em/routed/ (RIP) och <em/gated/ (RIP, OSPF och andra). Programmet 
<em/routed/ finns normalt med i Linuxdistributioner eller finns inkluderat
i 'NetKit' paketet ovan.
<p>
Ett exempel på var och hur man skulle kunna använda en dynamisk routingalgoritm
skulle kunna se ut som följer:
<tscreen><verb>
    192.168.1.0 /                         192.168.2.0 /
       255.255.255.0                         255.255.255.0
     -                                     -
     |                                     |
     |   /-----\                 /-----\   |
     |   |     |ppp0   //    ppp0|     |   |
eth0 |---|  A  |------//---------|  B  |---| eth0
     |   |     |     //          |     |   |
     |   \-----/                 \-----/   |
     |      \ ppp1             ppp1 /      |
     -       \                     /       -
              \                   /
               \                 /
                \               /
                 \             /
                  \           /
                   \         /
                    \       /
                     \     /
                  ppp0\   /ppp1
                     /-----\
                     |     |
                     |  C  |
                     |     |
                     \-----/
                        |eth0
                        |
                   |---------|
                   192.168.3.0 /
                      255.255.255.0

</verb></tscreen>

Vi har tre routrar A, B och C. Var och en har ett Ethernet-segment med ett 
klass C IP-nätverk (nätmask 255.255.255.0). Varje router har även en PPP-länk
till var och en av de andra routrarna. Nätverket bildar en triangel.
<p>
Det bör vara klart att routingtabellen för router A skulle kunna se ut som:
<tscreen><verb>
# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
# route add -net 192.168.2.0 netmask 255.255.255.0 ppp0
# route add -net 192.168.3.0 netmask 255.255.255.0 ppp1
</verb></tscreen>
Detta skulle fungera utmärkt ända tills länken mellan router A och B fallerar.
Om så skulle ske så skulle datorer på A's Ethernet-segment inte kunna nå 
datorer på B's Ethernet-segment eftersom dess datagram skulle routas till A's
ppp0-länk, vilken är trasig. De skulle fortfarande kunna 'prata' med datorer
på C's Ethernet-segment och datorer på C's Ethernet-segment skulle kunna 
kontakta datorer på B's Ethernet-segment eftersom länkarna mellan A och C 
respektive mellan C och B fortfarande fungerar.
<p>
Men vänta lite nu, om A kan prata med C och C fortfarande kan prata med B, 
varför skulle inte A kunna routa sina datagram till B via C och låta C skicka
dem till B? Detta är precis den typen av problem som dynamiska 
routingalgoritmer som RIP designades för att lösa. Om var och en av routrarna
A, B och C körde en routingdaemon så skulle deras routingtabeller automatiskt 
uppdateras till att spegla det nya tillståndet i nätverket om någon av länkarna
skulle fallera. För att konfigurera ett sådant nätverk är enkelt, på varje
router behöver man endast göra två saker. I detta fall för router A:
<tscreen><verb>
# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
# /usr/sbin/routed
</verb></tscreen>
Routingdaemonen <em/routed/ hittar automatiskt alla aktiva nätverksportar när
den startar och skickar och lyssnar efter meddelanden på var och en av 
nätverksenheterna så att den kan fastställa och uppdatera routingtabellen på
datorn.
<p>
Detta har varit en väldigt översiktlig förklaring av dynamisk routing och var
man bör använda det. Om man vill ha mer information så sök ibland referenserna
i början av dokumentet.
<p>
De viktiga punkterna relaterade till dynamisk routing är:
<enum>
<item>Man behöver bara använda dynamisk routing när ens Linuxburk har 
möjligheten att välja flera olika routes till en destination.
<item>Den dynamiska routingdaemonen kommer automatiskt att modifiera
routingtabellen för att ställa in sig till förändringar i nätverket.
<item>RIP är bra anpassat för små till medelstora nätverk.
</enum>

<sect1><heading>Att konfigurera nätverksservrar och tjänster.
<p>
Nätverksservrar och tjänster är de program som låter en avlägsen användare
använda sig av ens Linuxburk. Serverprogram lyssnar på nätverksportar.
Nätverksportar är hjälpmedel för att adressera en speciell tjänst på en dator
och är hur en server vet skillnaden mellan en inkommande telnet-anslutning och
en inkommande ftp-anslutning. Den avlägsna användaren upprättar en 
nätverksanslutning till Linuxburken och serverprogrammet, nätverksdaemonen, 
lyssnar på den porten och accepterar anslutningen och exekverar. Det finns två
sätt på vilka nätverksdaemoner kan fungera. Båda är flitigt använda i 
praktiken. De två sätten är:

<descrip>
<tag>fristående</tag>nätverksdaemonen lyssnar på den angivna porten och när den
upptäcker en inkommande anslutning så sköter den om anslutningen själv för att
vidare tillhandahålla tjänster.
<p><tag>slav till <em/inetd/ servern</tag><em/inetd/ servern är en särskild
nätverksdaemon som är specialiserad på att ta hand om inkommande 
nätvarksanslutningar. Den har en konfigurationsfil som talar om vilket program
som skall köras då en inkommande anslutning tas emot. Varje port kan 
konfigureras för något av protokollen TCP eller UDP. Portarna är beskrivna i 
en annan fil som vi skall prata om snart.
</descrip>
Det finns två viktiga filer som behöver konfigureras. De är 
<tt>/etc/services</tt> som tilldelar namn till portnummer och 
<tt>/etc/inetd.conf</tt> som är konfigurationsfilen till nätverksdaemonen 
<em/inetd/.

<sect2><heading><tt>/etc/services</tt>
<p>
Filen <tt>/etc/services</tt> är en enkel databas som associerar ett 
människovänligt namn med en maskinvänlig port. Formatet är ganska enkelt. Filen
är en textfil där varje rad representerar en rad i databasen. Varje rad består
av tre fält som är separerade av valfritt antal vita tecken (tab eller space).
Fälten är:
<verb>
name      port/protocol        aliases     # comment
</verb>
<descrip>
<tag>name</tag>ett namn, bestående av ett ord, som representerar tjänsten som
skall beskrivas.
<p><tag>port/protocol</tag>detta fält är indelat i två delfält.
         <descrip>

	 <tag>port</tag>ett nummer som anger portnummret som den namngivna
	 tjänsten kommer att vara tillgänglig på. De flesta vanliga tjänster
	 har tilldelats reserverade nummer. Dessa finns beskrivna i
	 <tt>RFC-1340</tt>.
	 <p><tag>protocol</tag>detta delfält kan sättas till antingen <tt>tcp</tt>
	 eller <tt>udp</tt>.
	 </descrip>

Det är viktigt att notera att en rad med <tt>18/tcp</tt> är väldigt olik en rad
med <tt>18/udp</tt> och att det inte finns någon teknisk anledning till att
samma tjänst finns tillgänglig på båda. Normalt råder sunt förnuft och det är
bara om en viss tjänst finns tillgänglig via både <tt>tcp</tt> och <tt>udp</tt>
som man kommer att se rader med båda.
<p><tag>aliases</tag>andra namn som kan användas för att referera till denna 
tjänsten.
</descrip>
All text som finns efter ett <tt/#/ tecken på en rad ignoreras och behandlas 
som en kommentar.
<sect3>Ett exempel på en <tt>/etc/services</tt> fil.
<p>
Alla moderna Linuxdistributioner kommer med en bra <tt>/etc/services</tt> fil.
Men i fall man råkar bygga ett system från grunden så är här en kopia av 
<tt>/etc/services</tt> filen som kommer med 
<url url="http://www.debian.org/" name="Debian"> distributionen.
<tscreen><verb>
# /etc/services:
# $Id: services,v 1.3 1996/05/06 21:42:37 tobias Exp $
#
# Network services, Internet style
#
# Note that it is presently the policy of IANA to assign a single well-known
# port number for both TCP and UDP; hence, most entries here have two entries
# even if the protocol doesn't support UDP operations.
# Updated from RFC 1340, ``Assigned Numbers'' (July 1992).  Not all ports
# are included, only the more common ones.

tcpmux		1/tcp				# TCP port service multiplexer
echo		7/tcp
echo		7/udp
discard		9/tcp		sink null
discard		9/udp		sink null
systat		11/tcp		users
daytime		13/tcp
daytime		13/udp
netstat		15/tcp
qotd		17/tcp		quote
msp		18/tcp				# message send protocol
msp		18/udp				# message send protocol
chargen		19/tcp		ttytst source
chargen		19/udp		ttytst source
ftp-data	20/tcp
ftp		21/tcp
ssh		22/tcp				# SSH Remote Login Protocol
ssh		22/udp				# SSH Remote Login Protocol
telnet		23/tcp
# 24 - private
smtp		25/tcp		mail
# 26 - unassigned
time		37/tcp		timserver
time		37/udp		timserver
rlp		39/udp		resource	# resource location
nameserver	42/tcp		name		# IEN 116
whois		43/tcp		nicname
re-mail-ck	50/tcp				# Remote Mail Checking Protocol
re-mail-ck	50/udp				# Remote Mail Checking Protocol
domain		53/tcp		nameserver	# name-domain server
domain		53/udp		nameserver
mtp		57/tcp				# deprecated
bootps		67/tcp				# BOOTP server
bootps		67/udp
bootpc		68/tcp				# BOOTP client
bootpc		68/udp
tftp		69/udp
gopher		70/tcp				# Internet Gopher
gopher		70/udp
rje		77/tcp		netrjs
finger		79/tcp
www		80/tcp		http		# WorldWideWeb HTTP
www		80/udp				# HyperText Transfer Protocol
link		87/tcp		ttylink
kerberos	88/tcp		kerberos5 krb5	# Kerberos v5
kerberos	88/udp		kerberos5 krb5	# Kerberos v5
supdup		95/tcp
# 100 - reserved
hostnames	101/tcp		hostname	# usually from sri-nic
iso-tsap	102/tcp		tsap		# part of ISODE.
csnet-ns	105/tcp		cso-ns		# also used by CSO name server
csnet-ns	105/udp		cso-ns
rtelnet		107/tcp				# Remote Telnet
rtelnet		107/udp
pop-2		109/tcp		postoffice	# POP version 2
pop-2		109/udp
pop-3		110/tcp				# POP version 3
pop-3		110/udp
sunrpc		111/tcp		portmapper	# RPC 4.0 portmapper TCP
sunrpc		111/udp		portmapper	# RPC 4.0 portmapper UDP
auth		113/tcp		authentication tap ident
sftp		115/tcp
uucp-path	117/tcp
nntp		119/tcp		readnews untp	# USENET News Transfer Protocol
ntp		123/tcp
ntp		123/udp				# Network Time Protocol
netbios-ns	137/tcp				# NETBIOS Name Service
netbios-ns	137/udp
netbios-dgm	138/tcp				# NETBIOS Datagram Service
netbios-dgm	138/udp
netbios-ssn	139/tcp				# NETBIOS session service
netbios-ssn	139/udp
imap2		143/tcp				# Interim Mail Access Proto v2
imap2		143/udp
snmp		161/udp				# Simple Net Mgmt Proto
snmp-trap	162/udp		snmptrap	# Traps for SNMP
cmip-man	163/tcp				# ISO mgmt over IP (CMOT)
cmip-man	163/udp
cmip-agent	164/tcp
cmip-agent	164/udp
xdmcp		177/tcp				# X Display Mgr. Control Proto
xdmcp		177/udp
nextstep	178/tcp		NeXTStep NextStep	# NeXTStep window
nextstep	178/udp		NeXTStep NextStep	# server
bgp		179/tcp				# Border Gateway Proto.
bgp		179/udp
prospero	191/tcp				# Cliff Neuman's Prospero
prospero	191/udp
irc		194/tcp				# Internet Relay Chat
irc		194/udp
smux		199/tcp				# SNMP Unix Multiplexer
smux		199/udp
at-rtmp		201/tcp				# AppleTalk routing
at-rtmp		201/udp
at-nbp		202/tcp				# AppleTalk name binding
at-nbp		202/udp
at-echo		204/tcp				# AppleTalk echo
at-echo		204/udp
at-zis		206/tcp				# AppleTalk zone information
at-zis		206/udp
z3950		210/tcp		wais		# NISO Z39.50 database
z3950		210/udp		wais
ipx		213/tcp				# IPX
ipx		213/udp
imap3		220/tcp				# Interactive Mail Access
imap3		220/udp				# Protocol v3
ulistserv	372/tcp				# UNIX Listserv
ulistserv	372/udp
#
# UNIX specific services
#
exec		512/tcp
biff		512/udp		comsat
login		513/tcp
who		513/udp		whod
shell		514/tcp		cmd		# no passwords used
syslog		514/udp
printer		515/tcp		spooler		# line printer spooler
talk		517/udp
ntalk		518/udp
route		520/udp		router routed	# RIP
timed		525/udp		timeserver
tempo		526/tcp		newdate
courier		530/tcp		rpc
conference	531/tcp		chat
netnews		532/tcp		readnews
netwall		533/udp				# -for emergency broadcasts
uucp		540/tcp		uucpd		# uucp daemon
remotefs	556/tcp		rfs_server rfs	# Brunhoff remote filesystem
klogin		543/tcp				# Kerberized `rlogin' (v5)
kshell		544/tcp		krcmd		# Kerberized `rsh' (v5)
kerberos-adm	749/tcp				# Kerberos `kadmin' (v5)
#
webster		765/tcp				# Network dictionary
webster		765/udp
#
# From ``Assigned Numbers'':
#
#> The Registered Ports are not controlled by the IANA and on most systems
#> can be used by ordinary user processes or programs executed by ordinary
#> users.
#
#> Ports are used in the TCP [45,106] to name the ends of logical
#> connections which carry long term conversations.  For the purpose of
#> providing services to unknown callers, a service contact port is
#> defined.  This list specifies the port used by the server process as its
#> contact port.  While the IANA can not control uses of these ports it
#> does register or list uses of these ports as a convienence to the
#> community.
#
ingreslock	1524/tcp
ingreslock	1524/udp
prospero-np	1525/tcp		# Prospero non-privileged
prospero-np	1525/udp
rfe		5002/tcp		# Radio Free Ethernet
rfe		5002/udp		# Actually uses UDP only
bbs		7000/tcp		# BBS service
#
#
# Kerberos (Project Athena/MIT) services
# Note that these are for Kerberos v4 and are unofficial.  Sites running
# v4 should uncomment these and comment out the v5 entries above.
#
kerberos4	750/udp		kdc	# Kerberos (server) udp
kerberos4	750/tcp		kdc	# Kerberos (server) tcp
kerberos_master	751/udp			# Kerberos authentication
kerberos_master	751/tcp			# Kerberos authentication
passwd_server	752/udp			# Kerberos passwd server
krb_prop	754/tcp			# Kerberos slave propagation
krbupdate	760/tcp		kreg	# Kerberos registration
kpasswd		761/tcp		kpwd	# Kerberos "passwd"
kpop		1109/tcp		# Pop with Kerberos
knetd		2053/tcp		# Kerberos de-multiplexor
zephyr-srv	2102/udp		# Zephyr server
zephyr-clt	2103/udp		# Zephyr serv-hm connection
zephyr-hm	2104/udp		# Zephyr hostmanager
eklogin		2105/tcp		# Kerberos encrypted rlogin
#
# Unofficial but necessary (for NetBSD) services
#
supfilesrv	871/tcp			# SUP server
supfiledbg	1127/tcp		# SUP debugging
#
# Datagram Delivery Protocol services
#
rtmp		1/ddp			# Routing Table Maintenance Protocol
nbp		2/ddp			# Name Binding Protocol
echo		4/ddp			# AppleTalk Echo Protocol
zip		6/ddp			# Zone Information Protocol
#
# Debian GNU/Linux services
rmtcfg		1236/tcp		# Gracilis Packeten remote config server
xtel		1313/tcp		# french minitel
cfinger		2003/tcp		# GNU Finger
postgres	4321/tcp		# POSTGRES
mandelspawn	9359/udp	mandelbrot	# network mandelbrot

# Local services
</verb></tscreen>

<sect2><heading><tt>/etc/inetd.conf</tt>
<p>
Filen <tt>/etc/inetd.conf</tt> är konfigurationsfilen för serverdaemonen
<em/inetd/. Dess funktion är att tala om för <em/inetd/ vad som skall hända när
den tar emot en anslutningsförfrågan för en viss tjänst. För varje tjänst för 
vilken man önskar acceptera anslutningar måste man tala om för <em/inetd/ vilken
nätverksserver den skall starta och hur den skall startas.
<p>
Dess format är ganska enkelt. Det är en textfil där varje rad beskriver en 
tjänst som man vill tillhandahålla. All text efter ett <tt/#/ tecken på en rad
ignoreras och ses som en kommentar. Varje rad innehåller sju fält som är 
separerade av valfritt antal vita tecken (tab eller space). Det generella
formatet är som följer:
<tscreen><verb>
service  socket_type  proto  flags  user  server_path  server_args
</verb></tscreen>
<descrip>
<tag>service</tag>är tjänsten som är relevant för denna konfiguration som den 
benämns i <tt>/etc/services</tt>.
<p><tag>socket_type</tag>detta fält beskriver vilken typ av socket som denna rad
kommer att beteckna som relevant, tillåtna värden är <tt/stream/, <tt/dgram/, 
<tt/raw/, <tt/rdm/ eller <tt/seqpacket/. Detta är lite tekniskt till karaktären
men som tumregel så använder nästan alla <tt/tcp/-baserade tjänster <tt/stream/
och alla <tt/udp/-baserade tjänster <tt/dgram/. Det är bara väldigt speciella
typer av daemoner som använder de andra värdena.
<p><tag>proto</tag>protokollet som skall anses som giltigt för denna rad. Detta
skall passa ihop med lämplig rad i <tt>/etc/services</tt> och är vanligtvis
antingen <tt/tcp/ eller <tt/udp/. Sun RPC (Remote Procedure Call) baserade
tjänster använder <tt>rpc/tcp</tt> eller <tt>rcp/udp</tt>.
<p><tag>flags</tag>det finns egentligen bara två möjliga värden för detta fält.
Detta fält talar om för <tt/inetd/ om serverprogramvaran stänger socketen
efter det att den startats och därför om <em/inetd/ kan starta en annan server
på nästa anslutningsförfrågan. Återigen så är detta lite besvärligt att lista
ut, men som tumregel så skall alla <tt/tcp/ servrar ha värdet <tt/nowait/ och
de flesta <tt/udp/ servrar <tt/wait/. Observera att det finns undantag för
detta, så man bör endast följa exemplet om man inte vet.
<p><tag>user</tag>detta fält talar om vilket användarkonto från 
<tt>/etc/passwd</tt> som skall sättas som ägare till nätverksdaemonen när den
startas. Detta är ofta användbart för att skydda sig mot säkerhetsrisker. Man
kan sätta värdet till <tt/nobody/ så att skadan minimeras ifall 
nätverksserverns säkerhet fallerar. Men vanligtvis så är detta fält satt till
<tt/root/ eftersom många servrar måste ha root-rättigheter för att fungera
korrekt.
<p><tag>server_path</tag>detta fält skall innehålla det absoluta filnamnet till
serverprogrammet som skall exekveras för denna raden.
<p><tag>server_args</tag>detta fältet utgör resten av raden och är valfri. Det är
här som man placerar kommandoradsargument som man vill skicka med till 
serverdaemonen när den startas.
</descrip>

<sect3>Ett exempel på en <tt>/etc/inetd.conf</tt> fil.
<p>
Som för filen <tt>/etc/services</tt> så inkluderar alla moderna distributioner
en bra <tt>/etc/inetd.conf</tt> fil som man kan arbeta med. För att vara 
komplett så inkluderas <tt>/etc/inetd.conf</tt> från
<url url="http://www.debian.org/" name="Debian"> distributionen.

<tscreen><verb>
# /etc/inetd.conf:  see inetd(8) for further informations.
#
# Internet server configuration database
#
#
# Modified for Debian by Peter Tobias <tobias@et-inf.fho-emden.de>
#
# <service_name> <sock_type> <proto> <flags> <user> <server_path> <args>
#
# Internal services
#
#echo		stream	tcp	nowait	root	internal
#echo		dgram	udp	wait	root	internal
discard		stream	tcp	nowait	root	internal
discard		dgram	udp	wait	root	internal
daytime		stream	tcp	nowait	root	internal
daytime		dgram	udp	wait	root	internal
#chargen	stream	tcp	nowait	root	internal
#chargen	dgram	udp	wait	root	internal
time		stream	tcp	nowait	root	internal
time		dgram	udp	wait	root	internal
#
# These are standard services.
#
telnet	stream	tcp	nowait	root	/usr/sbin/tcpd	/usr/sbin/in.telnetd
ftp	stream	tcp	nowait	root	/usr/sbin/tcpd	/usr/sbin/in.ftpd
#fsp	dgram	udp	wait	root	/usr/sbin/tcpd	/usr/sbin/in.fspd
#
# Shell, login, exec and talk are BSD protocols.
#
shell	stream	tcp	nowait	root	/usr/sbin/tcpd	/usr/sbin/in.rshd
login	stream	tcp	nowait	root	/usr/sbin/tcpd	/usr/sbin/in.rlogind
#exec	stream	tcp	nowait	root	/usr/sbin/tcpd	/usr/sbin/in.rexecd
talk	dgram	udp	wait	root	/usr/sbin/tcpd	/usr/sbin/in.talkd
ntalk	dgram	udp	wait	root	/usr/sbin/tcpd	/usr/sbin/in.ntalkd
#
# Mail, news and uucp services.
#
smtp	stream	tcp	nowait	root	/usr/sbin/tcpd	/usr/sbin/in.smtpd  
#nntp	stream	tcp	nowait	news	/usr/sbin/tcpd	/usr/sbin/in.nntpd
#uucp	stream	tcp	nowait	uucp	/usr/sbin/tcpd	/usr/lib/uucp/uucico
#comsat	dgram	udp	wait	root	/usr/sbin/tcpd	/usr/sbin/in.comsat
#
# Pop et al
#
#pop-2	stream	tcp	nowait	root	/usr/sbin/tcpd	/usr/sbin/in.pop2d
#pop-3	stream	tcp	nowait	root	/usr/sbin/tcpd	/usr/sbin/in.pop3d
#
# `cfinger' is for the GNU finger server available for Debian.  (NOTE: The
# current implementation of the `finger' daemon allows it to be run as `root'.)
#
#cfinger stream	tcp	nowait	root	/usr/sbin/tcpd	/usr/sbin/in.cfingerd
#finger	stream	tcp	nowait	root	/usr/sbin/tcpd	/usr/sbin/in.fingerd
#netstat	stream	tcp	nowait	nobody	/usr/sbin/tcpd	/bin/netstat
#systat	stream	tcp	nowait	nobody	/usr/sbin/tcpd	/bin/ps -auwwx
#
# Tftp service is provided primarily for booting.  Most sites
# run this only on machines acting as "boot servers."
#
#tftp	dgram	udp	wait	nobody	/usr/sbin/tcpd	/usr/sbin/in.tftpd
#tftp	dgram	udp	wait	nobody	/usr/sbin/tcpd	/usr/sbin/in.tftpd /boot
#bootps	dgram	udp	wait	root	/usr/sbin/bootpd	bootpd -i -t 120
#
# Kerberos authenticated services (these probably need to be corrected)
#
#klogin		stream	tcp	nowait	root	/usr/sbin/tcpd	/usr/sbin/in.rlogind -k
#eklogin	stream	tcp	nowait	root	/usr/sbin/tcpd	/usr/sbin/in.rlogind -k -x
#kshell		stream	tcp	nowait	root	/usr/sbin/tcpd	/usr/sbin/in.rshd -k
#
# Services run ONLY on the Kerberos server (these probably need to be corrected)
#
#krbupdate	stream tcp	nowait	root	/usr/sbin/tcpd	/usr/sbin/registerd
#kpasswd	stream	tcp	nowait	root	/usr/sbin/tcpd	/usr/sbin/kpasswdd
#
# RPC based services
#
#mountd/1	dgram	rpc/udp	wait	root	/usr/sbin/tcpd	/usr/sbin/rpc.mountd
#rstatd/1-3	dgram	rpc/udp	wait	root	/usr/sbin/tcpd	/usr/sbin/rpc.rstatd
#rusersd/2-3	dgram	rpc/udp	wait	root	/usr/sbin/tcpd	/usr/sbin/rpc.rusersd
#walld/1	dgram	rpc/udp	wait	root	/usr/sbin/tcpd	/usr/sbin/rpc.rwalld
#
# End of inetd.conf.
ident		stream	tcp	nowait	nobody	/usr/sbin/identd	identd -i
</verb></tscreen>

<sect1><heading>Andra nätverksrelaterade konfigurationsfiler.
<p>
Det finns ett antal andra filer som är relaterade till nätverkskonfiguration i
Linux som man skulle kunna vara intresserad av. Man behöver kanske aldrig 
modifiera dessa filer, men det är värt att beskriva dem ändå så att man vet vad
de innehåller och vad de används till.

<sect2><heading><tt>/etc/protocols</tt>
<p>
Filen <tt>/etc/protocols</tt> är en databas som mappar protokollens id-nummer
mot protokollens namn. Detta används av programmerare för att låta dem ange
protokoll med dess namn i program, och även av vissa program, som till
exempel <em>tcpdump</em>, för att kunna skriva ut namn istället för nummer.
Syntaxen för filen är:
<tscreen><verb>
protocolname  number  aliases
</verb></tscreen>
I <url url="http://www.debian.org/" name="Debian"> distributionen ser 
<tt>/etc/protocols</tt> ut som följande:
<tscreen><verb>
# /etc/protocols:
# $Id: protocols,v 1.1 1995/02/24 01:09:41 imurdock Exp $
#
# Internet (IP) protocols
#
#	from: @(#)protocols	5.1 (Berkeley) 4/17/89
#
# Updated for NetBSD based on RFC 1340, Assigned Numbers (July 1992).

ip	0	IP		# internet protocol, pseudo protocol number
icmp	1	ICMP		# internet control message protocol
igmp	2	IGMP		# Internet Group Management
ggp	3	GGP		# gateway-gateway protocol
ipencap	4	IP-ENCAP	# IP encapsulated in IP (officially ``IP'')
st	5	ST		# ST datagram mode
tcp	6	TCP		# transmission control protocol
egp	8	EGP		# exterior gateway protocol
pup	12	PUP		# PARC universal packet protocol
udp	17	UDP		# user datagram protocol
hmp	20	HMP		# host monitoring protocol
xns-idp	22	XNS-IDP		# Xerox NS IDP
rdp	27	RDP		# "reliable datagram" protocol
iso-tp4	29	ISO-TP4		# ISO Transport Protocol class 4
xtp	36	XTP		# Xpress Tranfer Protocol
ddp	37	DDP		# Datagram Delivery Protocol
idpr-cmtp	39	IDPR-CMTP	# IDPR Control Message Transport
rspf	73	RSPF		# Radio Shortest Path First.
vmtp	81	VMTP		# Versatile Message Transport
ospf	89	OSPFIGP		# Open Shortest Path First IGP
ipip	94	IPIP		# Yet Another IP encapsulation
encap	98	ENCAP		# Yet Another IP encapsulation
</verb></tscreen>

<sect2><heading><tt>/etc/networks</tt>
<p>
Filen <tt>/etc/networks</tt> har en liknande funktion som filen 
<tt>/etc/hosts</tt>. Den tillhandahåller en enkel databas av nätverksnamn som
mappas mot nätverksadresser. Dess format skiljer sig genom att det får endast 
finnas två fält per rad och att fälten skrivs som:

<tscreen><verb>
networkname networkaddress
</verb></tscreen>

Ett exempel kam se ut såhär:
<tscreen><verb>
loopnet    127.0.0.0
localnet   192.168.0.0
amprnet    44.0.0.0
</verb></tscreen>

När man använder kommandon som <em>route</em>, om en destination är ett nätverk
och det nätverket finns i <tt>/etc/networks</tt>, så kommer <em>route</em> att
visa nätverksnamnet istället för dess adress.

<sect1><heading>Nätverkssäkerhet och åtkomstkontroll.
<p>
Låt mig börja denna sektion med att varna för att säkra en maskin och ett
nätverk mot illvilliga attacker är en komplex konst. Jag anser mig inte själv 
vara en expert på detta område och även om de följande mekanismerna som jag
beskriver kommer att hjälpa, så om man är riktigt allvarlig när det gäller 
säkerhet så rekommenderar jag att man gör egna undersökningar i ämnet. Det finns
många bra referenser på Internet relaterade till detta ämne.
<p>
En viktig tumregel är:
       `<bf>Kör inte servrar som inte skall användas</bf>'.
Många distributioner kommer konfigurerade med alla möjliga tjänster som startas
automatiskt. För att säkerställa en miniminivå av säkerhet så bör man gå igenom
sin <tt>/etc/inetd.conf</tt> och kommentera bort (<em>sätt ett '#' i början
av raden</em>) alla rader som innehåller tjänster vilka man inte tänker använda.
Bra kandidater är tjänster såsom: <tt/shell/, <tt/login/, <tt/exec/, <tt/uucp/,
<tt/ftp/ och informativa tjänster som <tt/finger/, <tt/netstat/ och <tt/systat/.
<p>
Det finns alla möjliga sorters säkerhets- och åtkomstkontrollmekanismer, jag 
kommer att beskriva de mest elementära av dem.

<sect2><heading>/etc/ftpusers
<p>
Filen <tt>/etc/ftpusers</tt> är en enkel mekanism med vilken man kan vägra vissa 
användare att logga in till maskinen via ftp. Filen <tt>/etc/ftpusers</tt>
läses av ftp-daemonen (<em/ftpd/) när en inkommande ftp-anslutning tas emot.
Filen är en enkel lista av de användare som inte är tillåtna att logga in. Den
skulle kunna se ut som:
<tscreen><verb>
# /etc/ftpusers - users not allowed to login via ftp
root
uucp
bin
mail
</verb></tscreen>

<sect2><heading>/etc/securetty
<p>
I filen <tt>/etc/securetty</tt> kan man specificera vilka <tt/tty/ enheter som 
<tt/root/ är tillåten att logga in på. Filen <tt>/etc/securetty</tt> läses av
loginprogrammet (vanligtvis <em>/bin/login</em>). Dess format är en lista av
de tty enhetsnamn som är tillåtna, på alla andra är <tt/root/ login otillåten:
<tscreen><verb>
# /etc/securetty - tty's on which root is allowed to login
tty1
tty2
tty3
tty4
</verb></tscreen>

<sect2><heading><em>tcpd</em> åtkomstkontrollmekanism.
<p>
Programmet <em>tcpd</em> som man sett listat i <tt>/etc/inetd.conf</tt> 
tillhandahåller loggning och åtkomstkontrollmekanismer för tjänster som det är
konfigurerat att skydda.
<p>
När det aktiveras av programmet <em>inetd</em> så läser det två filer som 
innehåller åtkomstregler och antingen tillåter det eller nekar åtkomst till
servern som det skyddar.
<p>
Programmet söker i reglerna tills dess att det hittar det första mönstret som
passar. Hittar det inget passande mönster så antas det att åtkomst skall
tillåtas till vem som helst. Filerna som söks igenom i sekvens är: 
<tt>/etc/hosts.allow</tt>, <tt>/etc/hosts.deny</tt>. Jag kommer att beskriva 
dem i ordning. För en komplett beskrivning av detta så bör man titta i lämpliga
<em>manualblad</em> (<tt>hosts_access(5)</tt> är ett bra ställe att börja på).

<sect3><heading>/etc/hosts.allow
<p>
Filen <tt>/etc/hosts.allow</tt> är en konfigurationsfil för programmet 
<em>/usr/sbin/tcpd</em>. Filen innehåller regler som beskriver vilka datorer 
som är <em>tillåtna</em> åtkomst till en tjänst på maskinen.
<p>
Filformatet är ganska enkelt:
<tscreen><verb>
# /etc/hosts.allow
#
# <service list>: <host list> [: command]
</verb></tscreen>

<descrip>
<tag><tt/service list/</tag>är en kommaseparerad lista av servernamn som denna
regeln gäller för. Exempel: <tt/ftpd/, <tt/telnetd/ och <tt/fingerd/.
<p><tag><tt/host list/</tag>är en kommaseparerad lista av datornamn. Man kan 
även använda IP-adresser. Man kan dessutom ange datornamn eller adresser med
hjälp av 'wildcards' för att täcka grupper av datorer. Exempel: <tt/gw.vk2ktj.ampr.org/ för att täcka en enskild dator, <tt>.uts.edu.au</tt> för att täcka 
alla datornamn som slutar med den strängen, <tt>44.</tt> för att täcka alla
IP-adresser som börjar med de siffrorna. Det finns några särskilda tokens för
att förenkla konfigurationen, några av dessa är: <tt/ALL/ täcker alla datorer, 
<tt/LOCAL/ täcker alla datornamn som inte innehåller en '<tt/./' dvs som är i
samma domän som din maskin och <tt/PARANOID/ täcker alla datorer vars namn inte
stämmer överens med sin adress (name spoofing). Det finns en sista användbar 
token. <tt/EXCEPT/ tillåter dig att ange en lista med undantag. Detta visas i 
ett exempel senare.
<p><tag><tt/command/</tag>är en valfri parameter. Detta är det absoluta
filnamnet för ett kommando som skall exekveras varje gång denna regel används.
Det skulle till exempel kunna köra ett program som försöker identifiera vem som
är påloggad på den anslutande datorn, eller att generera ett mail eller någon
annan varning till en systemadministratör att någon försöker ansluta. Det finns
ett antal utökningar som kan inkluderas, till exempel: <tt/%h/ expanderar till
namnet på den anslutande datorn eller adress om den inte har något namn, 
<tt/%d/ daemonnamnet anropas.
</descrip>
<p>
Ett exempel:
<tscreen><verb>
# /etc/hosts.allow
#
# Allow mail to anyone
in.smtpd: ALL
# All telnet and ftp to only hosts within my domain and my host at home.
telnetd, ftpd: LOCAL, myhost.athome.org.au
# Allow finger to anyone but keep a record of who they are.
fingerd: ALL: (finger @%h | mail -s "finger from %h" root)
</verb></tscreen>

<sect3><heading>/etc/hosts.deny
<p>
Filen <tt>/etc/hosts.deny</tt> är en konfigurationsfil för programmet 
<em>/usr/sbin/tcpd</em>. Filen innehåller regler som beskriver vilka datorer 
som är <em>nekade</em> åtkomst till en tjänst på maskinen.
<p>
Ett enkelt exempel:

<tscreen><verb>
# /etc/hosts.deny
#
# Disallow all hosts with suspect hostnames
ALL: PARANOID
#
# Disallow all hosts.
ALL: ALL
</verb></tscreen>

Raden med <tt>PARANOID</tt> är egentligen redundant eftersom den andra raden
fäller allt i vilket fall. Någon av dessa rader skulle vara tänkbara beroende
på vilka krav man har.
<p>
Att ha <tt>ALL: ALL</tt> i <tt>/etc/hosts.deny</tt> och sedan specifikt ange de
tjänster och datorer som man vill ha i filen <tt>/etc/hosts.allow</tt> är den 
säkraste konfigurationen.

<sect2><heading>/etc/hosts.equiv
<p>
Filen <tt/hosts.equiv/ används för att ge vissa datorer och användare 
åtkomsträttigheter till konton på maskinen utan att behöva ange ett lösenord.
Detta är användbart i en säker omgivning där man kontrollerar alla maskinerna, 
men det är en säkerhetsrisk i annat fall. Datorn är bara så säker som den
minst säkra av de datorer man litar på. För att maximera säkerheten så bör man
inte använda denna mekanismen och påverka sina användare att inte använda filen
<tt/.rhosts/ heller.

<sect2><heading> Konfigurera <em/ftp/-daemonen ordentligt.
<p>
Många sajter är intresserade av att köra en anonym <em/ftp/ server för att 
tillåta andra personer att ladda upp och ladda ner filer utan att ha ett 
särskilt användarid. Om man bestämmer sig för att tillhandahålla denna tjänst så
skall man se till att man konfigurerar sin <em/ftp/-daemon ordentligt för anonym åtkomst.
De flesta <em/manualblad/ för <tt>ftpd(8)</tt> beskriver hur man skall göra 
detta. Man bör alltid försäkra sig om att man följer dessa instruktioner. Ett 
viktigt tips är att inte använda en kopia av sin <tt>/etc/passwd</tt> fil i 
<tt>/etc</tt> katalogen för det anonyma kontot, se till att man tar bort alla
detaljer om konton som man inte måste ha, annars kommer man att vara sårbar mot
tekniker för lösenordscracking.

<sect2><heading>Brandväggar.
<p>
Att inte tillåta datagram att ens nå fram till din maskin eller servrar är ett
utmärkt sätt att säkra systemet. Detta beskrivs i 
<url url="Firewall-HOWTO.html" name="Firewall-HOWTO">.

<sect2><heading>Andra förslag.
<p>
Här är några andra, potentiellt religiösa förslag som man kan tänka på.
<descrip>
<tag>sendmail</tag>oavsett dess popularitet så framträder <em/sendmail/ 
daemonen med skrämmande jämna mellanrum på säkerhetsmeddelanden. Det är upp 
till en själv om man väljer att köra den.
<p><tag>NFS och andra Sun RPC tjänster</tag>man bör vara aktsam med dessa. Det finns
alla möjliga olika sätt att utnyttja dessa tjänster. Det är svårt att hitta
alternativ till en tjänst som NFS, men om man konfigurerar dem så skall man se till att
vara försiktig med vem man ger mount-rättigheter till.
</descrip>

<sect><heading>Nätverksspecifik Information.
<p>
Följande delsektioner är specifika för vissa nätverkstekniker. Informationen
i dessa sektioner gäller inte nödvändigtvis för någon annan nätverksteknik.

<sect1><heading>ARCNet
<p>
Enhetsnamn för ARCNet är `<tt/arc0e/', `<tt/arc1e/', `<tt/arc2e/' osv eller
`<tt/arc0s/', `<tt/arc1s/', `<tt/arc2s/' osv. Det första kortet som hittas av
kärnan tilldelas `<tt/arc0e/' eller `<tt/arc0s/' och resten tilldelas namn
sekvensiellt i den ordning som de hittas. Bokstaven på slutet av namnet 
betecknar om man har valt Ethenet-inkapsling som paketformat eller RFC1051 som
paketformat.
<p>
<bf/Kompileringsalternativ för Kärnan/:
<tscreen><verb>
Network device support  --->
    [*] Network device support
    <*> ARCnet support
    [ ]   Enable arc0e (ARCnet "Ether-Encap" packet format)
    [ ]   Enable arc0s (ARCnet RFC1051 packet format)
</verb></tscreen>
<p>
När man väl har en kärna som stöder sitt Ethernetkort så är konfiguration
av kortet lätt.
<p>
Man skulle kunna använda något som liknar:<tscreen><verb>
# ifconfig arc0e 192.168.0.1 netmask 255.255.255.0 up
# route add -net 192.168.0.0 netmask 255.255.255.0 arc0e
</verb></tscreen>
Titta gärna i filerna
<tt>/usr/src/linux/Documentation/networking/arcnet.txt</tt> och
<tt>/usr/src/linux/Documentation/networking/arcnet-hardware.txt</tt> för mer
information.
<p>
ARCNet-stöd utvecklades av Avery Pennarun, <tt/apenwarr@foxnet.net/.

<sect1><heading>Appletalk (<tt/AF_APPLETALK/)
<p>
Appletalk har inga särskilda enhetsnamn eftersom det använder existerande
nätverksenheter.
<p>
<bf/Kompileringsalternativ för Kärnan/:
<tscreen><verb>
Networking options  --->
    <*> Appletalk DDP
</verb></tscreen>
Appletalk-stöd gör det möjligt för Linuxburken att kommunicera med 
Apple-nätverk. Ett viktigt användningsområde för detta är möjligheten att kunna
dela resurser, som till exempel skrivare och hårddiskar, mellan Linux- och 
Appledatorer. Man behöver ytterligare programvara, <em/netatalk/, för detta.
Wesley Craig, <tt/netatalk@umich.edu/, representerar en grupp som heter
`Research Systems Unix Group' på University of Michigan och de har utvecklat
<em/netatalk/-paketet som tillhandahåller programvara som implementerar
protokollstacken för Appletalk och några andra användbara verktyg.
Paketet <em/netatalk/ finns antingen med i Linuxditributionen, eller så kan 
man ladda hem det via ftp från 
<url url="ftp://terminator.rs.itd.umich.edu/unix/netatalk/"
	name="University of Michigan">
<p>
För att kompilera och installera paketet gör man ungefär så här:
<tscreen><verb>
# cd /usr/src
# tar xvfz .../netatalk-1.4b2.tar.Z
- You may want to edit the `Makefile' at this point, specifically to change
  the DESTDIR variable which defines where the files will be installed later.
  The default of /usr/local/atalk is fairly safe.
# make
- as root:
# make install
</verb></tscreen>

<sect2><heading>Att konfigurera mjukvaran för Appletalk.
<p>
Det första man måste göra för att få det att fungera är att se till att de rätta
raderna finns med i filen <tt>/etc/services</tt>. Raderna man behöver är:<tscreen><verb>
rtmp	1/ddp	# Routing Table Maintenance Protocol
nbp	2/ddp	# Name Binding Protocol
echo	4/ddp	# AppleTalk Echo Protocol
zip	6/ddp	# Zone Information Protocol
</verb></tscreen>

Nästa steg är att skapa konfigurationsfiler för Appletalk i katalogen
<tt>/usr/local/atalk/etc</tt> (eller var man nu installerade paketet).
<p>
Den första filen som behövs är <tt>/usr/local/atalk/etc/atalkd.conf</tt>. Till
en början behöver denna fil endast en rad som anger namnet på den 
nätverksenhet som är kopplad nätverket där Applemaskinerna finns:

<tscreen><verb>
eth0
</verb></tscreen>

Daemonen för Appletalk kommer att lägga dit fler detaljer när den körs.

<sect2><heading>Att exportera ett Linuxfilsystem via Appletalk.
<p>
Man kan exportera filsystem från sin Linuxburk till nätverket så att 
Applemaskinerna på nätverket kan använda dem.
<p>
För att göra detta så behöver man konfigurera filen 
<tt>/usr/local/atalk/etc/AppleVolumes.system</tt>. Det finns ytterligare en 
konfigurationsfil som heter <tt>/usr/local/atalk/etc/AppleVolumes.default</tt>
som har precis samma format och beskriver vilka filsystem som kan användas av
användare som ansluter med gäst-rättigheter.
<p>
Alla detaljer om hur man konfigurerar dessa finns i manualbladet för 
<em>afpd</em>.
<p>
Ett enkelt exempel:
<tscreen><verb>
/tmp Scratch
/home/ftp/pub "Public Area"
</verb></tscreen>

Detta skulle exportera <tt>/tmp</tt>-filsystemet som en AppleShare-volym
`Scratch' och <tt>/home/ftp/pub</tt>-katalogen som en AppleShare-volym 
`Public Area'. Volymnamnen är inte obligatoriska, daemonen väljer namn om man
inte anger dem, men det skadar inte att ange dem ändå.

<sect2><heading>Att dela sin skrivare via Appletalk.
<p>
Man kan dela sin Linuxskrivare med sina Applemaskiner ganska enkelt. Man behöver
köra programmet <em>papd</em> (Appletalk Printer Access Protocol Daemon). När
man kör detta program så tar det emot förfrågningar från Applemaskinerna
och spoolar utskriftsjobben till den lokala line-printer daemonen.
<p>
Man behöver ändra filen <tt>/usr/local/atalk/etc/papd.conf</tt> för att 
konfigurera daemonen. Syntaxen för denna fil är densamma som för den vanliga
<tt>/etc/printcap</tt> filen. Namnet som man ger till definitionen registreras med
Appletalks namnsättningsprotokoll, NBP.
<p>
En exempelkonfiguration kan se ut så här:

<tscreen><verb>
TricWriter:\
   :pr=lp:op=cg:
</verb></tscreen>

Vilken skulle skapa en printer som kallas för `TricWriter' som blir tillgänglig
för Appletalknätverket och alla accepterade jobb skulle skrivas ut på
Linuxskrivaren `<tt/lp/' (som den definieras i filen <tt>/etc/printcap</tt>) 
genom att använda <em>lpd</em>. Uttrycket `<tt/op=cg/' talar om att 
Linux-användaren `<tt/cg/' är ansvarig för skrivaren.

<sect2><heading>Att starta programvaran för Appletalk.
<p>
Nu bör man var redo att testa denna enkla konfiguration. Det finns en fil
<em>rc.atalk</em> som följer med paketet <em>netatalk</em> som borde fungera
för de flesta, så allt man behöver göra är följande:

<tscreen><verb>
# /usr/local/atalk/etc/rc.atalk
</verb></tscreen>

och allt borde startas och fungera. Man skall inte se några felmeddelanden och 
programvaran kommer att skicka meddelanden till konsolen som indikerar varje
steg som startas.

<sect2><heading>Att testa programvaran för Appletalk.
<p>
För att testa att mjukvaran fungerar som den skall, så går man till en av sina 
Applemaskiner, tar ner äpplemenyn, väljer Väljaren (Chooser), klickar på 
AppleShare, och Linuxburken bör synas.

<sect2><heading>Brister i programvaran för Appletalk.
<p>
<itemize>
<item>Man kanske måste starta Appletalk-stödet innan man konfigurerar sitt
IP-nätverk. Om man har problem med att starta Appletalkprogrammen, eller om man,
efter att ha startat dem, har problem med sitt IP-nätverk, så försöker man med att
starta Appletalk innan man kör sin <tt>/etc/rc.d/rc.inet1</tt> fil.
<item>Daemonen <em>afpd</em> (Apple Filing Protocol Daemon) stökar till
ordentligt i filsystemet. Under mount-punkterna så skapar den ett par 
kataloger som heter <tt>.AppleDesktop</tt> och <tt>Network Trash Folder</tt>.
Sedan för varje katalog som man besöker så kommer den att skapa en 
<tt>.AppleDouble</tt> under dem så att den kan spara diverse information. Så man bör
tänka efter innan man exporterar <tt>/</tt>, man kommer att ha det skoj när man
städar upp efteråt.
<item>Daemonen <em>afpd</em> förväntar sig lösenord i klartext från Macarna.
Säkerhet kan vara ett problem, så man skall vara försiktig när man kör denna daemonen på 
en dator som är ansluten till Internet, man har sig själv att skylla om någon
elak person gör någon skada.
<item>Existerande diagnostiseringsverktyg som <em>netstat</em> och 
<em>ifconfig</em> stöder inte Appletalk. Rå information är tillgänglig i
katalogen <tt>/proc/net/</tt> om man behöver den. 
</itemize>

<sect2>Mer information.
<p>
En mycket mer detaljerad information om hur man konfigurerar Appletalk för
Linux finns i Anders Brownworths <em/Linux Netatalk-HOWTO/ sida på
<url url="http://thehamptons.com/anders/netatalk/"
	name="thehamptons.com">.


<sect1><heading>ATM
<p>
Werner Almesberger <tt>&lt;werner.almesberger@lrc.di.epfl.ch&gt;</tt> håller i
ett projekt för att skapa stöd för Asynchronous Transfer Mode i Linux.
Uppdaterad information om statusen för projektet kan fås från 
<url url="http://lrcwww.epfl.ch/linux-atm/"
	name="lrcwww.epfl.ch">.

<sect1><heading>AX25 (<tt/AF_AX25/)
<p>
Enhetsnamn för AX.25 är `<tt/sl0/', `<tt/sl1/', osv i <tt/2.0.*/ kärnor eller
`<tt/ax0/', `<tt/ax1/', osv i <tt/2.1.*/ kärnor.
<p>
<bf/Kompileringsalternativ för Kärnan/:
<tscreen><verb>
Networking options  --->
    [*] Amateur Radio AX.25 Level 2
</verb></tscreen>
AX25, Netrom och Rose protokollen täcks av 
<url url="AX25-HOWTO.html" name="AX25-HOWTO">.
Dessa protokoll används av Amatörradio-operatörer i hela världen för paketradio
experiment.
<p>
Det mesta arbetet för att implementera protokollen har utförts av 
Jonathon Naylor, <tt/jsn@cs.nott.ac.uk/.

<sect1><heading>DECNet
<p>
Stöd för DECNet håller för tillfället på att utvecklas. Man kan räkna med att
det dyker upp i sena <tt/2.1.*/ kärnor.

<sect1><heading>EQL - trafikutjämnare för multipla linor.
<p>
Enhetsnamnet för EQL är `<tt/eql/'. Med standardkärnan kan man endast ha en
EQL-enhet per maskin. EQL tillhandahåller hjälpmedel för att använda multipla
punkt till punkt förbindelser (tex PPP, SLIP eller PLIP) som en ensam logisk
länk för att bära TCP/IP. Ofta är det billigare att använda flera linor med
lägre hastighet än att ha en höghastighetslina installerad.
<p>
<bf/Kompileringsalternativ för Kärnan/:
<tscreen><verb>
Network device support  --->
    [*] Network device support
    <*> EQL (serial line load balancing) support
</verb></tscreen>
<p>
För att stödja denna mekanism så måste maskinen på andra sidan av linorna
också stödja EQL. Linux, Livingstone Portmasters och nyare dial-in servrar
stöder kompatibla tjänster.
<p>
För att konfigurera EQL behöver man eql-verktygen som finns på:
<url url="ftp://sunsite.unc.edu/pub/linux/system/Serial/eql-1.2.tar.gz"
	name="sunsite.unc.edu">.
<p>
Konfigurationen är hyfsat okomplicerad. Man börjar med att konfigurera 
eql-gränssnittet. Eql-gränssnittet är precis som alla andra nätverksgränssnitt.
Man kan konfigurera IP-adressen och MTU genom att använda <em/ifconfig/, så
ungefär som:
<tscreen><verb>
ifconfig eql 192.168.10.1 mtu 1006
</verb></tscreen>
<p>
Sedan behöver man manuellt initiera var och en av linorna som man skall använda. 
Dessa kan vara en valfri kombination av punkt till punkt förbindelser. Hur
man initierar de anslutningarna beror på vilken typ av länkar de är, se
passande sektioner för mer information.
<p>
Till sist skall man associera den seriella länken med EQL-enheten, detta kallas
för `enslaving' och görs med kommandot <em/eql_enslave/:
<tscreen><verb>
eql_enslave eql sl0 28800
eql_enslave eql ppp0 14400
</verb></tscreen>
Parametern `<em>estimated speed</em>' som man ger till <em/eql_enslave/ gör 
ingen direkt nytta. Den används av EQL-drivrutinen för att avgöra hur stor del
av datagrammen som den enheten skall få ta emot, så man kan finjustera balansen
hos linorna genom att ändra på detta värde.
<p>
För att disassociera en lina från en EQL-enhet så använder man kommandot
<em/eql_emancipate/:
<tscreen><verb>
eql_emancipate eql sl0
</verb></tscreen>
<p>
Man lägger till routing som om det vore en normal punkt till punkt förbindelse, 
förutom att router skall referera till <tt/eql/ enheten istället för de 
verkliga seriella enheterna:
<tscreen><verb>
route add default eql
</verb></tscreen>
<p>
EQL-drivrutinen utvecklades av Simon Janes, <tt/simon@ncm.com/.

<sect1><heading>Ethernet
<p>
Enhetsnamn för Ethernet är `<tt/eth0/', `<tt/eth1/', `<tt/eth2/' osv. Det 
första kortet som hittas får namnet `<tt/eth0/' och resten tilldelas namn 
sekvensiellt i den ordning som de hittas.
<p>
För att ta reda på hur man får sitt Ethernet-kort att fungera i Linux så bör man
titta i <url url="Ethernet-HOWTO.html" name="Ethernet-HOWTO">.
<p>
När man väl har en kärna som stöder sitt Ethernet-kort så är det enkelt att
konfigurera kortet.
<p>
Vanligtvis så används ungefär följande:
<tscreen><verb>
# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up
# route add -net 192.168.0.0 netmask 255.255.255.0 eth0
</verb></tscreen>
<p>
De flesta drivrutinerna för Ethernet utvecklades av Donald Becker,
<tt/becker@CESDIS.gsfc.nasa.gov/.

<sect1><heading>FDDI
<p>
Enhetsnamnen för FDDI är `<tt/fddi0/', `<tt/fddi1/', `<tt/fddi2/' osv. Det 
första kortet som hittas får namnet `<tt/fddi0/' och resten tilldelas namn 
sekvensiellt i den ordning som de hittas.
<p>
Larry Stefani, <tt/lstefani@ultranet.com/, har utvecklat en drivrutin för 
EISA och PCI FDDI-kort från Digital Equipment Corporation.
<p>
<bf/Kompileringsalternativ för Kärnan/:
<tscreen><verb>
Network device support  --->
    [*] FDDI driver support
    [*] Digital DEFEA and DEFPA adapter support
</verb></tscreen>
När man väl har en kärna som stöder sitt FDDI-kort, så konfigureras 
FDDI-kortet nästan likadant som Ethernet-kortet. Man behöver bara ange lämpliga
FDDI-enhetsnamn till kommandona <em/ifconfig/ och <em/route/.

<sect1><heading>Frame Relay
<p>
Enhetsnamnen för Frame Relay är `<tt/dlci00/', `<tt/dlci01/' osv för DLCI 
inkapslingsenheter och `<tt/sdla0/', `<tt/sdla1/' osv för FRAD(s).
<p>
Frame Relay är en ny teknik att bygga nätverk och är designad att passa
datakommunikation vars trafik är av oregelbunden karaktär. Man ansluter till
ett Frame Realay nätverk genom att använda en Frame Relay Access Device (FRAD).
Linux Frame Relay stödjer IP över Frame Relay så som det beskrivs i RFC1490.
<p>
<bf/Kompileringsalternativ för Kärnan/:
<tscreen><verb>
Network device support  --->
    <*> Frame relay DLCI support (EXPERIMENTAL)
    (24)   Max open DLCI
    (8)   Max DLCI per device
    <*>   SDLA (Sangoma S502/S508) support
</verb></tscreen>
<p>
Mike McLagan, <tt/mike.mclagan@linux.org/, utvecklade stödet och 
konfigurationsverktygen för Frame Relay.
<p>
För närvarande är de FRADs som stöds följande: 
<url url="http://www.sangoma.com/" name="Sangoma Technologies">
<tt/S502A/, <tt/S502E/ och <tt/S508/.
<p>
För att konfigurera FRAD och DLCI enheter efter det att man har kompilerat om 
sin kärna så behöver man konfigurationsverktygen för Frame Relay. Dessa finns
på: <url url="ftp://ftp.invlogic.com/pub/linux/fr/frad-0.15.tgz" 
         name="ftp.invlogic.com">.
Det är okomplicerat att kompilera och installera verktygen, men avsaknaden av 
en toppnivå-Makefile gör det till en manuell process:
<tscreen><verb>
# cd /usr/src
# tar xvfz .../frad-0.15.tgz
# cd frad-0.15
# for i in common dlci frad; make -C $i clean; make -C $i; done
# mkdir /etc/frad
# install -m 644 -o root -g root bin/*.sfm /etc/frad
# install -m 700 -o root -g root frad/fradcfg /sbin
# install -m 700 -o root -g root dlci/dlcicfg /sbin
</verb></tscreen>
Efter att man har installerat verktygen skall man skapa en fil som heter
<tt>/etc/frad/router.conf</tt>. Man kan använda följande mall, som är en 
modifierad version av en exempelfil:
<tscreen><verb>
# /etc/frad/router.conf
# This is a template configuration for frame relay.
# All tags are included. The default values are based on the code
# supplied with the DOS drivers for the Sangoma S502A card.
#
# A '#' anywhere in a line constitutes a comment
# Blanks are ignored (you can indent with tabs too)
# Unknown [] entries and unknown keys are ignored
#

[Devices]
Count=1                 # number of devices to configure
Dev_1=sdla0             # the name of a device
#Dev_2=sdla1            # the name of a device

# Specified here, these are applied to all devices and can be overriden for 
# each individual board.
#
Access=CPE
Clock=Internal
KBaud=64
Flags=TX
#
# MTU=1500              # Maximum transmit IFrame length, default is 4096
# T391=10               # T391 value    5 - 30, default is 10
# T392=15               # T392 value    5 - 30, default is 15
# N391=6                # N391 value    1 - 255, default is 6
# N392=3                # N392 value    1 - 10, default is 3
# N393=4                # N393 value    1 - 10, default is 4

# Specified here, these set the defaults for all boards
# CIRfwd=16             # CIR forward   1 - 64
# Bc_fwd=16             # Bc forward    1 - 512 
# Be_fwd=0              # Be forward    0 - 511
# CIRbak=16             # CIR backward  1 - 64
# Bc_bak=16             # Bc backward   1 - 512
# Be_bak=0              # Be backward   0 - 511


#
#
# Device specific configuration
#
#

#
# The first device is a Sangoma S502E
#
[sdla0]
Type=Sangoma            # Type of the device to configure, currently only 
                        # SANGOMA is recognised
#
# These keys are specific to the 'Sangoma' type
#
# The type of Sangoma board - S502A, S502E, S508
Board=S502E
#
# The name of the test firmware for the Sangoma board
# Testware=/usr/src/frad-0.10/bin/sdla_tst.502
#
# The name of the FR firmware
# Firmware=/usr/src/frad-0.10/bin/frm_rel.502
#
Port=360                # Port for this particular card
Mem=C8                  # Address of memory window, A0-EE, depending on card
IRQ=5                   # IRQ number, do not supply for S502A
DLCIs=1                 # Number of DLCI's attached to this device
DLCI_1=16               # DLCI #1's number, 16 - 991
# DLCI_2=17
# DLCI_3=18
# DLCI_4=19
# DLCI_5=20
#
# Specified here, these apply to this device only, 
# and override defaults from above
#
# Access=CPE            # CPE or NODE, default is CPE 
# Flags=TXIgnore,RXIgnore,BufferFrames,DropAborted,Stats,MCI,AutoDLCI
# Clock=Internal        # External or Internal, default is Internal
# Baud=128              # Specified baud rate of attached CSU/DSU
# MTU=2048              # Maximum transmit IFrame length, default is 4096
# T391=10               # T391 value    5 - 30, default is 10
# T392=15               # T392 value    5 - 30, default is 15
# N391=6                # N391 value    1 - 255, default is 6
# N392=3                # N392 value    1 - 10, default is 3
# N393=4                # N393 value    1 - 10, default is 4

#
# The second device is some other card
#
# [sdla1]
# Type=FancyCard        # Type of the device to configure.
# Board=                # Type of Sangoma board
# Key=Value             # values specific to this type of device


#
# DLCI Default configuration parameters
# These may be overridden in the DLCI specific configurations
#
CIRfwd=64               # CIR forward   1 - 64
# Bc_fwd=16             # Bc forward    1 - 512 
# Be_fwd=0              # Be forward    0 - 511
# CIRbak=16             # CIR backward  1 - 64
# Bc_bak=16             # Bc backward   1 - 512
# Be_bak=0              # Be backward   0 - 511

#
# DLCI Configuration
# These are all optional. The naming convention is
# [DLCI_D<devicenum>_<DLCI_Num>]
#

[DLCI_D1_16]
# IP=
# Net=
# Mask=
# Flags defined by Sangoma: TXIgnore,RXIgnore,BufferFrames
# DLCIFlags=TXIgnore,RXIgnore,BufferFrames
# CIRfwd=64
# Bc_fwd=512
# Be_fwd=0
# CIRbak=64
# Bc_bak=512
# Be_bak=0

[DLCI_D2_16]
# IP=
# Net=
# Mask=
# Flags defined by Sangoma: TXIgnore,RXIgnore,BufferFrames
# DLCIFlags=TXIgnore,RXIgnore,BufferFrames
# CIRfwd=16
# Bc_fwd=16
# Be_fwd=0
# CIRbak=16
# Bc_bak=16
# Be_bak=0
</verb></tscreen>

När man har skapat sin <tt>/etc/frad/router.conf</tt> fil så är det enda som 
återstår att konfigurera enheterna. Detta är bara lite svårare än att
konfigurera en normal nätverksenhet. Man måste komma ihåg att starta upp 
FRAD-enheten innan DLCI inkapslingsenheterna.
<tscreen><verb>
# Configure the frad hardware and the DLCI parameters
/sbin/fradcfg /etc/frad/router.conf || exit 1
/sbin/dlcicfg file /etc/frad/router.conf
#
# Bring up the FRAD device
ifconfig sdla0 up
#
# Configure the DLCI encapsulation interfaces and routing
ifconfig dlci00 192.168.10.1 pointopoint 192.168.10.2 up
route add -net 192.168.10.0 netmask 255.255.255.0 dlci00
#
ifconfig dlci01 192.168.11.1 pointopoint 192.168.11.2 up
route add -net 192.168.11.0 netmask 255.255.255.0 dlci00
#
route add default dev dlci00
#
</verb></tscreen>

<sect1><heading>IP-redovisning (IP Accounting)
<p>
Med IP-redovisningsegenskaperna i Linuxkärnan kan man samla ihop och analysera
viss data från nätverksanvändningen. Datan som samlas ihop består av antalet
paket och antalet bytes ackumulerade sedan talen senast nollställdes. Man kan
specificera en mängd olika regler för att kategorisera talen för att passa
sina ändamål.
<p>
<bf/Kompileringsalternativ för Kärnan/:
<tscreen><verb>
Networking options  --->
    [*] IP: accounting
</verb></tscreen>
När man har kompilerat och installerat kärnan så behöver man använda kommandot
<em/ipfwadm/ för att konfigurera IP-redovisningen. Det finns många olika sätt
att bryta ner redovisningsinformationen. Jag har valt ett enkelt exempel på vad
som skulle kunna vara användbart, man kan läsa manualbladet för kommandot
<em/ipfwadm/ för mer information.
<p>
Scenario: man har ett Ethernet-nätverk som är anslutet till Internet via en 
PPP-länk. På sitt Ethernet har man en maskin som erbjuder ett antal tjänster och
man är intresserad av att veta hur mycket trafik som genereras av telnet, 
rlogin, ftp och www trafik.
<p>
Man skulle då kunna använda följande:
<tscreen><verb>
#
# Flush the accounting rules
ipfwadm -A -f
#
# Add rules for local ethernet segment
ipfwadm -A in -a -P tcp -D 44.136.8.96/29 20
ipfwadm -A out -a -P tcp -S 44.136.8.96/29 20
ipfwadm -A in -a -P tcp -D 44.136.8.96/29 23
ipfwadm -A out -a -P tcp -S 44.136.8.96/29 23
ipfwadm -A in -a -P tcp -D 44.136.8.96/29 80
ipfwadm -A out -a -P tcp -S 44.136.8.96/29 80
ipfwadm -A in -a -P tcp -D 44.136.8.96/29 513
ipfwadm -A out -a -P tcp -S 44.136.8.96/29 513
ipfwadm -A in -a -P tcp -D 44.136.8.96/29
ipfwadm -A out -a -P tcp -D 44.136.8.96/29
ipfwadm -A in -a -P udp -D 44.136.8.96/29
ipfwadm -A out -a -P udp  -D 44.136.8.96/29
ipfwadm -A in -a -P icmp -D 44.136.8.96/29
ipfwadm -A out -a -P icmp -D 44.136.8.96/29
#
# Rules for default
ipfwadm -A in -a -P tcp -D 0/0 20
ipfwadm -A out -a -P tcp -S 0/0 20
ipfwadm -A in -a -P tcp -D 0/0 23
ipfwadm -A out -a -P tcp -S 0/0 23
ipfwadm -A in -a -P tcp -D 0/0 80
ipfwadm -A out -a -P tcp -S 0/0 80
ipfwadm -A in -a -P tcp -D 0/0 513
ipfwadm -A out -a -P tcp -S 0/0 513
ipfwadm -A in -a -P tcp -D 0/0
ipfwadm -A out -a -P tcp -D 0/0
ipfwadm -A in -a -P udp -D 0/0
ipfwadm -A out -a -P udp  -D 0/0
ipfwadm -A in -a -P icmp -D 0/0
ipfwadm -A out -a -P icmp -D 0/0
#
# List the rules
ipfwadm -A -l -n
#
</verb></tscreen>
Det sista kommandot listar var och en av redovisningsreglerna och visar de
ihopsamlade summorna.
<p>
En viktig notering är att när man analyserar datan är att <bf/summan för alla
regler som passar in kommer att ökas/ så för att erhålla summor för enskilda
protokoll så måste man räkna lite grann. Om jag tex ville veta hur mycket data
som inte var ftp, telnet, rlogin eller www så skulle jag subtrahera de 
individuella summorna från den regel som passar in på alla portarna.
<tscreen><verb>
# ipfwadm -A -l -n
IP accounting rules
 pkts bytes dir prot source               destination          ports
    0     0 in  tcp  0.0.0.0/0            44.136.8.96/29       * -> 20
    0     0 out tcp  44.136.8.96/29       0.0.0.0/0            20 -> *
    0     0 in  tcp  0.0.0.0/0            44.136.8.96/29       * -> 23
    0     0 out tcp  44.136.8.96/29       0.0.0.0/0            23 -> *
   10  1166 in  tcp  0.0.0.0/0            44.136.8.96/29       * -> 80
   10   572 out tcp  44.136.8.96/29       0.0.0.0/0            80 -> *
  242  9777 in  tcp  0.0.0.0/0            44.136.8.96/29       * -> 513
  220 18198 out tcp  44.136.8.96/29       0.0.0.0/0            513 -> *
  252 10943 in  tcp  0.0.0.0/0            44.136.8.96/29       * -> *
  231 18831 out tcp  0.0.0.0/0            44.136.8.96/29       * -> *
    0     0 in  udp  0.0.0.0/0            44.136.8.96/29       * -> *
    0     0 out udp  0.0.0.0/0            44.136.8.96/29       * -> *
    0     0 in  icmp 0.0.0.0/0            44.136.8.96/29       *
    0     0 out icmp 0.0.0.0/0            44.136.8.96/29       *
    0     0 in  tcp  0.0.0.0/0            0.0.0.0/0            * -> 20
    0     0 out tcp  0.0.0.0/0            0.0.0.0/0            20 -> *
    0     0 in  tcp  0.0.0.0/0            0.0.0.0/0            * -> 23
    0     0 out tcp  0.0.0.0/0            0.0.0.0/0            23 -> *
   10  1166 in  tcp  0.0.0.0/0            0.0.0.0/0            * -> 80
   10   572 out tcp  0.0.0.0/0            0.0.0.0/0            80 -> *
  243  9817 in  tcp  0.0.0.0/0            0.0.0.0/0            * -> 513
  221 18259 out tcp  0.0.0.0/0            0.0.0.0/0            513 -> *
  253 10983 in  tcp  0.0.0.0/0            0.0.0.0/0            * -> *
  231 18831 out tcp  0.0.0.0/0            0.0.0.0/0            * -> *
    0     0 in  udp  0.0.0.0/0            0.0.0.0/0            * -> *
    0     0 out udp  0.0.0.0/0            0.0.0.0/0            * -> *
    0     0 in  icmp 0.0.0.0/0            0.0.0.0/0            *
    0     0 out icmp 0.0.0.0/0            0.0.0.0/0            *
# 
</verb></tscreen>

<sect1><heading>IP Aliasing
<p>
Det finns vissa applikationer där det är användbart att kunna tilldela flera 
IP-adresser till en och samma nätverksenhet. Titta i IP-Aliasing mini-HOWTO
för mer information än vad man hittar här.
<p>
<bf/Kompileringsalternativ för Kärnan/:
<tscreen><verb>
Networking options  --->
    ....
    [*] Network aliasing
    ....
    <*> IP: aliasing support
</verb></tscreen>
När man har kompilerat och installerat sin kärna med stöd för IP Aliasing så
är det väldigt enkelt att konfigurera. Aliasen läggs till virtuella 
nätverksenheter som är associerade med den verkliga enheten. En enkel 
namnkonvention används, nämligen 
<tt>&lt;enhetsnamn>:&lt;virtuellt enhetsnummer></tt>, tex <tt/eth0:0/,
<tt/ppp0:1/ osv. Notera att en virtuell enhet endast kan konfigureras 
<em>efter</em> det att den riktiga enheten har konfigurerats.
<p>
Till exempel, antag att man har ett Ethernet-nätverk som innehåller två olika
IP-subnät på en gång. Man vill nu att maskinen skall ha direkt access till
båda. Man skulle använda något som:
<tscreen><verb>
#
# ifconfig eth0 192.168.1.1 netmask 255.255.255.0 up
# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
#
# ifconfig eth0:0 192.168.10.1 netmask 255.255.255.0 up
# route add -net 192.168.10.0 netmask 255.255.255.0 eth0:0
#
</verb></tscreen>
För att ta bort ett alias så lägger man till ett `<tt/-/' i slutet på dess namn:
<tscreen><verb>
# ifconfig eth0:0- 0
</verb></tscreen>
Alla router som är relaterade till det aliaset kommer också att tas bort 
automatiskt.

<sect1><heading>IP Brandväggar (IP Firewalls)
<p>
IP-brandväggar täcks mer i detalj i 
<url url="Firewall-HOWTO.html" name="Firewall-HOWTO">. Med en IP-brandvägg kan 
man skydda sin maskin mot otillåten åtkomst via nätverket genom att filtrera 
bort eller tillåta datagram till eller ifrån IP-adresser som man anger. Det 
finns regler i tre olika klasser: inkommande filtrering, utgående filtrering 
och filtrering vid vidareskickning. Reglerna för inkommande gäller datagram som
tas emot av en nätverksenhet. Reglerna för utgående gäller datagram som skall
skickas av en nätverksenhet. Reglerna för vidareskickning gäller de datagram
som tas emot men inte skall till den aktuella maskinen, dvs datagram som skall
routas.
<p>
<bf/Kompileringsalternativ för Kärnan/:
<tscreen><verb>
Networking options  --->
    [*] Network firewalls
    ....
    [*] IP: forwarding/gatewaying
    ....
    [*] IP: firewalling
    [ ] IP: firewall packet logging
</verb></tscreen>

Konfigurationen av reglerna för brandväggen görs med hjälp av kommandot 
<em/ipfwadm/. Som jag nämnde tidigare så är jag ingen expert på säkerhet, så
även om jag visar ett exempel som går att använda så rekommenderas egna 
undersökningar i ämnet om säkerhet är särskilt viktigt.
<p>
Det kanske vanligaste användningsområdet för en brandvägg är när man använder
sin Linuxburk som en router och brandvägg för att skydda sitt lokala nätverk mot
otillåten åtkomst utifrån.
<p>
Följande konfiguration är baserad på ett bidrag från Arnt Gulbrandsen,
<tt>&lt;agulbra@troll.no&gt;</tt>.
<p>
Exemplet beskriver en konfiguration av brandväggsreglerna i 
Linux-brandväggen/routern som illustreras i denna figur:

<tscreen><verb>
-                                   -
 \                                  | 172.16.37.0
  \                                 |   /255.255.255.0
   \                 ---------      |
    |  172.16.174.30 | Linux |      |
NET =================|  f/w  |------|    ..37.19
    |    PPP         | router|      |  --------
   /                 ---------      |--| Mail |
  /                                 |  | /DNS |
 /                                  |  --------
-                                   -
</verb></tscreen>

Kommandona som följer placeras normalt i en <tt/rc/ fil så att de startas 
automatiskt varje gång systemet startas. För maximal säkerhet så borde de 
utföras efter det att nätverksgränssnitten konfigurerats, men innan enheterna
aktiveras så att man på detta sätt hindrar att någon får tillgång till maskinen
medan den startar upp.

<tscreen><verb>
#!/bin/sh

# Flush the 'Forwarding' rules table
# Change the default policy to 'accept'
#
/sbin/ipfwadm -F -f
/sbin/ipfwadm -F -p accept
#
# .. and for 'Incoming'
#
/sbin/ipfwadm -I -f
/sbin/ipfwadm -I -p accept

# First off, seal off the PPP interface
# I'd love to use '-a deny' instead of '-a reject -y' but then it
# would be impossible to originate connections on that interface too.
# The -o causes all rejected datagrams to be logged. This trades
# disk space against knowledge of an attack of configuration error.
#
/sbin/ipfwadm -I -a reject -y -o -P tcp -S 0/0 -D 172.16.174.30

# Throw away certain kinds of obviously forged packets right away:
# Nothing should come from multicast/anycast/broadcast addresses
#
/sbin/ipfwadm -F -a deny -o -S 224.0/3 -D 172.16.37.0/24
#
# and nothing coming from the loopback network should ever be
# seen on a wire
#
/sbin/ipfwadm -F -a deny -o -S 127.0/8 -D 172.16.37.0/24

# accept incoming SMTP and DNS connections, but only
# to the Mail/Name Server
#
/sbin/ipfwadm -F -a accept -P tcp -S 0/0 -D 172.16.37.19 25 53
#
# DNS uses UDP as well as TCP, so allow that too
# for questions to our name server
#
/sbin/ipfwadm -F -a accept -P udp -S 0/0 -D 172.16.37.19 53
#
# but not "answers" coming to dangerous ports like NFS and
# Larry McVoy's NFS extension.  If you run squid, add its port here.
#
/sbin/ipfwadm -F -a deny -o -P udp -S 0/0 53 \
        -D 172.16.37.0/24 2049 2050

# answers to other user ports are okay
#
/sbin/ipfwadm -F -a accept -P udp -S 0/0 53 \
        -D 172.16.37.0/24 53 1024:65535

# Reject incoming connections to identd
# We use 'reject' here so that the connecting host is told
# straight away not to bother continuing, otherwise we'd experience
# delays while ident timed out.
#
/sbin/ipfwadm -F -a reject -o -P tcp -S 0/0 -D 172.16.37.0/24 113

# Accept some common service connections from the 192.168.64 and
# 192.168.65 networks, they are friends that we trust.
#
/sbin/ipfwadm -F -a accept -P tcp -S 192.168.64.0/23 \
        -D 172.16.37.0/24 20:23

# accept and pass through anything originating inside
#
/sbin/ipfwadm -F -a accept -P tcp -S 172.16.37.0/24 -D 0/0

# deny most other incoming TCP connections and log them
# (append 1:1023 if you have problems with ftp not working)
#
/sbin/ipfwadm -F -a deny -o -y -P tcp -S 0/0 -D 172.16.37.0/24

# ... for UDP too
#
/sbin/ipfwadm -F -a deny -o -P udp -S 0/0 -D 172.16.37.0/24
</verb></tscreen>

Att göra en bra konfiguration av brandväggen är lite trixigt. Exemplet ovan 
borde dock vara en hyfsad startpunkt. Manualbladet för kommandot 
<em/ipfwadm/ innehåller mer hjälp om hur man använder det. Om man tänker 
konfigurera en brandvägg, så skall man se till att fråga runt och få så mycket råd man kan
ifrån källor som man anser vara pålitliga. Låt sedan någon testa konfigurationen 
från utsidan.

<sect1><heading>IPIP Inkapsling (IPIP Encapsulation)
<p>
Varför skulle man vilja kapsla in IP-datagram i andra IP-datagram? Det låter
som en konstig sak att göra om man aldrig sett ett exempel på det innan.
Ok, här är ett par vanliga områden där det används: Mobil IP och IP-Multicast. 
Men där det antagligen används mest är också det mest okända området, 
Amatörradio.
<p>
<bf/Kompileringsalternativ för Kärnan/:
<tscreen><verb>
Networking options  --->
    [*] TCP/IP networking
    [*] IP: forwarding/gatewaying
    ....
    <*> IP: tunneling
</verb></tscreen>
<p>
Tunnlingsenheterna heter `<tt/tunl0/', `<tt/tunl1/' osv.
<p>
"Men varför....?". Ok, ok. Konventionella regler för IP-routing säger att ett
IP-nätverk består av en nätverksadress och en nätmask. Detta producerar en 
serie kontinuerliga adresser som alla kan routas till en och samma utgående 
lina. Detta är väldigt bekvämt, men det innebär att man bara kan använda en 
viss IP-adress när man är ansluten till ett visst nätverk som adressen tillhör.
I de flesta fall går detta bra, men om man är en mobil 'nät-invånare' så 
kanske man inte alltid är ansluten till ett och samma nätverk hela tiden. IPIP
inkapsling (IP-tunnling) gör det möjligt att slippa den restriktionen genom att
låta datagram som är destinerade till en viss IP-adress packas in i ett nytt 
IP-paket och omdirigeras till en annan IP-adress. Om man vet att man kommer 
att arbeta på ett annat IP-nätverk ett tag så kan man ställa in en maskin på 
sitt hemmanät att ta emot ens datagram och sedan omdirigera dem till den 
adress som man använder temporärt.

<sect2><heading>En tunnlad nätverkskonfiguration.
<p>
Som alltid, så tycker jag att en figur fungerar bättre än en massa förvirrande 
text, så här kommer en:

<tscreen><verb>
 192.168.1/24                          192.168.2/24

     -                                     -
     |      ppp0 =            ppp0 =       |
     |  aaa.bbb.ccc.ddd  fff.ggg.hhh.iii   |
     |                                     |
     |   /-----\                 /-----\   |
     |   |     |       //        |     |   |
     |---|  A  |------//---------|  B  |---|
     |   |     |     //          |     |   |
     |   \-----/                 \-----/   |
     |                                     |
     -                                     -
</verb></tscreen>

Figuren illustrerar en annan möjlig anledning till IPIP-inkapsling, ett 
virtuellt privat nätverk. Detta exempel förutsätter att man har två maskiner 
som båda har en enkel uppringd anslutning till Internet. Båda datorerna 
allokeras en IP-adress. Bakom dessa maskiner finns några privata LAN 
konfigurerade med reserverade nätverksadresser. Antag att man vill låta vilken
dator som helst på nätverk A kommunicera med vilken dator som helst på 
nätverk B, precis som om de vore anslutna till Internet med en nätverksroute.
IPIP-inkapsling fixar detta. Notera att inkapslingen inte löser problemet med 
att låta datorerna på nätverken A och B kommunicera med någon annan dator på
Internet, då behöver man trix som IP-maskering. Inkapsling görs normalt av
maskiner som uppträder som routrar.
<p>
Linux routern `<tt/A/' skulle konfigureras med:
<tscreen><verb>
#
PATH=/sbin:/usr/sbin
#
# Ethernet configuration
ifconfig eth0 192.168.1.1 netmask 255.255.255.0 up
route add -net 192.168.1.0 netmask 255.255.255.0 eth0
#
# ppp0 configuration (start ppp link, set default route)
pppd
route add default ppp0
#
# Tunnel device configuration
ifconfig tunl0 192.168.1.1 up
route add -net 192.168.2.0 netmask 255.255.255.0 gw fff.ggg.hhh.iii tunl0
</verb></tscreen>
<p>
<p>
Linux routern `<tt/B/' skulle konfigureras med:
<tscreen><verb>
#
PATH=/sbin:/usr/sbin
#
# Ethernet configuration
ifconfig eth0 192.168.2.1 netmask 255.255.255.0 up
route add -net 192.168.2.0 netmask 255.255.255.0 eth0
#
# ppp0 configuration (start ppp link, set default route)
pppd
route add default ppp0
#
# Tunnel device configuration
ifconfig tunl0 192.168.2.1 up
route add -net 192.168.1.0 netmask 255.255.255.0 gw aaa.bbb.ccc.ddd tunl0
</verb></tscreen>
<p>
Kommandot:
<tscreen><verb>
route add -net 192.168.1.0 netmask 255.255.255.0 gw aaa.bbb.ccc.ddd tunl0
</verb></tscreen>
betyder: 'Skicka alla datagram ämnade för <tt>192.168.1.0/24</tt> inuti ett
IPIP-inkapslat datagram med destinationsadressen <tt/aaa.bbb.ccc.ddd/'.
<p>
Notera att konfigurationen finns på båda sidor. Tunnlingsenheten använder 
`<tt/gw/' parametern i routen som <em/destination/ för IP-datagrammet som 
kapslar in originaldatagrammet. Den maskinen måste då veta hur man 'packar upp'
ett IPIP-datagram, dvs den måste också ha en tunnlingsenhet.

<sect2><heading>En tunnlad datorkonfiguration.
<p>
Man måste inte routa ett helt nätverk. Man skulle till exempel kunna routa en
enskild IP-adress. I sådana fall skulle man kunna konfigurera <tt/tunl/ enheten
på den 'avlägsna' maskinen med sin hemma-IP-adress och i A-ändan bara använda
dator-route (och Proxy Arp) istället för en nätverksroute via tunnlingsenheten.
Låt oss rita om och modifiera vår konfiguration efter detta. Nu har vi bara
datorn `<tt/B/' som vill agera och uppföra sig som om den både var ansluten 
till Internet och även en del av nätverket som stöds av datorn `<tt/A/':
<p>
<tscreen><verb>
 192.168.1/24

     -
     |      ppp0 =                ppp0 =
     |  aaa.bbb.ccc.ddd      fff.ggg.hhh.iii
     |
     |   /-----\                 /-----\
     |   |     |       //        |     |
     |---|  A  |------//---------|  B  |
     |   |     |     //          |     |
     |   \-----/                 \-----/
     |                      also: 192.168.1.12
     -
</verb></tscreen>
<p>
Linux routern `<tt/A/' skulle konfigureras med:
<tscreen><verb>
#
PATH=/sbin:/usr/sbin
#
# Ethernet configuration
ifconfig eth0 192.168.1.1 netmask 255.255.255.0 up
route add -net 192.168.1.0 netmask 255.255.255.0 eth0
#
# ppp0 configuration (start ppp link, set default route)
pppd
route add default ppp0
#
# Tunnel device configuration
ifconfig tunl0 192.168.1.1 up
route add -host 192.168.1.12 gw fff.ggg.hhh.iii tunl0
#
# Proxy ARP for the remote host
arp -s 192.168.1.12 xx:xx:xx:xx:xx:xx pub
</verb></tscreen>
<p>
<p>
Linuxdatorn `<tt/B/' skulle konfigureras med:
<tscreen><verb>
#
PATH=/sbin:/usr/sbin
#
# ppp0 configuration (start ppp link, set default route)
pppd
route add default ppp0
#
# Tunnel device configuration
ifconfig tunl0 192.168.1.12 up
route add -net 192.168.1.0 netmask 255.255.255.0 gw aaa.bbb.ccc.ddd tunl0
</verb></tscreen>
<p>
Denna typ av konfiguration är mer typisk för Mobil IP. Där en enskild dator
vill flytta omkring på Internet och hela tiden använda samma IP-adress. Mer 
information om detta finns i sektionen om Mobil IP.

<sect1><heading>IPX (<tt/AF_IPX/)
<p>
IPX-protokollet används mest i LAN-omgivningar med Novell NetWare(tm). Linux
har stöd för att kunna agera som en nätverksändpunkt, eller som en router för
IPX.
<p>
<bf/Kompileringsalternativ för Kärnan/:
<tscreen><verb>
Networking options  --->
    [*] The IPX protocol
    [ ] Full internal IPX network
</verb></tscreen>

IPX-protokollet och NCPFS täcks mer detaljerat i 
<url url="IPX-HOWTO.html" name="IPX-HOWTO">.

<sect1><heading>IPv6
<p>
Precis när man tror att man förstår hur IP-nätverk fungerar så ändras reglerna!
IPv6 är en förkortning av Internet Protocol version 6. IPv6 kan ibland också kallas
för IPng (IP next generation) (SvÖ). IPv6 utvecklades i 
huvudsak för att ta bort oron i Internetvärlden att det snart är slut på 
IP-adresser som kan delas ut. IPv6-adresserna är 16 bytes stora (128 bits).
IPv6 har ett antal andra ändringar, mest förenklingar, som kommer att göra 
IPv6-nätverk lättare att underhålla än IPv4-nätverk.
<p>
Linux har redan en fungerande, men inte komplett, IPv6-implementation i version
<tt/2.1.*/ av kärnan.
<p>
Om man vill experimentera med nästa generations Internetteknik, eller om man 
behöver den, så bör man läsa IPv6-FAQ som finns på 
<url url="http://www.terra.net/ipv6/" name="www.terra.net">.

<sect1><heading>ISDN
<p>
Integrated Services Digital Network (ISDN) är en serie standarder som 
specificerar ett generellt switchat digitalt nätverk. En ISDN-`uppringning'
skapar en synkron punkt till punkt förbindelse till destinationen. ISDN körs 
normalt på höghastighetslänkar som delas in i ett antal diskreta kanaler. Det
finns två olika typer av kanaler, `B-kanaler' som bär användardatan och 
`D-kanaler' som används för kontrollinformation till ISDN-växeln. I Australien
till exempel så kan ISDN levereras med en 2Mbps-länk som delas in i 30 diskreta
64kbps B-kanaler och en 64kbps D-kanal. Valfritt antal kanaler kan användas 
samtidigt i valfri kombination. Man kan till exempel upprätta 30 olika 
anslutningar på 64kbps var till 30 olika destinationer, eller så kan man 
upprätta 15 olika anslutningar på 128kbps var till 15 olika destinationer (med
två kanaler per anslutning), eller bara ett litet antal kanaler och lämna 
resten vilande. En kanal kan användas till både inkommande och utgående 
anslutningar. Den ursprungliga avsikten med ISDN var att telefonbolagen ville
kunna erbjuda en enda datatjänst som kunde ge antingen telefon- (digitalt) 
eller datatjänster till hem och kontor utan att kunden skulle behöva ändra
någon konfiguration.
<p>
Det finns några olika sätt att ansluta en dator till en ISDN-tjänst. Ett sätt 
är att använda enhet som heter `Terminaladapter' som ansluter till en `Network 
Terminating Unit' vilken telefonbolaget har installerat i samband med 
ISDN-tjänsten och som har ett antal seriella gränssnitt. Ett av de gränssnitten
används för att skicka kommandon som upprättar en förbindelse och konfiguration
och de andra är anslutna till nätverket som skall användas. Linux fungerar i 
denna omgivningen utan modifikation, man behandlar bara terminaladaptern som 
vilken annan seriell enhet som helst. Ett annat sätt, vilket är så som kärnan
stöder ISDN, är att installera ett ISDN-kort i Linuxburken och sedan låta 
mjukvaran i Linux hantera protokollen och upprätta förbindelser.
<p>
<bf/Kompileringsalternativ för Kärnan/:
<tscreen><verb>
ISDN subsystem  --->
	<*> ISDN support
	[ ] Support synchronous PPP
	[ ] Support audio via ISDN
	< > ICN 2B and 4B support
	< > PCBIT-D support
	< > Teles/NICCY1016PC/Creatix support
</verb></tscreen>

Implementationen av ISDN i Linux stöder ett antal olika interna ISDN-kort.
Dessa finns listade i konfigurationen för kärnan:
<itemize>
<item/ICN 2B and 4B/
<item/Octal PCBIT-D/
<item/Teles ISDN-cards and compatibles/
</itemize>
Några av dessa kort kräver att man laddar hem särskild programvara för
att de skall fungera. Det finns ett separat verktyg att göra detta med.
<p>
Alla detaljer om hur man konfigurerar ISDN för Linux finns tillgängligt i 
katalogen <tt>/usr/src/linux/Documentation/isdn/</tt> och en FAQ för 
<em>isdn4linux</em> finns på 
<url url="http://www.lrz-muenchen.de/~ui161ab/www/isdn/"
	name="www.lrz-muenchen.de">.
<p>
<bf/En anmärkning om PPP/. PPP-protokollen fungerar antingen för asynkrona 
eller synkrona seriella linor. PPP-daemonen som vanligtvis levereras med Linux,
`<em/pppd/', stöder endast asynkront läge. Om man vill köra PPP-protokoll via
ISDN så måste man använda en särskilt modifierad version. Var man hittar den 
finns beskrivet i dokumentationen som nämns ovan.

<sect1><heading>IP-maskering (IP Masquerade).
<p>
Många har en enkel uppringd anslutning till Internet. Nästan alla som använder 
den typen av konfiguration allokeras en enda IP-adress av ISPn.
Det räcker normalt för att en dator skall ha full åtkomst till Internet. 
IP-maskering är ett smart trix som gör det möjligt att ha många maskiner som 
använder en enda IP-adress genom att låta de andra datorerna se ut som, därav
termen maskering, maskinen som har den uppringda anslutningen. Det finns dock 
en liten brist, maskeringsfunktionen fungerar nästan alltid bara i ena
riktningen. Det betyder att de förklädda datorerna kan ansluta utåt, men de kan
inte ta emot nätverksanslutningar från andra datorer. Detta betyder att vissa
nätverkstjänster inte fungerar, tex <em/talk/, och andra som till exempel 
<em/ftp/ måste konfigureras att köra i passivt (PASV) läge för att fungera. 
Lyckligtvis så fungerar de vanligaste tjänsterna som till exempel <em/telnet/, 
<em/World Wide Web/ och <em/irc/ utmärkt.
<p>
<bf/Kompileringsalternativ för Kärnan/:
<tscreen><verb>
Code maturity level options  --->
    [*] Prompt for development and/or incomplete code/drivers
Networking options  --->
    [*] Network firewalls
    ....
    [*] TCP/IP networking
    [*] IP: forwarding/gatewaying
    ....
    [*] IP: masquerading (EXPERIMENTAL)
</verb></tscreen>

Vanligtvis har man sin Linuxburk konfigurerad för uppringd  SLIP eller PPP, 
precis som om det var en friståenda dator. Dessutom så skulle den ha en 
ytterligare nätverksenhet konfigurerad, kanske Ethernet som är konfigurerat 
med en reserverad nätverksadress. Datorerna som skall förklädas skulle då 
finnas på det nätverket. Var och en av de datorerna skulle ställa in 
IP-adressen på Linuxboxens Ethernet-kort som `default gateway' eller router.
Observera att de andra datorerna (de som inte har den uppringda anslutningen) inte
behöver konfigureras med IP-maskering, de behöver endast veta vilken dator som
är `default gateway' (SvÖ).
<p>
En typisk konfiguration:
<tscreen><verb>
-                                   -
 \                                  | 192.168.1.0
  \                                 |   /255.255.255.0
   \                 ---------      |
    |                | Linux | .1.1 |
NET =================| masq  |------|
    |    PPP/slip    | router|      |  --------
   /                 ---------      |--| host |
  /                                 |  |      |
 /                                  |  --------
-                                   -
</verb></tscreen>

De viktigaste kommandona för denna konfiguration är:
<tscreen><verb>
# Network route for ethernet
route add -net 192.168.1.0 netmask 255.255.255.0 eth0
#
# Default route to the rest of the internet.
route add default ppp0
#
# Cause all hosts on the 192.168.1/24 network to be masqueraded.
ipfwadm -F -a m -S 192.168.1.0/24 -D 0.0.0.0/0 
</verb></tscreen>

Man kan hitta mer information om detta på 
<url url="http://www.hwy401.com/achau/ipmasq/"
name="IP Masquerade Resource Page"> eller i IP-Masquerade-MINI-HOWTO.


<sect1><heading>IP Transparent Proxy
<p>
Med IP transparent proxy kan man omdirigera servrar eller tjänster ämnade för
en annan dator till tjänsterna på denna maskinen.
Detta kan till exempel vara användbart om man har en Linuxburk som router och
även tillhandahåller en proxy-server. Då skulle man omdirigera alla anslutningar
ämnade för en avlägsen tjänst till den lokala proxy-servern.
<p>
<bf/Kompileringsalternativ för Kärnan/:
<tscreen><verb>
Code maturity level options  --->
	[*] Prompt for development and/or incomplete code/drivers
Networking options  --->
	[*] Network firewalls
	....
	[*] TCP/IP networking
	....
	[*] IP: firewalling
	....
	[*] IP: transparent proxy support (EXPERIMENTAL)
</verb></tscreen>

Man konfigurerar transparent proxy med kommandot <em/ipfwadm/.
<p>
Ett exempel som kan vara användbart följer:
<tscreen><verb>
ipfwadm -I -a accept -D 0/0 telnet -r 2323
</verb></tscreen>
Detta exempel gör att alla försök att upprätta en <tt/telnet/-anslutning 
(port 23) till någon dator kommer att omdirigeras till port 2323 på denna
dator. Om man kör en tjänst på den porten så kan man vidarebefodra 
telnet-anslutningar, logga dem eller göra vadhelst man önskar.
<p>
Ett mer intressant exempel är att omdirigera all <tt/http/-trafik genom en 
lokal cache. Men protokollet som används av proxy-servrar är annorlunda än 
vanlig http: där en klient ansluter till <tt/www.server.com:80/ och frågar efter
<tt>/sökväg/sida/</tt>, men när den ansluter till en lokal cache kontaktar den
<tt/proxy.local.domain:8080/ och frågar efter 
<tt>www.server.com/path/page</tt>.
<p>
För att filtrera en <tt/http/-förfrågan genom den lokala proxyn så behöver man 
lägga till det protokollet genom att köra en liten server, som heter 
<tt/transproxy/ (som man hittar på www). Man kan då köra <tt/transproxy/ på
port 8081 och ge följande kommando:
<tscreen><verb>
ipfwadm -I -a accept -D 0/0 80 -r 8081
</verb></tscreen>
Programmet <em/transproxy/ kommer då att ta emot alla anslutningar ämnade för
externa servrar och dirigera dem till den lokala proxyn efter att den har 
fixat till protokollskillnaderna.

<sect1><heading>Mobil IP
<p>
Termen IP-mobilitet beskriver förmågan att för en dator flytta sina 
nätverksanslutningar från en punkt på Internet till en annan utan att ändra 
sin IP-adress eller tappa anslutningen. Vanligtvis när en IP-dator byter
anslutningspunkt så måste den även byta IP-adress. IP-mobilitet övervinner 
detta problem genom att allokera en fix IP-adress till den mobila datorn och 
använda IP-inkapsling (tunnling) med automatisk routing för att se till att 
datagrammen som är ämnade för den routas till den IP-adress som den verkligen
använder.
<p>
Ett projekt är igång för att ta fram ett komplett paket med verktyg för
IP-mobilitet i Linux. Information om projektet kan fås på 
<url url="http://anchor.cs.binghamton.edu/~mobileip/"
	name="Linux Mobile IP Home Page">.

<sect1><heading>Multicast
<p>
Med IP-multicasting kan datagram routas till ett godtyckligt antal IP-datorer 
på olika IP-nätverk samtidigt. Denna mekanism kan till exempel användas för 
att sända broadcastmaterial, som tex video eller ljud, till ett stort antal
datorer på Internet samtidigt utan att var och en av dessa datorer behöver
belasta nätverket med en egen `kopia' av materialet.
<p>
<bf/Kompileringsalternativ för Kärnan/:
<tscreen><verb>
Networking options  --->
	[*] TCP/IP networking
	....
	[*] IP: multicasting
</verb></tscreen>
<p>
Man behöver även ett paket med verktyg och göra mindre nätverkskonfiguration.
Ett ställe att hämta information om hur man installerar dessa för Linux finns
på:
<url url="http://www.teksouth.com/linux/multicast/"
	name="www.teksouth.com">.

<sect1><heading>NAT - Översättning av nätverksadresser (Network Address Translation)
<p>
NAT är en standardiserad storebror till Linux IP-maskering. Det finns en 
detaljerad specifikation i RFC1631. NAT tillhandahåller funktioner som 
IP-maskering inte gör vilket gör det mer passande för användning i 
brandväggsroutrar hos företag och i större installationer.
<p>
En alpha-implementation av NAT för Linux 2.0.29 kärnan har utvecklats av
Michael Hasenstein, <tt/Michael.Hasenstein@informatik.tu-chemnitz.de/. Michaels
dokumentation och implementation finn på 
<url name="Linux IP Network Address Web Page"
	url="http://www.csn.tu-chemnitz.de/HyperNews/get/linux-ip-nat.html">
<p>
Nyare Linux 2.1.* kärnor har också viss NAT-funktionalitet i 
routingalgoritmen.
<sect1><heading>NetRom (<tt/AF_NETROM/)
<p>
Enhetsnamn för NetRom är `<tt/nr0/', `<tt/nr1/', osv.
<p>
<bf/Kompileringsalternativ för Kärnan/:
<tscreen><verb>
Networking options  --->
    [*] Amateur Radio AX.25 Level 2
    [*] Amateur Radio NET/ROM
</verb></tscreen>
Protokollen AX25, Netrom och Rose finns beskrivna i 
<url url="AX25-HOWTO.html" name="AX25-HOWTO">.
Dessa protokoll används av radioamatörer i hela världen i experiment med 
paketradio.
<p>
Det mesta arbetet med implementationen av dessa protokoll har gjorts av
Jonathon Naylor, <tt/jsn@cs.nott.ac.uk/.

<sect1><heading>PLIP (Parallel Line Internet Protocol)
<p>
Enhetsnamn för PLIP är `<tt/plip0/', `<tt/plip1/ and <tt/plip2/.
<p>
<bf/Kompileringsalternativ för Kärnan/:
<tscreen><verb>
Networking options  --->
    <*> PLIP (parallel port) support
</verb></tscreen>                            
<p>
<em/PLIP/, är som SLIP i den mening att det används för att
skapa en <em/punkt till punkt/ nätverksförbindelse mellan två maskiner. Men 
det skiljer sig genom att det är designat för att använda de parallella 
skrivarportarna på datorn istället för de seriella (ett kabelschema finns
längre fram i dokumentet). Eftersom det är möjligt att överföra mer än en bit
åt gången med en parallellport, så är det möjligt att uppnå högre hastigheter
med <em/PLIP/-gränssnittet än vad man gör med seriell enhet. Dessutom kan även
den enklaste av alla parallellportar, skrivarporten, användas i stället för att
man skall behöva köpa jämförelsevis dyra 16550AFN UARTs till de seriella 
portarna. PLIP använder dock mycket CPU-tid jämfört med en seriell länk och
är naturligtvis inget bra val om man kan få tag på några billiga Ethernet-kort,
men det fungerar om inget annat finns tillgängligt och det fungerar dessutom 
ganska bra. Man kan förvänta sig en överföringshastighet på ungefär 20 kB/s
när en länk fungerar bra.
<p>
PLIP-drivrutinerna slåss med parallell-drivrutinen om hårdvaran. Om man vill
använda båda drivrutinerna så skall man kompilera båda som moduler så kan man
välja vilken port man skall använda för PLIP och vilka portar man skall använda
för skrivardrivrutinen. Se <url name="Modules-HOWTO" url="Modules-HOWTO.html">
för mer information om hur man konfigurerar moduler till kärnan.
<p>
Notera att vissa bärbara datorer använder chipsets som inte fungerar med PLIP
därför att de inte tillåter vissa kombinationer av signaler som PLIP behöver, 
som skrivare inte använder.
<p>
Linux <em/PLIP/-gränssnitt är kompatibelt med <em/Crynwyr Packet Driver PLIP/ 
vilket betyder att man kan ansluta sin Linuxburk till en DOS-maskin som kör en
annan typ av TCP/IP via <em/PLIP/.
<p>
I 2.0.* kärnor är PLIP-enheterna mappade mot I/O-port och IRQ som följer:

<tscreen><verb>
device	i/o	IRQ
------	-----	---
plip0	0x3bc	5
plip1	0x378	7
plip2	0x278	2
</verb></tscreen>
Om man inte har parallellportar som stämmer överens med någon av ovanstående
kombinationer så kan man ändra en ports IRQ med kommandot <em/ifconfig/ och
parametern `<tt/irq/'. Man måste då slå på IRQ på skrivarportarna i sitt ROM 
BIOS (om det stöder det).
<p>
I senare 2.1.* kärnor med Plug'n'Play stöd så allokeras PLIP-enheterna 
sekvensiellt när de hittas precis som Ethernet-enheterna.
<p>
När man kompilerar kärnan är det en fil som man kanske behöver titta i för att
konfigurera <em/PLIP/. Filen är <tt>/usr/src/linux/driver/net/CONFIG</tt> och 
den innehåller <em/PLIP/ timrar i millisekunder. De förvalda är antagligen ok i
de flesta fall. Man måste antagligen öka på dem om man har en särskilt långsam
dator, då man faktiskt skall öka timrarna på den <em/andra/ datorn. Det finns 
ett program <em/plipconfig/ med vilket man kan ändra dessa timerinställningar
utan att kompilera om kärnan. Det kommandot följer med i många 
Linuxdistributioner.
<p>
För att konfigurera ett <em/PLIP/-gränssnitt så måste man <bf/lägga till/ 
följande rader i sin <tt/rc/-fil för nätverket:

<tscreen><verb>
#
# Attach a PLIP interface
#
#  configure first parallel port as a plip device
/sbin/ifconfig plip0 IPA.IPA.IPA.IPA pointopoint IPR.IPR.IPR.IPR up
#
# End plip
</verb></tscreen>

Där:
<descrip>
<tag>IPA.IPA.IPA.IPA</tag>representerar ens egen IP-adress.

<tag>IPR.IPR.IPR.IPR</tag>representerar IP-adress på den andra maskinen.
</descrip>
<p>
Parametern <em/pointopoint/ har samma betydelse som för SLIP, den specificerar
adressen på maskinen i andra änden av länken.
<p>
I nästan alla fall kan man behandla <em/PLIP/-gränssnittet som om det var ett
<em/SLIP/-gränssnitt, förutom att varken <em/dip/ eller <em/slattach/ behöver, 
eller kan användas.
<p>
Mer information om PLIP kan hittas i: 
<url name="PLIP-mini-HOWTO" url="mini/PLIP">


<sect1><heading>PPP (Point to Point Protocol)
<p>
Enhetsnamn för PPP är `<tt/ppp0/', `<tt/ppp1/, osv. Enheter numreras 
sekvensiellt och den första enheten som konfigureras får `<tt/ppp0/'.
<p>
<bf/Kompileringsalternativ för Kärnan/:
<tscreen><verb>
Networking options  --->
    <*> PPP (point-to-point) support
</verb></tscreen>
<p>
Detaljer om PPP-konfiguration finns i 
<url url="PPP-HOWTO.html" name="PPP-HOWTO">.
<p>
<sect2><heading>Att vidhålla en permanent anslutning till nätet med <em/pppd/.
<p>
Om man har en semi-permanent anslutning till nätet och vill att ens maskin 
automatiskt skall återuppta PPP-anslutningen om den bryts så finns det ett
enkelt trix som gör detta:
<p>
Konfigurera PPP så att det kan startas genom att <tt/root/-användaren ger
kommandot: 
<tscreen><verb>
# pppd
</verb></tscreen>
<bf/Se till/ att `<tt/-detach/' parametern finns konfigurerad i filen 
<tt>/etc/ppp/options</tt>. Sedan skall följande rader läggas in i filen 
<tt>/etc/inittab</tt>, tillsammans med <em/getty/-definitionerna:
<tscreen><verb>
pd:23:respawn:/usr/sbin/pppd
</verb></tscreen>
Detta gör så att programmet <em/init/ håller koll på <em/pppd/ och automatiskt
startar om det ifall det dör.

<sect1><heading>Rose protokollet (<tt/AF_ROSE/)
<p>
Enhetsnamn för Rose är `<tt/rs0/', `<tt/rs1/', osv. i <tt/2.1.*/ kärnor.
Rose finns endast i <tt/2.1.*/ kärnor.
<p>
<bf/Kompileringsalternativ för Kärnan/:
<tscreen><verb>
Networking options  --->
    [*] Amateur Radio AX.25 Level 2
    [*] Amateur Radio NET/ROM
</verb></tscreen>
Protokollen AX25, Netrom och Rose finns beskrivna i 
<url url="AX25-HOWTO.html" name="AX25-HOWTO">.
Dessa protokoll används av radioamatörer i hela världen i experiment med 
paketradio.
<p>
Det mesta arbetet med implementationen av dessa protokoll har gjorts av
Jonathon Naylor, <tt/jsn@cs.nott.ac.uk/.

<sect1><heading>SAMBA (stöd för `NetBEUI', `NetBios').
<p>
SAMBA är en implementation av protokollet `Session Management Block'. Med SAMBA
kan system från bland annat Microsoft använda diskar och skrivare i en 
Linuxbox.
<p>
Detaljer om SAMBA och dess konfiguration finns i 
<url url="SMB-HOWTO.html" name="SMB-HOWTO">.

<sect1><heading>SLIP (Serial Line Internet Protocol) klient.
<p>
Enhetsnamn för SLIP är `<tt/sl0/', `<tt/sl1/' osv. Enheter numreras 
sekvensiellt och den första enheten som konfigureras får `<tt/sl0/'.
<p>
<bf/Kompileringsalternativ för Kärnan/:
<tscreen><verb>
Network device support  --->
    [*] Network device support
    <*> SLIP (serial line) support
    [ ]  CSLIP compressed headers
    [ ]  Keepalive and linefill
    [ ]  Six bit SLIP encapsulation
</verb></tscreen>
<p>
Med SLIP kan man använda TCP/IP över en seriell
lina, som kan vara en telefonledning och modem, eller en hyrd ledning av något
slag. För att kunna använda SLIP behöver man ha tillgång till en 
<em>SLIP-server</em> i sitt närområde. Många universitet och företag i hela 
världen tillhandahåller SLIP-åtkomst.
<p>
SLIP använder de seriella portarna på datorn för att bära IP-datagram. För att
göra detta måste det ha kontroll över de seriella enheterna. SLIP-enheter benämns
med <em>sl0</em>, <em>sl1</em> osv. Hur motsvarar detta de seriella enheterna? 
Nätverkskoden använder vad som heter ett <em>ioctl</em>-anrop (i/o control) 
för att ändra de seriella enheterna till SLIP-enheter. Det finns två program 
som kan göra detta, de heter <em/dip/ och <em/slattach/.
<p>
<sect2><heading>dip (Dialup IP) 
<p>
<em>dip</em> är ett smart program som kan ställa in hastigheten på
den seriella enheten, kommendera modemet att ringa upp den andra ändan av 
länken, automatiskt logga in på servern, söka efter meddelanden som man får 
från servern och ta fram information från dem som tex IP-adress och dessutom
kan programmet utföra <em/ioctl/-kommandot som behövs för att sätta den 
seriella porten i SLIP-läge. <em/dip/ har ett kraftfullt scriptspråk i vilket
man kan automatisera sitt inloggningsförfarande.
<p>
Programmet finns på:
<url url="ftp://sunsite.unc.edu/pub/Linux/system/Network/serial/dip/dip337o-uri.tgz" name="sunsite.unc.edu">.
<p>
För att installera det, försök med följande:
<tscreen><verb>
#
# cd /usr/src
# gzip -dc dip337o-uri.tgz | tar xvf -
# cd dip-3.3.7o

<edit Makefile>

# make install
#
</verb></tscreen>

<p>
<tt/Makefile/ antar att det finns en grupp som heter <em/uucp/, men om man 
vill kan man ändra det till <em/dip/ eller <em/SLIP/ beroende på sin 
konfiguration.

<sect2><heading>slattach
<p>
I motsats till <em/dip/ så är <em>slattach</em> ett väldigt enkelt program som
är väldigt enkelt att använda, men det är inte så sofistikerat som <em/dip/.
Det har inte något scriptspråk och allt det gör är att konfigurera den seriella
enheten som en SLIP-enhet. Det antar att man har all information man behöver 
och att den seriella länken är upprättad när man kör programmet. <em/slattach/ 
är idealiskt att använda om man har en permanent förbindelse till en server, 
till exempel en fysisk kabel eller en hyrd ledning.

<sect2><heading>När använder man vilket?
<p>
Man skulle använda <em/dip/ om man har en uppringd förbindelse, eller någon 
annan temporär förbindelse, till sin SLIP-server. Man skulle använda 
<em/slattach/ om man har en hyrd ledning mellan sin maskin och SLIP-servern och
när man inte behöver göra något särskilt för att förbindelsen skall fungera. 
Se avsnittet `Permanent SLIP-anslutning' för mer information.
<p>
Att konfigurera SLIP är ungefär som att konfigurera ett Ethernet-gränssnitt (
Läs avsnittet `Att konfigurera en Ethernet-enhet' ovan). Det finns dock vissa
viktiga skillnader.
<p>
Först och främst så är SLIP-länkar olika Ethernet-nätverk i den meningen att 
det alltid endast finns två datorer på nätverket, en i varje ända av länken. 
Till skillnad från Ethernet, som är tillgängligt så fort man är inkopplad, så
måste man kanske, beroende på typen av länk, initialisera anslutningen på något
speciellt sätt.
<p>
Om man använder <em/dip/ så gör man det normalt inte vid systemstarten, utan
senare när man är redo att använda länken. Det är möjligt att automatisera den
processen. Om man använder <em/slattach/ så vill man antagligen lägga till
några rader i sin <em/rc.inet1/-fil. Detta beskrivs snart.
<p>
Det finns två huvudtyper av SLIP-servrar: Dynamisk IP-adress servrar och 
statisk IP-adress servrar. Nästan alla SLIP-servrar presenterar en prompt där
man skall logga in med användarnamn och lösenord. <em/dip/ kan logga in 
automatiskt.

<sect2><heading>Statisk SLIP-server med uppringd förbindelse och <em/dip/
<p>
En <em/statisk/ SLIP-server är en server i vilken man har fått en IP-adress 
som är ens egen. Varje gång man ansluter till servern så konfigurerar man sin 
SLIP-port med den adressen. Den statiska SLIP-servern kommer att svara på 
modemuppringningen, eventuellt fråga efter användarnamn och lösenord, och sedan
routa alla datagram ämnade för ens IP-adress genom den anslutningen. Om man har
en statisk server, så kanske man vill lägga in rader med sitt datornamn och sin
IP-adress (eftersom man vet vad den kommer att vara) i sin fil 
<tt>/etc/hosts/</tt>. Man bör också konfigurera lite andra filer, såsom 
<tt>rc.inet2</tt>, <tt>host.conf</tt>, <tt>resolv.conf</tt>,
<tt>/etc/HOSTNAME</tt> och <tt>rc.local</tt>. Kom ihåg att när man 
konfigurerar <tt>rc.inet1</tt> så behöver man inte lägga till några särskilda
kommandon för SLIP eftersom <em/dip/ sköter om allt som behöver göras där. Man
behöver dock ge <em/dip/ all nödvändig information så att det kan konfigurera
gränssnittet efter det att det har upprättat förbindelsen och loggat in på
SLIP-servern.

Om det är såhär ens SLIP-server fungerar så kan man gå vidare till avsnittet 
`Att använda <em/dip/' för att få reda på hur man konfigurerar <em/dip/.

<sect2><heading>Dynamisk SLIP-server med uppringd förbindelse och <em/dip/.
<p>
En <em/dynamisk/ SLIP-server är en server där man slumpvis allokeras en 
IP-adress, från en pool med adresser, varje gång man loggar på. Detta betyder
att det inte finns någon garanti för att man har en viss adress varje gång och 
att adressen kan användas av någon annan efter det att man har loggat av. 
Administratören för SLIP-servern har angett en mängd IP-adresser där servern
väljer den första lediga när den får en ny anslutning varefter den guidar 
användaren igenom loginprocessen och sedan skriver ett välkomstmeddelande som 
innehåller IP-adressen som sedan används under resten av anslutningen.
<p>
Konfigurationen för denna typ av server liknar den för en statisk server 
förutom att man måste lägga till ett steg där man tar emot IP-adressen som 
servern har allokerat och konfigurera SLIP-enheten med den.
<p>
Återigen så gör <em/dip/ det hårda jobbet och nyare versioner är tillräckligt 
smarta för att inte bara logga in, utan även ta reda på IP-adressen och spara
den så att man kan konfigurera SLIP-enheten med den.
<p>
Om det är såhär ens SLIP-server fungerar så kan man gå vidare till avsnittet 
`Att använda <em/dip/' för att få reda på hur man konfigurerar <em/dip/.

<sect2><heading>Att använda <em/dip/.
<p>
Som nämnts tidigare så är <em/dip/ ett kraftfullt program som kan förenkla och
automatisera processen där man ringer upp SLIP-servern, loggar in, aktivera
anslutningen och konfigurera SLIP-enheter med lämpliga <em/ifconfig/ och
<em/route/ kommandon.

För att använda <em/dip/ så skall man skriva ett `dip script', som formellt är
en lista av kommandon som <em/dip/ förstår och som talar om för <em/dip/ hur
det skall utföra varje sak som man vill att det skall utföra. Se 
<tt/sample.dip/ för att få en aning om hur det fungerar. <em/dip/ är ett ganska
kraftfullt program med många alternativ. Istället för att gå in på alla här så
är det lämpligt att titta på manualbladet, README- och exempelfiler för 
<em/dip/.
<p>
Exempelfilen <tt/sample.dip/ förutsätter att man använder en statisk 
SLIP-server, där man vet sin IP-adress i förväg. För dynamiska SLIP-servrar så
har nyare versioner av <em/dip/ ett kommando som automatiskt läser och 
konfigurerar SLIP-enheten med IP-adressen som man allokeras. Följande exempel
är en modifierad version av <tt/sample.dip/ som kom med <em/dip337j-uri.tgz/
och kan vara en bra utgångspunkt. Det kan vara bra att spara det som 
<tt>/etc/dipscript</tt> och sedan ändra det efter behov:
<tscreen><verb>
#
# sample.dip	Dialup IP connection support program.
#
#		This file (should show) shows how to use the DIP
#       This file should work for Annex type dynamic servers, if you
#       use a static address server then use the sample.dip file that
#       comes as part of the dip337-uri.tgz package.
#
#
# Version:	@(#)sample.dip	1.40	07/20/93
#
# Author:	Fred N. van Kempen, <waltje@uWalt.NL.Mugnet.ORG>
#

main:
# Next, set up the other side's name and address.
# My dialin machine is called 'xs4all.hacktic.nl' (== 193.78.33.42)
get $remote xs4all.hacktic.nl
# Set netmask on sl0 to 255.255.255.0
netmask 255.255.255.0
# Set the desired serial port and speed.
port cua02
speed 38400

# Reset the modem and terminal line.
# This seems to cause trouble for some people!
reset

# Note! "Standard" pre-defined "errlevel" values:
#  0 - OK
#  1 - CONNECT
#  2 - ERROR
#
# You can change those grep'ping for "addchat()" in *.c...

# Prepare for dialing.
send ATQ0V1E1X4\r
wait OK 2
if $errlvl != 0 goto modem_trouble
dial 555-1234567
if $errlvl != 1 goto modem_trouble

# We are connected.  Login to the system.
login:
sleep 2
wait ogin: 20
if $errlvl != 0 goto login_trouble
send MYLOGIN\n
wait ord: 20
if $errlvl != 0 goto password_error
send MYPASSWD\n
loggedin:

# We are now logged in.
wait SOMEPROMPT 30
if $errlvl != 0 goto prompt_error

# Command the server into SLIP mode
send SLIP\n
wait SLIP 30
if $errlvl != 0 goto prompt_error

# Get and Set your IP address from the server.  
#   Here we assume that after commanding the SLIP server into SLIP
#   mode that it prints your IP address
get $locip remote 30
if $errlvl != 0 goto prompt_error

# Set up the SLIP operating parameters.
get $mtu 296
# Ensure "route add -net default xs4all.hacktic.nl" will be done
default

# Say hello and fire up!
done:
print CONNECTED $locip ---> $rmtip
mode CSLIP
goto exit

prompt_error:
print TIME-OUT waiting for sliplogin to fire up...
goto error

login_trouble:
print Trouble waiting for the Login: prompt...
goto error

password:error:
print Trouble waiting for the Password: prompt...
goto error

modem_trouble:
print Trouble occurred with the modem...
error:
print CONNECT FAILED to $remote
quit

exit:
exit
</verb></tscreen>

Ovanstående exempel förutsätter att man kontaktar en <em/dynamisk/ SLIP-server,
om man kontaktar en <em/statisk/ server så bör <tt/sample.dip/ som följer med
<em/dip337-uri.tgz/ fungera bra.
<p>
Där <em/dip/ får kommandot <em>get &dollar;local</em> så söker det igenom den 
inkommande texten efter en textsträng som ser ut som en IP-adress, dvs tal som
är separerade med '.'-tecken. Denna modifiering gjordes speciellt för att 
fungera med <em/dynamiska/ SLIP-servrar, så att processen att läsa in 
IP-adressen från servern skulle bli automatiserad.
<p>
Ovanstående exempel skapar automatiskt en `default route' via SLIP-länken, om
det inte är detta man vill, om man tex har en Ethernet-anslutning som skall 
vara `default route, så tar man bort kommandot <em/default/ från scriptet.
<p>
Om man, då scriptet kört färdigt, ger kommandot <em/ifconfig/ så ser
man att det finns en enhet <em/sl0/. Detta är SLIP-enheten. Om så behövs så kan
man modifiera dess konfiguration manuellt efter det att <em/dip/ har kört färdigt, 
genom att använda kommandona <em/ifconfig/ och <em/route/.
<p>
Notera att med <em/dip/ kan man välja ett antal olika protokoll att använda med 
<tt/mode/-kommandot, det vanligaste är <em/cSLIP/ för SLIP med kompression.
Notera att båda ändar av länken måste komma överens, så man måste välja det som
ens server är inställt på.
<p>
Ovanstående exempel är hyfsat stabilt och skall klara av de flesta felen. Titta
annars i manualbladet för <em/dip/ för mer information. Naturligtvis så kan man 
skriva scriptet så att det till exempel försöker ringa upp servern igen om det
inte lyckas få en anslutning inom en given tid, eller till och med försöka med 
en serie olika servrar om man har tillgång till mer än en.

<sect2><heading>Permanent SLIP-anslutning med hyrd ledning och <em/slattach/.
<p>
Om man har en kabel mellan två maskiner, eller är lyckligt lottad och har en 
hyrd ledning, eller någon annan permanent seriell anslutning mellan sin maskin
och en annan, så behöver man inte besvära sig med att använda <em/dip/ för att
sätta upp en seriell länk. <em/slattach/ är ett väldigt enkelt verktyg att använda som 
har precis tillräckligt med funktionalitet för att konfigurera en anslutning.
<p>
Eftersom anslutningen är permanent så vill man lägga till några kommandon i sin
<tt/rc.inet1/-fil. Det enda man egentligen behöver göra för en permanent
anslutning är att konfigurera den seriella enheten till korrekt hastighet och
ställa in den i SLIP-läge. Med <em/slattach/ kan man göra detta i ett enda kommando. Man
<bf/lägger till/ följande i sin <tt/rc.inet1/-fil:

<tscreen><verb>
#
# Attach a leased line static SLIP connection
#
#  configure /dev/cua0 for 19.2kbps and cslip
/sbin/slattach -p cslip -s 19200 /dev/cua0 &
/sbin/ifconfig sl0 IPA.IPA.IPA.IPA pointopoint IPR.IPR.IPR.IPR up
#
# End static SLIP.
</verb></tscreen>

Där:
<descrip>
<tag>IPA.IPA.IPA.IPA</tag>representerar IP-adressen.

<tag>IPR.IPR.IPR.IPR</tag>representerar the IP-adressen i andra ändan.
</descrip>

<em/slattach/ allokerar den första icke allokerade SLIP-enheten till den specificerade
seriella enheten. <em/slattach/ börjar börjar med <em/sl0/. Därför så parar <em/slattach/ ihop 
<em/sl0/ med den specifierade seriella enheten och därefter <em/sl1/ osv.
<p>
Med <em/slattach/ kan man konfigurera ett antal olika protokoll med parametern <tt/-p/.
Vanligtvis så använder man <em/SLIP/ eller <em/cSLIP/ beroende på om man vill
ha kompression eller inte, men båda sidor måste vara överens.

<sect1><heading>SLIP (Serial Line Internet Protocol) server.
<p>
Om man har en maskin, som kanske är nätverksansluten, som man vill att andra 
skall kunna ansluta till och använda nätverkstjänster, så skall man konfigurera sin 
maskin som en server. Om man vill använda SLIP som protokoll så har man för
närvarande tre valmöjligheter för hur man skall konfigurera Linuxboxen som en
SLIP-server. Mitt råd skulle vara att använda det som presenteras först , <em/sliplogin/, 
eftersom det verkar vara det enklaste att konfigurera och förstå, men jag
kommer att presentera en sammanfattning av varje så att man kan bilda sig en
egen uppfattning.

<sect2><heading>SLIP-server med <em/sliplogin/.
<p>
<em/sliplogin/ är ett program som man kan använda istället för det normala login-shellet
för SLIP-användare som konverterar terminallinjen till en SLIP-länk. Man kan
med <em/sliplogin/ konfigurera sin Linuxbox som antingen en <em/statisk adressserver/,  
användare får samma IP-adress varje gång de ansluter, eller som en 
<em/dynamisk adresserver/ där användare inte nödvändigtvis får samma IP-adress
varje gång de ansluter.
<p>
De som ansluter kommer att logga in på vanligt vis med användarnamn och 
lösenord, men istället för att få ett shell efter de loggat in så exekveras
<em/sliplogin/, som söker i sin konfigurationsfil (<tt>/etc/slip.hosts</tt>) efter en rad
med ett loginnamn som motsvarar det som använts vid inloggningen. Om detta 
hittas så konfigurerar <em/sliplogin/ linjen som en ren 8 bitars länk och använder 
<em/ioctl/ för att konvertera länken till en SLIP-länk. Sedan återstår ett steg
där <em/sliplogin/ kör ett shellscript som konfigurerar SLIP-gränssnittet med relevant
IP-adress, nätmask och routing. Scriptet heter normalt 
<tt>/etc/slip.login</tt>, men på liknande sätt som för <em/getty/ om man har
särskilda användare som behöver speciell initiering, så kan man skapa script
som heter <tt>/etc/slip.login.loginname</tt> som körs istället för det 
allmänna.
<p>
Det finns antingen tre eller fyra filer att konfigurera för att <em/sliplogin/ skall 
fungera. Jag skall i detalj gå igenom hur man får tag på programvara och hur
man konfigurerar detta. Filerna är:

<itemize>
<item><tt>/etc/passwd</tt>, för användarkonton.
<p><item><tt>/etc/slip.hosts</tt>, för att innehålla information som är unik för 
varje användare.
<p><item><tt>/etc/slip.login</tt>, vilken tar hand om konfiguration av routing. 
<p><item><tt>/etc/slip.tty</tt>, vilken endast behövs om man skall konfigurera en
server som skall använda <em/dynamisk adressallokering/ och innehåller en 
tabell med adresser att allokera.
<p><item><tt>/etc/slip.logout</tt>, vilken innehåller kommandon för att städa upp
efter det att en användare har lagt på eller loggat ut.
</itemize>

<sect3><heading>Var man får tag på <em/sliplogin/.
<p>
Vissa kanske redan har <em/sliplogin/-paketet installerat som en del av sin distribution, 
om inte så kan <em/sliplogin/ hämtas ifrån: <url url="ftp://sunsite.unc.edu/pub/linux/system/Network/serial/sliplogin-2.1.1.tar.gz" name="sunsite.unc.edu">. Tar-filen
innehåller både källkod, kompilerade körbara filer och manualblad.
<p>
För att se till att bara auktoriserade användare skall kunna köra <em/sliplogin/, så bör
man lägga till en rad i filen <tt>/etc/group</tt>, ungefär som följande:

<tscreen><verb>
 ..
slip::13:radio,fred
 ..
</verb></tscreen>

När man installerar <em/sliplogin/-paketet så kommer <tt/Makefile/ att ändra ägargruppen
för kommandot <em/sliplogin/ till <tt/slip/, och det betyder att endast användare som 
tillhör den gruppen kan köra programmet. I exemplet ovan kan endast <tt/radio/ 
och <tt/fred/ köra <em/sliplogin/.
<p>
För att installera binärfilerna i katalogen <tt>/sbin</tt> gör man följande:

<tscreen><verb>
# cd /usr/src
# gzip -dc .../sliplogin-2.1.1.tar.gz | tar xvf -
# cd sliplogin-2.1.1
# <..edit the Makefile if you don't use shadow passwords..>
# make install
</verb></tscreen>

Om man vill kompilera om binärfilerna innan man installerar så skall man göra
<tt/make clean/ innan man kör <tt/make install/. Om man vill installera filerna
i någon annan katalog så får man ändra i filen <tt/Makefile/ under regeln
<em/install/.
<p>
Läs filen <tt/README/ som följer med paketet för mer information.

<sect3><heading>Att konfigurera <tt>/etc/passwd</tt> för SLIP.
<p>
Normalt skulle man skapa särskilda login för SLIP-användare i filen 
<tt>/etc/passwd</tt>. En konvention som ofta följs är att använda <em/hostname/
för den anslutande datorn med ett stort `S' i början. Så, till exempel, om den
anslutande datorn heter <tt/radio/ så kan man lägga en rad i 
<tt>/etc/passwd</tt> som ser ut såhär:

<tscreen><verb>
Sradio:FvKurok73:1427:1:radio SLIP login:/tmp:/sbin/sliplogin
</verb></tscreen>

Men det spelar egentligen ingen roll vad kontot heter, bara det betyder något
för administratören av SLIP-servern.
<p>
Notera att användarna inte behöver en särskild hemkatalog, efter som de inte 
kommer att få något shell från denna maskinen. Därför duger <tt>/tmp</tt> gott.
Notera även att <em/sliplogin/ används istället för ett normalt shell.

<sect3><heading>Att konfigurera <tt>/etc/slip.hosts</tt>
<p>
Filen <tt>/etc/slip.hosts</tt> är filen som <em/sliplogin/ söker igenom efter rader som 
stämmer överens med loginnamnet för att få tag på 
konfigurationsdetaljer för denna användare. Det är filen där man specificerar
IP-adressen och nätmasken som kommer att tilldelas användaren. Exempelrader för
två datorer, en statisk konfiguration för <tt/radio/ och en annan, dynamisk
konfiguration för <tt/albert/ kan se ut såhär:

<tscreen><verb>
#
Sradio   44.136.8.99   44.136.8.100  255.255.255.0  normal      -1
Salbert  44.136.8.99   DYNAMIC       255.255.255.0  compressed  60
#
</verb></tscreen>

Parametrarna i <tt>/etc/slip.hosts</tt> är:
<enum>
<item>loginnamnet för användaren.
<item>IP-adress för servermaskinen (dvs denna dator)
<item>IP-adress som användaren blir tilldelad. Om detta fält innehåller 
<tt/DYNAMIC/ så kommer IP-adressen att allokeras baserad på informationen som
finns i filen <tt>/etc/slip.tty</tt>. <bf/Notera:/ man måste ha åtminstone
version 1.3 av <em/sliplogin/ för att detta skall fungera.
<item>nätmasken som tilldelas den anslutande maskinen.
<item>SLIP-läge där man kan sätta på/stänga av kompression och andra 
funktioner. Tillåtna värden är <tt/normal/ eller <tt/compressed/.
<item>en timeoutparameter som specificerar hur lång tid länken kan vara oanvänd
innan den automatiskt avbryts. Ett negativt värde stänger av funktionen.
<item>valfria argument.
</enum>

Notera att man kan använda antingen datornamn eller IP-adresser för fält 2 och 
3. Om man använder datornamn så måste dessa kunna översättas, dvs maskinen 
måste måste kunna hitta en IP-adress som stämmer överens med datornamnet annars
kommer scripet att fallera när det körs. Man kan testa detta genom att försöka
öppna en telnet-anslutning till datornamnet, om man får meddelandet 
`<em/Trying nnn.nnn.nnn.../' så kan maskinen hitta en IP-adress. Får man 
däremot meddelandet `<em/Unknown host/' så kan den inte hitta någon IP-adress.
Om inte så använder man IP-adresser eller fixar till konfigurationen av sin
namnöversättare (se avsnitt `Att konfigurera din Name Resolver').
<p>
De vanligaste SLIP-lägena är:
<descrip>
<tag>normal
</tag>att slå på normal SLIP utan kompression.

<tag>compression
</tag>att slå på van Jacobsen header compression (cSLIP)
</descrip>

Man kan endast använda en åt gången. För mer information om de andra 
valmöjligheterna som finns, se manualbladen.

<sect3><heading>Att konfigurera <tt>/etc/slip.login</tt>.
<p>
När <em/sliplogin/ har hittat en passande rad i <tt>/etc/slip.hosts</tt> så kommer 
programmet att försöka exekvera filen <tt>/etc/slip.login</tt> för att 
konfigurera SLIP-gränssnittet med dess IP-adress och nätmask.
<p>
Exemplet på en <tt>/etc/slip.login</tt> som följer med <em/sliplogin/-paketet ser
ut så här:

<tscreen><verb>
#!/bin/sh -
#
#       @(#)slip.login  5.1 (Berkeley) 7/1/90
#
# generic login file for a SLIP line.  sliplogin invokes this with
# the parameters:
#     $1       $2       $3    $4, $5, $6 ...
#   SLIPunit ttyspeed   pid   the arguments from the slip.host entry
#
/sbin/ifconfig $1 $5 pointopoint $6 mtu 1500 -trailers up
/sbin/route add $6
arp -s $6 <hw_addr> pub
exit 0
#
</verb></tscreen>

Scriptet använder helt enkelt kommandona <em/ifconfig/ och <em/route/ för att
konfigurera SLIP-enheten med dess IP-adress, avlägsen IP-adress och nätmask och
sedan skapa en route till den avlägsna adressen via SLIP-enheten. Precis som om
man använde kommandot <em/slattach/.
<p>
Notera också användandet av <em/Proxy ARP/ för att se till att andra datorer på
samma Ethernet som servern kommer att nå den anslutna datorn. Fältet 
<tt>&lt;hw_addr></tt> skall vara hårdvaruadressen på Ethernet-kortet i 
maskinen. Om servern inte är ansluten till ett Ethernet-nätverk kan man helt
utelämna denna rad.

<sect3><heading>Att konfigurera <tt>/etc/slip.logout</tt>.
<p>
När anslutningen avslutas, så vill man se till att den seriella enheten 
återställs till sitt normala tillstånd så att framtida anslutningar kan logga in
ordentligt. Detta uppnås genom med hjälp av filen <tt>/etc/slip.logout</tt>. 
Dess format är ganska enkelt och används med samma argument som filen
<tt>/etc/slip.login</tt>.

<tscreen><verb>
#!/bin/sh -
#
#               slip.logout
#
/sbin/ifconfig $1 down
arp -d $6
exit 0
#
</verb></tscreen>

Allt den gör är `ta ner' gränssnittet vilket kommer att ta bort routen som 
skapades tidigare. Den använder också kommandot <em/arp/ för att ta bort 
eventuella <em/Proxy ARP/s som har skapats, återigen, man behöver inte 
kommandot <em/arp/ ifall servern inte är ansluten till ett Ethernet-nätverk.

<sect3><heading>Att konfigurera <tt>/etc/slip.tty</tt>.
<p>
Om man använder dynamisk IP-adressallokering (har någon rad konfigurerad med
<tt/DYNAMIC/ i <tt>/etc/slip.hosts</tt>) så måste man konfigurera filen 
<tt>/etc/slip.tty</tt> för att lista vilka adresser som tilldelas vilken port.
Man behöver endast denna fil om man vill att servern dynamiskt skall ge 
adresser till användare. Formatet är följande:
<tscreen><verb>
# slip.tty    tty -> IP address mappings for dynamic SLIP
# format: /dev/tty?? xxx.xxx.xxx.xxx
#
/dev/ttyS0      192.168.0.100
/dev/ttyS1      192.168.0.101
#
</verb></tscreen>
Vad denna fil säger är att användare som ansluter till porten 
<tt>/dev/ttyS0</tt> och som har sitt adressfält i filen 
<tt>/etc/slip.hosts</tt> satt till <tt>DYNAMIC</tt> kommer att tilldelas 
adressen <tt>192.168.0.100</tt>.
<p>
På detta sättet behöver man endast allokera en adress per port förutom för de
användare som behöver en egen adress. Detta hjälper till att hålla nere 
antalet adresser man behöver till ett minimum och undviker slösande.

<sect2><heading>Slip Server med <em>dip</em>.
<p>
Låt mig börja med att säga att lite av informationen nedan kom ifrån 
manualbladet för <em/dip/, där det kortfattat beskrivs hur man kör Linux som en
SLIP-server. Var också uppmärksam på att det som följer är baserat på paketet
<em>dip337o-uri.tgz</em> och antagligen inte gäller för andra versioner av
<em/dip/.
<p>
<em/dip/ har ett läge när det automatiskt letar upp en rad för den användaren som 
körde programmet och konfigurerar den seriella linjen som en SLIP-länk baserat
på informationen som den hittar i filen <tt>/etc/diphosts</tt>. Detta läge 
aktiveras genom att köra <em/dip/ som <em/diplogin/. Detta är därför sättet på vilket man 
använder <em/dip/ som en SLIP-server, genom att skapa särskilda konton där <em/diplogin/
används som login-shell. Det första som skall göras är att göra en symbolisk
länk som följer:

<tscreen><verb>
# ln -sf /usr/sbin/dip /usr/sbin/diplogin
</verb></tscreen>

Sedan behöver man lägga till rader i filerna <tt>/etc/passwd</tt> och 
<tt>/etc/diphosts</tt>. Raderna är formaterade som följer:

För att konfigurera Linux som en SLIP-server med <em/dip/ behöver man skapa några
särskilda SLIP-konton för användare, där <em/dip/ används som login-shell. En 
föreslagen konvention är att låta alla SLIP-konton börja med ett stort `S', 
tex `Sfredm'.
<p>
Ett exempel på en rad för en SLIP-användare i <tt>/etc/passwd</tt> ser ut så
här:

<tscreen><verb>
Sfredm:ij/SMxiTlGVCo:1004:10:Fred:/tmp:/usr/sbin/diplogin
^^         ^^        ^^  ^^   ^^   ^^   ^^
|          |         |   |    |    |    \__ diplogin as login shell
|          |         |   |    |    \_______ Home directory
|          |         |   |    \____________ User Full Name
|          |         |   \_________________ User Group ID
|          |         \_____________________ User ID
|          \_______________________________ Encrypted User Password
\__________________________________________ Slip User Login Name
</verb></tscreen>

När användaren har loggat in så utför programmet <em/login/, om det hittar och
verifierar användaren ok, kommandot <em/diplogin/. <em/dip/, när det körs som <em/diplogin/, vet 
automatiskt att det skall användas som ett login-shell. När det startas som 
<em/diplogin/ så är det första programmet gör att använda funktionsanropet 
<em>getuid()</em> för att få användarid för den som körde programmet. Det letar
sedan i filen <tt>/etc/diphosts</tt> efter den första raden som passar in på
det användaridt eller namnet på den <em/tty/-enhet som anslutningen kom från
och konfigurerar sig själv därefter. Genom att välja om en användare skall få
en rad i filen <tt>/etc/diphosts</tt> eller om användaren skall ges den 
generella konfigurationen så kan man bygga sin server på så sätt att man kan
ha en blandning av statiskt och dynamiskt tilldelade adresser för användarna.
<em/dip/ kommer automatiskt att lägga till en <em/Proxy ARP/ så detta behöver man 
inte bry sig om att göra manuellt.

<sect3><heading>Att konfigurera <tt>/etc/diphosts</tt>

<p>
Filen <tt>/etc/diphosts</tt> används av <em/dip/ för att hitta konfigurationer för 
avlägsna datorer. Dessa avlägsna datorer kan vara användare som ringer in till
en Linuxbox eller de kan vara datorer som man ringer till ifrån Linuxboxen.

Det generella formatet på <tt>/etc/diphosts</tt> är som följer:

<tscreen><verb>
 ..
Suwalt::145.71.34.1:145.71.34.2:255.255.255.0:SLIP uwalt:CSLIP,1006
ttyS1::145.71.34.3:145.71.34.2:255.255.255.0:Dynamic ttyS1:CSLIP,296
 ..
</verb></tscreen>

Fälten är:
<enum>
<item><tt>login name</tt>: som returnerat av getpwuid(getuid()) eller tty namn.
<item><tt>oanvänd</tt>: kompatibilitet med /etc/passwd
<item><tt>Remote Address</tt>: IP-adress för den anslutande datorn, antingen 
numeriskt eller med namn
<item><tt>Local Address</tt>: IP-adress för denna dator, numeriskt eller med
namn
<item><tt>Netmask</tt>: i punkterad decimal notation
<item><tt>Comment field</tt>: skriv vad du vill här.
<item><tt>protocol</tt>: Slip, CSlip osv.
<item><tt>MTU</tt>: decimalt tal
</enum>

Ett exempel på en rad i <tt>/etc/net/diphosts</tt> för en SLIP-användare kan
vara:

<tscreen><verb>
Sfredm::145.71.34.1:145.71.34.2:255.255.255.0:SLIP uwalt:SLIP,296
</verb></tscreen>
som specificerar en SLIP-länk med en avlägsen adress 145.71.34.2 och MTU på 
296, eller:

<tscreen><verb>
Sfredm::145.71.34.1:145.71.34.2:255.255.255.0:SLIP uwalt:CSLIP,1006
</verb></tscreen>

som specificerar en cSLIP-länk med avlägsen adress 145.71.34.1 och MTU på 1006.
<p>
Därför så skall alla användare som man vill tillåta en statiskt allokerad 
adress ha en rad i <tt>/etc/diphosts</tt>. Om man vill att användare som 
ansluter till en viss port skall få en dynamisk allokerad adress så måste man ha
en rad för <tt/tty/-enheten och ingen rad för användaren.
Man skall komma ihåg att konfigurera åtminstonde en rad för varje <tt/tty/-enhet 
som används för SLIP så att det säkert finns en passande konfiguration oavsett
vilket modem de ringer in på.
<p>
När användare loggar in får de en normal login och password prompt vid vilken
de skall skriva in sitt SLIP-login och password. Om dessa verifieras ok så 
kommer användaren inte se några särskilda meddelanden och användarna skall 
endast byta till SLIP-läge på sin sida. Användaren bör ha möjlighet att ansluta
ok och bli konfigurerad med relevanta parametrar från filen <tt>diphosts</tt>.

<sect2><heading>SLIP server med paketet <em>dSLIP</em>

<p>
Matt Dillon <tt>&lt;dillon@apollo.west.oic.com></tt> har skrivit ett 
programpaket som inte bara ringer in utan också ringer ut med SLIP. Matts paket 
är en kombination av små program och scripts som hanterar ens anslutningar. För
detta måste man ha <em>tcsh</em> eftersom åtminstone ett av scripten kräver 
detta. Matt tillhandahåller en binär kopia av verktyget <em>expect</em> 
eftersom även det behövs av en del av scripten. Man behöver antagligen ha 
lite erfarenhet med kommandot <em>expect</em> för att lyckas länka in ok, men 
låt inte detta avskräcka.
<p>
Matt har skrivit bra med installationsinstruktioner i README-filen så
jag tänker inte upprepa dem.
<p>
Man kan hämta <em>dSLIP</em> från dess hemsida på:

<bf>apollo.west.oic.com</bf>
<tscreen><verb>
/pub/linux/dillon_src/dSLIP203.tgz
</verb></tscreen>

eller från:

<bf>sunsite.unc.edu</bf>
<tscreen><verb>
/pub/Linux/system/Network/serial/dSLIP203.tgz
</verb></tscreen>

Läs filen <tt/README/ och skapa raderna i <tt>/etc/passwd</tt> och 
<tt>/etc/group</tt> <bf/innan/ <tt>make install</tt>.

<sect1><heading>STRIP (Starmode Radio IP)
<p>
<bf/Kompileringsalternativ för Kärnan/:
<tscreen><verb>
Network device support  --->
	[*] Network device support
	....
	[*] Radio network interfaces
	< > STRIP (Metricom starmode radio IP)
</verb></tscreen>
STRIP är ett protokoll som designats speciellt för en typ av Metricom 
radiomodem för ett forskningsprojekt på Stanford University som heter 
<url url="http://mosquitonet.Stanford.EDU/mosquitonet.html"
	name="MosquitoNet Project">.
Det finns mycket intressant att läsa där, även om man inte är direkt intresserad
av projektet.
<p>
Metricom radiorna kopplas till en seriell port, använder många olika tekniker
och klarar av en överföringshastighet på ungefär 100kbps. Information om 
Metricom radior kan fås på: <url url="http://www.metricom.com/"
	name="Metricom Web Server">.
<p>
För närvarande så stöds inte STRIP av standardverktygen för nätverk, så man
måste ladda hem några specialdesignade verktyg från MosquitoNets WWW-server.
Detaljer om vad man behöver finns på:
<url url="http://mosquitonet.Stanford.EDU/strip.html"
	name="MosquitoNet STRIP Page">.
<p>
En sammanfattning av konfigurationen är att man använder ett modifierat
<em/slattach/ program för att ställa in den seriella enheten i STRIP-läge
och sedan konfigurera den resulterande `<tt/st[0-9]/'-enheten som om det
var en Ethernet-enhet, men med en viktig skillnad. Av tekniska skäl så 
stöder inte STRIP ARP-protokollet, så man måste konfigurera ARP-raderna för
var och en av datorerna på sitt subnät manuellt. 

<sect1><heading>Token Ring
<p>
Enhetsnamn för Token Ring är `<tt/tr0/', `<tt/tr1/' osv. Token Ring är ett
standardiserat LAN-protokoll från IBM som undviker kollisioner med en mekanism
som endast tillåter en station på LANet att sända åt gången. En `token' innehas
av en station åt gången och stationen som har `token' får lov att sända. När 
den har sänt sin data så skickar den `token' vidare till nästa station. Token
går runt mellan alla aktiva stationer, därav namnet `Token Ring'.
<p>
<bf/Kompileringsalternativ för Kärnan/:
<tscreen><verb>
Network device support  --->
	[*] Network device support
	....
	[*] Token Ring driver support
	< > IBM Tropic chipset based adaptor support
</verb></tscreen>

Konfigurationen av Token Ring är identisk med den som görs med Ethernet 
förutom att man använder andra enhetsnamn.

<sect1><heading>X.25
<p>
X.25 är ett paketswitchat protokoll som definieras av <tt/C.C.I.T.T./ (en 
standardiseringsorganisation som erkänns av de flesta telebolag i världen). En
implementation av X.25 och LAPB håller på att utvecklas och de senaste 
<tt/2.1.*/ kärnor inkluderar detta arbete.
<p>
Jonathon Naylor <tt>jsn@cs.nott.ac.uk</tt> leder utvecklingen och det har 
skapats en mailinglista för att diskutera ämnen relaterade till Linux X.25.
För att prenumerera skall man skicka ett meddelande till 
<tt/majordomo@vger.rutgers.edu/ med texten "<tt/subscribe linux-x25/" i 
meddelandekroppen.
<p>
Tidiga versioner av konfigureringsverktygen kan hämtas från Jonathons ftp-sajt
på <url url="ftp://ftp.cs.nott.ac.uk/jsn/" name="ftp.cs.nott.ac.uk">.

<sect1><heading>WaveLan
<p>
Enhetsnamn för WaveLan är `<tt/eth0/', `<tt/eth1/', osv.
<p>
<bf/Kompileringsalternativ för Kärnan/:
<tscreen><verb>
Network device support  --->
	[*] Network device support
	....
	[*] Radio network interfaces
	....
	<*> WaveLAN support
</verb></tscreen>

WaveLan-kortet är ett vitt spektrum av trådlösa LAN-kort. Korten liknar 
Ethernet-kort mycket och konfigureras på ungefär samma sätt.
<p>
Mer information om WaveLan finns på 
<url url="http://www.wavelan.com/" name="Wavelan.com">.

<sect><heading>Kablage
<p>
De som är händiga med en lödpenna kanske vill bygga egna kablar för att 
koppla ihop Linuxburkar. Följande figurer bör vara till hjälp för detta.

<sect1><heading>Seriell NULL-modem kabel.
<p>
Alla NULL-modem kablar är <bf/inte/ likadana. Många NULL-modem kablar gör inte
mer än att lura datorn att tro att alla signaler finns och byter sänd och ta 
emot data pinnarna. Detta fungerar men betyder att man måste använda 
flödeskontroll i mjukvara (XON/XOFF) vilket inte är så effektivt som 
flödeskontroll i hårdvara. Följande kabel har bästa möjliga signalering mellan
datorer och tillåter användning av flödeskontroll i hårdvara (RTS/CTS).
<tscreen><verb>
Pin Name  Pin                               Pin
Tx Data    2  -----------------------------  3
Rx Data    3  -----------------------------  2
RTS        4  -----------------------------  5
CTS        5  -----------------------------  4
Ground     7  -----------------------------  7
DTR        20 -\---------------------------  8
DSR        6  -/
RLSD/DCD   8  ---------------------------/-  20
                                         \-  6
</verb></tscreen>

<sect1><heading>Parallellportskabel (PLIP kabel)
<p>
Om man tänker använda PLIP-protokollet mellan två maskiner så fungerar följande
kabel oavsett vilken typ av parallellportar man har.

<tscreen><verb>
Pin Name    pin            pin
STROBE      1*
D0->ERROR   2  ----------- 15
D1->SLCT    3  ----------- 13
D2->PAPOUT  4  ----------- 12
D3->ACK     5  ----------- 10
D4->BUSY    6  ----------- 11
D5          7*
D6          8*
D7          9*
ACK->D3     10 ----------- 5
BUSY->D4    11 ----------- 6
PAPOUT->D2  12 ----------- 4
SLCT->D1    13 ----------- 3
FEED        14*
ERROR->D0   15 ----------- 2
INIT        16*
SLCTIN      17*
GROUND      25 ----------- 25
</verb></tscreen>

Anmärkningar:
<itemize>
<item>Anslut inte pinnarna som är markerade med en asterisk `*'.
<item>Extra jordning är 18,19,20,21,22,23 och 24.
<item>Om kabeln man använder har en metallskärmning, så skall den anslutas
till metallskalet på DB-25 <bf/endast på en sida/.
</itemize>
<bf>Varning: en felkopplad PLIP-kabel kan förstöra kontrollerkortet.</bf> Var
försiktig och dubbelkolla alla anslutningar.
<p>
Även om man kan använda PLIP-kablar över långa avstånd så skall man undvika
det om man kan. Specifikationerna för kabeln tillåter längder på ungefär en
meter. Var försiktig med långa PLIP-kablar eftersom källor för stark 
elektromagnetisk strålning (tex blixtar, elkablar och radiosändare) kan störa
och till och med skada kontrollerkortet. Om man verkligen vill ansluta två 
datorer över långa avstånd så bör man titta på möjligheterna med Ethernet och
använda tunn koaxialkabel.

<sect1><heading>10base2 (tunn koax) Ethernet-kabel
<p>
10base2 är en kabelstandard för Ethernet som specificerar en 52 ohms 
koaxialkabel med en diameter på ungefär 5 millimeter. Det finns ett par viktiga
regler att komma ihåg när man skall koppla ihop maskiner med 10base2 kablar.
Det första är att man måste använda terminatorer i <bf/båda ändar/ av kabeln.
En terminator är ett 52 ohms motstånd som ser till att signalen absorberas, och
inte reflekteras, när den når slutet av kabeln. Utan en terminator i båda ändar
av kabeln så kommer man att märka att nätverket är opålitligt eller inte 
fungerar alls. Normalt så använder man `T-korsningar' för att koppla ihop
maskinerna, så man får något som liknar:
<tscreen><verb>
 |==========T=============T=============T==========T==========|
            |             |             |          |
            |             |             |          |
          -----         -----         -----      -----
          |   |         |   |         |   |      |   |
          -----         -----         -----      -----
</verb></tscreen>
där en `<tt/|/' i båda ändar representerar en terminator, `<tt/======/' 
representerar en längd med koaxialkabel med BNC-kontakter i båda ändar och 
`<tt/T/' representerar en `T-korsning'-kontakt. Man skall försöka att hålla 
längden på kabeln mellan `T-korsningen' och Ethernet-kortet så kort som 
möjligt, det bästa är om `T-korsningen' är kopplad direkt på Ethernet-kortet.

<sect1><heading>Tvinnad tvåpar Ethernet-kabel.
<p>
Om man bara har två Ethernet-kort med tvinnad tvåpar anslutning som man vill
koppla ihop så måste man inte ha en hub. Man kan koppla ihop korten direkt.
Ett diagram som visar hur man gör detta finns i 
<url url="Ethernet-HOWTO.html" Name="Ethernet-HOWTO">.

<sect><heading>Terminologi i detta dokument.
<p>
Följande är en lista med de viktigaste termerna som används i detta dokument.
<descrip>
<tag>ARP</tag>Detta är en förkortning av <em>Address Resolution Protocol</em> 
och det är hur en maskin på ett nätverk associerar en IP-adress med en 
hårdvaruadress.

<tag>ATM</tag>Detta är en förkortning av <em>Asynchronous Transfer Mode</em>.
Ett ATM-nätverk packar data i block med en standardstorlek vilka det sedan kan
skicka effektivt från punkt till punkt. ATM är ett kopplingsorienterat nätverk
med virtuella kretsar.

<tag>klient</tag>Detta är vanligtvis mjukvaran i den ändan av systemet där 
användaren finns. Det finns undantag, till exempel i X11 fönstersystem så är
det egentligen servern som finns hos användaren och klienten kör på en annan
maskin. Klienten är programmet eller delen av systemet som använder en tjänst 
som tillhandahålls av servern. I fallet med <em/peer to peer/ system, som 
<em/slip/ eller <em/ppp/, så är den dator som startar anslutningen klienten och
den andra datorn servern.

<tag>datagram</tag>Ett datagram är ett diskret paket med data och huvuden, som 
innehåller adresser, som är en transmissionsenhet över ett IP-nätverk. Detta 
kan också kallas för `paket' i vissa sammanhang.

<tag>DLCI</tag>Detta är en förkortning av <em/Data Link Connection Identifier/ 
och används för att identifiera en unik virtuell punkt till punkt anslutning
via ett Frame Relay nätverk. DLCIs delas normalt ut av den som tillhandahåller
Frame Relay nätverket.

<tag>Frame Relay</tag>Frame Relay är en nätverksteknik som är anpassad för att
bära trafik som är av oregelbunden natur. Nätverkskostnader reduceras genom att
flera Frame Relay kunder delar samma nätverkskapacitet och förväntas använda
kapaciteten vid olika tidpunkter.

<tag>hårdvaruadress</tag>Detta är ett nummer som unikt identifierar en dator i
ett nätverk på det länklagret. Exempel på detta är <em/Ethernetadresser/ och
<em/AX.25-adresser/.

<tag>ISDN</tag>Detta är en förkortning av <em>Integrated Services Digital
Network</em>. ISDN tillhandahåller ett standardiserat sätt på vilket telebolag
kan erbjuda antingen data- eller rösttjänster till en kund. Tekniskt sett är
ISDN ett datanätverk med virtuella kretsar.

<tag>ISP</tag>Detta är en förkortning av <em/Internet Service Provider/ 
(internetleverantör). Detta är de organisationer eller företag som erbjuder
nätverksanslutningar till Internet.

<tag>IP-adress</tag>Detta är ett nummer som unikt identifierar en TCP/IP dator
på ett nätverk. Adressen är 4 bytes lång och representeras ofta i vad som heter
"<em/punkterad decimal notation/", där varje byte skrivs för sig och de olika
bytearna är separerade med en `.'.

<tag>MTU</tag>Detta är en förkortning av <em/Maximum Transmission Unit/. MTU
är en parameter som bestämmer den största datagramstorleken som kan överföras
av ett IP-gränssnitt utan att det behöver delas upp i flera mindre delar. MTU
bör vara större än det största datagram som man vill skicka ofragmenterat. 
Notera att detta bara hindrar lokal fragmentering, om datagrammet passerar en 
länk med en mindre MTU så kan det fragmenteras där. Typiska värden för MTU är
1500 bytes för Ethernet och 576 bytes för SLIP.

<tag>route</tag>Routen (eller rutten) är den väg som datagrammen färdas genom
nätverket för att nå sin destination.

<tag>server</tag>Detta är vanligtvis den mjukvara eller del av systemet som 
är avlägset från användaren. Servern erbjuder tjänster till en eller flera
klienter. Exempel på servrar är <em/ftp/, <em/Networked File System/ och
<em/Domain Name Server/. I fallet med <em/peer to peer/ system, som 
<em/slip/ eller <em/ppp/, så är den dator som startar anslutningen klienten och
den andra datorn servern.
</descrip>

<sect><heading>Linux för en ISP?
<p>
Om man är intresserad av att använda Linux för ISP-syften så rekommenderar jag
att titta på 
<url url="http://www.anime.net/linuxisp/" name="Linux ISP homepage"> för en 
bra lista med pekare till information som kan vara användbar.

<sect><heading>Tillkännagivanden
<p>
Jag skulle vilja tacka följande personer för bidrag till detta dokument 
(ingen speciell ordningsföljd): Terry Dawson, Axel Boldt, Arnt Gulbrandsen, 
Gary Allpike, Cees de Groot, Alan Cox, Jonathon Naylor, Claes Ensson, 
Ron Nessim, John Minack, Jean-Pierre Cocatrix, Erez Strauss.

<sect><heading>Copyright.
<p>
NET-3-HOWTO, information om hur man installerar och konfigurerar nätverksstöd 
för Linux. Copyright (c) 1997 Terry Dawson.

Detta program är fri mjukvara; du kan distribuera det och/eller modifiera det
under reglerna som finns i GNU General Public License så som de publiceras av 
Free Software Foundation; antingen version 2 av licensen, eller (ditt eget val)
någon senare version.

Detta program distribueras med förhoppningen att det skall vara användbart, men
UTAN NÅGON GARANTI;se GNU General Public License för fler detaljer.

Du skall ha fått en kopia av GNU General Public License tillsammans med detta 
program; om inte, skriv till:

Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

</article>
