Kapitel 9 Fehlersuche bei Netzwerkproblemen (Aufgaben)

Dieses Kapitel enthält Lösungen für allgemeine Probleme, die in Ihrem Netzwerk auftreten könnten. Es umfasst die folgenden Themen:

• Allgemeine Tipps zur Fehlersuche bei Netzwerkproblemen

• Allgemeine Probleme bei der Bereitstellung von IPv6

Neuerungen in diesem Kapitel

Unter Solaris 10 7/07 wird die Datei /etc/inet/ipnodes nicht mehr benötigt. Verwenden Sie /etc/inet/ipnodes nur für frühere Oracle Solaris 10-Versionen, wie es in den jeweiligen Verfahren beschrieben wird.

Allgemeine Tipps zur Fehlersuche bei Netzwerkproblemen

Das erste Anzeichen eines Problems in einem Netzwerk ist, wenn mit einem oder mehreren Hosts kein Datenaustausch durchgeführt werden kann. Wenn ein Host nach dem Hinzufügen zu einem Netzwerk nicht online geschaltet werden kann, könnte der Fehler in einer der Konfigurationsdateien liegen. Möglich wäre aber auch eine fehlerhafte Netzwerkschnittstellenkarte. Wenn ein einzelner Host unvermittelt ein Problem erzeugt, könnte die Netzwerkschnittstelle die Ursache sein. Können die Hosts in einem Netzwerk zwar untereinander, aber nicht mit anderen Netzwerken kommunizieren, ist vermutlich der Router die Fehlerursache. Möglich wäre auch, dass das Problem in dem anderen Netzwerk liegt.

Mit dem Befehl ifconfig können Sie Informationen zu den Netzwerkschnittstellen abrufen. Der Befehl netstat eignet sich zum Anzeigen von Routing-Tabellen und Protokollstatistiken. Auch Netzwerk-Diagnoseprogramme von Drittanbietern enthalten Tools zur Fehlersuche. Weitere Informationen finden Sie in der Dokumentation der Drittanbieter.

Weniger offensichtlich sind die Ursachen von Problemen, die zu einer Leistungsverschlechterung im Netzwerk führen. Mit Tools wie ping können Sie Probleme wie den Verlust von Paketen durch einen Host feststellen.

Durchführen allgemeiner Diagnoseprüfungen

Bei Problemen im Netzwerk können Sie verschiedene Softwareprüfungen durchführen, um allgemeine Software-bezogene Probleme zu diagnostizieren und zu korrigieren.

So führen Sie eine allgemeine Prüfung der Netzwerksoftware durch

1. Nehmen Sie auf dem lokalen System die Rolle eines Netzwerkmanagers an, oder melden Sie sich als Superuser an.

   Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Configuring RBAC (Task Map) in System Administration Guide: Security Services.

2. Zeigen Sie die Netzwerkinformationen mit dem Befehl netstat an.

   Informationen zur Syntax des Befehls netstat finden Sie unter Überwachen des Netzwerkstatus mit dem Befehl netstat und in der Manpage netstat(1M).

3. Überprüfen·Sie die hosts-Datenbank (und, unter Solaris 10 11/06 und früheren Releases, die ipnodes-Datenbank, wenn Sie IPv6 verwenden) um sicherzustellen, dass die Einträge korrekt und auf dem neuesten Stand sind.

   Informationen zur /etc/inet/hosts-Datenbank finden Sie unter hosts-Datenbank und in der Manpage hosts(4) Informationen zur /etc/inet/ipnodes-Datenbank finden Sie unter ipnodes-Datenbank und in der Manpage ipnodes(4).

4. Wenn Sie das Reverse Address Resolution Protocol (RARP) ausführen, zeigen Sie die Ethernet-Adressen in der ethers-Datenbank an, um sicherzustellen, dass die Einträge korrekt und auf dem neuesten Stand sind.

5. Versuchen Sie, mit dem Befehl telnet eine Verbindung zum lokalen Host herzustellen.

   Informationen zur Syntax des Befehls telnet finden Sie in der Manpage telnet(1).

6. Stellen Sie sicher, dass der Netzwerk-Daemon inetd ausgeführt wird.

   # ps -ef | grep inetd

   Die folgende Ausgabe bestätigt, dass der inetd-Daemon ausgeführt wird:

   root 57 1 0 Apr 04 ? 3:19 /usr/sbin/inetd -s

7. Falls IPv6 in Ihrem Netzwerk aktiviert ist, prüfen Sie, ob der IPv6-Daemon in.ndpd ausgeführt wird:

   # ps -ef | grep in.ndpd

   Die folgende Ausgabe bestätigt, dass der in.ndpd-Daemon ausgeführt wird:

   root 123 1 0 Oct 27 ? 0:03 /usr/lib/inet/in.ndpd

Allgemeine Probleme bei der Bereitstellung von IPv6

In diesem Abschnitt werden die Fehler und Probleme beschrieben, die bei der Planung und Bereitstellung von IPv6 an Ihrem Standort auftreten könnten. Eine Liste der Planungsaufgaben finden Sie in Kapitel 4Planen eines IPv6-Netzwerks (Aufgaben).

IPv4-Router kann nicht auf IPv6 aufgerüstet werden

Falls Ihre bestehende Ausrüstung nicht aufgerüstet werden kann, müssen Sie eventuell eine IPv6-konforme Ausrüstung erwerben. Suchen Sie in der Dokumentation des Herstellers nach Verfahren, die Sie zur Unterstützung von IPv6 ausführen müssen.

Bestimmte IPv4-Router können nicht zur Unterstützung von IPv6 aufgerüstet werden. Falls dies auf Ihre Topologie zutrifft, verbinden Sie einen IPv6-Router mit einem IPv4-Router. Dann können Sie einen Tunnel vom IPv6-Router über den IPv4-Router konfigurieren. Informationen zu den Aufgaben beim Konfigurieren von Tunneln finden Sie unter Aufgaben bei der Konfiguration von Tunneln zur Unterstützung von IPv6 (Übersicht der Schritte).

Probleme beim Aufrüsten von Services auf IPv6

Bei der Vorbereitung von Services zur Unterstützung von IPv6 tritt eventuell Folgendes auf:

• Einige Anwendungen aktivieren standardmäßig keine IPv6-Unterstützung, auch dann nicht, nachdem sie zu IPv6 portiert wurden. Eventuell müssen Sie diese Anwendungen konfigurieren, um IPv6 zu aktivieren.

• Auf einem Server, der mehrere Services ausführt, von denen einige ausschließlich IPv4-konform sind, andere sowohl IPv4 als auch IPv6 unterstützen, könnten Probleme auftreten. Einige Clients müssen beide Servicetypen unterstützen, was zu Fehlern auf dem Server führen kann.

Der aktuelle ISP unterstützt IPv6 nicht

Wenn Sie IPv6 bereitstellen möchten, Ihr aktueller ISP jedoch keine IPv6-Adressierung anbietet, sind neben dem ISP-Wechsel folgende Alternativen möglich:

• Beauftragen Sie einen ISP, eine zweite Leitung für IPv6-Kommunikationen von Ihrem Standort bereitzustellen. Diese Lösung ist kostenintensiv.

• Konfigurieren Sie einen virtuellen ISP. Ein virtueller ISP bietet Ihrem Standort IPv6-Konnektivität ohne einen Link. Stattdessen erstellen Sie einen Tunnel von Ihrem Standort über Ihren IPv4-ISP zum virtuellen ISP.

• Verwenden Sie einen 6to4-Tunnel über Ihren ISP zu anderen IPv6-Standorten. Bei der Adresse verwenden Sie die registrierte IPv4-Adresse des 6to4-Routers als öffentliche Topologiekomponente der IPv6-Adresse.

Sicherheitsbetrachtungen beim Tunneling zu einem 6to4-Relay-Router

Grundsätzlich ist ein Tunnel zwischen einem 6to4-Router und einem 6to4-Relay-Router unsicher. Sicherheitsprobleme wie die Folgenden tauchen bei Tunneln immer auf:

• Obwohl 6to4-Relay-Router Pakete einkapseln und entkapseln, prüfen dem Router keine der in den Paketen enthaltenen Daten.

• Adressen-Spoofing ist ein wesentliches Problem bei Tunneln zu einem 6to4-Relay-Router. Bei eingehenden Verkehr ist der 6to4-Router nicht in der Lage, die IPv4-Adresse des Relay-Routers mit der IPv6-Adresse der Quelle in Einklang zu bringen. Aus diesem Grund kann für die Adresse des IPv6-Hosts leicht ein Spoofing durchgeführt werden. Auch die Adresse des 6to4-Relay-Routers bietet ein Spoofing-Ziel.

• Standardmäßig existieren keine Vertrauensmechanismen zwischen 6to4-Routern und 6to4-Relay-Routern. Aus diesem Grund kann ein 6to4-Router nicht feststellen, ob der 6to4-Relay-Router vertrauenswürdig ist und ob es sich überhaupt um einen legitimen 6to4-Relay-Router handelt. Es muss eine vertrauenswürdige Beziehung zwischen 6to4-Standort und IPv6-Ziel bestehen, oder beide Standorte sind möglichen Angriffen offen ausgesetzt.

Diese und andere Sicherheitsprobleme im Zusammenhang mit 6to4-Relay-Routern sind im Internet Draft, Security Considerations for 6to4 beschrieben. Allgemein sollten Sie die Unterstützung für 6to4-Relay-Router nur aus den folgenden Gründen aktivieren:

• Jeder 6to4-Standort muss mit einem privaten, vertrauenswürdigen IPv6-Netzwerk kommunizieren. Beispielsweise können Sie die Unterstützung eines 6to4-Relay-Routers in einem Universitätsnetzwerk aktivieren, das aus isolierten 6to4-Standorten und nativen IPv6-Standorten besteht.

• Ihr 6to4-Standort muss aus zwingenden geschäftlichen Gründen mit bestimmten nativen IPv6-Hosts kommunizieren.

• Sie haben die Prüfungs- und Vertrauensmodelle implementiert, die in der Internet Draft Security Considerations for 6to4 vorgeschlagen werden.

Bekannte Probleme bei einem 6to4-Router

Die folgenden bekannten Programmfehler wirken sich auf die 6to4-Konfiguration aus:

• 4709338 – RIPng-Implementierung erforderlich, die statische Routen erkennt

• 4152864 – Konfiguration zweier Tunnel mit dem gleichen tsrc/tdst-Paar ist möglich

Implementierung statischer Routen an einem 6to4-Standort (Bug-ID 4709338)

Das folgende Problem tritt bei 6to4-Standorten mit Routern auf, die sich innerhalb des 6to4-Grenzrouters befinden. Wenn Sie die 6to4-Pseudoschnittstelle konfigurieren, wird die statische Route 2002::/16 automatisch zur Routing-Tabelle auf dem 6to4-Router hinzugefügt. Bug 4709338 beschreibt eine Einschränkung des Oracle Solaris RIPng-Routing-Protokolls, das verhindert, dass diese statische Route am 6to4-Standort bekannt gegeben wird.

Eine der folgenden Problemumgehungen ist für Bug 4709338 möglich.

• Fügen Sie die statische Route 2002::/16 den Routing-Tabellen aller Intrasite-Router am 6to4-Standort hinzu.

• Verwenden Sie ein anderes Protokoll als RIPng auf dem internen Router des 6to4-Standorts.

Konfiguration von Tunneln mit der gleichen Quelladresse (Bug-ID 4152864)

Bug-ID 4152864 beschreibt Probleme, die auftreten, wenn zwei Tunnel mit der gleichen Tunnel-Quelladresse konfiguriert wurden. Dies ist ein schwerwiegendes Problem bei 6to4-Tunneln.

Konfigurieren Sie einen 6to4-Tunnel und einen automatischen Tunnel (atun) nicht mit der gleichen Tunnel-Quelladresse. Informationen zu automatischen Tunneln und dem Befehl atun finden Sie in der Manpage tun(7M).