1.112.3 – TCP/IP Konfiguration – Problemlösung

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.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert