Archiv für den Monat: Januar 2008

Allgemein

1.113.2 – Sendmail

Schreibe einen Kommentar

zurück zu Linux Zertifizierungen LPIC
1.113.2 – Verwendung und allgemeine Konfiguration von Sendmail
Prüfungskandidaten sollten in der Lage sein, einfache Einstellungen in den Sendmail Konfigurationsdateien vorzunehmen (einschließlich des “Smart Host” Parameters, wenn notwendig), Mail-Aliases anzulegen, die Mail-Queue zu verwalten, Sendmail zu starten und zu stoppen, Mail-Weiterleitung zu konfigurieren und allgemeine Sendmail-Probleme zu lösen.

Die wichtigsten Dateien, Bezeichnungen und Anwendungen:

* /etc/sendmail.cf
* /etc/aliases oder /etc/mail/aliases
* /etc/mail/*
* ~/.forward

Die Einrichtung eines Mailservers mit sendmail gilt als eines der kompliziertesten Kapitel der Unix-Serverinstallation. Es existiert ein tausendseitiges Buch alleine über die Sendmail-Konfiguration, es gibt auch die Weisheit:

Ein richtiger Unix-Systemadministrator ist man erst, wenn man einmal eine Sendmail Konfigurationsdatei geschrieben hat.

Ein richtiger Unix-Systemadministrator wird sich aber hüten, es ein zweites Mal zu tun.

Aber so schlimm ist es heute nicht mehr, keine Angst. Die modernen Sendmail Versionen bringen heute ausgesprochen leicht zu handhabende Konfigurationsdateien mit, die die Arbeit mit Sendmail erleichtern. Wenn also kein zu komplizierter Mailserver aufgesetzt werden soll, dann können wir uns das Leben sehr einfach machen.

Die LPI102 Prüfung verlangt kein tiefergehendes Wissen über die Geheimnisse der sendmail Konfiguration, es genügen die notwendigen Informationen, um einen einfachen Mailserver einzurichten.

Die Architektur von E-Mail
Das SMTP Prinzip verteilt seine Aufgaben auf verschiedene Programme. Die zwei grundlegenden Programmtypen sind dabei

Der Mail User Agent (MUA)
Das Programm, mit dem der User seine Mails liesst und erstellt. Es existieren hunderte verschiedener MUAs, für jedes Betriebssystem. Beispiele hierfür sind Eudora, OutlookExpress, Outlook auf der Windows-Seite und elm, pine, xfmail, kmail, mutt auf der Linux-Seite.
Der Mail Transfer Agent (MTA)
Das Programm, das die abgehende Mail von einem beliebigen MUA erhält und sich darum kümmert, daß diese Mail weitergeleitet wird. Andererseits das Programm, das – bei permanenter Internet-Anbindung – die ankommenden Mails von anderen MTAs entgegennimmt und lokal abspeichert, damit die MUAs darauf zugreifen können. Der verbreitetste und mächtigste MTA ist das Programm sendmail.

Hier geht es prinzipiell um die Konfiguration von MTAs – konkret um die Konfiguration von sendmail. Die genannte Aufteilung der Aufgaben in Userprogramm und Versendeprogramm machen eine Unterscheidung hinsichtlich der Netzanbindung nötig. Es ist ein erheblicher Unterschied, ob unser Mailserver eine permanente Netzanbindung hat, oder nicht.

In einem lokalen Netz kann auf jeder Unix-Workstation ein sendmail-Daemon laufen, jedoch hat nur einer der Rechner die tatsächliche Anbindung ans Internet. Das bewirkt, daß die anderen Rechner ihre Mails an den einen mit Netzanbindung schicken, erst der versendet sie dann weiter ins Internet. Diese Architektur hat in vielen Fällen Vorteile, zum Beispiel

* Bei temporärer Netzanbindung bauen nicht alle User dauernd Verbindungen ins Internet auf, sondern schicken ihre Mails an einen Rechner, der die Mails regelmäßig weiterleitet.
* Bei einer Firewalleinrichtung kann eingestellt werden, daß nur SMTP-Pakete von und zu diesem einen Rechner durchgelassen werden.

Im Regelfall läuft sendmail als stand-alone Dienst. Das heißt, auch bei temporärer Anbindung ist der Daemon ständig im Speicher. Das ist notwendig, damit ein Rechner Mails von anderen MTAs empfangen kann. Ob sendmail die ausgehenden Mails gleich losschickt, oder wohin es sie weiterleitet, das muss konfiguriert werden.

Die zentrale sendmail-Konfigurationsdatei ist /etc/sendmail.cf. Diese Datei selbst zu bearbeiten oder gar zu erstellen ist ausgesprochen kompliziert – das Anfangs angeführte Zitat bezieht sich eben darauf. Wir werden hier nicht die komplette Konfiguration von sendmail behandeln, sondern ausschließlich kleine Veränderungen an dieser Datei vornehmen.

Grundlagen der Mailverzeichnisse im Linux-System
Jedes Unix/Linux-System hat zwei verschiedene Mail-Verzeichnisse. Zum einen existiert eine Warteschlange für ausgehende Mails (meist /var/spool/mqueue oder /var/mqueue) und zum anderen ein Verzeichnis /var/spool/mail, in dem eine Datei für jeden User existiert, die seine angekommene Mail bereithält. Die MUAs und MTAs arbeiten beide mit diesen Verzeichnissen.

Ein MUA, mit dessen Hilfe eine Mail versendet wird, legt diese abgehende Mail mitsamt aller dazu nötigen Headerinformation (von wem kommt die Mail, an wen geht die Mail usw.) in das Spoolverzeichnis für die ausgehende Mail. Der MTA arbeitet diese Warteschlange in regelmäßigen Abständen ab und verschickt die Mails ins Internet – entweder direkt an die empangenden Rechner oder an einen Mailserver des Providers, der dann die Weiterversendung übernimmt.

Umgekehrt bekommt der MTA eingehende Mails aus dem Netz und sortiert sie in die Eingangspostfächer (z.B. /var/spool/mail/hans). Beim nächsten Aufruf eines MUA findet dieser im jeweiligen Verzeichnis dann die neue Mail vor und kann sie darstellen.

Die Programme, die unter Unix ständig dafür sorgen, daß einem User mitgeteilt wird, daß er neue Mail hat (biff/xbiff), nützen ebenso diese Verzeichnisse. Der Vorteil an diesem Prinzip liegt in der Tatsache, daß das Mailsystem so integraler Bestandteil des Systems selbst ist, und nicht ein aufgepfropftes Anwenderprogramm. Nur deshalb können z.B. Programme wie cron oder at ihre Ausgaben als Mail an den User schicken, der den Auftrag gegeben hatte.

Um den Inhalt der Warteschlange anzusehen, existiert der Befehl mailq, der in Wahrheit nur ein symbolischer Link auf sendmail ist.

Starten von sendmail
Die zentrale Aufgabe von sendmail ist es, neben dem Empfang von Mails über SMTP, die Warteschlange für die ausgehende Mail (mqueue) zu bearbeiten. Dazu existieren zwei völlig unterschiedliche Architekturen, entweder ist der Rechner, auf dem sendmail läuft tatsächlich mit einer festen IP-Adresse ans Internet angebunden und von überall her unter einem bestimmten Namen zu erreichen, oder er ist nur temporär ans Internet angebunden und somit nur für das Versenden von Mails gedacht.

Starten des Mailservers mit permanenter Netzanbindung
Auf einem Rechner mit permanenter Internet-Anbindung hat sendmail in der Regel zwei Aufgaben:

* Empfang von Mails aus dem Internet über SMTP
* Versand von ausgehenden Mails über SMTP

Zumindestens die erste Aufgabe bedingt es, daß sendmail permanent als Daemon im Speicher liegt und arbeitet. Nur so ist es gewährleistet, daß eingehende Mails tatsächlich jederzeit angenommen werden können. Der Start von sendmail benötigt hier zwei wesentliche Parameter, der erste gibt an, daß das Programm als Daemon gestartet werden soll und der zweite stellt die Frequenz ein, in der sendmail die Warteschlange bearbeiten soll (in diesem Beispiel 30 Minuten):

sendmail -bd -q30m

Auf diese Weise wird sendmail alle 30 Minuten die Mailqueue lesen und anstehende Aufträge (ausgehende Mails) versenden. Die eingehenden Mails werden jederzeit empfangen.

Starten des Mailservers mit temporärer Netzanbindung
In diesem Fall wird sendmail nur für die Versendung von Mail herangezogen. Das Empfangen wird wahrscheinlich über POP3 oder IMAP geregelt. In diesem Fall muß sendmail nur regelmäßig aufgerufen werden, um die ausgehenden Mails zu versenden. Dazu wird der Parameter -bd weggelassen, um zu verhindern, daß das Programm als Daemon gestartet wird. Der Parameter -q wird ohne Angabe eines Zeitintervalls angegeben. Das führt dazu, daß sendmail die Mailqueue abarbeitet und anschließend beendet wird.

sendmail -q

Dieser Befehl kann jetzt z.B. in regelmäßigen Abständen von cron aufgerufen werden.

Um die interne Weitergabe von Mails zu realisieren, wird meist jedoch auch auf Rechnern ohne permanente Anbindung ein Sendmail-Daemon gestartet, der allerdings nicht die Warteschlange abarbeitet. Die Versendung geschieht mit dem oben genannten Befehl über cron gesteuert, der Aufruf von sendmail heißt dann

sendmail -bd

So ist die interne Funktionalität weiter gewährleistet, ohne daß in regelmäßigen Abständen die Queue abgearbeitet wird.

Mailaliase
sendmail hat die Möglichkeit, Alias-Adressen zu bilden. Das sind E-Mail Adressen, die in Wahrheit keinem normalen User zugeordnet sind, sondern auf andere User verweisen. Häufig benutzte solche Adressen sind z.B.

* webmaster@…
* abuse@…
* ftpadmin@…

In den seltensten Fällen sind das wirkliche User des Systems. Normalerweise werden einfach Aliase angelegt, die diese Adressen dem entsprechenden User zuweisen, der den Job übernommen hat. Dazu kennt sendmail die Datei /etc/aliases oder manchmal auch /etc/mail/aliases.

Das Format dieser Datei ist sehr einfach, pro Zeile wird ein Alias definiert:

Aliasname: Username

Um die drei obigen Beispiele bestimmten Usern zuzuordnen könnten in einer solchen Datei also folgende Einträge stehen:

webmaster: root
abuse: root
ftpadmin: hans

Alle Mails an webmaster@mydomain.de und abuse@mydomain.de würden also an den User root@mydomain.de weitergeleitet, während Mails an ftpadmin@mydomain.de an hans@mydomain.de weitergegeben würden. mydomain.de würde natürlich durch die entsprechende lokale Domain ersetzt.

Es ist auch möglich, bestimmte Adressen nicht an andere Adressen zu versenden, sondern an bestimmte Programme weiterzuleiten. In diesem Fall werden Mails, die an diese Adresse gingen an ein angegebenes Programm weitergepiped. So können z.B. Mailinglists organisiert werden. Statt einem Usernamen wird dann ein Programmname angegeben, dem ein Pipe-Symbol vorangestellt wurde. Programmname und Pipesymbol müssen in doppelte Anführungszeichen gesetzt werden:

Aliasname: “|Pfad/zu/Programm Optionen”

Nach jeder Veränderung der Alias-Datei muß das Programm newaliases aufgerufen werden, um diese Aliase für sendmail bekannt zu machen. Wie mailq ist auch newaliases nur ein symbolischer Link auf sendmail.

Mails an andere Adressen weiterleiten
Einen ähnlichen Mechanismus wie das Setzen von Aliasen bietet die Datei ~/.forward im Homeverzeichnis eines Users. Diese Datei enthält entweder E-Mail-Adressen, Dateinamen oder Programmnamen, an die eingehende Mails des Users, in dessen Homeverzeichnis die Datei liegt, weitergeleitet werden.

Die Syntax der drei möglichen Einträge ist einfach:

E-Mail-Adressen
Enthält eine .forward Datei eine Zeile mit einer einfachen E-Mail-Adresse, so wird jede eingehende Mail des Users an diese Mailadresse weitergeleitet. Die E-Mail-Adresse wird ohne Anführungszeichen angegeben. Enthält sie keine Domain-Angabe, so wird eine lokale Adresse angenommen. Wenn z.B. auf einem Rechner der Useraccount hans der Normallogin des Systemverwalters ist, so kann der Systemverwalter in sein Homeverzeichnis eine .forward Datei anlegen, mit dem Eintrag

hans

Jede Mail an root wird jetzt an Hans weitergeleitet. So empfängt der Systemverwalter seine Mails auch, wenn er sich als hans anmeldet.
Dateinamen
Wenn eingehende Mails in eine bestimmte Datei kopiert werden sollen, so wird der Name der Datei in Anführungszeichen in .forward angegeben. Die angegebene Datei entspricht vom Aufbau her einer normalen Mailbox-Datei, wie sie normalerweise in /var/spool/mail liegt. Alle Mails werden an diese Datei angehängt.

“/var/spool/mail2/hans”
“./Mail/meinemail”

Die Angaben einer Datei werden immer entweder als kompletter Pfad zu der Datei oder als Pfad mit führendem Punkt angegeben. Im zweiten Fall bezieht sich der Pfad auf das Homeverzeichnis des jeweiligen Users.

Bei der Angabe von normalen Pfaden muß darauf geachtet werden, daß der User Schreibrecht auf die entsprechende Datei besitzt.
Programmnamen
Soll eine Mail an ein bestimmtes Programm weitergegeben werden, so wird der Programmname in die Datei .forward in Anführungszeichen mit führendem Pipe-Symbol angegeben.

“| /Pfad/zu/Programm”

Die Mail wird dann an das angegebene Programm gepiped, das heißt, das Programm muß Eingaben von der Standard-Eingabe verarbeiten können. Die Angabe eines Programms erfolgt mit vollem Pfad.

Mit Hilfe dieses Mechanismuses ist es möglich, daß auch Normaluser ihre Mails weiterleiten oder Mailinglisten aufbauen, auch wenn sie keinen Zugriff auf /etc/aliases besitzen.

Ausgehende Mailserver
Wenn Mails von sendmail versendet werden sollen, dann gibt es zwei Möglichkeiten, wie das organisiert werden kann. Entweder verschickt sendmail die Mails direkt an die angegebenen Adressen, oder alle Mail wird an einen sogenannten Smarthost weitergeleitet, der sich dann um das weitere Versenden kümmert. Die meisten Internet-Provider stellen einen solchen SMTP-Server für ihre Kunden zur Verfügung.

Die Versendung ohne Smarthost bedingt eine funktionierende DNS-Installation, da sendmail sowohl die Adressen der ausgehenden Mails auflösen muß, als auch von den Empfänger-Rechnern wieder angesprochen werden muß.

Wird stattdessen aber ein Smarthost angegeben, so sendet sendmail alle ausgehende Mail an diesen Rechner, der dann natürlich die selben Ansprüche erfüllen muß, wie ein lokaler Rechner, der keinen Smarthost verwendet, er muß eine funktionierende DNS-Anbindung haben.

Der Eintrag für den Smarthost findet in der zentralen Konfigurationsdatei von sendmail statt, die Datei /etc/sendmail.cf. Hier muß die Einstellung

DSRechnername

eingetragen sein. Soll stattdessen kein solcher Rechner verwendet werden, so wird der Parameter Rechnername einfach weggelassen.

DS

Die Dateien in /etc/mail
Das Verzeichnis /etc/mail enthält verschiedene Dateien, die Einstellungen für sendmail ermöglichen. Die meisten davon existieren in zwei Formaten. Zum einen existiert eine einfache Textdatei, in der wir die Einstellungen vornehmen können, zum anderen eine Datei, die den selben Namen, aber die Endung .db trägt. Sie enthält die Informationen, die sendmail selbst verarbeitet. Nach jeder Änderung einer der Textdateien ist es notwendig, diese Datei in das Datenbankformat (.db) zu konvertieren. Dazu wird folgender Befehl eingegeben:

makemap hash -f /etc/mail/datei.db < /etc/mail/datei

Statt datei wird natürlich der Name der zu konvertierenden Datei angegeben.
/etc/mail/access
Diese Datei regelt den Zugriff auf den Mailserver. Also die Frage, welcher Rechner darf ausgehende Mail an diesen Server schicken, damit er sie weiterleitet. Ein paar Beispiele:

127 RELAY
192.168.100.123 OK
mydomain.de OK

Alle Rechner, deren Adresse mit 127 anfangen (das sind nur wir selbst) senden ihre Mail grundsätzlich (RELAY) über diesen Rechner. Der Rechner 192.168.100.123 darf jederzeit Aufträge an diesen Rechner weitergeben und alle Mitglieder der Domain mydomain.de ebenfalls. Sonst werden alle Aufträge zur Weiterleitung abgelehnt.

Wie oben erwähnt muß diese Datei nach jeder Veränderung in das Datenbankformat konvertiert werden.

/etc/mail/genericstable
Diese Datei dient der Übersetzung ausgehender E-Mail Adressen in weltweit gültige. Bin ich z.B. auf dem Server der Systemverwalter, so lautet meine E-Mail Adresse intern z.B. root@server.local. Würde meine ausgehende Mail nun diese Adresse als Absender tragen, bekäme ich wohl nie eine Antwort. Denn mit root@server.local kann im Internet niemand etwas anfangen. Dort gilt meine Adresse echter.name@echter.provider.org. In der Datei genericstable stehen jetzt Umrechnungstabellen für solche Fälle:

root echter.name@echter.provider.org
root@server.local echter.name@echter.provider.org
hans hMueller@gmx.de
hans@server.local hMueller@gmx.de

Auch diese Datei muß nach einer Veränderung in das Datenbankformat gebracht werden.

/etc/mail/mailertable
Hier werden bekannte Rechner genannt, samt den Methoden, mit denen Mail an sie verschickt wird. Dabei können auch Tricks angewandt werden, wie etwa der Domainname, der an einen bestimmten Rechner weitergeleitet wird:

marvin.local.de smtp:marvin.local.de
hal.local.de smtp:hal.local.de
golem.local.de smtp:golem.local.de
local.de smtp:marvin.local.de

Alle Aufträge an bestimmte Rechner (marvin, hal und golem) gehen an die Rechner selbst via smtp. Alle Adressen, die keinen Rechner sondern nur eine Domain nennen (z.B. hans@local.de) werden an marvin weitergeschickt.

Auch diese Datei muß nach einer Veränderung in das Datenbankformat gebracht werden.

/etc/mail/virtusertable
Hier werden – ähnlich wie bei aliases – zwei verschiedene Adressen miteinander verknüpft. Dabei darf allerdings über Domaingrenzen gegangen werden, so daß – sollte ein Rechner mehrere Domains verwalten – hier Umleitungen zur jeweils passenden Adresse vorgenommen werden können.

efka@local.de root@golem.local.de

Die Adresse efka@local.de wird in Wahrheit an root@golem.local.de weitergegeben.

Auch diese Datei muß nach einer Veränderung in das Datenbankformat gebracht werden.

Allgemein

1.113.1 – inetd, xinetd und verwandte Diensten

Schreibe einen Kommentar

zurück zu Linux Zertifizierungen LPIC
1.113.1 – Konfiguration und Verwaltung von inetd, xinetd und verwandten Diensten
Prüfungskandidaten sollten in der Lage sein, die über inetd verfügbaren Dienste zu konfigurieren, tcpwrappers für das Erlauben oder Verweigern von Diensten auf Host-Ebene zu verwenden, Internetdienste manuell zu starten, stoppen und neu zu starten und grundlegende Netzwerkdienste einschließlich Telnet und FTP zu konfigurieren. Ebenfalls enthalten ist das Ausführen von Diensten unter einer anderen als der voreingestellten Benutzerkennung in inetd.conf.

Die wichtigsten Dateien, Bezeichnungen und Anwendungen:

* /etc/inetd.conf
* /etc/hosts.allow
* /etc/hosts.deny
* /etc/services
* /etc/xinetd.conf
* /etc/xinetd.log

Der inetd-Superserver
Bei der großen Anzahl von möglichen Servern, die auf einem Rechner laufen müssten, damit alle Internetdienste immer bereit sind, wäre es schnell soweit, daß der Speicher mit untätigen Servern überfüllt wäre. Damit das vermieden wird, gibt es einen “Superserver”, der alle möglichen Portnummern abhört und bei Anfrage einen entsprechenden Server startet. Damit kann es ermöglicht werden, daß nur die Server laufen, die gerade arbeiten, obwohl alle Dienste verfügbar sind.

Der zuständige Daemon heißt inetd und wird in der Datei /etc/inetd.conf konfiguriert. Der Aufbau dieser Datei ist verhältnismäßig einfach, meist sind alle notwendigen Einträge schon vorhanden. Sie müssen nur jeweils auskommentiert werden, wenn sie nicht erwünscht sind. Das Format der Datei ist folgendermaßen organisiert:

Dienstname Socket-Typ Transportprotokoll Flags User Programm Argumente

Die Felder haben folgende Bedeutung:

Dienstname
Hier steht der Name eines Dienstes, so, wie er in der Datei /etc/services eingetragen ist. Die ganze folgende Zeile bezieht sich darauf, daß ein Client versucht, auf dem Port zuzugreifen, der in /etc/services unter diesem Namen genannt ist.
Socket-Typ
Gültige Werte für den Socket-Typ sind stream, dgram, raw, rdm und seqpacket, wobei in der Praxis meist nur die ersten beiden eine Rolle spielen. Über den Daumen gepeilt kann behauptet werden, daß jedes Programm, daß als Transportprotokoll TCP benutzt, hier ein stream eingetragen hat, jedes, das mit UDP arbeitet hat hier ein dgram benutzt.
Transportprotokoll
Das hier eingetragene Transportprotokoll muß eins der in /etc/protocols angegebenen Protokolle sein. In der Regel spielen hier nur tcp und udp eine Rolle.
Flags
An dieser Stelle gibt es nur zwei gültige Einträge, wait und nowait. Die Unterscheidung spielt nur für UDP-basierte Anwendungen eine Rolle. Alle anderen sollten hier ein nowait eingetragen haben. Wenn ein Datagram-Server (ein Server, der mit UDP arbeitet) nach der Versendung eines Datagrams den benutzten Socket löscht, so daß inetd weitere Anfragen auf diesem Socket empfangen kann, dann spricht man von einem multi-threaded Server und sollte hier nowait benutzen. Datagram-Server, die alle eingehenden Datagramme über einen Socket empfangen und letztendlich mit einem TimeOut reagieren, werden single-threaded genannt und benötigen hier den Wert wait. Typische Vertreter dieses Typs sind die biff und talkd Daemonen.

Optional kann diesem Eintrag noch ein Maximalwert mitgegeben werden, der angibt, wieviele dieser Server maximal innerhalb von 60 Sekunden gestartet werden dürfen. Dieser Wert wird durch einen Punkt getrennt an wait oder nowait angehängt. Seine Voreinstellung ist 40.
User
Der User-Eintrag legt fest, unter welcher UserID das Serverprogramm laufen soll. Nachdem inetd selbst unter der UserID 0 läuft, kann hier verhindert werden, daß bestimmte Dienste auch unter dieser gefährlichen UID laufen. Optional kann diesem Eintrag ein durch Punkt vom Usernamen getrennter Gruppennamen folgen, der entsprechend die GID setzt.
Programm
Hier wird das Programm angegeben, das gestartet werden soll, wenn eine auf diesen Eintrag passende Anfrage eingeht. Es wird der komplette Pfad und Programmname angegeben. Wenn inetd diesen Dienst selbstständig anbietet, so steht hier internal.
Argumente
Die Argumente (Kommandozeilenoptionen) für das zu startende Programm. Normalerweise wird der Programmname selbst (Argument 0) mit angegeben. Auch hier wird das Wort internal angegeben oder der Eintrag wird leer gelassen, wenn inetd den Dienst intern zur Verfügung stellt.

So bedeutet die folgende Zeile also:

ftp stream tcp nowait root /usr/sbin/in.ftpd in.ftpd

Wenn eine Nachfrage nach dem Service ftp ankommt, (über den Sockettyp stream, mit dem Protokoll TCP) wird unter der UserID root das Programm /usr/sbin/in.ftpd ohne weitere Parameter gestartet und mit der Anfrage verbunden.

Die nötigen Portnummern bezieht inetd aus der Datei /etc/services .

Der inetd ließt diese Konfigurationsdatei nur beim Start. Wenn also Veränderungen daran vorgenommen wurden, so muß entweder der inetd neu gestartet werden, oder ihm muß ein HUP-Signal geschickt werden. Dieses Signal zwingt ihn, seine Konfigurationsdatei neu einzulesen.
Der TCP-Daemon (tcpwrapper)
Neben dem oben gezeigten Beispiel gibt es noch eine spezielle Form des Aufrufs über den inetd. In der Datei inetd.conf finden sich oft auch Zeilen wie die folgenden:

klogin stream tcp nowait root /usr/sbin/tcpd rlogind -k
eklogin stream tcp nowait root /usr/sbin/tcpd rlogind -k -x
kshell stream tcp nowait root /usr/sbin/tcpd rshd -k

Hier scheint auf den ersten Blick immer das gleiche Programm aufgerufen zu werden, nämlich /usr/sbin/tcpd. Erst als dessen Parameter kommen die eigentlichen Server an die Reihe. In der Tat ist es so, daß hier der TCP-Daemon (tcpd) aufgerufen wird, der dann erst die Server aufruft. Das klingt auf den ersten Blick unsinnig, aber es ermöglicht eine Einstellung, wer diesen Service benutzen darf.

Der tcpd überprüft anhand der Dateien /etc/hosts.allow und /etc/hosts.deny ob der jeweilige Host überhaupt berechtigt ist, diesen Dienst in Anspruch zu nehmen. Eine genaue Darstellung dieser Technik:

TCP-Wrapper

Ursprünglich alleine für die Verwendung mit inetd gedacht, hat sich das Prinzip des TCP-Wrappers inzwischen auch für Stand-Alone-Dienste wie ssh durchgesetzt. Worum geht es?

Wenn ein bestimmter Dienst aufgerufen wird, so kann er – anstatt direkt aufgerufen zu werden – durch das Programm tcpd aufgerufen werden. Dazu wird einfach statt dem zu startenden Dienst der tcpd aufgerufen und ihm wird der Name des zu startenden Dienstes als Parameter mitgegeben. Das Programm tcpd überprüft jetzt anhand von Einträgen in den Dateien

* /etc/hosts.allow
* /etc/hosts.deny

ob der Dienst von dem entsprechenden Host in Anspruch genommen werden darf. Analog überprüfen auch Stand-Alone-Dienste diese beiden Dateien.

Die Überprüfung erfolgt auf eine etwas eigenwillige Weise:

* Existiert ein passender Eintrag in der Datei /etc/hosts.allow, so wird Zugriff gegeben. Wenn nicht, dann
* Existiert ein passender Eintrag in der Datei /etc/hosts.deny, so wird kein Zugriff gegeben. Wenn nicht, dann
* wird Zugriff gegeben.

Die klassische Form der TCP-Wrapper

Das Format beider Dateien ist in der Handbuchseite hosts_access(5) genauestens dargestellt, es handelt sich um Zeilen des Formats:

Serverliste : Clientliste [: Shellkommando]

* Serverliste ist eine Liste von Servern (Programmnamen), oder Wildcards. Server werden mit ihrem Programmnamen – nicht über ihr Protokoll – angegeben, also z.B.: in.telnetd
* Clientliste ist eine Liste von einem oder mehreren Hostnamen, IP-Adressen, Suchmustern oder Wildcards,
* Shellkommando ist ein Kommando, das die lokale Shell ausführt, wenn der Dienst angefordert wurde und der Eintrag ausschlaggebend für seine Ausführung oder Nichtausführung war. Damit kann etwa eine Warnmeldung an root gegeben werden, wenn jemand versucht auf einen verbotenen Service zuzugreifen.

Als Suchmuster kommen zwei einfache Verfahren in Frage:

1. Beginnt ein Suchmuster mit einem Punkt (z.B. .foo.bar), so gelten alle Hostnamen als Treffer, deren Ende mit dem Muster übereinstimmt also etwa hal.foo.bar
2. Endet ein Suchmuster mit einem Punkt (z.B. 192.168.200.), so gelten alle Namen und Adressen als Treffer, deren erster Teil mit dem Muster übereinstimmt.

Als Wildcards können unter anderem folgende Werte verwendet werden:

ALL
Die universelle Wildcard, alles gilt…
LOCAL
Alle Hostnamen ohne Punkt (also lokale Namen) gelten.
UNKNOWN
Passt auf alle Usernamen, die unbekannt sind und alle Hosts, deren Namen oder Adressen nicht bekannt sind. Wird gerne in /etc/hosts.deny verwendet.
KNOWN
Passt auf alle Hosts und User, die bekannt sind
EXEPT
Ist ein Operator, um zwei Listen auszuschließen (Liste1 EXEPT Liste2) also etwa ALL EXEPT UNKNOWN

Das Shellkommando sollte grundsätzlich mit einem & beendet werden, weil sonst auf seine vollständige Abarbeitung gewartet wird, bevor ein Service evt. gestartet wird. Je nach Kommando kann das natürlich dauern…

Als zusätzliche Platzhalter in Shellkommandos können folgende Konstrukte verwendet werden:

%a
Die IP-Adresse des anfordernden Hosts
%A
Die IP-Adresse des aufgerufenen Servers
%c
Clientinformationen – User@Host oder User@IP-Adresse oder nur IP-Adresse des Anrufers, je nach dem, wieviel Informationen zur Verfügung stehen.
%d
Der Name des Daemon-Prozesses, der angefordert wurde.
%h
Name (oder falls nicht vorhanden IP-Adresse) des Clients
%H
Name (oder falls nicht vorhanden IP-Adresse) des Servers
%p
Die ProzessID des Daemon-Prozesses
%s
Serverinformationen – Daemon@Hostname oder Daemon@Adresse oder nur Daemon, je nach dem, wieviel Informationen zur Verfügung stehen.
%u
Der Username des Anrufers oder “unknown”
%%
Das %-Zeichen

Die modernere Form der Wrapper

Moderne Systeme arbeiten heute zwar immer noch mit dem dargestellten Prinzip, bieten aber auch die Möglichkeit, alle Einstellungen in nur einer der beiden Dateien vorzunehmen. Statt der Handbuchseite hosts_access(5) wird diese Methode in hosts_options(5) beschrieben. Der Aufbau der beiden Dateien sieht jetzt folgendermaßen aus:

Serverliste : Clientliste [: Option ] [: Option …]

Statt einem Shellkommando können also Optionen angegeben werden. Die wichtigsten Optionen sind:

ALLOW
Erlaubt den angegebenen Dienst für die angegebenen Clients.
DENY
Verbietet den angegebenen Dienst für die angegebenen Clients.
spawn Shellkommando
Führt das angegebene Shellkommando aus. Wie in der klassischen Form werden die oben beschriebenen Ersetzungen vorgenommen.
twist Shellkommando
Führt das angegebene Shellkommando aus und schickt seine Ausgaben an den Client, anstatt den gewünschten Dienst zu starten. Wie in der klassischen Form werden die oben beschriebenen Ersetzungen vorgenommen.
user Username[.Gruppe]
Startet den angegebenen Dienst unter der angegebenen User (und optional Gruppen) ID.

Der Vorteil dieser Methode liegt darin, daß alle Einstellungen in einer Datei vorgenommen werden können. Da die Optionen ALLOW und DENY zur Verfügung stehen, können in /etc/hosts.allow auch Verbote ausgesprochen werden und umgekehrt.

Aber Achtung: Es gilt immer noch die oben angegebene Reihenfolge. Es nützt also nichts, einem Host etwas zu erlauben, ohne allen anderen es zu verbieten. Die Einträge werden der Reihe nach gelesen und der erste passende wird benutzt. Um also nur dem Rechner marvin.foo.bar zu erlauben, den FTP-Daemon zu benutzen, müssten wir schreiben:

in.ftpd : marvin.foo.bar : ALLOW
in.ftpd : ALL : DENY

Wenn der Rechner marvin.foo.bar jetzt den Dienst anfordert, greift die erste Zeile und der Zugriff wird gewährt. Versucht aber ein anderer Rechner den Zugriff, so greift die erste Zeile nicht, dafür aber die zweite – der Zugriff wird verwehrt.

Der xinetd-Server
Der Server xinetd ist ein sicherer Ersatz für inetd. Er bietet eine eingebaute Zugriffskontrolle und eine direkte Unterstützung der Dateien /etc/hosts.allow und /etc/hosts.deny ohne den Umweg über tcpd. Außerdem werden noch viele weitere Verbesserungen angeboten wie etwa

* Beschränkung der Verbindungen entweder generell, oder pro Dienst oder pro Client.
* Beschränkung von Verbindungen anhand der Tageszeit.
* Dienste können an bestimmte IP-Adressen gebunden werden, so daß z.B. interne Clients andere Server-Programme nutzen als externe Clients, obwohl sie den selben Dienst aufgerufen haben.
* Schutz vor denial of service Angriffen.
* Ausgiebige Log-Möglichkeiten (auch unabhängig von syslogd).
* Umleitung von TCP-Verbindungen zu einem anderen Rechner, der selbst nicht von außen erreichbar sein muß. Damit können Server hinter einem Masquerading-Server auch von außen benutzt werden.
* Volle Unterstützung von IPv6.
* Interaktion mit dem User des Clients (Meldungen bei erfolgtem oder gescheitertem Zugriff).

Die Konfiguration des xinetd erfolgt analog zu seinem Vorgänger in der Datei /etc/xinetd.conf. Allerdings hat diese Datei einen vollkommen anderen Aufbau als /etc/inetd.conf. Für UmsteigerInnen gibt es ein spezielles Shellscript, das eine bestehende inetd.conf Datei in das neue Format konvertiert. Dieses Programm ist ein Perl-Script (xconv.pl) und wird mit xinetd mitgeliefert.

Die Konfigurationsdatei von xinetd beginnt mit einem Abschnitt für die Voreinstellungen, der default section. Die hier angegebenen Attribute werden von jedem Dienst genutzt, den xinetd verwaltet. Nach diesem Abschnitt folgen für jeden einzelnen zu startenden Dienst ein eigener Abschnitt. Wenn in einem solchen dienstspezifischen Abschnitt Angaben gemacht werden, die denen der default section widersprechen, so gelten die des dienstspezifischen Abschnitts.

Die typische Form einer default section ist folgendermaßen aufgebaut:

defaults
{
Attribut Operator Wert(e)
…
}

Alle weiteren Abschnitte beginnen mit dem Schlüsselwort service, dem der Name des Dienstes (wie er in /etc/services eingetragen ist) folgt.

service Dienstname
{
Attribut Operator Wert(e)
…
}

Es gibt drei unterschiedliche Operatoren, mit denen Attribute mit Werten versehen werden:

=
Setzt einen Wert für ein Attribut.
+=
Fügt einem Attribut einen Wert zu den bereits bestehenden Werten hinzu.
-=
Entfernt einem Attribut den angegebenen Wert.

Es existieren sehr viele möglichen Attribute, deren Beschreibung den Rahmen hier sprengen würde. Ein Beispiel für eine solche Datei sagt hier mehr als eine endlose Beschreibung:

defaults
{
instances = 15
log_type = FILE /var/log/xinetd.log
log_on_success = HOST PID USERID DURATION EXIT
log_on_failure = HOST USERID RECORD
only_from = 192.0.0.0/8

disabled = shell login exec comsat
disabled += telnet ftp
disabled += name uucp tftp
disabled += finger systat netstat
}

service ftp
{
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.ftpd
server_args = -l
instances = 4
access_times = 7:00-12:30 13:30-21:00
nice = 10
only_from = 192.168.1.0/24
}

In der defaults-Section definieren wir hier das Attribut instances mit dem Wert 15. Das bedeutet, daß grundsätzlich nicht mehr als 15 Dienste gleichzeitig gestartet werden können. Später in der Definition des FTP-Dienstes setzen wir den Wert 4 für dieses Attribut. In diesem Fall bezieht es sich auf die Menge der gleichzeitigen FTP-Verbindungen.

Die Angabe log_type = FILE /var/log/xinetd.log bestimmen wir, daß nicht der syslogd benutzt werden soll, sondern xinetd direkt in die angegebene Datei schreibt. Anstatt diesem Eintrag wäre auch folgender möglich gewesen:

log_type = SYSLOG daemon info

Dann wären alle Meldungen über den Syslog-Daemon geschrieben worden und zwar mit der Herkunft daemon und der Priorität info.

Die beiden Angaben log_on_success und log_on_failure legen fest, was alles in das Logbuch aufgenommen werden soll, wenn ein Zugriff erfolgreich war oder abgelehnt wurde.

Die Angabe only_from = 192.0.0.0/8 bestimmt, daß grundsätzlich (wenn beim entsprechenden Dienst nichts anderes angegeben wurde) nur die Rechner Zugriff haben, die auf die angegebene Adresse passen. Das /8 bestimmt, daß nur die ersten 8 Bit der Adresse gewertet werden. In unserem Beispiel werden also alle Rechner Zugriff bekommen, deren erstes Adressenbyte 192 ist.

Die folgenden Zeilen der default section schalten die angegebenen Dienste mit dem Attribut disabled komplett ab.

Im Abschnitt FTP werden jetzt die einzelnen Attribute für den Dienst gesetzt. Die ersten vier Einträge entsprechen dem, was auch in der alten inetd Konfiguration eingetragen war. Interessant sind hier noch die Angaben über die erlaubten Tageszeiten, in denen der Dienst zur Verfügung steht und der gesetzte NICE-Wert, unter dem der Daemon laufen soll. Zugreifen dürfen nur Rechner, deren Adresse mit 192.168.1 beginnt.

Eine Liste aller Attribute und ihrer Bedeutungen sind auf der Handbuchseite von xinetd.conf(5) zu finden. Eine genaue Beschreibung der Formate der Logdateien sind in der Handbuchseite xinetd.log(5) nachlesbar.

Allgemein

1.113 – Netzwerkdienste

Ein Kommentar

zurück zu Linux Zertifizierungen LPIC
Linux wird in der Praxis hauptsächlich als Serversystem eingesetzt, also als System, das Netzwerkdienste zur Verfügung stellen soll. Grundlegende Dienste werden in den folgenden sechs Kapiteln behandelt. Auch für diesen Abschnitt gilt, dass eine weiterführende Behandlung im nächsten Prüfungslevel erfolgt.

1.113.1 Konfiguration und Verwaltug von inetd, xinetd und verwandten Diensten
1.113.2 Verwendung und allgemeine Konfiguration von Sendmail
1.113.3 Verwendung und allgemeine Konfiguration von Apache
1.113.4 Richtiges Verwalten von NFS, smb und nmb Dämonen
1.113.5 Einrichtung und Konfiguration grundlegender DNS-Dienste
1.113.6 Einrichten von Secure Shell (OpenSSH)

Allgemein

1.112.4 – Linux als PPP-Client

Schreibe einen Kommentar

zurück zu Linux Zertifizierungen LPIC
1.112.4 – Konfiguration von Linux als PPP-Client
Prüfungskandidaten sollten die Grundlagen des PPP-Protokols verstehen und in der Lage sein, PPP für ausgehende Verbindungen zu konfigurieren und zu verwenden. Dieses Lernziel beinhaltet die Beschreibung der Sequenz des Verbindungsaufbaus (bei gegebenem Login-Beispiel) und das Einrichten von automatisch bei Verbindungsaufbau auszuführenden Kommandos. Ebenfalls enthalten ist die Initialisierung und die Beendung einer PPP-Verbindung mittels Modem, ISDN oder ADSL und die Einstellung der automatischen Neuverbindung bei Verbindungsabbruch.

Die wichtigsten Dateien, Bezeichnungen und Anwendungen:

* /etc/ppp/options.*
* /etc/ppp/peers/*
* /etc/wvdial.conf
* /etc/ppp/ip-up
* /etc/ppp/ip-down
* wvdial
* pppd

Normalerweise werden IP-Verbindungen über Netzwerkkarten hergestellt. Die Protokolle von TCP/IP sind für den Umgang mit Netzwerken geschrieben, sie arbeiten z.B. mit den MAC-Adressen (ARP) und mit der Aufteilung eines Datenstroms in Pakete, wie es bei Netzen üblich ist.

Um zwei Computer statt über Netzwerkkarten über serielle Schnittstellen zu vernetzen, existieren mehrere Protokolle wie SLIP (Serial Line IP) und PPP (Point to Point Protocol). SLIP ist veraltet und wird nur noch sehr selten eingesetzt. Heute wird meist PPP benutzt.

Die wirkliche Aufgabenstellung von PPP ist es nicht, zwei alleinstehene Computer über eine serielle Leitung zu vernetzen. Heute sind Netzwerkkabel und -karten so billig, daß es sich nicht lohnen würde eine solche Art der Vernetzung zu realisieren. Zumal damit nur zwei Rechner vernetzt werden können, das System also nicht ohne weiteres erweiterbar ist. Die wirkliche Aufgabe von PPP ist es, Rechner über serielle Leitungen mit anderen Rechnern zu verbinden, die an ein tatsächliches Netz angeschlossen sind, so daß auch der einzelne Rechner Zugriff auf das echte Netz hat. In der Regel ist das echte Netz das Internet und die serielle Leitung ist eine Modem/ISDN/ADSL Verbindung zum Provider:

pic

Das PPP Protokoll ist ein spezielles Protokoll zur Realisierung einer IP-Verbindung über ein Medium, das nur zwei Kommunikationspartner verbindet. Also etwa serielle oder parallele Verbindungen. Spezielle Versionen von PPP sind für ISDN (syncPPP) oder für DSL (PPPoE) verfügbar, das klassische PPP ist typischerweise für Modemverbindungen gedacht.

Linux kann natürlich beide Rollen übernehmen, die der Workstation, die über PPP an einen Gateway angeschlossen wird (PPP-Client) oder die des Gateways, der eine PPP-Verbindung an ein echtes Netz knüpft (PPP-Server). Für die LPI102 Prüfung ist nur die Konfiguration eines PPP-Clients gefragt, diese Konfiguration wird im weiteren Verlauf dieses Abschnitts beschrieben.

Physikalischer Vorgang
Grundsätzlich ist der Vorgang des Aufbaus einer PPP-Verbindung in drei Teile aufzuteilen:

* Aufbau der Modemverbindung
* Loginvorgang
* Aufbau der PPP-Verbindung

Das heißt, zunächst einmal muß das Modem soweit gebracht werden, daß es eine Verbindung zu der bestimmten Nummer aufbaut. Das heißt das Modem muß initialisiert werden (ATZ) und die Initialisierung mit einem OK beantworten, anschließend muß die Nummer gewählt werden (ATD Nummer) und auf die Antwort CONNECT gewartet werden. Wenn diese Antwort empfangen wurde ist der erste Teil der Aufgabe erledigt. Damit haben wir eine bestehende serielle Verbindung zu dem anderen Rechner (Gateway). Auf dem Gateway hat das Modem abgenommen und ein normaler Login-Vorgang über getty wird jetzt gestartet. Das heißt, der Gateway schickt uns jetzt eine Meldung, die wahrscheinlich den Rechnernamen und das Wort login: beinhaltet. Diese Meldung wird von uns mit unserem Usernamen beantwortet. Daraufhin schickt der Gateway die Frage nach dem Passwort, die wir mit unserem Passwort beantworten. Wenn alles geklappt hat, ist der Login-Vorgang damit abgeschlossen.

Jetzt muß der eigentliche PPP-Daemon gestartet werden. Das muß auf beiden Seiten der Verbindung geschehen. Der Gateway hat den PPP-Daemon (pppd) als Startshell für den Usernamen eingetragen, er startet den Daemon also automatisch. Wir müssen den Daemon jetzt von Hand starten mit

pppd Schnittstelle Geschwindigkeit defaultroute

Die Schnittstelle ist dabei unsere serielle Schnittstelle, auf der das Modem hängt, die Geschwindigkeit ist meist 38400 (für moderne schnelle Modems) und die Option defaultroute sorgt dafür, daß die Verbindung zum Gateway als Default Route eingetragen wird. Der PPP-Daemon initialisiert jetzt die neu entstandene symbolische Netzschnittstelle ppp0 mit dem Programm ifconfig (mit einer dynamischen IP-Adresse, die er von der Gegenstelle bekommt) und legt die default route auf dieses Interface.

Jetzt besteht eine IP-Verbindung zu dem Garteway und unser Rechner hat Zugriff auf das hinter dem Gateway liegende Netz. PPP ist also jetzt aktiv.

Dieser Vorgang kann natürlich automatisiert werden und muß niemals von Hand ausgeführt werden. Diese Darstellung dient nur dazu, den Vorgang zu verstehen, der im nächsten Abschnitt beschrieben wird.

Automatischer Aufbau einer PPP-Verbindung mit chat
Damit der oben beschriebene Vorgang automatisiert werden kann, gibt es das Programm chat. Es dient dazu, eine Kommunikation mit dem Modem (oder jeden anderen seriellen Verbindung) zu automatisieren. chat erwartet seine Befehle aus einer Scriptdatei, die eine sehr einfache Struktur hat. Jede Zeile eines chat-scripts besteht aus einem Paar:

“Warte auf” “Sende”

Das heißt, chat wartet immer auf ein angegebenes Wort, das vom Modem kommt, und sendet nach dem Empfang dann das entsprechende Wort Sende. Nehmen wir ein Beispiel. Wir wollen eine Verbindung zu einem Gateway aufbauen, der die Telefonnummer 12345 hat. Unser Username auf diesem Gateway ist hans, unser Passwort ist 12sd45gf. Das entsprechende chat-Script würde also folgendermaßen aussehen:

” ATZ
OK ATD12345
CONNECT ”
ogin: hans
ssword: 12sd45gf

Das bedeutet, wir warten auf nichts und senden ein ATZ. Dadurch wird das Modem initialisiert. Das Modem antwortet mit einem OK. Sobald wir das OK empfangen haben, senden wir den Modembefehl ATD12345, der das Modem veranlasst, die Nummer 12345 anzuwählen. Sobald das gegenüberliegende Modem des Gateways abgenommen hat und die beiden Modems ihren Handshake beendet haben, antwortet unser Modem mit dem Wort CONNECT. Wenn wir das empfangen haben, schicken wir ein Return (”).

Jetzt wird der Gateway eine Loginaufforderung schicken. Wir wissen nicht, was genau er schickt, aber wir wissen, daß die Aufforderung mit den Buchstaben ogin: aufhört. Der Gateway könnte beispielsweise folgendes schicken:

Welcome to XYZ-Gateway
Login:

Es ist egal, was der Gateway sendet, sobald wir die Buchstaben ogin: empfangen, schicken wir wiederum den Usernamen hans. Der Gateway antwortet mit einer Aufforderung, ein Passwort einzugeben. Wir wissen nicht, ob er das groß oder klein schreibt, aber die letzten Buchstaben, die er schickt werden sicherlich ssword: sein. Sobald wir die empfangen haben, schicken wir das Passwort.

Mit diesem Befehl ist der Anmeldedialog abgeschlossen und die PPP-Verbindung wird aufgebaut.

Um den PPP-Daemon mit diesem Script zu starten, wird der Befehl

pppd “chat -f Scriptdatei” /dev/tty2 38400

eingegeben. Scriptdatei bezeichnet die Datei, die das oben besprochene Chat-Script enthält. Dadurch wird eine PPP-Verbindung automatisch aufgebaut. Der PPP-Daemon pppd wird aufgerufen und er erhält als ersten Parameter den Aufruf von Chat, mit der Scriptdatei. Die Angabe /dev/tty2 38400 bezieht sich auf die serielle Schnittstelle, an der das Modem hängt und die dort verwendete Geschwindigkeit.

Die zu verwendenden Optionen werden wir – statt sie auf der Kommandozeile einzugeben – in einer anderen Datei (/etc/ppp/options) angeben, dazu genaueres später.

Wenn der PPP-Daemon erfolgreich einen Verbindungsaufbau erledigt hat, so ruft er ein Shellscript mit Namen /etc/ppp/ip-up auf. Diesem Shellscript gibt er die folgenden Parameter mit:

ip-up Interfacename Gerätedate Geschwindigkeit Locale_IP Remote_IP

Dieses Script kann jetzt dazu verwendet werden, weitere Befehle auszuführen, die nach dem Verbindungsaufbau gewünscht werden, etwa Firewallregeln oder andere Kommandos. Beim Abbau einer Verbindung wird entsprechend das Script /etc/ppp/ip-down abgearbeitet, das wieder entsprechende Befehle beinhalten kann.

Automatischer Aufbau einer PPP-Verbindung mit wvdial
Die modernere Methode, mit der heute PPP-Verbindungen aufgebaut werden läuft über das Programm wvdial. Dieses Programm erledigt alle Aufgaben, von der Anwahl über das Modem, bis hin zum Start des PPP-Daemons. Es ersetzt das Chat-Programm und ermöglicht einen Login, ohne ein Script zu schreiben.

Wen wvdial startet, läd es zunächst seine Konfiguration aus der Datei /etc/wvdial.conf. Diese Datei enthält sowohl die Grundeinstellungen für die Schnittstelle, das Modem und die Geschwindigkeit, als auch Informationen über die anzuwählenden Provider (Telefonnummer, Username, Passwort).

Nachdem diese Datei gelesen wurde, initialisiert wvdial das Modem, wählt die entsprechende Nummer, authentifiziert den Login und startet den PPP-Daemon.

Die Konfigurationsdatei kann für verschiedene Provider Einträge besitzen. Sie ist aufgebaut wie eine Windows-INI Datei, also mit Sektionen, die durch Überschriften in eckigen Klammern begrenzt werden. Neben der Sektion [Dialer Defaults], die die Grundeinstellungen und einen voreingestellten Providereintrag enthält, kann es beliebig viele andere Einträge in der Form [Dialer Providername].

Wird wvdial ohne Parameter aufgerufen, so wählt es die Verbindung aus der Sektion [Dialer Defaults], wird es aber mit einem Parameter aufgerufen, der einen Provider beschreibt, so wird der entsprechende Einträge aus der Datei /etc/wvdial.conf benutzt. Der Aufruf

wvdial foo

benutzt also den Eintrag [Dialer foo] aus der Konfigurationsdatei.

Ein Beispiel für eine solche Datei könnte folgendermaßen aussehen:

[Dialer Defaults]
Modem = /dev/modem
Baud = 57600
Init1 = ATZ
Dial Command = ATDT
Idle Seconds = 180
Phone = 012345678
Username = foo
Password = bar

[Dialer provider1]
Phone = 0987654321
Username = hans
Password = asdf1234

[Dialer provider2]
Phone = 0918273645
Login Prompt = Weristda:
Username = hmueller
Password = 1082.oir

Im Abschnitt [Dialer Defaults] werden die entsprechenden Grundeinstellungen gemacht, die für alle anderen Abschnitte auch benutzt werden, wenn dort nichts anderes vereinbart ist. Jeder andere Abschnitt enthält dann noch die notwendigen Informationen über den anzurufenden Provider.

Wie beim Aufbau der Verbindung mit Chat, so wird auch hier beim Aufbau der PPP-Verbindung das Script /etc/ppp/ip-up abgearbeitet und beim Verbindungsabbau entsprechend /etc/ppp/ip-down.

Im Verzeichnis /etc/ppp/peers muß – bei Verwendung modernerer PPP-Daemonen – die Datei wvdial liegen, die ein paar Optionen für den PPP-Daemon enthält, die er benötigt, wenn er über wvdial gestartet wurde. In der Regel enthält diese Datei nur die Zeilen

noauth
name wvdial
replacedefaultroute

Falls andere Startprogramme verwendet werden, können sie auch in diesem Verzeichnis jeweils eine Datei besitzen, die die nötigen Optionen für sie setzen.

Die Datei /etc/ppp/options
Damit der PPP-Daemon nicht jedesmal mit viele Kommandozeilenoptionen aufgerufen werden muß, können die gewünschten Optionen in die Datei /etc/ppp/options eingetragen werden. Es ist sogar möglich, für jede Schnittstelle (/dev/ttyS1, /dev/modem,…) eine eigene solche Datei anzulegen, die dann entsprechend /etc/ppp/options.ttyS1 usw. heißen muß.

Diese Datei kennt viele verschiedenen Einträge, die wichtigsten sind hier kurz erklärt:

noipdefault
Der ppp-Client übernimmt nicht seine IP-Adresse aus /etc/hosts sondern bezieht seine Adresse vom Server. Diese Option sollte für normale Provider immer angegeben sein.
noauth
Keine automatische Authentifizierung. Das bedeutet, daß die normale Authentifizierung über das Chat-Script benutzt wird.
crtscts
Hardware-Flußkontrolle des Modems wird aktiviert.
lock
Lockdateien werden angelegt, um zu verhindern, daß ein anderer Prozeß das Modemgerät benützt, während wir online sind.
modem
Die Verbindung läuft über ein Modem. Das Gegenteil wäre local und wird nur angewandt, wenn zwei Rechner über ein Nullmodemkabel miteinander verbunden sind. Für eine Modemverbindung sollte immer modem gesetzt sein.
defaultroute
Die aufgebaute PPP-Verbindung wird als Default Route gesetzt.
persist
Nach einem Verbindungsabbruch wird nicht aufgelegt, sondern versucht, die Verbindung erneut aufzubauen.
maxfail N
Die Verbindung wird abgebrochen, wenn N mal die Verbindung durch einen Fehler abgebrochen wurde. Ein Wert von 0 schaltet dieses Feature ab.
idle N
Die Verbindung wird automatisch beendet, wenn mehr als N Sekunden keine Daten über sie gelaufen sind.

Zwingender Abbau einer PPP-Verbindung
Um eine PPP-Verbindung abzubrechen, muß einfach der PPP-Daemon per Signal INT gekillt werden. Da der Daemon seine ProzeßID immer in einer bestimmten Datei ablegt, kann diese Aufgabe automatisch durch ein Script erledigt werden. Die Datei, in die der Daemon seine PID ablegt ist normalerweise /var/run/interface.pid, wobei interface für die symbolische Schnittstelle (ppp0, ppp1, …) der Verbindung steht. Um also die Verbindung von ppp0 abzubrechen, kann der Befehl

kill -INT `cat /var/run/ppp0.pid`

ausgeführt werden. Natürlich kann dieser Befehl auch in einem Script verwendet werden.

Allgemein

1.112.3 – TCP/IP Konfiguration – Problemlösung

Schreibe einen Kommentar

zurück zu Linux Zertifizierungen LPIC
1.112.3 – TCP/IP Konfiguration und Problemlösung
Prüfungskandidaten sollten in der Lage sein, Konfigurationseinstellungen und den Status verschiedener Netzwerkschnittstellen anzusehen, zu ändern und zu überprüfen. Dieses Lernziel beinhaltet die manuelle und automatische Konfiguration von Schnittstellen und Routing-Tabellen. Dies bedeutet im speziellen das Hinzufügen, Starten, Stoppen, Neustarten, Löschen und Rekonfigurieren von Netzwerkschnittstellen. Dies beinhaltet auch das Ändern, Listen und Konfigurieren der Routing-Tabelle und die manuelle Korrektur einer falsch gesetzten Default-Route. Kandidaten sollten auch in der Lage sein, Linux als DHCP-Client und TCP/IP-Host zu konfigurieren und Probleme im Zusammenhang mit der Netzwerkkonfiguration zu lösen.

Die wichtigsten Dateien, Bezeichnungen und Anwendungen:

* /etc/HOSTNAME oder /etc/hostname
* /etc/hosts
* /etc/networks
* /etc/host.conf
* /etc/resolv.conf
* /etc/nsswitch.conf
* ifconfig
* route
* dhcpcd, dhcpclient, pump
* host
* hostname (domainname, dnsdomainname)
* netstat
* ping
* traceroute
* tcpdump
* die Netzwerk-Scripts, die während der Systeminitialisierung ausgeführt werden.

Netzwerkkonfiguration ist etwas, was im Normalbetrieb immer automatisch beim Systemstart abläuft. Init-Scripts übernehmen die Konfiguration der Schnittstellen, das Anlegen der Routen und vieles mehr. Trotzdem ist das Wissen um die manuelle Konfiguration wichtig, erstens für Problemlösungen und zweitens, weil damit auf die Schnelle auch eine Umkonfiguration von Netzwerkkarten oder ein experimenteller Aufbau möglich ist.

Notwendig ist also beides, das Wissen um die manuelle und automatische Konfiguration. Im Prinzip ist die zweite Frage kein großer Wurf mehr, wenn die erste beantwortet ist. Da die automatische Konfiguration die selben Befehle und Mechanismen einsetzt, wie die manuelle – nur eben in Scripts – sollte das Verständnis der automatischen Konfiguration kein Problem darstellen, wenn die Befehle aus der manuellen bekannt sind.

Manuelle Konfiguration von Netzwerkkarten
Die erste Grundvoraussetzung für die Konfiguration von Netzwerkschnittstellen ist, daß TCP/IP im Kernel aktiviert ist. Das ist eigentlich immer der Fall, selbst bei Rechnern, die nicht für Netze geplant waren, weil unter Linux viele lokale Dienste ohne diese Fähigkeit nicht funktionieren würden.

Die Darstellung der notwendigen Konfigurationsarbeiten wird sich jetzt auf “normale” Netzwerkkarten (Ethernet) beziehen, die Einstellungen für andere Netzwerkschnittstellen, seien es andere Kartentypen (Token Ring, FDDI, …) oder andere Schnittstellen wie ppp oder slip, werden mit den selben Befehlen vorgenommen.

Damit die Konfiguration einer Netzwerkkarte überhaupt funktionieren kann, muß der Kernel die Karte zuallererst mal erkannt haben. Das heißt, daß der Kernel die Unterstützung für eine bestimte Netzwerkkarte bereits fest eingebaut haben muß oder daß das entsprechende Modul geladen sein muß. Diese Technik wurde bereits im Abschnitt 1.105.1 besprochen. Wir gehen hier also davon aus, daß das Modul für die zu konfigurierende Netzwerkkarte bereits geladen ist.

Das IP-Protokoll definiert eine abstrakte Schnittstelle interface um auf verschiedene Hardware zugreifen zu können. Diese Schnittstellen bieten eine Reihe von standardisierten Operationen an, die alle mit Versand und Empfang von Daten zu tun haben. Durch das Laden von Gerätetreibern (Modulen) werden diese Schnittstellen mit physikalischen Geräten (Netzwerkkarten o.ä.) verbunden. Dadurch entstehen symbolische Schnittstellennamen wie eth0, eth1 für Ethernetkarten, tr0, tr1 für Token Ring Karten oder arc0, arc1 für Arcnet-Karten. Der lokale Loopback heißt lo. Selbst serielle Verbindungen ins Internet mit ppp oder slip haben dann Interfacenamen wie sl0, sl1 oder ppp0, ppp1.

Diese Zuweisung geschieht in der Regel schon beim Booten, es können bei einem modularen Kernelaufbau aber auch während der Laufzeit des Kernels noch Gerätetreiber geladen werden. Dann erfolgt natürlich auch die Zuweisung von symbolischen Namen erst während der Laufzeit.

Konfigurieren des Interfaces
Nachdem wir ein funktionsfähiges Interface haben, z.b. eth0 muß jetzt dafür gesorgt werden, daß dieser Schnittstelle eine IP-Adresse zugewiesen wird. In der Regel geschieht das natürlich automatisch, aber um zu sehen was in den Init-Scripts passiert, ist es wichtig, diese Schritte auch mal von Hand durchgeführt zu haben.

Zum Konfigurieren eines Interfaces gibt es das Programm ifconfig, das einem beliebigen Interface IP-Adresse, Netzmaske und Broadcast-Adresse zuweist. Die Anwendung ist erstmal simpel:

ifconfig lo 127.0.0.1
ifconfig eth0 192.168.200.55

Damit haben wir dem Interface lo, also dem lokalen Loopback die ihm zustehende Adresse 127.0.0.1 zugewiesen, die Ethernetkarte eth0 bekommt die Adresse 192.168.200.55. Besser wäre noch gewesen, gleich die Netmask und Broadcast-Adresse mit anzugeben, mit den Schlüsselwörtern netmask und broadcast ist das möglich:

ifconfig eth0 192.168.200.55 broadcast 192.168.200.255 netmask 255.255.255.0

Somit wäre unser Interface jetzt komplett konfiguriert. Das Programm ifconfig kann aber noch mehr. Wird es ohne Optionen aufgerufen, so zeigt es Informationen zu allen bestehenden aktiven Netzschnittstellen an. (mit der Option -a werden auch die Schnittstellen dargestellt, die down geschalten sind) Mit

ifconfig Interface

werden Informationen zum angegebenen Interface angezeigt. Neben der Informationsausgabe kann das Programm ifconfig noch folgende Optionen verarbeiten:

down
Schaltet ein Interface schlagartig aus. Es ist danach für den Kernel nicht mehr erreichbar. Vorsicht, bei alten Versionen von ifconfig werden Routing Einträge nicht mitgelöscht, es können also noch Routen existieren, denen kein Interface zugeordnet ist.
up
Schaltet ein abgeschaltetes Interface wieder ein.
pointopoint ADRESSE
für SLIP und PPP, beides Protokolle für serielle Verbindungen. Hier ist das Interface etwas anders zu steuern, weil ja sozusagen nur ein Netz aus zwei Rechnern (Point to Point) besteht.
metric NUMMER
Nur für RIP. RIP summiert alle anfallenden metric Werte einer Verbindung um daraus die Kosten zu errechnen (heute selten benutzt) und damit Routenwahl auch hinsichtlich der Kosten zu optimieren.
mtu BYTES
Maximum Transmission Unit – Größte Übertragungseinheit des verwendeten Netzprotokolls. Bei Ethernet (802.3) 1500, bei SLIP 296.
promisc
Schaltet ein Interface in den promiscuos mode in dem alle Pakete des Netzwerks, egal ob an diesen oder einen anderen Rechner geschickt, empfangen werden. Brauchbar zur Analyse des Netzverkehrs, der Fehlersuche, aber auch zum Abhören von Netzleitungen.

Alle diese Optionen werden nach der Nennung des Interfacenamens angehängt, z.B.

ifconfig eth0 metric 2 mtu 1024

Der Befehl ifconfig ist also sowohl zu Konfiguration eines Interfaces, als auch zur Diagnose ein wichtiges Hilfsmittel.

Erstellen der Routen
Nachdem die Interfaces konfiguriert worden sind, müssen noch die Routing-Tables (Routen-Tabellen) erstellt werden. Das geschieht mit dem Programm route. Die Tabelle existiert nicht als Datei, sondern wird im Kernelspeicher verwaltet. Das heißt, der Aufruf von route muß also bei jedem Start erfolgen.

Die heutigen modernen Versionen von ifconfig erledigen bereits das Anlegen der Route ins eigene Netz sobald eine Schnittstelle mit einer IP-Adresse versehen wird. Diese Aufgabe musste bei älteren Systemen auch mit dem Befehl route erledigt werden.

Wird route ohne Parameter (oder nur mit -n) aufgerufen, so zeigt es den aktuellen Routing-Table an. (-n zeigt Adressen immer nummerisch, auch wenn Hostnamen bekannt sind)

Ansonsten muß route immer entweder mit dem Schlüsselwort add oder del versehen werden. add steht für das Hinzufügen einer Route, del für das Löschen einer Route.

route add [-net | -host] XXXX [gw GGGG]
[metric MMMM] [netmask NNNN] [dev DDDD]

oder

route del XXXX

Dabei stehen XXXX für die Route (Netz- oder Hostadresse), GGGG für die Adresse eines Gateways, MMMM für einen numerischen Wert, der als metric-Wert benutzt werden soll, NNNN für eine Netzmaskierung und DDDD für ein TCP/IP Interface wie etwa eth0.

Für einen einfachen Rechner in einem lokalen Netz würde also der folgende Eintrag genügen:

route add -net 192.168.200.0

Damit wäre eine Route definiert, die alle Pakete, die ans Netz 192.169.200.0 gerichtet sind an die Ethernetkarte schickt. Das weiß das System, weil die Ethernetkarte ja die Adresse 192.168.200.55 hat, also die gleiche Netzadresse. Dieser Befehl ist bei modernen Versionen von ifconfig unnötig geworden, weil diese Route eben automatisch bei der Konfiguration angelegt wird.

Nehmen wir an, in unserem Netz ist ein Gateway (z.B. 192.168.200.77) ans Internet angeschlossen. Wir brauchen jetzt also zwei Routen, eine ins lokale Netz und einen an den Gateway. An diesen schicken wir alle Pakete, die nicht fürs lokale Netz gedacht sind.

route add -net 192.168.200.0
route add default gw 192.168.200.77

Alle Pakete, die wir losschicken und die nicht für das lokale Netz bestimmt sind, werden jetzt direkt an den Gateway 192.168.200.77 geschickt. Das Schlüsselwort default kann auch mit -net 0.0.0.0 ausgetauscht werden, der schon bekannten Adresse der default route.

Auch in diesem Beispiel ist die erste Zeile bei modernen ifconfig Versionen unnötig.

Jetzt bleibt nur noch die Frage, wie die Routing-Tables eines Gateways konfiguriert werden müssen. Nehmen wir an, der Gateway 192.168.200.77 hat eine FDDI-Karte und hängt direkt am Rechner des Providers. Der Provider hat eine eigene Netzadresse für sein FDDI-Netz. Nehmen wir an, die Provider-Netzadresse ist 192.100.200.0 Der Rechner des Providers (192.100.200.1) leitet alle Pakete ans eigentliche Internet weiter. Das heißt, er dient als nächster Gateway ins Internet. Unser Gateway hat eine FDDI-Karte (Interface fddi0) mit der Adresse 192.100.200.7.

pic

Also müssen wir in unserem Gateway drei Routen konfigurieren. Eine ins lokale Netz, eine ins FDDI-Netz (beide werden wieder automatisch durch ifconfig angelegt und sind hier nur für ein besseres Verständnis angegeben) und eine Default-Route zum Providergateway. Selbstverständlich müssen hier auch beide Interfaces richtig konfiguriert sein:

ifconfig eth0 192.168.200.77 broadcast 192.168.200.255 netmask 255.255.255.0
ifconfig fddi0 192.100.200.7 broadcast 192.100.200.255 netmask 255.255.255.0
route add -net 192.168.200.0
route add -net 192.100.200.0
route add default 192.100.200.1

Der Gateway hat jetzt also zwei statische Routen in die jeweiligen Netze, die er verbindet (das geht selbstverständlich auch mit zwei Ethernetkarten) und eine Default Route, die wiederum auf den Gateway des Providers verweist. Wenn jetzt ein beliebiger Rechner in unserem lokalen Netz ein Paket an eine gänzlich unbekannte Adresse schickt (etwa 123.45.67.89) dann wird sie (weil es keine feste Route dorthin gibt) über die Default-Route geschickt. Diese ist mit unserem Gateway verbunden. Der hat auch keine feste Route zu 123.45.67.89, schickt das Paket wiederum auf seine Default Route, die mit dem Gateway des Providers verbunden ist. Der gibt das Paket seinerseits ans Internet weiter.

Das Programm route ist – wie schon ifconfig in der Praxis ein wichtiges Hilfsmittel zur Diagnose. Nachdem die Routen in der Regel beim Starten des Rechners automatisch gesetzt werden, ist die Anwendung zu Diagnosezwecken sehr viel häufiger, als die manuelle Erstellung von Routen.

Das Programm netstat
Dieses Programm gibt Informationen über den Status bestimmter Netzverbindungen zurück. Interessant sind folgende Möglichkeiten:

netstat -r oder -rn Wie route oder route -n Die angezeigten Flags haben folgende Bedeutung:

* G Route ist Gateway
* U Interface ist UP
* H Nur ein Host kann über die Route erreicht werden (PPP/SLIP/loopback)
* D Route wurde von ICMP eingetragen
* M Route wurde von ICMP verbessert (modified)

netstat -i Gibt die Statistik der Interfaces an, Flags haben folgende Bedeutung:

* B Broadcast ist gesetzt
* L ist Loopback
* M promiscous mode – Alle Pakete werden empfangen
* O ARP ist ausgeschaltet
* P Point to Point Verbindung
* R Running
* U Up

netstat -t, -u, -w, -x, -a zeigt die aktiven Sockets für TCP, UDP, RawIP, Unix oder Alle.

Automatische Konfiguration über Init-Scripts
All die oben erwähnten Befehle müssen natürlich nicht jedesmal von Hand eingegeben werden, wenn ein Linuxrechner startet. Sie werden von entsprechenden Init-Scripts gestartet, sobald in einen Runlevel gewechselt wird, der das Netzwerk aktivieren soll.

Die unterschiedlichen Distributionen gehen hier denkbar unterschiedliche Wege. Gemeinsam ist ihnen, daß die Einstellungen für die Netzwerkkarten (Adressen und Routen) in bestimmten Dateien (unter /etc) eingetragen werden, die dann von einem entsprechenden Init-Script (z.B. /etc/init.d/networking) ausgelesen werden. Das Init-Script startet dann die Befehle ifconfig und route mit den gefundenen Werten aus den Dateien.

Eine weitere Vereinfachung ist mit den Programmen ifup und ifdown möglich. Beide Programme sind Frontends für ifconfig und route. Im Verzeichnis /etc/network erwarten diese Programme eine Datei mit Namen interfaces, die Informationen über die benutzten Netzwerkschnittstellen beinhalten. In dieser Datei steht beispielsweise:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.100.123
netmask 255.255.255.0
network 192.168.100.0
broadcast 192.168.100.255
gateway 192.168.100.20

Mit dieser Information kann ifup dann entsprechend die Netzwerkschnittstellen mit Adressen versehen und die notwendige Route zum Gateway (default route) setzen.

Einsatz eines DHCP-Servers
Wenn im Netz ein DHCP-Server läuft, dann ist die gesamte Konfiguration der Netzwerkkarten nicht mehr nötig. Ein solcher Server hält alle notwendigen Informationen bereit, die ein Rechner benötigt, um seine Netzwerkkarte zu konfigurieren. Beim Hochfahren des Systems wird ein Broadcast ins Netz gesendet, um einen DHCP-Server zu finden. Der Server antwortet daraufhin mit einem Paket, das alle notwendigen Angaben zur Konfiguration beinhaltet.

Die Prüfungsziele für LPI102 beinhalten nicht die Installation eines DHCP-Servers, sondern nur die Anbindung eines Rechners an einen bestehenden Server.

Es gibt unterschiedliche Programme, die einen Linux-Rechner zum DHCP-Client machen. Die bekanntesten sind

* dhcpcd
Der DHCP-Client-Daemon. Er arbeitet vollkommen selbstständig und durchsucht das Netz nach einem DHCP-Server. Anschließend weisst er jeder gefundenen Netzwerkschnittstelle eine entsprechende IP-Adresse zu.
* dhclient
Auch dieses Programm arbeitet als Daemon, es bezieht seine Informationen, welche Interfaces über DHCP konfiguriert werden sollen aus der Konfigurationsdatei /etc/dhclient.conf.
* pump
Auch pump ist ein Daemon, der Netzwerkinterfaces über DHCP konfiguriert. Er kann aber auch als Alternative mit dem bootp Protokoll arbeiten, das eine ähliche Aufgabenstellung wie DHCP besitzt, allerdings auch das Booten plattenloser Workstations unterstützt. pump bezieht seine Konfigurationsinformationen aus der Datei /etc/pump.conf.

Jeder dieser Daemonen wird über ein Init-Script beim Systemstart gebootet und bleibt die ganze Zeit im Speicher. Das ist notwendig, weil DHCP-Server in regelmäßigen Abständen überprüfen, ob ein Rechner noch aktiv ist, um gegebenenfalls eine wieder frei gewordene Adresse neu vergeben zu können.

Konfigurationsdateien für Netzwerke
Neben den Init-Scripts und anderer Netzwerk-relevanten Einstellungen, die von Distribution zu Distribution unterschiedlich sind, gibt es eine Reihe Konfigurationsdateien, die allen Linux-Versionen (und auch allen anderen Unixen) gemeinsam sind. Diese Dateien werden hier jetzt der Reihe nach besprochen.

/etc/HOSTNAME oder /etc/hostname
Diese Datei enthält den Hostnamen des Rechners. Beim Systemstart wird ein Init-Script ausgeführt, das diese Datei ließt und den entsprechenden Namen darin als Hostnamen setzt. Das dazu verwendete Programm heißt ebenfalls hostname und ermöglicht es auch, im laufenden Betrieb den Hostnamen zu erfragen (ohne weitere Parameter) oder ihn zu verändern.

Das Programm hostname gibt als Ausgabe nur den Hostnamen, ohne Domainnamen an. Soll der volle Name (full qualified domain name) angegeben werden, so muß hostname mit der Option –fqdn aufgerufen werden. Der Domainname alleine kann mit dem Befehl dnsdomainname erfragt werden. Dieser Befehl ist aber nicht in der Lage den Domainnamen zu verändern, da es stark von der Organisation des Netzes abhängt, wo dieser Domainname eingestellt ist. Der Befehl domainname gibt statt der echten DNS-Domain den Namen der NIS-Domain an.

/etc/hosts
Die Datei /etc/hosts enthält IP-Adressen und die dazu passenden Hostnamen. Überall, wo eigentlich IP-Adressen erwartet werden, können stattdessen auch Hostnamen angegeben werden, wenn diese in der Datei /etc/hosts angegeben sind. Die Datei ist also – übertragen gemeint – eine Art Mini-Nameserver für das lokale Netz. Der Aufbau ist einfach, jede Zeile enthält zuerst eine IP-Adresse, dann den dazu passenden Namen und eventuelle Aliase auf diesen Namen.

192.168.100.1 marvin.mydomain.com marvin

bedeutet also, daß immer, wenn der Name marvin.mydomain.com oder der Name marvin verwendet wird, dieser Name durch die Adresse 192.168.100.1 ersetzt wird.

/etc/networks
Die Datei /etc/networks entspricht der Datei /etc/hosts, mit dem Unterschied, daß hier nicht Hostnamen, sondern Netzwerknamen verwendet werden. Diese Netzwerknamen werden mit Netzwerkadressen verbunden.

Im Unterschied zu /etc/hosts werden in dieser Datei zuerst die Namen und dann die Adressen angegeben. Eventuelle Aliase werden nach der Adresse angegeben:

buero1 192.168.1.0
buero2 192.168.2.0 meinnetz
backbone 192.168.100.0

Die angegebenen Adressen müssen Netzwerkadressen sein, also alle Bits des Hostadressenteils auf 0 gesetzt haben.

/etc/host.conf
Die Auflösung von Hostnamen zu IP-Adressen wird von einer speziellen Library erledigt (resolv+). Diese Library ist es auch, die entsprechend Nameserver und die Datei /etc/hosts abfrägt, wenn statt einer IP-Adresse ein symbolischer Name gefunden wurde.

Die Datei /etc/host.conf ist die Konfigurationsdatei für diese Bibliothek. Die wichtigste Aufgabe dieser Datei ist es, die Suchreihenfolge festzulegen, in der Namen in IP-Adressen aufgelöst werden. Entweder wird zuerst der Nameserver gefragt, und dann die Datei /etc/hots, oder umgekehrt. Diese Einstellung wird über die Zeile

order hosts,bind

erledigt. Das Beispiel gibt an, daß zuerst die Datei /etc/hosts und erst dann der Nameserver (bind) gefragt werden soll. Ist umgekehrt gewünscht, daß zuerst der Nameserver gefragt wird, so hieße die Zeile

order bind,hosts

Weitere Parameter sind:

multi
Gültige Werte sind on und off. Wenn on gesetzt ist, liefert die Resolverbibliothek alle für den gesuchten Host gültigen Adressen aus /etc/hosts zurück, anstatt nur den ersten gefundenen Eintrag. Der Standardwert für diesen Parameter ist off, da seine Verwendung auf Installationen mit sehr großer /etc/hosts zu Performanceproblemen führen kann.
nospoof
Gültige Werte sind on und off. Wenn dieser Parameter auf on gesetzt ist, versucht die Resolverbibliothek, das Spoofing von Hostnamen zu unterbinden, um die Sicherheit von rlogin und rsh zu verbessern. Nachdem für einen Hostnamen die Adresse gefunden wurde, wird geprüft, ob für diese Adresse auch genau dieser Hostname gefunden werden kann. Liegt keine eindeutige Zuordnung vor, schlägt die Namensauflösung fehl.
spoofalert
Wenn dieser Parameter auf on gesetzt und gleichzeitig nospoof aktiv ist, protokolliert die Resolverbibliothek Fehler im Zusammenhang mit dem Spoofing-Schutz an Syslog. Der Standardwert hierfür ist off.

Zumeist enthält diese Datei nur zwei Zeilen, die die Reihenfolge definieren und das multi auf on setzen.

/etc/resolv.conf
Diese Datei wird auch von der Resolver-Library ausgelesen. Die wichtigste Aufgabe ist die Angabe der verwendeten Nameserver. Es können hier bis zu drei verschiedene Nameserver angegeben werden, die dann in der Reihenfolge der Angaben befragt werden, wenn ein DNS-Lookup stattfindet.

Der hierfür verwendete Befehl lautet

nameserver IP-Adresse

Dieser Befehl kann bis zu dreimal in der Datei auftauchen.

Ein weiterer Befehl für die vernünftige Arbeit mit dem Resolver ist

search Domain-Name

Hier wird die lokale Domain (ohne Hostnamen) angegeben, um Namen, die ohne Domainnamen angegeben wurden, als lokale Namen festzulegen. Genauer gesagt, werden alle Rechnernamen (mit oder ohne Domainnamen) zunächst einmal mit dieser Endung versehen, die dort angegeben wurde. Erst wenn ein Rechner nicht mit der Endung gefunden wurde, wird nach einem Rechner ohne diese Endung gesucht.

Normalerweise enthält die Datei /etc/resolv.conf nur diese beiden Einträge.

/etc/nsswitch.conf
Verschiedene Funktionen der C-Standard-Library müssen anhand verschiedener Konfigurationsdateien konfiguriert werden. Traditionell wird das z.B. mit Dateien wie /etc/passwd erledigt. Später wurden dann zusätzliche Dienste eingeführt, die auch bestimmte Informationen anbieten, wie etwa NIS/YP, das auch Informationen über Usernamen und UIDs bereitstellen kann, nur eben netzweit und nicht nur lokal. Um festzulegen, welche dieser Dienste in welcher Reihenfolge verwendet werden sollen, existiert die Datei /etc/nsswitch.conf. Ihr Mechanismus ist in etwa zu vergleichen mit der Angabe der Reihenfolge in der Datei /etc/host.conf, nur daß sie sich nicht nur auf Namensauflösung, sondern auf alle verwendeten Konfigurationsmöglichkeiten bezieht.

Konkret werden die folgenden Datenbanken von /etc/nsswitch.conf verwaltet (in Klammern immer die normalerweise verwendeten Konfigurationsdateien):

aliases
Mail-Aliases von sendmail (/etc/aliases).
ethers
Ethernet-Adressen
group
User-Gruppen (/etc/group).
hosts
Hostnamen und Adressen (/etc/hosts).
netgroup
Netzweite Listen von Usern und Hosts, die für Bestimmungen von Zugriffsrechten wichtig sind.
network
Netzwerknamen und -adressen (/etc/networks).
passwd
User-Passwörter und andere Informationen (/etc/passwd).
protocols
Netzwerkprotokolle (/etc/protocols).
publickey
Public- und Secret-Keys für Secure_RPC
rpc
Remote Procedure Call Namen und Portnummern (/etc/rpc).
services
Portnummern von Netzwerkdiensten (/etc/services).
shadow
Shadow-Passwörter (/etc/shadow).

In der Datei kann jetzt für jede dieser Datenbanken die Suchreihenfolge angegeben werden, ob zuerst über NIS, dann über die Dateien (files) oder umgekehrt gesucht werden soll.

Troubleshooting mit tcpdump
Wenn Probleme in einem Netz auftauchen, so kann mit Hilfe des Programms tcpdump jedes einzelne Paket des Netzes protokolliert und analysiert werden. Dazu wird die Netzwerkkarte in den promisquous-mode geschaltet, das heißt, sie gibt jedes Paket, auch wenn es nicht die eigene Mac-Adresse hat, an die Vermittlungsschicht weiter.

tcpdump zeigt jetzt die empfangenen Paket-Header an und ermöglicht so eine Diagnose der aufgetretenen Fehler. Die Anwendung ist ziemlich kompliziert und würde den Rahmen dieser Darstellung sprengen. Es genügt, zu wissen, daß es dieses Programm gibt und daß es folgendermaßen aufgerufen wird.

tcpdump -i Interface

Damit werden alle Pakete des genannten Interfaces abgehört. Das Interface wird mit seinem symbolischen Namen angegeben, also beispielsweise eth0.

tcpdump hat eine eigene Art Abfragesprache, die Befehle ermöglicht wie

tcpdump host foo

Zeigt nur Pakete an den oder vom Rechner foo.

tcpdump host foo and bar

Zeigt nur Pakete, die zwischen den Rechnern foo und bar ausgetauscht werden.

Andere Programme
Die in der Liste für dieses Prüfungsziel erwähnten Programme host, ping und traceroute wurden bereits im Abschnitt 1.112.1 besprochen.