  Linux NET-3 HOWTO
  Terry Dawson (terry@perf.no.itg.telecom.com.au)         und
  Peter Stterlin (pit@uni-sw.gwdg.de)
  v1.0-2, 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 oder 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
  verstehen 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, der 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.x 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 dieses 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. Dieses ist ein Teil des Linux Documentatation
  Project und kann in diverse Formaten bezogen werden:

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


  Inzwischen kann es auch direkt ber das Netz gelesen werden:

       http://metalab.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 Newsgruppen gibt es auch eine, die sich speziell mit
  allen Belangen des Netzwerkens befat:

  de.comp.os.unix.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.  Dieses
  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

        Textversion
           athos.rutgers.edu:/runet/tcp-ip-intro.doc


        PostScript
           athos.rutgers.edu:/runet/tcp-ip-intro.ps


     TCP/IP administration

        Textversion
           athos.rutgers.edu:/runet/tcp-ip-admin.doc


        PostScript
           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




  Die folgenden beiden Bcher befassen sich mit dem Schreiben von
  Netzwerk-Anwendungen in einer Unix Umgebung:



       "Unix Network Programming 1/2"
       von W. Richard Stevens

       Prentice Hall publications





  Ein guter Tip ist eventuell auch die Newsgruppe

       comp.protocols.tcp-ip


  Eine ungemein wichtige Quelle fr spezielle technische Informationen
  zu Internet und TCP/IP Netzwerken sind die RFCs. 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 RFCs gesammelt und archiviert werden.
  Viele davon sind per 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 wie derzeit 2.1.x,
  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
  diese in jedem Fall installieren.

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

  Die Programme werden von Bernd Eckenfels betreut und knnen via FTP
  bezogen werden:


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

    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. Folgendes Beispiel zeigt
  dieses an Hand der 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 Programmen. 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 Netzwerk-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 ist 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 UND
  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
        RFC 1597 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 fr 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,
  was fr Interface Configure, also Schnittstellenkonfiguration, steht.

  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 Protokoll zur Auflsung von Adressen (address
        resolution protocol) 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 Netmask 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.  Dieses findet  z.B. im Falle von SLIP
        und PPP Verbindungen Verwendung.


     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.

  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 (toplevel 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.
  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    name.dieses.rechners




  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 mit
  geteilt, da es sich um einen Eintrag fr ein ganzes Netzwerk handelt.
  Die andere Alternative ist ein Eintrag host, bei dem nur eine einzige
  IP Adresse eingegeben 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
  Tabelle 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 Tabelle 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 wie auch 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 Rechner im
  Netzwerk ausfllt, der als Router arbeitet. In diesem Fall besteht die
  einzige Mglichkeit, ein Datenpaket dennoch zum Ziel weiterzuleiten
  darin, von Hand einzugreifen und die entsprechenden Routes manuell zu
  ndern - vorausgesetzt natrlich, es existiert solch ein alternativer
  Weg.  Das ist umstndlich, langsam und fehleranfllig. Deshalb wurden
  unterschiedliche Mechanismen entwickelt, um die Routing Tabelle
  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,
  ansonst 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 Tabelle 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 Daemon 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 Daemon routed erkennt beim Start automatisch alle aktiven
  Netzwerkschnittstellen und sendet und erkennt ber diese
  Schnittstellen Meldungen, um festzustellen, ob nderungen in der Rout
  ing Tabelle 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 Daemon bentigt nur, wer auf seinem Rechner mehrere
     verschiedene mgliche Routes zu einer Zieladresse besitzt.

  2. Der Routing Daemon 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 Daemon, berwacht einen
  Port. Er nimmt ankommende Verbindungswnsche entgegen und fhrt dann
  die jeweiligen Aktionen aus. Es gibt zwei unterschiedliche Methoden,
  wie ein solcher Netzwerk-Daemon arbeitet:

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



     inetd Servers
        Der inetd Server ist ein besonderer Daemon, 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 der
  den unterschiedlichen Portnummern Namen zugeordnet werden, und
  /etc/inetd.conf, die Konfigurationsdatei des inetd Netzwerk Daemons.


  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, die durch beliebig viele Leerzeichen
  getrennt sind. 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 Zahl, die die Portnummer angibt, unter der der jeweilige
           Service angesprochen werden kann. Die meisten der blichen
           Services haben festgelegte Nummern. Dieses 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 technis
        chen 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: DE-NET3-HOWTO.sgml,v 1.4 1999/11/10 13:43:50 mbudde Exp $
  #
  # Netzwerk Dienstes, Internet Ausfhrung
  #
  # Man beachte, da es zur Zeit die Politik von IANA ist, eine einzelne,
  # gut bekannte Port Nummer sowohl fr TCP als auch UDP zuzuweisen. Daher
  # gibt es oft auch einen UDP Eintrag, obwohl das entsprechende Protokoll
  # UDP garnicht untersttzt.
  # Aktualisiert durch RFC 1340, "Assigned Numbers" (Juli 1992). Nicht
  # alle Ports sind enthalten, sondern nur die weiter verbreiteten.

  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 - privat
  smtp            25/tcp          mail
  # 26 - nicht zugewiesen
  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 - reserviert
  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
  #
  # spezielle UNIX Dienste
  #
  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
  #
  # Aus "Assigned Numbers":
  #
  #> Die registrierten Ports werden nicht von der IANA kontrolliert
  #> und knnen auf den meisten Systemen von Prozessen gewhnlicher
  #> Benutzer verwendet werden.
  #
  #> Ports werden in TCP [45,106] verwendet, um die Endpunkte von
  #> logischen Verbindungen, die fr lnger dauernden Austausch
  #> von Daten verwendet werden, zu kennzeichnen. Um Dienste fr
  #> unbekannte Nutzer anzubieten, wird ein Port definiert, um
  #> Kontakt zu diesem Service aufzunehmen. Diese Liste definiert die
  #> Ports, die von den Server Prozessen fr die Kontaktaufnahme
  #> verwendet werden. Whrend IANA die Benutzung dieser Ports nicht
  #> kontrollieren kann, registriert sie die Verwendung dieser Ports.
  #
  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 (Athena/MIT Projekt) Dienste
  # Man beachte, da diese fr Kerberos v4 und nicht offiziell sind.
  # Auf Rechner, die v4 verwenden, sollte vor diesen das Hash Zeichen
  # entfernt werden und die obigen v5 Eintrge auskommentiert werden.
  #
  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
  #
  # Nicht offizielle aber (fr NetBSD) notwenige Dienste
  #
  supfilesrv      871/tcp                 # SUP server
  supfiledbg      1127/tcp                # SUP debugging
  #
  # Datagram Delivery Protocol Dienste
  #
  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 Dienste
  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

  # Lokale Dienste





  4.8.2.



  /etc/inetd.conf

  Die Datei /etc/inetd.conf ist die Konfigurationsdatei des Server
  Daemons inetd. Bei einer eingehenden Anfrage nach einem bestimmten
  Service sieht der Daemon 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 Daemon 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 /etc/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 TCP basierten 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 tcp
        oder 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, weshalb hier meist root steht.


     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: weitere Informationen finden sich in inetd(8)
  #
  # Datenbank der Internet Server Konfiguration
  #
  #
  # Modifiziert fr Debian von Peter Tobias <tobias@et-inf.fho-emden.de>
  #
  # <service_name> <sock_type> <proto> <flags> <user> <server_path> <args>
  #
  # Interne Dienste
  #
  #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
  #
  # Dieses sind die Standardienste.
  #
  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 und talk sind BSD Protokolle.
  #
  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 und uucp Dienste
  #
  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
  #
  #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" ist fr den GNU finger Server, der fr Debian verfgbar ist.
  # Hinweis: Die augenblickliche Implementation des "finger" Daemons
  #          erlaubt es, als "root" gestartet zu werden.
  #
  #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
  #
  # Der TFTP Dienst wird vor allem fr das Booten von anderen Rechner
  # angeboten. Auf den meisten Rechnern luft dieses nur, falls sie als
  # Bootserver fr andere Rechner dienen.
  #
  #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 Authentifikation Dienst (mu eventuell verndert werden)
  #
  #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
  #
  # Dienste, die nur auf dem Kerberos Server laufen (mu eventuell
  # verndert werden).
  #
  #krbupdate      stream tcp      nowait  root    /usr/sbin/tcpd  /usr/sbin/registerd
  #kpasswd        stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/kpasswdd
  #
  # RPC basierte Dienste
  #
  #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
  #
  # Ende von 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 verwenden
  Programmen wie tcpdump diese Datei, 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: DE-NET3-HOWTO.sgml,v 1.4 1999/11/10 13:43:50 mbudde Exp $
  #
  # Internet (IP) Protokolle
  #
  # Fr NetBSD basierend auf RFC 1340 (Assigned Numbers, Juli 1992)
  # auf den neusten Stand gebracht.

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


       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 route wird 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 nicht bentigten 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
  Daemonen 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 - Benutzer, die sich nicht per FTP
       # einloggen drfen
       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 - ttys, auf denen sich root einloggen
  # darf
  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 manual pages 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 Daemons, 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, meinrechner.zuhause.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 Rechnern der Zugang zu
  Diensten auf dem eigenen Rechner verboten werden soll.

  Ein einfaches Beispiel sieht etwa so aus:


       # /etc/hosts.deny
       #
       # Kein Zugang fr Rechner mit suspektem Namen
       ALL: PARANOID
       #
       # Verbot fr 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-Daemons

  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-
  Daemon 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-Daemons 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
  Erkennung. Der Buchstabe am Ende des Devicenamens gibt an, ob als
  Paketformat Ethernet Encapsulation oder RFC 1051 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 Netzwerk.
  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 folgendermaen
  vor:


       # cd /usr/src
       # tar xvfz .../netatalk-1.4b2.tar.Z




  Nachdem man das Archiv entpackt hat, sollte man die Datei Makefile
  editieren, um die Software an das eigene System anzupassen. So legt
  z.B.  die Variable DESTDIR fest, wohin die Dateien installiert werden.


       # make
       # 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. Eventuell hat das Verzeichnis
  auch einen anderen Namen. Das hngt davon ab, wo 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 Daemon 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
  manual page zum afpd. Eine einfache Konfiguration knnte etwa so
  aussehen:


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




  Dadurch wird das lokale Verzeichnis /tmp als AppleShare Volume Scratch
  und das ffentliche FTP-Verzeichnis als AppleShare Volume Public Area
  exportiert. Die Namen fr die Volumes mssen nicht angegeben werden.
  Wenn sie fehlen, weist der Daemon 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 Daemon. Dieses Programm bernimmt die Druckauftrge von
  Applerechnern im Netz und leitet sie an den lokale Drucker Spool
  Daemon weiter.

  Zur Konfiguration dieses Daemon 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-Daemon 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




  Alles sollte nun 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 Daemon) bringt die Festplatte
     ziemlich durcheinander. Er legt im gemounteten Verzeichnisbaum 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
     Daemon 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 unter folgender Adresse:
       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.





  AX.25 (AF_AX25)

  AX.25 Devicenamen sind sl0, sl1 usw. in 2.0.x Kernels bzw.  ax0, ax1
  usw. in 2.1.x Kernels.

  Optionen beim Kernel kompilieren:


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




  Die Protokolle AX.25, 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.x Kernels auftauchen.


  5.6.



  EQL - Lastverteilung auf mehrere Leitungen

  EQL Devices haben den Namen eql. Bei den 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. Der
  Hintergrund dabei ist, da mehrere langsame Leitungen oft billiger als
  eine schnelle sind.

  Optionen beim Kernel kompilieren:


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




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

  Um EQL richtig zu konfigurieren, bentigt man die EQL Tools:

       metalab.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 verknpft
  werden.  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 werden 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 Handar
  beit 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, bei der es sich um eine
  abgenderte Version der dem Paket beiliegenden Beispieldatei handelt:

































































  # /etc/frad/router.conf
  # Dies ist eine Beispielkonfiguration fr Frame Relay.
  # Alle mglichen Eintrge sind aufgefhrt, die Standard-
  # einstellungen basieren auf dem Code des DOS-Treibers
  # fr die Karte S502A von Sangoma.
  #
  # Ein "#" irgendwo in der Zeile leitet einen Kommentar
  # ein. Leerzeilen werden ignoriert (TAB ist auch erlaubt).
  # Unbekannte Eintrge [] 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 Eintrge fr
  # alle Devices. Sie koennen fr einzelne Karten in den
  # entsprechenden Abschnitten verndert 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 fr
  # 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 Eintrge sind spezifisch fr Sangoma
  #

  # Typ der Sangoma Karte - S502A, S502E, S508
  Board=S502E

  # Name der Test-Firmware fr 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 fr diese Karte
  Mem=C8          # Adresse fr Memory Window, A0-EE
  IRQ=5           # IRQ Nummer, fr S502A nicht angeben
  DLCIs=1         # Anzahl der DLCIs an diesem Device
  DLCI_1=16       # DLCI #1's Nummer, 16 - 991
  # DLCI_2=17
  # DLCI_3=18
  # DLCI_4=19
  # DLCI_5=20

  # Hier angegeben, gelten die Eintrge nur fr die
  # jeweilige Karte und berschreiben 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 irgendeine andere Karte
  #

  # [sdla1]
  # Type=FancyCard      # Art des Device
  # Board=              # Typ der Sangoma Karte
  # Key=Value           # Eintrge spezifisch fr dieses
  #                     # Device


  # DLCI Default Konfigurationsparameter
  # Diese knnen in den jeweiligen spezifischen
  # Abschnitten berschrieben 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 manual
  page 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:


       #
       # Lschen der bestehenden Accounting Regeln
       ipfwadm -A -f
       #
       # Neue Regeln fr 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 Firewalls, 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

  # Lschen 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 wre hier "-a deny" anstelle von "-a reject -y",
  # aber dann wre es auch nicht mehr mglich, ber dieses
  # Interface selber eine Verbindung aufzubauen.
  # Das -o veranlasst, da alle geblockten Datagramme
  # protokolliert werden. Das verbraucht viel Plattenplatz,
  # andernfalls ist man aber ber 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 nichts kommen.

  /sbin/ipfwadm -F -a deny -o -S 224.0/3 -D 172.16.37.0/24

  # 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 mu das auch
  # freigegeben werden.

  /sbin/ipfwadm -F -a accept -P udp -S 0/0 \
                -D 172.16.37.19 53

  # "Antworten" von gefhrlichen Ports wie NFS und Larry
  # McVoys NFS Erweiterung werden abgelehnt.  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 wrden Verzgerungen 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 fr 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, hngen Sie ein 1:1023 an.

  /sbin/ipfwadm -F -a deny -o -y -P tcp -S 0/0 \
                -D 172.16.37.0/24

  # ... ebenfalls fr 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 Sie 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 16 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.x 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) hat in Deutschland vor
  allem als Ersatz fr das alte analoge Telefonnetz eine recht groe
  Verbreitung gefunden. Im Gegensatz zum alten Telefonnetz ist dieses
  vollstndig digital ausgelegt. Auch hat man von Anfang an ISDN nicht
  nur zur bermittlung von Sprache ausgelegt sondern auch fr andere
  Dienste wie z.B. BTX, Fax oder Datenbertragung. Wie beim
  herkmmlichen Telefonnetz wird jeweils eine Punkt zu Punkt Verbindung
  zwischen zwei Teilnehmern aufgebaut.

  Fr die Datenbertragung ist ISDN vor allem wegen der
  Datenbertragungsrate von 64 kBit/s und der geringeren
  Stranflligkeit interessant.  Inzwischen hat das herkmmliche
  Telefonnetz allerdings durch die Digitalisierung der
  Vermittlungsstelle nachgezogenn und erlaubt jetzt auch mit Modems
  recht hohe Geschwindigkeiten.

  Ein ISDN-Anschlu unterteilt sich in mehrere B-Kanle und einen D-
  Kanal. Die B-Kanle dienen der eigentlichen Datenbertragung.  Pro
  Kanal werden 64 kBit/s bertragen. Der D-Kanal hat eine
  Geschwindigkeit von 16 kBit/s bzw. 64 kBit/s. ber ihn werden
  Kontrollinformationen z.B. fr den Verbindungsaufbau bermittelt. Der
  Kunde kann zwischen verschiedenen ISDN-Anschlssen whlen. Neben dem
  fr Privatkunden blichen Anschlu mit zwei B-Kanlen, gibt es noch
  Multiplexer Anschlsse, die 30 B-Kanle anhalten und damit immerhin
  eine Bandbreite von 2 MBit/s bieten.

  Zu jedem Zeitpunkt knnen beliebig viele dieser Kanle in jeder
  Kombination benutzt werden. So knnen z.B. zwei Verbindungen mit
  jeweils 64 kBit/s zu zwei anderen Teilnehmern aufgebaut werden.  Es
  knnen aber auch beide Kanle zusammengefat werden, so da dann eine
  Verbindung mit 128 kBit/s zu einem anderen Teilnehmer aufgebaut werden
  kann. Natrlich knnen auch Kanle unbenutzt bleiben, da ja fr jeden
  Kanal jeweils Gebhren erhoben werden, wenn er benutzt wird.

  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 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. Diese werden wie
  analoge Modems an die serielle Schnittstelle des Rechners
  angeschlossen. Die meisten dieser Gerte werden wie ein Modem per AT-
  Befehlssatz gesteuert und bentigen deshalb keinen speziellen Treiber.
  Eine andere Mglichkeit ist die Verwendung einer passiven oder aktiven
  ISA- oder PCI-Karte. Da hier der Rechner meistens einen Teil des ISDN-
  Protokolls generieren mu, bentigt Linux spezielle Treiber fr jeden
  Kartentyp.

  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 isdn4linux FAQ, zu beziehen bei

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


  Es gibt dort eine deutsche und eine englische Version. Auerdem gibt
  es noch eine deutsche ISDN HOWTO.

  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 Daemon 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. Allerdings kann der Rechner nicht
  direkt als Router ins Internet fr andere Rechner verwendet werden, da
  diese dann auch eine weltweit eindeutige IP Adresse bentigen wrden.
  Nun knnte man ja prinzipiell den eigenen Provider bieten, mehr
  offizielle IP Adresse zur Verfgung zu stellen. Dem stehen jedoch zwei
  Grnden entgegen. Zum einen sind IP Adressen im Internet ein knappes
  Gut, zum anderen bieten die meisten Provider solche Leistung nur in
  Verbindung mit sehr teuren Vertrgen fr Firmen an.

  IP Masquerade erlaubt es nun, dieses Problem zum umgehen, in dem die
  anderen Rechner ebenfalls diese eine IP Adresse verwenden und zum
  Provider deshalb als ein einziger Rechner erscheinen - deshalb der
  Name Maskerade. Ein kleiner Nachteil dabei ist allerdings, da
  dieses 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 zu konfiguriert werden, da er die IP Adresse des Linux
  Rechners als Gateway bzw. Router verwendet.

  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 Konfigurationsbefehle in diesem Fall sind:


       # Netzwerk Route fr Ethernet
       route add 192.168.1.0 netmask 255.255.255.0 eth0

       # Default Route fr 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. 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 in verschiedenen Segmenten von 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 AX.25, 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 einwandfrei,
  insbesondere bei langsamen Rechnern wird man sie aber unter Umstnden
  erhhen mssen und zwar auf dem schnelleren 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 IRQs 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:


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

  Wie ein fr PLIP passendes Kabel auszusehen hat, wird in Abschnitt
  ``Kabel fr die parallele Schnittstelle'' beschrieben.  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 Controllers 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 von root durch einen
  einfachen Befehl gestartet werden kann:


       # pppd




  Stellen Sie sicher, da sie in der Datei /etc/ppp/options die Option
  -detach eingetragen 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 Daemon 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.x untersttzt.

  Optionen beim Kernel kompilieren:


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




  Die Protokolle AX.25, 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 Systeme, die
  Betriebssysteme von Microsoft wie z.B. Windows verwenden, die Platten
  des Linux-Rechners mounten und dessen Drucker verwenden knnen.

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


  5.25.




  SLIP Client

  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 gemietete
  Standleitungen. 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 der
  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

       metalab.unc.edu:/pub/Linux/system/Network/serial/dip/


  Zur Installation gehen Sie wie folgt vor; zuerst wird das Paket
  entpackt:


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




  Nur mu der Makefile an die eigenen Bedrfnisse angepat werden.
  Schlielich wird das Programm kompiliert und installiert:


       # make
       # 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 finden sich in dem Abschnitt ``Dauerhafte SLIP
  Verbindungen''.


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

  Zunchst unterscheiden sich SLIP Verbindungen von Ethernet Netzwerken
  dadurch, da an einem SLIP-Netzwerk immer nur zwei Rechner beteiligt
  sind. Auerdem sind bei SLIP Verbindungen oft 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, da man
  bei jeder Verbindung eine bestimmte IP Adresse zugewiesen bekommt. 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    Programm fr Dialup IP Verbindung
  #
  #       Dieses Datei zeigt, wie DIP verwendet wird.
  #
  #       Fr dynamische Server vom Typ Annex sollte diese
  #       Datei funktionieren. Falls Sie einen statischen
  #       Server mit statischen Adressen verwenden,
  #       benutzen Sie die Datei sample.dip, die als Teil
  #       des dip337-uri.tgz Paketes ausgeliefert wird.
  #
  #
  # Version: @(#)sample.dip       1.40    07/20/93
  #
  # Autor: Fred N. van Kempen, <waltje@uWalt.NL.Mugnet.ORG>
  #

  main:
  # Lege Namen und Adresse des Servers fest.
  # Mein Server heit "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 fr das Modem und die Terminal Verbindung.
  # Das verursacht bei manchen Anwendern Probleme!
  reset

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

  # Vorbereitung zum Whlen
  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, da 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, da ein
  #    "route add -net default xs4all.hacktic.nl"
  # durchgefhrt 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.


  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 fr 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 8 Bit clean 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, Netmask, 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
        Enthlt die Accounts der Benutzer.


     /etc/slip.hosts
        Hier stehen die fr jeden Nutzer spezifischen Informationen fr
        SLIP.


     /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 einem Logout
        oder bei Fehlern korrekt zu beenden.


  5.26.1.1.  Bezugsquellen fr sliplogin

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

       metalab.unc.edu:/pub/linux/system/Network/serial/


  Die TAR Datei enthlt Quellen, vorkompilierte Binrprogramme und die
  manual page.

  Um sicherzustellen, da nur autorisierte Nutzer sliplogin benutzen
  knnen, sollten Sie in der 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 manual pages in der
  Sektion 8 zu installieren, gehen Sie folgendermaen vor. Zuerst wird
  das Paket entpackt:


       # cd /usr/src
       # gzip -dc .../sliplogin-2.1.1.tar.gz | tar xvf -
       # cd sliplogin-2.1.1




  Nun wird das Makefile editiert, falls Sie keine Shadow Pawrter ver
  wenden. Schlielich kann das Paket installiert werden:



       # 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 fr jeden Benutzer von SLIP einen speziellen
  Account in /etc/passwd ein. Eine Konvention hierbei ist es, als
  Benutzernamen ein groes S, gefolgt vom Namen des einwhlenden
  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
  Netmask 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. Aber Vorsicht,
     das funktioniert erst ab Version 1.3 von sliplogin.

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

  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. Wie das geht, wird im
  Abschnitt ``Konfiguration des Name Resolvers'' erlutert.

  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
  Netmask zu konfigurieren.

  Die mit dem Paket gelieferte Beispieldatei sieht folgendermaen aus:



       #!/bin/sh -
       #
       #       @(#)slip.login  5.1 (Berkeley) 7/1/90
       #
       # Generische login Datei fr eine SLIP Verbindung.
       # sliplogin ruft das Script mit folgenden 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. Dieses
  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 fr
       #                    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 manual page 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
       |          \_______________________________ Verschlsseltes 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: 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. Netmask: 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/

    metalab.unc.edu:/pub/Linux/system/Network/serial/

  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)


  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:

       http://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.x.

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

       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 verbinden die Sendeleitung jeweils mit der
  Empfangsleitung des Partners. Das geht zwar im Prinzip, bedeutet aber,
  da Sie eine Software Flukontrolle (XON/XOFF) verwenden mssen, was
  weniger effizient ist als eine Hardware Flukontrolle. Das folgende
  Kabel bietet die bestmgliche Signalverbindung zwischen Rechnern und
  erlaubt die Verwendung der Hardware Flukontrolle (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 parallele Schnittstelle (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.

    Ein falsch verdrahtetes PLIP-Kabel kann ihre Controller 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.

  Die erste ist, da an beiden Enden des Busses 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 Zellen einer vorgegebenen Gre, die effizient
        von einem zum anderen Punkt bertragen werden kann.


     Client
        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
        Client 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 Client 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. DLCIs
        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, das 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
        Ein Server bietet einen Dienst fr einen oder mehrere Clients
        an. Beispiele sind FTP, NFS oder DNS. Bei einem Peer-to-Peer
        Netzwerk bezeichnet der Server den angerufenen Rechner, der
        anrufende Rechner ist der Client.


     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.












































