Skip to content

15 Linux im Netz

15 Linux im Netz

Lernziele

  • Einen Überblick über Netzwerk-Konzepte haben * Anforderungen dafür verstehen, einen Linux-Rechner in ein lokales Netz zu integrieren

  • Wichtige Kommandos zur Fehlersuche kennen

  • Wichtige Netzwerkdienste kennen

Vorkenntnisse

  • Umgang mit Dateien (Kapitel 6) und mit einem Texteditor

  • Kenntnisse über die Linux-Dateisystemstruktur (Kapitel 10)

  • Vorkenntnisse im TCP/IP-Bereich und Kenntnisse im Umgang mit Netzwerkdiensten sind nützlich

15.1 Netzwerk-Grundlagen

15.1.1 Einführung und Protokolle

Erst im 21. Jahrhundert machen Computer richtig Spaß, wenn sie ans Internet angeschlossen sind – in Firmen meist über ein unternehmensweites „lokales Netz“, daheim über einen DSL-Router oder unterwegs über eine Funkverbindung (WLAN oder Mobilfunk). Es gibt diverse Methoden, um ins Netz zu kommen, aber unabhängig davon, wie Ihr Rechner im Netz ist, funktioniert das Internet selbst immer gleich.

Grundlage des Internets ist eine „Protokollfamilie“ namens „TCP/IP“. Ein Protokoll ist eine Vereinbarung darüber, wie sich Rechner miteinander unterhalten. Es kann alles abdecken – von bestimmten elektrischen, optischen oder Funksignalen bis hin zu Anfragen und Antworten an einen Web-Server –, aber nicht alles gleichzeitig. Man kann grob zwischen drei Arten von Protokollen unterscheiden:

  1. Übertragungsprotokolle regeln den Datenverkehr auf der Ebene von Netzwerkkarten und Kabeln (etwas salopp gesagt). Dazu gehören beispielsweise Ethernet (fürs LAN) oder WLAN-Protokolle wie IEEE 802.11.

  2. Kommunikationsprotokolle regeln die Kommunikation zwischen Rechnern in verschiedenen Netzen. Wenn Sie von Deutschland aus auf eine Webseite in Australien zugreifen, sorgen die Kommunikationsprotokolle IP und TCP dafür, dass die Datenbytes, die Sie hier losschicken, in Australien ankommen und umgekehrt.

  3. Anwendungsprotokolle sorgen dafür, dass der Empfänger Ihrer Datenbytes in Australien mit diesen tatsächlich etwas anfangen kann. Das Web-Anwendungsprotokoll HTTP erlaubt es Ihnen beispielsweise, ein Bild eines Koalabären abzurufen. Der Server in Australien interpretiert Ihre Anfrage und schickt Ihnen das Bild des Koalabären (und nicht das eines Kängurus). Ihr Webbrowser kann erkennen, dass Sie ein Bild und keine Fehlermeldung erhalten haben.

💡 Diese schichtweise Organisation hat den großen Vorteil, dass jede Schicht nur mit der darüber und der darunter liegenden Schicht verkehren muss. So muss das Anwendungsprotokoll HTTP beispielsweise nicht wissen, wie Bytes von Deutschland nach Australien gelangen (zum Glück!), denn diese Aufgabe wird an das Kommunikationsprotokoll delegiert. Dieses wiederum überlässt die tatsächliche Übertragung der Bytes dem Übertragungsprotokoll.

💡 Klassischerweise wird an dieser Stelle auf das ISO/OSI-Referenzmodell verwiesen, das zur Organisation eines Rechnernetzes nicht weniger als sieben Schichten vorsieht. Wir ersparen Ihnen das hier aber im Interesse der Kürze.

Die Anwendungsprotokolle in TCP/IP – außer HTTP etwa SMTP (für E-Mail), SSH (für interaktive Sitzungen auf entfernten Rechnern), DNS (für die Auflösung von Rechnernamen) oder SIP (für Internet-Telefonie) – verwenden normalerweise eines von zwei Kommunikationsprotokollen: UDP oder TCP. Während UDP einen verbindungslosen, unzuverlässigen Dienst realisiert (das heißt, Daten können bei der Übertragung verlorengehen oder in einer anderen Reihenfolge ankommen, als sie abgeschickt wurden), stellt TCP einen verbindungsorientierten, zuverlässigen Dienst zur Verfügung (die Daten kommen also am anderen Ende vollständig und in der richtigen Reihenfolge an).

💡 Welches Kommunikationsprotokoll günstiger ist, hängt von der Anwendung ab. Im Web möchten Sie normalerweise nicht, dass bei der Übertragung Daten verloren gehen (es könnte ein Stück Text, ein Bild oder ein heruntergeladener Programmcode fehlen, was zu ärgerlichen bis katastrophalen Ergebnissen führen kann), also ist TCP die richtige Wahl. Bei Fernsehen oder Telefonie übers Internet können Sie dagegen wahrscheinlich eher mit kurzen Aussetzern leben (ein pixeliges Bild oder ein kurzes Rauschen in der Leitung), als dass alles für eine halbe Minute komplett zum Stehen kommt, während das System ein verlorengegangenes Datenpaket neu anfordert. An dieser Stelle ist UDP besser geeignet. UDP eignet sich auch besser für Dienste wie DNS, bei denen kurze Anfragen sehr schnell kurze Antworten liefern sollen.

💡 Das dritte Kommunikationsprotokoll in TCP/IP, ICMP, dient zur Steuerung und Fehlersuche und wird von Benutzerprogrammen normalerweise nicht direkt verwendet.

15.1.2 Adressierung und Routing

Damit jeder Rechner im Internet gezielt angesprochen werden kann, bekommt er eine eindeutige Adresse, die sogenannte „IP-Adresse“. Ihr Rechner schickt einem bestimmten Server eine Anfrage und die Antwort auf diese Anfrage muss ja auch wieder genau zu Ihrem Rechner zurückfinden. Im aktuell noch weiter verbreiteten Standard IPv4 ist das eine Kombination aus vier Oktetten, also Zahlen von 0 bis 255, zum Beispiel 192.168.178.10.

Ihre IP-Adresse können Sie sich nicht einfach aussuchen, sondern sie wird Ihnen zugewiesen. In einer Firma erledigt das der System- oder Netzwerkadministrator, für Ihren Internetanschluss daheim ist das Ihr Internetanbieter.

💡 In der Firma kriegen Sie mit einiger Wahrscheinlichkeit immer dieselbe IP-Adresse. Ihr Internetanbieter wird Ihnen dagegen eine IP-Adresse immer nur für eine bestimmte Zeit „leihen“; beim nächsten Mal bekommen Sie dann eine andere. Das soll dem Anbieter einerseits ermöglichen, weniger Adressen zu benutzen, als er Kunden hat (denn nicht jeder Kunde ist permanent online), und Sie andererseits davon abhalten, Serverdienste anzubieten, für die eine ständig wechselnde IP-Adresse eine Behinderung darstellt.

💡 Die IP-Adressen selbst fallen nicht einfach so vom Himmel, sondern werden – soweit möglich – mit System vergeben, um die Weiterleitung von Daten zwischen verschiedenen Netzen, das sogenannte „Routing“, zu vereinfachen. Dazu gleich mehr.

Rechner haben normalerweise mehr als eine IP-Adresse. Die „Loopback-Adresse“ 127.0.0.1 steht auf jedem Rechner für den Rechner selbst und ist auch von außen nicht zugänglich. Ein Dienst, der auf dieser Adresse angeboten wird, kann deshalb nur von Clients auf dem Rechner selbst angesprochen werden.

💡 Das mag absurd und nutzlos klingen, ist aber durchaus sinnvoll: Sie könnten beispielsweise an der Entwicklung einer Webseite arbeiten, die E-Mails an Benutzer verschicken können muss (etwa mit Aktivierungslinks für Benutzerkonten). Um das auf Ihrem Entwicklungsrechner zu testen, können Sie einen lokalen Mailserver installieren, der nur auf der Loopback-Adresse E-Mails annimmt. Für Ihr Projekt reicht das auf jeden Fall aus und Sie laufen keine Gefahr, von irgendwo aus dem Internet mit Spam überschüttet zu werden.

Bei Rechnern mit Ethernet- oder WLAN-Verbindung hat die betreffende Schnittstelle natürlich auch eine IP-Adresse, zumindest wenn der Rechner aktuell im Netz ist. Außerdem spricht nichts dagegen, den Netzwerkschnittstellen für Testzwecke oder besondere Konfigurationen weitere Adressen zuzuordnen.

Die Herausforderung besteht darin, dafür zu sorgen, dass irgendein beliebiger Rechner A im Internet mit irgendeinem beliebigen anderen Rechner B kommunizieren kann, solange er nur die IP-Adresse von B kennt. (Wenn A in Deutschland und B in Australien steht, ist nicht offensichtlich, wie die Bytes von A zu B gelangen sollen.) Das Zauberwort, das dies möglich macht, ist „Routing”. Und das funktioniert ungefähr so:

  • Ihr Rechner A kann die IP-Adresse von Rechner B herausfinden (dazu ist das DNS da). Vielleicht ist sie 10.11.12.13.

  • Rechner A kann feststellen, dass die IP-Adresse 10.11.12.13 nicht im selben lokalen Netz ist wie seine eigene (was nicht überraschend ist, da Rechner B sich in Australien befindet). Das heißt, Rechner A kann keine Daten direkt an Rechner B schicken.

  • Die Netzwerkkonfiguration von Rechner A enthält eine „Default-Route”, d. h. ein Rezept dafür, wie Rechner A mit Daten umgehen soll, die er nicht direkt zustellen kann. Diese Standardroute kann zum Beispiel wie folgt aussehen: „Schicke alles, was du nicht direkt zustellen kannst, an Rechner C“. Den Rechner C nennt man auch „Default-Gateway”.

    • Auch Rechner B – vielleicht Ihr DSL-Router – kann die Daten nicht direkt zustellen. Dafür weiß er aber, was er mit Daten machen soll, die nicht für ihn gedacht sind, nämlich sie an Ihren Internet-Anbieter weiterzuleiten.
  • Dieses Spiel geht möglicherweise noch über ein paar Ebenen so weiter, bis Ihre Daten auf einem Rechner landen, der weiß, dass Daten, die an 10.11.𝑥.𝑦 adressiert sind, an den australischen Internetanbieter Billabong-Net geschickt werden sollen. Sie werden also dorthin geleitet.

  • Billabong-Net weiß hoffentlich, wie eingehende Pakete an 10.11.12.13 an ihr endgültiges Ziel geleitet werden müssen. Der tatsächliche Rechner B steht vielleicht bei einem Kunden von Billabong-Net oder bei einem Kunden dieses Kunden. Wenn alles richtig konfiguriert ist, funktioniert das.

  • Allfällige Antworten von B an A nehmen prinzipiell den umgekehrten Weg.

Die wichtige Beobachtung an dieser Stelle ist, dass sich der tatsächliche Weg der Daten von Rechner A zu Rechner B erst während der Zustellung ergibt. Rechner A muss keine genaue Streckenführung vorgeben, sondern verlässt sich darauf, dass jede Station unterwegs das Richtige tut. Umgekehrt kommt jeder Rechner mit „lokalem” Wissen aus und muss nicht für das komplette Internet wissen, was wo ist – was ohnehin unmöglich wäre.

💡 Eine der Eigenschaften von IP als Kommunikationsprotokoll ist, dass das Routing sich grundsätzlich von Paket zu Paket ändern kann (auch wenn das in der Regel nicht passiert). Dadurch kann das Internet flexibel auf Engpässe oder Ausfälle von Verbindungen reagieren.

💡 Im Prinzip ist das ähnlich wie bei der „gelben Post”. Sie müssen schließlich auch nicht wissen, welchen genauen Weg Ihre Geburtstagskarte für Tante Susi in Sydney nimmt, sondern Sie stecken nur den korrekt freigemachten Umschlag in den Briefkasten Ihres freundlichen Nachbarn.

  • Auch Rechner B – vielleicht Ihr DSL-Router – kann die Daten nicht direkt zustellen. Dafür weiß er aber, was er mit Daten machen soll, die nicht für ihn gedacht sind, nämlich sie an Ihren Internet-Anbieter weiterzuleiten.

  • Dieses Spiel geht möglicherweise noch über ein paar Ebenen so weiter, bis Ihre Daten auf einem Rechner landen, der weiß, dass Daten, die an 10.11.𝑥.𝑦 adressiert sind, an den australischen Internetanbieter Billabong-Net geschickt werden sollen. Sie werden also dorthin geleitet.

  • Billabong-Net weiß hoffentlich, wie eingehende Pakete an 10.11.12.13 an ihr endgültiges Ziel geleitet werden müssen. Der tatsächliche Rechner B steht vielleicht bei einem Kunden von Billabong-Net oder bei einem Kunden dieses Kunden. Wenn alles richtig konfiguriert ist, funktioniert das.

  • Allfällige Antworten von B an A nehmen prinzipiell den umgekehrten Weg.

Die wichtige Beobachtung an dieser Stelle ist, dass sich der tatsächliche Weg der Daten von Rechner A zu Rechner B erst während der Zustellung ergibt. Rechner A muss keine genaue Streckenführung vorgeben, sondern verlässt sich darauf, dass jede Station unterwegs das Richtige tut. Umgekehrt kommt jeder Rechner mit „lokalem” Wissen aus und muss nicht für das komplette Internet wissen, was wo ist – was ohnehin unmöglich wäre.

💡 Eine der Eigenschaften von IP als Kommunikationsprotokoll ist, dass das Routing sich grundsätzlich von Paket zu Paket ändern kann (auch wenn das in der Regel nicht passiert). Dadurch kann das Internet flexibel auf Engpässe oder Ausfälle von Verbindungen reagieren.

💡 Im Prinzip ist das ähnlich wie bei der „gelben Post”. Sie müssen schließlich auch nicht wissen, welchen genauen Weg Ihre Geburtstagskarte für Tante Susi in Sydney nimmt, sondern Sie stecken nur den korrekt freigemachten Umschlag in den Briefkasten Ihres freundlichen Nachbarn.

Wenn Sie einen Linux-Rechner als Client ins Netz bringen wollen, reicht es normalerweise, ihn einzuschalten und entweder das Ethernet-Kabel in die entsprechende Buchse zu stecken oder im Menü ein WLAN auszuwählen und das Kennwort einzugeben. Sollte es dabei zu Problemen kommen, dann rufen Sie Ihren System- oder Netzadministrator zu Hilfe.

15.1.3 Namen und DNS

IP-Adressen sind zwar gut und wichtig, aber etwas umständlich in der Handhabung. Es wäre schließlich sehr ärgerlich, wenn Sie die Adresse 213.157.7.75 eingeben (oder sich diese merken) müssten, um auf den Webserver zu gelangen, auf dem die aktuelle Version dieser Schulungsunterlage verfügbar ist. shop.linupfront.de ist da doch um einiges eingängiger. Damit Sie von den bequemen Namen zu den unbequemen IP-Adressen (und umgekehrt) kommen, gibt es das Domain Name System (DNS). Das DNS ist eine weltweit verteilte Datenbank für Rechnernamen, IP-Adressen und einige andere Dinge. Sie ist über DNS-Server (auch „Nameserver” genannt) zugänglich. Ihre Firma oder Ihr Internet-Anbieter sollte einen (oder aus Redundanzgründen besser zwei) DNS-Server für Sie betreiben.

💡 Sie können das bei Bedarf auch selbst – natürlich auf Linux-Basis – und spätestens, wenn Sie für Ihre Firma ein lokales Netz mit mehreren Servern warten, ist das meistens auch eine gute Idee. Allerdings sind wir da schon deutlich im LPIC-2-Territorium.

💡 Die Adresse des (oder der) DNS-Server kommt als viertes Element zu den „wichtigen Netzwerkparametern” aus dem letzten Abschnitt – IP-Adresse, Subnetzmaske, Standardgateway – hinzu, die jeder Linux-Rechner haben sollte.

Ähnlich wie bei den IP-Adressen und Routen muss auch kein DNS-Server den kompletten Überblick über alle existierenden Namen haben (dafür sind es inzwischen auch einfach zu viele). In Wirklichkeit gibt es eine Hierarchie:

  • Die „Root-Level-Nameserver” kennen den Teil eines Namens, der ganz rechts steht – etwa de, com, tv usw. – und wissen, welche Nameserver sich mit dem Inhalt dieser Zonen auskennen.

  • Die Nameserver für .de (nur mal so als Beispiel) kennen alle Namen der Form irgendwas.de und wissen, welche Nameserver über die Namen unterhalb dieser Namen Bescheid wissen.

  • Die Nameserver für einen Domainnamen wie irgendwas.de (die normalerweise bei der betreffenden Firma oder deren Internet-Anbieter stehen) kennen die IP-Adresse für einen Domainnamen wie und können sie bei Bedarf liefern.

Um beispielsweise den Namen shop.linupfront.de „aufzulösen“, also die dazugehörige IP-Adresse zu finden, fragt Ihr Rechner zunächst einen Root-Level-Nameserver nach Nameservern für de. Anschließend fragt er einen dieser Nameserver nach Nameservern für linupfront.de. Schließlich fragt er einen Nameserver für linupfront.de nach der Adresse von shop.linupfront.de.

💡 Genau genommen macht diese Arbeit nicht „Ihr Rechner“, sondern der DNS-Server, den Ihr Rechner benutzt. Aber das ändert nichts am Prinzip.

Das ist natürlich ein ziemlich aufwendiges Verfahren, weshalb sich Ihr System die Ergebnisse von Anfragen für eine Weile merkt. Wenn Sie beispielsweise herausgefunden haben, dass shop.linupfront.de der IP-Adresse 213.157.7.75 entspricht, wird davon ausgegangen, dass dies auch eine Weile so bleibt, und der Auflösungsprozess erst nach Ablauf dieser Zeit erneut angestoßen wird.

💡 Der Vorteil dabei ist, dass wir von der Linup Front GmbH frei über Namen „unterhalb von” linupfront.de verfügen und diese auch nach Belieben in unseren DNS-Server eintragen können. Andere Leute holen sie sich direkt von dort. Es wäre viel mühsamer, einen neuen Namen aufwendig beim „Internet-Amt” beantragen zu müssen und darauf zu warten, dass er ins offizielle Verzeichnis eingetragen wird. (Denken Sie mal an Grundbuchänderungen und wie lange die dauern.)

15.1.4 IPv6

Das Kommunikationsprotokoll IP gibt es schon seit gut 30 Jahren. Dabei hat man festgestellt, dass einige seinerzeit getroffene Annahmen wohl doch etwas naiv waren. So erlaubt beispielsweise die aktuelle Version des Protokolls, IPv4, prinzipiell 2³², also gut 4 Milliarden Adressen. Aufgrund von Einschränkungen des Protokolls sowie verschiedenen Ungeschicklichkeiten bei der Vergabe stehen jedoch praktisch keine unbenutzten IPv4-Adressen mehr zur Verfügung. In einem Zeitalter, in dem fast jeder ein internetfähiges Mobiltelefon besitzt und noch mehr Leute eines haben wollen, ist das ein definitives Problem.

💡 Es gibt zwar Mittel und Wege, das Problem abzumildern – beispielsweise bekommt nicht jedes internetfähige Mobiltelefon eine vom ganzen Internet aus sichtbare Adresse zugeordnet, sondern die Betreiber schotten ihre Netze vom eigentlichen Internet ab, sodass sie mehr Adressen vergeben können (Stichwort „Adressumsetzung” oder Network Address Translation, NAT) –, diese Methoden sind jedoch ziemlich unappetitlich und führen auch zu Problemen anderswo.

IPv6, der designierte Nachfolger von IPv4, steht schon seit geraumer Zeit in den Startlöchern. IPv6 löst einige Probleme von IPv41, allerdings tun sich die Internet-Anbieter im Moment noch schwer damit, IPv6 flächendeckend zur Verfügung zu stellen. Linux kommt mit IPv6 jedoch hervorragend zurecht und da IPv4 und IPv6 parallel betrieben werden können, steht einer IPv6-basierten Infrastruktur in Ihrem Unternehmen (oder gar im häuslichen LAN – viele DSL-Router unterstützen inzwischen IPv6) im Prinzip nichts im Weg. Hier sind einige der wesentlichen Eigenschaften von IPv6:

  • Erweiterter Adressraum

Statt der 32 Bit breiten Adressen von IPv4 verwendet IPv6 128 Bit breite Adressen – in der Hoffnung, dass dies für die vorhersehbare Zukunft ausreicht (die Chancen dafür stehen recht gut). IPv6-Adressen werden so notiert, dass jeweils zwei Bytes hexadezimal (Basis 16) dargestellt werden und der Doppelpunkt als Trennzeichen dient:

txt fe80:0000:0000:0000:025a:b6ff:fe9c:406a

In jedem Viererblock können führende Nullen entfernt werden:

txt fe80:0:0:0:25a:b6ff:fe9c:406a

Außerdem darf höchstens eine Folge von Null-Blocks durch „::” ersetzt werden:

txt fe80::25a:b6ff:fe9c:406a

Die Loopback-Adresse, also das moralische Äquivalent zu 127.0.0.1 in IPv4, ist ::1.

  • Adresszuordnung

Bei IPv4 erhalten Sie von Ihrem Internetanbieter normalerweise eine IP-Adresse oder höchstens einige wenige (es sei denn, Sie sind ein großer Konzern oder Internetanbieter – selbst für diese sind die Adressen inzwischen sehr knapp). Wenn Sie mehr Adressen für Ihre Rechner benötigen, müssen Sie tricksen. Bei IPv6 erhalten Sie dagegen ein komplettes Netz, auch „Subnetz-Präfix“ genannt, bei dem von den 128 möglichen Adressbits nur 48 oder 56 festgeschrieben sind. Sie können dann in mehreren Subnetzen jeweils 2⁶⁴ Adressen vergeben. Das ist wahrscheinlich mehr, als Sie verbrauchen können, denn das gesamte Internet hat gemäß IPv4 nur 2³² Adressen, also einen Bruchteil davon, zur Verfügung.

  • Vereinfachte Konfiguration

Während bei IPv4 ein Rechner eine IP-Adresse für das lokale Netz zugeordnet bekommen muss, damit er andere Rechner erreichen kann – notfalls mithilfe eines DHCP-Servers –, kann sich ein Rechner mit IPv6 selbst eine Adresse geben, die zumindest für die lokale Kommunikation mit Rechnern in der unmittelbaren Nachbarschaft funktioniert. Außerdem kann ein Rechner mit IPv6 auch ohne DHCP Router in der Umgebung finden, die Daten ins Internet weiterleiten können. Dadurch werden verschiedene Probleme mit DHCP unter IPv4 vermieden. IPv6 verwendet übrigens keine „Defaultroute”.

  • Andere Verbesserungen im Detail

Um ein schnelleres Routing zu ermöglichen, wurde das Format von IP-Datenpaketen geändert. Außerdem definiert IPv6 Verfahren, mit denen das Subnetz-Präfix eines Netzes viel leichter geändert werden kann als dessen Adresse mit IPv4. Auch das dient dazu, das Routing zu vereinfachen. IPv6 unterstützt außerdem verschlüsselte Netzwerkstrukturen (IPsec) und Mobilität. Dabei können Rechner, wie beispielsweise Mobiltelefone, von einem Netz in ein anderes umziehen, ohne dass sich ihre IP-Adressen ändern oder bestehende Verbindungen abgebrochen werden („Mobile IPv6”).

  • Kompatibilität

Die Einführung von IPv6 betrifft nur das IP-Protokoll. TCP, UDP und die darauf aufsetzenden Anwendungsprotokolle bleiben unverändert. Darüber hinaus ist es möglich, IPv4 und IPv6 parallel zu betreiben.

Übungen

✏️ 15.1 [!1] Welche Transportprotokolle außer Ethernet und IEEE 802.11 sind Ihnen bekannt? Welche Kommunikationsprotokolle außer IP, TCP und UDP? Welche Anwendungsprotokolle außer den im Text genannten?

✏️ 15.2 [!1] Wie viele nutzbare IP-Adressen enthält das Netz 10.11.12.0/22? (Ziehen Sie wegen ihrer Sonderbedeutung die erste und letzte Adresse ab.)

✏️ 15.3 [2] Welche Voraussetzungen müssen erfüllt sein, damit Sie einen Domainnamen in der Top-Level-Domain „.de” registrieren können?

15.2 Linux als Netzwerk-Client

15.2.1 Anforderungen

Was nötig ist, um einen Linux-Rechner als (IPv4-)Client in ein existierendes Netz zu integrieren (der einzige für Linux Essentials relevante Anwendungsfall), haben wir im vorigen Abschnitt bereits umrissen.

  • Eine IP-Adresse für den Rechner selbst,
  • eine Netzwerkadresse und -maske für den Rechner (damit er entscheiden kann, welche IP-Adressen „lokal” sind).

  • Die Adresse eines Standard-Gateways im lokalen Netz.

  • die Adresse(n) eines (oder besser zweier) DNS-Server(s).

Im Idealfall werden diese Informationen Ihrem Rechner automatisch über DHCP zugewiesen, beispielsweise beim Hochfahren oder Einstöpseln des LAN-Kabels bei einem stationären Rechner oder beim Einbuchen in ein drahtloses Netz bei mobilen Systemen. Sollte das nicht der Fall sein, müssen Sie die Netzwerkparameter manuell setzen. Wie das genau geht, hängt von Ihrer Distribution ab.

Bei Debian GNU/Linux und den davon abgeleiteten Distributionen steht die Netzkonfiguration in der Datei /etc/network/interfaces. Das Format ist größtenteils selbsterklärend und unter /usr/share/doc/ifupdown/examples/networkinterfaces.gz finden Sie ein kommentiertes Beispiel. Die Dokumentation finden Sie in interfaces(5).

  • Bei den SUSE-Distributionen konfigurieren Sie die Netzwerkparameter am einfachsten über YaST (in „Netzwerkgeräte/Netzwerkkarte”). Ansonsten finden Sie die Konfigurationsdateien unter /etc/sysconfig/network.

Bei den Red-Hat- und von Red Hat abgeleiteten Distributionen stehen die Konfigurationsdateien im Verzeichnis /etc/sysconfig/network-scripts.

Für kurzzeitige Experimente können Sie auch das Kommando ifconfig verwenden. Etwas wie

# ifconfig eth0 192.168.178.111 netmask 255.255.255.0

verpasst der Netzwerkschnittstelle eth0 (Ethernet) die IP-Adresse 192.168.178.111 im lokalen Netz 192.168.178.0/24. Die Angabe 255.255.255.0 ist eine umständliche Methode, um die Netzmaske (24) anzugeben. Das Standard-Gateway (zum Beispiel 192.168.178.1) konfigurieren Sie mit dem Befehl route.

# route add -net default gw 192.168.178.1

Diese Einstellung gilt nur bis zum nächsten Neustart!

Die Adressen der DNS-Server sind in der Regel in der Datei /etc/resolv.conf zu finden. Diese könnte beispielsweise wie folgt aussehen:

# /etc/resolv.conf search example.com
nameserver 192.168.178.1
nameserver 192.168.178.2

Wenn Sie irgendwo einen Namen ohne Punkt – etwa „www” – angegeben haben, sucht das „search example.com” automatisch nach „www.example.com”.

💡 Wenn Ihr System das Netz automatisch konfiguriert – etwa bei der Verbindung mit WLANs –, wird der Inhalt von /etc/resolv.conf mitunter überschrieben. Schauen Sie in der Dokumentation nach, wie und wo Sie in Ihrer Distribution Nameserver dauerhaft konfigurieren können.

15.2.2 Fehlersuche

Sollte die einfache Methode der Netzwerkkonfiguration (Einstöpseln bzw. Einbuchen) nicht funktionieren oder sollten anderweitige Probleme auftreten, beispielsweise quälend lange Wartezeiten beim Zugriff auf Webseiten oder unerklärliche Verbindungsabbrüche, sollten Sie einen System- oder Netzadministrator oder generell jemanden, der sich mit der Materie besser auskennt als Sie, zu Rate ziehen. (Jedenfalls bis Sie die LPIC-2-Prüfungen abgelegt haben – spätestens ab dann werden Sie herbeigerufen, wenn andere Leute in Schwierigkeiten sind.)

Auf der anderen Seite kommt es immer gut an, wenn Sie die gängigsten Probleme selbst ausgeschlossen oder den Fehler eingegrenzt haben. Das spart Ihrem Administrator möglicherweise Arbeit oder sorgt zumindest dafür, dass Sie nicht wie ein DAU 2 aussehen, sondern wie jemand, der ernst genommen werden sollte.

Im Rest dieses Abschnitts erklären wir Ihnen die wichtigsten Werkzeuge zur Fehlersuche und ihre Benutzung.

Das Kommando ifconfig haben wir gerade zur Netzkonfiguration kennengelernt. Mit ifconfig können Sie aber auch die Konfiguration einer Netzwerkschnittstelle abfragen:

$ /sbin/ifconfig eth0
eth0 Link encap:Ethernet Hardware Adresse 70:5a:b6:9c:40:6a inet Adresse:192.168.178.130 Bcast:192.168.178.255✄
✁ Maske:255.255.255.0
inet6-Adresse: 2002:4fee:57e5:0:725a:b6ff:fe9c:406a/64✄
✁ Gültigkeitsbereich:Global
inet6-Adresse: fe80::725a:b6ff:fe9c:406a/64✄
✁ Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
RX packets:83769 errors:0 dropped:0 overruns:0 frame:0
TX packets:76525 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:69767848 (66.5 MiB) TX bytes:10245590 (9.7 MiB)
Interrupt:20 Speicher:d7400000-d7420000

Hier sind vor allem die verschiedenen Adressangaben interessant:

  • In der ersten Zeile der Ausgabe steht die Hardware- oder MAC-Adresse der Schnittstelle. Sie wird vom Hersteller der Ethernet-Karte fest vergeben.

  • In der zweiten Zeile steht die IP(v4)-Adresse, die der Schnittstelle zugeordnet ist. Ganz rechts steht die Netzmaske in der altertümlich-umständlichen Form.

  • Die dritte und vierte Zeile geben verschiedene IPv6-Adressen an. Die vierte Zeile enthält die nur lokal gültige Adresse, die der Rechner selbst vergeben hat. Die dritte Zeile enthält ein Netzwerkpräfix, über das der Rechner grundsätzlich aus dem Internet erreichbar wäre.

💡 Wenn Sie genau hinschauen, können Sie in der zweiten Hälfte jeder der IPv6-Adressen die MAC-Adresse der Schnittstelle wiederfinden.

Das „UP” in der fünften Zeile signalisiert, dass die Schnittstelle aktiv ist.

Rufen Sie ifconfig ohne Parameter auf, werden Informationen über alle aktiven Netzwerkschnittstellen auf dem Rechner ausgegeben. Mit dem Parameter -a werden auch die gerade nicht aktiven angezeigt.

Mit dem Kommando ping können Sie auf der untersten Ebene (IP) prüfen, ob Ihr Rechner mit anderen Rechnern kommunizieren kann. ping benutzt das Steuerungsprotokoll ICMP, um einen anderen Rechner um ein „Lebenszeichen” zu bitten. Kommt dieses Lebenszeichen wieder bei Ihrem Rechner an, wissen Sie, dass (a) Ihr Rechner Daten an den anderen Rechner schicken kann und (b) der andere Rechner Daten an Ihren Rechner schicken kann (das eine impliziert nicht notwendigerweise das andere).

Im einfachsten Fall rufen Sie Ping mit dem Namen des Rechners auf, mit dem Sie kommunizieren wollen:

$ ping fritz.box
PING fritz.box (192.168.178.1) 56(84) bytes of data.
64 bytes from fritz.box (192.168.178.1): icmp_req=1 ttl=64 time=3.84 ms
64 bytes from fritz.box (192.168.178.1): icmp_req=2 ttl=64 time=5.09 ms
64 bytes from fritz.box (192.168.178.1): icmp_req=3 ttl=64 time=3.66 ms
64 bytes from fritz.box (192.168.178.1): icmp_req=4 ttl=64 time=3.69 ms
64 bytes from fritz.box (192.168.178.1): icmp_req=5 ttl=64 time=3.54 ms
Abbruch mit Strg + c …
--fritz.box ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms rtt min/avg/max/mdev = 3.543/3.967/5.095/0.575 ms

Hier ist alles in Ordnung: Alle fünf abgeschickten Pakete sind zurückgekommen, die Reihenfolge stimmt und die Laufzeiten liegen im Rahmen für ein lokales Netz. Wenn Sie eine Weile lang nichts sehen und dann etwas wie

From 192.168.178.130 icmp_seq=1 Destination Host Unreachable 
From 192.168.178.130 icmp_seq=2 Destination Host Unreachable 
From 192.168.178.130 icmp_seq=3 Destination Host Unreachable 

erscheint diese Meldung, dann liegt etwas im Argen – der Zielrechner ist nicht erreichbar.

Wenn Sie keine Verbindung zu einem entfernten Rechner im Internet herstellen können, kann das Problem grundsätzlich überall zwischen Ihnen und dem entfernten Rechner liegen. Wenn Sie methodisch vorgehen möchten, benutzen Sie am besten die folgende Taktik:

  • Prüfen Sie zunächst mit Ping, ob Sie die Loopback-Schnittstelle 127.0.0.1 erreichen können. Wenn das nicht klappt, dann ist mit Ihrem Rechner etwas nicht in Ordnung.

  • Prüfen Sie mit Ping, ob Sie die Adresse der Netzwerkkarte (Ethernet, WLAN usw.) erreichen können, über die Sie gerade mit dem Internet verbunden sind (oder zu sein glauben). Die Adresse können Sie bei Bedarf mit einem Befehl wie „$ /sbin/ifconfig eth0” herausfinden. Auch das sollte funktionieren – ansonsten haben Sie ein lokales Problem.

  • Prüfen Sie mit Ping, ob Sie die Adresse Ihres Standardgateways erreichen können. Wenn Sie diese nicht auswendig wissen, rufen Sie „route” auf. In

$ /sbin/route
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
default fritz.box "0,000" UG 0 0 0 eth0
link-local * "25,525,500" U 1000 0 0 lo 1,921,681,780" * "2,552,552,550" U 0 0 0 eth0 

sehen Sie in der Zeile „Ziel” unter „Standard” nach, was Sie verwenden müssen – hier „ping fritz.box”. Wenn das nicht funktioniert und Sie Meldungen wie „Destination Host Unreachable” erhalten, ist in Ihrem lokalen Netz etwas nicht in Ordnung. Fragen Sie gegebenenfalls einen Kollegen, ob er gerade ins Internet kommt, oder probieren Sie einen anderen Rechner aus. Sollte dort alles klappen, liegt das Problem bei Ihrem Computer. Ansonsten – und möglicherweise auch in diesem Fall – ist es Zeit für den Systemadministrator.

💡 Beispielsweise könnte es sein, dass Ihre Standardroute verbogen ist und auf den falschen Rechner zeigt. (Zumindest bei manueller Konfiguration wäre das denkbar.) Das würde Benutzer anderer Rechner, bei denen die Konfiguration wahrscheinlich stimmt, nicht betreffen.

  • Wenn Sie auch das Standard-Gateway problemlos erreichen können, dann liegt das Problem entweder jenseits Ihres LANs, also im Internet, und ist damit möglicherweise nicht nur Ihrem, sondern sogar dem Zugriff Ihres Administrators entzogen, oder es ist weiter oben im „Protokollstapel” anzusiedeln. Es kann beispielsweise sein, dass Sie einen entfernten Web-Server zwar über Ping kontaktieren können, der direkte Zugriff ins Web bei Ihrem (Firmen-)Internetzugang aber gesperrt ist, weil Sie einen Proxy-Server benutzen sollen (und das zu konfigurieren vergessen haben). Ihr Systemadministrator hilft Ihnen weiter.

Eine Netzanbindung, die manchmal funktioniert und manchmal nicht (Knick im Kabel? Mäusefraß?), können Sie mit „ping -f” auf die Probe stellen. Hierbei schickt Ping nicht wie üblich ein Paket pro Sekunde an den anderen Rechner, sondern so schnell es geht. Für jedes gesendete Paket wird ein Punkt ausgegeben, für jedes empfangene Paket ein „Backspace“-Zeichen, das den Punkt wieder löschen sollte. Gehen Ihnen Pakete verloren, dann entsteht eine immer länger werdende Zeile von Punkten.

💡 Wenn Sie kein Administrator sind, sondern nur ein normaler Benutzer, müssen Sie sich mit einem minimalen Abstand von 0,2 Sekunden zwischen zwei versandten Paketen zufriedengeben. Das Netzwerk zu überfluten, ist nämlich nur Administratoren erlaubt.

Wenn Sie IPv6-Verbindungen prüfen möchten, müssen Sie statt Ping das Kommando Ping6 verwenden:

ping6 ::1

Mit dem Kommando dig können Sie die Namensauflösung über das DNS testen.

Wenn Sie keine weiteren Angaben machen, versucht es, zu dem auf der Kommandozeile angegebenen Namen eine IP-Adresse zu finden:

$ dig www.linupfront.de
; <<>> DiG 9.8.1-P1 <<>> www.linupfront.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<opcode: QUERY, status: NOERROR, id: 34301
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.linupfront.de." IN A
;; ANSWER SECTION:
www.linupfront.de." 3600 IN CNAME s0a.linupfront.de.
s0a.linupfront.de. 3600 IN A "312,417,568
;; Query time: 112 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Mar 1 16:06:06 2012
;; MSG SIZE rcvd: 69

In dieser (sehr geschwätzigen) Ausgabe wird in der „QUESTION SECTION” verraten, dass wir nach „www.linupfront.de” gesucht haben (als ob wir das nicht sowieso wüssten). Die „ANSWER SECTION” teilt mit, dass zu dem Namen „www.linupfront.de” eigentlich gar keine IP-Adresse gehört, sondern dass „www.linupfront.de” nur ein „Spitzname” für den Rechner „s0a.linupfront.de” ist (eine beliebte Methode). s0a.linupfront.de hat jedoch die Adresse 31.24.175.68. Im letzten Block sehen wir schließlich, dass diese Antwort vom DNS-Server auf 127.0.0.1 kommt.

Kommt dagegen längere Zeit keine Antwort, dann schließlich etwas wie:

<<>> DiG 9.8.1-P1 <<>> www.linupfront.de ;; global options: +cmd 
;; connection timed out; no servers could be reached

dann ist etwas faul im Staate Dänemark. Entweder sind Ihre Einstellungen in /etc/resolv.conf nicht korrekt, oder der Nameserver funktioniert nicht richtig.

💡 Sie können gezielt einen bestimmten Nameserver anfragen, indem Sie ihn auf der Kommandozeile benennen:

dig www.linupfront.de @fritz.box Frage fritz.box

Zum Auflösen dieses Namens sollte natürlich keine aufwendige DNS-Suche nötig sein (ansonsten hätten Sie womöglich ein Henne-Ei-Problem). Im Zweifel können Sie die IP-Adresse auch direkt angeben:

dig www.linupfront.de @192.168.178.1

💡 Wenn Sie sich mit DNS auskennen: Dann können Sie dig auch verwenden, um nach anderen RR-Typen als A-Records zu suchen. Geben Sie dazu einfach auf der Kommandozeile ein, was Sie suchen:

dig linupfront.de mx

Um den Namen einer gegebenen IP-Adresse herauszufinden (sofern vorhanden), müssen Sie die Option -x angeben:

$ dig +short -x 31.24.175.68
s0a.linupfront.de.

Mit der Option „+short” liefert dig eine sehr knappe Antwort.

Natürlich kann dig noch viel mehr, aber das meiste davon ist nur für Personen von Interesse, die Nameserver konfigurieren oder am Laufen halten müssen. Im Zweifel finden Sie mehr Details in dig(1).

Das Kommando netstat ist eine Art Schweizer Messer und liefert Ihnen Informationen aller Art über Ihren Rechner und seine Netzanbindung. Wenn Sie einfach nur

netstat

aufrufen, bekommen Sie eine Liste aller aktiven Verbindungen angezeigt. Dazu zählen nicht nur TCP-Verbindungen, sondern auch lokale Verbindungen über Unix-Domain-Sockets. Diese sind ebenso umfangreich wie langweilig. Interessanter ist es, sich beispielsweise

$ netstat -tl
Aktive Internetverbindungen (Nur Server)
Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 ceol:domain *:* LISTEN
tcp 0 0 ceol-eth.fri:domain *:* LISTEN
tcp 0 0 *:ssh *:* LISTEN
tcp 0 0 ceol:ipp *:* LISTEN
tcp 0 0 ceol:postgresql *:* LISTEN tcp
✁✁✁✁✁" 0 0 ceol:smtp *:* LISTEN eine Liste der TCP-Ports ausgeben zu lassen, auf denen auf dem lokalen Rechner

Serverprogramme anzusehen, die auf eingehende Verbindungen lauschen.

💡 Damit derselbe Rechner gleichzeitig mehrere Dienste anbieten oder ansprechen kann, verwenden TCP und UDP »Ports«. Viele Protokolle haben fest zugeordnete Portnummern. Eine Liste der Portnummern finden Sie in der Datei /etc/services.

An der Beispielausgabe können Sie sehen, dass der Rechner mit der Adresse ceol unter anderem einen DNS-Server (Dienst domain), einen CUPS-Server zum Drucken (Dienst ipp) sowie einen Mailserver (Dienst smtp) anbietet. Den SSH-Dienst (Secure Shell) bietet er sogar auf allen konfigurierten Adressen an.

💡 „netstat -tl“ ist ein wichtiges Werkzeug zur Fehlersuche im Zusammenhang mit Netzwerkdiensten. Wenn ein Dienst hier nicht aufgeführt ist, von dem Sie annehmen, dass er in der Liste aufgeführt sein sollte, dann ist das ein Zeichen dafür, dass mit seiner Konfiguration etwas nicht stimmt – entweder ist die Adresse und/oder der Port nicht richtig eingestellt oder beim Start des Dienstes ist etwas schiefgelaufen, sodass er gar nicht läuft.

💡 Mit „-u” statt „-t” sehen Sie die UDP-basierten Serverdienste und mit „-p” werden auch der Name und die PID des Prozesses ausgegeben, der den Dienst erbringt. Letzteres funktioniert allerdings nur, wenn Sie das Kommando als root aufrufen.

💡 Mit „-n” bekommen Sie das Ganze mit IP-Adressen und Portnummern statt Namen. Das kann manchmal aufschlussreicher sein, jedenfalls sofern Sie ein Gefühl für die Portnummern haben:

$ netstat -tln
Aktive Internetverbindungen (Nur Server)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN
tcp 0 0 192.168.178.130:53 0.0.0.0:* LISTEN tcp
✁✁✁✁✁" 0 0 0.0.0.0:22 0.0.0.0:* LISTEN

Mit dem Befehl „netstat -s” erhalten Sie statistische Informationen:

Ip:
145845 total packets received
8 with invalid addresses
0 forwarded
0 incoming packets discarded 145837 incoming packets delivered 138894 requests sent out
16 outgoing packets dropped
172 dropped because of missing route Icmp:
30 ICMP messages received
0 input ICMP message failed.
✁✁✁✁✁

Im Wesentlichen ist „netstat -r” dasselbe wie „route” (ohne Parameter).

Übungen

✏️ 15.4 [!2] Verwenden Sie Ping, um sicherzustellen, dass Sie einen bekannten Rechner im Internet erreichen können, beispielsweise .

✏️ 15.5 [1] Benutzen Sie dig, um nachzuschauen, für welche IP-Adresse hat.

✏️ 15.6 [2] Mit der Option „+trace” von dig wird die komplette Suchkette für einen Namen dokumentiert, beginnend bei den Root-Level-Nameservern. Probieren Sie dies für einige interessante Namen aus und prüfen Sie die Zwischenschritte.

✏️ 15.7 [2] Welche Netzwerkdienste bietet Ihr Rechner an? Welche davon sind von anderen Rechnern aus erreichbar?

15.3 Kommandos in diesem Kapitel

Kommando Beschreibung manpage
dig Sucht Informationen im DNS (sehr komfortabel) dig(1)
ifconfig Konfiguriert Netzwerk-Schnittstellen ifconfig(8)
netstat Liefert Informationen über Netzverbindungen, Server, Routing netstat(8)
ping Prüft grundlegende Netzwerk-Konnektivität mit ICMP ping(8)
ping6 Prüft grundlegende Netzwerk-Konnektivität (für IPv6) ping(8)
route Verwaltet die statische Routing-Tabelle im Linux-Kern route(8)

15.4 Zusammenfassung

  • Es gibt drei Arten von Netzwerkprotokollen:
  • Transportprotokolle,
  • Kommunikationsprotokolle und
  • Anwendungsprotokolle.

  • In einem „Protokollstapel” kommuniziert jedes Protokoll nur mit den unmittelbar darunter- und darüberliegenden Protokollen.

  • TCP/IP enthält die Kommunikationsprotokolle IP und TCP (zuverlässig und verbindungsorientiert) sowie UDP (unzuverlässig und verbindungslos). Darüber hinaus umfasst es das Steuerungsprotokoll ICMP und eine Vielzahl von Anwendungsprotokollen auf TCP- oder UDP-Basis.

  • Rechner im Internet haben eindeutige IP-Adressen.

  • Routing ermöglicht die Kommunikation zwischen nicht direkt verbundenen Rechnern.

  • Um am Netzwerk teilzunehmen, benötigt ein Linux-Rechner eine IP-Adresse, eine Subnetzadresse mit Maske, ein Standard-Gateway und die Adresse mindestens eines DNS-Servers.

  • Das DNS ist eine verteilte Datenbank zur Abbildung von Rechnernamen auf IP-Adressen und umgekehrt.

  • IPv6 ist der Nachfolgestandard von IPv4 und hebt verschiedene Einschränkungen auf.

  • ifconfig und route dienen zur manuellen Konfiguration der Netzanbindung. Distributionen bieten verschiedene Methoden zur dauerhaften Netzkonfiguration.

  • Die Programme ifconfig, ping, dig und netstat dienen der Fehlersuche im Netzwerk.


  1. IPv5 hat es nie wirklich gegeben. 

  2. »Dümmster anzunehmender User«