  Linux NET-3 HOWTO
  von Terry Dawson (terry@perf.no.itg.telecom.com.au)         
  und Peter Stterlin (pit@uni-sw.gwdg.de)
  v1.0, Dezember 1997

  Das Betriebssystem Linux enthlt bereits im Kernel Untersttzung fr
  fast alle Arten von Netzwerkprotokollen.  Ziel dieses Textes ist es,
  die Installation und Konfiguration der Netzwerk-Software unter Linux
  sowie der zugehrigen Hilfsprogramme zu beschreiben.
  

  1.  Einleitung

  Die ursprngliche Version des NET-FAQ wurde von Matt Welsh und Terry
  Dawson geschrieben, bevor das Linux Documentation Project gegrndet
  wurde.  Sein Ziel war es, hufig gestellte Fragen ber Linux und
  Netzwerke zu beantworten.  Es behandelte die frhen Entwickler-
  Versionen der netzwerkfhigen Linux Kernel.  Das NET-2-HOWTO setzte
  diese Aufgabe fort.  Es war einer der ersten Texte des LDP und
  beschrieb das was zunchst als Version 2 und spter als Version 3 der
  Linux Kernel Netzwerk Software bezeichnet wurde.  Der vorliegende Text
  ersetzt das NET-2-HOWTO, er beschreibt ausschlielich die (aktuelle)
  Version 3 der Netzwerk Software im Linux Kernel.

  Die frheren Versionen dieses Textes wurden stndig umfangreicher da
  der kleine Begriff "Netzwerk unter Linux" einen enormen Bereich
  abdeckt.  Um diesen Umfang etwas zu reduzieren wurden etliche HOWTOs
  geschrieben, die sich mit spezifischen Netzwerkproblemen befassen.  An
  den jeweiligen Stellen wird auf diese Dokumente hingewiesen, das
  NET-3-HOWTO selber behandelt lediglich noch solche Themen, die von den
  anderen HOWTOs nicht abgedeckt werden.

  1.1.  Feedback

  Kommentare und vor allem aktive Beitrge zu diesem Dokument sind
  jederzeit willkommen.  Bitte senden sie Hinweise/Kommentare zu dieser
  deutschen Version an mich (pit@uni-sw.gwdg.de).

  1.2.  Danksagung

  Folgenden Personen (ohne bestimmte Reihenfolge) sei an dieser Stelle
  fr ihre Beitrge zu diesem Text gedankt: Axel Boldt, Arnt
  Gulbrandsen, Gary Allpike, Cees de Groot, Alan Cox, Jonathon Naylor.

  1.3.  Copyright.

  Dieses Dokument ist urheberrechtlich geschtzt. Das Copyright fr die
  englische NET-3 HOWTO, auf der dieses Dokument basiert, liegt bei
  Terry Dawson. Das Copyright fr die deutsche Version liegt bei Peter
  Stterlin.

  Das Dokument darf gem der GNU General Public License verbreitet
  werden. Insbesondere bedeutet dieses, da der Text sowohl ber
  elektronische wie auch physikalische Medien ohne die Zahlung von
  Lizenzgebhren verbreitet werden darf, solange dieser Copyright
  Hinweis nicht entfernt wird. Eine kommerzielle Verbreitung ist erlaubt
  und ausdrcklich erwnscht. Bei einer Publikation in Papierform ist
  das Deutsche Linux HOWTO Projekt hierber zu

  2.  Wie gehe ich mit diesem Text um?

  Gegenber frheren Versionen hat sich das Format dieses Dokumentes
  gendert.  Die einzelnen Abschnitte wurden so umsortiert, da zu
  Beginn alles informative Material zusammengestellt ist.  Wen das nicht
  so sehr interessiert, der kann diesen Teil leicht berspringen.  Als
  nchstes folgen einige generelle Bemerkungen, die man unbedingt lesen
  und erstehen sollte, bevor man sich mit den spezifischen
  Technologieteilen befat, die den Rest des Textes ausmachen.

     Generelle Bemerkungen
        Lesen sie diesen Abschnitt unbedingt, er betrifft praktisch alle
        im folgenden beschriebenen Teile und ist zu deren Verstndnis
        unbedingt notwendig.

     Welche Art Netzwerk habe ich?
        Sie sollten sich darber informieren, welche Art von Netzwerk
        sie installiert haben oder installieren wollen, und welche
        diesbezgliche Hardware in ihrem Computer eingebaut ist/wird.

     Spezifische Abschnitte
        Lesen sie alle Abschnitte, die sich speziell mit der bei ihnen
        vorhandenen Hardware und Netztechnologie befassen.  Wer genau
        wei, was er will, findet hier alle fr eine einzelne
        Technologie relevanten Daten zusammengestellt.

     Die eigentliche Konfiguration
        Versuchen sie, ihr Netzwerk zu konfigurieren und notieren sie
        genau alle dabei eventuell auftretenden Probleme.

     Weitergehende Fragen
        Stoen sie bei der Konfiguration auf Probleme, die in diesem
        Text nicht behandelt werden, so lesen sie den Abschnitt ber
        weitergehende Hilfe und Fehlermeldungen.

     Viel Spa!
        Ein funktionierendes Netzwerk macht wirklich Spa, genieen sie
        es.

  3.  Allgemeine Information ber Netzwerke in Linux

  3.1.  Eine kurze Geschichte der Netzwerk-Kernelentwicklung

  Eine vllig neue Implementation des TCP/IP Protokolles im Kernel zu
  entwickeln, die mindestens so schnell ist wie bereits vorhandene war
  keine leichte Aufgabe.  Die Entscheidung, keinen der bereits
  vorhandenen Treiber zu bertragen fiel zu einem Zeitpunkt an dem es
  einige Unsicherheiten darber gab, ob ebendiese Implementationen mit
  einem restriktiven Copyright belegt werden wrden.  Auerdem war zu
  diesem Zeitpunkt der Enthusiasmus recht gro, diese Aufgabe auf eine
  andere Weise und womglich sogar besser als in den vorhandenen
  Treibern zu lsen.

  Der erste, der die Entwicklung des Linux Netzwerk-Codes leitete, war
  Ross Biro (biro@yggdrasil.com).  Er schrieb einen zwar nicht ganz
  vollstndigen aber dennoch gut brauchbaren Code, die durch einen
  Treiber fr die WD-8003 Netzwerk-Karte vervollstndigt wurde.  Dies
  reichte aus, um viele andere dazu zu bringen, diesen Code zu testen
  und mit ihm zu experimentieren.  Manchen ist es sogar bereits mit
  dieser Konfiguration gelungen, ihren Rechner an das Internet
  anzuschlieen.  Dadurch stieg im Linux-Umfeld der Druck, die
  Entwicklung des Netzwerk-Codes voranzutreiben.  Dieser unfaire Druck,
  wohl zusammen mit seinen privaten Verpflichtungen, veranlaten Ross,
  diese Rolle als Hauptentwickler aufzugeben.  Seine Bemhungen, das
  ursprnglich Projekt ins Rollen zu bringen und die Verantwortung dafr
  zu bernehmen, da dabei auch unter schwierigen Bedingungen etwas
  brauchbares herauskam wirkten als Katalysator fr alle folgenden
  Arbeiten und sind aus diesem Grund ein wesentlicher Baustein des
  Erfolges des heutigen Produktes.

  Die Programmierung des originalen BSD Socket Interface im Linux Kernel
  wurde von Orest Zborowski (obz@Kodak.COM) durchgefhrt.  Dies war ein
  gewaltiger Schritt nach vorne da es dadurch mglich wurde, eine groe
  Zahl von Netzwerkanwendungen ohne groen Aufwand fr Linux zu
  portieren.

  Ungefhr zu diesem Zeitpunkt schrieb Laurence Culhane
  (loz@holmes.demon.co.uk) den ersten SLIP-Treiber fr Linux.  Dadurch
  konnten endlich auch solche Leute mit dem Netzwerk experimentieren,
  die nicht ber Zugang zu einem Ethernet verfgten.  Auch dieser
  Treiber wurde weiterentwickelt, um eine Internetanbindung ber SLIP zu
  ermglichen.  Erneut stieg die Zahl derjeniger, die aktiv an der
  Erprobung und Weiterentwicklung der Netzwerk-Software mitarbeiten
  konnten, auch wurde vielen jetzt vor Augen gefhrt, was mit Linux
  alles mglich ist, wenn man erst einmal eine vollstndige
  Netzwerkuntersttzung hat.

  Einer dieser Personen die aktiv an der Netzwerkuntersttzung fr Linux
  arbeiteten war Fred van Kempen (waltje@uwalt.nl.mugnet.org).  Nach
  einer Phase der Ungewiheit, die auf den Rckzug von Ross folgte, bot
  Fred seine Zeit und Arbeitskraft fr diesen Posten an.  Fred hatte
  einige sehr ambitionierte Plne bezglich der Richtung, in die die
  Entwicklung des Linux Netzwerk-Codes gehen sollte, und er begann
  damit, die notwendigen Schritte zu tun.  Fred schrieb eine Version
  dieser Software, die als `NET-2' Kernel Code bezeichnet wurde (`NET'
  Code war die Version von Ross).  Diese Version konnte von vielen
  Leuten erfolgreich eingesetzt werden.  Fred schrieb auch einige
  Neuerungen in die Planbcher der Entwickler, so z.B. die dynamische
  Gerteschnittstelle, Untersttzung fr das Amateurfunk Protokoll AX.25
  sowie eine strker modularisierte Version der Software.  Freds
  Programme wurden zunchst von einigen Enthusiasten benutzt, deren Zahl
  aber stndig zunahm, je mehr sich herumsprach da die Software gut
  funktionierte.  Zu diesem Zeitpunkt bestand die Netzwerksoftware immer
  noch aus einer groen Anzahl von Patches gegenber dem Standard-
  Kernel, sie gehrte nicht zur normalen Distribution.  Das NET_FAQ und
  die folgenden NET-2-HOWTOs beschrieben die recht komplizierte
  Prozedur, all dies zum Laufen zu bekommen.  Freds Hauptaugenmerk lag
  darauf, Neuerungen zu entwickeln, und das beanspruchte Zeit.  Die
  Nutzergemeinschaft hingegen wartete immer ungeduldiger auf eine
  stabile Version, die fr 80% auch funktionierte.  Wie bereits bei Ross
  stieg der Druck auf Fred als Hauptentwickler.

  Alan Cox (iialan@www.linux.uk.org) schlug daraufhin eine Lsung des
  Problems vor.  Er wollte Freds NET-2 Code nehmen und die Fehler darin
  beseitigen, um so eine stabile und zuverlssige Version
  zusammenzustellen, die die ungeduldigen Nutzer zufriedenstellte und
  den Druck von Freds Schultern nahm, soda dieser seine eigentliche
  Arbeit verfolgen konnte.  Alan tat dies mit Erfolg, und seine erste
  Version wurde als `NET-2D(ebugged)' bezeichnet.  Sie arbeitete
  zuverlssig in vielen typischen Konfigurationen, und die Benutzer
  waren glcklich.  Alan hatte natrlich auch eigene Ideen und auch die
  Fhigkeiten, die er zum Projekt beitragen wollte, und in der Folgezeit
  gab es viele Diskussionen darber, in welche Richtung die Entwicklung
  des Netzwerk-Codes gehen solle.  Es bildeten sich zwei Lager in der
  Linux-Gemeinde.  Die eine vertrat die Ansicht, der Code msse zunchst
  funktionieren, dann knne man ihn verbessern, die andere Gruppe wollte
  ihn zunchst verbessern.  Linus fllte letztendlich die Entscheidung,
  indem er Alan seien Untersttzung anbot und seine Version in die
  offiziellen Kernel Distribution aufnahm.  Dadurch geriet Fred in eine
  schwierige Lage.  Jede Weiterentwicklung seines Codes htte nun nicht
  mehr die Verbreitung und breite Nutzerbasis, die fr ein gutes Testen
  ntig wre.  Dadurch wrde der Fortschritt langsam und schwierig
  werden.  Fred arbeitete noch eine zeitlang weiter, zog sich dann aber
  zurck und Alan wurde der neue Kopf der Netzwerk Entwicklung.

  Donald Becker (becker@cesdis.gsfc.nasa.gov) zeigte bald sein Talent
  auf dem Bereich des Low-Level Netzwerk-Codes und schuf eine groe Zahl
  von Ethernet-treibern;  fast alle in der Standard Kerneldistribution
  enthaltenen wurden von ihm entwickelt.  Auch einige andere Personen
  haben wichtige Beitrge geliefert, doch Donalds Arbeit war uerst
  fruchtbar und rechtfertigt so die besondere Erwhnung.

  Alan setzte seine Arbeit an der Verbesserung des NET-2D Codes fort,
  und beschftigte sich mit einigen Bereichen der `TODO' Liste, die
  bislang unbercksichtigt geblieben waren.  Mit der Stabilisierung der
  Kernelversionen der 1.3 Serie hatte auch der Netzwerk-Code den Schritt
  zur Version NET-3 vollzogen, auf dem auch die aktuellen Versionen
  basieren.  Alan arbeitete an unterschiedlichen Aspekten des Netzwerk-
  Codes und mit der Hilfe einer Zahl anderer talentierter Programmierer
  aus der Linux Gemeinschaft wuchs der Code in alle mglichen
  Richtungen.  Alan schrieb die dynamischen Netzwerk Devices und die
  ersten standardkonformen AX.25 und IPX Implementationen.  Seine
  Feinarbeit am Code hat Alan fortgesetzt und in auf den heutigen Stand
  verbessert.

  Untersttzung fr PPP wurde von Michael Callahan
  (callahan@maths.ox.ac.uk) und Al Longyear (longyear@netcom.com)
  implementiert.  Auch dies war ein wichtiger Schritt der die Anzahl
  derjenigen Nutzer erhhte, die Linux fr Netzwerkaufgaben einsetzten.

  Durch Jonathon Naylor (jsn@cs.nott.ac.uk) wurde der AX.25 Code von
  Alan deutlich verbessert und Untersttzung fr das NetRom Protokoll
  hinzugefgt.  Damit war Linux das einzige System das sich rhmen
  konnte, von Haus aus AX.25/NetRom zu untersttzen.

  Selbstverstndlich haben darberhinaus hunderte weiterer Personen
  wichtige Beitrge zur Weiterentwicklung der Netzwerk-Software fr
  Linux geliefert.  Einige dieser Namen werden weiter unten in den
  entsprechenden Abschnitten erwhnt, andere haben Module oder Treiber
  geschrieben, Fehler beseitigt, Vorschlge gemacht, Tests durchgefhrt
  oder einfach moralische Untersttzung geliefert.  Jeder von ihnen kann
  von sich sagen, seinen Teil zum Ganzen hinzugefgt zu haben.  Der
  Linux Netzwerk-Code ist ein hervorragendes Beispiel dafr, welch
  beeindruckende Ergebnisse der Linux-typische anarchische Stil der
  Entwicklung liefern kann.  Und diese Entwicklung geht natrlich noch
  immer weiter.

  3.2.  Wo bekomme ich weitere Informationen zum Netzwerk unter Linux?

  Alan Cox, der derzeit die Entwicklung des Netzwerk Codes leitet,
  unterhlt eine Seite im World Wide Web, die die Highlights der
  derzeitigen Entwicklung auflistet:

       http://www.uk.linux.org/NetNews.html

  Eine andere gute Quelle ist das Buch von Olaf Kirch: The Network
  Administrators Guide.  Dieser ist ein Teil des Linux Documentatation
  Project  und kann entweder via ftp in diversen Formaten besorgt werden

       sunsite.unc.edu:/pub/Linux/docs/LDP/network-guide/

  oder inzwischen auch direkt ber das Netz gelesen werden:

       http://sunsite.unc.edu/LDP/LDP/nag/nag.html

  Olafs Buch ist sehr verstndlich und gibt einen sehr tiefgehenden Ein
  blick in die Netzwerk Konfiguration unter Linux.

  Unter den Linux Newsgroups gibt es auch eine, die sich speziell mit
  allen Belangen des Netzwerkens befat: de.comp.os.linux.networking.

  Weiterhin besteht eine Mailing Liste zum Thema Netzwerke.  Um sie zu
  abonnieren gengt eine kurze Mail:

       To: majordomo@vger.rutgers.edu
       Subject: anything at all
       Message:

       subscribe linux-net

  Auf vielen der diversen IRC Netzwerke gibt es auch oft #linux Kanle.
  Dort ist meist auch jemand bereit und in der Lage, Hilfestellungen zum
  Thema Netzwerke zu geben.

  Eines sollte man aber immer beherzigen, wenn man mit seinen Problemen
  an die ffentlichkeit will:  Es sollte immer soviel wie mglich an
  relevanter Information angegeben werden.  Insbesondere sind das die
  Versionsnummern des Kernels und der Software wie z.B. pppd oder dip,
  sowie eine genaue Beschreibung der auftretenden Probleme.  Dies umfat
  auch den genauen Wortlaut etwaiger Fehlermeldungen sowie die genaue
  Syntax, mit der man ein Programm startet.

  3.3.  Nicht Linux-spezifische Informationsquellen.

  Wer nach einer grundlegenden Einfhrung in TCP/IP Netzwerke sucht, dem
  seien folgende Dokumente empfohlen:

     TCP/IP introduction
        entweder als Textversion (athos.rutgers.edu:/runet/tcp-ip-
        intro.doc)

        oder in PostScript Form (athos.rutgers.edu:/runet/tcp-ip-
        intro.ps)

     TCP/IP administration
        entweder als Textversion (athos.rutgers.edu:/runet/tcp-ip-
        admin.doc)

        oder in PostScript Form (athos.rutgers.edu:/runet/tcp-ip-
        admin.ps)

  Noch detailliertere Informationen zum TCP/IP Netzwerk findet man in
  folgendem Buch:

       "Internetworking with TCP/IP"
       von Douglas E. Comer

       ISBN 0-13-474321-0
       Prentice Hall publications.

  Das folgende Buch befat sich mit dem Schreiben von Netzwerk-
  Anwendungen in einer Unix Umgebung:

       "Unix Network Programming"
       von W. Richard Stevens

       ISBN 0-13-949876-1
       Prentice Hall publications.

  Ein guter Tip ist eventuell auch die Newsgroup comp.protocols.tcp-ip.

  Eine ungemein wichtige Quelle fr spezielle technische Informationen
  zu Internet und TCP/IP Netzwerken sind die RFC's.  RFC ist ein Akronym
  fr `Request For Comment', also `Bitte um Kommentar'.  Es handelt sich
  dabei um den Standard, in dem Internet Protokolle dokumentiert werden.
  Es gibt viele Stellen, an denen RFC's gesammelt und archiviert werden.
  Viele davon sind ber ftp erreichbar, manche bieten Zugang ber das
  WWW, dann oft gekoppelt mit Suchmaschinen, mit denen eine gezielte
  Stichwortsuche mglich ist.

  Eine mgliche Anlaufstelle ist die Nexor RFC database:

       http://pubweb.nexor.co.uk/public/rfc/index/rfc.html

  4.  Grundkonfiguration

  Die folgenden Abschnitte sollte man gut durchlesen, denn ihr
  Verstndnis ist sehr wichtig, bevor man mit der tatschlichen
  Konfiguration beginnen kann.  Es handelt sich um grundlegende
  Prinzipien die unabhngig davon sind, welche Art von Netzwerk
  letztendlich verwendet wird.

  4.1.  Was brauche ich fr den Anfang?

  Einige Dinge bentigt man, bevor man sich mit der Zusammenstellung und
  Konfiguration seines Netzwerkes beschftigen kann.  Die wichtigsten
  davon sind:

  4.1.1.  Aktuelle Kernel Quelldateien.

  Der derzeit installierte Kernel hat oft nicht die Treiber fr die
  gewnschte Hardware und Netzwerk-Protokolle eingebunden.  Hier ist
  eine Neukompilation des Kernels mit den entsprechenden Optionen
  notwendig.

  Die jeweils aktuelle Kernel-Version befindet sich auf

       ftp.funet.fi:/pub/Linux/PEOPLE/Linus/v2.0

  Normalerweise wird das Archiv mit den Quelltexten in das Verzeichnis
  /usr/src/linux entpackt.  Weiterfhrende Informationen dazu, wie man
  Patches einspielt und den Kernel bersetzt, findet man im Kernel
  HOWTO.  Die Konfiguration der verschiedenen Module beschreibt das
  Module HOWTO

  Solange nicht besonders auf eine besondere Kernel-Version verwiesen
  wird, sollte man bei den Standard-Kernels bleiben.  Dies sind die
  Versionen mit gerader zweiter Ziffer.  Die Entwickler-Kernel
  (gekennzeichnet durch eine ungerade zweite Ziffer, derzeit 2.1.xx)
  knnen strukturelle Vernderungen oder Test-Code enthalten, die im
  Zusammenspiel mit anderen Programmen des Systems zu Problemen fhren
  knnen.  Wer sich nicht sicher ist, da er mit derartigen
  Schwierigkeiten umgehen kann, sollte bei den Standard-Versionen
  bleiben.

  4.1.2.  Aktuelle Hilfsprogramme.

  Diese Programme (englisch: network tools) dienen dazu, die Netzwerk
  Devices (Kernel-Schnittstellen zur Hardware) zu konfigurieren.  Damit
  knnen also zum Beispiel Netzwerkadressen zugeordnet werden oder
  routes definiert werden.

  Normalerweise kommen alle neueren Linux Distributionen mit diesen
  Hilfsprogrammen.  Wer sie bei der Erstinstallation weggelassen hat,
  mu dies in jedem Fall nachholen.

  Wer keine fertige Distribution verwendet mu sich die Quellen selbst
  besorgen und die ntigen Programme kompilieren.  Dies ist aber nicht
  weiter schwierig.

  Sie werden betreut von Bernd Eckenfels und knnen via ftp bezogen
  werden, entweder von

       ftp.inka.de:/pub/comp/Linux/networking/NetTools/

  oder die Spiegelung

       ftp.linux.uk.org:/pub/linux/Networking/PROGRAMS/NetTools/

  Auf jeden Fall mu man sich vergewissern, da die Version sich auch
  mit dem eingesetzten Kernel vertrgt.  Um die gegenwrtig (also als
  dieser Text geschrieben wurde) aktuelle Version zu installieren geht
  man wie folgt vor:

       #
       # cd /usr/src
       # tar xvfz net-tools-1.32-alpha.tar.gz
       # cd net-tools-1.32-alpha
       # make config
       # make
       # make install
       #

  Wer auerdem auch beabsichtigt, ein Firewall aufzusetzen oder IP
  Masquerading zu verwenden, wird darberhinaus das Programm ipfwadm
  bentigen.  Die aktuellste Version bekommt man ber
  ftp.xos.nl:/pub/linux/ipfwadm.  Auch dort gibt es unterschiedliche
  Versionen, man mu deshalb darauf achten die fr den eigenen Kernel
  passende auszuwhlen.

  Die Installation ist dann ganz einfach (wieder am Beispiel der gerade
  aktuellen Version):

       #
       # cd /usr/src
       # tar xvfz ipfwadm-2.3.0.tar.gz
       # cd ipfwadm-2.3.0
       # make
       # make install
       #

  4.1.3.  Anwendungsprogramme.

  Mit `Anwendungen' sind hier Programme wie telnet oder ftp sowie die
  zugehrigen Server gemeint.  David Holland (dholland@hcs.harvard.edu)
  verwaltet inzwischen eine Distribution mit den am weitesten
  verbreiteten dieser Programme.  Man erhlt sie hier:

       ftp.uk.linux.org:/pub/linux/Networking/base

  Zur Installation der derzeit aktuellen Version geht man folgendermaen
  vor:

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

  4.1.4.  Adressen.

  Die reinen Internet Protokoll Adressen bestehen aus 4 Bytes.
  Standardmig schreibt man diese in einer durch Punkte getrennten
  Dezimalschreibweise:  Jedes Byte wird in eine Dezimalzahl umgewandelt
  (0-255), wobei fhrende Nullen weggelassen werden (auer wenn die Zahl
  Null ist).  Diese vier Zahlen werden dann, durch einen Dezimalpunkt
  `.'  getrennt, hintereinander aufgeschrieben.  Fr gewhnlich bekommt
  jedes Interface eines Rechners eine eigene IP Adresse.  Es ist zwar
  erlaubt, da verschiedene Schnittstellen eines Rechners dieselbe
  Adresse verwenden, dies wird aber normalerweise nicht gemacht.

  Ein Internet Protokoll Netzwerk besteht aus einer fortlaufenden
  Sequenz von IP Adressen.  Alle Adressen innerhalb eines solchen
  Netzwerkes haben einige Ziffern mit den anderen gemeinsam.  Dieser
  bereinstimmende Teil wird als `Netwerk-Anteil' bezeichnet, die
  verbleibenden Ziffern bilden den Host-Anteil (Rechner-Teil).  Die
  Anzahl an Bits die bei allen Adressen im Netz gleich ist, bezeichnet
  man als netmask.  Ihre Aufgabe is es festzustellen, ob ein Rechner zu
  diesem Netzwerk gehrt, oder nicht.  Hier ein Beispiel:

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

  Jede Adresse, die bitweise mit der netmask durch ein logisches AND
  verknpft wird, ergibt so die Adresse des Netzwerkes, zu der sie
  gehrt.  Die Netzwerk-Adresse besitzt deshalb immer die kleinste
  Nummer aus dem Bereich des Netzwerkes, und der Host-Anteil ist immer
  Null.

  Die Broadcast Adresse ist eine besondere Adresse, auf die jeder
  Rechner eines Netzwerkes zustzlich zu seiner eigenen, eindeutigen
  reagiert.  An diese Adresse werden Datagramme gesendet, die jeder
  Rechner im Netzwerk erhalten soll.  Einige besondere Datentypen wie
  Routing-Informationen oder Warnungen werden ber diese Broadcast
  Adresse verbreitet, damit alle Rechner sie sofort erhalten.  Es gibt
  zwei verwendete Standards dafr, wie eine solche Broadcast-Adresse
  aussieht.  Am weitesten verbreitet ist es, die hchste Nummer des
  Adressbereiches zu verwenden, im obigen Beispiel also die
  192.168.110.255.  An einigen Stellen wird auch die Netzwerk-Adresse
  fr diesen Zweck verwendet.  In der Praxis ist es egal, welche dieser
  Adressen verwandt wird.  Es mu nur sichergestellt sein, da alle
  Rechner des Netzes mit derselben Broadcast-Adresse konfiguriert
  werden.

  In einer recht frhen Phase der Entwicklung des IP Protokolles wurden
  einige willkrlich gewhlte Bereiche des Adressraumes zu Netzwerken
  zusammengefat, die man als Klassen bezeichnet.  Diese Klassen stellen
  die Standard-Gren fr ein Netzwerk dar, die Aufteilung ist wie
  folgt:

       ----------------------------------------------------------
       | Netzwerk|Netmask        | Netzwerk Adressen            |
       | Klasse  |               |                              |
       ----------------------------------------------------------
       |    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 |
       ----------------------------------------------------------

  Welcher dieser Adressen man verwenden sollte hngt vom jeweiligen Fall
  ab, eventuell mu man eine Kombination der unten aufgefhrten Aktionen
  durchfhren.

     Anbinden eines einzelnen Linux-Rechners in ein bestehendes Netz
        In diesem Fall mu man sich an den Administrator des Netzes
        wenden und ihn um folgende Informationen bitten:

       IP Adresse fr den Rechner

       IP Netzwerk Adresse

       IP Broadcast Adresse

       IP Netmask

       Adresse des Routers

       Adresse des Domain Name Servers

        Mit diesen Angaben kann man dann sein Netzwerk unter Linux
        konfigurieren.

     Neubildung eines Netzwerkes, da keine Verbindung zum Internet hat
        Wer sich ein kleines privates Netzwerk zulegen will und nicht
        beabsichtigt, dieses jemals mit dem Internet zu verbinden, kann
        im Prinzip seine Adressen vllig frei auswhlen.  Aus
        Sicherheitsgrnden, und um trotzdem eine gewisse Konsistenz in
        der Adressenvergabe zu wahren, wurden jedoch einige Bereiche des
        Adressraumes speziell fr diesen Zweck reserviert.  Sie sind im
        RFC1597 festgelegt:

     -----------------------------------------------------------
     |           Adressbereiche f. private Nutzung             |
     -----------------------------------------------------------
     | Netzwerk| Netmask       | Netzwerk Adressen             |
     | Klasse  |               |                               |
     -----------------------------------------------------------
     |    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 |
     -----------------------------------------------------------

     Zuerst sollte man sich berlegen, wie gro das eigene Netz sein
     soll und dann einen geeigneten Bereich auswhlen.

  4.2.  Wo mu ich die Konfiguration durchfhren?

  Unter Linux gibt es unterschiedliche Anstze, wie die Boot-Prozedur
  abluft.  In jedem Fall wird aber, nachdem der Kernel geladen ist, ein
  Programm mit dem Namen init gestartet.  init liest dann die
  Konfigurationsdatei /etc/inittab und beginnt den eigentlichen Boot-
  Proze.  Es gibt verschiedene Versionen des init-Programmes, und das
  ist auch bereits der Hauptgrund fr die unterschiedlichen Bootkonzepte
  der verschiedenen Distributionen.

  Fr gewhnlich enthlt /etc/inittab einen Eintrag der Form

       si::sysinit:/etc/init.d/boot

  Diese Zeile legt den Namen desjenigen Shell-Scriptes fest, das den
  Bootproze steuert.  In gewisser Weise handelt es sich um das
  quivalent zu der Datei AUTOEXEC.BAT in DOS.

  Meist werden von diesem Script aus weitere Scripte aufgerufen, und oft
  ist eines davon dann fr die Konfiguration des Netzwerkes zustndig.

  Die folgende Tabelle gibt einen Anhaltspunkt, welche Dateien das fr
  die diversen Distributionen sind:

       -------------------------------------------------------------------------------
       Distrib. |Schnittstellen Konfig./Routing              |Server Initialisierung
       -------------------------------------------------------------------------------
       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-<ifname>|/etc/rc.d/init.d/network
       -------------------------------------------------------------------------------

  Die meisten modernen Distributionen stellen ein Programm zur
  Verfgung, mit dem man die gngigsten Netzwerk Schnittstellen
  konfigurieren kann.  Es lohnt sich auf jeden Fall diese Programme
  auszuprobieren, bevor man sich an eine manuelle Installation macht.

       --------------------------------------------
       Distrib   | Netzwerk Konfigurations Programm
       --------------------------------------------
       RedHat    | /sbin/netcfg
       Slackware | /sbin/netconfig
       --------------------------------------------

  4.3.  Anlegen der Netzwerk Schnittstellen.

  In vielen Varianten von Unix haben die verschiedenen Netzwerk Devices
  feste Eintrge im Verzeichnis /dev.  Nicht so bei Linux.  Hier werden
  diese Eintrge dynamisch von der Software angelegt, die entsprechenden
  Dateien in /dev mssen also nicht vorhanden sein.

  In fast allen Fllen werden die Device-Eintrge fr das Netzwerk
  automatisch von den jeweiligen Treibern angelegt, sobald diese bei der
  Initialisierung die entsprechende Hardware vorfinden.  So legt der
  Ethernet-Treiber z.B. die Schnittstellen eth[0..n] an, durchnumeriert
  in der Reihenfolge, in der die Hardware gefunden wird.  Der ersten
  Karte wird der Eintrag eth0 zugeordnet, der zweiten eth1 usw.

  Manche Device-Eintrge, insbesondere SLIP und PPP, werden jedoch erst
  aufgrund von Benutzerprogrammen angelegt.  Auch in diesem Fall gilt
  die sequentielle Durchnumerierung, sie werden eben nur nicht bereits
  beim Booten des Systems angelegt.  Das liegt daran, da sich die
  Anzahl der aktiven slip oder ppp Gerte bei laufendem Betrieb ndern
  kann - im Gegensatz zu Ethernetkarten.  Diese Flle werden spter
  genauer behandelt.

  4.4.  Konfiguration der Netzwerk Schnittstelle.

  Hat man sich alle bentigten Programme und Informationen besorgt, kann
  mit der Konfiguration der Netzwerk Schnittstelle begonnen werden.  Mit
  Konfiguration ist dabei gemeint, der Schnittstelle die Adresse
  zuzuteilen sowie fr andere einstellbare Parameter die richtigen Werte
  einzusetzen.  Das hierfr am meisten verwendete Programm ist ifconfig,
  das steht fr Interface Configure, also Schnittstellenkonfiguration.

  Ein typisches Beispiel fr den Einsatz von ifconfig ist etwa

       # ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up

  In diesem Fall wird die Schnittstelle eth0 mit der Adresse 192.168.0.1
  sowie der Netmask 255.255.255.0 konfiguriert.  Das abschlieende up
  aktiviert die Schnittstelle.

  Der Kernel hat einige voreingestellte Standardwerte fr viele der
  Konfigurationsparameter.  So kann man natrlich Netzwerkadresse und
  Broadcastadresse fr eine Schnittstelle festlegen.  Tut man dies
  nicht, wie im obigen Beispiel, dann versucht der Kernel fr diese
  Parameter vernnftige Werte anzunehmen.  Dies macht er anhand der
  Netzwerk-Klasse der angegebenen IP-Adresse.  In diesem Fall wre das
  ein Klasse-C Netz, dementsprechend benutzt der Kernel 192.168.0.0 als
  Netzwerk-Adresse und 192.168.0.255 als Broadcast-Adresse.

  ifconfig besitzt unzhlige Parameter.  Die wichtigsten davon sind

     up aktiviert die Schnittstelle

     down
        deaktiviert die Schnittstelle

     [-]arp
        (de-)aktiviert das Adress-Auflsungs-Protokoll.  (address
        resolution protocoll) fr diese Schnittstelle.

     [-]allmulti
        (de-)aktiviert den sogenannten promiscuous mode.  In diesem
        Modus kann man eine Schnittstelle anweisen auch Datenpakete
        anzunehmen, die nicht an diese Schnittstelle adressiert sind.
        Dies ist sehr wichtig fr Programme wie tcpdump.

     mtu N
        legt die MTU fest.

     netmask addr
        legt die Netzwerk Maske fr die Schnittstelle fest.

     irq addr
        legt den verwendeten Interrupt der Hardware fest.  Dies
        funktioniert aber nur fr einige wenige Gerte.

     [-]broadcast [addr]
        damit kann die Adresse fr Broadcast-Meldungen festgelegt werden
        oder die Annahme solcher Pakete abgeschaltet werden.

     [-]pointopoint [addr]
        hiermit wird die Adresse des Rechners am anderen Ende der
        Verbindung festgelegt, z.B. im Falle von SLIP und PPP
        Verbindungen.

     hw <type> <addr>
        damit lassen sich fr bestimmte Netzwerk-Typen die Hardware
        Adressen festlegen.  Das ist fr Ethernet kaum ntzlich, fr
        andere Typen wie AX.25 aber schon.

  ifconfig kann im Prinzip zur Konfiguration jeder beliebigen Netzwerk
  Schnittstelle verwendet werden.  Einige Programme wie pppd oder dip
  machen dies jedoch selbstndig, soda sich ein manueller Aufruf von
  ifconfig in diesem Fall erbrigt.

  4.5.  Konfiguration des Name Resolver.

  Der Name Resolver ist ein Teil der Standardbibliothek von Linux.
  Seine Aufgabe ist es, benutzerfreundliche Rechnernamen wie
  ftp.funet.fi in Rechnerfreundliche IP-Adressen wie 128.214.248.6 zu
  bersetzen.

  4.5.1.  Aus was besteht ein Name?

  Jeder ist wohl inzwischen mit Rechnernamen im Internet vertraut, doch
  mancher versteht nicht genau wie sie gebildet werden.  Namen im
  Internet haben eine hierarchische Struktur, bilden also so etwas wie
  einen Baum mit Verstelungen.  Eine Domain ist eine Gruppe von Namen.
  Eine solche Domain kann wiederum unterteilt sein in mehrere
  subdomains.  Eine toplevel domain ist eine domain, die nicht mehr
  subdomain einer anderen ist.  Diese Toplevel Domains sind im RFC-920
  festgelegt.  Beispiele fr die bekanntesten Toplevel Domains sind:

     COM
        Kommerzielle Organisationen

     EDU
        Bildung und Lehre

     GOV
        Regierungsstellen

     MIL
        Militrische Organisationen

     ORG
        Andere Organisationen

     Lnderkennzeichen
        Diese sind gebildet aus zwei Buchstaben, die fr ein Land stehen
        country.

  Jede dieser hchsten Domnen hat nun Unterdomnen.  So gibt es fr
  viele Lnder wieder eine Unterteilung entsprechend der hchsten
  Domnen, also etwa com.au und gov.au fr kommerzielle und staatliche
  Organisationen in Australien.  Aus historischen Grnden liegen
  praktisch alle nicht lnderspezifischen Toplevel Domnen in den USA,
  obwohl auch diese einen spezifischen Lnder-Code (.us)besitzen.

  Die nchste Ebene der Unterteilung stellt meist der Name der
  Organisation dar.  Weitere Unterdomnen sind dann sehr
  unterschiedlich, oft basieren sie auf internen Strukturen der
  jeweiligen Organisation, jedoch kann der Netzadministrator jedes ihm
  sinnvoll erscheinende Kriterium zur Unterteilung verwenden.

  Der erste, am weitesten links stehende Teil des Namens ist immer der
  eindeutige Name des jeweiligen Rechners, man bezeichnet ihn als
  hostname, der brige Teil rechts davon wird domainname genannt.  Beide
  zusammen bilden den Fully Qualified Domain Name.

  Am Beispiel meines eigenen Email Rechners ist der vollstndige
  Domainname perf.no.itg.telstra.com.au.  das heit der Rechnername
  (hostname) ist perf, der domainname no.itg.telstra.com.au.  Die
  oberste Domain (top level domain) ist Australien (.au) und es handelt
  sich um eine kommerzielle Organisation (.com).  Der Name der Firma ist
  telstra, und die Namensgebung der internen Unterdomnen basiert auf
  der Firmenstruktur, in diesem Fall befindet sich der Rechner in der
  Information Technology Group, Sektion Network Operation.

  4.5.2.  Welche Informationen brauche ich?

  Natrlich mu man wissen, zu welcher Domne der Rechner gehren soll.
  Weiterhin bentigt die Software, die das bersetzen von Namen in
  gltige IP-Adressen bernimmt, die Adresse eines Domain Name Servers,
  dessen IP-Nummer man sich ebenfalls besorgen mu.

  Es gibt insgesamt drei Dateien, die editiert werden mssen, auf jede
  von ihnen wird im folgenden eingegangen.

  4.5.3.  /etc/resolv.conf

  /etc/resolv.conf ist die zentrale Konfigurationsdatei fr den Name
  Resolver.  Das Format ist sehr einfach, es ist eine Textdatei mit
  einem Schlsselwort pro Zeile.  Normalerweise werden drei davon
  benutzt, dies sind:

     domain
        Dieser Eintrag bestimmt den Namen der lokalen Domain.

     search
        Mit diesem Eintrag kann man die Namen von zustzlichen Domnen
        angeben, in denen nach einem Hostnamen gesucht wird.

     nameserver
        Mit diesem Eintrag - es knnen mehrere davon angegeben werden -
        gibt man die IP Adresse eines Domain Name Servers an.

  Eine typische Datei /etc/resolv.conf sieht etwa so aus:

       domain maths.wu.edu.au
       search maths.wu.edu.au wu.edu.au
       nameserver 192.168.10.1
       nameserver 192.168.12.1

  In diesem Beispiel ist der Standard Domain Name, der an nicht
  vollstndige angegebene Rechnernamen angehngt wird, maths.wu.edu.au
  ist.  Wird der Rechner in dieser Domain nicht gefunden, wird auch in
  der Domne wu.edu.au gesucht.  Weiterhin sind zwei unabhngige
  Nameserver Eintrge vorhanden, beide knnen von der Name Resolver
  Software benutzt werden um Namen aufzulsen.

  4.5.4.  /etc/host.conf

  In der Datei /etc/host.conf knnen einige Verhaltensweisen der Name
  Resolving Software festgelegt werden.  Das Format dieser Datei ist
  ausfhrlich in der Online Hilfe zu resolv+(8) beschrieben.  Jedoch
  wird in praktisch allen Fllen das folgende Beispiel ausreichend sein:

       order hosts,bind
       multi on

  Mit diesen Eintrgen wird festgelegt, da die Software zunchst in der
  Datei /etc/hosts nach einer Namen - Adressen Zuordnung sucht, bevor
  der Nameserver gefragt wird.  Auerdem sollen alle gltigen
  Adresseintrge, die in /etc/hosts gefunden werden, als Antwort
  geliefert werden, und nicht nur der erste.

  4.5.5.  /etc/hosts

  In der Datei /etc/hosts knnen die IP Adressen von lokalen Rechnern
  eingetragen werden.  Ein Rechner, dessen Namen in dieser Datei
  auftaucht, wird auch ohne eine Nachfrage bei dem Domain Name Server
  gefunden.  Der Nachteil dabei ist aber, da man diese Datei selber auf
  dem aktuellen Stand halten mu, wenn sich die IP Adresse eines hier
  eingetragenen Rechners ndert.  In einem gut verwalteten System wird
  man hier meist nur Eintrge fr das Loopback Interface sowie den
  lokalen Rechnernamen vorfinden:

       # /etc/hosts
       127.0.0.1      localhost loopback
       192.168.0.1    this.host.name

  Wie man am ersten Eintrag sieht, sind auch mehrere Namen je
  Adresseintrag erlaubt.

  4.6.  Die Konfiguration des Loopback Interface.

  Das loopback Interface ist eine spezielle Schnittstelle, ber die man
  eine Verbindung zum eigenen Rechner aufbauen kann.  Es gibt einige
  Grnde, warum dies sinnvoll sein kann, zum Beispiel wenn man Netzwerk
  Software testen will, ohne dabei von anderen Teilnehmern des Netzes
  gestrt zu werden.  Die Standard IP Adresse fr dieses Loopback
  Interface ist 127.0.0.1.  Unabhngig, auf welchem Rechner man
  arbeitet, ein telnet 127.0.0.1 baut immer eine Verbindung zum lokalen
  Rechner auf.

  Die Konfiguration dieser Schnittstelle ist uerst einfach und sollte
  auf jeden Fall vorgenommen werden:

       # ifconfig lo 127.0.0.1
       # route add -host 127.0.0.1 lo

  Der route-Befehl wird im nchsten Kapitel ausfhrlich behandelt.

  4.7.  Routing.

  Routing ist ein wichtiges Thema, es lieen sich leicht Bnde damit
  fllen.  Obwohl die meisten nur recht geringe Ansprche an das Routing
  haben, trifft das fr einige nicht zu.  Im folgenden werden nur die
  grundlegenden Aspekte des Routing behandelt.  Wer weitergehende
  Informationen zu diesem Thema bentigt, der sei auf die
  Literaturhinweise zu Beginn dieses Dokumentes verwiesen.

  Zunchst zum Begriff selber: Was ist IP Routing?  Hier ist die
  Definition, die ich selber verwende:

       IP Routing ist der Proze ber den ein Rechner mit unter
       schiedlichen Netzwerkanbindungen entscheidet, ber welche
       Verbindung ein empfangenes IP Datagramm weitergeleitet wer
       den soll.

  Dies soll an einem Beispiel eines typischen Routers in einem Bro
  verdeutlicht werden.  Dieser habe eine PPP Verbindung zum Internet,
  bedient ber einige Ethernet Segmente lokale Workstations und ist ber
  eine weitere PPP Verbindung mit einer Zweigstelle verbunden.  Empfngt
  dieser Router nun ein Datagramm von irgendeiner dieser Verbindungen,
  so wird ber das Routing festgelegt, ber welche der Verbindungen das
  Datagramm weitergereicht wird.  Jeder Rechner bentigt das Routing,
  denn selbst der einfachste Rechner am Internet besitzt mindestens zwei
  Netzwerk Schnittstellen, nmlich das Loopback Interface sowie die
  normale Schnittstelle zum restlichen Netzwerk, also Ethernet, PPP oder
  SLIP.

  Also, wie funktioniert nun dieses Routing?  Jeder einzelne Rechner hat
  eine eigene Liste mit Vorschriften fr das Routing, man nennt sie die
  Routing Table.  Diese Tabelle enthlt Zeilen mit typischerweise
  mindestens drei Spalten.  Die erste Spalte enthlt die Zieladresse,
  die zweite Spalte die Schnittstelle, ber die das Datenpaket
  weitergeleitet werden soll, und die dritte enthlt optional die IP
  Adresse eines anderen Rechners (Gateway), der das Datenpaket zu seinem
  nchsten Etappenziel leitet.  Unter Linux kann man sich diese Tabelle
  mit dem folgenden Befehl ansehen:

       # cat /proc/net/route

  Der eigentliche Vorgang des Routing ist sehr einfach:  Ein eingehendes
  Datenpaket wird entgegengenommen, seine Zieladresse wird untersucht
  und mit den Eintrgen in der Tabelle verglichen.  Der Eintrag, der der
  Zieladresse am besten entspricht, wird selektiert und das Datenpaket
  an die in diesem Eintrag festgelegte Schnittstelle weitergeleitet.
  Ist fr die Adresse auch ein Gateway eingetragen, wird das Paket an
  diesen Rechner adressiert, andernfalls wird angenommen, da der Ziel
  rechner zu dem Netzwerk gehrt, mit dem die benutzte Schnittstelle
  verbunden ist.

  Um die Routing Table zu verndern gibt es einen speziellen Befehl.
  Dieser Befehl bernimmt die Kommandozeilenargumente und setzt sie in
  die entsprechenden Systemaufrufe um die den Kernel dazu veranlassen,
  die entsprechenden Eintrge in der Routing Table hinzuzufgen, zu
  entfernen oder zu verndern.  Aus naheliegenden Grnden heit dieser
  Befehl route.

  Ein einfaches Beispiel:  Nehmen wir an wir befinden uns an einem
  Ethernet Netzwerk.  Es sei ein Klasse C Netz mit der Adresse
  192.168.1.0.  Unsere eigene IP Adresse ist 192.168.1.10, und der
  Rechner 192.168.1.1 ist ein Router mit Verbindung zum Internet.

  Zunchst mu natrlich die Schnittstelle wie bereits beschrieben
  konfiguriert werden, also etwa

       # ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up

  Als nchstes mu in die Routing Table eingetragen werden, da Data
  gramme an alle Adressen 192.168.1.* direkt ber das Ethernet Device
  eth0 geleitet werden:

       # route add -net 192.168.0.0 netmask 255.255.255.0 eth0

  ber den Schalter -net im obigen Befehl wird dem route Programm
  mitgeteilt, da es sich um einen Eintrag fr ein ganzes Netzwerk han
  delt.  Die andere Alternative ist ein Eintrag host, bei dem nur eine
  einzige IP Adresse engegeben wird.

  Mittels diesem Eintrag ist der eigene Rechner nun in der Lage, zu
  allen anderen Rechnern im lokalen Ethernet IP Verbindungen aufzubauen.
  Doch was ist mit Rechnern, die sich auerhalb dieses Netzes befinden?

  Es wre sehr umstndlich und nicht praktikabel, fr jedes denkbare
  Netzwerk einen entsprechenden Eintrag anzufgen.  Aus diesem Grund
  gibt es eine Standardeinstellung in der festgelegt wird, wie mit
  Paketen zu verfahren ist, die nicht gesondert in der Routing Table
  aufgefhrt sind: die Default Route.  Im obigen Beispiel heit das:
  Alles was nicht im lokalen Netz ist, wird ber den Router
  weitergeleitet - der wird dann schon wissen, wie mit dem Paket zu
  verfahren ist.  Den entsprechenden Eintrag in der Routing Table
  erzeugt man folgendermaen:

       # route add default gw 192.168.1.1 eth0

  Durch den Parameter gw wird dem route-Befehl mitgeteilt da die fol
  gende Adresse die IP-Adresse eines Gateway Rechners oder eines Routers
  ist, an den die Pakete weitergeleitet werden.

  Die komplette Konfiguration sieht also so aus:

       # ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
       # route add -net 192.168.0.0 netmask 255.255.255.0 eth0
       # route add default gw 192.168.1.1 eth0

  Ein Blick in die rc-Dateien, die beim Bootproze das Netzwerk initial
  isieren, sollte hnliche Eintrge (wenn auch mit anderen Adressen)zu
  Tage bringen, denn es ist eine sehr verbreitete Konfiguration.

  Wir knnen uns nun an ein etwas komplizierteres Beispiel wagen.
  Nehmen wir an, wir wollten einen einfachen Router konfigurieren, z.B.
  den bereits erwhnten mit mehreren lokalen Netzen und einer PPP
  Verbindung zum Internet.  Fr drei lokale Ethernet Segmente wrde die
  Routing Table etwa folgendermaen aufgebaut:

       # route add 192.168.1.0 netmask 255.255.255.0 eth0
       # route add 192.168.2.0 netmask 255.255.255.0 eth1
       # route add 192.168.3.0 netmask 255.255.255.0 eth2
       # route add default ppp0

  Fr jede der an diesen Router angeschlossenen Workstations htte die
  Routing Table dieselbe einfache Form wie im vorangegangenen Beispiel,
  lediglich der Router mu alle drei Netzwerke separat auffhren, da er
  ja die Aufteilung der Datenpakete auf diese Netze durchfhren mu.
  Bleibt also nur noch die Frage, warum in der default route der Eintrag
  gw fehlt.  Der Grund dafr ist, da es sich bei einer PPP-Verbindung
  (ebenso wie bei einer Verbindung ber das SLIP Protokoll) um eine
  Verbindung zwischen genau zwei Rechnern handelt.  Der Kernel `wei'
  also welchen Rechner er ber die PPP-Verbindung anspricht, und die
  zustzliche Angabe einer Gateway-Adresse ist in diesem Falle
  berflssig.  Lediglich fr Ethernet-, Arcnet- oder Token Ring
  Verbindungen ist die Angabe einer Gatewayadresse zwingend
  vorgeschrieben, da hier ber eine Verbindung eine groe Zahl an Rechn
  ern erreicht werden kann.

  4.7.1.  Was macht das routed Programm?

  Die oben beschriebene Konfiguration ist optimiert auf einfache
  Netzwerke mit nur wenigen, unvernderlichen Pfaden zu den
  unterschiedlichen Zielen.  In einem komplexen Netzwerk werden die
  Dinge jedoch etwas schwieriger.  Doch zum Glck betrifft das nur die
  wenigsten.

  Das grte Problem des manuellen oder statischen Routing, das im
  vorigen Abschnitt beschrieben wurde, tritt auf, wenn ein
  (Verbindungs-) Rechner im Netzwerk ausfllt.  In diesem Fall besteht
  die einzige Mglichkeit, ein Datenpaket dennoch zum Ziel
  weiterzuleiten darin, von Hand einzugreifen und die entsprechenden
  Routes manuell einzutragen -- vorausgesetzt natrlich, es existiert
  solch ein alternativer Weg.  Das ist umstndlich, langsam und
  fehleranfllig.  Deshalb wurden unterschiedliche Mechanismen
  entwickelt, um die Routing Table automatisch anzupassen, falls ein
  Netzwerkfehler auftritt und `Umwege' zum Ziel bekannt sind.  All diese
  Techniken bezeichnet man als dynamische Routing Protokolle.

  Die bekanntesten dynamischen Protokolle sind RIP (Routing Information
  Protocol) und OSPF (Open Shortest Path First Protocol).  RIP ist
  besonders in kleinen Netzwerken wie mittelgroen Betrieben oder
  Gebude-Netzwerken sehr verbreitet.  OSPF ist moderner und
  insbesondere darauf ausgelegt, in groen Netzwerken benutzt zu werden,
  in denen es eine groe Zahl an Wegen durch das Netzwerk gibt.  Die am
  weitesten verbreiteten Vertreter dieser Protokolle sind routed (RIP)
  und gated (OSPF).  routed ist normalerweise Bestandteil jeder Linux
  Distribution, sonst bekommt man es mit dem Paket NetKit (s.o.).

  Ein Beispiel fr die Verwendung dynamischen Routings ist die folgende
  Konfiguration:

      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

  Es gibt drei Router: A, B und C.  Jeder ist fr ein Ethernet Segment
  mit einem Klasse C IP Netzwerk (netmask 255.255.255.0) zustndig.
  Darberhinaus verfgt jeder Router ber jeweils eine PPP-Verbindung zu
  jedem der anderen beiden Router, diese Bilden also ein Dreieck.

  Ganz offensichtlich knnte die Routing Table fr Router A
  folgendermaen aussehen:

       # 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

  Dies funktioniert aber nur, solange die Verbindung zwischen Router A
  und B besteht.  Bricht diese Verbindung zusammen, knnen Rechner des
  Ethernet Segmentes von Router A keinen Rechner des Segmentes von
  Router B mehr erreichen, da A die Datagramme ber die PPP-Verbindung
  an B weiterreichen will.  Sie knnen immernoch Verbindungen zu den
  Rechnern des Segmentes C aufbauen, und diese wiederum knnen problem
  los mit Rechnern im Segment B kommunizieren, da die Verbindung zwis
  chen B und C immernoch besteht.

  Es wre also naheliegend da A die an B gerichteten Pakete an C sendet
  und diese dann von C an B weitergeleitet werden.  Fr genau diese Art
  von Problemen sind die dynamischen Protokolle wie RIP ausgelegt.
  Wrde auf jedem der drei Router A, B und C ein Routing Dmon laufen,
  wrden diese im Falle eines Netzwerkfehlers die Routing Tabellen der
  drei Router automatisch den neuen Gegebenheiten anpassen.  Ein
  derartiges Netz zu konfigurieren ist sehr einfach, es sind lediglich
  zwei Schritte notwendig.  Hier das Beispiel fr Router A:

       # route add -net 192.168.1.0 netmask 255.255.255.0 eth0
       # /usr/sbin/routed

  Der Routing Dmon routed erkennt beim Start automatisch alle aktiven
  Netzwerkschnittstellen und sendet und erkennt ber diese
  Schnittstellen Meldungen um festzustellen, ob nderungen in der Rout
  ing Table ntig sind.

  Die war nur eine sehr kurze Beschreibung, was dynamisches Routing ist,
  und in welchen Fllen man es verwendet.  Wer genauere Informationen
  bentigt sei auf die am Anfang dieses Textes genannten Quellen
  verwiesen.

  Wichtige Punkte im Zusammenhang mit dynamischen Routing sind:

  1. Einen Routing Dmon bentigt nur, wer auf seinem Rechner mehrere
     verschiedene mgliche Routes zu einer Zieladresse besitzt.

  2. Der Routing Dmon ndert automatisch die Routing Table, um sie an
     nderungen im Netzwerk anzupassen.

  3. RIP ist fr kleine und mittelgroe Netzwerke ausgelegt.

  4.8.  Die Konfiguration von Netzwerk Servern und Diensten.

  Netzwerk Server und Dienste bezeichnet diejenigen Programme, die es
  einem Nutzer von auerhalb (remote user) erlauben, ihren  Rechner zu
  benutzen.  Dieser Nutzer stellt eine Netzwerkverbindung zu ihrem
  Rechner, oder besser zu einem Server-Programm auf ihrem Rechner, her.
  Dieser Server, man nennt ihn auch Netzwerk Dmon, berwacht einen
  Port.  Er nimmt ankommende Verbindungswnsche entgegen und fhrt dann
  die jeweiligen Aktionen aus.  Es gibt zwei unterschiedliche Methoden,
  wie ein solcher Netzwerk-Dmon arbeitet:

     Standalone
        Der Dmon berwacht selber den Port. Im Falle einer ankommenden
        Verbindung bernimmt der Dmon selbst die Arbeit und stellt die
        gewnschte Dienstleistung zur Verfgung.

     slave des inetd Servers
        Der inetd Server ist ein besonderer Dmon der allgemein darauf
        spezialisiert ist, eingehende Netzwerkverbindungen zu
        beantworten.  Er besitzt eine eigene Konfigurationsdatei in der
        festgelegt wird, welche Programme er starten mu wenn auf einem
        Port eine tcp oder udp Anfrage eintrifft.  Diese Ports werden in
        einer anderen Datei beschrieben, davon spter mehr.

  Es gibt zwei wichtige Konfigurationsdateien, die an die eigenen
  Bedrfnisse angepat werden mssen.  Dies sind /etc/services, in dem
  den unterschiedlichen Portnummern Namen zugeordnet werden, und
  /etc/inetd.conf, die Konfigurationsdatei des inetd Netzwerkdmons.

  4.8.1.  /etc/services

  Die Datei /etc/services ist eine einfache Datenbasis, die jedem Port
  einen fr Menschen leichter verstndlichen Namen zuordnet.  Das Format
  dieser Datei ist sehr einfach: Es handelt sich um eine Textdatei, und
  jede Zeile stellt einen Eintrag der Datenbasis dar.  ein solcher
  Eintrag besteht aus drei Feldern, durch beliebig viele Leerzeichen
  getrennt.  Diese drei Felder sind:

  Name      Port/Protokoll       Aliases     # Kommentar

     Name
        Ein einzelnes Wort, welches den jeweiligen Service beschreibt.

     Port/Protokoll
        Dieses Feld besteht aus zwei Eintrgen.

        Port
           Eine Nummer, die die Portnummer angibt, unter der der
           jeweilige Service angesprochen werden kann.  Die meisten der
           blichen Services haben festgelegte Nummern, dies wird in
           RFC-1340 beschrieben.

        Protokoll
           Je nach verwendetem Protokoll steht hier tcp oder udp

        Es ist wichtig darauf hinzuweisen da ein Eintrag 18/tcp etwas
        ganz anderes ist als ein Eintrag 18/udp.  Es gibt keinen tech
        nischen Grund warum ein Service ber beide Protokolle zur
        Verfgung stehen sollte.  Nur in seltenen Ausnahmefllen ist
        dies der Fall, dann wird man beide Eintrge, also fr udp und
        tcp finden.

     Aliases
        Zustzliche Namen, unter denen dieser Service angesprochen
        werden kann.

  Jeglicher Text nach dem Hash-Zeichen (#) wird ignoriert.

  4.8.1.1.  Ein Beispiel fr /etc/services.

  Alle modernen Linux Distributionen enthalten bereits eine gute Version
  dieser Datei.  Falls aber jemand seinen eigenen Rechner von Grund auf
  selber aufbauen will, hier ist die mit der Debian Distribution
  gelieferte Version.

  # /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

  4.8.2.  /etc/inetd.conf

  Die Datei /etc/inetd.conf ist die Konfigurationsdatei des Server
  Dmons inetd.  Bei einer eingehenden Anfrage nach einem bestimmten
  Service sieht der Dmon in dieser Datei nach, was zu tun ist.  Fr
  jeden Service, den man anbieten will, mu ein entsprechender Eintrag
  vorhanden sein in dem festgelegt wird, welcher Damon bei einer
  Anfrage gestartet werden soll, und wie dies zu geschehen hat.

  Auch hier ist das Dateiformat sehr einfach, es handelt sich ebenfalls
  um eine reine Textdatei, in der in jeder Zeile ein anzubietender
  Service beschrieben wird. Das Zeichen #dient als Kommentarzeichen,
  nachfolgender Text wird ignoriert. Jede Zeile enthlt sieben Felder,
  die jeweils durch eine beliebige Anzahl von Leerzeichen oder
  Tabulatoren voneinander getrennt sind. Die Bezeichnungen der einzelnen
  Felder sind folgende:

       service  socket_type  proto  flags  user  server_path  server_args

     service
        Name des Dienstes, entsprechend dem Eintrag in tc/services.

     socket_type
        Dieser Eintrag beschreibt den Typ des Socket, der fr den Dienst
        gilt. Erlaubte Eintrge sind stream, dgram, raw, rdm und
        seqpacket. Die Grnde fr die Unterteilung sind technischer
        Natur, aber als Faustregel kann man davon ausgehen, da
        praktisch alle tcpbasierten Dienste stream verwenden, whrend
        udp-basierte Dienste dgram benutzen. Nur in ganz seltenen Fllen
        wird ein Dienst einen anderen Typ verwenden.

     proto
        Das fr diesen Service gltige Protokoll. Es mu mit dem Eintrag
        in /etc/services bereinstimmen, normalerweise also entweder
        tcpoder udp.  Fr Server, die Sun RPC (Remote Procedure Call)
        verwenden, lauten die Eintrge rpc/tcp oder rpc/udp.

     flags
        Hier gibt es nur zwei mgliche Eintrge. Dem inetd Server wird
        damit angezeigt, ob das gestartete Serverprogramm den Socket
        nach dem Start wieder freigibt oder nicht.  Danach entscheidet
        sich, ob fr eine weitere eingehende Anfrage ein neuer Proze
        gestartet werden mu, oder ob der laufende Proze auch die neuen
        Anfragen bearbeitet. Die Regeln hierfr sind etwas schwierig,
        aber auch hier gilt als Faustregel: tcp-Dienste bentigen den
        Eintrag nowait, udp-Dienste verwenden wait. Es gibt hier aber
        etliche Ausnahmen, im Zweifelsfall sollte man sich am Beispiel
        orientieren.

     user
        Dieser Eintrag legt den Nutzernamen entsprechend /etc/passwd
        fest, mit dessen Rechten der Server gestartet wird. Dies wird
        oft aus Sicherheitsgrnden gemacht. Verwendet man hier der
        Benutzer nobody, so werden die mglichen Folgeschden
        eingegrenzt, sollte doch jemand die Sicherheitsmechanismen des
        Systems umgehen. Allerdings bentigen viele Server die Rechte
        des Systemadministrators, deshalb steht hier meist root.

     server_path
        Dies ist der Name inklusive vollem Pfad des zu startenden
        Servers.

     server_args
        Dieser Eintrag umfat die gesamte restliche Zeile und ist
        optional. Hier knnen zustzliche Argumente fr das
        Serverprogramm bergeben werden.

  4.8.2.1.  Ein Beispiel fr /etc/inetd.conf

  Wie auch im Falle von /etc/services gehrt ein funktionierendes
  /etc/inetd.conf zum Standardumfang jeder Distribution. Der
  Vollstndigkeit halber hier die Version der Debian Distribution.

  # /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

  4.9.  Weitere Konfigurationsdateien im Netzwerkumfeld.

  Es gibt noch eine ganze Reihe an Dateien, die mit der
  Netzwerkkonfiguration unter Linux zu tun haben. Die meisten davon wird
  man nie verndern mssen, es lohnt sich aber dennoch, sie kurz zu
  beschreiben, damit klar wird was darinsteht, und wozu sie gut sind.

  4.9.1.  /etc/protocols

  /etc/protocols ist eine Datei, in der Protokollnamen und
  Identifikationsnummern einander zugeordnet werden. Sie wird vorwiegend
  von Programmierern verwendet, damit sie in ihren Programmen die
  Dienste anhand ihres Namens verwenden knnen, auerdem von Programmen
  wie tcpdump, um anstelle von Nummern Namen ausgeben zu knnen.  Die
  Standardsyntax dieser Datei ist

       Protokollname  Nummer  Alias

  Die Datei /etc/protocols der Debian Distribution sieht so aus:

  # /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

  4.9.2.  /etc/networks

  Die Datei /etc/networks hat eine hnliche Funktion wie /etc/hosts. Es
  stellt eine einfache Datenbasis fr die Zuordnung von Netzwerknamen
  und -adressen dar. Der einzige Unterschied zu letzterem besteht darin,
  da nur zwei Eintrge je Zeile erlaubt sind, und zwar folgendermassen:

       Netzwerkname  Netzwerkadresse

  Auch hier ein kleines Beispiel:

       loopnet    127.0.0.0
       localnet   192.168.0.0
       amprnet    44.0.0.0

  Bei Programmen wie routewird ein Netzwerk, das einen Eintrag in
  /etc/networks hat, mit seinem Namen anstelle der reinen
  Netzwerkadresse angezeigt.

  4.10.  Netzwerksicherheit und Zugangskontrolle

  Zu Beginn dieses Abschnittes eine kleine Warnung: Einen Rechner oder
  gar ein Netzwerk gegen unerlaubtes Eindringen abzusichern ist ein
  uerst schwieriges Unterfangen. Ich selber betrachte mich nicht als
  Experten auf diesem Gebiet, und obwohl die im folgenden beschriebenen
  Mechanismen sicherlich hilfreich sind mchte ich all denen, die
  wirklich um die Sicherheit ihres Systems besorgt sind, raten, selber
  geeignete Literatur zu suchen. Im Internet findet man viele gute
  Hinweise dazu.

  Ein wichtiger Grundsatz zur Sicherheit ist Aktivieren sie keine
  Dienste, die sie nicht bentigen.  Die meisten Distributionen sind
  heute mit einer Vielzahl von Servern ausgestattet, die beim Bootproze
  automatisch gestartet werden. Um ein Mindestma an Systemsicherheit zu
  gewhrleisten sollten Sie sich die Datei /etc/inetd.conf in Ruhe
  ansehen und alle nichtbentigten Dienste durch Einfgen eines # am
  Zeilenanfang auszukommentieren. Gute `Kandidaten' hierfr sind shell,
  login, exec, uucp und ftp sowie informelle Dienste wie finger, netstat
  und systat.

  Es gibt eine groe Zahl an Sicherheits- und
  Zugangskontrollmechanismen, ich werde im folgenden die wichtigsten
  davon kurz beschreiben.

  4.10.1.  /etc/ftpusers

  Die Datei /etc/ftpusers bietet eine einfache Mglichkeit, einzelne
  Personen vom Zugang ber ftp auszuschlieen. Die Datei wird vom ftp-
  Dmonen ftpd gelesen, wenn eine FTP-Verbindung aufgebaut wird. Die
  Datei enthlt einfach eine Liste mit den Benutzernamen all derer,
  denen ein Login verboten werden soll.  Hier ein Beispiel:

       # /etc/ftpusers - users not allowed to login via ftp
       root
       uucp
       bin
       mail

  4.10.2.  /etc/securetty

  Mit dieser Datei wird festgelegt, an welchen (virtuellen) Terminals
  (ttys) sich der Systemverwalter root einloggen darf.  /etc/securetty
  wird vom Login-Programm (normalerweise /bin/login) gelesen und enthlt
  eine Liste der erlaubten Terminals, auf allen anderen kann root sich
  nicht einloggen:

       # /etc/securetty - tty's on which root is allowed to login
       tty1
       tty2
       tty3
       tty4

  4.10.3.  Die tcpd Hostzugangskontrolle

  Das Programm tcpd ist ihnen vielleicht schon in der Datei
  /etc/inetd.conf aufgefallen.  Es stellt Kontroll- und
  Zugangskontrollmechanismen fr diejenigen Dienste zur Verfgung, fr
  die es konfiguriert wird.

  Wird es von inetd gestartet so liest es zwei Dateien, anhand derer der
  Zugang zum berwachten Server gewhrt oder verboten werden kann.

  Die beiden Steuerdateien werden jeweils solange gelesen, bis ein
  zutreffender Eintrag gefunden wird. Wird ein solcher zutreffender
  Eintrag nicht gefunden, wird angenommen, da der Zugang fr jeden
  erlaubt ist. Gelesen werden die Dateien in der Reihenfolge
  /etc/hosts.allow, /etc/hosts.deny. Die beiden Dateien werden in den
  folgenden Abschnitten beschrieben.  Fr eine detaillierte Beschreibung
  sei auf die man Hilfeseiten verwiesen, host_access(5) ist hier ein
  guter Startpunkt.

  4.10.3.1.  /etc/hosts.allow

  Dies ist eine der Konfigurationsdateien des Programmes /usr/sbin/tcpd.
  In /etc/hosts.allow wird eingestellt, welchen anderen Rechnern der
  Zugang zu Diensten auf dem eigenen Rechner gestattet werden soll.  Das
  Dateiformat ist sehr einfach:

       # /etc/hosts.allow
       #
       # <service list>: <host list> [: command]

     service list
        Eine durch Kommata getrennte Liste von Namen der Dienste, fr
        die der Eintrag gelten soll, z.B. ftpd, telnetd oder fingerd.

     host list
        Eine durch Komma getrennte Liste von Rechnernamen, es knnen
        hier auch IP-Adressen angegeben werden. Auerdem knnen
        Platzhalter verwendet werden.  Beispiele hierfr sind
        gw.vk2ktj.ampr.org (bestimmter Rechner), .uts.edu.au (alle
        Rechner deren Name mit dieser Zeichenkette endet) oder 44. (alle
        IP-Adressen, die mit der angegebenen Ziffernfolge beginnen).
        Weiterhin existieren einige besondere, die die Konfiguration
        vereinfachen.  Einige davon sind ALL (jeder Rechner), LOCAL
        (Rechner ohne Dezimalpunkt "." im Namen, also solche der lokalen
        Domain) sowie PARANOID (Rechner, deren Namen nicht der Adresse
        entspricht; dient der Vermeidung von Spoofing). Ein letzter
        ntzlicher Eintrag ist EXCEPT. Dadurch knnen Listen mit
        Ausnahmen definiert werden, wie in einem spteren Beispiel
        erlutert wird.

     command
        Dies ist ein optionaler Parameter. Hier kann ein Programm mit
        seinem vollstndigen Pfad angegeben werden welches jedesmal
        ausgefhrt wird, wenn die entsprechende Regel erfllt ist. Es
        kann beispielsweise ein Programm gestartet werden das
        herauszufinden versucht, wer gerade auf dem anderen Rechner
        eingelogged ist, oder eine Meldung an den Systemadministrator
        schickt, da gerade jemand versucht, diesen Dienst zu nutzen.
        Zur Kommandogenerierung existieren einige Platzhalter, die
        automatisch gesetzt werden: %h ist der Name des Rechners, der
        die Verbindung aufbauen will, oder seine IP-Adresse. %d ist der
        Name des Dmons, der gestartet werden soll.

  Ein Beispiel:

       # /etc/hosts.allow
       #
       # Mail ist jedem erlaubt
       in.smtpd: ALL
       # Telnet und FTP nur von lokalen Rechnern sowie meinem Rechner zu Hause
       telnetd, ftpd: LOCAL, myhost.athome.org.au
       # Finger ist allen erlaubt, aber es wird protokolliert, woher die
       # Anfrage kommt
       fingerd: ALL: (finger @%h | mail -s "finger from %h" root)

  4.10.3.2.  /etc/hosts.deny

  Dies ist eine der Konfigurationsdateien des Programmes /usr/sbin/tcpd.
  In /etc/hosts.deny wird eingestellt, welchen anderen Rechnern der
  Zugang zu Diensten auf dem eigenen Rechner verboten werden soll.

  Ein einfaches Beispiel sieht etwa so aus:

       # /etc/hosts.deny
       #
       # Kein Zugang fuer Rechner mit suspektem Namen
       ALL: PARANOID
       #
       # Verbot fuer ALLE Rechner
       ALL: ALL

  Der Eintrag PARANOID ist hier redundant, da der folgende Eintrag in
  jedem Fall einen Zugang unterbindet. Jeder der beiden Eintrge ist
  eine sinnvolle Einstellung, abhngig von den jeweiligen Bedrfnissen.

  Die sicherste Konfiguration ist ein Eintrag ALL: ALL in
  /etc/hosts.deny zusammen mit einer Datei /etc/hosts.allow in der im
  einzelnen festgelegt wird, fr wen der Zugang erlaubt wird.

  4.10.4.  /etc/hosts.equiv

  Die Datei /etc/hosts.equiv erlaubt es, einzelnen Rechnern und
  Benutzern den Zugang zur eigenen Maschine ohne Pawortabfrage zu
  ermglichen. Dies ist in einer sicheren Umgebung hilfreich, in der man
  alle anderen Maschinen unter Kontrolle hat.  Andernfalls ist es aber
  ein groes Sicherheitsrisiko.  Denn der eigene Rechner ist nur so
  sicher wie der unsicherste Rechner, dem man vertraut.  Wer groen Wert
  auf hchste Sicherheit legt sollte diesen Mechanismus nicht verwenden,
  und auch den Nutzern nahelegen, die Datei .rhosts nicht zu verwenden.

  4.10.5.  Konfiguration des ftp Dmons

  Viele Besitzer von vernetzten Rechnern sind daran interessiert,
  anderen Personen das bertragen von Daten von und zum eigenen Rechner
  zu ermglichen, ohne ihnen einen expliziten Account einzurichten.
  Dazu dient der FTP Server.  Es mu aber sichergestellt sein, da der
  ftp-Dmon korrekt fr den anonymen Zugang konfiguriert ist. Die Seite
  ftpd(8) der Online-Hilfe beschreibt die dazu notwendigen Schritte in
  einiger Lnge. Diesen Tips sollte man unbedingt folgen.  Auerdem ein
  wichtiger Tip: Verwenden sie auf keinen Fall einfach eine Kopie der
  eigenen Datei /etc/passwd im anonymen Heimatverzeichnis /etc.  Stellen
  sie sicher, da alle unwichtigen Eintrge entfernt werden, sonst
  stehen Angriffen durch Pawortentschlsselung Tr und Tor offen.

  4.10.6.  Einrichtung eines Firewall

  Eine extrem sichere Methode gegen Angriffe ber das Netzwerk ist es,
  erst gar keine Datagramme an den Rechner heranzulassen.  Dieses wird
  in einem eigenen Dokument beschrieben, dem Firewall HOWTO.

  4.10.7.  Weitere Tips und Vorschlge

  Hier noch ein paar weitere Hinweise, auch wenn der eine oder andere
  davon geeignet ist, Glaubenskriege unter Unix-Administratoren
  hervorzurufen.

     sendmail
        Obwohl die Verwendung des sendmail-Dmons sehr weit verbreitet
        ist, taucht er mit erschreckender Regelmigkeit in Warnungen
        vor Sicherheitslchern auf. Es obliegt jedem selber, ob er
        sendmail verwenden will.

     NFS und andere Sun RPC Dienste
        Seien Sie vorsichtig damit. Es gibt bei diesen Diensten eine
        groe Zahl potentieller Sicherheitsrisiken.  Allerdings ist es
        schwierig, fr etwas wie NFS eine Alternative zu finden.  Wenn
        Sie diese Dienste benutzen, seien Sie vorsichtig, wem Sie einen
        Zugriff darauf erlauben.

  5.  Spezifische Informationen zur Netzwerk Technologie.

  Die Informationen in den folgenden Abschnitten sind jeweils spezifisch
  fr die jeweilige Technologie.  Die darin gemachten Aussagen gelten
  nicht automatisch auch fr andere Netzwerk Technologien.

  5.1.  ARCNet

  Die Device Namen fr ARCNET sind arc0s, arc1e, arc2e usw.  Der ersten
  gefundenen Karte wird automatisch der Eintrag arc0 zugewiesen, den
  weiteren Karten die folgenden Nummern in der Reihenfolge ihrer
  Detektion.  Der Buchstabe am Ende des Devicenamens gibt an, ob als
  Paketformat Ethernet Encapsulation oder RFC1051 ausgewhlt wurde.

  Optionen beim Kernel kompilieren:

       Network device support  --->
           [*] Network device support
           <*> ARCnet support
           [ ]   Enable arc0e (ARCnet "Ether-Encap" packet format)
           [ ]   Enable arc0s (ARCnet RFC1051 packet format)

  Ist die Untersttzung fr die Karte erst einmal im Kernel eingebunden,
  ist die Konfiguration einfach.  Typischerweise geschieht das etwa so:

       # ifconfig arc0e 192.168.0.1 netmask 255.255.255.0 up
       # route add 192.168.0.0 netmask 255.255.255.0 arc0e

  Die Datei /usr/src/linux/Documentation/networking/arcnet-hardware.txt
  enthlt weitere Informationen zu diesem Thema.

  Die ARCNet Untersttzung wurde von Avery Pennarun
  (apenwarr@foxnet.net) entwickelt.

  5.2.  Appletalk (AF_APPLETALK)

  Hierfr gibt es keine speziellen Device-Eintrge, da bestehende
  Netzwerk-Devices genutzt werden.

  Optionen beim Kernel kompilieren:

       Networking options  --->
           <*> Appletalk DDP

  Durch die Untersttzung von Appletalk kann ein Linux Rechner mit einem
  Apple Netzwerk zusammenarbeiten.  Eine wichtige Anwendung dafr ist
  die gemeinsame Nutzung von Druckern oder Festplatten ber ein Netzw
  erk.  Man bentigt dafr zustzliche Software: netatalk.  Wesley Craig
  (netatalk@umich.edu) steht stellvertretend fr ein Team an der Univer
  sity of Michigan, das sich `Research Systems Unix Group' nennt.  Sie
  haben das Paket netatalk mit der notwendigen Software entwickelt,
  nmlich der Implementation des Appletalk Protocoll Stack sowie weitere
  ntzliche Hilfsprogramme.  Das Paket netatalk ist entweder bereits
  Bestandteil ihrer Linux Distribution oder kann ber ftp von der Uni
  versity of Michigan bezogen werden

       terminator.rs.itd.umich.edu:/unix/netatalk/

  Um das Paket zu bersetzen und zu installieren geht man
  folgendermassen vor:

       # cd /usr/src
       # tar xvfz .../netatalk-1.4b2.tar.Z
       - Hier sollte man die Datei 'Makefile' editieren, um die Software an das
         eigene System anzupassen, z.B. die Variable DESTDIR, welche festlegt,
         wo die Dateien installiert werden.
       # make
       - als root:
       # make install

  5.2.1.  Die Konfiguration der Appletalk Software.

  Damit spter alles einwandfrei funktioniert, sind zunchst einige
  zustzliche Eintrge in der Datei /etc/services ntig. Diese sind:

       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

  Als nchstes mssen die Konfigurationsdateien im Verzeichnis
  /usr/local/atalk/etc angelegt werden (oder wo immer das Paket
  installiert wurde).

  Die erste Datei ist atalkd.conf, man bentigt hier vorlufig nur eine
  einzige Zeile in der festgelegt wird, ber welches Netzwerk Device die
  Apple Rechner erreicht werden:

       eth0

  Der Appletalk Dmon wird nach seinem Start weitere Details hinzufgen.

  5.2.2.  Exportieren eines Linux Dateisystems via Appletalk,

  Man kann Dateisysteme des Linuxrechners auch an Apple-Rechner
  exportieren, soda diese von beiden Rechnern gemeinsam genutzt werden
  knnen.

  Dafr mu man die Datei /usr/local/atalk/etc/AppleVolumes.system
  entsprechend konfigurieren.  Im selben Verzeichnis gibt es auerdem
  noch die Datei AppleVolumes.default.  Sie hat dasselbe Format und legt
  fest, welche Dateisysteme fr Nutzer zur Verfgung stehen, die sich
  als Gastnutzer anmelden.

  Die genauen Details fr diese Konfiguration entnehmen sie bitte der
  Manpage afpd.  Eine einfache Konfiguration knnte etwa so aussehen:

       /tmp Scratch
       /home/ftp/pub "Public Area"

  Dadurch wird das lokale Verzeichnis /tmp als AppleShare Volume
  angegeben werden.  Wenn sie fehlen, weist der Dmon automatisch
  passende Namen zu.

  5.2.3.  Gemeinsame Nutzung eines Druckers mit Appletalk.

  Die gemeinsame Nutzung eines Druckers lt sich einfach verwirklichen.
  Man mu dazu das Programm papd starten, den Appletalk Printer Access
  Protocol Dmon. Dieses Programm bernimmt die Druckauftrge von
  Applerechnern im Netz und leitet sie an den lokale Drucker Spool Dmon
  weiter.
  Zur Konfiguration dieses Dmon dient die Datei papd.conf. Die Syntax
  entspricht dabei der der Datei /etc/printcap. Der Name, der in der
  Datei definiert wird, wird dann ber das Appletalk Naming Protokoll,
  NBP, registriert.

  Hier eine Beispielkonfiguration:

       TricWriter:\
          :pr=lp:op=cg:

  Dadurch wird im Appletalk Netzwerk ein Drucker namens 'TricWriter' zur
  Verfgung gestellt.  Alle Druckauftrge an diesen Drucker werden durch
  den Drucker-Dmon lpd ber den Linux-Drucker lp (der in der Datei
  /etc/printcap definiert sein mu) ausgedruckt.  Der Eintrag op=cg legt
  fest, da der Druckauftrag unter der ID des Linux-Nutzers cg
  abgewickelt wird.

  5.2.4.  Starten der Appletalk Software.

  Nun ist alles soweit konfiguriert, der erste Test kann beginnen.  Zum
  Paket netatalk gehrt eine Datei rc.atalk, die fr Normalanwendungen
  funktionieren sollte. Alles was zu tun bleibt, ist diese Datei
  aufzurufen:

       # /usr/local/atalk/etc/rc.atalk

  und alles sollte einwandfrei laufen.  Fehlermeldungen sollten keine
  auftreten. Der Start der Software wird, ebenso wie weitere
  Statusmeldungen, ber die Konsole ausgegeben.

  5.2.5.  Testen der Appletalk Software.

  Um zu berprfen ob alles einwandfrei funktioniert begeben sie sich an
  einen ihrer Apple Rechner, ffnen sie das Apple Menue, whlen
  'Chooser' aus und klicken auf AppleShare.  Ihr Linux-Rechner sollte
  sich nun melden.

  5.2.6.  Nachteile der Appletalk Software.

    Unter Umstnden mssen sie die Appletalk-Untersttzung vor der
     Konfiguration des IP-Netzwerkes durchfhren.  Gibt es beim Start
     des Appletalk Programmes Probleme, oder haben sie nach dessen Start
     Probleme mit dem IP Netzwerk, versuchen Sie die Appletalk Software
     vor der Ausfhrung von /etc/rc.d/rc.inet1 zu starten.

    afpd (der Apple Filing Protocol Dmon) bringt die Festplatte
     ziemlich durcheinander. Er legt unterhalb des Mount-punktes eine
     Vielzahl von Verzeichnissen an:.AppleDesktop und Network Trash
     Folder.  Weiterhin wird darin fr jedes angesprochene Verzeichnis
     ein .AppleDouble angelegt, um darin Resource Forks usw. zu
     speichern.  berlegen sie es sich genau, bevor sie ihr
     Rootverzeichnis / exportieren.  Die Aufrumarbeiten hinterher haben
     es in sich.

    Das Programm afpd erwartet von Macs Paworte in Klartext,
     Sicherheitsbedenken sind also berechtigt.  Benutzen sie diesen
     Dmon auf einer Maschine, die selber am Internet hngt, mssen Sie
     sich an die eigene Nase fassen, wenn hinterher jemand diese
     Schwachstellen ausnutzt.

    Die vorhandenen Diagnosetools wie netstat oder ifconfig
     untersttzen kein Appletalk.  Die Information ist - unformatiert -
     ber /proc/net zugnglich.

  5.2.7.  Weitere Informationsquellen.

  Eine sehr viel detailliertere Beschreibung, wie man Appletalk fr
  Linux konfiguriert, finden sie auf der Seite Linux Netatalk HOWTO von
  Anders Brownworth bei

       http://thehamptons.com/anders/netatalk/

  5.3.  ATM

  Werner Almesberger (werner.almesberger@lrc.di.epfl.ch) leitet ein
  Projekt mit dem Ziel, auch unter Linux ATM (Asynchronous Transfer Mode
  ) zu untersttzen.  Den aktuellen Stand des Projektes erfhrt man
  ber:

       http://lrcwww.epfl.ch/linux-atm/

  5.4.  AX25 (AF_AX25)

  AX.25 Devicenamen sind sl0, sl1 usw. in 2.0.* Kernels or ax0, ax1
  usw.. in 2.1.* Kernels.

  Optionen beim Kernel kompilieren:

       Networking options  --->
           [*] Amateur Radio AX.25 Level 2

  Die Protokolle AX25, Netrom und Rose werden von Amateurfunkern fr
  Experimente mit Packet Radio genutzt. Eine Ausfhrliche Beschreibung
  enthlt das AX25 HOWTO

  Der Groteil der Arbeit bei der Implementation dieser Protokolle wurde
  von Jonathon Naylor (jsn@cs.not.ac.uk) geleistet.

  5.5.  DECNet

  An der Untersttzung von DECNet wird derzeit gearbeitet. Es wird
  vermutlich in den spten 2.1.* Kernels auftauchen.

  5.6.  EQL - Lastverteilung auf mehrere Leitungen.

  EQL Devices haben den Namen eql.  Mit Standard Kernels gibt es nur
  eines dieser Devices.  Es nutzt mehrere Point-to-Point Verbindungen
  (PPP, SLIP, Plip) und fat sie zu einer einzigen logischen Leitung
  zusammen, um darber eine TCP/IP Verbindung aufzubauen.  Hintergrund:
  Oft sind mehrere langsame Leitungen billiger als eine schnelle.

  Optionen beim Kernel kompilieren:

       Network device support  --->
           [*] Network device support
           <*> EQL (serial line load balancing) support

  Um diesen Mechanismus zu nutzen mssen beide Maschinen EQL
  untersttzen. Dies ist bei Linux, neueren Dial-in Servern und
  Livingstone Portmasters mglich.

  Um EQL richtig zu konfigurieren bentigen sie die EQL Tools:

       sunsite.unc.edu:/pub/linux/system/Serial/eql-1.2.tar.gz

  Die Konfiguration ist sehr logisch aufgebaut. Zunchst wird das EQL
  Interface konfiguriert. Es verhlt sich wie jedes andere
  Netzwerkinterface auch, man konfiguriert IP Adresse und MTU mittels
  ifconfig, also etwa so:

       ifconfig eql 192.168.10.1 mtu 1006
       route add default eql

  Als nchstes mssen die zu nutzenden Verbindungen von Hand aufgebaut
  werden. Jede denkbare Kombination von Point-to-Point Verbindungen ist
  mglich. Lesen sie diesbezglich die entsprechenden Abschnitte dieses
  Dokumentes.

  Nun mssen diese seriellen Verbindungen mit dem EQL Device verknpfen.
  Man nennt das 'enslaving', der entsprechende Befehl lautet
  eql_enslave, z.B.:

       eql_enslave eql sl0 28800
       eql_enslave eql ppp0 14400

  Die angegebene ungefhre Geschwindigkeit hat keinen direkten Hardware
  bezug. Der EQL Treiber nimmt diese Werte lediglich als Anhaltspunkt,
  um die Datagramme mglichst sinnvoll auf die vorhandenen Leitungen zu
  verteilen.  Man kann die Werte also fr das Feintuning durchaus frei
  verndern.

  Um eine Leitung wieder aus dem EQL Verbund zu entfernen dient der
  Befehl eql_emancipate. Wieder ein Beispiel:

  eql_emancipate eql sl0

  Das Routing wird wie fr jede andere Point-to-Point Verbindung
  aufgesetzt. Der einzige Unterschied ist, das anstelle des seriellen
  Device das EQL-Device angegeben wird:

       route add default eql0

  Der EQL Treiber wurde von Simon Janes (simon@ncm.com) entwickelt.

  5.7.  Ethernet

  Die Devicenamen fr Ethernet sind eth0, eth1, eth2 usw.  Der ersten
  gefundenen Karte wird eth0 zugewiesen, die weiteren werden fortlaufend
  durchnumeriert.

  Zur Inbetriebnahme einer Ethernetkarte unter Linux existiert ein
  eigenes HOWTO, das Ethernet HOWTO.

  Ist der Kernel mit Untersttzung fr Ethernetkarten kompiliert, ist
  die Konfiguration der Karte einfach.  Typischerweise verwendet man
  etwa folgende Befehle:

       # ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up
       # route add 192.168.0.0 netmask 255.255.255.0 eth0

  Die meisten der Treiber fr Ethernetkarten wurden von Donald Becker
  (becker@CESDIS.gsfc.nasa.gov) entwickelt.

  5.8.  FDDI

  Die Devicenamen fr FDDI sind fddi0, fddi1, fddi2 usw.  Der ersten
  gefundenen Karte wird fddi0 zugewiesen, die weiteren werden
  fortlaufend durchnumeriert.

  Lawrence V. Stefani (stefani@lkg.dec.com) hat einen Treiber fr die
  EISA und PCI Karten der Digital Equipment Corporation entwickelt.

  Optionen beim Kernel kompilieren:

       Network device support  --->
           [*] FDDI driver support
           [*] Digital DEFEA and DEFPA adapter support

  Ist der Kernel mit Untersttzung fr FDDI kompiliert, ist die
  Konfiguration praktisch identisch zu derjenigen eines Ethernet
  Interface: Es mssen lediglich die entsprechenden FDDI-Devicenamen
  angegeben werden.

  5.9.  Frame Relay

  Die Devicenamen fr Frame Relay sind dlci00, dlci01 usw. fr Devices
  mit DLCI Encapsulation und sdla0, sdla1 usw. fr solche mit FRAD.

  Frame Relay ist eine neue Netzwerktechnologie.  Sie wurde speziell fr
  Umgebungen entwickelt, in denen die Netzauslastung intermittierend
  ist, also oft kurzzeitig scharfe Spitzen auftreten.  Fr den Zugang zu
  einem Frame Relay Netzwerk bentigt man ein Frame Relay Access Device
  (FRAD).  Die Frame Relay Untersttzung unter Linux hlt sich an
  RFC-1490.

  Optionen beim Kernel kompilieren:

       Network device support  --->
           <*> Frame relay DLCI support (EXPERIMENTAL)
           (24)   Max open DLCI
           (8)   Max DLCI per device
           <*>   SDLA (Sangoma S502/S508) support

  Die Frame Relay Treiber und Konfigurationsprogramme wurden von Mike
  McLagan (mike.mclagan@linux.org) entwickelt.

  Derzeit sind allerdings nur diese Karten untersttzt: Sangoma
  Technologies (http://www.sangoma.com) S502A, S502E und S508.

  Um die FRAD und DLCI Devices zu konfigurieren bentigen Sie spezielle
  Programme, die Frame Relay Configuration Tools. Diese bekommen Sie bei

       ftp.invlogic.com:/pub/linux/fr/frad-0.15.tgz

  Kompilierung und Installation der Tools ist eigentlich kein Problem,
  allerdings gibt es kein zentrales Makefile.  Dadurch ist einige Han
  darbeit notwendig:

       # cd /usr/src
       # tar xvfz .../frad-0.15.tgz
       # cd frad-0.15
       # for i in common dlci frad; do cd $i; make clean; make; cd ..; 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

  Nach der Installation mssen sie die Datei /etc/frad/router.conf
  anlegen.  Dafr ist folgende Vorlage hilfreich (es ist eine
  abgenderte Version der Beispieldatei des Paketes):

  # /etc/frad/router.conf
  # Dies ist eine Beispielkonfiguration fuer Frame Relay.
  # Alle moeglichen Eintraege sind aufgefuehrt, die Standardeinstellungen
  # basieren auf dem Code des DOS-Treibers fuer die Karte
  # S502A von Sangoma.
  #
  # Ein '#' irgendwo in der Zeile leitet einen Kommentar ein
  # Leerzeilen werden ignoriert (TAB ist auch erlaubt).
  # Unbekannte Eintraege [] oder Zeichen werden ignoriert.
  #

  [Devices]
  Count=1                 # Anzahl zu konfigurierender Devices
  Dev_1=sdla0             # Name eines Device
  #Dev_2=sdla1            # Name eines Device

  # An dieser Stelle angegeben, gelten die Eintraege fuer alle Devices.
  # Sie koennen fuer einzelne Karten in den entsprechenden Abschnitten
  # veraendert werden.
  #
  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

  # An dieser Stelle angegeben, werden Standardwerte fuer alle Devices
  # festgelegt.
  # 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 spezifische Konfiguration
  #
  #

  #
  # Das erste Device ist eine Sangoma S502E
  #
  [sdla0]
  Type=Sangoma            # Art des Device
                          # SANGOMA ist bekannt
  #
  # Diese Eintraege sind spezifisch fuer Sangoma
  #
  # Typ der Sangoma Karte - S502A, S502E, S508
  Board=S502E
  #
  # Name der Test-Firmware fuer das Sangoma Board
  # Testware=/usr/src/frad-0.10/bin/sdla_tst.502
  #
  # Name der FR Firmware
  # Firmware=/usr/src/frad-0.10/bin/frm_rel.502
  #
  Port=360                # Port fuer diese Karte
  Mem=C8                  # Address fuer Memory Window, A0-EE
  IRQ=5                   # IRQ Nummer, fuer S502A nicht angeben
  DLCIs=1                 # Anzahl der DLCI's an diesem Device
  DLCI_1=16               # DLCI #1's number, 16 - 991
  # DLCI_2=17
  # DLCI_3=18
  # DLCI_4=19
  # DLCI_5=20
  #
  # Hier angegeben, gelten die Eintraege nur fuer die jeweilige Karte und
  # ueberschreiben im globalen Teil gemachte Einstellungen.
  #
  # Access=CPE            # CPE oder NODE, Default ist CPE
  # Flags=TXIgnore,RXIgnore,BufferFrames,DropAborted,Stats,MCI,AutoDLCI
  # Clock=Internal        # External oder Internal, Default ist Internal
  # Baud=128              # Angegebene Baud Rate des angeschlossenen CSU/DSU
  # MTU=2048              # Maximale IFrame Laenge, Default ist 4096
  # T391=10               # T391 value    5 - 30, Default ist 10
  # T392=15               # T392 value    5 - 30, Default ist 15
  # N391=6                # N391 value    1 - 255, Default ist 6
  # N392=3                # N392 value    1 - 10, Default ist 3
  # N393=4                # N393 value    1 - 10, Default ist 4

  #
  # Die zweite Karte ist irgend eine andere Karte
  #
  # [sdla1]
  # Type=FancyCard        # Art des Device
  # Board=                # Typ des Sangoma board
  # Key=Value             # Eintraege spezifisch fuer dieses Device

  #
  # DLCI Default Konfigurationsparameter
  # Diese koennen in den jeweiligen spezifischen Abschnitten
  # ueberschrieben werden.
  #
  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 Konfiguration
  # Alle Eintraege sind optional.  Namenkonvention ist:
  # [DLCI_D<devicenum>_<DLCI_Num>]
  #

  [DLCI_D1_16]
  # IP=
  # Net=
  # Mask=
  # Von Sangoma definierte Flags sind: 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=
  # Von Sangoma definierte Flags sind: TXIgnore,RXIgnore,BufferFrames
  # DLCIFlags=TXIgnore,RXIgnore,BufferFrames
  # CIRfwd=16
  # Bc_fwd=16
  # Be_fwd=0
  # CIRbak=16
  # Bc_bak=16
  # Be_bak=0

  Ist die Datei /etc/frad/router.conf angelegt, bleibt nur noch die
  Konfiguration der eigentlichen Devices.  Dies ist nicht viel
  schwieriger als die bliche Konfiguration eines Netzwerk Devices.  Man
  mu nur daran denken, die FRAD Devices vor den DLCI Devices zu
  konfigurieren.

       # Konfiguriere FRAD Hardware und DLCI Parameter
       /sbin/fradcfg /etc/frad/router.conf || exit 1
       /sbin/dlcicfg file /etc/frad/router.conf
       #
       # Aktiviere FRAD Device
       ifconfig sdla0 up
       #
       # Konfiguriere das DLCI Encapsulation Interface und Routing
       ifconfig dlci00 192.168.10.1 pointopoint 192.168.10.2 up
       route add 192.168.10.0 netmask 255.255.255.0 dlci00
       #
       ifconfig dlci01 192.168.11.1 pointopoint 192.168.11.2 up
       route add 192.168.11.0 netmask 255.255.255.0 dlci00
       #
       route add default dev dlci00
       #

  5.10.  IP Accounting

  IP Accounting im Kernel erlaubt es, Daten ber die Nutzung des
  Netzwerkes zu sammeln und zu analysieren. Die Daten umfassen die
  Anzahl der Pakete bzw. Bytes seit dem letzten Reset der Zhler. Es
  knnen eine Vielzahl von Regeln festgelegt werden, um die
  verschiedenen Zhler den eigenen Bedrfnissen anzupassen.

  Optionen beim Kernel kompilieren:

       Networking options  --->
           [*] IP: accounting

  Nach Kompilierung und Installation des Kernels bentigen sie das
  Programm ipfwadm, um das IP Accounting zu konfigurieren.  Es gibt eine
  Menge unterschiedlicher Wege, die Accounting Information in
  verschiedene Bereiche aufzuspalten.  Hier ist ein einfaches Beispiel
  als Anregung, fr weitergehende Informationen sollten Sie die
  Hilfeseite zu ipfwadm lesen.
  Das Szenario fr das Beispiel ist folgendes: Ein lokales Ethernet ist
  ber eine serielle PPP-Leitung mit dem Internet verbunden.  Im
  Internet steht ein Rechner, der einige Dienste zur Verfgung stellt.
  Sie sind daran interessiert zu erfahren, welchen Anteil der Auslastung
  durch die Dienste telnet, rlogin, ftp und WWW verursacht wird.

  Eine entsprechende Konfiguration sieht so aus:

       #
       # Loeschen der bestehenden Accounting Regeln
       ipfwadm -A -f
       #
       # Neue Regeln fuer das lokale 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
       #
       # Default Regeln
       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
       #
       # Auflisten der Regeln
       ipfwadm -A -l -n
       #

  Der letzte Befehl zeigt eine Auflistung aller Accounting Regeln und
  zeigt die aufsummierten Zahlenwerte an.

  Ein wichtiger Punkt bei der Auswertung der Accounting Informationen
  ist, da die Zhler fr alle zutreffenden Regeln erhht werden.  Fr
  eine genaue, differentielle Analyse mu man also ein wenig Rechnen.
  Um z.B. herauszufinden, welcher Datenanteil nicht von ftp, telnet,
  rlogin oder WWW herrhrt, mssen die Summe der Zahlenwerte der
  einzelnen Ports subtrahiert werden von der Regel, die alle Ports
  umfat:

  # 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            *
  #

  5.11.  IP Aliasing

  Es gibt einige Anwendungen bei denen es hilfreich ist, wenn man einem
  einzelnen Netzwerk-Device mehrere IP Adressen zuweisen kann. Provider
  fr Internet Dienste verwenden dies hufig, um ihren Kunden speziell
  angepate WWW- und FTP-Dienste anzubieten.

  Optionen beim Kernel kompilieren:

       Networking options  --->
           ....
           [*] Network aliasing
           ....
           <*> IP: aliasing support

  Die Konfiguration fr IP Aliasing ist sehr einfach.  Die Aliases
  werden virtuellen Netzwerk Devices zugewiesen, die an das tatschliche
  Device gekoppelt sind.  Eine einfache Namenskonvention fr diese
  Devices ist <Devicename>:<virtuelle Dev Nummer>, also z.B.  eth0:0,
  ppp0:10 usw.

  Als Beispiel nehmen wir ein Ethernet Netzwerk mit zwei IP
  Subnetzwerken an.  Um beide gleichzeitig ber eine Netzwerkkarte
  anzusprechen dienen folgende Befehle:

       #
       # ifconfig eth0:0 192.168.1.1 netmask 255.255.255.0 up
       # route add -net 192.168.1.0 netmask 255.255.255.0 eth0:0
       #
       # ifconfig eth0:1 192.168.10.1 netmask 255.255.255.0 up
       # route add -net 192.168.10.0 netmask 255.255.255.0 eth0:0
       #

  Um einen Alias zu lschen, hngen sie einfach ein '-' an das Ende
  seines Namens an:

       # ifconfig eth0:0- 0

  Alle mit diesem Device verbundenen Routes werden automatisch ebenfalls
  gelscht.

  5.12.  IP Firewall

  Alles was mit IP Firewall und Firewalls allgemein zu tun hat wird
  ausfhrlich im Firewall HOWTO erlutert.  Ein IP Firewall erlaubt es,
  den Rechner oder ein ganzes Netzwerk gegen unerlaubte Netzzugriffe
  abzuschotten, indem Datenpakete von und zu angegebenen IP-Adressen
  gefiltert werden.  Es existieren drei unterschiedliche Klassen fr
  Regeln: Incoming Filter, Outgoing Filter und Forward Filter.  Incoming
  Filter werden auf Datenpakete angewandt, die ber eine
  Netzwerkschnittstelle empfangen werden.  Outgoing Filter gelten fr
  Datenpakete, die ber eine Netzwerkschnittstelle ausgegeben werden.
  Forward Filter werden auf Datenpakete angewandt, die zwar angenommen
  werden, aber nicht fr den eigenen Rechner bestimmt sind, also solche,
  die gerouted werden.

  Optionen beim Kernel kompilieren:

       Networking options  --->
           [*] Network firewalls
           ....
           [*] IP: forwarding/gatewaying
           ....
           [*] IP: firewalling
           [ ] IP: firewall packet logging

  Die Konfiguration eines IP Firewall wird mit dem Befehl ipfwadm
  durchgefhrt.  Wie bereits erwhnt bin ich kein Experte in Sachen
  Sicherheit.  Obwohl hier ein Beispiel fr die Konfiguration angegeben
  wird, sollten Sie weitere Nachforschungen auf diesem Gebiet anstellen
  und ihre eigenen Regeln zusammensuchen, wenn Sie wirklich auf
  Sicherheit bedacht sind.

  Am weitesten Verbreitet ist die Benutzung von IP Firewall, um einen
  Linux-Rechner als Router und Firewall Gateway fr ein lokales Netzwerk
  einzusetzen und dieses gegen unerlaubten Zugriff von auerhalb zu
  sichern.

  Die folgende Konfiguration basiert auf einem Beitrag von Arnt
  Gulbrandsen (agulbra@troll.no).

  Das Beispiel beschreibt die Konfiguration der Firewall-Regeln des
  Linux Firewall/Router Rechners aus folgendem Schaubild:

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

  Die folgenden Befehle gehren eigentlich in eine rc-Datei, so da sie
  automatisch bei jedem Systemstart ausgefhrt werden.  Um maximale
  Sicherheit zu erreichen, sollten sie nach der Konfiguration der
  Netzwerk Devices, aber vor deren Aktivierung ausgefhrt werden.
  Dadurch wird ein Einbruch whrend des Bootens unterbunden.

  #!/bin/sh

  # Loeschen der Forwarding Regeln
  # Default Policy auf 'accept'
  #
  /sbin/ipfwadm -F -f
  /sbin/ipfwadm -F -p accept
  #
  # .. ebenso fuer 'Incoming'
  #
  /sbin/ipfwadm -I -f
  /sbin/ipfwadm -I -p accept

  # Als erstes das PPP Interface schlieen
  # besser waere hier '-a deny' anstelle von '-a reject -y', aber dann
  # waere es auch nicht mehr moeglich, ueber dieses Interface selber eine
  # Verbindung aufzubauen.
  # Das -o veranlasst, dass alle geblockten Datagramme protokolliert
  # werden.  Das verbraucht viel Plattenplatz, andernfalls ist man aber
  # ueber Angriffsversuche oder Fehlkonfiguration im Unklaren.
  #
  /sbin/ipfwadm -I -a reject -y -o -P tcp -S 0/0 -D 172.16.174.30

  # Einige offensichtlich falsche Pakete werden sofort abgewiesen:
  # Von multicast/anycast/broadcast Adressen sollte nicht kommen.
  #
  /sbin/ipfwadm -F -a deny -o -S 224.0/3 -D 172.16.37.0/24
  #
  # und auch vom Loopback Netzwerk sollten keine Pakete auf der Leitung
  # erscheinen.
  #
  /sbin/ipfwadm -F -a deny -o -S 127.0/8 -D 172.16.37.0/24

  # Eingehende SMTP und DNS Verbindungen werden akzeptiert, aber nur an
  # den Mail/Nameserver
  #
  /sbin/ipfwadm -F -a accept -P tcp -S 0/0 -D 172.16.37.19 25 53
  #
  # DNS verwendet UDP und TCP, deshalb muss das auch freigegeben werden
  #
  /sbin/ipfwadm -F -a accept -P udp -S 0/0 -D 172.16.37.19 53
  #
  # allerdings keine 'Antworten' von gefaehrlichen Ports wie NFS und
  # Larry McVoy's NFS extension.  Wer SQUID verwendet, sollte dessen Ports
  # hier ebenfalls angeben
  #
  /sbin/ipfwadm -F -a deny -o -P udp -S 0/0 53 \
          -D 172.16.37.0/24 2049 2050

  # Antworten an andere User Ports sind OK
  #
  /sbin/ipfwadm -F -a accept -P udp -S 0/0 53 \
          -D 172.16.37.0/24 53 1024:65535

  # Eingehende Verbindungen mit identd werden geblockt.
  # Hier wird 'reject' verwendet, damit dem anderen Rechner sofort
  # mitgeteilt wird, das weitere Versuche sinnlos sind. Andernfalls
  # wuerden Verzoegerungen durch timeouts von ident auftreten.
  #
  /sbin/ipfwadm -F -a reject -o -P tcp -S 0/0 -D 172.16.37.0/24 113

  # Einige Standard-Dienste werden fuer Verbindungen von den Netzwerken
  # 192.168.64 und 192.168.65 akzeptiert; das sind Freunde, denen wir trauen.
  #
  /sbin/ipfwadm -F -a accept -P tcp -S 192.168.64.0/23 \
          -D 172.16.37.0/24 20:23
  # Alles von innerhalb des lokalen Netzes wird akzeptiert und
  # weitergeleitet.
  #
  /sbin/ipfwadm -F -a accept -P tcp -S 172.16.37.0/24 -D 0/0

  # Alle anderen eingehenden TCP Verbindungen werden verweigert und
  # protokolliert. (Falls FTP nicht funktioniert, haengen Sie ein
  # 1:1023 an).
  #
  /sbin/ipfwadm -F -a deny -o -y -P tcp -S 0/0 -D 172.16.37.0/24

  # ... ebenfalls fuer UDP
  #
  /sbin/ipfwadm -F -a deny -o -P udp -S 0/0 -D 172.16.37.0/24

  Gute Firewall Konfigurationen sind etwas trickreich.  Dieses Beispiel
  sollte einen brauchbaren Anfang liefern. Die Hilfeseite zu ipfwadm
  gibt weitere Untersttzung bei der Konfiguration.  Wenn Sie vorhaben,
  einen Firewall einzurichten, erkundigen Si sich auch bei
  vertrauenswrdigen Bekannten und sammeln sie soviel Hinweise und
  Ratschlge wie mglich.  Suchen sie auch jemanden, der ein paar
  Zuverlssigkeits- und Funktionstests von auerhalb durchfhrt.

  5.13.  IPX (AF_IPX)

  Das IPX Protokoll wird hauptschlich in lokalen Netzwerken unter
  Novell Netware(tm) verwendet. Linux untersttzt dieses Protokoll und
  kann als Endpunkt oder Router fr IPX verwendet werden.

  Optionen beim Kernel kompilieren:

       Networking options  --->
           [*] The IPX protocol
           [ ] Full internal IPX network

  IPX Protokoll und NCPFS werden ausfhrlich im IPX HOWTO behandelt.

  5.14.  IPv6

  Da hat man nun gerade geglaubt, IP Netzwerke ansatzweise zu verstehen,
  und nun werden die Regeln gendert!  IPv6 ist eine abgekrzte Form fr
  die Version 6 des Internet Protokolls.  IPv6 wurde vorrangig
  entwickelt, um den Befrchtungen der Internet Gemeinde
  entgegenzuwirken, da es bald einen Engpa bei den IP Adressen gbe.
  IPv6 Adressen sind 32 Byte, also 128 Bit, lang.  Auerdem enthlt IPv6
  einige weitere nderungen, vorrangig Vereinfachungen, die ein IPv6
  Netzwerk einfacher verwaltbar machen als ein IPv4 Netzwerk.

  Die Kernels der Version 2.1.* enthalten bereits eine funktionierende,
  wenn auch noch unvollstndige Implementation von IPv6.

  Wenn Sie mit  dieser neuen Generation der Internet Technologie
  experimentieren wollen, sollten Sie das IPv6-FAQ lesen.  Es ist von

       http://www.terra.net/ipv6

  erhltlich.

  5.15.  ISDN

  Das Integrated Services Digital Network (ISDN) umfat eine Reihe von
  Standards, die ein Vielzweck Digitales Netzwerk definieren. Ein ISDN
  Service, zur angerufenen Seite auf.  ISDN wird fr gewhnlich auf
  Hochgeschwindigkeitsleitungen verwendet, die in mehrere diskrete
  Kanle aufgeteilt ist.  Es gibt zwei unterschiedliche Typen dieser
  Kanle, eine einzelnen 'C-Kanal', ber den ISDN Kontrollinformationen
  zum Verbindungsaufbau und andere Funktionen bertrgt.  In Australien
  wird ISDN z.B. ber eine 2Mbps Leitung bertragen, die in 30 B-Kanle
  zu 64kbps sowie einen D-Kanal mit ebenfalls 64kbps aufgespalten ist.
  Zu jedem Zeitpunkt knnen beliebig viele dieser Kanle in jeder
  Kombination benutzt werden.  Also z.B. gleichzeitig 30 Verbindungen
  (64kbps) zu 30 verschiedenen Zielen aufbauen, oder 15 Verbindungen
  (128kbps) zu 15 unterschiedlichen Zielen, oder eben auch nur eine
  kleine Zahl von Verbindungen, wobei ein Teil der Kanle unbenutzt
  bleibt.  Ein Kanal kann fr eingehende oder ausgehende Verbindungen
  genutzt werden. Das ursprngliche Ziel hinter ISDN war es, den
  Telekommunikationsgesellschaften die Mglichkeit zu geben, ber eine
  einzelne Leitung sowohl Telefondienste (als digitalisierte Sprache)
  als auch Datendienste anzubieten, ohne da nderungen in der
  Konfiguration notwendig werden.

  Es gibt unterschiedliche Wege, einen Rechner an ISDN anzuschlieen.
  Eine Mglichkeit stellt ein 'Terminal Adapter' dar. Dieser wird direkt
  an die Netzwerk-Endstelle der Telekom angeschlossen und stellt eine
  Anzahl von seriellen Schnittstellen zur Verfgung. Eine dieser
  Schnittstellen wird dazu benutzt, um Kommandos zum Verbindungsaufbau,
  Konfiguration usw. zu bermitteln, die brigen sind mit den Netzwerk-
  Devices gekoppelt, ber die die Datenverbindungen aufgebaut werden.
  In dieser Umgebung funktioniert Linux ohne Vernderungen, die Ports am
  Terminal Adapter werden einfach wie eine normale serielle
  Schnittstelle behandelt.  Eine andere Mglichkeit besteht im Einsatz
  einer speziellen Einsteckkarte fr den Rechner.  Dafr sind die ISDN
  Treiber im Kernel vorgesehen. In diesem Fall werden Protokolle und
  Verbindungsaufbau von der Software des Rechners berwacht.

  Optionen beim Kernel kompilieren:

       ISDN subsystem  --->
               <*> ISDN support
               [ ] Support synchronous PPP
               [ ] Support audio via ISDN
               < > ICN 2B and 4B support
               < > PCBIT-D support
               < > Teles/NICCY1016PC/Creatix support

  Linux untersttzt eine Reihe unterschiedlicher ISDN Karten:

    ICN 2B und 4B

    Octal PCBIT-D

    Teles ISDN-Karten und Kompatible

     Fr einige dieser Karten ist zustzliche Software ntig, um sie zu
     betreiben. Diese mu mit speziellen Programmen geladen werden.

  Weitere Details zur Konfiguration von ISDN unter Linux befinden sich
  im Verzeichnis /usr/src/linux/Documentation/isdn, auerdem existiert
  das FAQ isdn4linux, zu beziehen bei

       http://www.lrz-muenchen.de/~ui161ab/www/isdn/

  Es gibt dort eine deutsche und eine englische Version.

  Ein Hinweis zu PPP. PPP ist generell fr den Betrieb sowohl ber
  synchrone wie auch ber asynchrone serielle Verbindungen ausgelegt.
  Der normalerweise in Linux-Distributionen enthaltene Dmon pppd
  untersttzt jedoch nur den asynchronen Modus.  Wenn sie PPP ber ihre
  ISDN Verbindung benutzen wollen, bentigen sie eine speziell angepate
  Version. Nhere Details dazu finden sie in den oben erwhnten Quellen.

  5.16.  IP Masquerade

  Viele Personen setzen eine einfache Einwahlverbindung als Zugang zum
  Internet ein.  Hierbei wird dem einwhlenden Rechner praktisch immer
  genau eine einzige IP Adresse zugewiesen. Das ist normalerweise
  ausreichend, um einem einzelnen Rechner vollen Zugang zu den
  Mglichkeiten des Internet zu geben. IP Masquerade erlaubt es nun
  auch, da beliebig viele Rechner (z.B. ein lokales Netzwerk) diese
  eine IP Adresse verwenden, indem man erreicht, da sie nach auen so
  aussehen wie der eine Rechner, dessen IP Adresse verwandt wird -
  deshalb der Name Masquerading immer nur in eine Richtung funktioniert.
  D.h. der maskierte Rechner kann zwar Verbindungen nach auen aufbauen,
  er kann aber keine Anfragen/Verbindungen von auenliegenden Rechnern
  empfangen.  Deshalb funktionieren einige Dienste wie talk nicht,
  andere wie z.B. ftp mssen speziell auf passiven Modus (PASV)
  konfiguriert werden, damit sie funktionieren. Zum Glck sind aber
  Standard-Dienste wie telnet, irc und WWW davon nicht betroffen.

  Optionen beim Kernel kompilieren:

       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)

  Auf dem Linux Rechner wird SLIP oder PPP ganz normal konfiguriert, wie
  fr einen Einzelrechner.  Auerdem besitzt der Rechner aber eine
  weitere Netzwerkschnittstelle, z.B. eine Ethernetkarte, ber die er
  mit dem lokalen Netzwerk verbunden ist. An diesem Netz hngen auch die
  Rechner, die 'maskiert' werden sollen.  Jeder dieser anderen Rechner
  mu nun zunchst die IP Adresse des Linux Rechners als Gateway bzw.
  Router konfigurieren.

  Eine typische Konfiguration sieht etwa so aus:

  -                                   -
   \                                  | 192.168.1.0
    \                                 |   /255.255.255.0
     \                 ---------      |
      |                | Linux | .1.1 |
  NET =================| masq  |------|
      |    PPP/slip    | router|      |  --------
     /                 ---------      |--| host |
    /                                 |  |      |
   /                                  |  --------
  -                                   -

  Die wichtigsten Konfigurationsbefehlein diesem Fall sind:

       # Netzwerk Route fuer Ethernet
       route add 192.168.1.0 netmask 255.255.255.0 eth0
       #
       # Default Route fuer den Rest des Internet
       route add default ppp0
       #
       # Alle Hosts auf dem Netzwerk 192.168.1/24 werden maskiert
       ipfwadm -F -a m -S 192.168.1.0/24 -D 0.0.0.0/0

  Weitere Informationen ber IP Masquerade unter Linux enthlt die IP
  Masquerade Resource Page:

       http://www.hwy401.com/achau/ipmasq/

  5.17.  IP Transparent Proxy

  IP Transparent Proxy ermglicht es, Anfragen fr Server oder Dienste
  auf anderen Rechnern auf die lokale Maschine umzulenken. Dies ist z.B.
  sinnvoll, wenn ein Linux Rechner als Router und Proxy Server
  eingesetzt wird. In diesem Fall werden alle Anfragen nach nichtlokalen
  Diensten an den lokalen Proxy weitergeleitet.

  Optionen beim Kernel kompilieren:

       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)

  Die Konfiguration von IP Transparent Proxy wird mit Hilfe des Befehles
  ipfwadm durchgefhrt, zum Beispiel so:

  ipfwadm -I -a accept -D 0/0 80 -r 8080

  Dadurch wird jede Verbindungsversuch mit dem Port 80 (www) eines
  beliebigen Rechners auf den Port 8080 des lokalen Rechners umgeleitet.
  Dadurch kann man z.B. sicherstellen da jeglicher WWW Verkehr auf dem
  Netzwerk automatisch ber ein lokales Cache Programm geleitet wird.

  5.18.  Mobile IP

  Der Ausdruck "IP mobility" beschreibt die Fhigkeit eines Rechners,
  seine Verbindung zum Internet an unterschiedliche Punkte zu verlagern,
  ohne dabei seine IP Adresse zu ndern oder die Verbindung zu
  verlieren.  Normalerweise ndert sich die IP Adresse eines Rechners,
  wenn er an einer anderen Stelle (z.B. in ber ein anderen Netzwerk) an
  das Internet angekoppelt wird.  Mobile IP umgeht dieses Problem, indem
  dem Rechner eine feste IP Adresse zugeordnet wird und jeglicher
  Datenverkehr zu diesem Rechner durch IP Encapsulation (Tunneling) an
  die momentan tatschlich genutzte IP Adresse umgeleitet wird.

  In einem derzeit in Entwicklung befindlichen Projekt sollen alle
  notwendigen Programme fr IP Mobility unter Linux zusammengetragen
  werden.  Den gegenwrtigen Stand der Dinge erfahren Sie auf der Linux
  Mobile IP Home Page:

       http://anchor.cs.binghamton.edu/~mobileip/

  5.19.  Multicast

  Mit IP Mulicast ist es mglich, Datenpakete gleichzeitig an beliebig
  viele Rechner auf verschiedenen IP Netzwerken zu routen.  Dieser
  Mechanismus wird ausgenutzt, um Internet-weite Verteilung von z.B.
  Audio- oder Videodaten zu ermglichen.

  Optionen beim Kernel kompilieren:

       Networking options  --->
               [*] TCP/IP networking
               ....
               [*] IP: multicasting

  Ein paar spezielle Programme sowie einige kleinere
  Konfigurationsnderungen des Netzwerkes sind ntig, um diese
  Mglichkeiten auszunutzen.  Weitere Informationen zu Installation und
  Konfiguration findet man z.B. bei

       http://www.teksouth.com/linux/multicast/

  5.20.  NetRom (AF_NETROM)

  Die NetRom Devices sind nr0, nr1 usw.

  Optionen beim Kernel kompilieren:

       Networking options  --->
           [*] Amateur Radio AX.25 Level 2
           [*] Amateur Radio NET/ROM

  Die Protokolle AX25, Netrom und Rose werden von Amateurfunkern fr
  Experimente mit Packet Radio genutzt. Eine Ausfhrliche Beschreibung
  enthlt das AX25 HOWTO.

  Der Groteil der Arbeit bei der Implementation dieser Protokolle wurde
  von Jonathon Naylor (jsn@cs.not.ac.uk) geleistet.

  5.21.  PLIP

  Die Namen der PLIP Devices sind plip0, plip1 usw.  Das erste Device
  erhlt die Nummer 0, die weiteren werden fortlaufend durchnumeriert.

  Optionen beim Kernel kompilieren:

       Networking options  --->
           <*> PLIP (parallel port) support

  PLIP (Parallel Line IP) wird -- wie SLIP -- benutzt, um eine Point-to-
  Point Netzwerkverbindung zwischen zwei Rechnern herzustellen.  Im
  Unterschied zu SLIP werden dazu jedoch die Parallelports der Rechner
  verwendet.  Da dabei mehr als ein Bit gleichzeitig bertragen werden
  kann, lassen sich mit PLIP hhere Datenbertragungsraten erreichen.
  Auerdem lassen sich selbst die einfachsten parallelen Anschlsse, die
  Druckerports, verwenden.

  Aber Vorsicht: Manche Laptops verwenden Chipstze, mit denen PLIP
  nicht verwendet werden kann: Sie lassen bestimmte Kombinationen von
  Signalen, die PLIP zum Funktionieren bentigt, nicht zu, da sie von
  Druckern nicht verwendet werden.

  Die PLIP Schnittstelle von Linux ist kompatibel zum Crynwyr Packet
  Driver PLIP, d.h. man kann damit eine vollwertige TCP/IP Verbindung
  zwischen seinem Linux Rechner und einem DOS-Rechner aufbauen.

  Bein Kompilieren des Kernels sollte man einen Blick in die Datei
  /usr/src/linux/driver/net/CONFIG werfen.  Sie enthlt Definitionen fr
  den PLIP Timer in mS.  Die Standardwerte sind zwar meist OK,
  insbesondere bei langsamen Rechnern wird man sie aber unter Umstnden
  erhhen mssen -- auf dem schnellen Rechner.

  Der Treiber geht von folgenden Einstellungen aus:

  device  i/o addr    IRQ
  ------  --------    -----
  plip0   0x3BC           5
  plip1   0x378           7
  plip2   0x278           2 (9)

  Entspricht ihr Parallelports keiner dieser Mglichkeiten, knnen die
  Werte mit dem Befehl ifconfig und der Option irq gendert werden.
  Achten Sie auch darauf, da die IRQ's fr den Parallelport im BIOS
  aktiviert sind.

  Zu Konfiguration des PLIP Interface mssen die folgenden Befehle in
  der fr das Netzwerk zustndigen rc-Datei hinzugefgt werden:

       #
       # Attach a PLIP interface
       #
       #  Konfiguriere den ersten Parallelport als PLIP Device
       /sbin/ifconfig plip0 IPA.IPA.IPA.IPA pointopoint IPR.IPR.IPR.IPR up
       #
       # Ende PLIP

  Dabei ist

     IPA.IPA.IPA.IPA
        ihre IP Adresse.

     IPR.IPR.IPR.IPR
        die IP Adresse des anderen Rechners.

  Der Parameter pointopoint hat dieselbe Bedeutung wie bei SLIP: Es wird
  die Adresse des Rechners am anderen Ende der Verbindung angegeben.

  Ansonsten kann man ein PLIP Interface genau wie ein SLIP Interface
  behandelt, einzig dip oder slattach brauchen und knnen nicht
  verwendet werden.

  5.21.1.  Ein Kabel fr PLIP.

  PLIP wurde so ausgelegt, da es dieselben Verbindungskabel verwendet
  wie die normalerweise auf DOS-Rechnern verwendeten
  Datenbertragungsprogramme.

  Die Pinbelegung (aus /usr/src/linux/drivers/net/plip.c) sieht
  folgendermassen aus:

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

  Hinweis: Die mit einem Stern * gekennzeichneten Pins drfen nicht
  verbunden werden.  Zustzliche Erdungsanschlsse sind
  18,19,20,21,22,23 und 24.

  Geschirmte Kabel sollten nur auf einer Seite mit dem Metall des
  Steckers verbunden werden.

  Vorsicht: Ein falsch verdrahtetes PLIP-Kabel kann ihre Controler Karte
  zerstren!. Seien Sie sehr vorsichtig, und berprfen sie jede
  Verbindung doppelt um unntigen rger zu vermeiden.

  Obwohl man PLIP Verbindungen teilweise auch ber lange Distanzen
  verwenden kann sollten Sie das nach Mglichkeit vermeiden.  Die
  Spezifikationen erlauben eine Kabellnge von etwa einem Meter.  Wenn
  Sie dennoch lngere Kabel verwenden wollen, achten Sie besonders auf
  elektromagnetische Streinstreuungen (Blitz, andere Stromkabel,
  Radiosender), da auch dadurch eine Beeintrchtigung der Verbindung bis
  hin zur Beschdigung des Controlers mglich ist.  Wenn sie wirklich
  eine Verbindung ber grere Distanzen herstellen wollen oder mssen,
  kaufen Sie lieber zwei billige Ethernet-Karten und ein Koaxial-Kabel

  5.22.  PPP

  Die Namen der PPP Devices sind ppp0, ppp1 usw.  Die Devices werden
  fortlaufend durchnumeriert, beginnend mit 0 fr das erste
  konfigurierte Device.

  Optionen beim Kernel kompilieren:

       Networking options  --->
           <*> PPP (point-to-point) support

  Die Konfiguration von PPP wird im PPP HOWTO beschrieben.

  5.22.1.  Permanente Netzverbindungen mit pppd.

  Falls Sie sich in der glcklichen Lage befinden eine mehr oder weniger
  dauerhafte Netzanbindung zu haben gibt es eine sehr einfache
  Mglichkeit, da der Rechner automatisch eine neue PPP Verbindung
  aufbaut, wenn diese zusammenbrechen sollte.

  Dabei mu PPP derart konfiguriert werden, da es vom Superuser root
  durch einen einfachen Befehl gestartet werden kann:

       # pppd

  Stellen Sie sicher da sie in der Datei /etc/ppp/options die Option
  -detach konfiguriert haben.  Dann fgen sie die folgende Zeile bei den
  getty-Definitionen in die Datei /etc/inittab ein:

       pd:23:respawn:/usr/sbin/pppd

  Dadurch wird der Dmon pppd laufend von init berwacht und im Falle
  eines Verbindungsabbruches automatisch neu gestartet.

  5.23.  Rose protocol (AF_ROSE)

  Die Namen der Rose Devices sind rs0, rs1 usw.  Rose wird nur in den
  Entwickler-Kernels 2.1.* untersttzt.

  Optionen beim Kernel kompilieren:

       Networking options  --->
           [*] Amateur Radio AX.25 Level 2
           <*> Amateur Radio X.25 PLP (Rose)

  Die Protokolle AX25, Netrom und Rose werden von Amateurfunkern fr
  Experimente mit Packet Radio genutzt. Eine Ausfhrliche Beschreibung
  enthlt das AX25 HOWTO.

  Der Groteil der Arbeit bei der Implementation dieser Protokolle wurde
  von Jonathon Naylor (jsn@cs.not.ac.uk) geleistet.

  5.24.  SAMBA - `NetBEUI', `NetBios' Untersttzung.

  SAMBA ist eine Implementation des Session Management Block
  Protokolles.  Mit SAMBA ist es mglich, da Microsoft- und andere
  Systeme die Platten des Linux-Rechners mounten knnen und dessen
  Drucker verwenden.

  SAMBA und seine Konfiguration werden ausfhrlich im Linux Samba HOWTO
  beschrieben.

  5.25.  SLIP Klient

  Die Namen der SLIP Devices sind sl0, sl1 usw.  Das erste konfigurierte
  Device erhlt die Nummer 0, weitere werden fortlaufend durchnumeriert.

  Optionen beim Kernel kompilieren:

       Network device support  --->
           [*] Network device support
           <*> SLIP (serial line) support
           [ ]  CSLIP compressed headers
           [ ]  Keepalive and linefill
           [ ]  Six bit SLIP encapsulation

  SLIP (Serial Line IP) ermglicht TCP/IP Verbindungen ber serielle
  Leitungen wie Telefonleitungen (mit Modem) oder geleaste Leitungen. Um
  es zu benutzen bentigt man einen SLIP-Server mglichst in der nheren
  Umgebung. Viele Universitten und einige Firmen bieten einen solchen
  Service an.

  SLIP verwendet die serielle Schnittstelle des Rechners, um Datenpakete
  zu versenden.  Dafr mu man diese Schnittstelle kontrollieren knnen.
  Wie sind die SLIP-Namen den seriellen Schnittstellen zugeordnet?  Der
  Netzwerk Code verwendet einen ioctl (I/O Control) Aufruf, um die
  serielle Schnittstelle in ein SLIP-Device 'umzuschalten'.  Es gibt
  zwei Programme, die diese Aufgabe bernehmen: dip und slattach.

  5.25.1.  dip

  dip (Dialup IP) ist ein intelligentes Programm, das die
  bertragungsgeschwindigkeit der seriellen Schnittstelle einstellen
  kann, das Modem zum Whlen veranlat, automatisch die eingehenden
  Meldungen der Gegenstelle nach den notwendigen Informationen wie IP-
  Adresse durchsucht und die notwendigen ioctl Aufrufe ausfhrt, um die
  Schnittstelle in den SLIP Modus zu schalten.  dip untersttzt eine
  umfangreiche Script-Sprache und kann dadurch den gesamten Login-Proze
  automatisieren.

  Die Bezugsquelle ist

       sunsite.unc.edu:/pub/Linux/system/Network/serial/dip/dip337o-uri.tgz

  Zur Installation gehen Sie wie folgt vor:

  #
  # cd /usr/src
  # gzip -dc dip337o-uri.tgz | tar xvf -
  # cd dip-3.3.7o

  <Makefile editieren>

  # make install
  #

  Das Makefile nimmt die Existenz einer Gruppe uucp an, dies kann aber
  leicht z.B. in dip oder SLIP umgendert werden.

  5.25.2.  slattach

  Im Gegensatz zu dip ist slattach ein extrem einfaches Programm.  Es
  ist einfach zu benutzen, bietet aber nicht den Komfort oder die
  Script-Fhigkeit von dip.  Alles was es macht, ist, die serielle
  Schnittstelle als SLIP Device zu konfigurieren.  Dabei setzt es
  voraus, da sie alle notwendigen Informationen besitzen, und da die
  Verbindung bereits aufgebaut ist, wenn es gestartet wird.  slattach
  ist optimal geeignet, wenn sie eine dauerhafte Verbindung zu ihrem
  Server haben.

  5.25.3.  Wann benutze ich welches Programm?

  dip bietet sich an, wenn die Verbindung zum SLIP Server ber ein Modem
  oder eine andere temporre Leitung aufgebaut wird.  slattach ist eher
  fr feste Verbindungen, ein fest installiertes Kabel etwa, oder eine
  gemietete Leitung, geeignet, fr Flle also, in denen keine besonderen
  Aktionen notwendig sind, um die Verbindung aufzubauen.  Fr weitere
  Informationen siehe den Abschnitt 'Dauerhafte SLIP Verbindungen'.

  Die Konfiguration von SLIP ist bis auf ein paar kleine Ausnahmen sehr
  hnlich zur Konfiguration eines Ethernet Device (siehe dort).

  Zunchst unterscheiden sich SLIP Verbindungen von Ethernet Netzwerken
  dadurch, da an einem SLIP-'Netzwerk' immer nur zwei Rechner beteiligt
  sind.  Auerdem sind bei SLIP Verbindungenoft zustzliche Manahmen
  notwendig, um die Netzverbindung zu aktivieren, wohingegen bei einer
  Ethernet Netzwerk die Verbindung bereits mit dem Einstecken der Kabel
  besteht.

  Wenn Sie dip verwenden, wird der Verbindungsaufbau normalerweise nicht
  bereits beim Booten vorgenommen sondern erst zu einem spteren
  Zeitpunkt, wenn eine Netzverbindung bentigt wird.  Es ist auch dann
  mglich, diesen Vorgang zu automatisieren.  Falls Sie slattach
  verwenden werden Sie vermutlich lieber einen speziellen Abschnitt in
  der Datei rc.inet1 einfgen wollen.  Dies wird etwas spter
  beschrieben.

  Es gibt zwei unterschiedliche Arten von SLIP Servern: Solche die die
  Adressen dynamisch vergeben, und solche die statische Adressen
  verwenden.  Praktisch jeder SLIP Server wird sie beim Login
  auffordern, ihren Benutzernamen sowie ihr Pawort einzugeben. dip kann
  diese Loginprozedur bernehmen und automatisch durchfhren.


  5.25.4.  Statische SLIP Server und dip.

  Bei einem statischen SLIP Server bekommen Sie eine IP Adresse fr ihre
  alleinige Verwendung zugewiesen.  Bei jedem Verbindungsaufbau zum
  Server bekommen Sie also diese feste Adresse.  Der statische SLIP
  Server wird also ihren Modem-Anruf entgegennehmen, die normale Login-
  Prozedur durchfhren und dann alle Datagramme an ihre IP Adresse ber
  diese Leitung routen.  Wenn Sie Zugang zu einem solchen statischen
  Server haben, sollten Sie einen festen Eintrag mit ihrem Rechnernamen
  und der IP Adresse in der Datei /etc/hosts einfgen.  Auch in den
  folgenden Dateien sollten Sie entsprechende Konfigurationsnderungen
  vornehmen: rc.inet2, host.conf, resolv.conf, etc/HOSTNAME sowie
  rc.local.  Denken Sie auch daran, da bei der Konfiguration von
  rc.inet1 keine besonderen Befehle zur Konfiguration der SLIP
  Verbindung bentigt werden, dies wird zur gegebenen Zeit von dip
  erledigt.  Dazu mssen ihm lediglich die notwendigen Informationen
  mitgeteilt werden, dann wird die Konfiguration automatisch
  durchgefhrt, nachdem die Einwhlprozedur beendet ist.

  Falls Ihr SLIP Server statische Adressen verwendet, knnen Sie den
  folgenden Abschnitt berspringen und gleich den Abschnitt 'Benutzung
  von dip' lesen.

  5.25.5.  Dynamische SLIP Server und dip.

  Ein dynamischer SLIP Server vergibt die IP Adressen zufllig aus einem
  Pool von vorhandenen Adressen.  Es gibt also keine Garantie, das man
  bei jeder Verbindung eine bestimmte IP Adresse zugewiesen bekommt, und
  die von Ihnen bei einer Sitzung verwendete Adresse kann, nachdem Sie
  die Verbindung beendet haben, von einem anderen Benutzer verwendet
  werden.  Der Administrator des SLIP Servers hat fr diesen Zweck einen
  Pool von IP Adressen reserviert, und bei einem Verbindungsaufbau
  bekommen Sie die erste freie Adresse zugewiesen.  Diese wird dem
  Anrufer nach dem Verbindungsaufbau bermittelt und ist fr ihn fr die
  Dauer der Verbindung reserviert.

  Die Konfiguration verluft hier recht hnlich wie im Falle von
  statischen SLIP Servern, allerdings mu in einem Zustzlichen Schritt
  die zugewiesene IP Adresse ermittelt werden, um das SLIP Device
  entsprechend zu konfigurieren.

  Auch in diesem Fall bernimmt dip den schwierigen Teil, die neueren
  Versionen sind intelligent genug um nicht nur den Verbindungsaufbau
  durchzufhren sondern auch automatisch die bermittelte IP Adresse zu
  erkennen und damit das SLIP Device zu konfigurieren.

  5.25.6.  Die Benutzung von dip.

  Wie bereits erwhnt, handelt es sich bei dip um ein mchtiges
  Programm, welches den aufwendigen Proze des Einwhlens in einen SLIP
  Server, die Loginprozedur sowie die Konfiguration des SLIP Device
  vereinfachen und automatisieren kann.

  Um dip zu verwenden benutzt man im Allgemeinen ein `dip Script', das
  eigentlich nur aus einer Liste von Kommandos besteht, die dip
  versteht, und die ihm mitteilen, wie die notwendigen Aktionen
  durchgefhrt werden sollen.  Die Datei sample.dip, die Bestandteil des
  Paketes ist, vermittelt einen ersten Eindruck, wie das vor sich geht.
  dip ist ein Programm mit vielen Optionen.  Sie alle hier aufzulisten
  wre mig, lesen Sie dazu bitte die Online Hilfe, die Beispieldatei
  sowie die Datei README des dip-Paketes.

  Sie werden feststellen, da die Beispieldatei sample.dip von einem
  statischen SLIP Server ausgeht, die verwendete IP Adresse also bereits
  bekannt sein mu.  Fr dynamische SLIP Server gibt es in den neueren
  Versionen von dip ein spezielles Kommando, mit dem man automatisch die
  IP Adresse aus den Antworten des Servers extrahieren kann, um damit
  dann das SLIP Device zu konfigurieren.  Das folgende Script ist eine
  vernderte Version der Datei sample.dip, die mit der Version dip337j-
  uri.tgz ausgeliefert wird.  Sie stellt vermutlich einen ausreichenden
  Startpunkt fr alle dar, die einen dynamischen SLIP Server verwenden.
  Speichern sie es unter dem Namen /etc/dipscript und verndern Sie es
  entsprechend ihrer eigenen Konfiguration:

  #
  # 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:
  # Lege Namen und Adresse des Servers fest
  # Mein Server heisst 'xs4all.hacktic.nl' (== 193.78.33.42)
  get $remote xs4all.hacktic.nl
  # Setze die Netzmaske fuer sl0 auf 255.255.255.0
  netmask 255.255.255.0
  # Lege die verwendete serielle Schnittstelle und die Geschwindigkeit fest
  port cua02
  speed 38400

  # Reset fuer das Modem und die Terminal Verbindung.
  # Das verursacht fuer manche Leute Probleme!
  reset

  # Hinweis! "Standard" vordefinierte "errlevel" Werte sind:
  #  0 - OK
  #  1 - CONNECT
  #  2 - ERROR
  #
  # Man kann sie aendern, Suchen Sie (mit grep) nach "addchat()" in *.c

  # Vorbereitung zum Waehlen
  send ATQ0V1E1X4\r
  wait OK 2
  if $errlvl != 0 goto modem_trouble
  dial 555-1234567
  if $errlvl != 1 goto modem_trouble

  # Die Verbindung wurde aufgebaut, jetzt der Login
  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:

  # Login erfolgreich
  wait SOMEPROMPT 30
  if $errlvl != 0 goto prompt_error

  # Setze den Server in den SLIP Mous
  send SLIP\n
  wait SLIP 30
  if $errlvl != 0 goto prompt_error

  # Ermitteln der vom Server zugewiesenen IP Adresse
  #   Dabei wird vorausgesetzt, dass der Server diese Adresse nach
  #   dem Umschalten in den SLIP Modus ausgibt.
  get $locip remote 30
  if $errlvl != 0 goto prompt_error

  # Setzen der Arbeitsparameter fuer SLIP
  get $mtu 296
  # Dies stellt sicher, dass ein
  #  "route add -net default xs4all.hacktic.nl" durchgefuehrt wird
  default

  # Wir sind da! Starte SLIP
  done:
  print CONNECTED $locip ---> $rmtip
  mode CSLIP
  goto exit

  prompt_error:
  print TIME-OUT beim Starten von sliplogin...
  goto error

  login_trouble:
  print Probleme beim Warten auf den Login: Prompt...
  goto error

  password:error:
  print Probleme beim Warten auf den Password: Prompt...
  goto error

  modem_trouble:
  print Probleme mit dem Modem
  error:
  print CONNECT mit $remote gescheitert!
  quit

  exit:
  exit

  Dieses Script geht von einer dynamischen SLIP Verbindung aus.  Fr
  statische SLIP Server verwenden Sie bitte die Datei sample.dip aus dem
  Paket dip337j-uri.tgz.

  Wenn dip den Befehl get $local erhlt, durchsucht es smtlichen
  eingehenden Text von der anderen Seite auf eine Zeichenkette, die wie
  eine IP Adresse aussieht, also Zahlen, die durch Punkte getrennt sind.
  Diese Vernderung wurde eingefhrt, damit der Verbindungsaufbau auch
  fr dynamische SLIP Server automatisiert werden kann.

  Das obige Beispiel konfiguriert automatisch einen Default Route
  Eintrag ber das SLIP Device.  Entspricht das nicht ihren Wnschen,
  z.B. weil Sie auerdem noch eine Ethernet Verbindung haben, die ihre
  `default' Route darstellt, entfernen Sie die Zeile default aus dem
  Script.  Nachdem das Script beendet ist, knnen Sie mit dem Befehl
  ifconfig verifizieren, da ein Device sl0 existiert.  Dieses Device
  knnen Sie dann mit den blichen ifconfig und route Befehlen Ihren
  Wnschen entsprechend konfigurieren.

  Beachten Sie auch, da sie mit dip mittels des mode Befehles
  unterschiedliche Protokolle nutzen knnen.  Das am hufigsten
  verwendete ist wohl CSLIP fr SLIP mit Komprimierung.  Eine solche
  Einstellung mu aber auf beiden Seiten identisch sein, verwenden Sie
  also die Einstellung ihres Servers.

  Das Beispiel ist recht robust und sollte die meisten Fehler abfangen.
  Bei weiteren Fragen informieren Sie sich bitte ber die Online Hilfe
  zu dip.  Selbstverstndlich kann ein solches Script auch derart
  erweitert werden, da bei einem gescheiterten Einwahlversuch erneut
  gewhlt wird, oder sogar eine andere Nummer angerufen wird usw.

  5.25.7.  Dauerhafte SLIP Verbindungen mit slattach.

  Wenn sie zwei Rechner direkt ber ein Kabel miteinander verbinden,
  oder in der glcklichen Lage sind, ber eine gemietete Standleitung
  mit dem Internet verbunden zu sein, knnen Sie sich die aufwendige
  Prozedur mit dip ersparen.  slattach ist ein extrem einfach zu
  benutzendes Programm das gerade genug Funktionalitt bietet, um die
  Verbindung richtig zu konfigurieren.

  Da es sich um eine dauernde Verbindung handelt, ist der einfachste
  Weg, die Befehle zur Konfiguration in der Datei rc.inet1 einzubauen.
  Im Prinzip besteht diese Konfiguration lediglich darin,
  sicherzustellen, da die serielle Schnittstelle mit der korrekten
  Geschwindigkeit betrieben und in den SLIP Modus umgeschaltet wird. Mit
  slattach erreichen sie dies mit einem einzigen Befehl.  Fgen Sie
  einfach folgende Zeilen in ihr rc.inet1 ein:

       #
       # Aufbau einer dauerhaften statischen SLIP Verbindung
       #
       # Konfiguriere /dev/cua0 fuer 19.2kbps und CSLIP
       /sbin/slattach -p cslip -s 19200 /dev/cua0 &
       /sbin/ifconfig sl0 IPA.IPA.IPA.IPA pointopoint IPR.IPR.IPR.IPR up
       #
       # Ende statisches SLIP.

  Hierbei ist:

     IPA.IPA.IPA.IPA
        Ihre IP Adresse.

     IPR.IPR.IPR.IPR
        die IP Adresse des anderen Rechners

  slattach weist dem angegebenen Seriellen Device das erste freie SLIP
  Device zu, beginnend mit sl0.  Der erste Aufruf von slattach
  konfiguriert also das Device sl0, ein weiterer Aufruf sl1 usw.

  Mit slattach knnen mittels der Option -p eine Reihe von Protokollen
  eingestellt werden.  Im Normalfall sind das meist SLIP oder CSLIP, je
  nachdem ob Komprimierung verwendet werden soll oder nicht.  In jedem
  Fall mu aber auf beiden Seiten dieselbe Einstellung verwendet werden.

  5.26.  SLIP server.

  Wenn Sie einen Rechner mit Netzwerkzugang besitzen, ber den Sie
  anderen Nutzern die Einwahl in das Netz ermglichen wollen, mssen Sie
  diesen Rechner als Server konfigurieren. Wenn Sie fr die Verbindung
  als serielles Protokoll SLIP verwenden wollen, haben Sie drei
  Mglichkeiten unterschiedliche Mglichkeiten fr diese Konfiguration.
  Ich wrde den ersten Vorschlag, sliplogin, bevorzugen, da er am
  einfachsten zu realisieren und zu verstehen ist.  Aber treffen Sie
  ihre eigene Entscheidung.

  5.26.1.  SLIP Server mit sliplogin.

  sliplogin knnen Sie anstelle der normalen Login-Shell fr Nutzer
  verwenden, die sich in ihren Rechner einwhlen.  Das Programm schaltet
  automatisch die serielle Verbindung in den SLIP Modus und bietet
  Untersttzung sowohl fr statische als auch fr dynamische IP
  Adressenvergabe.

  Der Benutzer fhrt einen normalen Login-Proze durch, also Eingabe von
  Benutzerkennung und Pawort, aber statt dann eine Shell vorgesetzt zu
  bekommen wird sliplogin gestartet, das in der Datei /etc/slip.hosts
  nach einem Eintrag fr den anrufenden Benutzer sucht.  Wird dieser
  gefunden, wird die Verbindung als 8bit-rein konfiguriert und ber
  einen ioctl Aufruf in den SLIP Modus geschaltet.  Danach startet
  sliplogin als letzten Schritt ein Script, in dem das SLIP Device mit
  den entsprechenden Parametern (IP Adresse, Netz Maske, Routing)
  konfiguriert wird.  Dieses Script heit blicherweise /etc/slip.login,
  aber wie auch bei getty knnen sie fr Benutzer, die einer besonderen
  Behandlung bedrfen, eigene Scripts unter dem Namen
  /etc/slip.login.loginname anlegen, die dann anstelle des
  Standardscriptes gestartet werden.

  Es gibt drei bzw. vier Dateien, die konfiguriert werden mssen, damit
  sliplogin richtig funktioniert:

    /etc/passwd, fr die Accounts der einwhlenden Nutzer.

    /etc/slip.hosts, hier stehen die Nutzer-spezifischen Informationen
     fr jeden einzelnen Einwhler.

    /etc/slip.login, dieses Script regelt die Routing Konfiguration fr
     die Nutzer.

    /etc/slip.tty, diese Datei wird nur bei der Verwendung von
     dynamischer Adressvergabe bentigt und enthlt eine Tabelle mit
     benutzbaren Adressen.

    /etc/slip.logout, hier stehen die Kommandos um die Verbindung bei
     Logout oder Fehlern korrekt zu beenden.

  5.26.1.1.  Bezugsquellen fr sliplogin.

  Eventuell ist sliplogin bereits Bestandteil ihrer Linux-Distribution.
  Wenn nicht bekommt man es von

       sun
       site.unc.edu:/pub/linux/system/Network/serial/sliplogin-2.1.1.tar.gz

  Die TAR Datei enthlt Quellen, vorkompilierte Binrprogramme und die
  Manpage.

  Um sicherzustellen da nur autorisierte Nutzer sliplogin benutzen
  knnen, sollten Sie in de Datei /etc/group einen Eintrag wie diesen
  hier vorsehen:

        ..
       slip::13:radio,fred
        ..

  Bei der Installation von sliplogin wird das Makefile die
  Eigentumsrechte fr sliplogin auf die Gruppe slip setzen. Dadurch
  knnen nur Nutzer, die in dieser Gruppe sind, das Programm ausfhren.
  Im oben angefhrten Beispiel wren das die Nutzer radio und fred.

  Um die Programme im Verzeichnis /sbin und die Manpages in der Sektion
  8 zu installieren gehen Sie folgendermassen vor:

       # cd /usr/src
       # gzip -dc .../sliplogin-2.1.1.tar.gz | tar xvf -
       # cd sliplogin-2.1.1
       # <..Makefile editieren falls Sie keine Shadow Passworte verwenden..>
       # make install

  Falls Sie die Programme vor der Installation selber neu bersetzen
  wollen, fgen Sie vor dem make install noch ein make clean ein.
  Sollen die Programme in eine anderes Verzeichnis installiert werden,
  mssen Sie im Makefile die Regel install entsprechend editieren.

  Lesen Sie bitte auch die Datei README die zum Paket gehrt.

  5.26.1.2.  Anpassung von /etc/passwd fr SLIP Hosts.

  Normalerweise richtet man auf dem fr jeden Benutzer von SLIP einen
  speziellen Account in /etc/passwd ein.  Eine Konvention hierbei ist
  es, als Benutzernamen eingroes `S', gefolgt vom Namen des
  einwaehlenden Rechners, zu verwenden.  Ein Rechner mit dem Namen radio
  bekommt also folgenden Eintrag:

       Sradio:FvKurok73:1427:1:radio SLIP login:/tmp:/sbin/sliplogin

  Diese Konvention ist allerdings nicht zwingend, Sie knnen jeden
  beliebigen Namen verwenden, der ihnen aussagekrftig genug erscheint.

  Hinweis: Der Anrufer bentigt kein besonderes Heimatverzeichnis, da er
  von diesem Rechner niemals eine Shell zu Gesicht bekommen wird.  /tmp
  ist deshalb eine gute Wahl fr diesen Zweck. Beachten Sie auch den
  Eintrag /sbin/sliplogin als Login-Shell.

  5.26.1.3.  Konfiguration von /etc/slip.hosts

  In der Datei /etc/slip.hosts sucht sliplogin nach Eintrgen, die dem
  Namen des Anrufers entsprechen.  In dieser Datei werden IP Adresse und
  Netzmaske festgelegt, die dem Anrufer zugewiesen werden. Das folgende
  Beispiel enthlt Eintrge fr zwei Rechner, radio und albert, wobei
  letzterem die IP Adresse dynamisch zugewiesen wird:

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

  Die einzelnen Eintrge sind:

  1. Login-Name des Anrufers

  2. IP Adresse des Servers

  3. IP Adresse, die dem Anrufer zugeteilt wird.  Enthlt dieses Feld
     den Eintrag DYNAMIC, wird die IP Adresse basierend auf den
     Informationen in der Datei /etc/slip.tty bestimmt. Achtung: Das
     funktioniert erst ab Version 1.3 von sliplogin!

  4. Netzmaske fr den Anrufer in Dezimalpunktschreibweise, fr ein
     Klasse-C Netz also 255.255.255.0.

  5. Verwendeter SLIP Modus, hier knnen Kompression sowie einige andere
     Besonderheiten eingestellt werden.

  6. Timeout. Hier kann man einstellen, wie lange eine Verbindung
     unbenutzt sein darf (d.h. es werden keine Datagramme
     gesendet/empfangen), bevor die Verbindung automatisch unterbrochen
     wird. Ein negativer Wert verhindert das automatische Unterbrechen.

  7. Optionale Argumente

  Hinweise: In den Feldern 2 und 3 knnen sowohl Rechnernamen als auch
  IP Adressen in Dezimalpunktschreibweise stehen.  Wenn Sie Rechnernamen
  verwenden, mssen diese allerdings auflsbar sein, d.h. der Server mu
  in der Lage sein, die zu dem Namen gehrende IP Adresse
  herauszufinden.  berprfen knnen Sie dies z.B. durch ein telnet auf
  diesen Rechnernamen.  Bekommen sie dann die Meldung Trying
  nnn.nnn.nnn..., hat ihr Rechner den Namen einwandfrei aufgelst.
  Bekommen Sie hingegen die Meldung Unknown host, ist der Versuch
  fehlgeschlagen.  Dann verwenden Sie entweder direkt die IP Adresse,
  oder stellen Sie ihr Name Resolving so ein, da der Name gefunden wird
  (siehe dazu den Abschnitt `Konfiguration des Name Resolver').

  Die am hufigsten verwendeten Einstellungen fr den SLIP Modus sind

     normal
        fr normales, unkomprimiertes SLIP.

     compressed
        um van Jacobsen Header Kompression (cSLIP) zu aktivieren.

  Die beiden Optionen schlieen sich natrlich wechselseitig aus.  Fr
  weitere Informationen lesen Sie bitte die Online-Hilfe.

  5.26.1.4.  Konfiguration der Datei /etc/slip.login.

  Hat sliplogin einen passenden Eintrag in /etc/slip.hosts gefunden,
  wird es als nchstes Versuchen, das Script /etc/slip.login zu starten,
  um das SLIP Interface mit den notwendigen Parametern IP Adresse und
  Netzmaske zu konfigurieren.

  Die mit dem Paket gelieferte Beispieldatei sieht folgendermassen aus:

       #!/bin/sh -
       #
       #       @(#)slip.login  5.1 (Berkeley) 7/1/90
       #
       # generische login Datei fuer eine SLIP Verbindung.  sliplogin
       # ruft das Script mit ff. Parametern auf:
       #     $1       $2       $3    $4, $5, $6 ...
       #   SLIPunit ttyspeed   pid   die Argumente aus dem Eintrag in slip.host
       #
       /sbin/ifconfig $1 $5 pointopoint $6 mtu 1500 -trailers up
       /sbin/route add $6
       arp -s $6 <hw_addr> pub
       exit 0
       #

  Sie werden feststellen, da dieses Script ganz einfach nur die Befehle
  ifconfig und route verwendet, um das SLIP Device zu konfigurieren,
  genau wie das auch bei der Verwendung von slattach der Fall wre.

  Beachten Sie auch die Verwendung von Proxy ARP. Damit wird
  sichergestellt, da andere Rechner, die am selben Ethernet Netzwerk
  wie der Server angeschlossen sind, den einwhlenden Rechner erreichen
  knnen.  Ist ihr Server nicht an ein Ethernet Netz angeschlossen,
  knnen Sie diese letzte Zeile ganz auslassen.

  5.26.1.5.  Konfiguration von /etc/slip.logout.

  Falls die Verbindung zusammenbricht sollten Sie sicherstellen, da die
  serielle Schnittstelle in ihren Normalzustand zurckversetzt wird,
  damit der nchste Anrufer sich ganz normal einloggen kann.  Dies
  erreichen sie mit dem Script /etc/slip.logout.  Es hat ein sehr
  einfaches Format und wird mit denselben Parametern wie /etc/slip.login
  aufgerufen (auch wenn davon nur ein paar verwendet werden...)

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

  Alles was es macht, ist das Interface herunterzufahren, wodurch
  automatisch auch die vorher angelegte Route gelscht wird.  Den hier
  ebenfalls enthaltenen arp Aufruf knnen Sie auch wieder lschen, falls
  Sie nicht an ein Ethernet Netzwerk angeschlossen sind.

  5.26.1.6.  Konfiguration von /etc/slip.tty.

  Falls Sie dynamische IP Adressen verwenden (also mindestens einen der
  Rechner mit dem Eintrag DYNAMIC konfiguriert haben), dann mssen Sie
  auch die Datei /etc/slip.tty konfigurieren, indem Sie dort alle zur
  Auswahl stehenden Adressen auflisten.  Sie bentigen diese Datei aber
  nur fr die dynamische Vergabe von IP Adressen.

  Die Datei ist eine Tabelle, die die tty-Devices auflistet, ber die
  SLIP Verbindungen eingehen knnen, und die IP Adresse, die einem
  Anrufer auf dem jeweiligen Port zugewiesen wird:

       # slip.tty    tty -> IP Adressenzuweisung fuer dynamisches SLIP
       # Format: /dev/tty?? xxx.xxx.xxx.xxx
       #
       /dev/ttyS0      192.168.0.100
       /dev/ttyS1      192.168.0.101
       #

  Das vorstehende Beispiel legt also fest da all denjenigen Anrufern,
  die sich ber den Port /dev/ttyS0 einwhlen und in dem entsprechenden
  Feld in der Datei /etc/slip.hosts den Eintrag DYNAMIC haben, die IP
  Adresse  192.168.0.100 zugewiesen bekommen.

  Dadurch bentigt man nur eine Adresse je zur Verfgung stehenden Port
  und kann so die Anzahl der belegten Adressen klein halten.

  5.26.2.  SLIP Server mit dip.

  Zu Beginn ein Hinweis: Einige der in diesem Abschnitt gegebenen
  Informationen entstammen der Hilfe-Seite von dip, in der ebenfalls
  eine kurze Anleitung gegeben wird, wie Linux als SLIP Server
  konfiguriert werden kann.  Alle Angaben hier beziehen sich auf die
  Version dip337o-uri.tgz und gelten nicht automatisch fr andere
  Versionen dieses Paketes.

  dip hat einen speziellen Eingabemodus, in dem es fr denjenigen, der
  es gestartet hat, automatisch alle notwendigen Informationen aus der
  Datei /etc/diphosts zusammensucht, um die serielle Verbindung zu
  konfigurieren und in den SLIP Modus zu schalten.  Dieser besondere
  Modus wird aktiviert, wenn das Programm unter dem Namen diplogin
  gestartet wird.  Um dip auf eine Server zu verwenden mssen Sie also
  lediglich besondere Accounts einrichten, die diplogin als Login-Shell
  verwenden.

  Dafr mu zunchst ein symbolischer Link angelegt werden:

       # ln -sf /usr/sbin/dip /usr/sbin/diplogin

  Dann mssen entsprechende Eintrge in /etc/passwd und /etc/diphosts
  vorgenommen werden.

  Fr jeden Benutzer wird - wie auch bei sliplogin - ein Account
  angelegt, Konvention ist auch hier, den Nutzernamen mit einem groen
  `S' zu beginnen. Das sieht dann etwa so aus:

       Sfredm:ij/SMxiTlGVCo:1004:10:Fred:/tmp:/usr/sbin/diplogin
       ^^         ^^        ^^  ^^   ^^   ^^   ^^
       |          |         |   |    |    |    \__ diplogin als Login Shell
       |          |         |   |    |    \_______ Heimatverzeichnis
       |          |         |   |    \____________ Voller Nutzername
       |          |         |   \_________________ User Group ID
       |          |         \_____________________ User ID
       |          \_______________________________ Verschluesseltes Passwort
       \__________________________________________ Slip User Login Name

  Der Login wird wie gewhnlich vom Programm login(1) abgewickelt.  Ist
  alles in Ordnung, wird das Programm diplogin gestartet.  dip, mit dem
  Namen diplogin aufgerufen, wei dann automatisch, da es als Login-
  Shell benutzt wird.  Als erstes ruft es dann die Funktion getuid() auf
  um die Benutzer ID desjenigen herauszufinden, der das Programm
  gestartet hat.  Danach sucht es in der Datei /etc/diphosts nach dem
  ersten Eintrag, der entweder der Benutzer-ID oder aber dem Namen des
  tty entspricht, ber den die Verbindung aufgebaut wurde, und fhrt
  dementsprechend die Konfiguration durch. Durch die Entscheidung, einem
  Nutzer entweder einen Eintrag fr seine ID zuzuweisen, oder die
  Standardeinstellung fr das tty zu verwenden knnen einfach statische
  und dynamische Adressen parallel verwendet werden.

  dip fgt in diesem Modus automatisch einen Eintrag fr Proxy-ARP
  durch, dies mu also nicht von Hand geschehen.

  5.26.2.1.  Die Konfiguration von /etc/diphosts.

  Die Datei /etc/diphosts wird von dip verwendet, um voreingestellte
  Konfigurationen fr unterschiedliche Rechner zu speichern. Dabei kann
  es sich um Rechner handeln, die sich in ihren Rechner einwhlen, aber
  auch um solche, in die Sie sich mit ihrem Rechner einwhlen.

  Das allgemeine Format der Eintrge in /etc/diphosts sieht so aus:

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

  Die einzelnen Eintrge bedeuten:

  1. Login Name: wie er von getpwuid(getuid()) zurckgeliefert wird,
     oder Name des tty.

  2. unbenutzt: zur Kompatibilitt mit passwd.

  3. Remote Adresse: IP Adresse des anrufenden Rechners, entweder als
     Name oder in Dezimalschreibweise.
  4. Lokale Adresse: IP Adresse des lokalen Rechners, entweder als Name
     oder in Dezimalschreibweise.

  5. Netzmaske: in Dezimalschreibweise.

  6. Kommentar: Beliebiger Eintrag.

  7. Protokoll: SLIP, CSLIP usw.

  8. MTU: Zahl.

  Der untere der beiden Beispieleintrge legt also z.B. fest, da ein
  Anrufer auf ttyS1 die (dynamische) Adresse 145.71.34.3 zugewiesen
  bekommt und die Verbindung mit Komprimierung (CSLIP) und einer MTU von
  296 konfiguriert wird.

  Alle Nutzer, die eine statische IP Adresse zugewiesen bekommen sollen,
  mssen einen Eintrag unter ihrem Login-Namen in /etc/diphosts haben.
  Fr andere Anrufer, denen die IP Adresse dynamisch zugewiesen werden
  soll, mu ein Eintrag fr die in Frage kommenden tty Ports vorhanden
  sein.  Es sollte auf jeden Fall fr jeden vorhandenen Port ein Eintrag
  vorhanden sein um sicherzustellen, da ein Anrufer in jedem Fall eine
  gltige Konfiguration vorfindet.

  Wenn sich nun ein Benutzer einlogged, wird er ganz normal nach Name
  und Pawort gefragt.  Hier mu er seinen SLIP Login-Namen und das
  zugehrige Pawort eingeben. Verluft alles normal wird der Benutzer
  keinerlei zustzliche Meldungen bekommen, er sollte dann einfach die
  Verbindung in den SLIP Modus schalten, dann sollte er eine Verbindung
  mit den Parametern aus diphosts aufbauen knnen.

  5.26.3.  SLIP Server mit dem dSLIP Paket

  Matt Dillon (dillon@apollo.west.oic.com) hat ein Paket von kleinen
  Programmen und Shell-Scripts geschrieben, mit denen SLIP sowohl im
  Dial-in wie im Dial-out betrieben werden kann.  Allerdings mu die
  Shell tcsh installiert sein, da mindestens eines der Scripts auf deren
  Syntax angewiesen ist.  Jedoch ist dies keine groe Einschrnkung, da
  die tcsh bei den meisten Distributionen mitgeliefert wird.  Auerdem
  gehrt zu Matts Paket auch eine ausfhrbare Kopie des Programmes
  expect, das ebenfalls an einigen Stellen bentigt wird.  Es ist von
  Vorteil wenn man sich mit expect bereits auskennt, da andernfalls bei
  der Konfiguration leicht Fehler gemacht werden knnen.  Aus diesem
  Grunde empfiehlt sich das Paket mehr fr die bereits mit Unix
  vertrauten, man sollte sich aber trotzdem nicht davon abhalten lassen,
  sich das Programm einmal anzusehen, zumal Matt eine sehr gute
  Installationsanleitung im README gibt.

  Das dSLIP Paket bekommt man von:

       apollo.west.oic.com:/pub/linux/dillon_src/dSLIP203.tgz

  oder

       sunsite.unc.edu:/pub/Linux/system/Network/serial/dSLIP203.tgz

  Wichtig ist, die Datei README aufmerksam zu lesen und vor allem die
  dort angegebenen Eintrge in den Dateien /etc/passwd und /etc/group
  einzufgen, bevor ein make install ausgefhrt wird.

  5.27.  Untersttzung fr STRIP (Starmode Radio IP)

  Die Device Namen fr STRIP sind ??? usw.

  Optionen beim Kernel kompilieren:

       Network device support  --->
               [*] Network device support
               ....
               [*] Radio network interfaces
               < > STRIP (Metricom starmode radio IP)

  Das STRIP Protokoll wurde speziell fr eine besondere Art von Funk-
  Modems entwickelt, die in einem Forschungsprojekt der Universitt
  Stanford mit dem Namen MosquitoNet Project verwendet werden:

       http://mosquitonet.Stanford.EDU/mosquitonet.html

  Sie finden dort eine Menge interessanter Informationen - selbst wenn
  Sie nicht an dem Projekt selber interessiert sind.

  Die Metricom Sender werden an die serielle Schnittstelle
  angeschlossen, verwenden verteilte Wellenlngenbereiche und knnen
  typischerweise etwa 100kbps bertragen.  Informationen ber diese
  Sender finden sie auf dem Metricom Web Server (www.metricom.com).

  Die normalen Netzwerkprogramme untersttzen dieses Protokoll derzeit
  nicht, sie mssen sich also speziell angepate Versionen vom
  MosquitoNet Webserver beschaffen. Genauere Informationen, welche
  Software Sie bentigen, finden sie auf der MosquitoNet STRIP Page:

       http://mosquitonet.Stanford.EDU/strip.html

  Eine kurze Zusammenfassung der Konfiguration: Sie verwenden eine
  modifizierte Version des Programmes slattach, um die serielle
  Verbindung in den STRIP Modus zu schalten, und konfigurieren die neuen
  Devices dann wie ein normales Ethernet Device. Einziger wichtiger
  Unterschied: STRIP untersttzt kein ARP, die ARP Eintrge fr alle
  Rechner eines Sub-Netzwerkes mssen also von Hand vorgenommen werden.

  5.28.  Token Ring

  Die Namen der Token Ring Devices sind tr0, tr1 usw.  Token Ring ist
  ein Standard LAN Protokoll von IBM, bei dem Kollisionen von
  Datagrammen dadurch vermieden werden, da jeweils immer nur ein
  Rechner des LAN das Recht hat, Daten zu bertragen.  Auf dem LAN wird
  ein `Token' vergeben, das zu einem beliebigen Zeitpunkt immer nur ein
  Rechner haben kann.  Nur dieser Rechner ist befugt, zu senden.  Sind
  die Daten bertragen, wird das Token an den nchsten Rechner
  weitergegeben.  Das Token wandert also zwischen allen aktiven Rechnern
  herum, daher der Name `Token Ring'.

  Optionen beim Kernel kompilieren:

  Network device support  --->
          [*] Network device support
          ....
          [*] Token Ring driver support
          < > IBM Tropic chipset based adaptor support

  Die Konfiguration eines Token Ring Device ist bis auf die anderen
  Devicenamen identisch zur Konfiguration eines Ethernet Device.

  5.29.  X.25

  X.25 ist ein Packet Switching Protokoll, das durch die C.C.I.T.T.
  festgelegt wurde, einer Basis von Standards, die von
  Telefongesellschaften in den meisten Teilen der Welt anerkannt sind.
  An einer Implementation von X.25 und LAPB wird derzeit gearbeitet, die
  jeweils aktuelle Version ist Bestandteil der Entwickler-Kernels 2.1.*.

  Jonathon Naylor (jsn@cs.nott.ac.uk) leitet die Entwicklung, es wurde
  eine Mailing Liste angelegt, ber die Diskussionen zum Thema X.25
  unter Linux gefhrt werden.  Um sie zu abonnieren schicken sie eine
  Mail an majordomo@vger.rutgers.edu mit dem Text "subscribe linux-x25"
  als Inhalt der Mail.

  Erste Versionen der Konfigurationsprogramme bekommen Sie per FTP von:

       ftp.cs.nott.ac.uk:/jsn/

  5.30.  WaveLan Karten

  Die Device Namen fr WaveLan sind eth0, eth1 usw.

  Optionen beim Kernel kompilieren:

       Network device support  --->
               [*] Network device support
               ....
               [*] Radio network interfaces
               ....
               <*> WaveLAN support

  WaveLan Karten sind fr Kabellose Verbindungen und verwenden
  Multifrequenztechnik.  Die Karten verhalten sich praktisch wie
  Ethernet-Karten und werden genauso konfiguriert.

  Informationen ber diese Karten bekommen Sie von Wavelan
  (http://www.wavelan.com).

  6.  Kabel und Verkabelung

  Wer mit einem Ltkolben umgehen kann mchte sich vielleicht ein Kabel
  basteln, um zwei Linux Rechner zu verbinden.  Die folgenden Diagramme
  sollten Sie dabei untersttzen.

  6.1.  Ein Serielles NULL Modem Kabel

  Nicht alle NULL Modem Kabel sind gleich.  Viele dieser Kabel machen
  nicht mehr als dem Rechner vorzugaukeln da die notwendigen Signale
  vorhanden sind und vertauschen Transmit und Receive. Das ist im
  Prinzip OK, bedeutet aber, da Sie Software Flow Control (XON/XOFF)
  verwenden mssen, was weniger effizient ist als Hardware Flow Control.
  Das folgende Kabel bietet die bestmgliche Signalverbindung zwischen
  Rechnern und erlaubt die Verwendung von Hardware Flow Control
  (RTS/CTS).

       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

  6.2.  Kabel fr die Parallelschnittstelle (PLIP)

  Wenn Sie zur Verbindung zweier Rechner das PLIP Protokoll nutzen
  wollen, sollten sie folgende Verkabelung whlen, die unabhngig von
  der Art der verwendeten Parallelschnittstelle ist.

  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

  Hinweise:

    Die mit einem Stern * gekennzeichneten Pins drfen nicht verbunden
     werden.

    Geschirmte Kabel sollten nur auf einer Seite mit dem Metall des
     Steckers verbunden werden.

    Vorsicht: Ein falsch verdrahtetes PLIP-Kabel kann ihre Controler
     Karte zerstren!. Seien Sie sehr vorsichtig, und berprfen sie
     jede Verbindung doppelt um unntigen rger zu vermeiden.

  6.3.  (Thin) Ethernet Verkabelung (10base2)

  10base2 ist ein Ethernet Standard, der die Verwendung von 52 Ohm
  Koaxialkabel mit einem Durchmesser von etwa 5mm vorschreibt. Bei der
  Verbindung von Rechnern mit dieser Art von Kabel sind einige wichtige
  Regeln zu beachten.

  Das erste ist, da an beiden Enden des Kabels Terminatoren angebracht
  werden mssen.  Ein Terminator ist ein 52 Ohm Widerstand der
  sicherstellt, da ein Signal am Ende des Kabels nicht reflektiert
  wird. Ohne einen solchen Endwiderstand arbeitet das Netzwerk
  unzuverlssig oder gar nicht.

  Normalerweise werden T-Stcke verwendet, um Rechner anzuschlieen, das
  Netzwerk sieht also etwa so aus:

        |==========T=============T=============T==========T==========|
                   |             |             |          |
                   |             |             |          |
                 -----         -----         -----      -----
                 |   |         |   |         |   |      |   |
                 -----         -----         -----      -----

  die Zeichen | an beiden Enden stellen die Terminatoren dar, ==== ist
  ein Stck Koaxial-Kabel mit BNC-Steckern, T das erwhnte T-Stck.  Die
  Kabellnge zwischen T-Stck und der Ethernetkarte mu uerst kurz
  gehalten werden, normalerweise sollte es direkt am Ausgang der Ether
  netkarte angebracht werden.

  7.  Glossar der im Text verwendeten Ausdrcke

     ARP
        Ein Akronym fr Address Resolution Protocol. Es beschreibt, wie
        ein vernetzter Rechner einer IP Adresse eine Hardware Adresse
        zuordnet.

     ATM
        Ein Akronym fr Asynchronous Transfer Mode. Ein ATM Netzwerk
        verpackt Daten in Blocks einer vorgegebenen Gre, die effizient
        von einem zum anderen Punkt bertragen werden kann.

     Klient
        Damit bezeichnet man meist eine Software auf der Nutzer-Seite
        eines Systems.  Es gibt da aber Ausnahmen, z.B. ist das X Window
        System ein Server auf der Nutzer-Seite, und das X-Programm ein
        Klient auf dem anderen (remote) Rechner, der die Dienste des
        (lokalen) Servers in Anspruch nimmt. Bei einem Peer-to-Peer
        Netzwerk wie SLIP oder PPP ist der Klient diejenige Seite, die
        die Verbindung initiiert, die angerufene Seite bezeichnet man
        als Server.

     Datagramm
        Ein Datagramm ist ein einzelnes Datenpaket, bestehend aus Daten
        und einem Header, der die Adressen enthlt. Basiseinheit der
        bertragung ber ein IP Netzwerk, wird manchmal auch als `Paket'
        bezeichnet.

     DLCI
        Data Link Connection Identifier, bezeichnet eine eindeutige
        Point-to-Point Verbindung ber ein Frame Relay Netzwerk. DLCI's
        werden normalerweise vom Provider festgelegt.

     Frame Relay
        Eine Netzwerktechnologie die insbesondere fr Datenverkehr
        optimiert ist, der in Spitzen auftritt. Die Netzwerkkosten
        werden reduziert, indem sich mehrere Nutzer die Bandbreite einer
        Verbindung teilen. Dabei wird davon ausgegangen da die
        Hauptnutzungszeiten der verschiedenen Teilnehmer sich nicht
        berschneiden.

     Hardware Adresse
        Eine Zahl, die einen Rechner in einem physikalischen Netzwerk
        eindeutig auf Hardware-Zugriffsebene identifiziert.  Beispiele
        hierfr sind die Ethernet-Adresse oder die AX.25 Adresse.

     ISDN
        Ein Akronym fr Integrated Services Dedicated Network.  Bietet
        einen standardisierten Weg fr Telefongesellschaften, Sprache
        oder Daten zum Endkunden zu bertragen.

     ISP
        Ein Akronym fr Internet Service Provider - Anbieter von
        Internet Diensten. Organisationen oder Firmen, die anderen
        Personen Anschlu an das Internet anbieten.

     IP Adresse
        Eine Nummer, die einen Rechner in einem IP Netzwerk eindeutig
        identifiziert. Die Adressen sind 4 Byte lang und werden fr
        gewhnlich in der Dezimalpunktschreibweise dargestellt, bei der
        jedes Byte als Dezimalzahl (0-255), durch Punkte getrennt,
        aufgeschrieben wird.

     MSS
        Ein Akronym fr Maximum Segment Size .  Die maximale Gre eines
        Datenpaketes, das auf einmal bertragen werden kann. Um lokale
        Fragmentation zu vermeiden sollte gelten MSS=MTU-IP_Header.

     MTU
        Ein Akronym fr Maximum Transmission Unit. Die Maximale Gre
        eines Datagrammes, die ber ein IP Interface bertragen werden
        kann, ohne in Teilstcke zerlegt werden zu mssen. Die MTU
        sollte grer sein als das grte Datenpaket, das man
        unfragmentiert bertragen will (da noch der IP-Header
        hinzukommt).  Das verhindert eine Fragmentierung allerdings nur
        lokal, da andere Rechner auf der Verbindung mglicherweise
        kleinere Werte fr die MTU verwenden und die Datenpakete dann
        dort fragmentiert werden.  Typische Werte sind 1500 fr ein
        Ethernet Interface und 576 fr ein SLIP Interface.

     Route
        Der Weg, den ein Datenpaket vom Startrechner zum Zielrechner
        nimmt.

     Server
        Normalerweise eine Software auf der fr den Nutzer nichtlokalen
        Seite einer Verbindung.  Ein Server bietet einen Dienst fr
        einen oder mehrere Klienten an.  Beispiele sind FTP, NFS oder
        DNS.  Bei einem Peer-to-Peer Netzwerk bezeichnet der Server den
        angerufenen Rechner, der anrufende Rechner ist der Klient.

     Window
        Die grte Datenmenge, die der Empfnger zu jedem beliebigen
        Zeitpunkt empfangen kann.

  8.  Linux fr einen ISP ?

  Wenn Sie Linux verwenden wollen, um Netzwerkdienste anzubieten,
  sollten sie einen Blick auf die Linux ISP Homepage

       http://www.anime.net/linuxisp/

  werfen.  Sie finden dort viele Verweise auf hilfreiche Informationen
  zu diesem Thema.

