Linux NET-3 HOWTO <author>Terry Dawson (<tt>terry@perf.no.itg.telecom.com.au</tt>) und Peter Sütterlin (<tt>pit@uni-sw.gwdg.de</tt>) <date>v1.0-2, Dezember 1997 <abstract> Das Betriebssystem Linux enthält bereits im Kernel Unterstützung für fast alle Arten von Netzwerkprotokollen. Ziel dieses Textes ist es, die Installation und Konfiguration der Netzwerk-Software unter Linux sowie der zugehörigen Hilfsprogramme zu beschreiben. </abstract>  <toc>  <sect>Einleitung Die ursprüngliche Version des NET-FAQ wurde von Matt Welsh und Terry Dawson geschrieben, bevor das <em/Linux Documentation Project/ gegründet wurde. Sein Ziel war es, häufig gestellte Fragen über Linux und Netzwerke zu beantworten. Es behandelte die frühen Entwickler-Versionen der netzwerkfähigen Linux Kernel. Das <em/NET-2 HOWTO/ setzte diese Aufgabe fort Es war einer der ersten Texte des LDP und beschrieb das, was zunächst als Version 2 und später als Version 3 der Linux Kernel Netzwerk Software bezeichnet wurde. Der vorliegende Text ersetzt das <em/NET-2 HOWTO/, er beschreibt ausschließlich die aktuelle Version 3 der Netzwerk Software im Linux Kernel. Die früheren Versionen dieses Textes wurden ständig 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 <em/NET-3 HOWTO/ selber behandelt lediglich noch solche Themen, die von den anderen HOWTOs nicht abgedeckt werden. <sect1>Feedback Kommentare und vor allem aktive Beiträge zu diesem Dokument sind jederzeit willkommen. Bitte senden sie Hinweise oder Kommentare zu dieser deutschen Version an mich: <tscreen><htmlurl url="mailto:pit@uni-sw.gwdg.de" name="pit@uni-sw.gwdg.de"></tscreen <sect1>Danksagung Folgenden Personen (ohne bestimmte Reihenfolge) sei an dieser Stelle für ihre Beiträge zu diesem Text gedankt: Axel Boldt, Arnt Gulbrandsen, Gary Allpike, Cees de Groot, Alan Cox, Jonathon Naylor. <sect1>Copyright Dieses Dokument ist urheberrechtlich geschützt. Das Copyright für die englische <htmlurl name="NET-3 HOWTO" url="http://metalab.unc.edu/LDP/HOWTO/NET-3-HOWTO.html">, auf der dieses Dokument basiert, liegt bei Terry Dawson. Das Copyright für die deutsche Version liegt bei Peter Sütterlin. Das Dokument darf gemäß der GNU <htmlurl url="DE-GPL.html" name="General Public License"> verbreitet werden. Insbesondere bedeutet dieses, daß der Text sowohl über elektronische wie auch physikalische Medien ohne die Zahlung von Lizenzgebühren verbreitet werden darf, solange dieser Copyright Hinweis nicht entfernt wird. Eine kommerzielle Verbreitung ist erlaubt und ausdrücklich erwünscht. Bei einer Publikation in Papierform ist das Deutsche Linux HOWTO Projekt hierüber zu <sect>Wie gehe ich mit diesem Text um? Gegenüber früheren Versionen hat sich das Format dieses Dokumentes geändert. 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 nächstes folgen einige generelle Bemerkungen, die man unbedingt lesen und verstehen sollte, bevor man sich mit den spezifischen Technologieteilen befaßt, die den Rest des Textes ausmachen. <descrip> <tag>Generelle Bemerkungen</tag>Lesen sie diesen Abschnitt unbedingt, er betrifft praktisch alle im folgenden beschriebenen Teile und ist zu deren Verständnis unbedingt notwendig. <tag>Welche Art Netzwerk habe ich?</tag>Sie sollten sich darüber informieren, welche Art von Netzwerk sie installiert haben oder installieren wollen, und welche diesbezügliche Hardware in ihrem Computer eingebaut ist/wird. <tag>Spezifische Abschnitte</tag>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 für eine einzelne Technologie relevanten Daten zusammengestellt. <tag>Die eigentliche Konfiguration</tag>Versuchen sie, ihr Netzwerk zu konfigurieren und notieren sie genau alle dabei eventuell auftretenden Probleme. <tag>Weitergehende Fragen</tag>Stoßen sie bei der Konfiguration auf Probleme, die in diesem Text nicht behandelt werden, so lesen sie den Abschnitt über weitergehende Hilfe und Fehlermeldungen. <tag>Viel Spaß!</tag>Ein funktionierendes Netzwerk macht wirklich Spaß, genießen sie es. </descrip> <sect>Allgemeine Information über Netzwerke in Linux <sect1>Eine kurze Geschichte der Netzwerk-Kernelentwicklung <nidx>Netzwerk!Geschichte der Kernelentwicklung</nidx> Eine völlig 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 darüber gab, ob ebendiese Implementationen mit einem restriktiven Copyright belegt werden würden. Außerdem war zu diesem Zeitpunkt der Enthusiasmus recht groß, diese Aufgabe auf eine andere Weise und womöglich sogar besser als in den vorhandenen Treibern zu lösen. Der erste, der die Entwicklung des Linux Netzwerk-Codes leitete, war Ross Biro (<tt><htmlurl url="mailto:biro@yggdrasil.com" name="biro@yggdrasil.com"></tt>). Er schrieb einen zwar nicht ganz vollständigen aber dennoch gut brauchbaren Code, der durch einen Treiber für die WD-8003 Netzwerk-Karte vervollständigt 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 anzuschließen. Dadurch stieg im Linux-Umfeld der Druck, die Entwicklung des Netzwerk-Codes voranzutreiben. Dieser unfaire Druck, wohl zusammen mit seinen privaten Verpflichtungen, veranlaßten Ross, diese Rolle als Hauptentwickler aufzugeben. Seine Bemühungen, das ursprünglich Projekt ins Rollen zu bringen und die Verantwortung dafür zu übernehmen, daß dabei auch unter schwierigen Bedingungen etwas brauchbares herauskam, wirkten als Katalysator für 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 (<tt><htmlurl url="mailto:obz@Kodak.COM" name="obz@Kodak.COM"></tt>) durchgeführt. Dies war ein gewaltiger Schritt nach vorne, da es dadurch möglich wurde, eine große Zahl von Netzwerkanwendungen ohne großen Aufwand für Linux zu portieren. Ungefähr zu diesem Zeitpunkt schrieb Laurence Culhane (<tt><htmlurl url="mailto:loz@holmes.demon.co.uk" name="loz@holmes.demon.co.uk"></tt>) den ersten SLIP-Treiber für Linux. Dadurch konnten endlich auch solche Leute mit dem Netzwerk experimentieren, die nicht über Zugang zu einem Ethernet verfügten. Auch dieser Treiber wurde weiterentwickelt, um eine Internetanbindung über SLIP zu ermöglichen. Erneut stieg die Zahl derjeniger, die aktiv an der Erprobung und Weiterentwicklung der Netzwerk-Software mitarbeiten konnten; auch wurde vielen jetzt vor Augen geführt, was mit Linux alles möglich ist, wenn man erst einmal eine vollständige Netzwerkunterstützung hat. Einer dieser Personen, die aktiv an der Netzwerkunterstützung für Linux arbeiteten, war Fred van Kempen (<tt><htmlurl url="mailto:waltje@uwalt.nl.mugnet.org" name="waltje@uwalt.nl.mugnet.org"></tt>). Nach einer Phase der Ungewißheit, die auf den Rückzug von Ross folgte, bot Fred seine Zeit und Arbeitskraft für diesen Posten an. Fred hatte einige sehr ambitionierte Pläne bezüglich 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 Planbücher der Entwickler, so z.B. die dynamische Geräteschnittstelle, Unterstützung für das Amateurfunk Protokoll AX.25 sowie eine stärker modularisierte Version der Software. Freds Programme wurden zunächst von einigen Enthusiasten benutzt, deren Zahl aber ständig zunahm, je mehr sich herumsprach daß die Software gut funktionierte. Zu diesem Zeitpunkt bestand die Netzwerksoftware immer noch aus einer großen Anzahl von Patches gegenüber dem Standard-Kernel; sie gehörte nicht zur normalen Distribution. Das <em/NET_FAQ/ und die folgenden <em/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 für 80% auch funktionierte. Wie bereits bei Ross stieg der Druck auf Fred als Hauptentwickler. Alan Cox (<tt><htmlurl url="mailto:iialan@www.linux.uk.org" name="iialan@www.linux.uk.org"></tt>) schlug daraufhin eine Lösung des Problems vor. Er wollte Freds NET-2 Code nehmen und die Fehler darin beseitigen, um so eine stabile und zuverlässige 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 zuverlässig in vielen typischen Konfigurationen, und die Benutzer waren glücklich. Alan hatte natürlich auch eigene Ideen und auch die Fähigkeiten, die er zum Projekt beitragen wollte, und in der Folgezeit gab es viele Diskussionen darüber, 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 müsse zunächst funktionieren, dann könne man ihn verbessern, die andere Gruppe wollte ihn zunächst verbessern. Linus fällte letztendlich die Entscheidung, indem er Alan seien Unterstützung anbot und seine Version in die offiziellen Kernel Distribution aufnahm. Dadurch geriet Fred in eine schwierige Lage. Jede Weiterentwicklung seines Codes hätte nun nicht mehr die Verbreitung und breite Nutzerbasis, die für ein gutes Testen nötig wäre. Dadurch würde der Fortschritt langsam und schwierig werden. Fred arbeitete noch eine zeitlang weiter, zog sich dann aber zurück und Alan wurde der neue Kopf der Netzwerk Entwicklung. Donald Becker (<tt><htmlurl url="mailto:becker@cesdis.gsfc.nasa.gov" name="becker@cesdis.gsfc.nasa.gov"></tt>) zeigte bald sein Talent auf dem Bereich des Low-Level Netzwerk-Codes und schuf eine große Zahl von Ethernet-Treibern; fast alle in der Standard Kerneldistribution enthaltenen wurden von ihm entwickelt. Auch einige andere Personen haben wichtige Beiträge geliefert, doch Donalds Arbeit war äußerst fruchtbar und rechtfertigt so die besondere Erwähnung. Alan setzte seine Arbeit an der Verbesserung des NET-2D Codes fort, und beschäftigte sich mit einigen Bereichen der »TODO« Liste, die bislang unberücksichtigt 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 möglichen 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. Unterstützung für PPP wurde von Michael Callahan (<tt><htmlurl url="mailto:callahan@maths.ox.ac.uk" name="callahan@maths.ox.ac.uk"></tt>) und Al Longyear (<tt><htmlurl url="mailto:longyear@netcom.com" name="longyear@netcom.com"></tt>) implementiert. Auch dieses war ein wichtiger Schritt, der die Anzahl derjenigen Nutzer erhöhte, die Linux für Netzwerkaufgaben einsetzten. Durch Jonathon Naylor (<tt><htmlurl url="mailto:jsn@cs.nott.ac.uk" name="jsn@cs.nott.ac.uk"></tt>) wurde der AX.25 Code von Alan deutlich verbessert und Unterstützung für das NetRom Protokoll hinzugefügt. Damit war Linux das einzige System, das sich rühmen konnte, von Haus aus AX.25/NetRom zu unterstützen. Selbstverständlich haben darüberhinaus hunderte weiterer Personen wichtige Beiträge zur Weiterentwicklung der Netzwerk-Software für Linux geliefert. Einige dieser Namen werden weiter unten in den entsprechenden Abschnitten erwähnt; andere haben Module oder Treiber geschrieben, Fehler beseitigt, Vorschläge gemacht, Tests durchgeführt oder einfach moralische Unterstützung geliefert. Jeder von ihnen kann von sich sagen, seinen Teil zum Ganzen hinzugefügt zu haben. Der Linux Netzwerk-Code ist ein hervorragendes Beispiel dafür, welch beeindruckende Ergebnisse der Linux-typische anarchische Stil der Entwicklung liefern kann. Und diese Entwicklung geht natürlich noch immer weiter. <sect1>Wo bekomme ich weitere Informationen zum Netzwerk unter Linux? Alan Cox, der derzeit die Entwicklung des Netzwerk Codes leitet, unterhält eine Seite im World Wide Web, die die Highlights der derzeitigen Entwicklung auflistet: <tscreen><htmlurl url="http://www.uk.linux.org/NetNews.html" name="http://www.uk.linux.org/NetNews.html"></tscreen> <nidx>Netzwork Administrators Guide</nidx> Eine andere gute Quelle ist das Buch von Olaf Kirch: <em/The Network Administrators Guide/. Dieses ist ein Teil des <em/Linux Documentatation Project/ und kann in diverse Formaten bezogen werden: <tscreen><htmlurl url="ftp://metalab.unc.edu/pub/Linux/docs/LDP/network-guide/" name="metalab.unc.edu:/pub/Linux/docs/LDP/network-guide/"> </tscreen> Inzwischen kann es auch direkt über das Netz gelesen werden: <tscreen><htmlurl url="http://metalab.unc.edu/LDP/LDP/nag/nag.html" name="http://metalab.unc.edu/LDP/LDP/nag/nag.html"></tscreen> Olafs Buch ist sehr verständlich und gibt einen sehr tiefgehenden Einblick in die Netzwerk Konfiguration unter Linux. Unter den Linux Newsgruppen gibt es auch eine, die sich speziell mit allen Belangen des Netzwerkens befaßt: <tscreen><htmlurl url="news:de.comp.os.unix.linux.networking" name="de.comp.os.unix.linux.networking"></tscreen> <nidx>Mailingliste!Netzwerk</nidx> Weiterhin besteht eine Mailing Liste zum Thema Netzwerke. Um sie zu abonnieren, genügt eine kurze Mail: <tscreen><verb> To: majordomo@vger.rutgers.edu Subject: anything at all Message: subscribe linux-net </verb></tscreen> Auf vielen der diversen IRC Netzwerke gibt es auch oft <tt/#linux/ Kanäle. 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 möglich an <em/relevanter/ Information angegeben werden. Insbesondere sind das die Versionsnummern des Kernels und der Software wie z.B. <tt/pppd/ oder <tt/dip/, sowie eine genaue Beschreibung der auftretenden Probleme. Dieses umfaßt auch den genauen Wortlaut etwaiger Fehlermeldungen sowie die genaue Syntax, mit der man ein Programm startet. <sect1>Nicht Linux-spezifische Informationsquellen <nidx>Dokumentation!Netzwerk</nidx> Wer nach einer grundlegenden Einführung in TCP/IP Netzwerke sucht, dem seien folgende Dokumente empfohlen: <descrip> <tag>TCP/IP introduction</tag> <descrip> <tag/Textversion/ <tt><htmlurl url="ftp://athos.rutgers.edu/runet/tcp-ip-intro.doc" name="athos.rutgers.edu:/runet/tcp-ip-intro.doc"></tt> <tag/PostScript/ <tt><htmlurl url="ftp://athos.rutgers.edu/runet/tcp-ip-intro.ps" name="athos.rutgers.edu:/runet/tcp-ip-intro.ps"></tt> </descrip> <tag>TCP/IP administration</tag> <descrip> <tag/Textversion/ <tt><htmlurl url="ftp://athos.rutgers.edu/runet/tcp-ip-admin.doc" name="athos.rutgers.edu:/runet/tcp-ip-admin.doc"></tt> <tag/PostScript/ <tt><htmlurl url="ftp://athos.rutgers.edu/runet/tcp-ip-admin.ps" name="athos.rutgers.edu:/runet/tcp-ip-admin.ps"></tt> </descrip> </descrip> Noch detailliertere Informationen zum TCP/IP Netzwerk findet man in folgendem Buch: <tscreen><verb> "Internetworking with TCP/IP" von Douglas E. Comer ISBN 0-13-474321-0 Prentice Hall publications </verb></tscreen> <nidx>Netzwerk!Programmieren</nidx> Die folgenden beiden Bücher befassen sich mit dem Schreiben von Netzwerk-Anwendungen in einer Unix Umgebung: <tscreen><verb> "Unix Network Programming 1/2" von W. Richard Stevens Prentice Hall publications </verb></tscreen> Ein guter Tip ist eventuell auch die Newsgruppe <tscreen><htmlurl url="news:comp.protocols.tcp-ip" name="comp.protocols.tcp-ip"></tscreen> Eine ungemein wichtige Quelle für spezielle technische Informationen zu Internet und TCP/IP Netzwerken sind die RFCs. <idx/RFC/ ist ein Akronym für »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 möglich ist. Eine mögliche Anlaufstelle ist die Nexor RFC database: <tscreen><htmlurl url="http://pubweb.nexor.co.uk/public/rfc/index/rfc.html" name="http://pubweb.nexor.co.uk/public/rfc/index/rfc.html"> </tscreen> <sect>Grundkonfiguration Die folgenden Abschnitte sollte man gut durchlesen, denn ihr Verständnis ist sehr wichtig, bevor man mit der tatsächlichen Konfiguration beginnen kann. Es handelt sich um grundlegende Prinzipien, die unabhängig davon sind, welche Art von Netzwerk letztendlich verwendet wird. <sect1>Was brauche ich für den Anfang? Einige Dinge benötigt man, bevor man sich mit der Zusammenstellung und Konfiguration seines Netzwerkes beschäftigen kann. Die wichtigsten davon sind: <sect2>Aktuelle Kernel Quelldateien Der derzeit installierte Kernel hat oft nicht die Treiber für die gewünschte Hardware und Netzwerk-Protokolle eingebunden. Hier ist eine Neukompilation des Kernels mit den entsprechenden Optionen notwendig. Die jeweils aktuelle Kernel-Version befindet sich auf <tscreen><htmlurl url="ftp://ftp.funet.fi/pub/Linux/PEOPLE/Linus/v2.0" name="ftp.funet.fi:/pub/Linux/PEOPLE/Linus/v2.0"> </tscreen> Normalerweise wird das Archiv mit den Quelltexten in das Verzeichnis <tt>/usr/src/linux</tt> entpackt. Weiterführende Informationen dazu, wie man Patches einspielt und den Kernel übersetzt, findet man im <htmlurl name="Kernel HOWTO" url="DE-Kernel-HOWTO.html">. Die Konfiguration der verschiedenen Module beschreibt das <htmlurl name="Module HOWTO" url="http://metalab.unc.edu/LDP/HOWTO/Module-HOWTO.html">. 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, können strukturelle Veränderungen oder Test-Code enthalten, die im Zusammenspiel mit anderen Programmen des Systems zu Problemen führen können. Wer sich nicht sicher ist, daß er mit derartigen Schwierigkeiten umgehen kann, sollte bei den Standard-Versionen bleiben. <sect2>Aktuelle Hilfsprogramme <nidx>NetTools</nidx> <nidx>Netzwerk!NetTools</nidx> Diese Programme (englisch: network tools) dienen dazu, die Netzwerk Devices, Kernel-Schnittstellen zur Hardware, zu konfigurieren. Damit können 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 nötigen Programme kompilieren. Dies ist aber nicht weiter schwierig. Die Programme werden von Bernd Eckenfels betreut und können via FTP bezogen werden: <itemize> <item><tt><htmlurl url="ftp://ftp.inka.de/pub/comp/Linux/networking/NetTools/" name="ftp.inka.de:/pub/comp/Linux/networking/NetTools/"> </tt> <item><tt><htmlurl url="ftp://ftp.linux.uk.org/pub/linux/Networking/PROGRAMS/NetTools/" name="ftp.linux.uk.org:/pub/linux/Networking/PROGRAMS/NetTools/"> </tt> </itemize> Auf jeden Fall muß man sich vergewissern, daß die Version sich auch mit dem eingesetzten Kernel verträgt. Um die gegenwärtig, also als dieser Text geschrieben wurde, aktuelle Version zu installieren, geht man wie folgt vor: <tscreen><verb> # cd /usr/src # tar xvfz net-tools-1.32-alpha.tar.gz # cd net-tools-1.32-alpha # make config # make # make install </verb></tscreen> <nidx>ipfwadm!Bezugsquelle</nidx> Wer außerdem auch beabsichtigt, ein Firewall aufzusetzen oder IP Masquerading zu verwenden, wird darüberhinaus das Programm <tt>ipfwadm</tt> benötigen. Die aktuellste Version bekommt man über: <tscreen><htmlurl url="ftp:/ftp.xos.nl/pub/linux/ipfwadm" name="ftp.xos.nl:/pub/linux/ipfwadm"></tscreen> Auch dort gibt es unterschiedliche Versionen, man muß deshalb darauf achten, die für den eigenen Kernel passende auszuwählen. Die Installation ist dann ganz einfach. Folgendes Beispiel zeigt dieses an Hand der aktuellen Version: <tscreen><verb> # cd /usr/src # tar xvfz ipfwadm-2.3.0.tar.gz # cd ipfwadm-2.3.0 # make # make install </verb></tscreen> <sect2>Anwendungsprogramme <nidx>NetKit</nidx> <nidx>Netzwerk!NetKit</nidx> Mit <em/Anwendungen/ sind hier Programme wie <tt>telnet</tt> oder <tt>ftp</tt> sowie die zugehörigen Server gemeint. David Holland (<tt><htmlurl url="mailto:dholland@hcs.harvard.edu" name="dholland@hcs.harvard.edu"></tt>) verwaltet inzwischen eine Distribution mit den am weitesten verbreiteten Programmen. Man erhält sie hier: <tscreen><htmlurl url="ftp://ftp.uk.linux.org/pub/linux/Networking/base" name="ftp.uk.linux.org:/pub/linux/Networking/base"></tscreen> Zur Installation der derzeit aktuellen Version geht man folgendermaßen vor: <tscreen><verb> # cd /usr/src # tar xvfz /pub/net/NetKit-B-0.08.tar.gz # cd NetKit-B-0.08 # more README # vi MCONFIG # make # make install </verb></tscreen> <sect2>Adressen <nidx>IP!Adresse</nidx> <nidx>IP!Netmask</nidx> <nidx>IP!Broadcast Adresse</nidx> <nidx>Netmask</nidx> <nidx>Broadcast Adresse</nidx> <nidx>Netzwerk!Netmask</nidx> <nidx>Netzwerk!IP Adressen</nidx> <nidx>Netzwerk!Broadcast Adresse</nidx> Die reinen Internet Protokoll Adressen bestehen aus 4 Bytes. Standardmäßig schreibt man diese in einer durch Punkte getrennten Dezimalschreibweise: Jedes Byte wird in eine Dezimalzahl umgewandelt (0-255), wobei führende Nullen weggelassen werden, außer wenn die Zahl Null ist. Diese vier Zahlen werden dann, durch einen Dezimalpunkt ».« getrennt, hintereinander aufgeschrieben. Für gewöhnlich 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 <em/Netmask/. Ihre Aufgabe ist es, festzustellen, ob ein Rechner zu diesem Netzwerk gehört, oder nicht. Hier ein Beispiel: <tscreen><verb> ----------------- --------------- Host Address 192.168.110.23 Network Mask 255.255.255.0 Network Portion 192.168.110. Host portion .23 ----------------- --------------- Network Address 192.168.110.0 Broadcast Address 192.168.110.255 ----------------- --------------- </verb></tscreen> Jede Adresse, die bitweise mit der Netmask durch ein logisches UND verknüpft wird, ergibt so die Adresse des Netzwerkes, zu der sie gehört. 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 zusätzlich 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 dafür, wie eine solche Broadcast Adresse aussieht. Am weitesten verbreitet ist es, die höchste Nummer des Adressbereiches zu verwenden, im obigen Beispiel also die <tt>192.168.110.255</tt>. An einigen Stellen wird auch die Netzwerk-Adresse für 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 frühen Phase der Entwicklung des IP Protokolles wurden einige willkürlich gewählte Bereiche des Adressraumes zu Netzwerken zusammengefaßt, die man als Klassen bezeichnet. Diese Klassen stellen die Standard-Größen für ein Netzwerk dar, die Aufteilung ist wie folgt: <tscreen><verb> ------------------------------------------------------------ | 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 | ------------------------------------------------------------ </verb></tscreen> Welcher dieser Adressen man verwenden sollte, hängt vom jeweiligen Fall ab; eventuell muß man eine Kombination der unten aufgeführten Aktionen durchführen. <descrip> <tag>Anbinden eines einzelnen Linux-Rechners in ein bestehendes Netz </tag> In diesem Fall muß man sich an den Administrator des Netzes wenden und ihn um folgende Informationen bitten: <itemize> <item>IP Adresse für den Rechner <item>IP Netzwerk Adresse <item>IP Broadcast Adresse <item>IP Netmask <item>Adresse des Routers <item>Adresse des Domain Name Servers </itemize> Mit diesen Angaben kann man dann sein Netzwerk unter Linux konfigurieren. <tag>Neubildung eines Netzwerkes, daß keine Verbindung zum Internet hat </tag> <nidx>IP!private Adressen</nidx> <nidx>Netzwerk!private IP Adressen</nidx> Wer sich ein kleines privates Netzwerk zulegen will und nicht beabsichtigt, dieses jemals mit dem Internet zu verbinden, kann im Prinzip seine Adressen völlig frei auswählen. Aus Sicherheitsgründen, und um trotzdem eine gewisse Konsistenz in der Adressenvergabe zu wahren, wurden jedoch einige Bereiche des Adressraumes speziell für diesen Zweck reserviert. Sie sind im <em/RFC 1597/ festgelegt: <tscreen><verb> ------------------------------------------------------------ | 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 | ------------------------------------------------------------ </verb></tscreen> Zuerst sollte man sich überlegen, wie groß das eigene Netz sein soll und dann einen geeigneten Bereich auswählen. </descrip> <sect1>Wo muß ich die Konfiguration durchführen? Unter Linux gibt es unterschiedliche Ansätze, wie die Boot-Prozedur abläuft. In jedem Fall wird aber, nachdem der Kernel geladen ist, ein Programm mit dem Namen <tt/init/ gestartet. <tt/init/ liest dann die Konfigurationsdatei <tt>/etc/inittab</tt> und beginnt den eigentlichen Boot-Prozeß. Es gibt verschiedene Versionen des <tt/init/-Programmes, und das ist auch bereits der Hauptgrund für die unterschiedlichen Bootkonzepte der verschiedenen Distributionen. Für gewöhnlich enthält <tt>/etc/inittab</tt> einen Eintrag der Form <tscreen><verb> si::sysinit:/etc/init.d/boot </verb></tscreen> 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 <tt/AUTOEXEC.BAT/ in DOS. Meist werden von diesem Script aus weitere Scripte aufgerufen, und oft ist eines davon dann für die Konfiguration des Netzwerkes zuständig. Die folgende Tabelle gibt einen Anhaltspunkt, welche Dateien das für die diversen Distributionen sind: <tscreen><verb> ------------------------------------------------------------------------------- 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 ------------------------------------------------------------------------------- </verb></tscreen> Die meisten modernen Distributionen stellen ein Programm zur Verfügung, mit dem man die gängigsten Netzwerk Schnittstellen konfigurieren kann. Es lohnt sich auf jeden Fall, diese Programme auszuprobieren, bevor man sich an eine manuelle Installation macht. <tscreen><verb> -------------------------------------------- Distrib | Netzwerk Konfigurations Programm -------------------------------------------- RedHat | /sbin/netcfg Slackware | /sbin/netconfig -------------------------------------------- </verb></tscreen> <sect1>Anlegen der Netzwerk Schnittstellen <nidx>Netzwerk!Device</nidx> In vielen Varianten von Unix haben die verschiedenen Netzwerk Devices feste Einträge im Verzeichnis <tt>/dev</tt>. Nicht so bei Linux. Hier werden diese Einträge dynamisch von der Software angelegt, die entsprechenden Dateien in <tt>/dev</tt> müssen also nicht vorhanden sein. In fast allen Fällen werden die Device-Einträge für 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 <tt/eth[0..n]/ an, durchnumeriert in der Reihenfolge, in der die Hardware gefunden wird. Der ersten Karte wird der Eintrag <tt/eth0/ zugeordnet, der zweiten <tt/eth1/ usw. Manche Device-Einträge, insbesondere für <em/SLIP/ und <em/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 <em/SLIP/ oder <em/PPP/ Geräte bei laufendem Betrieb ändern kann - im Gegensatz zu Ethernetkarten. Diese Fälle werden später genauer behandelt. <sect1>Konfiguration der Netzwerk Schnittstelle <nidx>ifconfig</nidx> <nidx>Netzwerk!ifconfig</nidx> Hat man sich alle benötigten Programme und Informationen besorgt, kann mit der Konfiguration der Netzwerk Schnittstelle begonnen werden. Mit Konfiguration ist dabei gemeint, der Schnittstelle die Adresse zuzuteilen sowie für andere einstellbare Parameter die richtigen Werte einzusetzen. Das hierfür am meisten verwendete Programm ist <tt/ifconfig/, was für Interface Configure, also Schnittstellenkonfiguration, steht. Ein typisches Beispiel für den Einsatz von <tt/ifconfig/ ist etwa <tscreen><verb> # ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up </verb></tscreen> In diesem Fall wird die Schnittstelle <tt/eth0/ mit der Adresse <tt/192.168.0.1/ sowie der Netmask <tt/255.255.255.0/ konfiguriert. Das abschließende <tt/up/ aktiviert die Schnittstelle. Der Kernel hat einige voreingestellte Standardwerte für viele der Konfigurationsparameter. So kann man natürlich Netzwerkadresse und Broadcastadresse für eine Schnittstelle festlegen. Tut man dies nicht, wie im obigen Beispiel, dann versucht der Kernel für diese Parameter vernünftige Werte anzunehmen. Dies macht er anhand der Netzwerk-Klasse der angegebenen IP-Adresse. In diesem Fall wäre das ein Klasse-C Netz, dementsprechend benutzt der Kernel <tt/192.168.0.0/ als Netzwerk-Adresse und <tt/192.168.0.255/ als Broadcast-Adresse. <tt/ifconfig/ besitzt unzählige Parameter. Die wichtigsten davon sind <descrip> <tag/up/Aktiviert die Schnittstelle. <tag/down/Deaktiviert die Schnittstelle. <tag>[-]arp</tag>(De-)aktiviert das Protokoll zur Auflösung von Adressen (address resolution protocol) für diese Schnittstelle. <tag>[-]allmulti</tag>(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 für Programme wie <tt/tcpdump/. <tag/mtu N/Legt die <em/MTU/ fest. <tag/netmask addr/Legt die Netmask für die Schnittstelle fest. <tag/irq addr/Legt den verwendeten Interrupt der Hardware fest. Dies funktioniert aber nur für einige wenige Geräte. <tag>[-]broadcast [addr]</tag>Damit kann die Adresse für Broadcast-Meldungen festgelegt werden oder die Annahme solcher Pakete abgeschaltet werden. <tag>[-]pointopoint [addr]</tag>Hiermit wird die Adresse des Rechners am anderen Ende der Verbindung festgelegt. Dieses findet z.B. im Falle von <em/SLIP/ und <em/PPP/ Verbindungen Verwendung. <tag>hw <type> <addr></tag>Damit lassen sich für bestimmte Netzwerk-Typen die Hardware Adressen festlegen. Das ist für Ethernet kaum nützlich, für andere Typen wie AX.25 aber schon. </descrip> <tt/ifconfig/ kann im Prinzip zur Konfiguration jeder beliebigen Netzwerk Schnittstelle verwendet werden. Einige Programme wie <tt/pppd/ oder <tt/dip/ machen dies jedoch selbständig, sodaß sich ein manueller Aufruf von <tt/ifconfig/ in diesem Fall erübrigt. <sect1>Konfiguration des Name Resolver <label id="DE-NET3-HOWTO-Konfiguration-Name-Resolver"> <nidx>Name Resolver!Grundlagen</nidx> <nidx>Netzwerk!Name Resolver</nidx> <nidx>DNS!Grundlagen</nidx> <nidx>Netzwerk!DNS</nidx> Der <em/Name Resolver/ ist ein Teil der Standardbibliothek von Linux. Seine Aufgabe ist es, benutzerfreundliche Rechnernamen wie <tt/ftp.funet.fi/ in rechnerfreundliche IP-Adressen wie <tt/128.214.248.6/ zu übersetzen. <sect2>Aus was besteht ein Name? <nidx>Domain</nidx> <nidx>Netzwerk!Domain</nidx> <nidx>Subdomain</nidx> <nidx>Netzwerk!Subdomain</nidx> 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 Verästelungen. Eine <em/Domain/ ist eine Gruppe von Namen. Eine solche <em/Domain/ kann wiederum unterteilt sein in mehrere <em/Subdomains/. Eine <em/Toplevel Domain/ ist eine <em/Domain/, die nicht mehr <em/Subdomain/ einer anderen ist. Diese <em/Toplevel Domains/ sind im <em/RFC 920/ festgelegt. Beispiele für die bekanntesten <em/Toplevel Domains/ sind: <descrip> <tag/COM/Kommerzielle Organisationen <tag/EDU/Bildung und Lehre <tag/GOV/Regierungsstellen <tag/MIL/Militärische Organisationen <tag/ORG/Andere Organisationen <tag/Länderkennzeichen/Diese sind gebildet aus zwei Buchstaben, die für ein Land stehen. </descrip> Jede dieser höchsten Domänen hat nun Unterdomänen. So gibt es für viele Länder wieder eine Unterteilung entsprechend der höchsten Domänen, also etwa <tt/com.au/ und <tt/gov.au/ für kommerzielle und staatliche Organisationen in Australien. Aus historischen Gründen liegen praktisch alle nicht länderspezifischen Toplevel Domänen in den USA, obwohl auch diese einen spezifischen Länder-Code (<tt/.us/) besitzen. Die nächste Ebene der Unterteilung stellt meist der Name der Organisation dar. Weitere Unterdomänen 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. <nidx>Fully Qualified Domain Name</nidx> Der erste, am weitesten links stehende Teil des Namens ist immer der eindeutige Name des jeweiligen Rechners, man bezeichnet ihn als <em/hostname/, der übrige Teil rechts davon wird <em/domainname/ genannt. Beide zusammen bilden den <em/Fully Qualified Domain Name/. Am Beispiel meines eigenen Email Rechners ist der vollständige Domainname <tt/perf.no.itg.telstra.com.au/. Das heißt, der Rechnername (<em/hostname/) ist <tt/perf/, der <em/domainname/ <tt/no.itg.telstra.com.au/. Die oberste Domain (<em/toplevel domain/) ist Australien (<tt/.au/) und es handelt sich um eine kommerzielle Organisation (<tt/.com/). Der Name der Firma ist <tt/telstra/, und die Namensgebung der internen Unterdomänen basiert auf der Firmenstruktur, in diesem Fall befindet sich der Rechner in der Information Technology Group, Sektion Network Operation. <sect2>Welche Informationen brauche ich? Natürlich muß man wissen, zu welcher Domäne der Rechner gehören soll. Weiterhin benötigt die Software, die das Übersetzen von Namen in gültige IP-Adressen übernimmt, die Adresse eines <em/Domain Name Servers/, dessen IP-Nummer man sich ebenfalls besorgen muß. Es gibt insgesamt drei Dateien, die editiert werden müssen, auf jede von ihnen wird im folgenden eingegangen. <sect2>/etc/resolv.conf <nidx>Name Resolver!/etc/resolv.conf</nidx> <nidx>/etc/resolv.conf</nidx> <nidx>DNS!/etc/resolv.conf</nidx> <tt>/etc/resolv.conf</tt> ist die zentrale Konfigurationsdatei für den Name Resolver. Das Format ist sehr einfach, es ist eine Textdatei mit einem Schlüsselwort pro Zeile. Normalerweise werden drei davon benutzt, dies sind: <descrip> <tag/domain/Dieser Eintrag bestimmt den Namen der lokalen Domain. <tag/search/Mit diesem Eintrag kann man die Namen von zusätzlichen Domänen angeben, in denen nach einem Hostnamen gesucht wird. <tag/nameserver/Mit diesem Eintrag - es können mehrere davon angegeben werden - gibt man die IP Adresse eines Domain Name Servers an. </descrip> Eine typische Datei <tt>/etc/resolv.conf</tt> sieht etwa so aus: <tscreen><verb> domain maths.wu.edu.au search maths.wu.edu.au wu.edu.au nameserver 192.168.10.1 nameserver 192.168.12.1 </verb></tscreen> In diesem Beispiel ist der Standard Domain Name, der an nicht vollständige angegebene Rechnernamen angehängt wird, <tt/maths.wu.edu.au/. Wird der Rechner in dieser Domain nicht gefunden, wird auch in der Domäne <tt/wu.edu.au/ gesucht. Weiterhin sind zwei unabhängige Nameserver Einträge vorhanden. Beide können von der Name Resolver Software benutzt werden, um Namen aufzulösen. <sect2>/etc/host.conf <nidx>Name Resolver!/etc/host.conf</nidx> <nidx>/etc/host.conf</nidx> <nidx>DNS!/etc/host.conf</nidx> In der Datei <tt>/etc/host.conf</tt> können einige Verhaltensweisen der Name Resolving Software festgelegt werden. Das Format dieser Datei ist ausführlich in der Online Hilfe zu <tt/resolv(8)/ beschrieben. Jedoch wird in praktisch allen Fällen das folgende Beispiel ausreichend sein: <tscreen><verb> order hosts,bind multi on </verb></tscreen> Mit diesen Einträgen wird festgelegt, daß die Software zunächst in der Datei <tt>/etc/hosts</tt> nach einer Namen - Adressen Zuordnung sucht, bevor der Nameserver gefragt wird. Außerdem sollen alle gültigen Adresseinträge, die in <tt>/etc/hosts</tt> gefunden werden, als Antwort geliefert werden, und nicht nur der erste. <sect2>/etc/hosts <nidx>Name Resolver!/etc/hosts</nidx> <nidx>/etc/hosts</nidx> <nidx>DNS!/etc/hosts</nidx> In der Datei <tt>/etc/hosts</tt> können 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 Einträge für das Loopback Interface sowie den lokalen Rechnernamen vorfinden: <tscreen><verb> # /etc/hosts 127.0.0.1 localhost loopback 192.168.0.1 name.dieses.rechners </verb></tscreen> Wie man am ersten Eintrag sieht, sind auch mehrere Namen je Adresseintrag erlaubt. <sect1>Die Konfiguration des Loopback Interface <nidx>Loopback Device</nidx> <nidx>Netzwerk!Loopback Device</nidx> Das <tt/loopback/ Interface ist eine spezielle Schnittstelle, über die man eine Verbindung zum eigenen Rechner aufbauen kann. Es gibt einige Gründe, warum dies sinnvoll sein kann, zum Beispiel wenn man Netzwerk Software testen will, ohne dabei von anderen Teilnehmern des Netzes gestört zu werden. Die Standard IP Adresse für dieses Loopback Interface ist <tt/127.0.0.1/. Unabhängig, auf welchem Rechner man arbeitet, ein <tscreen/telnet 127.0.0.1/ baut immer eine Verbindung zum lokalen Rechner auf. Die Konfiguration dieser Schnittstelle ist äußerst einfach und sollte auf jeden Fall vorgenommen werden: <tscreen><verb> # ifconfig lo 127.0.0.1 # route add -host 127.0.0.1 lo </verb></tscreen> Der <tt/route/-Befehl wird im nächsten Kapitel ausführlich behandelt. <sect1>Routing <nidx>Routing</nidx> <nidx>Netzwerk!Routing</nidx> <nidx>IP!Routing</nidx> <em/Routing/ ist ein wichtiges Thema, es ließen sich leicht Bände damit füllen. Obwohl die meisten nur recht geringe Ansprüche an das Routing haben, trifft das für einige nicht zu. Im folgenden werden nur die grundlegenden Aspekte des Routing behandelt. Wer weitergehende Informationen zu diesem Thema benötigt, der sei auf die Literaturhinweise zu Beginn dieses Dokumentes verwiesen. Zunächst zum Begriff selber: Was ist <em/IP Routing/? Hier ist die Definition, die ich selber verwende: <quote>IP Routing ist der Prozeß über den ein Rechner mit unterschiedlichen Netzwerkanbindungen entscheidet, über welche Verbindung ein empfangenes IP Datagramm weitergeleitet werden soll. </quote> Dies soll an einem Beispiel eines typischen Routers in einem Büro 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. Empfängt 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 benötigt das Routing, denn selbst der einfachste Rechner am Internet besitzt mindestens zwei Netzwerk Schnittstellen, nämlich 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 für das Routing, man nennt sie die <em/Routing Table/. Diese Tabelle enthält Zeilen mit typischerweise mindestens drei Spalten. Die erste Spalte enthält die Zieladresse, die zweite Spalte die Schnittstelle, über die das Datenpaket weitergeleitet werden soll, und die dritte enthält optional die IP Adresse eines anderen Rechners (Gateway), der das Datenpaket zu seinem nächsten Etappenziel leitet. Unter Linux kann man sich diese Tabelle mit dem folgenden Befehl ansehen: <tscreen><verb> # cat /proc/net/route </verb></tscreen> Der eigentliche Vorgang des Routing ist sehr einfach: Ein eingehendes Datenpaket wird entgegengenommen, seine Zieladresse wird untersucht und mit den Einträgen 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 für die Adresse auch ein Gateway eingetragen, wird das Paket an diesen Rechner adressiert, andernfalls wird angenommen, daß der Zielrechner zu dem Netzwerk gehört, mit dem die benutzte Schnittstelle verbunden ist. <nidx>Routing!route</nidx> <nidx>Netzwerk!Routing!route</nidx> <nidx>IP!Routing!route</nidx> Um die Routing Table zu verändern, 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 Einträge in der Routing Table hinzuzufügen, zu entfernen oder zu verändern. Aus naheliegenden Gründen heißt dieser Befehl <tt/route/. Ein einfaches Beispiel: Nehmen wir an, wir befinden uns an einem Ethernet Netzwerk. Es sei ein Klasse C Netz mit der Adresse <tt/192.168.1.0/. Unsere eigene IP Adresse ist <tt/192.168.1.10/, und der Rechner <tt/192.168.1.1/ ist ein Router mit Verbindung zum Internet. Zunächst muß natürlich die Schnittstelle wie bereits beschrieben konfiguriert werden, also etwa <tscreen><verb> # ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up </verb></tscreen> Als nächstes muß in die Routing Table eingetragen werden, daß Datagramme an alle Adressen <tt>192.168.1.*</tt> direkt über das Ethernet Device <tt/eth0/ geleitet werden: <tscreen><verb> # route add -net 192.168.0.0 netmask 255.255.255.0 eth0 </verb></tscreen> Über den Schalter <tt>-net</tt> im obigen Befehl wird dem <tt/route/ Programm mitgeteilt, daß es sich um einen Eintrag für ein ganzes Netzwerk handelt. Die andere Alternative ist ein Eintrag <tt/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 außerhalb dieses Netzes befinden? <nidx>Default Route</nidx> <nidx>Netzwerk!Default Route</nidx> Es wäre sehr umständlich und nicht praktikabel, für jedes denkbare Netzwerk einen entsprechenden Eintrag anzufügen. Aus diesem Grund gibt es eine Standardeinstellung in der festgelegt wird, wie mit Paketen zu verfahren ist, die nicht gesondert in der Routing Table aufgeführt sind: die <em/Default Route/. Im obigen Beispiel heißt 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 folgendermaßen: <tscreen><verb> # route add default gw 192.168.1.1 eth0 </verb></tscreen> Durch den Parameter <tt/gw/ wird dem <tt/route/-Befehl mitgeteilt, daß die folgende Adresse die IP-Adresse eines Gateway Rechners oder eines Routers ist, an den die Pakete weitergeleitet werden. Die komplette Konfiguration sieht also so aus: <tscreen><verb> # 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 </verb></tscreen> Ein Blick in die <tt/rc/-Dateien, die beim Bootprozeß das Netzwerk initialisieren, sollte ähnliche Einträge wenn auch mit anderen Adressen zu Tage bringen, denn es ist eine sehr verbreitete Konfiguration. Wir können uns nun an ein etwas komplizierteres Beispiel wagen. Nehmen wir an, wir wollten einen einfachen Router konfigurieren, z.B. den bereits erwähnten mit mehreren lokalen Netzen und einer PPP Verbindung zum Internet. Für drei lokale Ethernet Segmente würde die Routing Tabelle etwa folgendermaßen aufgebaut: <tscreen><verb> # 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 </verb></tscreen> Für jede der an diesen Router angeschlossenen Workstations hätte die Routing Tabelle dieselbe einfache Form wie im vorangegangenen Beispiel. Lediglich der Router muß alle drei Netzwerke separat aufführen, da er ja die Aufteilung der Datenpakete auf diese Netze durchführen muß. Bleibt also nur noch die Frage, warum in der default route der Eintrag <tt/gw/ fehlt. Der Grund dafür 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 zusätzliche Angabe einer Gateway-Adresse ist in diesem Falle überflüssig. Lediglich für Ethernet-, Arcnet- oder Token Ring Verbindungen ist die Angabe einer Gatewayadresse zwingend vorgeschrieben, da hier über eine Verbindung eine große Zahl an Rechnern erreicht werden kann. <sect2>Was macht das routed Programm? <nidx>Routing!routed</nidx> <nidx>Netzwerk!Routing!routed</nidx> <nidx>IP!Routing!routed</nidx> <nidx>Routing!gated</nidx> <nidx>gated</nidx> <nidx>Netzwerk!Routing!gated</nidx> <nidx>IP!Routing!gated</nidx> Die oben beschriebene Konfiguration ist optimiert auf einfache Netzwerke mit nur wenigen, unveränderlichen Pfaden zu den unterschiedlichen Zielen. In einem komplexen Netzwerk werden die Dinge jedoch etwas schwieriger. Doch zum Glück betrifft das nur die wenigsten. Das größte Problem des manuellen oder statischen Routing, das im vorigen Abschnitt beschrieben wurde, tritt auf, wenn ein Rechner im Netzwerk ausfällt, der als Router arbeitet. In diesem Fall besteht die einzige Möglichkeit, ein Datenpaket dennoch zum Ziel weiterzuleiten darin, von Hand einzugreifen und die entsprechenden Routes manuell zu ändern - vorausgesetzt natürlich, es existiert solch ein alternativer Weg. Das ist umständlich, langsam und fehleranfällig. 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 <em/dynamische Routing Protokolle/. <nidx>Routing!RIP</nidx> <nidx>Routing!OSPF</nidx> <nidx>Netzwerk!Routing!RIP</nidx> <nidx>Netzwerk!Routing!OSPF</nidx> <nidx>IP!Routing!RIP</nidx> <nidx>IP!Routing!OSPF</nidx> Die bekanntesten dynamischen Protokolle sind <idx>RIP</idx> (Routing Information Protocol) und <idx>OSPF</idx> (Open Shortest Path First Protocol). RIP ist besonders in kleinen Netzwerken wie mittelgroßen Betrieben oder Gebäude-Netzwerken sehr verbreitet. OSPF ist moderner und insbesondere darauf ausgelegt, in großen Netzwerken benutzt zu werden, in denen es eine große Zahl an Wegen durch das Netzwerk gibt. Die am weitesten verbreiteten Vertreter dieser Protokolle sind <tt/routed/ (RIP) und <tt/gated/ (OSPF). <tt/routed/ ist normalerweise Bestandteil jeder Linux Distribution, ansonst bekommt man es mit dem Paket NetKit (s.o.). Ein Beispiel für die Verwendung dynamischen Routings ist die folgende Konfiguration: <tscreen><verb> 192.168.1.0 / 192.168.2.0 / 255.255.255.0 255.255.255.0 - - | | | /-----\ /-----\ | | | |ppp0 // ppp0| | | eth0 |---| A |------//---------| B |---| eth0 | | | // | | | | \-----/ \-----/ | | \ ppp1 ppp1 / | - \ / - \ / \ / \ / \ / \ / \ / \ / \ / ppp0\ /ppp1 /-----\ | | | C | | | \-----/ |eth0 | |---------| 192.168.3.0 / 255.255.255.0 </verb></tscreen> Es gibt drei Router: A, B und C. Jeder ist für ein Ethernet Segment mit einem Klasse C IP Netzwerk (Netmask 255.255.255.0) zuständig. Darüberhinaus verfügt jeder Router über jeweils eine PPP-Verbindung zu jedem der anderen beiden Router; diese bilden also ein Dreieck. Ganz offensichtlich könnte die Routing Tabelle für Router A folgendermaßen aussehen: <tscreen><verb> # route add -net 192.168.1.0 netmask 255.255.255.0 eth0 # route add -net 192.168.2.0 netmask 255.255.255.0 ppp0 # route add -net 192.168.3.0 netmask 255.255.255.0 ppp1 </verb></tscreen> Dies funktioniert aber nur, solange die Verbindung zwischen Router A und B besteht. Bricht diese Verbindung zusammen, können 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 können immernoch Verbindungen zu den Rechnern des Segmentes C aufbauen, und diese wiederum können problemlos mit Rechnern im Segment B kommunizieren, da die Verbindung zwischen B und C immernoch besteht. Es wäre also naheliegend daß A die an B gerichteten Pakete an C sendet und diese dann von C an B weitergeleitet werden. Für genau diese Art von Problemen sind die dynamischen Protokolle wie RIP ausgelegt. Würde auf jedem der drei Router A, B und C ein Routing Daemon laufen, würden 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 für Router A: <tscreen><verb> # route add -net 192.168.1.0 netmask 255.255.255.0 eth0 # /usr/sbin/routed </verb></tscreen> Der Routing Daemon <tt/routed/ erkennt beim Start automatisch alle aktiven Netzwerkschnittstellen und sendet und erkennt über diese Schnittstellen Meldungen, um festzustellen, ob Änderungen in der Routing Tabelle nötig sind. Die war nur eine sehr kurze Beschreibung, was dynamisches Routing ist, und in welchen Fällen man es verwendet. Wer genauere Informationen benötigt, sei auf die am Anfang dieses Textes genannten Quellen verwiesen. Wichtige Punkte im Zusammenhang mit dynamischen Routing sind: <enum> <item>Einen Routing Daemon benötigt nur, wer auf seinem Rechner mehrere verschiedene mögliche Routes zu einer Zieladresse besitzt. <item>Der Routing Daemon ändert automatisch die Routing Table, um sie an Änderungen im Netzwerk anzupassen. <item>RIP ist für kleine und mittelgroße Netzwerke ausgelegt. </enum> <sect1>Die Konfiguration von Netzwerk Servern und Diensten <nidx>Netzwerk!Daemon</nidx> <nidx>Netzwerk!Port</nidx> <nidx>Port</nidx> <nidx>inetd</nidx> <nidx>Netzwerk!inetd</nidx> Netzwerk Server und Dienste bezeichnet diejenigen Programme, die es einem Nutzer von außerhalb (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 <em/Port/. Er nimmt ankommende Verbindungswünsche entgegen und führt dann die jeweiligen Aktionen aus. Es gibt zwei unterschiedliche Methoden, wie ein solcher Netzwerk-Daemon arbeitet: <descrip> <tag>Standalone</tag>Der Daemon überwacht selber den Port. Im Falle einer ankommenden Verbindung übernimmt der Daemon selbst die Arbeit und stellt die gewünschte Dienstleistung zur Verfügung. <tag>inetd Servers</tag>Der <tt/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 später mehr. </descrip> Es gibt zwei wichtige Konfigurationsdateien, die an die eigenen Bedürfnisse angepaßt werden müssen. Dies sind <tt>/etc/services</tt>, in der den unterschiedlichen Portnummern Namen zugeordnet werden, und <tt>/etc/inetd.conf</tt>, die Konfigurationsdatei des <tt/inetd/ Netzwerk Daemons. <sect2>/etc/services <nidx>inetd!/etc/services</nidx> <nidx>Netzwerk!inetd!/etc/services</nidx> <nidx>/etc/services</nidx> Die Datei <tt>/etc/services</tt> ist eine einfache Datenbasis, die jedem Port einen für Menschen leichter verständlichen 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: <tscreen><verb> Name Port/Protokoll Aliases # Kommentar </verb></tscreen> <descrip> <tag>Name</tag>Ein einzelnes Wort, welches den jeweiligen Service beschreibt. <tag>Port/Protokoll</tag>Dieses Feld besteht aus zwei Einträgen. <descrip> <tag>Port</tag>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. <tag>Protokoll</tag>Je nach verwendetem Protokoll steht hier <tt>tcp</tt> oder <tt>udp</tt>. </descrip> Es ist wichtig darauf hinzuweisen, daß ein Eintrag <tt>18/tcp</tt> etwas ganz anderes ist als ein Eintrag <tt>18/udp</tt>. Es gibt keinen technischen Grund, warum ein Service über beide Protokolle zur Verfügung stehen sollte. Nur in seltenen Ausnahmefällen ist dies der Fall, dann wird man beide Einträge, also für <tt/udp/ und <tt/tcp/ finden. <tag>Aliases</tag>Zusätzliche Namen, unter denen dieser Service angesprochen werden kann. </descrip> Jeglicher Text nach dem Hash-Zeichen (<tt/#/) wird ignoriert. <sect3>Ein Beispiel für /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. <tscreen><verb> # /etc/services: # $Id: DE-NET3-HOWTO.sgml,v 1.4 1999/11/10 13:43:50 mbudde Exp $ # # Netzwerk Dienstes, Internet Ausführung # # Man beachte, daß es zur Zeit die Politik von IANA ist, eine einzelne, # gut bekannte Port Nummer sowohl für TCP als auch UDP zuzuweisen. Daher # gibt es oft auch einen UDP Eintrag, obwohl das entsprechende Protokoll # UDP garnicht unterstützt. # 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 können auf den meisten Systemen von Prozessen gewöhnlicher #> Benutzer verwendet werden. # #> Ports werden in TCP [45,106] verwendet, um die Endpunkte von #> logischen Verbindungen, die für länger dauernden Austausch #> von Daten verwendet werden, zu kennzeichnen. Um Dienste für #> unbekannte Nutzer anzubieten, wird ein Port definiert, um #> Kontakt zu diesem Service aufzunehmen. Diese Liste definiert die #> Ports, die von den Server Prozessen für die Kontaktaufnahme #> verwendet werden. Während 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 für Kerberos v4 und nicht offiziell sind. # Auf Rechner, die v4 verwenden, sollte vor diesen das Hash Zeichen # entfernt werden und die obigen v5 Einträge 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 (für 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 </verb></tscreen> <sect2>/etc/inetd.conf <nidx>inetd!/etc/inetd.conf</nidx> <nidx>Netzwerk!inetd!/etc/inetd.conf</nidx> <nidx>/etc/inetd.conf</nidx> Die Datei <tt>/etc/inetd.conf</tt> ist die Konfigurationsdatei des Server Daemons <tt/inetd/. Bei einer eingehenden Anfrage nach einem bestimmten Service sieht der Daemon in dieser Datei nach, was zu tun ist. Für 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 <tt/#/ dient als Kommentarzeichen, nachfolgender Text wird ignoriert. Jede Zeile enthält sieben Felder, die jeweils durch eine beliebige Anzahl von Leerzeichen oder Tabulatoren voneinander getrennt sind. Die Bezeichnungen der einzelnen Felder sind folgende: <tscreen><verb> service socket_type proto flags user server_path server_args </verb></tscreen> <descrip> <tag>service</tag>Name des Dienstes, entsprechend dem Eintrag in <tt>/etc/services</tt>. <tag>socket_type</tag>Dieser Eintrag beschreibt den Typ des Socket, der für den Dienst gilt. Erlaubte Einträge sind <tt/stream/, <tt/dgram/, <tt/raw/, <tt/rdm/ und <tt/seqpacket/. Die Gründe für die Unterteilung sind technischer Natur, aber als Faustregel kann man davon ausgehen, daß praktisch alle TCP basierten Dienste <tt/stream/ verwenden, während UDP basierte Dienste <tt/dgram/ benutzen. Nur in ganz seltenen Fällen wird ein Dienst einen anderen Typ verwenden. <tag>proto</tag>Das für diesen Service gültige Protokoll. Es muß mit dem Eintrag in <tt>/etc/services</tt> übereinstimmen, normalerweise also entweder <tt/tcp/ oder <tt/udp/. Für Server, die Sun RPC (Remote Procedure Call) verwenden, lauten die Einträge <tt>rpc/tcp</tt> oder <tt>rpc/udp</tt>. <tag>flags</tag>Hier gibt es nur zwei mögliche Einträge. Dem <tt/inetd/ Server wird damit angezeigt, ob das gestartete Serverprogramm den Socket nach dem Start wieder freigibt oder nicht. Danach entscheidet sich, ob für eine weitere eingehende Anfrage ein neuer Prozeß gestartet werden muß, oder ob der laufende Prozeß auch die neuen Anfragen bearbeitet. Die Regeln hierfür sind etwas schwierig, aber auch hier gilt als Faustregel: TCP-Dienste benötigen den Eintrag <tt/nowait/, UDP-Dienste verwenden <tt/wait/. Es gibt hier aber etliche Ausnahmen, im Zweifelsfall sollte man sich am Beispiel orientieren. <tag>user</tag>Dieser Eintrag legt den Nutzernamen entsprechend <tt>/etc/passwd</tt> fest, mit dessen Rechten der Server gestartet wird. Dies wird oft aus Sicherheitsgründen gemacht. Verwendet man hier der Benutzer <tt/nobody/, so werden die möglichen Folgeschäden eingegrenzt, sollte doch jemand die Sicherheitsmechanismen des Systems umgehen. Allerdings benötigen viele Server die Rechte des Systemadministrators, weshalb hier meist <tt/root/ steht. <tag>server_path</tag>Dies ist der Name inklusive vollem Pfad des zu startenden Servers. <tag>server_args</tag>Dieser Eintrag umfaßt die gesamte restliche Zeile und ist optional. Hier können zusätzliche Argumente für das Serverprogramm übergeben werden. </descrip> <sect3>Ein Beispiel für /etc/inetd.conf Wie auch im Falle von <tt>/etc/services</tt> gehört ein funktionierendes <tt>/etc/inetd.conf</tt> zum Standardumfang jeder Distribution. Der Vollständigkeit halber hier die Version der Debian Distribution. <tscreen><verb> # /etc/inetd.conf: weitere Informationen finden sich in inetd(8) # # Datenbank der Internet Server Konfiguration # # # Modifiziert für 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 für den GNU finger Server, der für Debian verfügbar 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 für das Booten von anderen Rechner # angeboten. Auf den meisten Rechnern läuft dieses nur, falls sie als # Bootserver für 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 verändert 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 # verändert 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 </verb></tscreen> <sect1>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 verändern müssen, es lohnt sich aber dennoch, sie kurz zu beschreiben, damit klar wird, was darinsteht, und wozu sie gut sind. <sect2>/etc/protocols <nidx>/etc/protocols</nidx> <nidx>Netzwerk!/etc/protocols</nidx> <tt>/etc/protocols</tt> 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 können. Außerdem verwenden Programmen wie <tt/tcpdump/ diese Datei, um anstelle von Nummern Namen ausgeben zu können. Die Standardsyntax dieser Datei ist <tscreen><verb> Protokollname Nummer Alias </verb></tscreen> Die Datei <tt>/etc/protocols</tt> der Debian Distribution sieht so aus: <tscreen><verb> # /etc/protocols: # $Id: DE-NET3-HOWTO.sgml,v 1.4 1999/11/10 13:43:50 mbudde Exp $ # # Internet (IP) Protokolle # # Für 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 </verb></tscreen> <sect2>/etc/networks <nidx>/etc/networks</nidx> <nidx>Netzwerk!/etc/networks</nidx> Die Datei <tt>/etc/networks</tt> hat eine ähnliche Funktion wie <tt>/etc/hosts</tt>. Es stellt eine einfache Datenbasis für die Zuordnung von Netzwerknamen und -adressen dar. Der einzige Unterschied zu letzterem besteht darin, daß nur zwei Einträge je Zeile erlaubt sind, und zwar folgendermaßen: <tscreen><verb> Netzwerkname Netzwerkadresse </verb></tscreen> Auch hier ein kleines Beispiel: <tscreen><verb> loopnet 127.0.0.0 localnet 192.168.0.0 amprnet 44.0.0.0 </verb></tscreen> <nidx>Routing!/etc/networks</nidx> Bei Programmen wie <tt/route/ wird ein Netzwerk, das einen Eintrag in <tt>/etc/networks</tt> hat, mit seinem Namen anstelle der reinen Netzwerkadresse angezeigt. <sect1>Netzwerksicherheit und Zugangskontrolle <nidx>Netzwerk!Sicherheit</nidx> Zu Beginn dieses Abschnittes eine kleine Warnung: Einen Rechner oder gar ein Netzwerk gegen unerlaubtes Eindringen abzusichern, ist ein äußerst schwieriges Unterfangen. Ich selber betrachte mich nicht als Experten auf diesem Gebiet, und obwohl die im folgenden beschriebenen Mechanismen sicherlich hilfreich sind, möchte 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 benötigen.« Die meisten Distributionen sind heute mit einer Vielzahl von Servern ausgestattet, die beim Bootprozeß automatisch gestartet werden. Um ein Mindestmaß an Systemsicherheit zu gewährleisten, sollten Sie sich die Datei <tt>/etc/inetd.conf</tt> in Ruhe ansehen und alle nicht benötigten Dienste durch Einfügen eines <tt/#/ am Zeilenanfang auszukommentieren. Gute »Kandidaten« hierfür sind <tt/shell/, <tt/login/, <tt/exec/, <tt/uucp/ und <tt/ftp/ sowie informelle Dienste wie <tt/finger/, <tt/netstat/ und <tt/systat/. Es gibt eine große Zahl an Sicherheits- und Zugangskontrollmechanismen, ich werde im folgenden die wichtigsten davon kurz beschreiben. <sect2>/etc/ftpusers <nidx>/etc/ftpusers</nidx> <nidx>FTP!/etc/ftpusers</nidx> <nidx>Netzwerk!FTP!/etc/ftpusers</nidx> Die Datei <tt>/etc/ftpusers</tt> bietet eine einfache Möglichkeit, einzelne Personen vom Zugang über FTP auszuschließen. Die Datei wird vom Daemonen <tt/ftpd/ gelesen, wenn eine FTP-Verbindung aufgebaut wird. Die Datei enthält einfach eine Liste mit den Benutzernamen all derer, denen ein Login verboten werden soll. Hier ein Beispiel: <tscreen><verb> # /etc/ftpusers - Benutzer, die sich nicht per FTP # einloggen dürfen root uucp bin mail </verb></tscreen> <sect2>/etc/securetty <nidx>/etc/securetty</nidx> Mit dieser Datei wird festgelegt, an welchen (virtuellen) Terminals (<tt/tty/s) sich der Systemverwalter <tt/root/ einloggen darf. <tt>/etc/securetty</tt> wird vom Login-Programm, normalerweise <tt>/bin/login</tt>, gelesen und enthält eine Liste der erlaubten Terminals. Auf allen anderen kann <tt/root/ sich <em/nicht/ einloggen: <tscreen><verb> # /etc/securetty - ttys, auf denen sich root einloggen # darf tty1 tty2 tty3 tty4 </verb></tscreen> <sect2>Die tcpd Hostzugangskontrolle <nidx>tcpd</nidx> <nidx>Netzwerk!tcpd</nidx> <nidx>inetd!tcpd</nidx> <nidx>/etc/hosts.allow</nidx> <nidx>/etc/hosts.deny</nidx> <nidx>Netzwerk!/etc/hosts.allow</nidx> <nidx>Netzwerk!/etc/hosts.deny</nidx> Das Programm <tt/tcpd/ ist ihnen vielleicht schon in der Datei <tt>/etc/inetd.conf</tt> aufgefallen. Es stellt Kontroll- und Zugangskontrollmechanismen für diejenigen Dienste zur Verfügung, für die es konfiguriert wird. Wird es von <tt/inetd/ gestartet, so liest es zwei Dateien, anhand derer der Zugang zum überwachten Server gewährt 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 für jeden erlaubt ist. Gelesen werden die Dateien in der Reihenfolge <tt>/etc/hosts.allow</tt>, <tt>/etc/hosts.deny</tt>. Die beiden Dateien werden in den folgenden Abschnitten beschrieben. Für eine detaillierte Beschreibung sei auf die manual pages verwiesen; <tt>host_access(5)</tt> ist hier ein guter Startpunkt. <sect3>/etc/hosts.allow Dies ist eine der Konfigurationsdateien des Programmes <tt>/usr/sbin/tcpd</tt>. In <tt>/etc/hosts.allow</tt> wird eingestellt, welchen anderen Rechnern der Zugang zu Diensten auf dem eigenen Rechner gestattet werden soll. Das Dateiformat ist sehr einfach: <tscreen><verb> # /etc/hosts.allow # # <service list>: <host list> [: command] </verb></tscreen> <descrip> <tag>service list</tag>Eine durch Kommata getrennte Liste von Namen der Dienste, für die der Eintrag gelten soll, z.B. <tt/ftpd/, <tt/telnetd/ oder <tt/fingerd/. <tag>host list</tag>Eine durch Komma getrennte Liste von Rechnernamen; es können hier auch IP-Adressen angegeben werden. Außerdem können Platzhalter verwendet werden. Beispiele hierfür sind <tt/gw.vk2ktj.ampr.org/ (bestimmter Rechner), <tt/.uts.edu.au/ (alle Rechner deren Name mit dieser Zeichenkette endet) oder <tt/44./ (alle IP-Adressen, die mit der angegebenen Ziffernfolge beginnen). Weiterhin existieren einige besondere, die die Konfiguration vereinfachen. Einige davon sind <tt/ALL/ (jeder Rechner), <tt/LOCAL/ (Rechner ohne Dezimalpunkt ».« im Namen, also solche der lokalen Domain) sowie <tt/PARANOID/ (Rechner, deren Namen nicht der Adresse entspricht; dient der Vermeidung von Spoofing). Ein letzter nützlicher Eintrag ist <tt/EXCEPT/. Dadurch können Listen mit Ausnahmen definiert werden, wie in einem späteren Beispiel erläutert wird. <tag>command</tag>Dies ist ein optionaler Parameter. Hier kann ein Programm mit seinem vollständigen Pfad angegeben werden, welches jedesmal ausgeführt wird, wenn die entsprechende Regel erfüllt 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: <tt/%h/ ist der Name des Rechners, der die Verbindung aufbauen will, oder seine IP-Adresse. <tt/%d/ ist der Name des Daemons, der gestartet werden soll. </descrip> Ein Beispiel: <tscreen><verb> # /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) </verb></tscreen> <sect3>/etc/hosts.deny Dies ist eine der Konfigurationsdateien des Programmes <tt>/usr/sbin/tcpd</tt>. In <tt>/etc/hosts.deny</tt> wird eingestellt, welchen Rechnern der Zugang zu Diensten auf dem eigenen Rechner verboten werden soll. Ein einfaches Beispiel sieht etwa so aus: <tscreen><verb> # /etc/hosts.deny # # Kein Zugang für Rechner mit suspektem Namen ALL: PARANOID # # Verbot für ALLE Rechner ALL: ALL </verb></tscreen> Der Eintrag <tt/PARANOID/ ist hier redundant, da der folgende Eintrag in jedem Fall einen Zugang unterbindet. Jeder der beiden Einträge ist eine sinnvolle Einstellung, abhängig von den jeweiligen Bedürfnissen. Die sicherste Konfiguration ist ein Eintrag <tt>ALL: ALL</tt> in <tt>/etc/hosts.deny</tt> zusammen mit einer Datei <tt>/etc/hosts.allow</tt> in der im einzelnen festgelegt wird, für wen der Zugang erlaubt wird. <sect2>/etc/hosts.equiv <nidx>/etc/hosts.equiv</nidx> <nidx>Netzwerk!/etc/hosts.equiv</nidx> Die Datei <tt>/etc/hosts.equiv</tt> erlaubt es, einzelnen Rechnern und Benutzern den Zugang zur eigenen Maschine ohne Paßwortabfrage zu ermöglichen. Dies ist in einer sicheren Umgebung hilfreich, in der man alle anderen Maschinen unter Kontrolle hat. Andernfalls ist es aber ein großes Sicherheitsrisiko. Denn der eigene Rechner ist nur so sicher wie der unsicherste Rechner, dem man vertraut. Wer großen Wert auf höchste Sicherheit legt, sollte diesen Mechanismus nicht verwenden, und auch den Nutzern nahelegen, die Datei <tt/.rhosts/ nicht zu verwenden. <sect2>Konfiguration des FTP-Daemons <nidx>FTP!Sicherheit</nidx> <nidx>Netzwerk!FTP!Sicherheit</nidx> Viele Besitzer von vernetzten Rechnern sind daran interessiert, anderen Personen das Übertragen von Daten von und zum eigenen Rechner zu ermöglichen, ohne ihnen einen expliziten Account einzurichten. Dazu dient der FTP Server. Es muß aber sichergestellt sein, daß der FTP-Daemon korrekt für den anonymen Zugang konfiguriert ist. Die Seite ftpd(8) der Online-Hilfe beschreibt die dazu notwendigen Schritte in einiger Länge. Diesen Tips sollte man unbedingt folgen. Außerdem ein wichtiger Tip: Verwenden sie auf keinen Fall einfach eine Kopie der eigenen Datei <tt>/etc/passwd</tt> im anonymen Heimatverzeichnis <tt>/etc</tt>. Stellen sie sicher, daß alle unwichtigen Einträge entfernt werden, sonst stehen Angriffen durch Paßwortentschlüsselung Tür und Tor offen. <sect2>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 <htmlurl name="Firewall HOWTO" url="DE-Firewall-HOWTO.html">. <sect2>Weitere Tips und Vorschläge Hier noch ein paar weitere Hinweise, auch wenn der eine oder andere davon geeignet ist, Glaubenskriege unter Unix-Administratoren hervorzurufen. <descrip> <tag>sendmail</tag>Obwohl die Verwendung des <tt/sendmail/-Daemons sehr weit verbreitet ist, taucht er mit erschreckender Regelmäßigkeit in Warnungen vor Sicherheitslöchern auf. Es obliegt jedem selber, ob er <tt/sendmail/ verwenden will. <tag>NFS und andere Sun RPC Dienste</tag>Seien Sie vorsichtig damit. Es gibt bei diesen Diensten eine große Zahl potentieller Sicherheitsrisiken. Allerdings ist es schwierig, für etwas wie NFS eine Alternative zu finden. Wenn Sie diese Dienste benutzen, seien Sie vorsichtig, wem Sie einen Zugriff darauf erlauben. </descrip> <sect>Spezifische Informationen zur Netzwerk Technologie <nidx>Kernel!Treiber!Netzwerk</nidx> Die Informationen in den folgenden Abschnitten sind jeweils spezifisch für die jeweilige Technologie. Die darin gemachten Aussagen gelten nicht automatisch auch für andere Netzwerk Technologien. <sect1>ARCNet <nidx>ARCNet</nidx> <nidx>Netzwerk!Treiber!ARCNet</nidx> <nidx>Kernel!Netzwerk!ARCNet</nidx> Die Device Namen für ARCNET sind <tt/arc0s/, <tt/arc1e/, <tt/arc2e/ usw. Der ersten gefundenen Karte wird automatisch der Eintrag <tt/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 <em/RFC 1051/ ausgewählt wurde. <bf/Optionen beim Kernel kompilieren:/ <tscreen><verb> Network device support ---> [*] Network device support <*> ARCnet support [ ] Enable arc0e (ARCnet "Ether-Encap" packet format) [ ] Enable arc0s (ARCnet RFC1051 packet format) </verb></tscreen> Ist die Unterstützung für die Karte erst einmal im Kernel eingebunden, ist die Konfiguration einfach. Typischerweise geschieht das etwa so: <tscreen><verb> # ifconfig arc0e 192.168.0.1 netmask 255.255.255.0 up # route add 192.168.0.0 netmask 255.255.255.0 arc0e </verb></tscreen> Die Datei <tt>/usr/src/linux/Documentation/networking/arcnet-hardware.txt</tt> enthält weitere Informationen zu diesem Thema. Die ARCNet Unterstützung wurde von Avery Pennarun (<tt><htmlurl url="mailto:apenwarr@foxnet.net" name="apenwarr@foxnet.net"></tt>) entwickelt. <sect1>Appletalk (AF_APPLETALK) <nidx>Appletalk</nidx> <nidx>Netzwerk!Treiber!Appletalk</nidx> <nidx>Kernel!Netzwerk!Appletalk</nidx> <nidx>Netatalk!Treiber</nidx> <nidx>Netzwerk!netatalk</nidx> Hierfür gibt es keine speziellen Device-Einträge, da bestehende Netzwerk-Devices genutzt werden. <bf/Optionen beim Kernel kompilieren:/ <tscreen><verb> Networking options ---> <*> Appletalk DDP </verb></tscreen> Durch die Unterstützung von Appletalk kann ein Linux Rechner mit einem Apple Netzwerk zusammenarbeiten. Eine wichtige Anwendung dafür ist die gemeinsame Nutzung von Druckern oder Festplatten über ein Netzwerk. Man benötigt dafür zusätzliche Software: <tt/netatalk/. Wesley Craig (<tt><htmlurl url="mailto:netatalk@umich.edu" name="netatalk@umich.edu"></tt>) steht stellvertretend für ein Team an der University of Michigan, das sich »Research Systems Unix Group« nennt. Sie haben das Paket <tt/netatalk/ mit der notwendigen Software entwickelt, nämlich der Implementation des Appletalk Protocoll Stack sowie weitere nützliche Hilfsprogramme. Das Paket <tt/netatalk/ ist entweder bereits Bestandteil ihrer Linux Distribution oder kann über FTP von der University of Michigan bezogen werden <tscreen><htmlurl url="ftp://terminator.rs.itd.umich.edu/unix/netatalk/" name="terminator.rs.itd.umich.edu:/unix/netatalk/"> </tscreen> Um das Paket zu übersetzen und zu installieren geht man folgendermaßen vor: <tscreen><verb> # cd /usr/src # tar xvfz .../netatalk-1.4b2.tar.Z </verb></tscreen> Nachdem man das Archiv entpackt hat, sollte man die Datei <tt/Makefile/ editieren, um die Software an das eigene System anzupassen. So legt z.B. die Variable <tt/DESTDIR/ fest, wohin die Dateien installiert werden. <tscreen><verb> # make # make install </verb></tscreen> <sect2>Die Konfiguration der Appletalk Software Damit später alles einwandfrei funktioniert, sind zunächst einige zusätzliche Einträge in der Datei <tt>/etc/services</tt> nötig. Diese sind: <tscreen><verb> rtmp 1/ddp # Routing Table Maintenance Protocol nbp 2/ddp # Name Binding Protocol echo 4/ddp # AppleTalk Echo Protocol zip 6/ddp # Zone Information Protocol </verb></tscreen> Als nächstes müssen die Konfigurationsdateien im Verzeichnis <tt>/usr/local/atalk/etc</tt> angelegt werden. Eventuell hat das Verzeichnis auch einen anderen Namen. Das hängt davon ab, wo das Paket installiert wurde. Die erste Datei ist <tt/atalkd.conf/. Man benötigt hier vorläufig nur eine einzige Zeile, in der festgelegt wird, über welches Netzwerk Device die Apple Rechner erreicht werden: <tscreen><verb> eth0 </verb></tscreen> Der Appletalk Daemon wird nach seinem Start weitere Details hinzufügen. <sect2>Exportieren eines Linux Dateisystems via Appletalk Man kann Dateisysteme des Linuxrechners auch an Apple-Rechner exportieren, sodaß diese von beiden Rechnern gemeinsam genutzt werden können. Dafür muß man die Datei <tt>/usr/local/atalk/etc/AppleVolumes.system</tt> entsprechend konfigurieren. Im selben Verzeichnis gibt es außerdem noch die Datei <tt/AppleVolumes.default/. Sie hat dasselbe Format und legt fest, welche Dateisysteme für Nutzer zur Verfügung stehen, die sich als Gastnutzer anmelden. Die genauen Details für diese Konfiguration entnehmen sie bitte der manual page zum <tt/afpd/. Eine einfache Konfiguration könnte etwa so aussehen: <tscreen><verb> /tmp Scratch /home/ftp/pub "Public Area" </verb></tscreen> Dadurch wird das lokale Verzeichnis <tt>/tmp</tt> als AppleShare Volume <tt/Scratch/ und das öffentliche FTP-Verzeichnis als AppleShare Volume <tt/Public Area/ exportiert. Die Namen für die Volumes müssen nicht angegeben werden. Wenn sie fehlen, weist der Daemon automatisch passende Namen zu. <sect2>Gemeinsame Nutzung eines Druckers mit Appletalk <nidx>Drucker!Netzwerk!Appletalk</nidx> Die gemeinsame Nutzung eines Druckers läßt sich einfach verwirklichen. Man muß dazu das Programm <tt/papd/ starten, den Appletalk Printer Access Protocol Daemon. Dieses Programm übernimmt die Druckaufträge von Applerechnern im Netz und leitet sie an den lokale Drucker Spool Daemon weiter. Zur Konfiguration dieses Daemon dient die Datei <tt/papd.conf/. Die Syntax entspricht dabei der der Datei <tt>/etc/printcap</tt>. Der Name, der in der Datei definiert wird, wird dann über das Appletalk Naming Protokoll, NBP, registriert. Hier eine Beispielkonfiguration: <tscreen><verb> TricWriter:\ :pr=lp:op=cg: </verb></tscreen> Dadurch wird im Appletalk Netzwerk ein Drucker namens <tt/TricWriter/ zur Verfügung gestellt. Alle Druckaufträge an diesen Drucker werden durch den Drucker-Daemon <tt/lpd/ über den Linux-Drucker <tt/lp/, der in der Datei <tt>/etc/printcap</tt> definiert sein muß, ausgedruckt. Der Eintrag <tt/op=cg/ legt fest, daß der Druckauftrag unter der ID des Linux-Nutzers <em/cg/ abgewickelt wird. <sect2>Starten der Appletalk Software Nun ist alles soweit konfiguriert; der erste Test kann beginnen. Zum Paket <tt/netatalk/ gehört eine Datei <tt/rc.atalk/, die für Normalanwendungen funktionieren sollte. Alles was zu tun bleibt, ist diese Datei aufzurufen: <tscreen><verb> # /usr/local/atalk/etc/rc.atalk </verb></tscreen> Alles sollte nun einwandfrei laufen. Fehlermeldungen sollten keine auftreten. Der Start der Software wird, ebenso wie weitere Statusmeldungen, über die Konsole ausgegeben. <sect2>Testen der Appletalk Software Um zu überprüfen ob alles einwandfrei funktioniert, begeben Sie sich an einen ihrer Apple Rechner, öffnen sie das Apple Menue, wählen »Chooser« aus und klicken auf AppleShare. Ihr Linux-Rechner sollte sich nun melden. <sect2>Nachteile der Appletalk Software <itemize> <item>Unter Umständen müssen Sie die Appletalk-Unterstützung vor der Konfiguration des IP-Netzwerkes durchführen. Gibt es beim Start des Appletalk Programmes Probleme, oder haben sie nach dessen Start Probleme mit dem IP Netzwerk, versuchen Sie die Appletalk Software <em/vor/ der Ausführung von <tt>/etc/rc.d/rc.inet1</tt> zu starten. <item><tt/afpd/ (der Apple Filing Protocol Daemon) bringt die Festplatte ziemlich durcheinander. Er legt im gemounteten Verzeichnisbaum eine Vielzahl von Verzeichnissen an: <tt>.AppleDesktop</tt> und <tt>Network Trash Folder</tt>. Weiterhin wird darin für jedes angesprochene Verzeichnis ein <tt>.AppleDouble</tt> angelegt, um darin Resource Forks usw. zu speichern. Überlegen Sie es sich <em/genau/, bevor sie ihr Rootverzeichnis <tt>/</tt> exportieren. Die Aufräumarbeiten hinterher haben es in sich. <item>Das Programm <tt/afpd/ erwartet von Macs Paßworte in Klartext, Sicherheitsbedenken sind also berechtigt. Benutzen Sie diesen Daemon auf einer Maschine, die selber am Internet hängt, müssen Sie sich an die eigene Nase fassen, wenn hinterher jemand diese Schwachstellen ausnutzt. <item>Die vorhandenen Diagnosetools wie <tt/netstat/ oder <tt/ifconfig/ unterstützen kein Appletalk. Die Information ist - unformatiert - über <tt>/proc/net</tt> zugänglich. </itemize> <sect2>Weitere Informationsquellen Eine sehr viel detailliertere Beschreibung, wie man Appletalk für Linux konfiguriert, finden Sie auf der Seite <em/Linux Netatalk HOWTO/ von Anders Brownworth unter folgender Adresse: <tscreen><htmlurl url="http://thehamptons.com/anders/netatalk/" name="http://thehamptons.com/anders/netatalk/"></tscreen> <sect1>ATM <nidx>ATM</nidx> <nidx>Netzwerk!Treiber!ATM</nidx> <nidx>Kernel!Treiber!ATM</nidx> Werner Almesberger (<tt><htmlurl url="mailto:werner.almesberger@lrc.di.epfl.ch" name="werner.almesberger@lrc.di.epfl.ch"></tt>) leitet ein Projekt mit dem Ziel, auch unter Linux ATM (Asynchronous Transfer Mode) zu unterstützen. Den aktuellen Stand des Projektes erfährt man über: <tscreen><htmlurl url="http://lrcwww.epfl.ch/linux-atm/" name="http://lrcwww.epfl.ch/linux-atm/"></tscreen> <sect1>AX.25 (AF_AX25) <nidx>AX.25</nidx> <nidx>Netzwerk!Treiber!AX.25</nidx> <nidx>Kernel!Netzwerk!AX.25</nidx> <nidx>Packet Radio!AX.25</nidx> <nidx>HAM!AX.25</nidx> AX.25 Devicenamen sind <tt/sl0/, <tt/sl1/ usw. in <tt/2.0.x/ Kernels bzw. <tt/ax0/, <tt/ax1/ usw. in <tt/2.1.x/ Kernels. <bf/Optionen beim Kernel kompilieren:/ <tscreen><verb> Networking options ---> [*] Amateur Radio AX.25 Level 2 </verb></tscreen> Die Protokolle AX.25, NetRom und Rose werden von Amateurfunkern für Experimente mit Packet Radio genutzt. Eine ausführliche Beschreibung enthält das <htmlurl name="AX25 HOWTO" url="DE-AX25-HOWTO.html"> Der Großteil der Arbeit bei der Implementation dieser Protokolle wurde von Jonathon Naylor (<tt><htmlurl url="mailto:jsn@cs.not.ac.uk" name="jsn@cs.not.ac.uk"></tt>) geleistet. <sect1>DECNet <nidx>DECNet</nidx> <nidx>Netzwerk!Treiber!DECNet</nidx> <nidx>Kernel!Netzwerk!DECNet</nidx> An der Unterstützung von DECNet wird derzeit gearbeitet. Es wird vermutlich in den späten <tt/2.1.x/ Kernels auftauchen. <sect1>EQL - Lastverteilung auf mehrere Leitungen <nidx>EQL</nidx> <nidx>Netzwerk!Treiber!EQL</nidx> <nidx>Kernel!Netzwerk!EQL</nidx> EQL Devices haben den Namen <tt/eql/. Bei den Standard Kernels gibt es nur eines dieser Devices. Es nutzt mehrere Point-to-Point Verbindungen (PPP, SLIP, PLIP) und faßt sie zu einer einzigen logischen Leitung zusammen, um darüber eine TCP/IP Verbindung aufzubauen. Der Hintergrund dabei ist, daß mehrere langsame Leitungen oft billiger als eine schnelle sind. <bf/Optionen beim Kernel kompilieren:/ <tscreen><verb> Network device support ---> [*] Network device support <*> EQL (serial line load balancing) support </verb></tscreen> Um diesen Mechanismus zu nutzen, müssen beide Rechner EQL unterstützen. Dies ist bei Linux, neueren Dial-in Servern und Livingstone Portmastern möglich. Um EQL richtig zu konfigurieren, benötigt man die EQL Tools: <tscreen><htmlurl url="ftp://metalab.unc.edu/pub/linux/system/Serial/eql-1.2.tar.gz" name="metalab.unc.edu:/pub/linux/system/Serial/eql-1.2.tar.gz"> </tscreen> Die Konfiguration ist sehr logisch aufgebaut. Zunächst wird das EQL Interface konfiguriert. Es verhält sich wie jedes andere Netzwerkinterface auch; man konfiguriert IP Adresse und MTU mittels <tt/ifconfig/, also etwa so: <tscreen><verb> # ifconfig eql 192.168.10.1 mtu 1006 # route add default eql </verb></tscreen> Als nächstes müssen die zu nutzenden Verbindungen von Hand aufgebaut werden. Jede denkbare Kombination von Point-to-Point Verbindungen ist möglich. Lesen sie diesbezüglich die entsprechenden Abschnitte dieses Dokumentes. Nun müssen diese seriellen Verbindungen mit dem EQL Device verknüpft werden. Man nennt das »enslaving«, der entsprechende Befehl lautet <tt/eql_enslave/, z.B.: <tscreen><verb> # eql_enslave eql sl0 28800 # eql_enslave eql ppp0 14400 </verb></tscreen> Die angegebene ungefähre Geschwindigkeit hat keinen direkten Hardwarebezug. Der EQL Treiber nimmt diese Werte lediglich als Anhaltspunkt, um die Datagramme möglichst sinnvoll auf die vorhandenen Leitungen zu verteilen. Man kann die Werte also für das Feintuning durchaus frei verändern. Um eine Leitung wieder aus dem EQL Verbund zu entfernen, dient der Befehl <tt/eql_emancipate/. Wieder ein Beispiel: <tscreen><verb> # eql_emancipate eql sl0 </verb></tscreen> Das Routing wird wie für jede andere Point-to-Point Verbindung aufgesetzt. Der einzige Unterschied ist, das anstelle des seriellen Device das EQL-Device angegeben wird: <tscreen><verb> # route add default eql0 </verb></tscreen> Der EQL Treiber wurde von Simon Janes (<tt><htmlurl url="mailto:simon@ncm.com" name="simon@ncm.com"></tt>) entwickelt. <sect1>Ethernet <nidx>Ethernet</nidx> <nidx>Netzwerk!Treiber!Ethernet</nidx> <nidx>Kernel!Netzwerk!Ethernet</nidx> Die Devicenamen für Ethernet sind <tt/eth0/, <tt/eth1/, <tt/eth2/ usw. Der ersten gefundenen Karte wird <tt/eth0/ zugewiesen, die weiteren werden fortlaufend durchnumeriert. Zur Inbetriebnahme einer Ethernetkarte unter Linux existiert ein eigenes HOWTO, das <htmlurl name="Ethernet HOWTO" url="http://metalab.unc.edu/LDP/HOWTO/Ethernet-HOWTO.html">. Ist der Kernel mit Unterstützung für Ethernetkarten kompiliert, ist die Konfiguration der Karte einfach. Typischerweise verwendet man etwa folgende Befehle: <tscreen><verb> # ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up # route add 192.168.0.0 netmask 255.255.255.0 eth0 </verb></tscreen> Die meisten der Treiber für Ethernetkarten wurden von Donald Becker (<tt><htmlurl url="mailto:becker@CESDIS.gsfc.nasa.gov" name="becker@CESDIS.gsfc.nasa.gov"></tt>) entwickelt. <sect1>FDDI <nidx>FDDI</nidx> <nidx>Netzwerk!Treiber!FDDI</nidx> <nidx>Kernel!Netzwerk!FDDI</nidx> Die Devicenamen für FDDI sind <tt/fddi0/, <tt/fddi1/, <tt/fddi2/ usw. Der ersten gefundenen Karte wird <tt/fddi0/ zugewiesen, die weiteren werden fortlaufend durchnumeriert. Lawrence V. Stefani (<tt><htmlurl url="mailto:stefani@lkg.dec.com" name="stefani@lkg.dec.com"></tt>) hat einen Treiber für die EISA und PCI Karten der Digital Equipment Corporation entwickelt. <bf/Optionen beim Kernel kompilieren:/ <tscreen><verb> Network device support ---> [*] FDDI driver support [*] Digital DEFEA and DEFPA adapter support </verb></tscreen> Ist der Kernel mit Unterstützung für FDDI kompiliert, ist die Konfiguration praktisch identisch zu derjenigen eines Ethernet Interface: Es müssen lediglich die entsprechenden FDDI-Devicenamen angegeben werden. <sect1>Frame Relay <nidx>Frame Relay</nidx> <nidx>DLCI</nidx> <nidx>FRAD</nidx> <nidx>Netzwerk!Treiber!Frame Relay</nidx> <nidx>Kernel!Netzwerk!Frame Relay</nidx> Die Devicenamen für Frame Relay sind <tt/dlci00/, <tt/dlci01/ usw. für Devices mit DLCI Encapsulation und <tt/sdla0/, <tt/sdla1/ usw. für solche mit FRAD. Frame Relay ist eine neue Netzwerktechnologie. Sie wurde speziell für Umgebungen entwickelt, in denen die Netzauslastung intermittierend ist, also oft kurzzeitig scharfe Spitzen auftreten. Für den Zugang zu einem Frame Relay Netzwerk benötigt man ein Frame Relay Access Device (FRAD). Die Frame Relay Unterstützung unter Linux hält sich an <em/RFC 1490/. <bf/Optionen beim Kernel kompilieren:/ <tscreen><verb> Network device support ---> <*> Frame relay DLCI support (EXPERIMENTAL) (24) Max open DLCI (8) Max DLCI per device <*> SDLA (Sangoma S502/S508) support </verb></tscreen> Die Frame Relay Treiber und Konfigurationsprogramme wurden von Mike McLagan (<tt><htmlurl url="mailto:mike.mclagan@linux.org" name="mike.mclagan@linux.org"></tt>) entwickelt. Derzeit werden allerdings nur diese Karten unterstützt: Sangoma Technologies (<tt><htmlurl url="http://www.sangoma.com/" name="http://www.sangoma.com"></tt>) <tt/S502A/, <tt/S502E/ und <tt/S508/. Um die FRAD und DLCI Devices zu konfigurieren, benötigen Sie spezielle Programme, die <em/Frame Relay Configuration Tools/. Diese bekommen Sie bei <tscreen><htmlurl url="ftp://ftp.invlogic.com/pub/linux/fr/frad-0.15.tgz" name="ftp.invlogic.com:/pub/linux/fr/frad-0.15.tgz"> </tscreen> Kompilierung und Installation der Tools ist eigentlich kein Problem, allerdings gibt es kein zentrales Makefile. Dadurch ist einige Handarbeit notwendig: <tscreen><verb> # 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 </verb></tscreen> <nidx>/etc/frad/router.conf</nidx> Nach der Installation müssen Sie die Datei <tt>/etc/frad/router.conf</tt> anlegen. Dafür ist folgende Vorlage hilfreich, bei der es sich um eine abgeänderte Version der dem Paket beiliegenden Beispieldatei handelt: <tscreen><verb> # /etc/frad/router.conf # Dies ist eine Beispielkonfiguration für Frame Relay. # Alle möglichen Einträge sind aufgeführt, die Standard- # einstellungen basieren auf dem Code des DOS-Treibers # für die Karte S502A von Sangoma. # # Ein "#" irgendwo in der Zeile leitet einen Kommentar # ein. Leerzeilen werden ignoriert (TAB ist auch erlaubt). # Unbekannte Einträge [] 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 Einträge für # alle Devices. Sie koennen für einzelne Karten in den # entsprechenden Abschnitten verändert 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 für # 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 Einträge sind spezifisch für Sangoma # # Typ der Sangoma Karte - S502A, S502E, S508 Board=S502E # Name der Test-Firmware für 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 für diese Karte Mem=C8 # Adresse für Memory Window, A0-EE IRQ=5 # IRQ Nummer, für 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 Einträge nur für 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 # Einträge spezifisch für dieses # # Device # DLCI Default Konfigurationsparameter # Diese können 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 </verb></tscreen> Ist die Datei <tt>/etc/frad/router.conf</tt> 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 <em/vor/ den DLCI Devices zu konfigurieren. <tscreen><verb> # 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 # </verb></tscreen> <sect1>IP Accounting <nidx>IP!Accounting</nidx> <nidx>Netzwerk!Treiber!IP Accounting</nidx> <nidx>Kernel!Netzwerk!IP Accounting</nidx> <nidx>ipfwadm!IP Accounting</nidx> 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 Zähler. Es können eine Vielzahl von Regeln festgelegt werden, um die verschiedenen Zähler den eigenen Bedürfnissen anzupassen. <bf/Optionen beim Kernel kompilieren:/ <tscreen><verb> Networking options ---> [*] IP: accounting </verb></tscreen> Nach Kompilierung und Installation des Kernels benötigen sie das Programm <tt/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; für weitergehende Informationen sollten Sie die manual page zu <tt/ipfwadm/ lesen. Das Szenario für 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 Verfügung stellt. Sie sind daran interessiert zu erfahren, welchen Anteil der Auslastung durch die Dienste <tt/telnet/, <tt/rlogin/, FTP und WWW verursacht wird. Eine entsprechende Konfiguration sieht so aus: <tscreen><verb> # # Löschen der bestehenden Accounting Regeln ipfwadm -A -f # # Neue Regeln für 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 # </verb></tscreen> 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 Zähler für <em/alle/ zutreffenden Regeln erhöht werden. Für eine genaue, differentielle Analyse muß man also ein wenig rechnen. Um z.B. herauszufinden, welcher Datenanteil nicht von FTP, telnet, rlogin oder WWW herrührt, müssen die Summe der Zahlenwerte der einzelnen Ports subtrahiert werden von der Regel, die alle Ports umfaßt: <tscreen><verb> # ipfwadm -A -l -n IP accounting rules pkts bytes dir prot source destination ports 0 0 in tcp 0.0.0.0/0 44.136.8.96/29 * -> 20 0 0 out tcp 44.136.8.96/29 0.0.0.0/0 20 -> * 0 0 in tcp 0.0.0.0/0 44.136.8.96/29 * -> 23 0 0 out tcp 44.136.8.96/29 0.0.0.0/0 23 -> * 10 1166 in tcp 0.0.0.0/0 44.136.8.96/29 * -> 80 10 572 out tcp 44.136.8.96/29 0.0.0.0/0 80 -> * 242 9777 in tcp 0.0.0.0/0 44.136.8.96/29 * -> 513 220 18198 out tcp 44.136.8.96/29 0.0.0.0/0 513 -> * 252 10943 in tcp 0.0.0.0/0 44.136.8.96/29 * -> * 231 18831 out tcp 0.0.0.0/0 44.136.8.96/29 * -> * 0 0 in udp 0.0.0.0/0 44.136.8.96/29 * -> * 0 0 out udp 0.0.0.0/0 44.136.8.96/29 * -> * 0 0 in icmp 0.0.0.0/0 44.136.8.96/29 * 0 0 out icmp 0.0.0.0/0 44.136.8.96/29 * 0 0 in tcp 0.0.0.0/0 0.0.0.0/0 * -> 20 0 0 out tcp 0.0.0.0/0 0.0.0.0/0 20 -> * 0 0 in tcp 0.0.0.0/0 0.0.0.0/0 * -> 23 0 0 out tcp 0.0.0.0/0 0.0.0.0/0 23 -> * 10 1166 in tcp 0.0.0.0/0 0.0.0.0/0 * -> 80 10 572 out tcp 0.0.0.0/0 0.0.0.0/0 80 -> * 243 9817 in tcp 0.0.0.0/0 0.0.0.0/0 * -> 513 221 18259 out tcp 0.0.0.0/0 0.0.0.0/0 513 -> * 253 10983 in tcp 0.0.0.0/0 0.0.0.0/0 * -> * 231 18831 out tcp 0.0.0.0/0 0.0.0.0/0 * -> * 0 0 in udp 0.0.0.0/0 0.0.0.0/0 * -> * 0 0 out udp 0.0.0.0/0 0.0.0.0/0 * -> * 0 0 in icmp 0.0.0.0/0 0.0.0.0/0 * 0 0 out icmp 0.0.0.0/0 0.0.0.0/0 * # </verb></tscreen> <sect1>IP Aliasing <nidx>IP!Aliasing</nidx> <nidx>Netzwerk!Treiber!IP Aliasing</nidx> <nidx>Kernel!Netzwerk!IP Aliasing</nidx> Es gibt einige Anwendungen, bei denen es hilfreich ist, wenn man einem einzelnen Netzwerk-Device mehrere IP Adressen zuweisen kann. Provider für Internet Dienste verwenden dies häufig, um ihren Kunden speziell angepaßte WWW- und FTP-Dienste anzubieten. <bf/Optionen beim Kernel kompilieren:/ <tscreen><verb> Networking options ---> .... [*] Network aliasing .... <*> IP: aliasing support </verb></tscreen> Die Konfiguration für IP Aliasing ist sehr einfach. Die Aliases werden virtuellen Netzwerk Devices zugewiesen, die an das tatsächliche Device gekoppelt sind. Eine einfache Namenskonvention für diese Devices ist <tt><Devicename>:<virtuelle Dev Nummer></tt>, also z.B. <tt/eth0:0/, <tt/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: <tscreen><verb> # 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 </verb></tscreen> Um einen Alias zu löschen, hängen sie einfach ein <tt/-/ an das Ende seines Namens an: <tscreen><verb> # ifconfig eth0:0- 0 </verb></tscreen> Alle mit diesem Device verbundenen Routes werden automatisch ebenfalls gelöscht. <sect1>IP Firewall <nidx>IP!Firewall</nidx> <nidx>Firewall</nidx> <nidx>Netzwerk!Treiber!IP Firewall</nidx> <nidx>Kernel!Netzwerk!IP Firewall</nidx> <nidx>ipfwadm!IP Firewall</nidx> Alles was mit IP Firewall und Firewalls allgemein zu tun hat, wird ausführlich im <htmlurl name="Firewall HOWTO" url="DE-Firewall-HOWTO.html"> erläutert. 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 für Regeln: Incoming Filter, Outgoing Filter und Forward Filter. <em/Incoming/ Filter werden auf Datenpakete angewandt, die über eine Netzwerkschnittstelle empfangen werden. <em/Outgoing/ Filter gelten für Datenpakete, die über eine Netzwerkschnittstelle ausgegeben werden. <em/Forward/ Filter werden auf Datenpakete angewandt, die zwar angenommen werden, aber nicht für den eigenen Rechner bestimmt sind, also solche, die gerouted werden. <bf/Optionen beim Kernel kompilieren:/ <tscreen><verb> Networking options ---> [*] Network firewalls .... [*] IP: forwarding/gatewaying .... [*] IP: firewalling [ ] IP: firewall packet logging </verb></tscreen> Die Konfiguration eines IP Firewall wird mit dem Befehl <tt/ipfwadm/ durchgeführt. Wie bereits erwähnt bin ich kein Experte in Sachen Sicherheit. Obwohl hier ein Beispiel für 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 für ein lokales Netzwerk einzusetzen und dieses gegen unerlaubten Zugriff von außerhalb zu sichern. Die folgende Konfiguration basiert auf einem Beitrag von Arnt Gulbrandsen (<tt><htmlurl url="mailto:agulbra@troll.no" name="agulbra@troll.no"></tt>). Das Beispiel beschreibt die Konfiguration der Firewall-Regeln des Linux Firewall/Router Rechners aus folgendem Schaubild: <tscreen><verb> - - \ | 172.16.37.0 \ | /255.255.255.0 \ --------- | | 172.16.174.30 | Linux | | NET =================| f/w |------| ..37.19 | PPP | router| | -------- / --------- |--| Mail | / | | /DNS | / | -------- - - </verb></tscreen> Die folgenden Befehle gehören eigentlich in eine <tt/rc/-Datei, so daß sie automatisch bei jedem Systemstart ausgeführt werden. Um maximale Sicherheit zu erreichen, sollten sie <em/nach/ der Konfiguration der Netzwerk Devices, aber <em/vor/ deren Aktivierung ausgeführt werden. Dadurch wird ein Einbruch während des Bootens unterbunden. <tscreen><verb> #!/bin/sh # Löschen 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 schließen. # Besser wäre hier "-a deny" anstelle von "-a reject -y", # aber dann wäre es auch nicht mehr möglich, ü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 gefährlichen 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 würden Verzögerungen 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 für 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, hängen Sie ein 1:1023 an. /sbin/ipfwadm -F -a deny -o -y -P tcp -S 0/0 \ -D 172.16.37.0/24 # ... ebenfalls für UDP /sbin/ipfwadm -F -a deny -o -P udp -S 0/0 \ -D 172.16.37.0/24 </verb></tscreen> Gute Firewall Konfigurationen sind etwas trickreich. Dieses Beispiel sollte einen brauchbaren Anfang liefern. Die Hilfeseite zu <tt/ipfwadm/ gibt weitere Unterstützung bei der Konfiguration. Wenn Sie vorhaben, einen Firewall einzurichten, erkundigen Sie sich auch bei vertrauenswürdigen Bekannten und sammeln sie soviel Hinweise und Ratschläge wie möglich. Suchen sie auch jemanden, der ein paar Zuverlässigkeits- und Funktionstests von außerhalb durchführt. <sect1>IPX (AF_IPX) <nidx>IPX</nidx> <nidx>Novell Netware</nidx> <nidx>ncpfs!Treiber</nidx> <nidx>Netzwerk!Treiber!IPX</nidx> <nidx>Kernel!Netzwerk!IPX</nidx> Das IPX Protokoll wird hauptsächlich in lokalen Netzwerken unter Novell Netware(tm) verwendet. Linux unterstützt dieses Protokoll und kann als Endpunkt oder Router für IPX verwendet werden. <bf/Optionen beim Kernel kompilieren:/ <tscreen><verb> Networking options ---> [*] The IPX protocol [ ] Full internal IPX network </verb></tscreen> IPX Protokoll und NCPFS werden ausführlich im <htmlurl name="IPX HOWTO" url="http://metalab.unc.edu/LDP/HOWTO/IPX-HOWTO.html"> behandelt. <sect1>IPv6 <nidx>IP!Version 6</nidx> <nidx>Netzwerk!Treiber!IPv6</nidx> <nidx>Kernel!Netzwerk!IPv6</nidx> Da hat man nun gerade geglaubt, IP Netzwerke ansatzweise zu verstehen, und nun werden die Regeln geändert. IPv6 ist eine abgekürzte Form für die Version 6 des Internet Protokolls. IPv6 wurde vorrangig entwickelt, um den Befürchtungen der Internet Gemeinde entgegenzuwirken, daß es bald einen Engpaß bei den IP Adressen gäbe. IPv6 Adressen sind 16 Byte, also 128 Bit, lang. Außerdem enthält 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 unvollständige Implementation von IPv6. Wenn Sie mit dieser neuen Generation der Internet Technologie experimentieren wollen, sollten Sie das <em/IPv6 FAQ/ lesen. Es ist von <tscreen><htmlurl url="http://www.terra.net/ipv6/" name="http://www.terra.net/ipv6"></tscreen> erhältlich. <sect1>ISDN <nidx>ISDN</nidx> <nidx>Kernel!Treiber!ISDN</nidx> <nidx>Netzwerk!Treiber!ISDN</nidx> <nidx>B-Kanal</nidx> <nidx>D-Kanal</nidx> Das Integrated Services Digital Network (ISDN) hat in Deutschland vor allem als Ersatz für das alte analoge Telefonnetz eine recht große Verbreitung gefunden. Im Gegensatz zum alten Telefonnetz ist dieses vollständig digital ausgelegt. Auch hat man von Anfang an ISDN nicht nur zur Übermittlung von Sprache ausgelegt sondern auch für andere Dienste wie z.B. BTX, Fax oder Datenübertragung. Wie beim herkömmlichen Telefonnetz wird jeweils eine Punkt zu Punkt Verbindung zwischen zwei Teilnehmern aufgebaut. Für die Datenübertragung ist ISDN vor allem wegen der Datenübertragungsrate von 64 kBit/s und der geringeren Störanfälligkeit interessant. Inzwischen hat das herkömmliche 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-Kanäle und einen D-Kanal. Die B-Kanäle dienen der eigentlichen Datenübertragung. 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. für den Verbindungsaufbau übermittelt. Der Kunde kann zwischen verschiedenen ISDN-Anschlüssen wählen. Neben dem für Privatkunden üblichen Anschluß mit zwei B-Kanälen, gibt es noch Multiplexer Anschlüsse, die 30 B-Kanäle anhalten und damit immerhin eine Bandbreite von 2 MBit/s bieten. Zu jedem Zeitpunkt können beliebig viele dieser Kanäle in jeder Kombination benutzt werden. So können z.B. zwei Verbindungen mit jeweils 64 kBit/s zu zwei anderen Teilnehmern aufgebaut werden. Es können aber auch beide Kanäle zusammengefaßt werden, so daß dann eine Verbindung mit 128 kBit/s zu einem anderen Teilnehmer aufgebaut werden kann. Natürlich können auch Kanäle unbenutzt bleiben, da ja für jeden Kanal jeweils Gebühren erhoben werden, wenn er benutzt wird. Ein Kanal kann für eingehende oder ausgehende Verbindungen genutzt werden. Das ursprüngliche Ziel hinter ISDN war es, den Telekommunikationsgesellschaften die Möglichkeit 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 anzuschließen. Eine Möglichkeit stellt ein »Terminal Adapter« dar. Diese werden wie analoge Modems an die serielle Schnittstelle des Rechners angeschlossen. Die meisten dieser Geräte werden wie ein Modem per AT-Befehlssatz gesteuert und benötigen deshalb keinen speziellen Treiber. Eine andere Möglichkeit ist die Verwendung einer passiven oder aktiven ISA- oder PCI-Karte. Da hier der Rechner meistens einen Teil des ISDN-Protokolls generieren muß, benötigt Linux spezielle Treiber für jeden Kartentyp. <bf/Optionen beim Kernel kompilieren:/ <tscreen><verb> ISDN subsystem ---> <*> ISDN support [ ] Support synchronous PPP [ ] Support audio via ISDN < > ICN 2B and 4B support < > PCBIT-D support < > Teles/NICCY1016PC/Creatix support </verb></tscreen> Linux unterstützt eine Reihe unterschiedlicher ISDN Karten: <itemize> <item/ICN 2B und 4B/ <item/Octal PCBIT-D/ <item/Teles ISDN-Karten und kompatible/ </itemize> Für einige dieser Karten ist zusätzliche Software nötig, um sie zu betreiben. Diese muß mit speziellen Programmen geladen werden. Weitere Details zur Konfiguration von ISDN unter Linux befinden sich im Verzeichnis <tt>/usr/src/linux/Documentation/isdn</tt>, außerdem existiert das isdn4linux FAQ, zu beziehen bei <tscreen><htmlurl url="http://www.lrz-muenchen.de/˜ui161ab/www/isdn/" name="http://www.lrz-muenchen.de/˜ui161ab/www/isdn/"> </tscreen> Es gibt dort eine deutsche und eine englische Version. Außerdem gibt es noch eine deutsche <htmlurl url="DE-ISDN-HOWTO.html" name="ISDN HOWTO">. <nidx>PPP!ISDN</nidx> Ein Hinweis zu PPP: PPP ist generell für den Betrieb sowohl über synchrone wie auch über asynchrone serielle Verbindungen ausgelegt. Der normalerweise in Linux-Distributionen enthaltene Daemon <tt/pppd/ unterstützt jedoch nur den asynchronen Modus. Wenn sie PPP über ihre ISDN Verbindung benutzen wollen, benötigen sie eine speziell angepaßte Version. Nähere Details dazu finden sie in den oben erwähnten Quellen. <sect1>IP Masquerade <nidx>IP!Masquerading</nidx> <nidx>Masquerading</nidx> <nidx>Netzwerk!Treiber!IP Masquerading</nidx> <nidx>Kernel!Netzwerk!IP Masquerading</nidx> <nidx>ipfwadm!IP Masquerading</nidx> Viele Personen setzen eine einfache Einwahlverbindung als Zugang zum Internet ein. Hierbei wird dem einwählenden Rechner praktisch immer genau eine einzige IP Adresse zugewiesen. Das ist normalerweise ausreichend, um einem einzelnen Rechner vollen Zugang zu den Möglichkeiten des Internet zu geben. Allerdings kann der Rechner <em/nicht/ direkt als Router ins Internet für andere Rechner verwendet werden, da diese dann auch eine weltweit eindeutige IP Adresse benötigen würden. Nun könnte man ja prinzipiell den eigenen Provider bieten, mehr offizielle IP Adresse zur Verfügung zu stellen. Dem stehen jedoch zwei Gründen 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 Verträgen für 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 außen aufbauen, er kann aber keine Anfragen/Verbindungen von außenliegenden Rechnern empfangen. Deshalb funktionieren einige Dienste wie <tt/talk/ nicht, andere wie z.B. FTP müssen speziell auf passiven Modus (PASV) konfiguriert werden, damit sie funktionieren. Zum Glück sind aber Standard-Dienste wie <tt/telnet/, IRC und WWW davon nicht betroffen. <bf/Optionen beim Kernel kompilieren:/ <tscreen><verb> Code maturity level options ---> [*] Prompt for development and/or incomplete code/drivers Networking options ---> [*] Network firewalls .... [*] TCP/IP networking [*] IP: forwarding/gatewaying .... [*] IP: masquerading (EXPERIMENTAL) </verb></tscreen> Auf dem Linux Rechner wird SLIP oder PPP ganz normal konfiguriert, wie für einen Einzelrechner. Außerdem besitzt der Rechner aber eine weitere Netzwerkschnittstelle, z.B. eine Ethernetkarte, über die er mit dem lokalen Netzwerk verbunden ist. An diesem Netz hängen auch die Rechner, die maskiert werden sollen. Jeder dieser anderen Rechner muß nun zunächst zu konfiguriert werden, daß er die IP Adresse des Linux Rechners als Gateway bzw. Router verwendet. Eine typische Konfiguration sieht etwa so aus: <tscreen><verb> - - \ | 192.168.1.0 \ | /255.255.255.0 \ --------- | | | Linux | .1.1 | NET =================| masq |------| | PPP/slip | router| | -------- / --------- |--| host | / | | | / | -------- - - </verb></tscreen> Die wichtigsten Konfigurationsbefehle in diesem Fall sind: <tscreen><verb> # Netzwerk Route für Ethernet route add 192.168.1.0 netmask 255.255.255.0 eth0 # Default Route für 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 </verb></tscreen> Weitere Informationen über IP Masquerade unter Linux enthält die IP Masquerade Resource Page: <tscreen><htmlurl url="http://www.hwy401.com/achau/ipmasq/" name="http://www.hwy401.com/achau/ipmasq/"></tscreen> <sect1>IP Transparent Proxy <nidx>IP!Transparent Proxy</nidx> <nidx>Transparent Proxy</nidx> <nidx>Netzwerk!Treiber!IP Transparent Proxy</nidx> <nidx>Kernel!Netzwerk!IP Transparent Proxy</nidx> <nidx>ipfwadm!IP Transparent Proxy</nidx> IP Transparent Proxy ermöglicht es, Anfragen für 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. <bf/Optionen beim Kernel kompilieren:/ <tscreen><verb> Code maturity level options ---> [*] Prompt for development and/or incomplete code/drivers Networking options ---> [*] Network firewalls .... [*] TCP/IP networking .... [*] IP: firewalling .... [*] IP: transparent proxy support (EXPERIMENTAL) </verb></tscreen> Die Konfiguration von IP Transparent Proxy wird mit Hilfe des Befehles <tt/ipfwadm/ durchgeführt, zum Beispiel so: <tscreen><verb> # ipfwadm -I -a accept -D 0/0 80 -r 8080 </verb></tscreen> 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. <sect1>Mobile IP <nidx>Mobile IP</nidx> <nidx>IP!Mobile</nidx> <nidx>Netzwerk!Treiber!Mobile IP</nidx> <nidx>Kernel!Netzwerk!Mobile IP</nidx> Der Ausdruck »IP mobility« beschreibt die Fähigkeit 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 tatsächlich genutzte IP Adresse umgeleitet wird. In einem derzeit in Entwicklung befindlichen Projekt sollen alle notwendigen Programme für IP Mobility unter Linux zusammengetragen werden. Den gegenwärtigen Stand der Dinge erfahren Sie auf der <em/Linux Mobile IP Home Page/: <tscreen><htmlurl url="http://anchor.cs.binghamton.edu/˜mobileip/" name="http://anchor.cs.binghamton.edu/˜mobileip/"> </tscreen> <sect1>Multicast <nidx>Multicast</nidx> <nidx>Netzwerk!Treiber!Multicast</nidx> <nidx>Kernel!Netzwerk!Multicast</nidx> Mit IP Mulicast ist es möglich, 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 ermöglichen. <bf/Optionen beim Kernel kompilieren:/ <tscreen><verb> Networking options ---> [*] TCP/IP networking .... [*] IP: multicasting </verb></tscreen> Ein paar spezielle Programme sowie einige kleinere Konfigurationsänderungen des Netzwerkes sind nötig, um diese Möglichkeiten auszunutzen. Weitere Informationen zu Installation und Konfiguration findet man z.B. bei <tscreen><htmlurl url="http://www.teksouth.com/linux/multicast/" name="http://www.teksouth.com/linux/multicast/"> </tscreen> <sect1>NetRom (AF_NETROM) <nidx>NetRom</nidx> <nidx>Packet Radio!NetRom</nidx> <nidx>HAM!NetRom</nidx> <nidx>Netzwerk!Treiber!NetRom</nidx> <nidx>Kernel!Netzwerk!NetRom</nidx> Die NetRom Devices sind <tt/nr0/, <tt/nr1/ usw. <bf/Optionen beim Kernel kompilieren:/ <tscreen><verb> Networking options ---> [*] Amateur Radio AX.25 Level 2 [*] Amateur Radio NET/ROM </verb></tscreen> Die Protokolle AX.25, NetRom und Rose werden von Amateurfunkern für Experimente mit Packet Radio genutzt. Eine Ausführliche Beschreibung enthält das <htmlurl name="AX25 HOWTO" url="DE-AX25-HOWTO.html">. Der Großteil der Arbeit bei der Implementation dieser Protokolle wurde von Jonathon Naylor (<tt><htmlurl url="mailto:jsn@cs.not.ac.uk" name="jsn@cs.not.ac.uk"></tt>) geleistet. <sect1>PLIP <nidx>PLIP!Treiber</nidx> <nidx>Netzwerk!Treiber!PLIP</nidx> <nidx>Kernel!Netzwerk!PLIP</nidx> <nidx>parallele Schnittstelle!PLIP!Treiber</nidx> Die Namen der PLIP Devices sind <tt/plip0/, <tt/plip1/ usw. Das erste Device erhält die Nummer <tt/0/, die weiteren werden fortlaufend durchnumeriert. <bf/Optionen beim Kernel kompilieren:/ <tscreen><verb> Networking options ---> <*> PLIP (parallel port) support </verb></tscreen> <em/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 höhere Datenübertragungsraten erreichen. Außerdem lassen sich selbst die einfachsten parallelen Anschlüsse, die Druckerports, verwenden. Aber Vorsicht, manche Laptops verwenden Chipsätze, mit denen PLIP nicht verwendet werden kann: Sie lassen bestimmte Kombinationen von Signalen, die PLIP zum Funktionieren benötigt, nicht zu, da sie von Druckern nicht verwendet werden. <nidx>Crynwyr</nidx> 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 <tt>/usr/src/linux/driver/net/CONFIG</tt> werfen. Sie enthält Definitionen für den PLIP Timer in ms. Die Standardwerte sind zwar meist einwandfrei, insbesondere bei langsamen Rechnern wird man sie aber unter Umständen erhöhen müssen und zwar auf dem <em/schnelleren/ Rechner. Der Treiber geht von folgenden Einstellungen aus: <tscreen><verb> device i/o addr IRQ ------ -------- ----- plip0 0x3BC 5 plip1 0x378 7 plip2 0x278 2 (9) </verb></tscreen> Entspricht ihr Parallelports keiner dieser Möglichkeiten, können die Werte mit dem Befehl <tt/ifconfig/ und der Option <tt/irq/ geändert werden. Achten Sie auch darauf, daß die IRQs für den Parallelport im BIOS aktiviert sind. Zu Konfiguration des PLIP Interface müssen die folgenden Befehle in der für das Netzwerk zuständigen <tt/rc/-Datei hinzugefügt werden: <tscreen><verb> # Konfiguriere den ersten Parallelport als PLIP Device /sbin/ifconfig plip0 IPA.IPA.IPA.IPA pointopoint \ IPR.IPR.IPR.IPR up # # Ende PLIP </verb></tscreen> Dabei ist <descrip> <tag>IPA.IPA.IPA.IPA</tag>ihre IP Adresse; <tag>IPR.IPR.IPR.IPR</tag>die IP Adresse des anderen Rechners. </descrip> Der Parameter <tt/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 <tt/dip/ oder <tt/slattach/ brauchen und können nicht verwendet werden. Wie ein für PLIP passendes Kabel auszusehen hat, wird in Abschnitt <ref id="DE-NET3-HOWTO-Kabel-PLIP" name="Kabel für die parallele Schnittstelle"> beschrieben. Obwohl man PLIP Verbindungen teilweise auch über lange Distanzen verwenden kann, sollten Sie das nach Möglichkeit vermeiden. Die Spezifikationen erlauben eine Kabellänge von etwa einem Meter. Wenn Sie dennoch längere Kabel verwenden wollen, achten Sie besonders auf elektromagnetische Störeinstreuungen (Blitz, andere Stromkabel, Radiosender), da auch dadurch eine Beeinträchtigung der Verbindung bis hin zur Beschädigung des Controllers möglich ist. Wenn sie wirklich eine Verbindung über größere Distanzen herstellen wollen oder müssen, kaufen Sie lieber zwei billige Ethernet-Karten und ein Koaxial-Kabel <sect1>PPP <nidx>PPP!Treiber</nidx> <nidx>serielle Schnittstelle!PPP</nidx> <nidx>Netzwerk!Treiber!PPP</nidx> <nidx>Kernel!Netzwerk!PPP</nidx> Die Namen der PPP Devices sind <tt/ppp0/, <tt/ppp1/ usw. Die Devices werden fortlaufend durchnumeriert, beginnend mit <tt/0/ für das erste konfigurierte Device. <bf/Optionen beim Kernel kompilieren:/ <tscreen><verb> Networking options ---> <*> PPP (point-to-point) support </verb></tscreen> Die Konfiguration von PPP wird im <htmlurl name="PPP HOWTO" url="DE-PPP-HOWTO.html"> beschrieben. <sect2>Permanente Netzverbindungen mit pppd <nidx>PPP!permanente Verbindungen</nidx> Falls Sie sich in der glücklichen Lage befinden, eine mehr oder weniger dauerhafte Netzanbindung zu haben, gibt es eine sehr einfache Möglichkeit, daß der Rechner automatisch eine neue PPP Verbindung aufbaut, wenn diese zusammenbrechen sollte. Dabei muß PPP derart konfiguriert werden, daß von <tt/root/ durch einen einfachen Befehl gestartet werden kann: <tscreen><verb> # pppd </verb></tscreen> Stellen Sie sicher, daß sie in der Datei <tt>/etc/ppp/options</tt> die Option <tt/-detach/ eingetragen haben. Dann fügen sie die folgende Zeile bei den <tt/getty/-Definitionen in die Datei <tt>/etc/inittab</tt> ein: <tscreen><verb> pd:23:respawn:/usr/sbin/pppd </verb></tscreen> Dadurch wird der Daemon <tt/pppd/ laufend von <tt/init/ überwacht und im Falle eines Verbindungsabbruches automatisch neu gestartet. <sect1>Rose protocol (AF_ROSE) <nidx>Rose</nidx> <nidx>Packet Radio!Rose</nidx> <nidx>HAM!Rose</nidx> <nidx>Netzwerk!Treiber!Rose</nidx> <nidx>Kernel!Netzwerk!Rose</nidx> Die Namen der Rose Devices sind <tt/rs0/, <tt/rs1/ usw. Rose wird nur in den Entwickler-Kernels <tt/2.1.x/ unterstützt. <bf/Optionen beim Kernel kompilieren:/ <tscreen><verb> Networking options ---> [*] Amateur Radio AX.25 Level 2 <*> Amateur Radio X.25 PLP (Rose) </verb></tscreen> Die Protokolle AX.25, NetRom und Rose werden von Amateurfunkern für Experimente mit Packet Radio genutzt. Eine Ausführliche Beschreibung enthält das <htmlurl name="AX25 HOWTO" url="DE-AX25-HOWTO.html">. Der Großteil der Arbeit bei der Implementation dieser Protokolle wurde von Jonathon Naylor (<tt><htmlurl url="mailto:jsn@cs.not.ac.uk" name="jsn@cs.not.ac.uk"></tt>) geleistet. <sect1>SAMBA - »NetBEUI«, »NetBios« Unterstützung <nidx>Samba</nidx> <nidx>Netzwerk!Samba</nidx> SAMBA ist eine Implementation des Session Management Block Protokolles. Mit SAMBA ist es möglich, daß Systeme, die Betriebssysteme von Microsoft wie z.B. Windows verwenden, die Platten des Linux-Rechners mounten und dessen Drucker verwenden können. SAMBA und seine Konfiguration werden ausführlich im <htmlurl name="Linux Samba HOWTO" url="DE-Samba-HOWTO.html"> beschrieben. <sect1>SLIP Client <nidx>SLIP!Client</nidx> <nidx>serielle Schnittstelle!SLIP</nidx> <nidx>Netzwerk!SLIP</nidx> <nidx>Kernel!Netzwerk!SLIP</nidx> Die Namen der SLIP Devices sind <tt/sl0/, <tt/sl1/ usw. Das erste konfigurierte Device erhält die Nummer <tt/0/, weitere werden fortlaufend durchnumeriert. <bf/Optionen beim Kernel kompilieren:/ <tscreen><verb> Network device support ---> [*] Network device support <*> SLIP (serial line) support [ ] CSLIP compressed headers [ ] Keepalive and linefill [ ] Six bit SLIP encapsulation </verb></tscreen> SLIP (Serial Line IP) ermöglicht TCP/IP Verbindungen über serielle Leitungen wie Telefonleitungen (mit Modem) oder gemietete Standleitungen. Um es zu benutzen, benötigt man einen <em/SLIP-Server/ möglichst in der näheren Umgebung. Viele Universitäten und einige Firmen bieten einen solchen Service an. SLIP verwendet die serielle Schnittstelle des Rechners, um Datenpakete zu versenden. Dafür muß man diese Schnittstelle kontrollieren können. Wie sind die SLIP-Namen den seriellen Schnittstellen zugeordnet? Der Netzwerk Code verwendet einen <tt/ioctl()/ (I/O Control) Aufruf, um die serielle Schnittstelle in ein SLIP-Device »umzuschalten«. Es gibt zwei Programme, die diese Aufgabe übernehmen: <tt/dip/ und <tt/slattach/. <sect2>dip <nidx>dip</nidx> <nidx>SLIP!dip</nidx> <nidx>Netzwerk!SLIP!dip</nidx> <tt/dip/ (Dialup IP) ist ein intelligentes Programm, das die Übertragungsgeschwindigkeit der seriellen Schnittstelle einstellen kann, das Modem zum Wählen veranlaßt, automatisch die eingehenden Meldungen der Gegenstelle nach den notwendigen Informationen wie der IP-Adresse durchsucht und die notwendigen <tt/ioctl()/ Aufrufe ausführt, um die Schnittstelle in den SLIP Modus zu schalten. <tt/dip/ unterstützt eine umfangreiche Script-Sprache und kann dadurch den gesamten Login-Prozeß automatisieren. Die Bezugsquelle ist <tscreen><htmlurl url="ftp://metalab.unc.edu/pub/Linux/system/Network/serial/dip/" name="metalab.unc.edu:/pub/Linux/system/Network/serial/dip/"> </tscreen> Zur Installation gehen Sie wie folgt vor; zuerst wird das Paket entpackt: <tscreen><verb> # cd /usr/src # gzip -dc dip337o-uri.tgz | tar xvf - # cd dip-3.3.7o </verb></tscreen> Nur muß der Makefile an die eigenen Bedürfnisse angepaßt werden. Schließlich wird das Programm kompiliert und installiert: <tscreen><verb> # make # make install </verb></tscreen> Das Makefile nimmt die Existenz einer Gruppe <tt/uucp/ an, dies kann aber leicht z.B. in <tt/dip/ oder <tt/SLIP/ umgeändert werden. <sect2>slattach <nidx>slattach</nidx> <nidx>SLIP!slattach</nidx> <nidx>Netzwerk!SLIP!slattach</nidx> Im Gegensatz zu <tt/dip/ ist <tt/slattach/ ein extrem einfaches Programm. Es ist einfach zu benutzen, bietet aber nicht den Komfort oder die Script-Fähigkeit von <tt/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. <tt/slattach/ ist optimal geeignet, wenn sie eine dauerhafte Verbindung zu ihrem Server haben. <sect2>Wann benutze ich welches Programm? <tt/dip/ bietet sich an, wenn die Verbindung zum SLIP Server über ein Modem oder eine andere temporäre Leitung aufgebaut wird. <tt/slattach/ ist eher für feste Verbindungen, ein fest installiertes Kabel etwa, oder eine gemietete Leitung geeignet. Für Fälle also, in denen keine besonderen Aktionen notwendig sind, um die Verbindung aufzubauen. Für weitere Informationen finden sich in dem Abschnitt <ref id="DE-NET3-HOWTO-SLIP-dauerhafte-Verbindungen" name="Dauerhafte SLIP Verbindungen">. Die Konfiguration von SLIP ist bis auf ein paar kleine Ausnahmen sehr ähnlich zur Konfiguration eines Ethernet Device. Zunächst unterscheiden sich SLIP Verbindungen von Ethernet Netzwerken dadurch, daß an einem SLIP-»Netzwerk« immer nur zwei Rechner beteiligt sind. Außerdem sind bei SLIP Verbindungen oft zusätzliche Maßnahmen notwendig, um die Netzverbindung zu aktivieren, wohingegen bei einer Ethernet Netzwerk die Verbindung bereits mit dem Einstecken der Kabel besteht. Wenn Sie <tt/dip/ verwenden, wird der Verbindungsaufbau normalerweise nicht bereits beim Booten vorgenommen sondern erst zu einem späteren Zeitpunkt, wenn eine Netzverbindung benötigt wird. Es ist auch dann möglich, diesen Vorgang zu automatisieren. Falls Sie <tt/slattach/ verwenden, werden Sie vermutlich lieber einen speziellen Abschnitt in der Datei <tt>rc.inet1</tt> einfügen wollen. Dies wird etwas später 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 Paßwort einzugeben. <tt/dip/ kann diese Loginprozedur übernehmen und automatisch durchführen. <sect2>Statische SLIP Server und dip <nidx>dip!statische IP Adresse</nidx> <nidx>SLIP!dip!statische IP Adresse</nidx> Bei einem statischen SLIP Server bekommen Sie eine IP Adresse für 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 durchführen 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 <tt>/etc/hosts</tt> einfügen. Auch in den folgenden Dateien sollten Sie entsprechende Konfigurationsänderungen vornehmen: <tt>rc.inet2</tt>, <tt>host.conf</tt>, <tt>resolv.conf</tt>, <tt>etc/HOSTNAME</tt> sowie <tt>rc.local</tt>. Denken Sie auch daran, daß bei der Konfiguration von <tt>rc.inet1</tt> keine besonderen Befehle zur Konfiguration der SLIP Verbindung benötigt werden, dies wird zur gegebenen Zeit von <tt/dip/ erledigt. Dazu müssen ihm lediglich die notwendigen Informationen mitgeteilt werden, dann wird die Konfiguration automatisch durchgeführt, nachdem die Einwählprozedur beendet ist. Falls Ihr SLIP Server statische Adressen verwendet, können Sie den folgenden Abschnitt überspringen und gleich den Abschnitt <ref id="DE-NET3-HOWTO-Benutzung-von-dip" name="Benutzung von dip"> lesen. <sect2>Dynamische SLIP Server und dip <nidx>dip!dynamische IP Adresse</nidx> <nidx>SLIP!dip!dynamische IP Adresse</nidx> Ein dynamischer SLIP Server vergibt die IP Adressen zufällig 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 für 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 für ihn für die Dauer der Verbindung reserviert. Die Konfiguration verläuft hier recht ähnlich wie im Falle von statischen SLIP Servern, allerdings muß in einem zusätzlichen Schritt die zugewiesene IP Adresse ermittelt werden, um das SLIP Device entsprechend zu konfigurieren. Auch in diesem Fall übernimmt <tt/dip/ den schwierigen Teil. Die neueren Versionen sind intelligent genug, um nicht nur den Verbindungsaufbau durchzuführen, sondern auch automatisch die übermittelte IP Adresse zu erkennen und damit das SLIP Device zu konfigurieren. <sect2>Die Benutzung von dip <label id="DE-NET3-HOWTO-Benutzung-von-dip"> <nidx>dip!Benutzung</nidx> <nidx>SLIP!dip!Benutzung</nidx> Wie bereits erwähnt, handelt es sich bei <tt/dip/ um ein mächtiges Programm, welches den aufwendigen Prozeß des Einwählens in einen SLIP Server, die Loginprozedur sowie die Konfiguration des SLIP Device vereinfachen und automatisieren kann. Um <tt/dip/ zu verwenden, benutzt man im Allgemeinen ein <tt/dip/-Script, das eigentlich nur aus einer Liste von Kommandos besteht, die <tt/dip/ versteht, und die ihm mitteilen, wie die notwendigen Aktionen durchgeführt werden sollen. Die Datei <tt/sample.dip/, die Bestandteil des Paketes ist, vermittelt einen ersten Eindruck, wie das vor sich geht. <tt/dip/ ist ein Programm mit vielen Optionen. Sie alle hier aufzulisten, wäre müßig. Lesen Sie dazu bitte die Online Hilfe, die Beispieldatei sowie die Datei <tt/README/ des <tt/dip/-Paketes. <nidx>/etc/dipscript</nidx> Sie werden feststellen, daß die Beispieldatei <tt/sample.dip/ von einem statischen SLIP Server ausgeht, die verwendete IP Adresse also bereits bekannt sein muß. Für dynamische SLIP Server gibt es in den neueren Versionen von <tt/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 veränderte Version der Datei <tt/sample.dip/, die mit der Version <tt/dip337j-uri.tgz/ ausgeliefert wird. Sie stellt vermutlich einen ausreichenden Startpunkt für alle dar, die einen dynamischen SLIP Server verwenden. Speichern Sie es unter dem Namen <tt>/etc/dipscript</tt> und verändern Sie es entsprechend ihrer eigenen Konfiguration: <tscreen><verb> # # sample.dip Programm für Dialup IP Verbindung # # Dieses Datei zeigt, wie DIP verwendet wird. # # Für 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 heißt "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 für das Modem und die Terminal Verbindung. # Das verursacht bei manchen Anwendern Probleme! reset # Hinweis: Standardmäßig vordefinierte "errlevel" # Werte sind: # 0 - OK # 1 - CONNECT # 2 - ERROR # # Man kann sie ändern. Suchen Sie (mit grep) nach # "addchat()" in *.c # Vorbereitung zum Wählen 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" # durchgeführt 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 </verb></tscreen> Dieses Script geht von einer dynamischen SLIP Verbindung aus. Für statische SLIP Server verwenden Sie bitte die Datei <tt/sample.dip/ aus dem Paket <tt/dip337j-uri.tgz/. Wenn <tt/dip/ den Befehl get $local erhält, durchsucht es sämtlichen eingehenden Text von der anderen Seite auf eine Zeichenkette, die wie eine IP Adresse aussieht, also Zahlen, die durch Punkte getrennt sind. Diese Veränderung wurde eingeführt, damit der Verbindungsaufbau auch für dynamische SLIP Server automatisiert werden kann. Das obige Beispiel konfiguriert automatisch einen Default Route Eintrag über das SLIP Device. Entspricht das nicht ihren Wünschen, z.B. weil Sie außerdem noch eine Ethernet Verbindung haben, die ihre Default Route darstellt, entfernen Sie die Zeile <tt/default/ aus dem Script. Nachdem das Script beendet ist, können Sie mit dem Befehl <tt/ifconfig/ verifizieren, daß ein Device <tt/sl0/ existiert. Dieses Device können Sie dann mit den üblichen <tt/ifconfig/ und <tt/route/ Befehlen Ihren Wünschen entsprechend konfigurieren. <nidx>CSLIP</nidx> <nidx>SLIP!dip!CSLIP</nidx> Beachten Sie auch, daß sie mit <tt/dip/ mittels des <tt/mode/ Befehles unterschiedliche Protokolle nutzen können. Das am häufigsten verwendete ist wohl <em/CSLIP/ für 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 <tt/dip/. Selbstverständlich kann ein solches Script auch derart erweitert werden, daß bei einem gescheiterten Einwahlversuch erneut gewählt wird, oder sogar eine andere Nummer angerufen wird. <sect2>Dauerhafte SLIP Verbindungen mit slattach <label id="DE-NET3-HOWTO-SLIP-dauerhafte-Verbindungen"> <nidx>slattach</nidx> <nidx>SLIP!slattach</nidx> Wenn sie zwei Rechner direkt über ein Kabel miteinander verbinden, oder in der glücklichen Lage sind, über eine gemietete Standleitung mit dem Internet verbunden zu sein, können Sie sich die aufwendige Prozedur mit <tt/dip/ ersparen. <tt/slattach/ ist ein extrem einfach zu benutzendes Programm, das gerade genug Funktionalität 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 <tt/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 <tt/slattach/ erreichen sie dies mit einem einzigen Befehl. Fügen Sie einfach folgende Zeilen in ihr <tt/rc.inet1/ ein: <tscreen><verb> # # Aufbau einer dauerhaften statischen SLIP Verbindung # # Konfiguriere /dev/cua0 für 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. </verb></tscreen> Hierbei ist: <descrip> <tag>IPA.IPA.IPA.IPA</tag>Ihre IP Adresse; <tag>IPR.IPR.IPR.IPR</tag>die IP Adresse des anderen Rechners. </descrip> <tt/slattach/ weist dem angegebenen seriellen Device das erste freie SLIP Device zu, beginnend mit <tt/sl0/. Der erste Aufruf von <tt/slattach/ konfiguriert also das Device <tt/sl0/, ein weiterer Aufruf <tt/sl1/ usw. Mit <tt/slattach/ können mittels der Option <tt/-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. <sect1>SLIP Server <nidx>SLIP!Server</nidx> Wenn Sie einen Rechner mit Netzwerkzugang besitzen, über den Sie anderen Nutzern die Einwahl in das Netz ermöglichen wollen, müssen Sie diesen Rechner als Server konfigurieren. Wenn Sie für die Verbindung als serielles Protokoll SLIP verwenden wollen, haben Sie drei Möglichkeiten unterschiedliche Möglichkeiten für diese Konfiguration. Ich würde den ersten Vorschlag, <tt/sliplogin/, bevorzugen, da er am einfachsten zu realisieren und zu verstehen ist. Aber treffen Sie ihre eigene Entscheidung. <sect2>SLIP Server mit sliplogin <nidx>SLIP!sliplogin</nidx> <nidx>/etc/slip.hosts</nidx> <nidx>/etc/slip.login</nidx> <nidx>/etc/slip.tty</nidx> <nidx>/etc/slip.logout</nidx> <tt/sliplogin/ können Sie anstelle der normalen Login-Shell für Nutzer verwenden, die sich in ihren Rechner einwählen. Das Programm schaltet automatisch die serielle Verbindung in den SLIP Modus und bietet Unterstützung sowohl für statische als auch für dynamische IP Adressenvergabe. Der Benutzer führt einen normalen Login-Prozeß durch, also Eingabe von Benutzerkennung und Paßwort. Aber statt dann eine Shell vorgesetzt zu bekommen, wird <tt/sliplogin/ gestartet, das in der Datei <tt>/etc/slip.hosts</tt> nach einem Eintrag für den anrufenden Benutzer sucht. Wird dieser gefunden, wird die Verbindung als 8 Bit clean konfiguriert und über einen <tt/ioctl/ Aufruf in den SLIP Modus geschaltet. Danach startet <tt/sliplogin/ als letzten Schritt ein Script, in dem das SLIP Device mit den entsprechenden Parametern (IP Adresse, Netmask, Routing) konfiguriert wird. Dieses Script heißt üblicherweise <tt>/etc/slip.login</tt>, aber wie auch bei <tt/getty/ können Sie für Benutzer, die einer besonderen Behandlung bedürfen, eigene Scripts unter dem Namen <tt>/etc/slip.login.loginname</tt> anlegen, die dann anstelle des Standardscriptes gestartet werden. Es gibt drei bzw. vier Dateien, die konfiguriert werden müssen, damit <tt/sliplogin/ richtig funktioniert: <descrip> <tag>/etc/passwd</tag> Enthält die Accounts der Benutzer. <tag>/etc/slip.hosts</tag> Hier stehen die für jeden Nutzer spezifischen Informationen für SLIP. <tag>/etc/slip.login</tag> Dieses Script regelt die Routing Konfiguration für die Nutzer. <tag>/etc/slip.tty</tag> Diese Datei wird nur bei der Verwendung von <em/dynamischer/ Adressvergabe benötigt und enthält eine Tabelle mit benutzbaren Adressen. <tag>/etc/slip.logout</tag> Hier stehen die Kommandos, um die Verbindung bei einem Logout oder bei Fehlern korrekt zu beenden. </descrip> <sect3>Bezugsquellen für sliplogin Eventuell ist <tt/sliplogin/ bereits Bestandteil ihrer Linux-Distribution. Wenn dieses nicht der Fall ist, bekommt man es von <tscreen><htmlurl url="ftp://metalab.unc.edu/pub/linux/system/Network/serial/" name="metalab.unc.edu:/pub/linux/system/Network/serial/"> </tscreen> Die TAR Datei enthält Quellen, vorkompilierte Binärprogramme und die manual page. Um sicherzustellen, daß nur autorisierte Nutzer <tt/sliplogin/ benutzen können, sollten Sie in der Datei <tt>/etc/group</tt> einen Eintrag wie diesen hier vorsehen: <tscreen><verb> slip::13:radio,fred </verb></tscreen> Bei der Installation von <tt/sliplogin/ wird das Makefile die Eigentumsrechte für <tt/sliplogin/ auf die Gruppe <tt/slip/ setzen. Dadurch können nur Nutzer, die in dieser Gruppe sind, das Programm ausführen. Im oben angeführten Beispiel wären das die Nutzer <tt/radio/ und <tt/fred/. Um die Programme im Verzeichnis <tt>/sbin</tt> und die manual pages in der Sektion 8 zu installieren, gehen Sie folgendermaßen vor. Zuerst wird das Paket entpackt: <tscreen><verb> # cd /usr/src # gzip -dc .../sliplogin-2.1.1.tar.gz | tar xvf - # cd sliplogin-2.1.1 </verb></tscreen> Nun wird das Makefile editiert, falls Sie keine Shadow Paßwörter verwenden. Schließlich kann das Paket installiert werden: <tscreen><verb> # make install </verb></tscreen> Falls Sie die Programme vor der Installation selber neu übersetzen wollen, fügen Sie vor dem <tt/make install/ noch ein <tt/make clean/ ein. Sollen die Programme in eine anderes Verzeichnis installiert werden, müssen Sie im Makefile die Regel <tt/install/ entsprechend editieren. Lesen Sie bitte auch die Datei <tt/README/, die zum Paket gehört. <sect3>Anpassung von /etc/passwd für SLIP Hosts Normalerweise richtet für jeden Benutzer von SLIP einen speziellen Account in <tt>/etc/passwd</tt> ein. Eine Konvention hierbei ist es, als Benutzernamen ein großes <tt/S/, gefolgt vom Namen des einwählenden Rechners, zu verwenden. Ein Rechner mit dem Namen <tt/radio/ bekommt also folgenden Eintrag: <tscreen><verb> Sradio:FvKurok73:1427:1:radio SLIP login:/tmp:/sbin/sliplogin </verb></tscreen> Diese Konvention ist allerdings nicht zwingend. Sie können jeden beliebigen Namen verwenden, der ihnen aussagekräftig genug erscheint. Hinweis: Der Anrufer benötigt kein besonderes Heimatverzeichnis, da er von diesem Rechner niemals eine Shell zu Gesicht bekommen wird. <tt>/tmp</tt> ist deshalb eine gute Wahl für diesen Zweck. Beachten Sie auch den Eintrag <tt>/sbin/sliplogin</tt> als Login-Shell. <sect3>Konfiguration von /etc/slip.hosts In der Datei <tt>/etc/slip.hosts</tt> sucht <tt/sliplogin/ nach Einträgen, die dem Namen des Anrufers entsprechen. In dieser Datei werden IP Adresse und Netmask festgelegt, die dem Anrufer zugewiesen werden. Das folgende Beispiel enthält Einträge für zwei Rechner, <tt/radio/ und <tt/albert/, wobei letzterem die IP Adresse dynamisch zugewiesen wird: <tscreen><verb> # Sradio 44.136.8.99 44.136.8.100 255.255.255.0 normal -1 Salbert 44.136.8.99 DYNAMIC 255.255.255.0 compressed 60 # </verb></tscreen> Die einzelnen Einträge sind: <enum> <item>Login-Name des Anrufers <item>IP Adresse des Servers <item>IP Adresse, die dem Anrufer zugeteilt wird. Enthält dieses Feld den Eintrag <tt/DYNAMIC/, wird die IP Adresse basierend auf den Informationen in der Datei <tt>/etc/slip.tty</tt> bestimmt. Aber Vorsicht, das funktioniert erst ab Version 1.3 von <tt/sliplogin/. <item>Netmask für den Anrufer in Dezimalpunktschreibweise, für ein Klasse-C Netz also 255.255.255.0. <item>Verwendeter SLIP Modus, hier können Kompression sowie einige andere Besonderheiten eingestellt werden. <item>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. <item>Optionale Argumente </enum> In den Feldern 2 und 3 können sowohl Rechnernamen als auch IP Adressen in Dezimalpunktschreibweise stehen. Wenn Sie Rechnernamen verwenden, müssen diese allerdings auflösbar sein, d.h. der Server muß in der Lage sein, die zu dem Namen gehörende IP Adresse herauszufinden. Überprüfen können Sie dies z.B. durch ein <tt/telnet/ auf diesen Rechnernamen. Bekommen Sie dann die Meldung <tt/Trying nnn.nnn.nnn.../, hat ihr Rechner den Namen einwandfrei aufgelöst. Bekommen Sie hingegen die Meldung <tt/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 <ref id="DE-NET3-HOWTO-Konfiguration-Name-Resolver" name="Konfiguration des Name Resolvers"> erläutert. Die am häufigsten verwendeten Einstellungen für den SLIP Modus sind <descrip> <tag>normal </tag>Für normales, unkomprimiertes SLIP. <tag>compressed </tag>Um van Jacobsen Header Kompression (cSLIP) zu aktivieren. </descrip> Die beiden Optionen schließen sich natürlich wechselseitig aus. Für weitere Informationen lesen Sie bitte die Online-Hilfe. <sect3>Konfiguration der Datei /etc/slip.login Hat <tt/sliplogin/ einen passenden Eintrag in <tt>/etc/slip.hosts</tt> gefunden, wird es als nächstes versuchen, das Script <tt>/etc/slip.login</tt> zu starten, um das SLIP Interface mit den notwendigen Parametern IP Adresse und Netmask zu konfigurieren. Die mit dem Paket gelieferte Beispieldatei sieht folgendermaßen aus: <tscreen><verb> #!/bin/sh - # # @(#)slip.login 5.1 (Berkeley) 7/1/90 # # Generische login Datei für 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 # </verb></tscreen> Sie werden feststellen, daß dieses Script ganz einfach nur die Befehle <tt/ifconfig/ und <tt/route/ verwendet, um das SLIP Device zu konfigurieren, genau wie das auch bei der Verwendung von <tt/slattach/ der Fall wäre. Beachten Sie auch die Verwendung von <em/Proxy ARP/. Damit wird sichergestellt, daß andere Rechner, die am selben Ethernet Netzwerk wie der Server angeschlossen sind, den einwählenden Rechner erreichen können. Ist ihr Server nicht an ein Ethernet Netz angeschlossen, können Sie diese letzte Zeile ganz auslassen. <sect3>Konfiguration von /etc/slip.logout Falls die Verbindung zusammenbricht, sollten Sie sicherstellen, daß die serielle Schnittstelle in ihren Normalzustand zurückversetzt wird, damit der nächste Anrufer sich ganz normal einloggen kann. Dieses erreichen Sie mit dem Script <tt>/etc/slip.logout</tt>. Es hat ein sehr einfaches Format und wird mit denselben Parametern wie <tt>/etc/slip.login</tt> aufgerufen, auch wenn davon nur ein paar verwendet werden. <tscreen><verb> #!/bin/sh - # # slip.logout # /sbin/ifconfig $1 down arp -d $6 exit 0 # </verb></tscreen> Alles was es macht, ist das Interface herunterzufahren, wodurch automatisch auch die vorher angelegte Route gelöscht wird. Den hier ebenfalls enthaltenen <tt/arp/ Aufruf können Sie auch wieder löschen, falls Sie nicht an ein Ethernet Netzwerk angeschlossen sind. <sect3>Konfiguration von /etc/slip.tty Falls Sie dynamische IP Adressen verwenden, also mindestens einen der Rechner mit dem Eintrag <tt/DYNAMIC/ konfiguriert haben, dann müssen Sie auch die Datei <tt>/etc/slip.tty</tt> konfigurieren, indem Sie dort alle zur Auswahl stehenden Adressen auflisten. Sie benötigen diese Datei aber nur für die dynamische Vergabe von IP Adressen. Die Datei ist eine Tabelle, die die <tt/tty/-Devices auflistet, über die SLIP Verbindungen eingehen können, und die IP Adresse, die einem Anrufer auf dem jeweiligen Port zugewiesen wird: <tscreen><verb> # slip.tty tty -> IP Adressenzuweisung für # dynamisches SLIP # Format: /dev/tty?? xxx.xxx.xxx.xxx # /dev/ttyS0 192.168.0.100 /dev/ttyS1 192.168.0.101 # </verb></tscreen> Das vorstehende Beispiel legt also fest, daß all denjenigen Anrufern, die sich über den Port <tt>/dev/ttyS0</tt> einwählen und in dem entsprechenden Feld in der Datei <tt>/etc/slip.hosts</tt> den Eintrag <tt/DYNAMIC/ haben, die IP Adresse <tt>192.168.0.100</tt> zugewiesen bekommen. Dadurch benötigt man nur eine Adresse je zur Verfügung stehenden Port und kann so die Anzahl der belegten Adressen klein halten. <sect2>SLIP Server mit dip <nidx>dip!Server</nidx> <nidx>SLIP!dip!Server</nidx> <nidx>diplogin</nidx> Zu Beginn ein Hinweis: Einige der in diesem Abschnitt gegebenen Informationen entstammen der manual page von <tt/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 <tt>dip337o-uri.tgz</tt> und gelten nicht automatisch für andere Versionen dieses Paketes. <tt/dip/ hat einen speziellen Eingabemodus, in dem es für denjenigen, der es gestartet hat, automatisch alle notwendigen Informationen aus der Datei <tt>/etc/diphosts</tt> 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 <tt/diplogin/ gestartet wird. Um <tt/dip/ auf eine Server zu verwenden, müssen Sie also lediglich besondere Accounts einrichten, die <tt/diplogin/ als Login-Shell verwenden. Dafür muß zunächst ein symbolischer Link angelegt werden: <tscreen><verb> # ln -sf /usr/sbin/dip /usr/sbin/diplogin </verb></tscreen> Dann müssen entsprechende Einträge in <tt>/etc/passwd</tt> und <tt>/etc/diphosts</tt> vorgenommen werden. Für jeden Benutzer wird - wie auch bei <tt/sliplogin/ - ein Account angelegt. Konvention ist auch hier, den Nutzernamen mit einem großen <tt/S/ zu beginnen. Das sieht dann etwa so aus: <tscreen><verb> Sfredm:ij/SMxiTlGVCo:1004:10:Fred:/tmp:/usr/sbin/diplogin ^^ ^^ ^^ ^^ ^^ ^^ ^^ | | | | | | \__ diplogin als Login Shell | | | | | \_______ Heimatverzeichnis | | | | \____________ Voller Nutzername | | | \_________________ User Group ID | | \_____________________ User ID | \_______________________________ Verschlüsseltes Passwort \__________________________________________ Slip User Login Name </verb></tscreen> Der Login wird wie gewöhnlich vom Programm login(1) abgewickelt. Ist alles in Ordnung, wird das Programm <tt/diplogin/ gestartet. <tt/dip/, mit dem Namen <tt/diplogin/ aufgerufen, weiß dann automatisch, daß es als Login-Shell benutzt wird. Als erstes ruft es dann die Funktion <tt/getuid()/ auf, um die Benutzer ID desjenigen herauszufinden, der das Programm gestartet hat. Danach sucht es in der Datei <tt>/etc/diphosts</tt> nach dem ersten Eintrag, der entweder der Benutzer-ID oder aber dem Namen des <em/tty/ entspricht, über den die Verbindung aufgebaut wurde, und führt dementsprechend die Konfiguration durch. Durch die Entscheidung, einem Nutzer entweder einen Eintrag für seine ID zuzuweisen, oder die Standardeinstellung für das <em/tty/ zu verwenden, können einfach statische und dynamische Adressen parallel verwendet werden. <tt/dip/ fügt in diesem Modus automatisch einen Eintrag für Proxy-ARP durch, dies muß also nicht von Hand geschehen. <sect3>Die Konfiguration von /etc/diphosts Die Datei <tt>/etc/diphosts</tt> wird von <tt/dip/ verwendet, um voreingestellte Konfigurationen für unterschiedliche Rechner zu speichern. Dabei kann es sich um Rechner handeln, die sich in ihren Rechner einwählen, aber auch um solche, in die Sie sich mit ihrem Rechner einwählen. Das allgemeine Format der Einträge in <tt>/etc/diphosts</tt> sieht so aus: <tscreen><verb> Suwalt::145.71.34.1:145.71.34.2:255.255.255.0:SLIP uwalt:CSLIP,1006 ttyS1::145.71.34.3:145.71.34.2:255.255.255.0:Dynamic ttyS1:CSLIP,296 </verb></tscreen> Die einzelnen Einträge bedeuten: <enum> <item><bf/Login Name/: Name, wie er von <tt/getpwuid(getuid())/ zurückgeliefert wird, oder Name des <em/tty/. <item><bf/unbenutzt/: Zur Kompatibilität mit <tt/passwd/. <item><bf/Remote Adresse/: IP Adresse des anrufenden Rechners, entweder als Name oder in Dezimalschreibweise. <item><bf/Lokale Adresse/: IP Adresse des lokalen Rechners, entweder als Name oder in Dezimalschreibweise. <item><bf/Netmask/: in Dezimalschreibweise <item><bf/Kommentar/: beliebiger Eintrag <item><bf/Protokoll/: SLIP, CSLIP usw. <item><bf/MTU/: Zahl </enum> Der untere der beiden Beispieleinträge legt also z.B. fest, daß ein Anrufer auf <tt/ttyS1/ die (dynamische) Adresse <tt/145.71.34.3/ zugewiesen bekommt und die Verbindung mit Komprimierung (<tt/CSLIP/) und einer MTU von 296 konfiguriert wird. Alle Nutzer, die eine <em/statische/ IP Adresse zugewiesen bekommen sollen, müssen einen Eintrag unter ihrem Login-Namen in <tt>/etc/diphosts</tt> haben. Für andere Anrufer, denen die IP Adresse dynamisch zugewiesen werden soll, muß ein Eintrag für die in Frage kommenden <em/tty/ Ports vorhanden sein. Es sollte auf jeden Fall für jeden vorhandenen Port ein Eintrag vorhanden sein, um sicherzustellen, daß ein Anrufer in jedem Fall eine gültige Konfiguration vorfindet. Wenn sich nun ein Benutzer einlogged, wird er ganz normal nach Name und Paßwort gefragt. Hier muß er seinen SLIP Login-Namen und das zugehörige Paßwort eingeben. Verläuft alles normal, wird der Benutzer keinerlei zusätzliche Meldungen bekommen, er sollte dann einfach die Verbindung in den SLIP Modus schalten, dann sollte er eine Verbindung mit den Parametern aus <tt/diphosts/ aufbauen können. <sect2>SLIP Server mit dem dSLIP Paket <nidx>SLIP!dSLIP</nidx> <nidx>dSLIP</nidx> Matt Dillon (<tt><htmlurl url="mailto:dillon@apollo.west.oic.com" name="dillon@apollo.west.oic.com"></tt>) 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 <tt>tcsh</tt> installiert sein, da mindestens eines der Scripts auf deren Syntax angewiesen ist. Jedoch ist dies keine große Einschränkung, da die <tt>tcsh</tt> bei den meisten Distributionen mitgeliefert wird. Außerdem gehört zu Matts Paket auch eine ausführbare Kopie des Programmes <tt>expect</tt>, das ebenfalls an einigen Stellen benötigt wird. Es ist von Vorteil, wenn man sich mit <tt>expect</tt> bereits auskennt, da andernfalls bei der Konfiguration leicht Fehler gemacht werden können. Aus diesem Grunde empfiehlt sich das Paket mehr für 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 <tt/README/ gibt. Das dSLIP Paket bekommt man von: <itemize> <item><tt><htmlurl url="ftp://apollo.west.oic.com/pub/linux/dillon_src/" name="apollo.west.oic.com:/pub/linux/dillon_src/"> </tt> <item><tt> <htmlurl url="ftp://metalab.unc.edu/pub/Linux/system/Network/serial/" name="metalab.unc.edu:/pub/Linux/system/Network/serial/"> </tt> </itemize> Wichtig ist, die Datei <tt/README/ aufmerksam zu lesen und vor allem die dort angegebenen Einträge in den Dateien <tt>/etc/passwd</tt> und <tt>/etc/group</tt> einzufügen, bevor ein <tt>make install</tt> ausgeführt wird. <sect1>Unterstützung für STRIP (Starmode Radio IP) <nidx>STRIP</nidx> <nidx>Kernel!Netzwerk!STRIP</nidx> <nidx>Netzwerk!Treiber!STRIP</nidx> <nidx>Packet Radio!STRIP</nidx> <nidx>HAM!STRIP</nidx>  <bf/Optionen beim Kernel kompilieren:/ <tscreen><verb> Network device support ---> [*] Network device support .... [*] Radio network interfaces < > STRIP (Metricom starmode radio IP) </verb></tscreen> Das STRIP Protokoll wurde speziell für eine besondere Art von Funk-Modems entwickelt, die in einem Forschungsprojekt der Universität Stanford mit dem Namen MosquitoNet Project verwendet werden: <tscreen><htmlurl url="http://mosquitonet.Stanford.EDU/mosquitonet.html" name="http://mosquitonet.Stanford.EDU/mosquitonet.html"> </tscreen> 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 Wellenlängenbereiche und können typischerweise etwa 100kbps übertragen. Informationen über diese Sender finden sie auf dem Metricom Web Server: <tscreen><htmlurl url="http://www.metricom.com/" name="http://www.metricom.com"> </tscreen> Die normalen Netzwerkprogramme unterstützen dieses Protokoll derzeit nicht, sie müssen sich also speziell angepaßte Versionen vom MosquitoNet Webserver beschaffen. Genauere Informationen, welche Software Sie benötigen, finden sie auf der MosquitoNet STRIP Page: <tscreen><htmlurl url="http://mosquitonet.Stanford.EDU/strip.html" name="http://mosquitonet.Stanford.EDU/strip.html"></tscreen> Eine kurze Zusammenfassung der Konfiguration: Sie verwenden eine modifizierte Version des Programmes <tt/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 unterstützt kein ARP, die ARP Einträge für alle Rechner eines Sub-Netzwerkes müssen also von Hand vorgenommen werden. <sect1>Token Ring <nidx>Token Ring!Treiber</nidx> <nidx>Netzwerk!Treiber!Token Ring</nidx> <nidx>Kernel!Netzwerk!Token Ring</nidx> Die Namen der Token Ring Devices sind <tt/tr0/, <tt/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 nächsten Rechner weitergegeben. Das Token wandert also zwischen allen aktiven Rechnern herum, daher der Name »Token Ring«. <bf/Optionen beim Kernel kompilieren:/ <tscreen><verb> Network device support ---> [*] Network device support .... [*] Token Ring driver support < > IBM Tropic chipset based adaptor support </verb></tscreen> Die Konfiguration eines Token Ring Device ist bis auf die anderen Devicenamen identisch zur Konfiguration eines Ethernet Device. <sect1>X.25 <nidx>X.25</nidx> <nidx>Netzwerk!Treiber!X.25</nidx> <nidx>Kernel!Netzwerk!X.25</nidx> 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 <tt/2.1.x/. Jonathon Naylor (<tt><htmlurl url="mailto:jsn@cs.nott.ac.uk" name="jsn@cs.nott.ac.uk"></tt>) leitet die Entwicklung. Es wurde eine Mailing Liste angelegt, über die Diskussionen zum Thema X.25 unter Linux geführt werden. Um sie zu abonnieren, schicken Sie eine Mail an <tt><htmlurl url="mailto:majordomo@vger.rutgers.edu" name="majordomo@vger.rutgers.edu"></tt> mit dem Text <tt/subscribe linux-x25/" als Inhalt der Mail. Erste Versionen der Konfigurationsprogramme bekommen Sie per FTP von: <tscreen><htmlurl url="ftp://ftp.cs.nott.ac.uk/jsn/" name="ftp.cs.nott.ac.uk:/jsn/"></tscreen> <sect1>WaveLan Karten <nidx>WaveLan</nidx> <nidx>Netzwerk!Treiber!WaveLan</nidx> <nidx>Kernel!Netzwerk!WaveLan</nidx> Die Device Namen für WaveLan sind <tt/eth0/, <tt/eth1/ usw. <bf/Optionen beim Kernel kompilieren:/ <tscreen><verb> Network device support ---> [*] Network device support .... [*] Radio network interfaces .... <*> WaveLAN support </verb></tscreen> WaveLan Karten sind für 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: <tscreen><htmlurl url="http://www.wavelan.com/" name="http://www.wavelan.com"></tscreen> <sect>Kabel und Verkabelung Wer mit einem Lötkolben umgehen kann, möchte sich vielleicht ein Kabel basteln, um zwei Linux Rechner zu verbinden. Die folgenden Diagramme sollten Sie dabei unterstützen. <sect1>Ein Serielles NULL Modem Kabel <nidx>NULL Modem Kabel</nidx> <nidx>serielle Schnittstelle!NULL Modem Kabel</nidx> <nidx>Netzwerk!Kabel!NULL Modem Kabel</nidx> <nidx>Kabel!NULL Modem</nidx> 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 Flußkontrolle (XON/XOFF) verwenden müssen, was weniger effizient ist als eine Hardware Flußkontrolle. Das folgende Kabel bietet die bestmögliche Signalverbindung zwischen Rechnern und erlaubt die Verwendung der Hardware Flußkontrolle (RTS/CTS). <tscreen><verb> Pin Name Pin Pin Tx Data 2 ----------------------------- 3 Rx Data 3 ----------------------------- 2 RTS 4 ----------------------------- 5 CTS 5 ----------------------------- 4 Ground 7 ----------------------------- 7 DTR 20 -\--------------------------- 8 DSR 6 -/ RLSD/DCD 8 ---------------------------/- 20 \- 6 </verb></tscreen> <sect1>Kabel für die parallele Schnittstelle (PLIP) <label id="DE-NET3-HOWTO-Kabel-PLIP"> <nidx>PLIP!Kabel</nidx> <nidx>parallele Schnittstelle!PLIP!Kabel</nidx> <nidx>Netzwerk!Kabel!PLIP</nidx> <nidx>Kabel!PLIP</nidx> Wenn Sie zur Verbindung zweier Rechner das PLIP Protokoll nutzen wollen, sollten Sie folgende Verkabelung wählen, die unabhängig von der Art der verwendeten Parallelschnittstelle ist. <tscreen><verb> Pin Name Pin Pin STROBE 1* D0->ERROR 2 ----------- 15 D1->SLCT 3 ----------- 13 D2->PAPOUT 4 ----------- 12 D3->ACK 5 ----------- 10 D4->BUSY 6 ----------- 11 D5 7* D6 8* D7 9* ACK->D3 10 ----------- 5 BUSY->D4 11 ----------- 6 PAPOUT->D2 12 ----------- 4 SLCT->D1 13 ----------- 3 FEED 14* ERROR->D0 15 ----------- 2 INIT 16* SLCTIN 17* GROUND 25 ----------- 25 </verb></tscreen> <bf/Hinweise:/ <itemize> <item>Die mit einem Stern <tt/*/ gekennzeichneten Pins dürfen nicht verbunden werden. <item>Geschirmte Kabel sollten nur auf einer Seite mit dem Metall des Steckers verbunden werden. <item>Ein falsch verdrahtetes PLIP-Kabel kann ihre Controller Karte zerstören. Seien Sie sehr vorsichtig, und überprüfen Sie jede Verbindung doppelt, um unnötigen Ärger zu vermeiden. </itemize> <sect1>(Thin) Ethernet Verkabelung (10base2) <nidx>Netzwerk!Kabel!Ethernet</nidx> <nidx>Kabel!Ethernet</nidx> <nidx>Ethernet!Kabel</nidx> 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 <em/beiden/ Enden des Busses Terminatoren angebracht werden müssen. 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 unzuverlässig oder gar nicht. Normalerweise werden T-Stücke verwendet, um Rechner anzuschließen. Das Netzwerk sieht also etwa so aus: <tscreen><verb> |==========T=============T=============T==========T==========| | | | | | | | | ----- ----- ----- ----- | | | | | | | | ----- ----- ----- ----- </verb></tscreen> Die Zeichen <tt/|/ an beiden Enden stellen die Terminatoren dar, <tt/====/ ist ein Stück Koaxial-Kabel mit BNC-Steckern, <tt/T/ das erwähnte T-Stück. Die Kabellänge zwischen T-Stück und der Ethernetkarte muß äußerst kurz gehalten werden, normalerweise sollte es direkt am Ausgang der Ethernetkarte angebracht werden.  <sect>Glossar der im Text verwendeten Ausdrücke <descrip> <tag>ARP</tag>Ein Akronym für Address Resolution Protocol. Es beschreibt, wie ein vernetzter Rechner einer IP Adresse eine Hardware Adresse zuordnet. <tag>ATM</tag>Ein Akronym für Asynchronous Transfer Mode. Ein ATM Netzwerk verpackt Daten in Zellen einer vorgegebenen Größe, die effizient von einem zum anderen Punkt übertragen werden kann. <tag>Client</tag>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 <em/Peer-to-Peer/ Netzwerk wie SLIP oder PPP ist der Client diejenige Seite, die die Verbindung initiiert, die angerufene Seite bezeichnet man als Server. <tag>Datagramm</tag>Ein Datagramm ist ein einzelnes Datenpaket, bestehend aus Daten und einem Header, der die Adressen enthält. Basiseinheit der Übertragung über ein IP Netzwerk, wird manchmal auch als »Paket« bezeichnet. <tag>DLCI</tag><em/Data Link Connection Identifier/, bezeichnet eine eindeutige Point-to-Point Verbindung über ein Frame Relay Netzwerk. DLCIs werden normalerweise vom Provider festgelegt. <tag>Frame Relay</tag>Eine Netzwerktechnologie, die insbesondere für 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. <tag>Hardware Adresse</tag>Eine Zahl, die einen Rechner in einem physikalischen Netzwerk eindeutig auf Hardware-Zugriffsebene identifiziert. Beispiele hierfür sind die Ethernet-Adresse oder die AX.25 Adresse. <tag>ISDN</tag>Ein Akronym für Integrated Services Dedicated Network. Bietet einen standardisierten Weg für Telefongesellschaften, Sprache oder Daten zum Endkunden zu übertragen. <tag>ISP</tag>Ein Akronym für Internet Service Provider - Anbieter von Internet Diensten. Organisationen oder Firmen, die anderen Personen Anschluß an das Internet anbieten. <tag>IP Adresse</tag>Eine Nummer, die einen Rechner in einem IP Netzwerk eindeutig identifiziert. Die Adressen sind 4 Byte lang und werden für gewöhnlich in der Dezimalpunktschreibweise dargestellt, bei der jedes Byte als Dezimalzahl (0-255), durch Punkte getrennt, aufgeschrieben wird. <tag>MSS</tag>Ein Akronym für Maximum Segment Size. Die maximale Größe eines Datenpaketes, das auf einmal übertragen werden kann. Um lokale Fragmentation zu vermeiden sollte gelten MSS=MTU-IP_Header. <tag>MTU</tag>Ein Akronym für Maximum Transmission Unit. Die maximale Größe eines Datagrammes, das über ein IP Interface übertragen werden kann, ohne in Teilstücke zerlegt werden zu müssen. Die MTU sollte größer sein als das größte 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 möglicherweise kleinere Werte für die MTU verwenden und die Datenpakete dann dort fragmentiert werden. Typische Werte sind 1500 für ein Ethernet Interface und 576 für ein SLIP Interface. <tag>Route</tag>Der Weg, den ein Datenpaket vom Startrechner zum Zielrechner nimmt. <tag>Server</tag>Ein Server bietet einen Dienst für 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. <tag>Window</tag>Die größte Datenmenge, die der Empfänger zu jedem beliebigen Zeitpunkt empfangen kann. </descrip> <sect>Linux für einen ISP ? Wenn Sie Linux verwenden wollen, um Netzwerkdienste anzubieten, sollten sie einen Blick auf die Linux ISP Homepage <tscreen><htmlurl url="http://www.anime.net/linuxisp/" name="http://www.anime.net/linuxisp/"> </tscreen> werfen. Sie finden dort viele Verweise auf hilfreiche Informationen zu diesem Thema. </article>