| SUSE LINUX – Administrationshandbuch Teil IV. Netzwerk / Kapitel 14. Grundlagen der Vernetzung | ||||
|---|---|---|---|---|
 | Teil IV. Netzwerk | 14.2. IPv6 – Internet der nächsten Generation |  | |
| SUSE LINUX – Administrationshandbuch Teil IV. Netzwerk / Kapitel 14. Grundlagen der Vernetzung | ||||
|---|---|---|---|---|
| Teil IV. Netzwerk | 14.2. IPv6 – Internet der nächsten Generation | | |
Inhaltsverzeichnis
Zusammenfassung
Linux, ein wahres Kind des Internets, bietet Ihnen alle Voraussetzungen und notwendigen Netzwerktools zur Einbindung in diverse Netzwerkstrukturen. Im folgenden erhalten Sie eine Einführung in das normalerweise von Linux verwendete Protokoll TCP/IP, dessen Dienstleistungen und auch besonderen Eigenschaften. Anschließend zeigen wir Ihnen die Einrichtung eines Netzwerkzugangs mit einer Netzwerkkarte unter SUSE LINUX mit Hilfe von YaST. Es werden die zentralen Konfigurationsdateien besprochen und einige der wichtigsten Tools aufgeführt. Da die Konfiguration eines Netzwerks beliebig komplex sein kann, werden in diesem Kapitel nur die grundlegenden Mechanismen dargestellt.
▪ x86
Auch die Internet-Anbindung per PPP via Modem, ISDN oder DSL lässt sich mit
YaST bequem konfigurieren und ist im
Benutzer-Handbuch erklärt.
▪
Linux und andere Unix-Betriebssysteme verwenden das TCP/IP-Protokoll. Genau genommen handelt es sich um eine Protokollfamilie, die ganz unterschiedliche Dienstleistungen bietet. TCP/IP wurde aus einer militärischen Anwendung heraus entwickelt und in der heute verwendeten Form ca. 1981 in einem so genannten RFC festgelegt. Bei RFC (engl. Request for comments) handelt es sich um Dokumente, die die verschiedenen Internetprotokolle und die Vorgehensweise bei der Implementierung des Betriebssystems und von Applikationen beschreiben. Auf diese RFC-Dokumente können Sie direkt über das Web zugreifen, die URL lautet http://www.ietf.org/. In der Zwischenzeit sind einige Verfeinerungen am TCP/IP Protokoll vorgenommen worden, am grundlegenden Protokoll hat sich seit 1981 aber nichts geändert.
![[Tip]](admon/tip.png) | Tipp |
|---|---|
Die RFC-Dokumente beschreiben den Aufbau der Internet Protokolle. Falls Sie Ihr Know-how über ein bestimmtes Protokoll vertiefen wollen, ist das passende RFC-Dokument die richtige Anlaufstelle: http://www.ietf.org/rfc.html | |
Die in Tabelle 14.1. “Verschiedene Protokolle der TCP/IP Protokollfamilie” genannten Dienste stehen zur Verfügung, um Daten zwischen zwei Linuxrechnern über TCP/IP auszutauschen:
Tabelle 14.1. Verschiedene Protokolle der TCP/IP Protokollfamilie
Fast alle Hardwareprotokolle arbeiten paketorientiert. Die zu übertragenden Daten müssen in kleine „Päckchen“ gepackt werden und können nicht „in einem Rutsch“ verschickt werden. Deshalb arbeitet auch TCP/IP mit kleinen Datenpaketen. Die Maximalgröße eines TCP/IP Paketes ist knapp 64 Kilobyte. In der Praxis sind die Pakete normalerweise viel kleiner, da die Netzwerkhardware der limitierende Faktor ist. So ist die zulässige Maximalgröße eines Datenpaketes auf dem Ethernet ca. 1500 Byte. Dementsprechend wird die Paketgröße des TCP/IP Pakets begrenzt, wenn die Daten über ein Ethernet geschickt werden. Will man mehr Daten übertragen, müssen vom Betriebssystem entsprechend mehr Datenpakete verschickt werden.
Über IP (engl. Internet protocol) findet eine ungesicherte Datenübertragung statt. TCP (engl. Transmission control protocol) ist gewissermaßen nur ein Aufsatz auf das darunter liegende IP, um eine gesicherte Übertragung der Daten zu garantieren. IP selbst ist wiederum ein Aufsatz auf das darunter liegende, hardwareabhängige Protokoll, zum Beispiel Ethernet. Kenner sprechen hier vom „Schichtenmodell“. Vergleichen Sie hierzu die Abbildung 14.1. “Vereinfachtes Schichtenmodell für TCP/IP”.
In der Abbildung sind jeweils ein oder zwei Beispiele für die jeweilige Schicht erwähnt. Wie Sie sehen, sind die Schichten nach „Abstraktionsebenen“ geordnet, die unterste Schicht ist sehr nah an der Hardware. Die oberste Schicht hingegen abstrahiert die darunter liegende Hardware nahezu vollständig. Jede der Schichten hat eine ganz spezielle Funktion, die zum Großteil schon aus der Bezeichnung hervorgeht. So wird das verwendete Netzwerk (zum Beispiel Ethernet) durch die Bitübertragungsschicht und die Sicherungsschicht verkörpert.
Während sich Schicht 1 mit solchen Dingen wie Kabeltypen, Signalformen, Signalkodierung und ähnlichem beschäftigt ist Schicht 2 für das Zugriffsverfahren (Welcher Rechner darf wann Daten schicken?) und eine Fehlerkorrektur (Datensicherung - deshalb Sicherungsschicht) zuständig. Die Schicht 1 nennt man die Bitübertragungsschicht.
Schicht 3 wiederum, die Vermittlungsschicht ist für die Datenübertragung über weite Strecken verantwortlich. Die Vermittlungsschicht stellt sicher, dass die Daten auch über weite Strecken beim richtigen Empfänger ankommen und zugestellt werden können.
Schicht 4, die Transportschicht, ist für die Daten der Applikation verantwortlich und stellt sicher, dass die Daten in der richtigen Reihenfolge ankommen und nicht verloren gehen. Die Sicherungsschicht ist nur dafür verantwortlich, dass die ankommenden Daten korrekt sind. Gegen das „Verlieren“ von Daten schützt die Transportschicht.
Schicht 5 schließlich ist die Datenverarbeitung durch die Applikation selbst.
Damit jede der Schichten die ihr zugeteilte Aufgabe erfüllen kann, müssen zusätzliche Informationen der jeweiligen Schicht im Datenpaket im Header, dem Kopf des Datenpakets, gespeichert werden. Jede der Schichten fügt einen kleinen Datenblock, den sog. „Protokollkopf“ (engl. Protocol header), an das im Entstehen begriffene Paket vorne dran. Schauen wir uns also einmal ein beliebiges TCP/IP-Datenpaket an, das auf einem Ethernetkabel unterwegs ist, so setzt sich dieses wie in Bild 14.2. “TCP/IP Paket im Ethernet” abgebildet zusammen.
Wie Sie sehen, ist die Welt nicht perfekt und ohne Ausnahme. Die Prüfsumme der Sicherungsschicht befindet sich am Ende des Pakets und nicht am Anfang. Dies bringt aber für die Netzwerkhardware eine Vereinfachung. Die maximal mögliche Menge der Nutzdaten in einem Paket beträgt im Ethernet-Netzwerk 1460 Byte.
Möchte eine Applikation also Daten über das Netzwerk verschicken, durchlaufen die Daten die einzelnen Schichtebenen, die alle im Linuxkernel (Ausnahme Schicht 1: Netzwerkkarte) implementiert sind. Jede der Schichten ist dafür verantwortlich, die Daten so aufzubereiten, dass sie an die jeweils darunter liegende Schicht weitergereicht werden können. Die unterste Schicht ist schließlich für den eigentlichen Datenversand zuständig. Beim Empfang läuft das ganze nun umgekehrt ab. Wie bei den Schalen einer Zwiebel werden von jeder Schicht die Protokollköpfe von den Nutzdaten entfernt. Schicht 4 ist dann letztendlich dafür verantwortlich, die Daten für die Applikation auf dem Zielrechner bereitzustellen. Dabei kommuniziert eine Schicht immer nur mit der Schicht direkt über oder unter ihr. Für eine Applikation ist es also irrelevant, ob die Daten über ein 100-MBit/s-FDDI-Netzwerk oder über eine 56-KBit/s-Modemleitung übertragen werden. Umgekehrt ist es für die Datenübertragungsleitung egal, welche Daten eigentlich verschickt werden, solange sie richtig verpackt sind.
![[Important]](admon/important.png) | Wichtig |
|---|---|
Die folgenden Abschnitte beschreiben IPv4-Netzwerke. Informationen zu seinem Nachfolgeprotokoll IPv6 bekommen Sie Abschnitt 14.2. “IPv6 – Internet der nächsten Generation”. | |
Jeder Computer im Internet hat eine eindeutige 32-Bit-Adresse. Diese 32 Bit bzw. 4 Byte werden normalerweise wie in Beispiel 14.1. “Schreibweise einer IP-Adresse” in der zweiten Zeile abgebildet geschrieben.
Beispiel 14.1. Schreibweise einer IP-Adresse
IP-Adresse (binär): 11000000 10101000 00000000 00010100 IP-Adresse (dezimal): 192. 168. 0. 20
Die vier Bytes werden also im dezimalen Zahlensystem durch einen Punkt getrennt nebeneinander geschrieben. Die IP-Adresse ist einem Rechner bzw. einer Netzwerkschnittstelle zugeordnet, sie kann also nicht woanders auf der Welt nochmals verwendet werden. Ausnahmen von diesen Regeln gibt es zwar, spielen aber bei der folgenden Betrachtung erst einmal keine Rolle.
Auch die Ethernetkarte besitzt selbst eine eindeutige Adresse, die so genannte MAC (engl. Media access control) Adresse. Diese ist 48 Bit lang, weltweit eindeutig und wird vom Hersteller der Netzwerkkarte fest in der Hardware gespeichert. Durch die Vergabe der Adresse vom Hersteller ergibt sich aber ein fataler Nachteil: Die MAC-Adressen bilden kein hierarchisches System, sondern sind mehr oder weniger zufällig verteilt. Sie können daher nicht zur Adressierung eines weit entfernten Rechners verwendet werden. Die MAC-Adresse spielt aber bei der Kommunikation von Rechnern in einem lokalen Netz eine entscheidende Rolle (und ist der Hauptbestandteil des Protokollkopfes von Schicht 2).
Zurück zu den IP-Adressen: Die Punkte deuten schon an, dass die IP-Adressen ein hierarchisches System bilden. Bis Mitte der 90er Jahre waren die IP-Adressen fest in Klassen eingeteilt. Dieses System erwies sich aber als zu unflexibel und daher wurde diese Aufteilung aufgegeben. Man verwendet nun „klassenloses Routing“ (CIDR (engl. classless inter domain routing)).
Da der Rechner mit der IP-Adresse 192.168.0.0 erst einmal nicht wissen kann, wo sich der Rechner mit der IP-Adresse 192.168.0.20 befindet, wurden die Netzmasken erdacht.
Vereinfacht gesagt definiert die (Sub-)Netzmaske auf einem Rechner mit IP-Adresse, was „drinnen“ und was „draußen“ ist. Rechner, die sich „drinnen“ (Profis sagen: „im gleichen Subnetz“) befinden, können direkt angesprochen werden. Rechner, die sich „draußen“ („nicht im gleichen Subnetz“) befinden, müssen über ein so genanntes Gateway oder Router angesprochen werden. Da jedes Netzwerkinterface eine eigene IP-Adresse bekommen kann, ahnen Sie schon, dass es schnell beliebig kompliziert wird.
Bevor ein Netzwerkpaket auf die Reise geschickt wird, läuft folgendes im Rechner ab: Die Zieladresse wird mit der Netzmaske bitweise UND verknüpft. Daraufhin wird auch die Absendeadresse bitweise mit der Netzmaske UND verknüpft (siehe Tabelle 14.2. “Verknüpfungen der IP-Adressen mit der Netzmaske”). Stehen mehrere Netzwerkinterfaces zur Verfügung, werden in der Regel alle möglichen Absendeadressen überprüft.
Die Ergebnisse der UND-Verknüpfungen werden verglichen. Ergibt sich zwischen den Ergebnissen eine exakte Übereinstimmung, so befindet sich der Zielrechner im gleichen Subnetz. Ansonsten muss er über ein Gateway angesprochen werden. Das heißt, je mehr „1“ Bits sich in der Netzmaske befinden, desto weniger Rechner können direkt, sondern nur über ein Gateway angesprochen werden. Zur Veranschaulichung sind in Beispiel 14.2. “Verknüpfungen der IP-Adressen mit der Netzmaske” mehrere Beispiele aufgeführt.
Beispiel 14.2. Verknüpfungen der IP-Adressen mit der Netzmaske
IP-Adresse (192.168.0.20): 11000000 10101000 00000000 00010100 Netzmaske (255.255.255.0): 11111111 11111111 11111111 00000000 _______________________________________________________________ Ergebnis (binär): 11000000 10101000 00000000 00000000 Ergebnis (dezimal): 192. 168. 0. 0 IP-Adresse (213.95.15.200): 11010101 10111111 00001111 11001000 Netzmaske (255.255.255.0): 11111111 11111111 11111111 00000000 --------------------------------------------------------------- Ergebnis (binär): 11010101 10111111 00001111 00000000 Ergebnis (dezimal): 213. 95. 15. 0
Die Netzmaske wird wieder – wie schon die IP-Adresse – in Form von durch Punkte getrennten Dezimalzahlen geschrieben. Da die Netzmaske auch ein 32-Bit-Wert ist, werden vier Zahlenwerte nebeneinander geschrieben. Welche Rechner Gateway sind oder welche Adressbereiche über welche Netzwerkschnittstelle erreichbar sind, muss vom Benutzer konfiguriert werden.
Um wieder ein Beispiel zu geben: Alle Rechner, die am gleichen Ethernetkabel angeschlossen sind, befinden sich in der Regel im gleichen Subnetz und sind direkt erreichbar. Auch wenn das Ethernet über Switches oder Bridges unterteilt ist, sind diese Rechner immer noch direkt erreichbar.
Wollen Sie eine längere Strecke überbrücken, ist das preiswerte Ethernet dafür nicht mehr geeignet. Sie müssen dann die IP-Pakete auf andere Hardware (zum Beispiel FDDI oder ISDN) weiterleiten. Solche Geräte heißen Router bzw. Gateway. Ein Linuxrechner kann diese Aufgabe selbstverständlich auch erledigen, die entsprechende Option wird mit ip_forwarding bezeichnet.
Ist ein Gateway konfiguriert, wird das IP-Paket an das passende Gateway geschickt. Dieses versucht, das Paket dann wiederum nach dem gleichen Schema weiterzuleiten. Das wiederholt sich auf jedem weiteren Rechner sooft, bis das Paket entweder den Zielrechner erreicht hat oder die „Lebenszeit“ TTL (engl. time to live) des Paketes verbraucht ist.
Tabelle 14.2. Spezielle Adressen
| Adressart | Beschreibung |
|---|---|
| Netzwerkbasisadresse | Das ist die Netzmaske UND eine beliebige Adresse aus dem Netz, also das was in Beispiel 14.2. “Verknüpfungen der IP-Adressen mit der Netzmaske” unter Ergebnis abgebildet ist. Diese Adresse kann keinem Rechner zugewiesen werden. |
| Broadcastadresse | Sie heißt soviel wie: „Sprich alle Rechner in diesem Subnetz an“. Um sie zu erzeugen wird die Netzmaske binär invertiert und mit der Netzwerkbasisadresse ODER verknüpft. Obiges Beispiel ergibt also 192.168.0.255. Natürlich kann auch diese Adresse keinem Rechner zugewiesen werden. |
| Localhost | Die Adresse 127.0.0.1 ist auf jedem Rechner fest dem so genannten „Loopbackdevice“ zugewiesen. Über diese Adresse kann man eine Verbindung auf den eigenen Rechner aufbauen. |
Da die IP-Adressen aber weltweit eindeutig sein müssen, können Sie natürlich nicht beliebige Adressen erfinden. Damit Sie aber trotzdem ein auf IP basierendes Netzwerk aufbauen können gibt es drei Adressbereiche, die Sie ohne weiteres verwenden können. Mit diesen können Sie allerdings nicht so ohne weiteres Verbindungen in das Internet aufbauen, da diese Adressen im Internet nicht weitergeleitet werden.
Dabei handelt es sich um diese Adressbereiche die in RFC 1597 definiert sind:
DNS sorgt dafür, dass Sie sich nicht zwingend irgendwelche IP-Adressen merken müssen: Mit Hilfe von DNS kann eine IP-Adresse einem oder sogar mehreren Namen zugeordnet werden und umgekehrt auch eine Name einer IP-Adresse. Unter Linux erfolgt diese Umwandlung üblicherweise von einer speziellen Software namens bind. Der Rechner, der diese Umwandlung dann erledigt, nennt sich Nameserver. Dabei bilden die Namen wieder ein hierarchisches System, in dem die einzelnen Namensbestandteile durch Punkte getrennt sind. Die Namenshierarchie ist aber unabhängig von der oben beschriebenen Hierarchie der IP-Adressen.
Schauen wir uns einmal einen vollständigen Namen an, zum Beispiel laurent.suse.de geschrieben im Format Rechnername.Domain. Ein vollständiger Name – Experten sagen „fully qualified domain name“ oder kurz FQDN dazu – besteht aus einem Rechnernamen und einem Domainteil. Dabei wird der Domainteil aus einem frei wählbaren Anteil – im obigen Beispiel suse – und der so genannten Top level domain, TLD gebildet.
Aus historischen Gründen ist die Zuteilung der TLDs etwas verwirrend. So werden in den USA traditionell dreibuchstabige TLDs verwendet, woanders aber immer die aus zwei Buchstaben bestehenden ISO-Länderbezeichnungen; seit 2000 stehen zusätzliche TLDs für spezielle Sachgebiete mit zum Teil mehr als drei Buchstaben zur Verfügung (zum Beispiel .info, .name, .museum usw.).
In der Frühzeit des Internets (vor 1990) gab es hierzu eine Datei /etc/hosts, in der die Namen aller im Internet vertretenen Rechner gespeichert waren. Dies erwies sich bei der schnell wachsenden Menge von am Internet angeschlossener Rechner als unpraktikabel. Deshalb wurde eine dezentralisierte Datenbank entworfen, die die Rechnernamen verteilt speichern kann. Diese Datenbank, eben jener oben erwähnte Nameserver, hält also nicht die Daten aller Rechner im Internet vorrätig, sondern kann Anfragen an ihm nachgeschaltete, andere Nameserver weiterdelegieren.
An der Spitze der Hierarchie befinden sich die „Root-Nameserver“, die die Top level domains verwalten. Die Root-Nameserver werden vom Network Information Center (NIC) verwaltet. Der Root-Nameserver kennt die jeweils für eine Top level domain zuständigen Nameserver. Im Falle der deutschen Top level domain de ist das DE-NIC für die Domains zuständig, die mit der TLD de aufhören. Mehr Informationen zum DE-NIC erhalten Sie auf der Website http://www.denic.de, mehr Informationen zum Top level domain NIC erfahren Sie unter http://www.internic.net.
Damit auch Ihr Rechner einen Namen in eine IP-Adresse auflösen kann, muss ihm mindestens ein Nameserver mit einer IP-Adresse bekannt sein. Die Konfiguration eines Nameservers erledigen Sie komfortabel mit Hilfe von YaST. Falls Sie eine Einwahl über Modem vornehmen, kann es sein, dass das zur Einwahl verwendete Protokoll die Adresse des Nameservers während der Einwahl mitliefert.
Aber nicht nur Rechnernamen können über DNS aufgelöst werden, DNS kann noch mehr. Zum Beispiel „weiß“ der Nameserver auch, welcher Rechner für eine ganze Domain E-Mails annimmt, der so genannte Mail exchanger (MX).
Die Konfiguration des Nameserverzugriffs unter SUSE LINUX ist im Abschnitt 14.6. “DNS – Domain Name System” beschrieben.
