SlideShare ist ein Scribd-Unternehmen logo
Linux – Advanced

Erweiterte Serverdienste, Netzwerk Monitoring




 I
Linux – Advanced                                                                                                                       1

Inhaltsverzeichnis

1  TCP / IP.............................................................................................................................4
 1.1     Open Systems Interconnection (OSI)-Referenzmodell.............................................4
 1.2     Das TCP/IP-Referenzmodell ....................................................................................6
 1.3     Die TCP/IP-Protokoll-Architektur ..............................................................................8
 1.4     Internet Protokoll (IP)..............................................................................................10
 1.5     Address Resolution Protocol (ARP)........................................................................18
 1.6     Reverse Address Resolution Protocol (RARP).......................................................19
 1.7     Internet Control Message Protocol (ICMP).............................................................20
 1.8     Transmission Control Protocol (TCP) .....................................................................22
 1.9     User Datagram Protocol (UDP) ..............................................................................26
 1.10 Adressierung im TCP/IP .........................................................................................27
 1.11 Subnetze ................................................................................................................28
   1.11.1      Grundlagen .....................................................................................................29
   1.11.2      Vorgehensweise zur Aufteilung in Subnetze ..................................................29
 1.12 Classless Inter Domain Routing (CIDR) .................................................................33
 1.13 Dynamic Host Configuration Protocol (DHCP) .......................................................34
 1.14 Domain Name Service (DNS).................................................................................35
 1.15 Übungsbeispiele .....................................................................................................38
2 Einrichten der Schulungsumgebung ...............................................................................41
 2.1     VMware ..................................................................................................................41
 2.2     Virtual PC ...............................................................................................................44
 2.3     QEMU .....................................................................................................................50
 2.4     Netzwerk – Installation ...........................................................................................53
 2.5     Übungsbeispiele .....................................................................................................60
3 Serverdienste ..................................................................................................................61
 3.1     Network File Service (NFS) ....................................................................................61
   3.1.1       NFS - Server...................................................................................................61
   3.1.2       NFS – Client ...................................................................................................64
 3.2     DHCP – Server .......................................................................................................68
 3.3     DNS – Server .........................................................................................................72
   3.3.1       Forward Zone .................................................................................................75
   3.3.2       Reverse-Lookup .............................................................................................78
   3.3.3       Master- und Secondaryzonen.........................................................................80
   3.3.4       Diagnose.........................................................................................................81
 3.4     Samba Grundkonfiguration.....................................................................................84
   3.4.1       Swat................................................................................................................88
 3.5     Apache2 .................................................................................................................91
 3.6     Postfix .....................................................................................................................95
 3.7     Qpopper..................................................................................................................98
 3.8     Übungsbeispiele .....................................................................................................99
4 Netzwerk Monitoring .....................................................................................................101
 4.1     ifconfig ..................................................................................................................101
 4.2     netstat...................................................................................................................102
 4.3     ping.......................................................................................................................105
 4.4     bing.......................................................................................................................106
 4.5     fping......................................................................................................................106
 4.6     traceroute .............................................................................................................106
 4.7     nslookup ...............................................................................................................107
 4.8     iptraf......................................................................................................................107
 4.9     nmap.....................................................................................................................108
 4.10 tcpdump ................................................................................................................113
 4.11 ethereal.................................................................................................................113
 4.12 ntop.......................................................................................................................116
Linux – Advanced                                                                                                                    2

    4.13 Nessus..................................................................................................................117
    4.14 Übungsbeispiele ...................................................................................................121
5     Server Security..............................................................................................................123
    5.1     SuSE Sicherheitseinstellugen...............................................................................123
    5.2     SuSE Firewall .......................................................................................................124
    5.3     Webmin ................................................................................................................127
    5.4     Apache mit mod_ssl .............................................................................................128
    5.5     Übungsbeispiele ...................................................................................................129
6     Stichwortverzeichnis .....................................................................................................130
7     Abbildungsverzeichnis ..................................................................................................131
8     Tabellenverzeichnis ......................................................................................................134
9     Literaturverzeichnis .......................................................................................................135
Linux – Advanced                                                                                3


Vorwort

LINUX, das Unix ähnliche System von Linus Torvald, ist zu einer echten Alternative für
Schulen gereift. Speziell für Schulen bietet ein solches System viele Vorteile. Abgesehen von
der günstigen Anschaffung und des geringen Wartungsaufwandes gibt es eine Vielzahl von
Erweiterungen, die das schulische Arbeiten erleichtern.

Ich habe versucht eine Installation von Opensuse 10 Beta2 für eine Schulumgebung mit
erweiterten Serverdiensten zu beschreiben.

Neben den Serverdiendiensten, wird das Hauptaugenmerk auf die Fehlersuche im eigenen
lokalen Netzwerk gelegt. Die meisten der vorgestellten Tools funktionieren übrigens nicht nur
unter Linux, sondern können auch für Windows verwendet werden.

Vor der endgültigen Installation empfiehlt es sich, ein Testsystem zu erstellen. Dafür reicht
ein einfacher PC oder eine virtuelle Arbeitsumgebung wie zum Beispiel VMware, Virtual PC
oder das freie QEMU. Erst wenn alles getestet wurde, sollte ein Echtsystem installiert
werden.

LINUX ist ein sich schnell weiter entwickelndes Betriebssystem. Opensuse zum Beispiel
bringt wöchentlich am Donnerstag neue Releasis heraus.

Dieses Buch baut auf das Wissen des Buches Vogl, H. Der Linux Schulserver auf.

Auch dieses Buch ist einem ständigen Veränderungsprozess unterworfen. Über Anregungen
und Verbesserungsvorschläge würde ich mich sehr freuen.

Heiko Vogl

heiko.vogl@gmx.at

Graz, 2005
Linux – Advanced                                                                                 4


1 TCP / IP

1.1       Open Systems Interconnection (OSI)-Referenzmodell

Das Open Systems Interconnection (OSI)-Referenzmodell ist ein Modell, dass auf einem
Vorschlag der International Standards Organisation (ISO) basiert. Der Aufbau des OSI-
Modells ist in der folgenden Abbildung dargestellt.




Abbildung 1: OSI-Referenzmodell


Das Modell dient derzeit allgemein als Rahmen zur Beschreibung von
Protokollcharakteristika und –funktionen. Das OSI-Modell (die offizielle Bezeichnung lautet
ISO-OSI-Referenzmodell) besteht aus sieben Schichten. Die Schichtung beruht auf dem
Prinzip, dass eine Schicht der jeweils über ihr angeordneten Schicht bestimmte
Dienstleistungen anbietet. Das OSI-Modell ist keine Netzarchitektur, da die Protokolle und
Dienste der einzelnen Schichten vom Modell nicht definiert werden. Das Modell beschreibt
lediglich, welche Aufgaben die Schichten erledigen sollen. Die folgenden Prinzipien haben
zur Siebenschichtigkeit des OSI-Modells geführt:

      •    Eine neue Schicht soll dort entstehen, wo ein neuer Abstraktionsgrad benötigt wird.

      •    Jede Schicht soll eine genau definiert Funktion erfüllen.

      •    Bei der Funktionswahl soll die Definition international genormter Protokolle
           berücksichtigt werden.
Linux – Advanced                                                                             5


    •   Die Grenzen zwischen den einzelnen Schichten sollen so gewählt werden, dass der
        Informationsfluss über die Schnittstellen möglichst gering ist.

    •   Die Anzahl der Schichten soll so groß sein, dass keine Notwendigkeit besteht,
        verschiedene Funktionen in eine Schicht zu packen. Aber auch nicht so klein, dass
        die gesamte Architektur unhandlich wird.

Den Schichten im OSI-Modell sind die folgenden Aufgaben zugeordnet:

Anwendungsschicht (application layer)
Die Anwendungsschicht enthält eine große Zahl häufig benötigter Protokolle, die einzelne
Programme zur Erbringung ihrer Dienste definiert haben. Auf der Anwendungsschicht finden
sich z.B. die Protokolle für die Dienste ftp, telnet, mail etc.

Darstellungsschicht (presentation layer)
Die Darstellungsschicht regelt die Darstellung der Übertragungsdaten in einer von der
darüber liegenden Ebene unabhängigen Form. Computersysteme verwenden z.B. oft
verschiedene Codierungen für Zeichenketten (z.B. ASCII, Unicode), Zahlen usw. Damit
diese Daten zwischen den Systemen ausgetauscht werden können, kodiert die
Darstellungsschicht die Daten auf eine standardisierte und vereinbarte Weise.

Sitzungsschicht (session layer)
Die Sitzungsschicht (oft auch Verbindungsschicht oder Kommunikationssteuerschicht
genannt) ermöglicht den Verbindungsauf- und abbau. Von der Sitzungsschicht wird der
Austausch von Nachrichten auf der Transportverbindung geregelt. Sitzungen können
beispielsweise einen Transfer gleichzeitig in zwei oder nur eine Richtung ermöglichen. Kann
der Transfer nur in eine Richtung stattfinden, regelt die Sitzungsschicht, welcher der
Kommunikationspartner jeweils an die Reihe kommt.

Transportschicht (transport layer)
Die Transportschicht übernimmt den Transport von Nachrichten zwischen den
Kommunikationspartnern. Sie hat die grundlegende Aufgabe, den Datenfluss zu steuern und
die Unverfälschtheit der Daten sicherzustellen. Beispiele für Transportprotokolle sind TCP
und UDP.

Netzwerkschicht (network layer)
Die Netzwerkschicht (Vermittlungsschicht) hat die Hauptaufgabe eine Verbindung zwischen
Knoten im Netzwerk herzustellen. Die Netzwerkschicht soll dabei die übergeordneten
Schichten von den Details der Datenübertragung über das Netzwerk befreien. Eine der
wichtigsten Aufgaben der Netzwerkschicht ist z.B. die Auswahl von Paketrouten bzw. das
Linux – Advanced                                                                               6

Routing vom Absender zum Empfänger. Das Internet Protokoll (IP) ist in die Netzwerkschicht
einzuordnen.

Sicherungsschicht (data link layer)
Die Aufgabe der Sicherungsschicht (Verbindungsschicht) ist die gesicherte Übertragung von
Daten. Vom Sender werden hierzu die Daten in Rahmen (frames) aufgeteilt und sequentiell
an den Empfänger gesendet. Vom Empfänger werden die empfangenen Daten durch
Bestätigungsrahmen quittiert. Protokollbeispiele für die Sicherungsschicht sind HDLC (high-
level data link control), SLIP (serial line IP) und PPP (point-to-point Protokoll).

Bitübertragungsschicht (physical layer)
Die Bitübertragungsschicht regelt die Übertragung von Bits über das Übertragungsmedium.
Dies betrifft die Übertragungsgeschwindigkeit, die Bit-Codierung, den Anschluss (wieviele
Pins hat der Netzanschluss?) etc. Die Festlegungen der Bitübertragungsschicht betreffen im
Wesentlichen die Eigenschaften des Übertragungsmediums.

1.2       Das TCP/IP-Referenzmodell

Im vorhergehenden Abschnitt wurde das OSI-Referenzmodell vorgestellt. In diesem
Abschnitt soll nun das Referenzmodell für die TCP/IP-Architektur vorgestellt werden. Das
TCP/IP-Referenzmodell, benannt nach den beiden primären Protokollen TCP und IP der
Netzarchitektur, beruht auf den Vorschlägen, die bei der Fortentwicklung des ARPANETs
gemacht wurden. Das TCP/IP-Modell ist zeitlich vor dem OSI-Referenzmodell entstanden.
Die Erfahrungen des TCP/IP-Modells sind in die OSI-Standardisierung eingeflossen. Das
TCP/IP-Referenzmodell besteht im Gegensatz zum OSI-Modell aus vier Schichten:
Application Layer, Transport Layer, Internet Layer, Network Layer. Als Ziele der Architektur
wurden bei der Entwicklung definiert:

      •    Unabhängigkeit von der verwendeten Netzwerk-Technologie.

      •    Unabhängigkeit von der Architektur der Hostrechner.

      •    Universelle Verbindungsmöglichkeiten im gesamten Netzwerk.

      •    Ende-zu-Ende-Quittungen.

      •    Standardisierte Anwendungsprotokolle.
Linux – Advanced                                                                              7




Abbildung 2: Vergleich des OSI-Referenzmodells mit dem TCP/IP-Referenzmodell


Applikationsschicht (application layer)
Die Applikationsschicht (auch Verarbeitungsschicht genannt) umfasst alle höherschichtigen
Protokolle des TCP/IP-Modells. Zu den ersten Protokollen der Verarbeitungsschicht zählen
TELNET (für virtuelle Terminals), FTP (Dateitransfer) und SMTP (zur Übertragung von E-
Mails). Im Laufe der Zeit kamen zu den etablierten Protokollen viele weitere Protokolle wie
z.B. DNS (Domain Name Service) und HTTP (Hypertext Transfer Protocol) hinzu.

Transportschicht (transport layer)
Wie im OSI-Modell ermöglicht die Transportschicht die Kommunikation zwischen den Quell-
und Zielhosts. Im TCP/IP-Referenzmodell wurden auf dieser Schicht zwei Ende-zu-Ende-
Protokolle definiert: das Transmission Control Protocol (TCP) und das User Datagram
Protocol (UDP). TCP ist ein zuverlässiges verbindungsorientiertes Protokoll. Dadurch kann
ein Bytestrom fehlerfrei einem anderen Rechner im Internet übermittelt werden. UDP ist ein
unzuverlässiges, verbindungsloses Protokoll, das vorwiegend für Abfragen und
Anwendungen in Client/Server-Umgebungen verwendet wird. Es dient nicht um eine sehr
genaue, sondern schnelle Datenübermittlung geht (z.B. Übertragung von Sprache und
Bildsignalen).

Internetschicht (internet layer)
Die Internetschicht im TCP/IP-Modell definiert ein Protokoll namens IP (Internet Protocol),
das alle am Netzwerk beteiligten Rechner verstehen können. Die Internetschicht hat die
Aufgabe IP-Pakete richtig zuzustellen. Dabei spielt das Routing der Pakete eine wichtige
Rolle. Das Internet Control Message Protocol (ICMP) ist fester Bestandteil jeder IP-
Linux – Advanced                                                                              8

Implementierung und dient zur Übertragung von Diagnose- und Fehlerinformationen für das
Internet Protocol.

Netzwerkschicht (network layer)
Unterhalb der Internetschicht befindet sich im TCP/IP-Modell eine große Definitionslücke.
Das Referenzmodell sagt in dieser Ebene nicht viel darüber aus, was hier passieren soll.
Festgelegt ist lediglich, dass zur Übermittlung von IP-Paketen ein Host über ein bestimmtes
Protokoll an ein Netz angeschlossen werden muss. Dieses Protokoll ist im TCP/IP-Modell
nicht weiter definiert und weicht von Netz zu Netz und Host zu Host ab. Das TCP/IP-Modell
macht an dieser Stelle vielmehr Gebrauch von bereits vorhandenen Protokollen, wie z.B.
Ethernet (IEEE 802.3), Serial Line IP (SLIP), etc.

1.3   Die TCP/IP-Protokoll-Architektur




Abbildung 3: Die TCP/IP-Protokoll-Architektur



Die TCP/IP-Architektur wird im Allgemeinen als vierschichtiges Modell beschrieben. Oft wird
Linux – Advanced                                                                            9

das TCP/IP-Referenzmodell auch als fünfschichtiges Modell dargestellt.




Abbildung 4: OSI-Referenzmodell, TCP/IP-Referenzmodell, Hybrides Referenzmodell


Die Schichtung beruht auf dem Prinzip, dass eine Schicht die angebotenen Dienste der
darunter liegenden Schicht in Anspruch nehmen kann. Dabei braucht jene Schicht, die die
Dienstleistung in Anspruch nimmt, keinerlei Kenntnisse darüber haben, wie die geforderten
Dienste erbracht werden. Auf diese Art und Weise wird eine Aufgabenteilung der Schichten
erreicht. Daten, die von einem Applikationsprogramm über ein Netzwerk versendet werden,
durchlaufen den TCP/IP-Protokollstapel von der Applikationsschicht zur Netzwerkschicht.
Von jeder Schicht werden dabei Kontrollinformationen in Form eines Protokollkopfes
angefügt. Diese Kontrollinformationen dienen der korrekten Zustellung der Daten. Das
Zufügen von Kontrollinformationen wird als Einkapselung (encapsulation) bezeichnet.




Abbildung 5: Dateneinkapselung
Linux – Advanced                                                                          10

Innerhalb der Schichten des TCP/IP-Modells werden Daten mit verschiedenen Termini
benannt, da jede Schicht auch ihre eigenen Datenstrukturen hat. Applikationen, die das
Transmission Control Protocol benutzen, bezeichnen Daten als Strom (stream);
Applikationen, die das User Datagram Protocol verwenden, bezeichnen Daten als Nachricht
(message). Auf der Transportebene bezeichnen die Protokolle TCP und UDP ihre Daten als
Segment (segment) bzw. Paket (packet). In der Internet Schicht werden Daten allgemein als
Datengramm (datagram) benannt. Oft werden die Daten hier aber auch als Paket
bezeichnet. Auf der Netzwerkebene bezeichnen die meisten Netzwerke ihre Daten als
Pakete oder Rahmen (frames).




Abbildung 6: Datenbezeichnung des TCP/IP-Modells


1.4   Internet Protokoll (IP)

Die Vermittlungsschicht im Internetprotokoll kann Datagramme nur an einen direkt
erreichbaren Router senden. Wir verwenden hier das folgende einfache Modell für die
Kommunikation im Internetprotokoll:




Abbildung 7: IP Kommunikation


Eine Station ist entweder ein Router zwischen Netzen oder eine Datenendeinrichtung, die
ein Datagramm nur absenden oder empfangen kann. Da das Internetprotokoll einen von evtl.
mehreren direkt erreichbaren Routern auswählen muss, wurden mehrere Partnerstationen
dargestellt.
Linux – Advanced                                                                            11

Datenübertragung mit Datagrammen

Ähnlich dem Paket im X.25/PLP hat auch ein Datagramm im IP einen festen Aufbau,
bestehend aus einem Datagrammkopf (Datagram Header) und einem Datenbereich (Data
Area).




Abbildung 8: Datagrammkopf


Im Internet werden die Datagramme nicht direkt zwischen Routern verschickt, sondern in der
Regel in einen Block eingepackt, der sie an den nächsten Rechner transportiert; dieser Block
kann z.B. ein Ethernet- oder ein FDDI-Rahmen sein. Hieraus resultiert die Forderung, dass
Datagramme nicht beliebig lang sein dürfen. Ein effizienter Transport kann nur garantiert
werden, wenn jedes Datagramm in einen Rahmen passt. Die Größe eines solchen Rahmens
ist jedoch von Netz zu Netz verschieden, so dass die Größe der Datagramme den
Rahmengrößen der Netze, an die der jeweilige Rechner angeschlossen ist, angepasst sein
sollte. Der Aufbau eines Rahmens mit Datagramm kann dann folgendermaßen dargestellt
werden:
Linux – Advanced                                                                         12




Abbildung 9: Datagramm


Diese Forderung ist jedoch im allgemenen nicht zu erfüllen, da diese Größen zwischen
128 Bytes (in X.25-Netzen) und 4500 Bytes (in FDDI-Ringen) schwanken können, und zu
kleine Datagramme wegen des recht großen Datagrammkopfes ineffizient sind. Daher legt
das Internetprotokoll fest, dass das Netz Datagramme bis zu einer Länge von 576 Oktetten
effizient übertragen muss. Wenn das Netz Rahmen mit Blöcken einer gegebenen Größe
nicht übertragen kann, so darf es die Datagramme fragmentieren (fragment), d.h. in kürzere
Blöcke zerlegen. Dabei enthält jeder Block neben einer Dateninformation auch den
gesamten Datagrammkopf.
Linux – Advanced                                                                         13




Abbildung 10: Datagramme fragmentieren


Ein einmal fragmentiertes Datagramm wird auf seinem Weg zum Empfänger nicht wieder
zusammengesetzt (reassemble), sondern unverändert weitergeschickt. Hierbei können
durchaus verschiedene Wege für unterschiedliche Fragmente gewählt werden. Da jedes
Fragment die gesamte notwendige Zielinformation enthält, können alle Zwischenstationen
den richtigen Weg wählen. Sollten Fragmente eines Datagramms verloren gehen, so gilt das
gesamte Datagramm als verloren und jene Teile, die den Empfänger evtl. erreichen, werden
vernichtet. Die Information, ob ein Datagramm fragmentiert wurde, und in welcher
Reihenfolge die Fragmente zusammengehören, muss natürlich gleichfalls im
Datagrammkopf verschlüsselt werden.




Abbildung 11: Datagramm wird reassembliert
Linux – Advanced                                                                          14

Ein Datagramm wird reassembliert, indem ein eintreffendes Fragment anhand von
Absenderadresse und einer Identifikation einem Datagramm zugeordnet wird. Anhand des
Feldes Fragmentabstand FA kann die Position im gesamten Fragment, anhand des
Längenfeldes GL die Länge des Datenteils berechnet werden. Dabei liegt der Anfang des
Datenfragments bei FA*8, das Ende bei FA*8+(GL-20)-1. Die reassemblierende Station
muss erkennen können, wann alle Fragmente eines Datagramms eingetroffen sind.
Geschieht dieses nicht innerhalb einer bestimmten Zeit (z.B. 1 Minute), so wird das
Datagramm beim Empfänger verworfen.

IP-Datengramm

Die TCP/IP-Protokolle wurden entwickelt, um Daten über ein paketvermittelndes Netz (wie
dem ARPANET) zu übertragen. Ein Paket ist ein Datenblock zusammen mit den
Informationen, die notwendig sind, um sie dem Empfänger zuzustellen (ein Paket ist also
nichts anderes als ein Paket im herkömmliche Sinn bei der Post - das Paket enthält die
Daten, auf dem Paket ist die Adresse des Empfängers notiert). Das Datengramm (datagram)
ist das Paketformat, das vom Internet Protokoll definiert ist. Ein IP-Datengramm besteht aus
einem Header und den zu übertragenden Daten. Der Header hat einen festen 20 Byte
großen Teil, gefolgt von einem optionalen Teil variabler Länge. Der Header umfasst alle
Informationen, die notwendig sind, um das Datengramm dem Empfänger zuzustellen. Ein
Datengramm kann theoretisch maximal 64 KByte groß sein, in der Praxis liegt die Größe
ungefähr bei 1500 Byte (das hängt mit der maximalen Rahmengröße des Ethernet-Protokolls
zusammen).




Abbildung 12: Der IP-Header
Linux – Advanced                                                                               15

Die Felder, des in der Abbildung dargestellten Protokollkopfes, haben die folgende
Bedeutung:

Version
Das Versions-Feld enthält die Versionsnummer des IP-Protokolls. Durch die Einbindung der
Versionsnummer besteht die Möglichkeit über eine längere Zeit mit verschiedenen Versionen
des IP Protokolls zu arbeiten. Einige Hosts können mit der alten und andere mit der neuen
Version arbeiten. Die derzeitige Versionsnummer ist 4, aber die Version 6 des IP Protokolls
befindet sich bereits in der Erprobung.

Length
Das Feld Length (Internet Header Length - IHL) enthält die Länge des Protokollkopfs, da
diese nicht konstant ist. Die Länge wird in 32-Bit-Werten angegeben. Der kleinste zulässige
Wert ist 5 - das entspricht also 20 Byte. In diesem Fall sind im Header keine Optionen
gesetzt. Die Länge des Headers kann sich durch Anfügen von Optionen aber bis auf 60 Byte
erhöhen.

Type of Servive
Über das Feld Type of Service kann das IP angewiesen werden Nachrichten nach
bestimmten Kriterien zu behandeln. Als Dienste sind hier verschiedene Kombinationen aus
Zuverlässigkeit und Geschwindigkeit möglich. In der Praxis wird dieses Feld aber ignoriert,
hat also den Wert 0. Das Feld selbst hat den folgenden Aufbau:




Abbildung 13: Type of Service


Precedence (Bits 0-2) gibt die Priorität von 0 (normal) bis 7 (Steuerungspaket) an. Die drei
Flags (D,T,R) ermöglichen es dem Host anzugeben, worauf er bei der Datenübertragung am
meisten Wert legt: Verzögerung (Delay - D), Durchsatz (Throughput - T), Zuverlässigkeit
(Reliability - R). Die beiden anderen Bit-Felder sind reserviert.

Total Length
Enthält die gesamte Paketlänge, d.h. Header und Daten. Da es sich hierbei um ein 16-Bit-
Feld handelt ist die Maximallänge eines Datengramms auf 65.535 Byte begrenzt. In der
Spezifikation von IP (RFC 791) ist festgelegt, dass jeder Host in der Lage sein muss, Pakete
bis zu einer Länge von 576 Bytes zu verarbeiten. In der Regel können von dem Host aber
Pakete größerer Länge verarbeitet werden.
Linux – Advanced                                                                             16

Identification
Über das Identifikationsfeld kann der Zielhost feststellen, zu welchem Datengramm ein neu
angekommenes Fragment gehört. Alle Fragmente eines Datengramms enthalten die gleiche
Identifikationsnummer, die vom Absender vergeben wird.

Flags
Das Flags-Feld ist drei Bit lang. Die Flags bestehen aus zwei Bits namens DF (Don't
Fragment) und MF (More Fragments). Das erste Bit des Flags-Feldes ist ungenutzt bzw.
reserviert. Die beiden Bits DF und MF steuern die Behandlung eines Pakets im Falle einer
Fragmentierung. Mit dem DF-Bit wird signalisiert, dass das Datengramm nicht fragmentiert
werden darf. Auch dann nicht, wenn das Paket eventuell nicht mehr weiter transportiert
werden kann und verworfen werden muss. Alle Hosts müssen Fragmente bzw.
Datengramme mit einer Größe von 576 Bytes oder weniger verarbeiten können. Mit dem
MF-Bit wird angezeigt, ob einem IP-Paket weitere Teilpakete nachfolgen. Dieses Bit ist bei
allen Fragmenten, außer dem letzten gesetzt.

Fragment Offset
Der Fragmentabstand bezeichnet, an welcher Stelle, relativ zum Beginn des gesamten
Datengramms, ein Fragment gehört. Mit Hilfe dieser Angabe kann der Zielhost das
Originalpaket wieder aus den Fragmenten zusammensetzen. Da dieses Feld nur 13 Bit groß
ist, können maximal 8192 Fragmente pro Datengramm erstellt werden. Alle Fragmente,
außer dem letzten, müssen ein Vielfaches von 8 Byte sein. Dies ist die elementare
Fragmenteinheit.

Time to Live
Das Feld Time to Live ist ein Zähler, mit dem die Lebensdauer von IP-Paketen begrenzt
wird. Im RFC 791 ist für dieses Feld als Einheit Sekunden spezifiziert. Zulässig ist eine
maximale Lebensdauer von 255 Sekunden (8 Bit). Der Zähler muss von jedem Netzknoten,
der durchlaufen wird, um mindestens 1 verringert werden. Bei einer längeren
Zwischenspeicherung in einem Router muss der Inhalt sogar mehrmals verringert werden.
Enthält das Feld den Wert 0, muss das Paket verworfen werden. Damit wird verhindert, dass
ein Paket endlos in einem Netz umherwandert. Der Absender wird in einem solchen Fall
durch eine Warnmeldung in Form einer ICMP-Nachricht informiert.

Protocol
Enthält die Nummer des Transportprotokolls, an das das Paket weitergeleitet werden muss.
Die Nummerierung von Protokollen ist im gesamten Internet einheitlich. Bisher wurden die
Protokollnummern im RFC 1700 definiert. Diese Aufgabe ist nun von der Internet Assigned
Linux – Advanced                                                                             17

Numbers Authority1 (IANA) übernommen worden. Bei UNIX-Systemen sind die
Protokollnummern in der Datei /etc/protocols abgelegt.

Header Checksum
Dieses Feld enthält die Prüfsumme der Felder im IP-Header. Die Nutzdaten des IP-
Datengramms werden aus Effizienzgründen nicht mit geprüft. Diese Prüfung findet beim
Empfänger innerhalb des Transportprotokolls statt. Die Prüfsumme muss von jedem
Netzknoten, der durchlaufen wird, neu berechnet werden, da der IP-Header durch das Feld
Time-to-Live sich bei jeder Teilstrecke verändert.

Source Address, Destination Address
In diese Felder werden die 32-Bit langen Internet-Adressen eingetragen.

Options und Padding
Das Feld Options wurde im Protokollkopf aufgenommen, um die Möglichkeit zu bieten, das
IP-Protokoll um weitere Informationen zu ergänzen, die im ursprünglichen Design nicht
berücksichtigt wurden. Das Optionsfeld hat eine variable Länge. Jede Option beginnt mit
einem Code von einem Byte, über den die Option identifiziert wird. Manchen Optionen folgt
ein weiteres Optionsfeld von 1 Byte und dann ein oder mehrere Datenbytes für die Option.
Das Feld Options wird über das Padding auf ein Vielfaches von 4 Byte aufgefüllt. Derzeit
sind die folgenden Optionen bekannt:

      •   End of Option List (Kennzeichnet das Ende der Optionsliste)

      •   No Option (Kann zum Auffüllen von Bits zwischen Optionen verwendet werden)

      •   Security (Bezeichnet, wie geheim ein Datengramm ist. In der Praxis wird diese Option
          jedoch fast immer ignoriert.)

      •   Loose Source-Routing, Strict Source-Routing (Diese Option enthält eine Liste von
          Internet-Adressen, die das Datagramm durchlaufen soll. Auf diese Weise kann dem
          Datenpaket vorgeschrieben werden eine bestimmte Route durch das Internet zu
          nehmen. Beim Source-Routing wird zwischen Strict Source and Record Route und
          Loose Source and Record Route unterschieden. Im ersten Fall wird verlangt, dass
          das Paket diese Route genau einhalten muss. Desweiteren wird die genommene
          Route aufgezeichnet. Die zweite Variante schreibt vor, dass die angegebenen Router
          nicht umgangen werden dürfen. Auf dem Weg können aber auch andere Router
          besucht werden.)

1
    http://www.iana.org
Linux – Advanced                                                                               18


      •    Record Route (
           Die Knoten, die dieses Datengramm durchläuft, werden angewiesen ihre IP-Adresse
           an das Optionsfeld anzuhängen. Damit lässt sich ermitteln, welche Route ein
           Datengramm genommen hat. Wie anfangs schon gesagt, ist die Größe für das
           Optionsfeld auf 40 Byte beschränkt. Deshalb kommt es heute auch oftmals zu
           Problemen mit dieser Option, da weit mehr Router durchlaufen werden, als dies zu
           Beginn des ARPANET der Fall war.)

      •    Time Stamp (Diese Option ist mit der Option Record Route vergleichbar. Zusätzlich
           zur IP-Adresse wird bei dieser Option die Uhrzeit des Durchlaufs durch den Knoten
           vermerkt. Auch diese Option dient hauptsächlich zur Fehlerbehandlung, wobei
           zusätzlich z.B. Verzögerungen auf den Netzstrecken erfasst werden können.)

Weitere Details zu den Optionen sind in RFC 791 zu finden.

1.5       Address Resolution Protocol (ARP)

In lokalen Netzen wird zur Bindung einer Protokolladresse mit einer Hardwareadresse meist
das Address Resolution Protocol (ARP) verwendet, welches in RFC 826 standardisiert ist. Es
wird ein ARP-Format definiert, welches für beliebige Adressformate gelten soll.




Abbildung 14: ARP


ARP-Nachrichten im Ethernet werden anhand des Ethernet-Typ-Feldes (Kennung 80616)
kenntlich gemacht. Anfragen und Antworten werden durch unterschiedliche Einträge im
Operationsfeld dargestellt.

In der Regel besitzt jeder Rechner einen Speicher für Adressbindungen (Cache), in welchem
die entsprechenden Adressen abgelegt sind. Sobald er ein Paket an einen anderen Rechner
senden muss, untersucht der Rechner, ob sich die Protokolladresse in diesem Speicher
befindet. Ist dieses der Fall, so wird das IP-Datagramm in ein Frame verpackt. Dieses wird
Linux – Advanced                                                                            19

mit der entsprechenden Zieladresse versehen. Ist das nicht der Fall, muss eine
Adressauflösung durchgeführt werden.

Dazu sendet der Rechner eine beschränkte Rundspruch-Nachricht an alle anderen Rechner
im eigenen Netz aus, in die er im ARP-Format seine eigene Internet- und Hardwareadresse
einfügt. Das Operationsfeld ist auf Anfrage (Wert=1) gesetzt. Der angesprochene Rechner
erkennt als einziger seine Internetadresse und liefert in einem Frame dem anfragenden
Rechner seine Hardware- und Internetadressen (falls er mehrere besitzt) zurück. Dazu wird
das Protokollfeld auf Antwort (Wert = 2) gesetzt. Außerdem verwendet er die
Senderadressen, um eine eigene Bindung herzustellen, da er vermutlich, auf ein demnächst
von diesem Rechner zu erwartendes Paket, eine Antwort zu senden hat. Auf diese Weise
wird der ARP-Verkehr optimiert.

Der Cache für die Adressbindung wird in gewissen zeitlichen Abständen (z.B. 20 Minuten)
gelöscht, um Änderungen im Netz besser folgen zu können. Daher würde auch eine
überflüssige Speicherung einer Bindung bald wieder korrigiert werden.

Meldet sich auf eine ARP-Anfrage kein Rechner, so ist dieser entweder abgestellt oder er
befindet sich in einem anderen physikalischen Netz. Dann sollte der Router dieses
feststellen. Er kann dann seine eigene Hardwareadresse zurücksenden und das folgende
Paket weitersenden.

1.6   Reverse Address Resolution Protocol (RARP)

Um zu einer bekannten physikalischen Adresse die Internetadresse zu finden, wird das
Reverse Address Resolution Protocol (RARP) verwendet. Es ist in RFC 903 standardisiert.
Dieses Problem tritt auf, wenn Arbeitsrechner ohne Plattenspeicher (Diskless Workstation)
eingeschaltet werden. Sie können zwar ihre Netzhardware nach ihrer physikalischen
Hardwareadresse abfragen, aber ihre Internetadresse ist ihnen unbekannt. Durch Senden
der physikalischen Adresse als Rundspruch-Nachricht können sie ihren Server auffordern,
ihnen ihre Internetadresse mitzuteilen.
Linux – Advanced                                                                              20




Abbildung 15: RARP


Das RARP-Protokoll verwendet das gleiche Datenformat wie ARP, benutzt jedoch den
Operationswert 3 für Anfragen und 4 für Antworten. In der Anfrage wird in der Regel nur die
Hardwareadresse des Absenders gesetzt. Alle anderen Werte sind undefiniert (u.U. wird
auch die Hardwareadresse des Empfängers gesetzt, ersatzweise ist deren Wert gleich der
des Absenders.) Ein RARP-Server erkennt die Anfrage und setzt sowohl seine Bindung ein
(um eine zusätzliche ARP-Anfrage zu vermeiden), als auch die Bindung des Empfängers.
Das Operationsfeld wird auf den Wert 4 gesetzt. Auf diese Weise erhält der Empfänger die
gewünschte Information.

1.7   Internet Control Message Protocol (ICMP)

Das Internet Control Message Protocol (ICMP) benutzt wie TCP und UDP das Internet
Protocol IP, ist also ein Teil der Internet-Protokoll-Familie. Es dient in Netzwerken zum
Austausch von Fehler- und Informationsmeldungen.

Obwohl ICMP eine Ebene über IP angeordnet ist, ist es in IP integriert. Es wird von jedem
Router und PC erwartet, ICM-Protokoll zu sprechen. Die meisten ICMP-Pakete enthalten
Diagnose-Informationen. Sie werden vom Router zur Quelle (source) zurückgeschickt, wenn
der Router Pakete verwirft. (z.B. weil das Ziel (destination) nicht erreichbar ist, die TTL
abgelaufen ist, usw.) Es gilt der Grundsatz, dass ein ICMP-Paket niemals ein anderes ICMP-
Paket auslöst, d.h. die Tatsache, dass ein ICMP Paket nicht zugestellt werden konnte wird
nicht durch ein Weiteres signalisiert. Eine Ausnahme zu diesem Grundsatz bildet die Echo-
Funktion. Echo-ICMP-Pakete werden z.B. durch das Programm Ping verschickt.

ICMP-Nachrichten werden beim Versand im Datenteil von IP-Datagrammen eingekapselt.
Dabei sind im IP-Header der Servicetyp immer 0 und die Protokollnummer immer 1.
Linux – Advanced                                                                 21




Abbildung 16: ICMP Paket

Tabelle 1: ICMP Typ - Code-Kombinationen



Typ                 Typname                Code                  Bedeutung



0      Echo Reply                      0          Echo Reply



3      Destination Unreachable         1          Host Unreachable



                                       3          Port Unreachable



                                       4          Fragmentation Needed, DF Set



8      Echo Request                    0          Echo Request



11     Time Exceeded                   0          TTL Exceeded



                                       1          Fragment Reassembly Timeout



30     Traceroute                                 Traceroute



33     IPv6 Where-Are-You                         IPv6 Where-Are-You
Linux – Advanced                                                                             22



34         IPv6 I-Am-Here                             IPv6 I-Am-Here



1.8       Transmission Control Protocol (TCP)

TCP (Transmission Control Protocol) hat die folgenden Merkmale.

      •    Verbindungsorientiert
           Zwischen den kommunizierenden Stationen ist vor der Übermittlung von Information
           eine virtuelle Verbindung aufzubauen und nach der Kommunikation wieder
           abzubauen.

      •    Duplex-Verbindung
           Beide Anwendungsprozesse können unabhängig voneinander Daten übermitteln.

      •    Punkt-zu-Punkt
           TCP überträgt Daten zwischen genau zwei Teilnehmern mit symmetrischen Rechten.

      •    Zuverlässigkeit
           TCP garantiert dem Benutzer eine hohe Zuverlässigkeit der Datenübermittlung
           bezüglich Verfälschung und Verlust von Daten.

      •    Stromorientiert
           Jede Folge von Bytes, die der Sender abschickt, wird unverändert (d.h. gleiche Bytes
           und gleiche Reihung) dem Empfänger übermittelt.

      •    Gepufferte Übertragung
           Daten werden byteweise an die Kommunikationsinstanz geliefert, welche diese in
           Paketen sammelt und selbsttätig übermittelt. Durch einen Push-Mechanismus kann
           der Sender das System zwingen, alle bisher abgesetzten Daten unverzüglich dem
           Empfänger abzuliefern.

      •    Unstrukturierter Strom
           Die Anwendungsprozesse müssen die Struktur ihres Datenstroms selbst vereinbaren
           und überwachen. TCP unterstützt nicht die Segmentierung der Information in
           Datensätze.

      •    Zuverlässiger Verbindungsauf- und abbau
           Verbindungen erhalten auch dann keine verfälschten Daten, wenn sie kurz
Linux – Advanced                                                                            23

         nacheinander mit der gleichen Portnummer aufgebaut werden.Beim Abbau werden
         Daten auch dann zuverlässig übertragen, wenn eine Seite die Verbindung abbaut,
         ehe alle Daten beim Empfänger eingetroffen sind. Jeder Empfänger kann seine
         Verbindung unabhängig von der Gegenstelle schließen.

TCP-Header

Zur Identifizierung einer Verbindung sieht TCP einen Header vor. Dieser kennzeichnet die
Port-Adressen von Quell- und Zielrechner in jedem Segment. Ports müssen von den
Anwenderprozessen bei jedem Aufruf der entsprechenden Betriebssystemroutinen
angegeben werden. Die Werte dieser Portnummern sind teilweise festgelegt, z.B. für
elektronische Post (25) oder remote job entry (5). Andere Portnummern sind jedoch frei
vereinbar und können vom Betriebssystem beliebig vergeben werden. Eine Liste der
Portnummer findet sich in dem RFC "Assigned Numbers" (Internet-Standard 2, zur Zeit RFC
1700).




Abbildung 17: TCP-Segment


Die Folgenummer gibt die Lage dieser Daten in dem Datenstrom des Senders an. Die
Quittungsnummer ist die Nummer jenes Datenbytes in dem Bytestrom, welches der
Absender dieses TCP-Segments als nächstes von der Gegenstelle erwartet. Das Feld Offset
(4 Bits) gibt an, wie viele 32-Bit-Worte der TCP-Header enthält. Dieses ist nötig, da das
Optionenfeld variable Länge haben kann. Das Fenster gibt an, wie viele Bytes der Sender
dieses Pakets von der Gegenstelle noch maximal akzeptieren kann. Damit ist eine
Flusskontrolle möglich. Sender und Empfänger synchronisieren sich entsprechend der
vorhandenen Ressourcen.
Linux – Advanced                                                                            24

Codes im TCP-Header

Da manche Pakete nur Daten, manche nur Quittungen enthalten, gibt Code an, welche
Bedeutung dieses Paket hat. Dieses Feld enthält 6 Bits, welche gesetzt oder gelöscht sein
können und folgendes bedeuten.




Abbildung 18: TCP-Head


Der Vorrang-Zeiger zeigt auf jenes Byte innerhalb dieses Pakets, ab welchem Vorrangdaten
vorhanden sind. Dieses Feld ist jedoch nur gültig, wenn das URG-Bit (urgent) gesetzt ist.

Das PSH-Bit (push) wird gesetzt, wenn Daten vom Sender abgeschickt wurden, ohne dass
der Sendepuffer bereits gefüllt ist. Dieses wird besonders beim interaktiven Betrieb benötigt,
um beim Zeilenende bei einem Terminalbetrieb die letzten Daten zu übertragen.

Das Ack-Bit (acknowledgement) und das SYN-Bit (synchronize) werden beim
Verbindungsaufbau, das FIN-Bit (finish) zusätzlich beim Verbindungsabbau benötigt.

Wenn eine Verbindung schnell (und nicht durch FIN) beendet werden soll, verwendet man
das RST-Bit (reset).

Verbindungsaufbau beim TCP-Protokoll

Der Verbindungsaufbau beim TCP-Protokoll wird durch ein 3-Wege-Verfahren (three-way
handshake) durchgeführt, welches nach folgendem Prinzip arbeitet.
Linux – Advanced                                                                           25




Abbildung 19: Dreiwege-Handshake (hier Verbindungsaufbau)


Nach dem Aufbau der Verbindung wissen somit beide Stationen, dass die andere
empfangsbereit ist und wie die jeweiligen Bytes nummeriert werden. Um eine Verbindung zu
schließen, wird ein Segment mit dem gesetzten FIN-Bit geschickt. Damit ist die jeweilige
Richtung geschlossen. Es dürfen keine Daten mehr übermittelt werden. In der
Gegenrichtung können jedoch noch weiter Daten gesendet werden. Erst wenn beide
Stationen ein FIN-Segment geschickt haben, ist die Verbindung vollständig beendet. Bei
fehlerhaften Situationen besteht die Möglichkeit, durch Setzen des RST-Bits die
Verbindungen sofort abzubrechen.

Portnummern

TCP ist außerdem dafür verantwortlich, die empfangenen Daten an die korrekte Applikation
weiterzuleiten. Zur Adressierung der Anwendungen werden auf der Transportebene deshalb
so genannte Portnummern (Kanalnummern) verwendet. Portnummern sind 16 Bit groß.
Theoretisch kann ein Host somit bis zu 65.535 verschiedene TCP-Verbindungen aufbauen.
Auch UDP verwendet Portnummern zur Adressierung. Portnummern sind nicht einzigartig
zwischen den Transportprotokollen, die Transportprotokolle haben jeweils eigene
Adresseräume. Das bedeutet TCP und UDP können die gleichen Portnummern belegen. Die
Portnummer 53 in TCP ist nicht identisch mit der Portnummer 53 in UDP. Der
Gültigkeitsbereich einer Portnummer ist auf einen Host beschränkt.
Linux – Advanced                                                                                  26

Die Verwaltung der Portnummern ist nun auch von der Internet Assigned Numbers Authority2
(IANA) übernommen worden. Portnummern sind dabei in drei Bereiche aufgeteilt worden:
well-known ports, registered ports und dynamic ports.

Tabelle 2: Ports



0 - 1023              Well-known ports (von der IANA verwaltet). Der Bereich der well-known
                      ports ist bis 1023 erweitert worden, damit sind auch die UNIX-
                      spezifischen Dienste als Standarddienste festgelegt.


1024 - 49151          Registered ports. Registrierte Ports dienen für Dienste, die üblicherweise
                      auf bestimmten Ports laufen. Ein Beispiel ist hier der Port 8080, der als
                      "zweiter" bzw. alternativer Port für das http dient.


49152 - 65535         Dynamic and/or private ports. Dieser Bereich ist für die sogenannten
                      dynamischen Ports festgelegt. Dynamische Ports dienen zur
                      Kommunikation zwischen den beiden TCP-Schichten, die an einer
                      Kommunikation beteiligt sind. Ein dynamischer Port wird nicht von
                      bestimmten Standarddiensten belegt.




1.9     User Datagram Protocol (UDP)

Das User Datagram Protocol (UDP) stellt dem Anwender einen Mechanismus zur
verbindungslosen Kommunikation zur Verfügung. Das Konzept ist ähnlich dem des IP. Es
setzt jedoch auf der Anwendungsschicht auf. UDP erlaubt es Anwendungsprozesse auf
anderen Rechnern Datagramme zu senden. Der Anwendungsprozess wird durch eine
Portnummer identifiziert. UDP ist in RFC 768 standardisiert. Das Feld Protocol im IP-Header
identifiziert UDP mit dem Wert 1710. Die teilweise festgelegten Portnummern werden aktuell
in RFC 1700 spezifiziert und sind aktueller unter der URL http://www.iana.org zu finden.

UDP-Nachricht

Eine UDP-Nachricht (UDP-Message) besteht aus einem Kopf und einem Datenteil. Die UDP-
Nachricht wird in einem IP-Datagramm wie ein Datenpaket behandelt.


2
    http://www.iana.org
Linux – Advanced                                                                       27




Abbildung 20: UDP Datagramm


Der UDP-Kopf hat den folgenden Aufbau.




Abbildung 21: UDP-Kopf


Der Quell- bzw. Ziel-Port identifiziert eindeutig den Anwendungsprozess, der dieses
Datagramm entweder sendet oder empfängt. Dabei ist der Quell-Port optional, d.h. entweder
enthält er die Adresse des Absenders, an die der Empfänger Antworten schicken soll, oder
er enthält den Wert null.

1.10 Adressierung im TCP/IP

Siehe Vogl, H. Der Linux Schulserver.
Linux – Advanced                                                                            28

Tabelle 3: Netzklassen



Netzklasse Adressbereich         Netzmaske         CIDR-Schreibweise


Klasse A     0.0.0.0 bis         255.0.0.0         0.0.0.0/8
             127.255.255.255


Klasse B     128.0.0.0 bis       255.255.0.0       128.0.0.0/16
             191.255.255.255


Klasse C     192.0.0.0 bis       255.255.255.0 192.0.0.0/24
             223.255.255.255




Tabelle 4: Private IP-Adressen



Netzklasse Adressbereich                       CIDR-              Anzahl der möglichen
                                               Schreibweise       Hosts


Klasse A     10.0.0.0 - 10.255.255.255         10.0.0.0/8         16777216


Klasse B     172.16.0.0 - 172.31.255.255       172.16.0.0/12      1048576


Klasse C     192.168.0.0 -                     192.168.0.0/16     65536
             192.168.255.255


Das Netzwerk 127.0.0.0/8 bezeichnet man als loopback-device. Es bezieht sich auf den
lokalen Computer. Mit der IP-Adresse 127.0.0.1 wird der lokale Rechner adressiert. Diese
Adresse dient der Kommunikation lokaler Clients mit dem lokalen Server. So wird am
Rechner mit dem URL http://127.0.0.1/ immer der lokale Webserver erreicht.

1.11 Subnetze

Ein Subnetz entsteht durch die Unterteilung aller möglichen IP-Adressen in Teilnetze. Die
logische Unterteilung des Netzes in Subnetze entspricht meist der physikalischen
Linux – Advanced                                                                               29

Unterteilung in lokale Teilnetze. Das Unterteilen einer Netzklasse mittels Netzmaske in
weitere Subnetze nennt man Subnetting.

1.11.1        Grundlagen

Die Zuordnung von IP-Adressen zu Subnetzen und die Bezeichnung des Subnetzes erfolgen
durch Angabe einer IP-Adresse und einer Netzmaske. Dabei bestimmt die Netzmaske die
Bits der IP-Adresse, die für alle IP-Adressen des Subnetzes gleich sind. Die restlichen Bits
können variieren und bestimmen den Adressraum.

Hieraus ergeben sich folgende Besonderheiten:

   •   Die erste IP-Adresse (alle Hostbits auf 0) eines Subnetzes adressiert das Subnetz
       selbst (Netzwerkkennung) und kann deshalb keinem Host zugewiesen werden.

   •   Die letzte IP-Adresse (alle Hostbits auf 1) eines Subnetzes dient als Broadcast-
       Adresse für das Netz und kann ebenfalls keinem Host zugewiesen werden.

   •   Es gibt einige IP-Bereiche, die für spezielle Zwecke vorgesehen sind. Dazu gehören
       z.B die loopback-Adresse oder Private IP-Adressen.

Ein Router arbeitet auf der Vermittlungsschicht des OSI-Modells und kann durch bitweise
Und-Verknüpfung von Netzmaske und IP-Adresse ermitteln, ob letztere zum eigenen oder in
anderes Subnetz gehört. Dadurch sind Router in der Lage, Subnetze zu verbinden.

Mit dem Routing Information Protocol war es lediglich möglich Netze in gleich große
Subnetze zu unterteilen. Da man dort für jedes Netz die gleiche Subnetzadresse mit der
gleichen Anzahl an Einsern benutzt hatte, sprach man auch vom Fixed Length Subnet
Masks (FLSM). OSPF und statisches Routing unterstützen inzwischen auch Subnetzmasken
unterschiedlicher Länge oder Variable Length Subnet Masks (VLSM).

1.11.2        Vorgehensweise zur Aufteilung in Subnetze

Die Standard-Aufteilung, nach der die Netzmasken bestimmt werden, folgt dabei einer
bestimmten Rechenmethode:

Gegeben sei: gewünschte Netze 40, gewünschte Hosts 720 je Netz, verfügbarer Hostbereich
181.45.x.x

Schritt 1: Kontrolle ob Adressressourcen ausreichen
Linux – Advanced                                                                            30

Dazu ist eine n-te Potenz von 2 (zwei hoch n) zu finden, die um 2 größer als die Anzahl der
gewünschten Netze oder Hosts ist:

Es stehen also zwei Oktette bzw. 16 Bit zur Verfügung.

       Adressresourcen = 2n = (Anzahl + 2) n

Erklärung: 1 Bit hat zwei mögliche Werte. Für n Bit gibt es also 2n mögliche
Bitkombinationen. Es können also 2n Netze/Hosts abgebildet werden, wobei von den
darstellbaren Adressen zwei wegfallen (Netzadresse und Broadcast, siehe oben).

Die ersten zehn Zweierpotenzen sind: 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024. Da also 25 =
32 < 40 < 64 = 26, müssen n = 6 Bit für die Netze reserviert werden.

Analog für die Anzahl der Hosts gilt: 29 = 512 < 720 < 1024 = 210, d.h. 10 Bit werden für die
Hosts benötigt.

Alternativ lässt sich n auch durch den Logarithmus zur Basis 2 (Logarithmus dualis)
ermitteln:

       Netze: 2log(40)=5,32 Aufrunden auf 6
       Hosts: 2log(720)=9,49 Aufrunden auf 10

Das Ergebnis der Überprüfung lautet, dass die Summe der benötigten Bits 16 beträgt. Da
auch 16 Bit verfügbar sind, kann mit dem gegebenen Adressenbereich 181.45.x.x die
Anforderung also erfüllt werden.

Schritt 2: Ermitteln der Netzmaske

Wie bereits berechnet, müssen für den Hostanteil 10 Bit verwendet werden. Host-Bit sind
immer die letzten in einer IP-Adresse:

       Gemischte Dezimal-Binär-Darstellung: 181.45.NNNNNNHH.HHHHHHHH
       (N für Netzwerkbits, H für Hostbits)

Die Netzmaske soll 32 Bit umfassen, wobei sämtliche Netzwerkbit durch 1 und sämtliche
Host-Bits (im Beispiel 10) durch 0 dargestellt werden:

       Es ergibt sich folgende Binärdarstellung:
       11111111.11111111.11111100.00000000

Jedes Oktett dieser Netzmaske wird nun vom Dualsystem ins Dezimalsystem umgerechnet:

00000000 (Dual) = 0 (Dezimal)
Linux – Advanced                                                                              31

11111100 (Dual) = 252 (Dezimal)

11111111 (Dual) = 255 (Dezimal)

Die Netzmaske lautet dementsprechend: 255.255.252.0.

Schritt 3: IP-Adressen der Netze finden

Zur Festlegung der IP-Adressen muss wieder gerechnet werden:

Erstes Netz

   •   Netzadresse des ersten Netzes:      181.45.NNNNN1HH.HHHHHHHH
               =10110101.00101101.00000100.00000000              =181.45.4.0

   •   Erster Host im ersten Netz:         181.45.NNNNN1HH.HHHHHHH1
               =10110101.00101101.00000100.00000001              =181.45.4.1.

Der letzte Host im ersten Netz orientiert sich an der maximalen Anzahl von Einsern, die für
Hosts zur Verfügung stehen. Das letzte Bit kann dann nicht 1 sein, da es sich sonst um den
Netzbroadcast handeln würde:

       181.45.(NNNNN1)11.11111110 =
       10110101.00101101.00000111.11111110 = 181.45.7.254

Demnach ist 181.45.7.255 der Broadcast für das 1. Netz.

Letztes Netz

Das letzte Netz ist auch anhand der möglichen Bits festgelegt:

   •   181.45.(111110)00.00000000 Netzadresse für das letzte Netz. (181.45.248.0)

   •   181.45.(111110)11.11111110 letzter Host im letzten Netz. (181.45.251.254)

Vereinfachung

Bei kleineren Subnetzen lassen sich die Adressen der einzelnen Subnetze folgendermaßen
berechnen:

Zuerst ermittelt man die Anzahl der möglichen Adressen pro Subnetz. Diese erhält man,
indem man die Anzahl der Adressen des aufzuteilenden Netzes durch die Anzahl der
Subnetze teilt. Nun beginnt jedes Subnetz mit einem Vielfachen der Anzahl der Adressen pro
Subnetz.
Linux – Advanced                                                                             32

Beispiel:

Das Netz 192.168.44.X soll in 8 Teilnetze aufgeteilt werden. Ein Oktett kann 256
verschiedene Werte annehmen. Jedes Subnetz hat 30 verwendbare Adressen (256:8=32-2
(Netzadresse und Broadcastadresse))

Folgende Netze entstehen:

   •   192.168.44.0

   •   192.168.44.32

   •   192.168.44.64

   •   192.168.44.96

   •   192.168.44.128

   •   192.168.44.160

   •   192.168.44.192

   •   192.168.44.224

Sollte ein Netz in mehrere, unterschiedlich große, Subnetze aufgeteilt werden, so wird mit
der größten Adressanzahl begonnen.

Host-Range

Der Host-Range bezeichnet den Teil in einem Subnetz der tatsächlich für IP-Adressen
verwendet werden kann. In jedem Subnetz ist die erste und die letzte Adresse reserviert. Bei
einem Subnetz mit der Adresse 200.10.57.8 lautet der Host-Range: 200.10.57.9 -
200.10.57.14 Die reservierten Adressen lauten in diesem Fall 200.10.57.8 und 200.10.57.15

Das nächste Subnetz mit der Adresse 200.10.57.16 hätte einen Hostrange von 200.10.57.17
bis 200.10.57.22

Vereinfachung von Subnetting

Beispiel: Ein Klasse B-Netz mit der Nummer 172.16.0.0 und der Subnetzmaske 255.255.0.0
Linux – Advanced                                                                           33

Ziel: In einem B-Netz können ca. 65.000 Hosts adressiert werden. Da mehrere Teilnetze
benötigt werden, wird diese Anzahl unterteilen. Im Beispiel sollen 20 Teilnetze gebildet
werden.

Lösung: (Erspart binäres Rechnen!)

Schritt 1: Wir suchen die 2er Potenz, die größer 20 ist :

           2^5 = 32

Schritt 2: Wir teilen die Anzahl der Bitkombinationen durch das Ergebnis aus dem 1.Schritt:

           256 : 32 = 8

Schritt 3: Wir bilden die Subnetzmaske: 256 - 8 = 248

           Die neue Subnetzmaske lautet: 255.255.248.0

Schritt 4: Wir bilden den Adressbereich eines gesuchten Teilnetzes.

Beispiel: Wir suchen das 5. Teilnetz:

           5 x 8 = 40
           6 x 8 = 48 - 1 = 47
           Der Adressbereich lautet:
           172.16.40.1 bis 172.16.47.254 mit der Subnetzmaske
           255.255.248.0

Beispiel: Wir suchen das 7. Teilnetz:

           7 x 8 = 56
           8 x 8 = 64 - 1 = 63
           Der Adressbereich lautet:
           172.16.56.1 bis 172.16.63.254 mit ebenfalls der Subnetzmaske
           255.255.248.0

Für diese Berechnungen gibt es natürlich auch Programme, wie den IP Calculator3.

1.12 Classless Inter Domain Routing (CIDR)

Classless Inter-Domain Routing (CIDR) beschreibt ein Verfahren zur effektiveren Nutzung
des bestehenden 32-Bit-IP-Adress-Raumes. Es wurde 1993 eingeführt, um die Größe von
Routing-Tabellen zu reduzieren und um die verfügbaren Adressbereiche besser
auszunutzen.




3
    http://jodies.de/ipcalc
Linux – Advanced                                                                            34

Mit CIDR entfällt die feste Zuordnung einer IP-Adresse zu einer Netzklasse und die
eventuelle Unterteilung (Subnetting) in weitere Netze oder die Zusammenfassung
(Supernetting) mehrerer Netze einer Klasse. Es existiert nur noch eine Netzmaske, welche
die IP-Adresse in den Netzwerk- und Hostteil aufteilt.

Bei CIDR führte man als neue Notation so genannte Suffixe ein. Das Suffix gibt die Anzahl
der 1-Bits in der Netzmaske an. Diese Schreibform ist viel kürzer als die dotted decimal
notation und auch eindeutig.

Beispiel: 192.168.0.0/24 entspricht im alten klassenbasierten Verfahren der Adresse
192.168.0.0 mit der Netzmaske 255.255.255.0. In binärer Schreibweise ergibt sich bei der
Netzmaske 11111111.11111111.11111111.00000000, womit die Anzahl der einer Bit 3*8 =
24 beträgt.

CIDR bietet außerdem Route aggregation. Dabei können verschiedene Netze unter einer
einzigen Adresse angesprochen werden.

1.13 Dynamic Host Configuration Protocol (DHCP)

Das Dynamic Host Configuration Protocol (DHCP) weist auf Anfrage einem Rechner
dynamisch eine Adresse zu. Es erledigt also eine ähnlich Aufgabe wie das RARP, wobei
allerdings die IP-Adressen nicht notwendigerweise unverändert dem jeweiligen Host
zugewiesen werden. Es baut auf dem BOOTP-Protokoll auf, welches für das Starten von
Computern über das Netz benutzt wird.




Abbildung 22: DHCP


Startet ein Rechner in einem neuen oder seinem bisherigen Netz, so sendet er eine
entsprechende Anfrage ab. Der zuständige DHCP-Server antwortet und sendet diesem
Linux – Advanced                                                                             35

Rechner verschiedene Daten. Die aktuelle IP-Adresse, aber auch die Adresse des Routers
und des Nameservers.

Im Unterschied zu ARP wird die IP-Adresse nur optional fest einem Rechner zugewiesen. In
der Regel werden Server, Drucker und ähnliche Geräte in einem lokalen Netz jeweils die
gleiche IP-Adresse erhalten. Clients erhalten evtl. auch jeweils ihre letzte Adresse, u.U. aber
auch eine neue. Jede dynamische Adresse verfällt nach einer gewissen Zeit und kann dann
wieder einem neuen Rechner zugewiesen werden. Auf diese Weise lassen sich
beispielsweise einige wenige Adressen einer großen Anzahl an Teilnehmern zuordnen, die
nicht ständig auf das Netz zugreifen. So vergeben Internet-Provider IP-Adressen nur
dynamisch, da sie in der Regel sehr viel mehr Kunden haben als ihnen IP-Adressen
zustehen.

1.14 Domain Name Service (DNS)

Das Domain Name System (DNS) löst die Namen im Internet auf. Das DNS ist eine verteilte
Datenbank.

Hauptsächlich wird das DNS zur Umsetzung von Namen in Adressen (forward lookup)
benutzt. Dies ist vergleichbar mit einem Telefonbuch, das die Namen der Teilnehmer in ihre
Telefonnummer auflöst. Das DNS bietet somit eine Vereinfachung, weil Menschen sich
Namen weitaus besser merken können als Zahlenkolonnen. So kann man sich den
Domainnamen www.bpa-graz.at sehr einfach merken, die dazugehörende IP-Adresse
207.142.131.236 dagegen nicht ganz so einfach.

Mit dem DNS ist auch eine umgekehrte Auflösung von IP-Adressen in Namen (reverse
lookup) möglich.

Darüber hinaus ermöglicht das DNS eine Entkoppelung vom darunter liegenden Aufbau.
(Änderung der IP-Adresse, ohne den Domainnamen ändern zu müssen).

Das DNS löste die hosts-Dateien ab, die bis dahin für die Namensauflösung zuständig
waren. Es zeichnet sich aus durch:

   •   dezentrale Verwaltung

   •   hierarchische Strukturierung des Namensraums in Baumform

   •   Eindeutigkeit der Namen

   •   Erweiterbarkeit
Linux – Advanced                                                                            36

Komponenten des DNS

Das DNS besteht aus drei Hauptkomponenten:

   •   Domänennamensraum

   •   Nameservern

   •   Resolver

Domänennamensraum

Der Domänennamensraum hat eine baumförmige Struktur. Die Blätter und Knoten des
Baumes werden als Labels bezeichnet. Ein kompletter Domänenname eines Objektes
besteht aus der Verkettung aller Labels. Label sind Zeichenketten (alphanumerisch, früher
war als einziges Sonderzeichen '-' erlaubt, im Jahre 2004 kamen auch noch Umlaute wie: ä,
ö, ü, é, à, è, usw. dazu), die mindestens ein Zeichen und maximal 63 Zeichen lang sind. Die
einzelnen Label werden durch Punkte voneinander getrennt. Ein Domänenname wird mit
einem Punkt abgeschlossen (der hinterste Punkt wird normalerweise weggelassen, gehört
rein formal aber zu einem vollständigen Domänennamen dazu). Ein korrekter, vollständiger
Domänenname (auch FQDN) lautet z.B. www.bpa-graz.at. (der letzte Punkt gehört zum
Domänennamen).

Nameserver

Nameserver sind Programme, die Anfragen zum Domänennamensraum beantworten. Man
unterscheidet zwischen autoritativen und nicht autoritativen Nameservern.

Ein autoritativer Nameserver ist verantwortlich für eine Zone. Seine Informationen über diese
Zone werden deshalb als gesichert angesehen. Für jede Zone existiert mindestens ein
autoritativer Server, der Primary Nameserver. Dieser wird im SOA Resource Record einer
Zonendatei aufgeführt. Aus Redundanz- und Lastverteilungsgründen werden autoritative
Nameserver fast immer als Server-Cluster realisiert, wobei die Zonendaten identisch auf
einem oder mehreren Secondary Nameservern liegen. Die Synchronisation zwischen
Primary und Secondary Nameservern erfolgt per Zonentransfer.

Ein nicht autoritativer Nameserver bezieht seine Informationen über eine Zone von anderen
Nameservern. Seine Informationen werden als nicht gesichert angesehen. Da sich DNS-
Daten normalerweise nur sehr selten ändern, speichern nicht autoritative Nameserver die
einmal von einem Resolver angefragten Informationen im lokalen RAM ab. Diese liegen bei
einer erneuten Anfrage schneller vor. Diese Technik wird als Caching bezeichnet. Jeder
Linux – Advanced                                                                             37

dieser Einträge besitzt ein eigenes Verfallsdatum (TTL time to live). Nach dem Ablauf wird
der Eintrag aus dem Cache gelöscht. Die TTL wird dabei durch einen autoritativen
Nameserver für diesen Eintrag festgelegt und wird nach der Änderungswahrscheinlichkeit
des Eintrages bestimmt (sich häufig ändernde DNS-Daten erhalten eine niedrige TTL). Das
kann u. U. aber auch bedeuten, dass der Nameserver in dieser Zeit falsche Informationen
liefern kann, wenn sich die Daten zwischenzeitlich geändert haben. Ein Spezialfall ist der
caching only Nameserver. In diesem Fall ist der Nameserver für keine Zone verantwortlich
und muss alle eintreffenden Anfragen über weitere Nameserver auflösen.

Ein Domänenname darf inklusive aller Punkte maximal 255 Zeichen lang sein.

Ein Domänenname wird immer von rechts nach links delegiert und aufgelöst, d. h. je weiter
rechts ein Label steht, umso höher steht es im Baum. Der Punkt ganz rechts wird auch als
root (Wurzel) im Namensraum bezeichnet.

Das erste Label (das links vom Punkt für 'root' steht) wird im Allgemeinen auch als Top Level
Domain (TLD) bezeichnet.

Die DNS-Objekte einer Domäne (zum Beispiel die Rechnernamen) werden als Satz von
Resource Records meist in einer Zonendatei gehalten, die auf einem oder mehreren
autoritativen Nameservern vorhanden sind. Statt Zonendatei wird meist der etwas
allgemeiner Ausdruck Zone verwendet.

Resolver

Resolver sind Ansammlungen von Bibliotheken, die Informationen aus den Nameservern
abrufen können. Sie bilden die Schnittstelle zwischen Anwendung und Nameserver. Der
Resolver übernimmt die Anfrage einer Anwendung, ergänzt sie falls notwendig zu einem
FQDN und übermittelt sie an den fest konfigurierten Nameserver.

Ein Resolver arbeitet entweder iterativ oder rekursiv und informiert den Nameserver über die
verwendete Arbeitsweise. Übliche Resolver von Clients arbeiten ausschließlich rekursiv, sie
werden dann auch als Stub-Resolver bezeichnet.

Bei einer rekursiven Anfrage schickt der Resolver eine Anfrage an einen ihm bekannten
Nameserver und erwartet von ihm eine eindeutige Antwort. Diese Antwort enthält entweder
den gewünschten Resource Record oder "gibt es nicht". Rekursiv arbeitende Resolver
überlassen also die Arbeit zur vollständigen Auflösung anderen.
Linux – Advanced                                                                           38

Bei einer iterativen Anfrage bekommt der Resolver entweder den gewünschten Resource
Record oder die Adresse eines weiteren Nameserver, den er als Nächsten fragt. Der
Resolver fragt so von Nameserver zu Nameserver, bis er bei einem autoritativen
Nameserver landet.

Die so gewonnene Antwort übergibt der Resolver an das Programm, das die Daten
angefordert hat, beispielsweise an den Webbrowser.

Bekannte Programme zur Überprüfung der Namensauflösung sind nslookup, host und dig.
Weitere Informationen zur iterativen/rekursiven Namensauflösung finden sich unter rekursive
und iterative Namensauflösung.

DynDNS

Es kann nur Rechnern mit fester, sich also nie ändernden IP-Adresse ein fester
Rechnername zugeordnet werden. Da jedoch sehr viele Nutzer mit Heimrechnern eine
variable IP-Adresse haben (mit jeder Einwahl in das Internet wird eine andere IP-Adresse
aus einem Pool zugeteilt), gibt es inzwischen DynDNS-Betreiber (z.B. DynDNS.org), die
dafür sorgen, dass man auch mit solch rasch ändernden Adressen möglichst immer über
denselben Rechnernamen erreichbar ist.

Domain-Registrierung

Um DNS-Namen im Internet bekanntmachen zu können, muss der Besitzer die Domain, die
diese Namen enthält, registrieren. Durch eine Registrierung wird sichergestellt, dass
bestimmte formale Regeln eingehalten werden und dass Domain-Namen weltweit eindeutig
sind. Domain-Registrierungen werden von Organisationen (Registrars) vorgenommen, die
dazu von der IANA bzw. ICANN autorisiert wurden. In Österreich ist nic.at dafür
verantwortlich. Registrierungen sind gebührenpflichtig.

1.15 Übungsbeispiele

   1. Wofür steht die Abkürzung OSI?

   2. Benennen Sie die Schichten des OSI-Models.

   3. Welche Ziele wurden bei der Entwicklung von TCP/IP definiert?

   4. Benennen Sie die Schichten des TCP/IP-Modells?

   5. Nenne Sie drei Protokolle der Applikationsschicht.
Linux – Advanced                                                                       39

   6. Nennen Sie die zwei Protokolle der Transportschicht.

   7. Vergleichen Sie das OSI- mit dem TCP/IP-Modell?

   8. Was bedeutet Encapsulation?

   9. Wie bezeichnet man die Daten auf den verschiedenen Schichten des TCP/IP-
      Modells?

   10. Aus welchen Bereichen besteht ein Datagramm?

   11. Was bedeutet fragmentieren?

   12. Was bedeutet reassemblieren?

   13. Wie ist der IP-Header aufgebaut?

   14. Wofür wird das Address Resolution Protocol verwendet?

   15. Was bedeutet RARP?

   16. Wofür wird ICMP verwendet?

   17. Welche Merkmale hat das Transmission Control Protocol?

   18. Wie ist der TCP-Header aufgebaut?

   19. Wie funktioniert der Verbindungsaufbau beim TCP-Protokoll?

   20. Was sind Ports?

   21. Welche Organisation verwaltet die Portnummern?

   22. Wie heißen die drei Bereiche in denen Portnummern aufgeteilt werden?

   23. Worin unterscheidet sich UDP von TCP?

   24. Mit welchen Protokollen können Rechnern IP-Adressen zugeordnet werden?

   25. Ordnen Sie die folgenden IP-Adressen den einzelnen Standard-Netzwerkklassen zu:
      192.168.1.44, 190.34.45, 77.55.123.234

   26. Wie lautet der Netzwerkteil der Adresse 192.168.1.44, wenn es sich um ein Klasse-C-
      Netz handelt.
Linux – Advanced                                                                           40

   27. Wozu werden Subnetzmasken eingesetzt?

   28. Wandel Sie die IP-Adresse 193.171.90.34 in das Binärformat um.

   29. Ermitteln Sie den Netzwerkteil der folgende IP-Adresse (http://jodies.de/ipcalc):
      10101100 00010100 01100111 11011001 = 172.20.103.217
      der dir folgende Subnetmaske zugeordnet wurde:
      11111111 11111111 11111000 00000000 = 255.255.248.0

   30. Wofür benötigt man eine Broadcast-Adresse?

   31. Kann die IP-Adresse 192.168.4.255 mit der Subnetmaske 255.255.255.0 an ein
      Endgerät vergeben werden?

   32. Wie lautet die Loopback-Adresse eines lokalen Systems?

   33. Geben Sie die IP-Adresse 192.168.1.55 mit der Netzmaske 255.255.255.0 in einer
      anderen Schreibweise an.

   34. Was ist ein Subnet?

   35. Gegeben ist folgende IP-Adresse und Subnetmaske:
      172.192.0.0, 255.255.255.0
      Es sollen Subnetz mit jeweils 40 Hostadressen berechnet werden.

   36. Wie lange darf ein Domänenname sein?

   37. Was ist ein Resolver?

   38. Wo kann man in Österreich eine Domain registrieren?

   39. Wer ist der Domaininhaber der Domain bpa-graz.at?
Linux – Advanced                                                                                 41


2 Einrichten der Schulungsumgebung

Für die Schulungsumgebung wird die Linux-Distribution SUSE Linux 10.0 OSS Beta 24
verwendet. Als Testumgebung kann VMware5 , MS Virtual PC6 oder OEMU7 verwendet
werden. Als Installationsmedium wird ein boot.iso Image verwendet. Dieses Image kann von
einem Mirror geladen werden (z.B. http://suse.inode.at/opensuse/distribution/SL-10.0-OSS-
beta2/inst-source/boot/boot.iso).

Sowohl in VMware als auch unter Virtual PC muss eine Virtuelle Hardware konfiguriert
werden.

2.1   VMware

VMware ist eine Softwarefirma, die sich auf Emulation und Virtualisierung spezialisiert hat
und deren bekanntestes Produkt VMware Workstation ist.

Mit VMware Workstation kann unter Linux sowie Microsoft Windows ein kompletter PC
virtualisiert werden. In dem virtualisierten PC können unterschiedliche Betriebssysteme
installiert werden. Es bestehen aber Restriktionen hinsichtlich der technischen Fähigkeiten
des zugrunde liegenden Betriebssystems. Eine mit Windows 2000 eingerichtete virtuelle
Maschine, die auf einem Rechner mit dem älteren Windows NT 4 läuft, kann beispielsweise
dennoch keinen USB-Zugriff durchführen.

Für den Betrieb von Servern gibt es die Produkte VMware GSX, sowie das Flaggschiff ESX-
Server. Letzterer basiert auf einem Vmware eigenen Kernel und benötigt daher kein
Wirtsbetriebssystem.

Mittlerweile lassen sich mit VirtualCenter komplette virtuelle Infrastrukturen darstellen. Das
bedeutet, dass man z.B. in einem Netzwerk 40 Server sieht, es tatsächlich aber nur 2
physikalische Server gibt. Der Rest sind virtuelle Server.

VMware bietet mittels der Software VMotion die Möglichkeit, einen virtuellen Server von
einem physikalischen Host zum nächsten zu transferieren, ohne dass der virtuelle Server
herunter gefahren werden muss. Das hat den Vorteil, dass wenn an der physikalischen
Maschine z.B. Hardware getauscht oder erweitert werden muss, die User weiterarbeiten
können. Für sie ist "ihr" Server nicht down.


4
  http://www.opensuse.org/
5
  http://www.vmware.com/
6
  http://www.microsoft.com/windows/virtualpc/
7
  http://fabrice.bellard.free.fr/qemu/
Linux – Advanced                                                                          42

Es lassen sich auch mehrere Maschinen mit verschiedenen Betriebssystemen gleichzeitig
virtualisieren. Die virtualisierten Betriebssysteme sind in Abhängigkeit vom Speicherausbau
etwas langsamer als vergleichbare Installationen auf identischer Hardware.

Im Bereich der Softwareentwicklung erleichtern virtuelle Maschinen den
Entwicklungsprozess, da verschiedene Instanzen gleichzeitig parallel laufen können. Damit
können verschiedene Releasestände bequem getestet werden. Durch Snapshots können
Wiederanlaufpunkte gesichert werden, zu denen wieder zurückgekehrt werden kann. Die
Installationen werden als Imagedateien abgelegt und können damit über eine
Netzwerkanbindung verschiedenen Entwicklern mit gleichem Stand zur Verfügung gestellt
werden.

Nach dem Start von Vmware, beginnt mit File, New Virtual Machine die Konfiguration.




Abbildung 23: VMware Konfiguration für Opensuse10beta2


Außerdem wird eine zweite Netzwerkkarte benötigt. Diese wird Host-only konfiguriert.
Linux – Advanced                                                               43




Abbildung 24: NIC2 Host-only


Das boot.iso Image wird direkt in das virtuelle CD-Rom Laufwerk eingebunden.




Abbildung 25: VMware boot.iso einbinden


Nach dem Start bootet die Virtuelle-Maschine direkt vom boot.iso Image.
Linux – Advanced                                                                               44




Abbildung 26: Vmware


2.2   Virtual PC

Virtual PC ist eine Virtualisierungssoftware von Microsoft und wird für Windows, wie auch für
Mac OS angeboten. Es ist Bestandteil des Produktes Microsoft Office Professional für Mac
OS.

Mit Virtual PC wird ein kompletter PC virtualisiert, das heißt, mit Hilfe einer so genannten
virtuellen Maschine wird ein PC emuliert. So wie die Java-VM dem Applet eine
Rechenumgebung vorgaukelt, erzeugen Programme wie Virtual PC einen kompletten
virtuellen Rechner. Dadurch wird es möglich, mehrere Betriebssysteme gleichzeitig auf nur
einem PC zu betreiben.

Virtual PC simuliert jedoch nicht den PC auf dem es ausgeführt wird, sondern einen
Standard-PC mit bis zu drei Festplatten, einem CD- oder DVD-Laufwerk, einem
Arbeitspeicher einstellbarer Größe (abhängig von der Arbeitsspeicherkapazität im echten
PC), einer 100-MBit-Netzwerkkarte, einer Audio-Karte und einer 8-MB-Grafikkarte. Eine
Unterstützung für lokale USB- oder PCI-Geräte fehlt. Die Festplatten werden als so genannte
Image-Dateien auf der lokalen Festplatte angelegt.

Nach dem Start von Virtual PC erscheint die Virtual PC Konsole. Mit Neu… startet die
Konfiguration eines neuen Virtuellen PCs.
Linux – Advanced                                                                           45




Abbildung 27: Virtual PC-Konsole


Nach der Begrüßung durch den Assistenten wird ein Virtueller Computer erstellt.




Abbildung 28: Virtuellen Computer erstellen


Für das Konfigurationsfile und die virtuelle Hard Disk empfiehlt es sich einen eigenen Ordner
pro PC einzurichten.
Linux – Advanced                                                                        46




Abbildung 29: Ordner des virtuellen Computers




Abbildung 30: Name und Pfad des virtuellen Computers


Virtul PC erkennt, dass es sich nicht um ein Windows Betriebsystem handelt. Als Vorschlag
wird Anderes übernommen.
Linux – Advanced                                                                            47




Abbildung 31: Virtual PC Betriebsystem


Vorgeschlagener werden 128 MB Arbeitsspeicher. Für effektiveres Arbeiten sollte dieser
Wert erhöht werden.




Abbildung 32: Speicher


Die virtuelle Festplatte wird mit 4 GB erstellt. Der Speicherort entspricht dem Speicherort des
Konfigurationsfiles.
Linux – Advanced                                      48




Abbildung 33: Neue virtuelle Festplatte




Abbildung 34: Speicherort der virtuellen Festplatte
Linux – Advanced                                                                       49




Abbildung 35: Abschluss der Konfiguration


Nach der Konfiguration wird in der Virtual PC Konsole über Einstellungen der Adapter 2 auf
lokal gesetzt.




Abbildung 36: Netzwerkadapter 2
Linux – Advanced                                                                         50




Abbildung 37: Start Virtual PC


Nach dem Start des virtuellen Computers, muss im Menü CD das boot.iso Image erfasst
werden.




Abbildung 38: boot.iso wählen


2.3      QEMU

QEMU8 ist ein CPU-Emulator bzw. eine virtuelle Maschine für die Betriebssysteme Linux,
Windows, FreeBSD, NetBSD, OpenBSD und Mac OS X.




8
    http://free.oszoo.org/
Linux – Advanced                                                                              51

Er emuliert bereits x86, x86-64 bzw. AMD64, PowerPC und Sparc32/64 Hardware. Alpha,
ARM und S390 werden noch getestet. Geplant sind eine Unterstützung für IA-64, m68k und
MIPS.

Das PC-BIOS stammt von Bochs9 und das VGA-BIOS von Plex86/Bochs.

Diverse Betriebssysteme wie z.B. AROS, DOS incl. dessen grafische Bedienoberflächen
PC/GEOS, OpenGEM und SealOS (VM86 Mode wird unterstützt, um DOSEMU ausführen
zu können), FreeBSD, NetBSD, OpenBSD, Linux, MenuetOS, OS/2, QNX, ReactOS,
Syllable, Unununium und Windows laufen unter QEMU.

Emuliert wird neben der CPU auch:

      •   PCI und ISA-System (i440FX host PCI bridge und PIIX3 PCI to ISA bridge)

      •   Grafikkarte (Cirrus CLGD 5446 PCI VGA card oder Standard-VGA-Grafikkarte mit
          Bochs VESA Extensions (Hardware Level, inclusive aller nicht Standard Modi)

      •   PS/2 Maus und Tastatur

      •   zwei PCI ATA-Schnittstellen mit Unterstützung für maximal vier Festplatten-Images
          im eigenen Format oder im Format von VMWare, VirtualPC, Bochs, Knoppix (cloop)
          und dd

      •   CD-ROM/DVD-Laufwerk über ISO-Abbild oder reales Laufwerk

      •   Diskettenlaufwerk

      •   Netzwerkkarte (NE2000 PCI Netzwerk Adapter) und ein DHCP-Server

      •   Serieller Port

      •   Paralleler Port

      •   Soundkarte (Soundblaster 16)

Das Starten von Live-CD- und Boot-Disketten-Images ist problemlos möglich.




9
    http://bochs.sourceforge.net/
Linux – Advanced                                                                       52




Abbildung 39: QEMU Manager


Die Installation und Konfiguration von QEMU wird im Wikibook QEMU10 beschrieben. Zur
leichteren Bedienung kann das Programm QEMU Manager11 verwendet werden.




10
     http://de.wikibooks.org/wiki/QEMU
11
     http://www.davereyn.co.uk/qemu.htm
Linux – Advanced                                                                         53




Abbildung 40: Opensuse 10 unter QEMU


2.4   Netzwerk – Installation

Nach dem Start des virtuellen Computers wird vom boot.iso Image gebootet. Es erscheint
der gewohnte Suse Installations-Bildschirm.
Linux – Advanced                                                          54




Abbildung 41: Netzwerk-Installation


Die Sprache wird mit    gewählt. Der Modus Installation wird bestätigt.




Abbildung 42: Keine Installationsquelle


Die Fehlermeldung, keine Installations-Quelle wird übernommen.
Linux – Advanced                                                                            55




Abbildung 43: Linuxrc


Der Installationsmanager Linuxrc startet. Die Tastaturbelegung Deutsch wird aktualisiert.




Abbildung 44: Linuxrc Hauptmenü


Im Hauptmenü von Linuxrc wird Installation / System starten gewählt.
Linux – Advanced                            56




Abbildung 45: Linuxrc - Installation




Abbildung 46: Linuxrc Quellmedium


Als Quellmedium wird Netzwerk ausgewählt.
Linux – Advanced                                                                      57




Abbildung 47: Linuxrc – Netzwerkprotokoll


Es empfiehlt sich das FTP-Protokoll oder HTTP-Protokoll zu verwenden. Die Netzwerkkarte
eth0 muss verwendet werden.




Abbildung 48: Linuxrc - DHCP aktivieren
Linux – Advanced                                                                           58

Ist im Netzwerk ein DHCP-Server aktiv, kann dieser verwendet werden. Ohne DHCP –
Server, müssen IP-Adresse, Netzmaske und Gateway händisch vergeben werden,




Abbildung 49: Linuxrc - HTTP Server


Die möglichen Mirror-Server12 sind auf der OpenSuSE Homepage eingetragen. Für die
Installation wird die IP-Adresse des Servers benötigt. Durch Ping auf den Hostnamen kann
die Adresse ausgelesen werden. Zum Beispiel:

          / # ping suse.inode.at
          PING suse.inode.at (81.223.20.170) 56(84) bytes of data.
          64 bytes from 81.223.20.170: icmp_seq=1 ttl=64 time=…




Abbildung 50: Linuxrc – HTTP-Proxy


Wird im Netzwerk ein Proxy-Server verwendet, muss dieser bekannt gegeben werden.




12
     http://www.opensuse.org/index.php/Mirrors_Released_Version#Europe
Linux – Advanced                                                                            59




Abbildung 51: Linuxrc – Verzeichnis


Das Installationsverzeichnis wird angegeben. Dieses kann je nach Server variieren (z.B.
http://suse.inode.at/: /opensuse/distribution/SL-10.0-OSS-beta3/inst-source). Das
Bereitstellen der Netzwerk-Installation einer neuen SuSE-Linux Version erfolgt erst einen
gewissen Zeitraum nach dem Verkaufsstart. Die weitere Installation entspricht der
Grundinstallation.

Folgende Einstellungen sollten bei der Installation verwendet werden.

Uhr und Zeitzone
Region: Europa
Zeitzone: Österreich
Rechneruhr eingestellt auf: lokale Zeit

Bildschirm-Einstellungen
KDE oder GNOME

Installationseinstellungen
…
Software-Auswahl: simple Web Server with Apache2
…

Root-Passwort
rooti

Benutzer
Username: tester
Passwort: te123er
Direkt anmelden: deaktiviert

Netzwerk
eth0: DHCP, wenn vorhanden
eth1: 192.168.0.254/255.255.255.0
Host: linux00.schule.local
Linux – Advanced                                                                 60

DNS: 193.171.90.37, 193.171.4.60
Firewall: deaktiviert

2.5     Übungsbeispiele

      40. Von welchen Netzwerkquellen kann Opensuse installiert werden?

      41. Wodurch unterscheidet sich die FTP von der http Installationsquelle?

      42. Nennen Sie drei Opensuse Mirror-Server.

      43. Wie erhalten Sie die IP-Adresse eines Mirror-Servers?
Linux – Advanced                                                                            61


3 Serverdienste

3.1   Network File Service (NFS)

Der Network File Service - abgekürzt NFS (früher: Network File System) - ist ein von Sun
Microsystems entwickeltes Protokoll, das den Zugriff auf Dateien über ein Netzwerk
ermöglicht. Dabei werden die Dateien nicht (wie z.B. bei FTP) übertragen, sondern die
Benutzer können auf Dateien, die sich auf einem entfernten Rechner befinden, so zugreifen,
als wenn sie auf ihrer lokalen Festplatte abgespeichert wären.

Bei diesem UNIX-Netzwerkprotokoll handelt es sich um einen Internet-Standard (RFC 1094,
RFC 1813), der auch als verteiltes Dateisystem (engl. Distributed File System) bezeichnet
wird. NFS-Dienste sind auch auf Microsoft-Windows-Servern verfügbar, wodurch UNIX-
Workstations Zugang zu deren Dateien erhalten können. Die Entsprechung zu NFS heißt
unter Windows- und OS/2-Umgebungen Server Message Block (SMB). Sowohl NFS als
auch SMB regeln Funktionen, um Dateien zu öffnen und zu schließen. Ferner regeln sie die
Zugriffskontrolle, welcher Benutzer Lese- und/oder Schreibzugriff auf eine Ressource erhält.




Abbildung 52: NFS im OSI-Schichtenmodell


NFS arbeitet auf dem Netzwerk-Transportprotokoll TCP/IP. NFS ist ursprünglich ein
zustandsloses UDP-Protokoll. Mittlerweile gibt es aber auch NFS über TCP. Derzeit wird
NFS Version 4 entwickelt, welches schneller und nicht mehr zustandslos sein soll.

3.1.1 NFS - Server

Benötigte Pakete: nfsserver, nfs-utils, portmap

Die Konfiguration des NFS-Servers erfolgt direkt mit YaST.
Linux – Advanced                                                                                62




Abbildung 53: Yast - Modul NFS-Server


In YaST wird die Kategorie Netzwerkdienste gewählt. Mit NFS-Server startet die
Konfiguration.




Abbildung 54: NFS-Server starten


Der Schalter Starten muss aktiviertet werden. Ist die Firewall aktiviert, muss zusätzlich der
NFS-Dienst und der Portmapper13 frei geschalten werden.




13
  Ein Portmapper übernimmt in der Informationstechnik die Koordination der durch den Client
gewünschten Funktionsaufrufe.
Linux – Advanced                                                                           63




Abbildung 55: Zu exportierendes Verzeichnis wählen


Das zu exportierende Verzeichnis kann mit Durchsuchen direkt aus dem Dateibaum
gewählt werden.




Abbildung 56: Rechner und Zugriffsoptionen für NFS


Unter Rechner-Wildcard können die IP-Adressen der Clients angeführt werden. Alternativ
kann * für alle Rechner verwendet werden, *.domain nur für eine bestimmte Domäne und
192.168.100.0/255.255.255.0 für ein bestimmtes Subnet.

Tabelle 5: Optionen für den NFS-Export



ro                    "read only" (schreibgeschützt)


rw                    "read/write" (volle Lese- und Schreibrechte für den Client)


noaccess              Zugriffsverweigerung für Unterverzeichnisse


root_squash           root erhält die UserID des Pseudobenutzers nobody, eine sichere
                      (Default-)Einstellung, da so der root-Benutzer des Client-Rechners
                      nicht mit root-Rechten auf dem Server schreiben kann.
Linux – Advanced                                                                          64



no_root_squash        root-Account auf dem Client wird dem auf dem Server gleichgestellt.
                      Hier ist der root-User des Client-Rechners auch root auf dem Server!


all_squash            Alle Zugreifenden erhalten die Nobody-UID


anongid=gid           Squashing der Gruppe. Die Gruppen-ID wird auf gid gesetzt. Bei
                      dieser Option kann root entscheiden, mit welcher Server-GID die
                      Client-User arbeiten sollen, sobald sie Zugriff auf den Server haben.


anonuid=uid           Squashing des Users. Die zugreifenden User bekommen die User-ID
                      uid verpasst.



3.1.2 NFS – Client

Freigegebene Verzeichnisse können direkt mit YaST in den Dateibaum eingebunden werde.




Abbildung 57: Yast - Modul NFS-Client


In YaST wird die Kategorie Netzwerkdienste gewählt. Mit NFS-Client startet die
Konfiguration.
Linux – Advanced                                                                        65




Abbildung 58: Konfiguration des NFS-Client


Mit Hinzufügen kann ein NFS-Server gewählt werden.




Abbildung 59: NFS-Verzeichnis einbinden


Wurde der Server gefunden, kann ein exportiertes Verzeichnis gewählt werden. Nach der
Angabe des lokalen Mountpointes können Optionen für das Einbinden gesetzt werden.

Tabelle 6: Mount-Parameter für über NFS-Verzeichnisse



rw, ro               Schreib- und Lesezugriff bzw. Nur-Lese-Zugriff
Linux – Advanced                                                                         66



fg                 Mount-Vorgang im Vordergrund ("foreground")


bg                 Mount-Vorgang im Hintergrund ("background")


retrans=zahl       Anzahl der Wiederholungsversuche, um einen Mount durchzuführen.
                   Der Default-Wert liegt bei 5.


hard               "Hartes" Mounten, d. h., es werden Anfragen abgesetzt, bis der
                   Server antwortet (default).


soft               "Weiches" Mounten, d. h., wenn ein Zähler abgelaufen ist (retrans),
                   gibt es eine Fehlermeldung, und der Versuch wird abgebrochen.


intr, nointr       Möglichkeit des Abbruchs durch eine Tastenkombination ("interrupt")
                   bzw. das Verhindern derselben.


remount            Aushängen eines Verzeichnisses, um es sofort wieder
                   (beispielsweise mit neuen Optionen) einzuhängen.


suid, nosuid       Möglichkeit zur Benutzung des SUID-Bits auf dem eingehängten
                   Dateisystem.


retry=zahl         Anzahl der erfolglosen Mount-Versuche (Default ist 10000), bis
                   endgültig abgebrochen wird.


wsize=zahl         Größe des Puffers für Schreibzugriffe (Default liegt zwischen 2048
                   und 32 kB, je nach Unix-System und -Version).


rsize=zahl         Puffergröße für Lesezugriffe (Default siehe oben).


timeo=zahl         Zeitspanne für Wiederholversuche, angegeben in Zehntelsekunden.
Linux – Advanced                                                                             67



proto=protokoll       ab Version 3: Angabe des Protokolls (UDP oder TCP).


nfsstat

Mit diesem Befehl werden NFS Statisken ausgegeben

       / # nfsstat
       Server rpc stats:
       calls       badcalls            badauth       badclnt        xdrcall
       20860       0                   0             0              0
       Server nfs v3:
       null        getattr             setattr    lookup           access    readlink
       0       0% 264       1%         0       0% 1148          5% 14726 70% 32
       …




Tabelle 7: nfsstat Optionen



-s            Gibt nur serverseitige Informationen aus. Voreingestellt sind sowohl Client-
              als auch Serverinformationen.


-c            Gibt nur clientseitige Informationen aus. Voreingestellt sind sowohl Client- als
              auch Serverinformationen.


-n            Gibt nur NFS-Statistiken aus. Voreingestellt sind NFS und RPC Statistiken.


-r            Gibt nur RPC-Statistiken aus.




Tabelle 8: NFS Konfigurations-Datein



/etc/export            Im File /etc/exports sind alle zu exportierenden Verzeichnisse
                       aufgeführt. Dazu kommen Angaben, wer (welche Clients) wie (mit
                       welchen Rechten) auf die Freigaben zugreifen dürfen.


/etc/hosts.allow       Die Datei hosts.allow dient der Zugangskontrolle von
Linux – Advanced                                                                              68

                      Nutzern/Diensten anderer Rechner. Für bestimmte Hosts/Netzwerke
                      kann hier der Zugriff auf bestimmte lokale Dienste explizit gestattet
                      werden.


/etc/hosts.deny       In hosts.deny kann der Zugang zu bestimmten Diensten des
                      Rechners für bestimmte Hosts/Netzwerke explizit untersagt werden.


/etc/fstab            In der Datei /etc/fstab des lokalen NFS-Client-Rechners stehen alle
                      Dateisysteme, Schnittstellen und Devices, die irgendwann einmal
                      gemountet werden bzw. werden können.



3.2   DHCP – Server

Das DHCP (Dynamic Host Configuration Protocol) ermöglicht mit Hilfe eines entsprechenden
Servers die dynamische Zuweisung einer IP-Adresse und weiterer Konfigurationsparameter
an Computer in einem Netzwerk (vgl. 1.13 Dynamic Host Configuration Protocol).

Benötigte Pakete: dhcpcd, dhcp-server

Dynamisches DHCP

Die Konfiguration des dynamischen DHCP erfolgt direkt mit YaST.




Abbildung 60: Yast - Modul DHCP-Server


In YaST wird die Kategorie Netzwerkdienste gewählt. Mit DCHP-Server startet die
Konfiguration.
Linux – Advanced                                                                           69




Abbildung 61: DHCP auf Netzwerkkarte eht1 binden


Der DHCP Server wird auf die Netzwerkkarte eth1 gebunden. Händisch müsste eine Route
mit der Adresse 255.255.255.255 der Netzwerkkarte zugeordnet werden.

       / # route add 255.255.255.255 eth0




Abbildung 62: DHCP Konfiguration


Die globalen Einstellungen werden in Schritt 2 gesetzt. Im Schritt 3 wird der dynamische
Adressbereich vergeben.
Linux – Advanced                                                                       70




Abbildung 63: Dynamisches DHCP


Das Ergebnis der Konfiguration kann in der Datei /etc/dhcpd.conf betrachtet werden.




Abbildung 64: /etc/dhcpd.conf


Statisches DHCP

Beim Einrichten von statischen DHCP, muss die Datei /etc/dhcpd.conf editiert werden.

       # DHCP-Server statisch
           #/etc/dhcpd.conf
Linux – Advanced                                                             71

            #
            # -> Kommentarzeile


            # Folgende Options gelten für alle Rechner
            option domain-name "schule.local";
            option domain-name-servers 193.171.90.37;
            option subnet-mask 255.255.255.0;
            option broadcast-address 192.168.0.255;
            option routers 192.168.0.254;

            #Verfallsdauer
            default-lease-time 86400;
            max-lease-time 2592000;

            subnet 192.168.0.0 netmask 255.255.255.0
            {
            # Alle Clients bekommen IP-Adresse nach ihrer MAC-Adresse
            host client10
               {
                 hardware ethernet 00:10:5f:58:43:9b;
                 fixed-address 192.168.0.10;
               }
            host client11
               {
                 hardware ethernet 00:10:5f:47:3b:05;
                 fixed-address 192.168.0.11;
               }
            }

Gemischtes DHCP

Der Normalfall wird das gemischte DHCP sein. Die ganze Konfigurationsdatei
/etc/dhcpd.conf sieht dann so aus:

            # DHCP-Server Konfiguration gemischtes DHCP
            #/etc/dhcpd.conf
            #
            # -> Kommentarzeile

            # Folgende Options gelten für alle Rechner
            option domain-name "schule.local";
            option domain-name-servers 193.171.90.37 193.171.4.60;
            option subnet-mask 255.255.255.0;
            option broadcast-address 192.168.0.255;
            option routers 192.168.0.254;

            #Verfallsdauer
            default-lease-time 86400;
            max-lease-time 2592000;

          subnet 192.168.0.0 netmask 255.255.255.0
           {
           # Alle Clients bekommen IP-Adresse nach ihrer MAC-Adresse
           host client10
Linux – Advanced                                                                                72

                  {
                      hardware ethernet 00:10:5f:58:43:9b;
                      fixed-address 192.168.0.10;
               }
            host client11
               {
                 hardware ethernet 00:10:5f:47:3b:05;
                 fixed-address 192.168.0.11;
               }
            }

             #Die Adressen 192.168.0.100 bis 192.168.0.200 werden→
       dynamisch vergeben
               range 192.168.0.100 192.168.0.200;
           }




Tabelle 9: DHCP Konfigurations-Datein



/etc/dhcpd.conf         Das File /etc/dhcpd.conf ist das zentrale Konfigurations-File für den
                        DHCP-Server.



3.3   DNS – Server

Das Domain Name System (DNS) ist einer der wichtigsten Dienste im Internet. Das DNS ist
eine verteilte Datenbank, die den Namensraum im Internet verwaltet (vgl. 1.14 Domain
Name Service).

Ein weit verbreiteter Nameserver unter Linux ist bind.

Benötigte Pakete: bind

Der erste Schritt ist das Ändern der Konfiguration der Netzwerkkarten. Als Nameserver wird
die IP des Rechners selber als Nameserver 1 eingetragen.
Linux – Advanced                                                                        73




Abbildung 65: Netzwerkkarte für DNS vorbereiten


Die forward Zone kann direkt mit Yast eingerichtet werden. In YaST wird die Kategorie
Netzwerkdienste gewählt. Mit DNS-Server startet die Konfiguration.




Abbildung 66: DNS-Server


Im ersten Schritt wird der Start des Nameservers festgelegt. Um eine funktionierende
Namensauflösungen zu gewährleisten, muss der Dienst beim Systemstart aktiviert werden.
Linux – Advanced                                                                      74




Abbildung 67: DNS-Server starten


Als Forwarders werden weitere DNS-Server bezeichnet. Kann der eigene Server die
Namensauflösung nicht durchführen, wird die Anfrage an diese Server weitergeleitet.




Abbildung 68: DNS-Forwarder




Abbildung 69: DNS-Protokollierung
Linux – Advanced                                                                       75


3.3.1 Forward Zone

Nach der Einstellung der Protokollierung wird die erste DNS-Zone erstellt. Die Zone
schule.local wird eine Locale-Masterzone. Der Zonen-Transport kann aktiviert werden,
muss aber nicht.




Abbildung 70: DNS-Master-Zone




Abbildung 71: DNS Zonen-Transport


Der NS-Eintrag bestimmt den zuständigen Nameserver der Zone. Pro Zone sollten zwei
zuständige Nameserver eingetragen werden (Primary und Sekondary).




Abbildung 72: NS (Nameserver) der Zone schule.local
Linux – Advanced                                                                            76




Abbildung 73: MX (Mailserver) der Zone schule.local


Der MX-Eintrag bestimmt den zuständigen Mailserver für die Zone.




Abbildung 74: SOA (Start of Authority)


Neu seit Bind8.2 ist der Eintrag TTL. In früheren Versionen wurde diese Option an anderer
Stelle aufgeführt, aber seit der Veröffentlichung von RFC 2308 musste die TTL-Anweisung
an einem anderen Ort angegeben werden und hierfür wurde die erste Zeile gewählt. Dieser
Wert gibt an, wie lange ein abfragender Nameserver die Daten in seinem Cache halten darf,
bevor er die Daten aus dem Cache wieder entfernt.
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced
Linux advanced

Weitere ähnliche Inhalte

Was ist angesagt?

Team Oldenburger Robo-Fußball – Abschlussbericht der Projektgruppe 2010
Team Oldenburger Robo-Fußball – Abschlussbericht  der Projektgruppe  2010Team Oldenburger Robo-Fußball – Abschlussbericht  der Projektgruppe  2010
Team Oldenburger Robo-Fußball – Abschlussbericht der Projektgruppe 2010
Johannes Diemke
 
Besser php programmieren - Von der Klasse über Unittests, Cruisecontrol, Seli...
Besser php programmieren - Von der Klasse über Unittests, Cruisecontrol, Seli...Besser php programmieren - Von der Klasse über Unittests, Cruisecontrol, Seli...
Besser php programmieren - Von der Klasse über Unittests, Cruisecontrol, Seli...
teena77
 
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Daniel Ward
 
User manual
User manualUser manual
User manual
Galo Ayala
 
backy - Image-basiertes Backup für virtuelle Maschinen
backy - Image-basiertes Backup für virtuelle Maschinenbacky - Image-basiertes Backup für virtuelle Maschinen
backy - Image-basiertes Backup für virtuelle Maschinen
Christian Kauhaus
 
Agorum core-administrations-handbuch-6 4-0a
Agorum core-administrations-handbuch-6 4-0aAgorum core-administrations-handbuch-6 4-0a
Agorum core-administrations-handbuch-6 4-0a
agorum Software GmbH
 
Agorum core-entwickler-dokumentation-6 4-0
Agorum core-entwickler-dokumentation-6 4-0Agorum core-entwickler-dokumentation-6 4-0
Agorum core-entwickler-dokumentation-6 4-0
agorum Software GmbH
 
Tippsammlung 2010
Tippsammlung 2010Tippsammlung 2010
Tippsammlung 2010
Cantabrian
 
Zotero Tutorial
Zotero TutorialZotero Tutorial
Zotero Tutorial
heiko.vogl
 
Technikerarbeit: Technische Dokumentation in der Ersatzteillogistik
Technikerarbeit: Technische Dokumentation in der ErsatzteillogistikTechnikerarbeit: Technische Dokumentation in der Ersatzteillogistik
Technikerarbeit: Technische Dokumentation in der Ersatzteillogistik
TheRealWolf
 
Best Practice Guide
Best Practice GuideBest Practice Guide
Best Practice Guide
guestc141a6
 
Final Opentrans 2.0 Rfq
Final Opentrans 2.0   RfqFinal Opentrans 2.0   Rfq
Final Opentrans 2.0 Rfq
guest6f1fb4
 
382726314 X Php5 In 14 Tagen (Ddt)
382726314 X Php5 In 14 Tagen (Ddt)382726314 X Php5 In 14 Tagen (Ddt)
382726314 X Php5 In 14 Tagen (Ddt)
guest943d41
 
agorum core-benutzer-handbuch-6 4-0
agorum core-benutzer-handbuch-6 4-0agorum core-benutzer-handbuch-6 4-0
agorum core-benutzer-handbuch-6 4-0
agorum Software GmbH
 
[DE] Dr. Ulrich Kampffmeyer - Artikel auf Wikipedia | 2015
[DE] Dr. Ulrich Kampffmeyer - Artikel auf Wikipedia | 2015[DE] Dr. Ulrich Kampffmeyer - Artikel auf Wikipedia | 2015
[DE] Dr. Ulrich Kampffmeyer - Artikel auf Wikipedia | 2015
PROJECT CONSULT Unternehmensberatung Dr. Ulrich Kampffmeyer GmbH
 
Maven Definitive Guide De
Maven Definitive Guide DeMaven Definitive Guide De
Maven Definitive Guide De
bouchri
 

Was ist angesagt? (19)

Team Oldenburger Robo-Fußball – Abschlussbericht der Projektgruppe 2010
Team Oldenburger Robo-Fußball – Abschlussbericht  der Projektgruppe  2010Team Oldenburger Robo-Fußball – Abschlussbericht  der Projektgruppe  2010
Team Oldenburger Robo-Fußball – Abschlussbericht der Projektgruppe 2010
 
Manual
ManualManual
Manual
 
Besser php programmieren - Von der Klasse über Unittests, Cruisecontrol, Seli...
Besser php programmieren - Von der Klasse über Unittests, Cruisecontrol, Seli...Besser php programmieren - Von der Klasse über Unittests, Cruisecontrol, Seli...
Besser php programmieren - Von der Klasse über Unittests, Cruisecontrol, Seli...
 
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
Allgemeine betriebsdokumentation-kolab server22-20080103_1.0
 
User manual
User manualUser manual
User manual
 
Pr O St Doku
Pr O St DokuPr O St Doku
Pr O St Doku
 
backy - Image-basiertes Backup für virtuelle Maschinen
backy - Image-basiertes Backup für virtuelle Maschinenbacky - Image-basiertes Backup für virtuelle Maschinen
backy - Image-basiertes Backup für virtuelle Maschinen
 
Agorum core-administrations-handbuch-6 4-0a
Agorum core-administrations-handbuch-6 4-0aAgorum core-administrations-handbuch-6 4-0a
Agorum core-administrations-handbuch-6 4-0a
 
Agorum core-entwickler-dokumentation-6 4-0
Agorum core-entwickler-dokumentation-6 4-0Agorum core-entwickler-dokumentation-6 4-0
Agorum core-entwickler-dokumentation-6 4-0
 
Tippsammlung 2010
Tippsammlung 2010Tippsammlung 2010
Tippsammlung 2010
 
Zotero Tutorial
Zotero TutorialZotero Tutorial
Zotero Tutorial
 
Technikerarbeit: Technische Dokumentation in der Ersatzteillogistik
Technikerarbeit: Technische Dokumentation in der ErsatzteillogistikTechnikerarbeit: Technische Dokumentation in der Ersatzteillogistik
Technikerarbeit: Technische Dokumentation in der Ersatzteillogistik
 
Best Practice Guide
Best Practice GuideBest Practice Guide
Best Practice Guide
 
Final Opentrans 2.0 Rfq
Final Opentrans 2.0   RfqFinal Opentrans 2.0   Rfq
Final Opentrans 2.0 Rfq
 
Pdf Crack
Pdf CrackPdf Crack
Pdf Crack
 
382726314 X Php5 In 14 Tagen (Ddt)
382726314 X Php5 In 14 Tagen (Ddt)382726314 X Php5 In 14 Tagen (Ddt)
382726314 X Php5 In 14 Tagen (Ddt)
 
agorum core-benutzer-handbuch-6 4-0
agorum core-benutzer-handbuch-6 4-0agorum core-benutzer-handbuch-6 4-0
agorum core-benutzer-handbuch-6 4-0
 
[DE] Dr. Ulrich Kampffmeyer - Artikel auf Wikipedia | 2015
[DE] Dr. Ulrich Kampffmeyer - Artikel auf Wikipedia | 2015[DE] Dr. Ulrich Kampffmeyer - Artikel auf Wikipedia | 2015
[DE] Dr. Ulrich Kampffmeyer - Artikel auf Wikipedia | 2015
 
Maven Definitive Guide De
Maven Definitive Guide DeMaven Definitive Guide De
Maven Definitive Guide De
 

Andere mochten auch

oEmbed (on rails)
oEmbed (on rails)oEmbed (on rails)
oEmbed (on rails)
Kerstin Puschke
 
Timetable identity
Timetable identityTimetable identity
Timetable identity
heiko.vogl
 
Linux slides fort_2013_upload
Linux slides fort_2013_uploadLinux slides fort_2013_upload
Linux slides fort_2013_upload
Rosa Freund
 
TestDisk User Manual
TestDisk User ManualTestDisk User Manual
TestDisk User Manual
Rockety Ryder
 
Behind the scenes of a grown-up web application
Behind the scenes of a grown-up web applicationBehind the scenes of a grown-up web application
Behind the scenes of a grown-up web application
Kerstin Puschke
 
In der Ruhe liegt die Kraft
In der Ruhe liegt die KraftIn der Ruhe liegt die Kraft
In der Ruhe liegt die Kraft
WM-Pool Pressedienst
 
Not only SQL - CouchDB und andere NoSQL-Datenbanken
Not only SQL - CouchDB und andere NoSQL-DatenbankenNot only SQL - CouchDB und andere NoSQL-Datenbanken
Not only SQL - CouchDB und andere NoSQL-Datenbanken
Kerstin Puschke
 
NoSQL-Datenbanken am Beispiel CouchDB
NoSQL-Datenbanken am Beispiel CouchDBNoSQL-Datenbanken am Beispiel CouchDB
NoSQL-Datenbanken am Beispiel CouchDB
Kerstin Puschke
 
Grundlagen der Kommandozeile unter Unix/Linux (Folien)
Grundlagen der Kommandozeile unter Unix/Linux (Folien)Grundlagen der Kommandozeile unter Unix/Linux (Folien)
Grundlagen der Kommandozeile unter Unix/Linux (Folien)
Kerstin Puschke
 
Grundlagen der Kommandozeile unter Unix/Linux (Handout)
Grundlagen der Kommandozeile unter Unix/Linux (Handout)Grundlagen der Kommandozeile unter Unix/Linux (Handout)
Grundlagen der Kommandozeile unter Unix/Linux (Handout)
Kerstin Puschke
 
Rsyslog - Deutsche Qualitätsarbeit für Linux
Rsyslog - Deutsche Qualitätsarbeit für LinuxRsyslog - Deutsche Qualitätsarbeit für Linux
Rsyslog - Deutsche Qualitätsarbeit für Linux
Trivadis
 
Einstieg in relationale Datenbanken mit MySQL (Handout)
Einstieg in relationale Datenbanken mit MySQL (Handout)Einstieg in relationale Datenbanken mit MySQL (Handout)
Einstieg in relationale Datenbanken mit MySQL (Handout)
Kerstin Puschke
 
Linux monitoring
Linux monitoringLinux monitoring
Linux monitoring
Mark Veltzer
 
Einstieg in relationale Datenbanken mit MySQL (Folien)
Einstieg in relationale Datenbanken mit MySQL (Folien)Einstieg in relationale Datenbanken mit MySQL (Folien)
Einstieg in relationale Datenbanken mit MySQL (Folien)
Kerstin Puschke
 
Nmon Analysis - Performance monitoring tool for LINUX and AIX
Nmon Analysis - Performance monitoring tool for LINUX and AIXNmon Analysis - Performance monitoring tool for LINUX and AIX
Nmon Analysis - Performance monitoring tool for LINUX and AIX
Ganesh Mandala
 
3 infomeeting
3 infomeeting3 infomeeting
3 infomeeting
heiko.vogl
 
Extreme Linux Performance Monitoring and Tuning
Extreme Linux Performance Monitoring and TuningExtreme Linux Performance Monitoring and Tuning
Extreme Linux Performance Monitoring and Tuning
Milind Koyande
 
Windows command prompt a to z
Windows command prompt a to zWindows command prompt a to z
Windows command prompt a to z
Subuh Kurniawan
 

Andere mochten auch (20)

oEmbed (on rails)
oEmbed (on rails)oEmbed (on rails)
oEmbed (on rails)
 
Timetable identity
Timetable identityTimetable identity
Timetable identity
 
Linux slides fort_2013_upload
Linux slides fort_2013_uploadLinux slides fort_2013_upload
Linux slides fort_2013_upload
 
TestDisk User Manual
TestDisk User ManualTestDisk User Manual
TestDisk User Manual
 
Behind the scenes of a grown-up web application
Behind the scenes of a grown-up web applicationBehind the scenes of a grown-up web application
Behind the scenes of a grown-up web application
 
Linux- und Windows Rechner…
Linux- und Windows Rechner…Linux- und Windows Rechner…
Linux- und Windows Rechner…
 
In der Ruhe liegt die Kraft
In der Ruhe liegt die KraftIn der Ruhe liegt die Kraft
In der Ruhe liegt die Kraft
 
Not only SQL - CouchDB und andere NoSQL-Datenbanken
Not only SQL - CouchDB und andere NoSQL-DatenbankenNot only SQL - CouchDB und andere NoSQL-Datenbanken
Not only SQL - CouchDB und andere NoSQL-Datenbanken
 
NoSQL und CouchDB
NoSQL und CouchDBNoSQL und CouchDB
NoSQL und CouchDB
 
NoSQL-Datenbanken am Beispiel CouchDB
NoSQL-Datenbanken am Beispiel CouchDBNoSQL-Datenbanken am Beispiel CouchDB
NoSQL-Datenbanken am Beispiel CouchDB
 
Grundlagen der Kommandozeile unter Unix/Linux (Folien)
Grundlagen der Kommandozeile unter Unix/Linux (Folien)Grundlagen der Kommandozeile unter Unix/Linux (Folien)
Grundlagen der Kommandozeile unter Unix/Linux (Folien)
 
Grundlagen der Kommandozeile unter Unix/Linux (Handout)
Grundlagen der Kommandozeile unter Unix/Linux (Handout)Grundlagen der Kommandozeile unter Unix/Linux (Handout)
Grundlagen der Kommandozeile unter Unix/Linux (Handout)
 
Rsyslog - Deutsche Qualitätsarbeit für Linux
Rsyslog - Deutsche Qualitätsarbeit für LinuxRsyslog - Deutsche Qualitätsarbeit für Linux
Rsyslog - Deutsche Qualitätsarbeit für Linux
 
Einstieg in relationale Datenbanken mit MySQL (Handout)
Einstieg in relationale Datenbanken mit MySQL (Handout)Einstieg in relationale Datenbanken mit MySQL (Handout)
Einstieg in relationale Datenbanken mit MySQL (Handout)
 
Linux monitoring
Linux monitoringLinux monitoring
Linux monitoring
 
Einstieg in relationale Datenbanken mit MySQL (Folien)
Einstieg in relationale Datenbanken mit MySQL (Folien)Einstieg in relationale Datenbanken mit MySQL (Folien)
Einstieg in relationale Datenbanken mit MySQL (Folien)
 
Nmon Analysis - Performance monitoring tool for LINUX and AIX
Nmon Analysis - Performance monitoring tool for LINUX and AIXNmon Analysis - Performance monitoring tool for LINUX and AIX
Nmon Analysis - Performance monitoring tool for LINUX and AIX
 
3 infomeeting
3 infomeeting3 infomeeting
3 infomeeting
 
Extreme Linux Performance Monitoring and Tuning
Extreme Linux Performance Monitoring and TuningExtreme Linux Performance Monitoring and Tuning
Extreme Linux Performance Monitoring and Tuning
 
Windows command prompt a to z
Windows command prompt a to zWindows command prompt a to z
Windows command prompt a to z
 

Ähnlich wie Linux advanced

Blockchain-based access right management for private data in decentralized cl...
Blockchain-based access right management for private data in decentralized cl...Blockchain-based access right management for private data in decentralized cl...
Blockchain-based access right management for private data in decentralized cl...
ArtemEger
 
Whitepaper: Indoor Positionsbestimmung in Büros & intelligenten Gebäuden
Whitepaper: Indoor Positionsbestimmung in Büros & intelligenten GebäudenWhitepaper: Indoor Positionsbestimmung in Büros & intelligenten Gebäuden
Whitepaper: Indoor Positionsbestimmung in Büros & intelligenten Gebäuden
infsoft GmbH
 
Handbuch CONSIDEO Modeler V 5.0
Handbuch CONSIDEO Modeler V 5.0Handbuch CONSIDEO Modeler V 5.0
Handbuch CONSIDEO Modeler V 5.0
Detlef Kahrs
 
Masterarbeit / Fakultät für Mathematik und Informatik / Lehrgebiet Datenverar...
Masterarbeit / Fakultät für Mathematik und Informatik / Lehrgebiet Datenverar...Masterarbeit / Fakultät für Mathematik und Informatik / Lehrgebiet Datenverar...
Masterarbeit / Fakultät für Mathematik und Informatik / Lehrgebiet Datenverar...
Melanie Eibl
 
Whitepaper: Indoor Positionsbestimmung in Industrie & Logistik
Whitepaper: Indoor Positionsbestimmung in Industrie & LogistikWhitepaper: Indoor Positionsbestimmung in Industrie & Logistik
Whitepaper: Indoor Positionsbestimmung in Industrie & Logistik
infsoft GmbH
 
Besser php entwickeln - Erstentwurf
Besser php entwickeln - ErstentwurfBesser php entwickeln - Erstentwurf
Besser php entwickeln - Erstentwurf
Günther Haslbeck
 
Whitepaper Indoor Positionsbestimmung im Gesundheitswesen
Whitepaper Indoor Positionsbestimmung im GesundheitswesenWhitepaper Indoor Positionsbestimmung im Gesundheitswesen
Whitepaper Indoor Positionsbestimmung im Gesundheitswesen
infsoft GmbH
 
lernOS Prozessmodellierung Guide (Version 1.0)
lernOS Prozessmodellierung Guide (Version 1.0)lernOS Prozessmodellierung Guide (Version 1.0)
lernOS Prozessmodellierung Guide (Version 1.0)
Cogneon Akademie
 
Handbuch de
Handbuch deHandbuch de
Handbuch de
gordem
 
SITEFORUM Tutorial v7
SITEFORUM Tutorial v7SITEFORUM Tutorial v7
SITEFORUM Tutorial v7
anuvito
 
Large Scale Multilayer Perceptron
Large Scale Multilayer PerceptronLarge Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Sascha Jonas
 
Web-Entwicklung mit Spring, Hibernate und Facelets in Eclipse
Web-Entwicklung mit Spring, Hibernate und Facelets in EclipseWeb-Entwicklung mit Spring, Hibernate und Facelets in Eclipse
Web-Entwicklung mit Spring, Hibernate und Facelets in Eclipse
Sarah Steffen
 
Master thesis pascal_mueller01
Master thesis pascal_mueller01Master thesis pascal_mueller01
Master thesis pascal_mueller01
guest39ce4e
 
ABAP Test & Troubleshooting @SITMuc 2013
ABAP Test & Troubleshooting @SITMuc 2013ABAP Test & Troubleshooting @SITMuc 2013
ABAP Test & Troubleshooting @SITMuc 2013
SbgMartin
 
Sappres Netweaver Identity Management
Sappres Netweaver Identity ManagementSappres Netweaver Identity Management
Sappres Netweaver Identity Management
gueste2a899
 
HTML5 und CSS3 Übersicht
HTML5 und CSS3 ÜbersichtHTML5 und CSS3 Übersicht
HTML5 und CSS3 Übersicht
Sven Brencher
 
German Original
German OriginalGerman Original
German Original
guestbf6d98
 

Ähnlich wie Linux advanced (20)

Blockchain-based access right management for private data in decentralized cl...
Blockchain-based access right management for private data in decentralized cl...Blockchain-based access right management for private data in decentralized cl...
Blockchain-based access right management for private data in decentralized cl...
 
Whitepaper: Indoor Positionsbestimmung in Büros & intelligenten Gebäuden
Whitepaper: Indoor Positionsbestimmung in Büros & intelligenten GebäudenWhitepaper: Indoor Positionsbestimmung in Büros & intelligenten Gebäuden
Whitepaper: Indoor Positionsbestimmung in Büros & intelligenten Gebäuden
 
Handbuch CONSIDEO Modeler V 5.0
Handbuch CONSIDEO Modeler V 5.0Handbuch CONSIDEO Modeler V 5.0
Handbuch CONSIDEO Modeler V 5.0
 
Masterarbeit / Fakultät für Mathematik und Informatik / Lehrgebiet Datenverar...
Masterarbeit / Fakultät für Mathematik und Informatik / Lehrgebiet Datenverar...Masterarbeit / Fakultät für Mathematik und Informatik / Lehrgebiet Datenverar...
Masterarbeit / Fakultät für Mathematik und Informatik / Lehrgebiet Datenverar...
 
Whitepaper: Indoor Positionsbestimmung in Industrie & Logistik
Whitepaper: Indoor Positionsbestimmung in Industrie & LogistikWhitepaper: Indoor Positionsbestimmung in Industrie & Logistik
Whitepaper: Indoor Positionsbestimmung in Industrie & Logistik
 
Besser php entwickeln - Erstentwurf
Besser php entwickeln - ErstentwurfBesser php entwickeln - Erstentwurf
Besser php entwickeln - Erstentwurf
 
Whitepaper Indoor Positionsbestimmung im Gesundheitswesen
Whitepaper Indoor Positionsbestimmung im GesundheitswesenWhitepaper Indoor Positionsbestimmung im Gesundheitswesen
Whitepaper Indoor Positionsbestimmung im Gesundheitswesen
 
lernOS Prozessmodellierung Guide (Version 1.0)
lernOS Prozessmodellierung Guide (Version 1.0)lernOS Prozessmodellierung Guide (Version 1.0)
lernOS Prozessmodellierung Guide (Version 1.0)
 
Solution Guide
Solution GuideSolution Guide
Solution Guide
 
Handbuch de
Handbuch deHandbuch de
Handbuch de
 
Xm b
Xm bXm b
Xm b
 
SITEFORUM Tutorial v7
SITEFORUM Tutorial v7SITEFORUM Tutorial v7
SITEFORUM Tutorial v7
 
Large Scale Multilayer Perceptron
Large Scale Multilayer PerceptronLarge Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
 
Web-Entwicklung mit Spring, Hibernate und Facelets in Eclipse
Web-Entwicklung mit Spring, Hibernate und Facelets in EclipseWeb-Entwicklung mit Spring, Hibernate und Facelets in Eclipse
Web-Entwicklung mit Spring, Hibernate und Facelets in Eclipse
 
Master thesis pascal_mueller01
Master thesis pascal_mueller01Master thesis pascal_mueller01
Master thesis pascal_mueller01
 
ABAP Test & Troubleshooting @SITMuc 2013
ABAP Test & Troubleshooting @SITMuc 2013ABAP Test & Troubleshooting @SITMuc 2013
ABAP Test & Troubleshooting @SITMuc 2013
 
BSI Audit
BSI AuditBSI Audit
BSI Audit
 
Sappres Netweaver Identity Management
Sappres Netweaver Identity ManagementSappres Netweaver Identity Management
Sappres Netweaver Identity Management
 
HTML5 und CSS3 Übersicht
HTML5 und CSS3 ÜbersichtHTML5 und CSS3 Übersicht
HTML5 und CSS3 Übersicht
 
German Original
German OriginalGerman Original
German Original
 

Mehr von heiko.vogl

Learning Agreement Student Mobility for Studies
Learning Agreement  Student Mobility for StudiesLearning Agreement  Student Mobility for Studies
Learning Agreement Student Mobility for Studies
heiko.vogl
 
Studying in Graz,
Studying in Graz, Studying in Graz,
Studying in Graz,
heiko.vogl
 
Erasmus+ Journal Issue 1
Erasmus+ Journal Issue 1 Erasmus+ Journal Issue 1
Erasmus+ Journal Issue 1
heiko.vogl
 
In-Service Course Graz: VOICES - Integrated competences for European Teachers...
In-Service Course Graz: VOICES - Integrated competences for European Teachers...In-Service Course Graz: VOICES - Integrated competences for European Teachers...
In-Service Course Graz: VOICES - Integrated competences for European Teachers...
heiko.vogl
 
In-Service Course Graz 2014: VOICES - Integrated competences for European Te...
In-Service Course Graz 2014: VOICES -  Integrated competences for European Te...In-Service Course Graz 2014: VOICES -  Integrated competences for European Te...
In-Service Course Graz 2014: VOICES - Integrated competences for European Te...
heiko.vogl
 
EINVERSTÄNDNIS-, EINWILLIGUNGSERKLÄRUNG
EINVERSTÄNDNIS-, EINWILLIGUNGSERKLÄRUNGEINVERSTÄNDNIS-, EINWILLIGUNGSERKLÄRUNG
EINVERSTÄNDNIS-, EINWILLIGUNGSERKLÄRUNG
heiko.vogl
 
EINVERSTÄNDNIS-, EINWILLIGUNGSERKLÄRUNG
EINVERSTÄNDNIS-, EINWILLIGUNGSERKLÄRUNGEINVERSTÄNDNIS-, EINWILLIGUNGSERKLÄRUNG
EINVERSTÄNDNIS-, EINWILLIGUNGSERKLÄRUNG
heiko.vogl
 
VoiceS National Group Meeting Graz 2013
VoiceS National Group Meeting Graz 2013VoiceS National Group Meeting Graz 2013
VoiceS National Group Meeting Graz 2013
heiko.vogl
 
E Book
E BookE Book
E Book
heiko.vogl
 
Sport- und Kreativwoche 2013
Sport- und Kreativwoche 2013Sport- und Kreativwoche 2013
Sport- und Kreativwoche 2013
heiko.vogl
 
Sport- und Kreativwoche 2012
Sport- und Kreativwoche 2012Sport- und Kreativwoche 2012
Sport- und Kreativwoche 2012
heiko.vogl
 
Learning-Management vs. Beziehungsmanagement
Learning-Management vs. BeziehungsmanagementLearning-Management vs. Beziehungsmanagement
Learning-Management vs. Beziehungsmanagement
heiko.vogl
 
Entwurf eines Posters Erasmus &lt;-> Facebook
Entwurf eines Posters Erasmus &lt;-> FacebookEntwurf eines Posters Erasmus &lt;-> Facebook
Entwurf eines Posters Erasmus &lt;-> Facebook
heiko.vogl
 
Entwurf des Papers Erasmus &lt;-> Facebook
Entwurf des Papers Erasmus &lt;-> FacebookEntwurf des Papers Erasmus &lt;-> Facebook
Entwurf des Papers Erasmus &lt;-> Facebook
heiko.vogl
 
20120130 Erasmus Auslandsstudium 1 Infomeeting
20120130 Erasmus Auslandsstudium 1 Infomeeting20120130 Erasmus Auslandsstudium 1 Infomeeting
20120130 Erasmus Auslandsstudium 1 Infomeeting
heiko.vogl
 
Erasmus Auslandsstudium 1. Infomeeting
Erasmus Auslandsstudium 1. InfomeetingErasmus Auslandsstudium 1. Infomeeting
Erasmus Auslandsstudium 1. Infomeeting
heiko.vogl
 
moodle vs. facebook.ppt
moodle vs. facebook.pptmoodle vs. facebook.ppt
moodle vs. facebook.ppt
heiko.vogl
 
moodle vs facebook
moodle vs facebookmoodle vs facebook
moodle vs facebook
heiko.vogl
 
20091017 design ii_detailkonzept
20091017 design ii_detailkonzept20091017 design ii_detailkonzept
20091017 design ii_detailkonzept
heiko.vogl
 
20091017 design i_rahmenkonzept
20091017 design i_rahmenkonzept20091017 design i_rahmenkonzept
20091017 design i_rahmenkonzept
heiko.vogl
 

Mehr von heiko.vogl (20)

Learning Agreement Student Mobility for Studies
Learning Agreement  Student Mobility for StudiesLearning Agreement  Student Mobility for Studies
Learning Agreement Student Mobility for Studies
 
Studying in Graz,
Studying in Graz, Studying in Graz,
Studying in Graz,
 
Erasmus+ Journal Issue 1
Erasmus+ Journal Issue 1 Erasmus+ Journal Issue 1
Erasmus+ Journal Issue 1
 
In-Service Course Graz: VOICES - Integrated competences for European Teachers...
In-Service Course Graz: VOICES - Integrated competences for European Teachers...In-Service Course Graz: VOICES - Integrated competences for European Teachers...
In-Service Course Graz: VOICES - Integrated competences for European Teachers...
 
In-Service Course Graz 2014: VOICES - Integrated competences for European Te...
In-Service Course Graz 2014: VOICES -  Integrated competences for European Te...In-Service Course Graz 2014: VOICES -  Integrated competences for European Te...
In-Service Course Graz 2014: VOICES - Integrated competences for European Te...
 
EINVERSTÄNDNIS-, EINWILLIGUNGSERKLÄRUNG
EINVERSTÄNDNIS-, EINWILLIGUNGSERKLÄRUNGEINVERSTÄNDNIS-, EINWILLIGUNGSERKLÄRUNG
EINVERSTÄNDNIS-, EINWILLIGUNGSERKLÄRUNG
 
EINVERSTÄNDNIS-, EINWILLIGUNGSERKLÄRUNG
EINVERSTÄNDNIS-, EINWILLIGUNGSERKLÄRUNGEINVERSTÄNDNIS-, EINWILLIGUNGSERKLÄRUNG
EINVERSTÄNDNIS-, EINWILLIGUNGSERKLÄRUNG
 
VoiceS National Group Meeting Graz 2013
VoiceS National Group Meeting Graz 2013VoiceS National Group Meeting Graz 2013
VoiceS National Group Meeting Graz 2013
 
E Book
E BookE Book
E Book
 
Sport- und Kreativwoche 2013
Sport- und Kreativwoche 2013Sport- und Kreativwoche 2013
Sport- und Kreativwoche 2013
 
Sport- und Kreativwoche 2012
Sport- und Kreativwoche 2012Sport- und Kreativwoche 2012
Sport- und Kreativwoche 2012
 
Learning-Management vs. Beziehungsmanagement
Learning-Management vs. BeziehungsmanagementLearning-Management vs. Beziehungsmanagement
Learning-Management vs. Beziehungsmanagement
 
Entwurf eines Posters Erasmus &lt;-> Facebook
Entwurf eines Posters Erasmus &lt;-> FacebookEntwurf eines Posters Erasmus &lt;-> Facebook
Entwurf eines Posters Erasmus &lt;-> Facebook
 
Entwurf des Papers Erasmus &lt;-> Facebook
Entwurf des Papers Erasmus &lt;-> FacebookEntwurf des Papers Erasmus &lt;-> Facebook
Entwurf des Papers Erasmus &lt;-> Facebook
 
20120130 Erasmus Auslandsstudium 1 Infomeeting
20120130 Erasmus Auslandsstudium 1 Infomeeting20120130 Erasmus Auslandsstudium 1 Infomeeting
20120130 Erasmus Auslandsstudium 1 Infomeeting
 
Erasmus Auslandsstudium 1. Infomeeting
Erasmus Auslandsstudium 1. InfomeetingErasmus Auslandsstudium 1. Infomeeting
Erasmus Auslandsstudium 1. Infomeeting
 
moodle vs. facebook.ppt
moodle vs. facebook.pptmoodle vs. facebook.ppt
moodle vs. facebook.ppt
 
moodle vs facebook
moodle vs facebookmoodle vs facebook
moodle vs facebook
 
20091017 design ii_detailkonzept
20091017 design ii_detailkonzept20091017 design ii_detailkonzept
20091017 design ii_detailkonzept
 
20091017 design i_rahmenkonzept
20091017 design i_rahmenkonzept20091017 design i_rahmenkonzept
20091017 design i_rahmenkonzept
 

Linux advanced

  • 1. Linux – Advanced Erweiterte Serverdienste, Netzwerk Monitoring I
  • 2. Linux – Advanced 1 Inhaltsverzeichnis 1 TCP / IP.............................................................................................................................4 1.1 Open Systems Interconnection (OSI)-Referenzmodell.............................................4 1.2 Das TCP/IP-Referenzmodell ....................................................................................6 1.3 Die TCP/IP-Protokoll-Architektur ..............................................................................8 1.4 Internet Protokoll (IP)..............................................................................................10 1.5 Address Resolution Protocol (ARP)........................................................................18 1.6 Reverse Address Resolution Protocol (RARP).......................................................19 1.7 Internet Control Message Protocol (ICMP).............................................................20 1.8 Transmission Control Protocol (TCP) .....................................................................22 1.9 User Datagram Protocol (UDP) ..............................................................................26 1.10 Adressierung im TCP/IP .........................................................................................27 1.11 Subnetze ................................................................................................................28 1.11.1 Grundlagen .....................................................................................................29 1.11.2 Vorgehensweise zur Aufteilung in Subnetze ..................................................29 1.12 Classless Inter Domain Routing (CIDR) .................................................................33 1.13 Dynamic Host Configuration Protocol (DHCP) .......................................................34 1.14 Domain Name Service (DNS).................................................................................35 1.15 Übungsbeispiele .....................................................................................................38 2 Einrichten der Schulungsumgebung ...............................................................................41 2.1 VMware ..................................................................................................................41 2.2 Virtual PC ...............................................................................................................44 2.3 QEMU .....................................................................................................................50 2.4 Netzwerk – Installation ...........................................................................................53 2.5 Übungsbeispiele .....................................................................................................60 3 Serverdienste ..................................................................................................................61 3.1 Network File Service (NFS) ....................................................................................61 3.1.1 NFS - Server...................................................................................................61 3.1.2 NFS – Client ...................................................................................................64 3.2 DHCP – Server .......................................................................................................68 3.3 DNS – Server .........................................................................................................72 3.3.1 Forward Zone .................................................................................................75 3.3.2 Reverse-Lookup .............................................................................................78 3.3.3 Master- und Secondaryzonen.........................................................................80 3.3.4 Diagnose.........................................................................................................81 3.4 Samba Grundkonfiguration.....................................................................................84 3.4.1 Swat................................................................................................................88 3.5 Apache2 .................................................................................................................91 3.6 Postfix .....................................................................................................................95 3.7 Qpopper..................................................................................................................98 3.8 Übungsbeispiele .....................................................................................................99 4 Netzwerk Monitoring .....................................................................................................101 4.1 ifconfig ..................................................................................................................101 4.2 netstat...................................................................................................................102 4.3 ping.......................................................................................................................105 4.4 bing.......................................................................................................................106 4.5 fping......................................................................................................................106 4.6 traceroute .............................................................................................................106 4.7 nslookup ...............................................................................................................107 4.8 iptraf......................................................................................................................107 4.9 nmap.....................................................................................................................108 4.10 tcpdump ................................................................................................................113 4.11 ethereal.................................................................................................................113 4.12 ntop.......................................................................................................................116
  • 3. Linux – Advanced 2 4.13 Nessus..................................................................................................................117 4.14 Übungsbeispiele ...................................................................................................121 5 Server Security..............................................................................................................123 5.1 SuSE Sicherheitseinstellugen...............................................................................123 5.2 SuSE Firewall .......................................................................................................124 5.3 Webmin ................................................................................................................127 5.4 Apache mit mod_ssl .............................................................................................128 5.5 Übungsbeispiele ...................................................................................................129 6 Stichwortverzeichnis .....................................................................................................130 7 Abbildungsverzeichnis ..................................................................................................131 8 Tabellenverzeichnis ......................................................................................................134 9 Literaturverzeichnis .......................................................................................................135
  • 4. Linux – Advanced 3 Vorwort LINUX, das Unix ähnliche System von Linus Torvald, ist zu einer echten Alternative für Schulen gereift. Speziell für Schulen bietet ein solches System viele Vorteile. Abgesehen von der günstigen Anschaffung und des geringen Wartungsaufwandes gibt es eine Vielzahl von Erweiterungen, die das schulische Arbeiten erleichtern. Ich habe versucht eine Installation von Opensuse 10 Beta2 für eine Schulumgebung mit erweiterten Serverdiensten zu beschreiben. Neben den Serverdiendiensten, wird das Hauptaugenmerk auf die Fehlersuche im eigenen lokalen Netzwerk gelegt. Die meisten der vorgestellten Tools funktionieren übrigens nicht nur unter Linux, sondern können auch für Windows verwendet werden. Vor der endgültigen Installation empfiehlt es sich, ein Testsystem zu erstellen. Dafür reicht ein einfacher PC oder eine virtuelle Arbeitsumgebung wie zum Beispiel VMware, Virtual PC oder das freie QEMU. Erst wenn alles getestet wurde, sollte ein Echtsystem installiert werden. LINUX ist ein sich schnell weiter entwickelndes Betriebssystem. Opensuse zum Beispiel bringt wöchentlich am Donnerstag neue Releasis heraus. Dieses Buch baut auf das Wissen des Buches Vogl, H. Der Linux Schulserver auf. Auch dieses Buch ist einem ständigen Veränderungsprozess unterworfen. Über Anregungen und Verbesserungsvorschläge würde ich mich sehr freuen. Heiko Vogl heiko.vogl@gmx.at Graz, 2005
  • 5. Linux – Advanced 4 1 TCP / IP 1.1 Open Systems Interconnection (OSI)-Referenzmodell Das Open Systems Interconnection (OSI)-Referenzmodell ist ein Modell, dass auf einem Vorschlag der International Standards Organisation (ISO) basiert. Der Aufbau des OSI- Modells ist in der folgenden Abbildung dargestellt. Abbildung 1: OSI-Referenzmodell Das Modell dient derzeit allgemein als Rahmen zur Beschreibung von Protokollcharakteristika und –funktionen. Das OSI-Modell (die offizielle Bezeichnung lautet ISO-OSI-Referenzmodell) besteht aus sieben Schichten. Die Schichtung beruht auf dem Prinzip, dass eine Schicht der jeweils über ihr angeordneten Schicht bestimmte Dienstleistungen anbietet. Das OSI-Modell ist keine Netzarchitektur, da die Protokolle und Dienste der einzelnen Schichten vom Modell nicht definiert werden. Das Modell beschreibt lediglich, welche Aufgaben die Schichten erledigen sollen. Die folgenden Prinzipien haben zur Siebenschichtigkeit des OSI-Modells geführt: • Eine neue Schicht soll dort entstehen, wo ein neuer Abstraktionsgrad benötigt wird. • Jede Schicht soll eine genau definiert Funktion erfüllen. • Bei der Funktionswahl soll die Definition international genormter Protokolle berücksichtigt werden.
  • 6. Linux – Advanced 5 • Die Grenzen zwischen den einzelnen Schichten sollen so gewählt werden, dass der Informationsfluss über die Schnittstellen möglichst gering ist. • Die Anzahl der Schichten soll so groß sein, dass keine Notwendigkeit besteht, verschiedene Funktionen in eine Schicht zu packen. Aber auch nicht so klein, dass die gesamte Architektur unhandlich wird. Den Schichten im OSI-Modell sind die folgenden Aufgaben zugeordnet: Anwendungsschicht (application layer) Die Anwendungsschicht enthält eine große Zahl häufig benötigter Protokolle, die einzelne Programme zur Erbringung ihrer Dienste definiert haben. Auf der Anwendungsschicht finden sich z.B. die Protokolle für die Dienste ftp, telnet, mail etc. Darstellungsschicht (presentation layer) Die Darstellungsschicht regelt die Darstellung der Übertragungsdaten in einer von der darüber liegenden Ebene unabhängigen Form. Computersysteme verwenden z.B. oft verschiedene Codierungen für Zeichenketten (z.B. ASCII, Unicode), Zahlen usw. Damit diese Daten zwischen den Systemen ausgetauscht werden können, kodiert die Darstellungsschicht die Daten auf eine standardisierte und vereinbarte Weise. Sitzungsschicht (session layer) Die Sitzungsschicht (oft auch Verbindungsschicht oder Kommunikationssteuerschicht genannt) ermöglicht den Verbindungsauf- und abbau. Von der Sitzungsschicht wird der Austausch von Nachrichten auf der Transportverbindung geregelt. Sitzungen können beispielsweise einen Transfer gleichzeitig in zwei oder nur eine Richtung ermöglichen. Kann der Transfer nur in eine Richtung stattfinden, regelt die Sitzungsschicht, welcher der Kommunikationspartner jeweils an die Reihe kommt. Transportschicht (transport layer) Die Transportschicht übernimmt den Transport von Nachrichten zwischen den Kommunikationspartnern. Sie hat die grundlegende Aufgabe, den Datenfluss zu steuern und die Unverfälschtheit der Daten sicherzustellen. Beispiele für Transportprotokolle sind TCP und UDP. Netzwerkschicht (network layer) Die Netzwerkschicht (Vermittlungsschicht) hat die Hauptaufgabe eine Verbindung zwischen Knoten im Netzwerk herzustellen. Die Netzwerkschicht soll dabei die übergeordneten Schichten von den Details der Datenübertragung über das Netzwerk befreien. Eine der wichtigsten Aufgaben der Netzwerkschicht ist z.B. die Auswahl von Paketrouten bzw. das
  • 7. Linux – Advanced 6 Routing vom Absender zum Empfänger. Das Internet Protokoll (IP) ist in die Netzwerkschicht einzuordnen. Sicherungsschicht (data link layer) Die Aufgabe der Sicherungsschicht (Verbindungsschicht) ist die gesicherte Übertragung von Daten. Vom Sender werden hierzu die Daten in Rahmen (frames) aufgeteilt und sequentiell an den Empfänger gesendet. Vom Empfänger werden die empfangenen Daten durch Bestätigungsrahmen quittiert. Protokollbeispiele für die Sicherungsschicht sind HDLC (high- level data link control), SLIP (serial line IP) und PPP (point-to-point Protokoll). Bitübertragungsschicht (physical layer) Die Bitübertragungsschicht regelt die Übertragung von Bits über das Übertragungsmedium. Dies betrifft die Übertragungsgeschwindigkeit, die Bit-Codierung, den Anschluss (wieviele Pins hat der Netzanschluss?) etc. Die Festlegungen der Bitübertragungsschicht betreffen im Wesentlichen die Eigenschaften des Übertragungsmediums. 1.2 Das TCP/IP-Referenzmodell Im vorhergehenden Abschnitt wurde das OSI-Referenzmodell vorgestellt. In diesem Abschnitt soll nun das Referenzmodell für die TCP/IP-Architektur vorgestellt werden. Das TCP/IP-Referenzmodell, benannt nach den beiden primären Protokollen TCP und IP der Netzarchitektur, beruht auf den Vorschlägen, die bei der Fortentwicklung des ARPANETs gemacht wurden. Das TCP/IP-Modell ist zeitlich vor dem OSI-Referenzmodell entstanden. Die Erfahrungen des TCP/IP-Modells sind in die OSI-Standardisierung eingeflossen. Das TCP/IP-Referenzmodell besteht im Gegensatz zum OSI-Modell aus vier Schichten: Application Layer, Transport Layer, Internet Layer, Network Layer. Als Ziele der Architektur wurden bei der Entwicklung definiert: • Unabhängigkeit von der verwendeten Netzwerk-Technologie. • Unabhängigkeit von der Architektur der Hostrechner. • Universelle Verbindungsmöglichkeiten im gesamten Netzwerk. • Ende-zu-Ende-Quittungen. • Standardisierte Anwendungsprotokolle.
  • 8. Linux – Advanced 7 Abbildung 2: Vergleich des OSI-Referenzmodells mit dem TCP/IP-Referenzmodell Applikationsschicht (application layer) Die Applikationsschicht (auch Verarbeitungsschicht genannt) umfasst alle höherschichtigen Protokolle des TCP/IP-Modells. Zu den ersten Protokollen der Verarbeitungsschicht zählen TELNET (für virtuelle Terminals), FTP (Dateitransfer) und SMTP (zur Übertragung von E- Mails). Im Laufe der Zeit kamen zu den etablierten Protokollen viele weitere Protokolle wie z.B. DNS (Domain Name Service) und HTTP (Hypertext Transfer Protocol) hinzu. Transportschicht (transport layer) Wie im OSI-Modell ermöglicht die Transportschicht die Kommunikation zwischen den Quell- und Zielhosts. Im TCP/IP-Referenzmodell wurden auf dieser Schicht zwei Ende-zu-Ende- Protokolle definiert: das Transmission Control Protocol (TCP) und das User Datagram Protocol (UDP). TCP ist ein zuverlässiges verbindungsorientiertes Protokoll. Dadurch kann ein Bytestrom fehlerfrei einem anderen Rechner im Internet übermittelt werden. UDP ist ein unzuverlässiges, verbindungsloses Protokoll, das vorwiegend für Abfragen und Anwendungen in Client/Server-Umgebungen verwendet wird. Es dient nicht um eine sehr genaue, sondern schnelle Datenübermittlung geht (z.B. Übertragung von Sprache und Bildsignalen). Internetschicht (internet layer) Die Internetschicht im TCP/IP-Modell definiert ein Protokoll namens IP (Internet Protocol), das alle am Netzwerk beteiligten Rechner verstehen können. Die Internetschicht hat die Aufgabe IP-Pakete richtig zuzustellen. Dabei spielt das Routing der Pakete eine wichtige Rolle. Das Internet Control Message Protocol (ICMP) ist fester Bestandteil jeder IP-
  • 9. Linux – Advanced 8 Implementierung und dient zur Übertragung von Diagnose- und Fehlerinformationen für das Internet Protocol. Netzwerkschicht (network layer) Unterhalb der Internetschicht befindet sich im TCP/IP-Modell eine große Definitionslücke. Das Referenzmodell sagt in dieser Ebene nicht viel darüber aus, was hier passieren soll. Festgelegt ist lediglich, dass zur Übermittlung von IP-Paketen ein Host über ein bestimmtes Protokoll an ein Netz angeschlossen werden muss. Dieses Protokoll ist im TCP/IP-Modell nicht weiter definiert und weicht von Netz zu Netz und Host zu Host ab. Das TCP/IP-Modell macht an dieser Stelle vielmehr Gebrauch von bereits vorhandenen Protokollen, wie z.B. Ethernet (IEEE 802.3), Serial Line IP (SLIP), etc. 1.3 Die TCP/IP-Protokoll-Architektur Abbildung 3: Die TCP/IP-Protokoll-Architektur Die TCP/IP-Architektur wird im Allgemeinen als vierschichtiges Modell beschrieben. Oft wird
  • 10. Linux – Advanced 9 das TCP/IP-Referenzmodell auch als fünfschichtiges Modell dargestellt. Abbildung 4: OSI-Referenzmodell, TCP/IP-Referenzmodell, Hybrides Referenzmodell Die Schichtung beruht auf dem Prinzip, dass eine Schicht die angebotenen Dienste der darunter liegenden Schicht in Anspruch nehmen kann. Dabei braucht jene Schicht, die die Dienstleistung in Anspruch nimmt, keinerlei Kenntnisse darüber haben, wie die geforderten Dienste erbracht werden. Auf diese Art und Weise wird eine Aufgabenteilung der Schichten erreicht. Daten, die von einem Applikationsprogramm über ein Netzwerk versendet werden, durchlaufen den TCP/IP-Protokollstapel von der Applikationsschicht zur Netzwerkschicht. Von jeder Schicht werden dabei Kontrollinformationen in Form eines Protokollkopfes angefügt. Diese Kontrollinformationen dienen der korrekten Zustellung der Daten. Das Zufügen von Kontrollinformationen wird als Einkapselung (encapsulation) bezeichnet. Abbildung 5: Dateneinkapselung
  • 11. Linux – Advanced 10 Innerhalb der Schichten des TCP/IP-Modells werden Daten mit verschiedenen Termini benannt, da jede Schicht auch ihre eigenen Datenstrukturen hat. Applikationen, die das Transmission Control Protocol benutzen, bezeichnen Daten als Strom (stream); Applikationen, die das User Datagram Protocol verwenden, bezeichnen Daten als Nachricht (message). Auf der Transportebene bezeichnen die Protokolle TCP und UDP ihre Daten als Segment (segment) bzw. Paket (packet). In der Internet Schicht werden Daten allgemein als Datengramm (datagram) benannt. Oft werden die Daten hier aber auch als Paket bezeichnet. Auf der Netzwerkebene bezeichnen die meisten Netzwerke ihre Daten als Pakete oder Rahmen (frames). Abbildung 6: Datenbezeichnung des TCP/IP-Modells 1.4 Internet Protokoll (IP) Die Vermittlungsschicht im Internetprotokoll kann Datagramme nur an einen direkt erreichbaren Router senden. Wir verwenden hier das folgende einfache Modell für die Kommunikation im Internetprotokoll: Abbildung 7: IP Kommunikation Eine Station ist entweder ein Router zwischen Netzen oder eine Datenendeinrichtung, die ein Datagramm nur absenden oder empfangen kann. Da das Internetprotokoll einen von evtl. mehreren direkt erreichbaren Routern auswählen muss, wurden mehrere Partnerstationen dargestellt.
  • 12. Linux – Advanced 11 Datenübertragung mit Datagrammen Ähnlich dem Paket im X.25/PLP hat auch ein Datagramm im IP einen festen Aufbau, bestehend aus einem Datagrammkopf (Datagram Header) und einem Datenbereich (Data Area). Abbildung 8: Datagrammkopf Im Internet werden die Datagramme nicht direkt zwischen Routern verschickt, sondern in der Regel in einen Block eingepackt, der sie an den nächsten Rechner transportiert; dieser Block kann z.B. ein Ethernet- oder ein FDDI-Rahmen sein. Hieraus resultiert die Forderung, dass Datagramme nicht beliebig lang sein dürfen. Ein effizienter Transport kann nur garantiert werden, wenn jedes Datagramm in einen Rahmen passt. Die Größe eines solchen Rahmens ist jedoch von Netz zu Netz verschieden, so dass die Größe der Datagramme den Rahmengrößen der Netze, an die der jeweilige Rechner angeschlossen ist, angepasst sein sollte. Der Aufbau eines Rahmens mit Datagramm kann dann folgendermaßen dargestellt werden:
  • 13. Linux – Advanced 12 Abbildung 9: Datagramm Diese Forderung ist jedoch im allgemenen nicht zu erfüllen, da diese Größen zwischen 128 Bytes (in X.25-Netzen) und 4500 Bytes (in FDDI-Ringen) schwanken können, und zu kleine Datagramme wegen des recht großen Datagrammkopfes ineffizient sind. Daher legt das Internetprotokoll fest, dass das Netz Datagramme bis zu einer Länge von 576 Oktetten effizient übertragen muss. Wenn das Netz Rahmen mit Blöcken einer gegebenen Größe nicht übertragen kann, so darf es die Datagramme fragmentieren (fragment), d.h. in kürzere Blöcke zerlegen. Dabei enthält jeder Block neben einer Dateninformation auch den gesamten Datagrammkopf.
  • 14. Linux – Advanced 13 Abbildung 10: Datagramme fragmentieren Ein einmal fragmentiertes Datagramm wird auf seinem Weg zum Empfänger nicht wieder zusammengesetzt (reassemble), sondern unverändert weitergeschickt. Hierbei können durchaus verschiedene Wege für unterschiedliche Fragmente gewählt werden. Da jedes Fragment die gesamte notwendige Zielinformation enthält, können alle Zwischenstationen den richtigen Weg wählen. Sollten Fragmente eines Datagramms verloren gehen, so gilt das gesamte Datagramm als verloren und jene Teile, die den Empfänger evtl. erreichen, werden vernichtet. Die Information, ob ein Datagramm fragmentiert wurde, und in welcher Reihenfolge die Fragmente zusammengehören, muss natürlich gleichfalls im Datagrammkopf verschlüsselt werden. Abbildung 11: Datagramm wird reassembliert
  • 15. Linux – Advanced 14 Ein Datagramm wird reassembliert, indem ein eintreffendes Fragment anhand von Absenderadresse und einer Identifikation einem Datagramm zugeordnet wird. Anhand des Feldes Fragmentabstand FA kann die Position im gesamten Fragment, anhand des Längenfeldes GL die Länge des Datenteils berechnet werden. Dabei liegt der Anfang des Datenfragments bei FA*8, das Ende bei FA*8+(GL-20)-1. Die reassemblierende Station muss erkennen können, wann alle Fragmente eines Datagramms eingetroffen sind. Geschieht dieses nicht innerhalb einer bestimmten Zeit (z.B. 1 Minute), so wird das Datagramm beim Empfänger verworfen. IP-Datengramm Die TCP/IP-Protokolle wurden entwickelt, um Daten über ein paketvermittelndes Netz (wie dem ARPANET) zu übertragen. Ein Paket ist ein Datenblock zusammen mit den Informationen, die notwendig sind, um sie dem Empfänger zuzustellen (ein Paket ist also nichts anderes als ein Paket im herkömmliche Sinn bei der Post - das Paket enthält die Daten, auf dem Paket ist die Adresse des Empfängers notiert). Das Datengramm (datagram) ist das Paketformat, das vom Internet Protokoll definiert ist. Ein IP-Datengramm besteht aus einem Header und den zu übertragenden Daten. Der Header hat einen festen 20 Byte großen Teil, gefolgt von einem optionalen Teil variabler Länge. Der Header umfasst alle Informationen, die notwendig sind, um das Datengramm dem Empfänger zuzustellen. Ein Datengramm kann theoretisch maximal 64 KByte groß sein, in der Praxis liegt die Größe ungefähr bei 1500 Byte (das hängt mit der maximalen Rahmengröße des Ethernet-Protokolls zusammen). Abbildung 12: Der IP-Header
  • 16. Linux – Advanced 15 Die Felder, des in der Abbildung dargestellten Protokollkopfes, haben die folgende Bedeutung: Version Das Versions-Feld enthält die Versionsnummer des IP-Protokolls. Durch die Einbindung der Versionsnummer besteht die Möglichkeit über eine längere Zeit mit verschiedenen Versionen des IP Protokolls zu arbeiten. Einige Hosts können mit der alten und andere mit der neuen Version arbeiten. Die derzeitige Versionsnummer ist 4, aber die Version 6 des IP Protokolls befindet sich bereits in der Erprobung. Length Das Feld Length (Internet Header Length - IHL) enthält die Länge des Protokollkopfs, da diese nicht konstant ist. Die Länge wird in 32-Bit-Werten angegeben. Der kleinste zulässige Wert ist 5 - das entspricht also 20 Byte. In diesem Fall sind im Header keine Optionen gesetzt. Die Länge des Headers kann sich durch Anfügen von Optionen aber bis auf 60 Byte erhöhen. Type of Servive Über das Feld Type of Service kann das IP angewiesen werden Nachrichten nach bestimmten Kriterien zu behandeln. Als Dienste sind hier verschiedene Kombinationen aus Zuverlässigkeit und Geschwindigkeit möglich. In der Praxis wird dieses Feld aber ignoriert, hat also den Wert 0. Das Feld selbst hat den folgenden Aufbau: Abbildung 13: Type of Service Precedence (Bits 0-2) gibt die Priorität von 0 (normal) bis 7 (Steuerungspaket) an. Die drei Flags (D,T,R) ermöglichen es dem Host anzugeben, worauf er bei der Datenübertragung am meisten Wert legt: Verzögerung (Delay - D), Durchsatz (Throughput - T), Zuverlässigkeit (Reliability - R). Die beiden anderen Bit-Felder sind reserviert. Total Length Enthält die gesamte Paketlänge, d.h. Header und Daten. Da es sich hierbei um ein 16-Bit- Feld handelt ist die Maximallänge eines Datengramms auf 65.535 Byte begrenzt. In der Spezifikation von IP (RFC 791) ist festgelegt, dass jeder Host in der Lage sein muss, Pakete bis zu einer Länge von 576 Bytes zu verarbeiten. In der Regel können von dem Host aber Pakete größerer Länge verarbeitet werden.
  • 17. Linux – Advanced 16 Identification Über das Identifikationsfeld kann der Zielhost feststellen, zu welchem Datengramm ein neu angekommenes Fragment gehört. Alle Fragmente eines Datengramms enthalten die gleiche Identifikationsnummer, die vom Absender vergeben wird. Flags Das Flags-Feld ist drei Bit lang. Die Flags bestehen aus zwei Bits namens DF (Don't Fragment) und MF (More Fragments). Das erste Bit des Flags-Feldes ist ungenutzt bzw. reserviert. Die beiden Bits DF und MF steuern die Behandlung eines Pakets im Falle einer Fragmentierung. Mit dem DF-Bit wird signalisiert, dass das Datengramm nicht fragmentiert werden darf. Auch dann nicht, wenn das Paket eventuell nicht mehr weiter transportiert werden kann und verworfen werden muss. Alle Hosts müssen Fragmente bzw. Datengramme mit einer Größe von 576 Bytes oder weniger verarbeiten können. Mit dem MF-Bit wird angezeigt, ob einem IP-Paket weitere Teilpakete nachfolgen. Dieses Bit ist bei allen Fragmenten, außer dem letzten gesetzt. Fragment Offset Der Fragmentabstand bezeichnet, an welcher Stelle, relativ zum Beginn des gesamten Datengramms, ein Fragment gehört. Mit Hilfe dieser Angabe kann der Zielhost das Originalpaket wieder aus den Fragmenten zusammensetzen. Da dieses Feld nur 13 Bit groß ist, können maximal 8192 Fragmente pro Datengramm erstellt werden. Alle Fragmente, außer dem letzten, müssen ein Vielfaches von 8 Byte sein. Dies ist die elementare Fragmenteinheit. Time to Live Das Feld Time to Live ist ein Zähler, mit dem die Lebensdauer von IP-Paketen begrenzt wird. Im RFC 791 ist für dieses Feld als Einheit Sekunden spezifiziert. Zulässig ist eine maximale Lebensdauer von 255 Sekunden (8 Bit). Der Zähler muss von jedem Netzknoten, der durchlaufen wird, um mindestens 1 verringert werden. Bei einer längeren Zwischenspeicherung in einem Router muss der Inhalt sogar mehrmals verringert werden. Enthält das Feld den Wert 0, muss das Paket verworfen werden. Damit wird verhindert, dass ein Paket endlos in einem Netz umherwandert. Der Absender wird in einem solchen Fall durch eine Warnmeldung in Form einer ICMP-Nachricht informiert. Protocol Enthält die Nummer des Transportprotokolls, an das das Paket weitergeleitet werden muss. Die Nummerierung von Protokollen ist im gesamten Internet einheitlich. Bisher wurden die Protokollnummern im RFC 1700 definiert. Diese Aufgabe ist nun von der Internet Assigned
  • 18. Linux – Advanced 17 Numbers Authority1 (IANA) übernommen worden. Bei UNIX-Systemen sind die Protokollnummern in der Datei /etc/protocols abgelegt. Header Checksum Dieses Feld enthält die Prüfsumme der Felder im IP-Header. Die Nutzdaten des IP- Datengramms werden aus Effizienzgründen nicht mit geprüft. Diese Prüfung findet beim Empfänger innerhalb des Transportprotokolls statt. Die Prüfsumme muss von jedem Netzknoten, der durchlaufen wird, neu berechnet werden, da der IP-Header durch das Feld Time-to-Live sich bei jeder Teilstrecke verändert. Source Address, Destination Address In diese Felder werden die 32-Bit langen Internet-Adressen eingetragen. Options und Padding Das Feld Options wurde im Protokollkopf aufgenommen, um die Möglichkeit zu bieten, das IP-Protokoll um weitere Informationen zu ergänzen, die im ursprünglichen Design nicht berücksichtigt wurden. Das Optionsfeld hat eine variable Länge. Jede Option beginnt mit einem Code von einem Byte, über den die Option identifiziert wird. Manchen Optionen folgt ein weiteres Optionsfeld von 1 Byte und dann ein oder mehrere Datenbytes für die Option. Das Feld Options wird über das Padding auf ein Vielfaches von 4 Byte aufgefüllt. Derzeit sind die folgenden Optionen bekannt: • End of Option List (Kennzeichnet das Ende der Optionsliste) • No Option (Kann zum Auffüllen von Bits zwischen Optionen verwendet werden) • Security (Bezeichnet, wie geheim ein Datengramm ist. In der Praxis wird diese Option jedoch fast immer ignoriert.) • Loose Source-Routing, Strict Source-Routing (Diese Option enthält eine Liste von Internet-Adressen, die das Datagramm durchlaufen soll. Auf diese Weise kann dem Datenpaket vorgeschrieben werden eine bestimmte Route durch das Internet zu nehmen. Beim Source-Routing wird zwischen Strict Source and Record Route und Loose Source and Record Route unterschieden. Im ersten Fall wird verlangt, dass das Paket diese Route genau einhalten muss. Desweiteren wird die genommene Route aufgezeichnet. Die zweite Variante schreibt vor, dass die angegebenen Router nicht umgangen werden dürfen. Auf dem Weg können aber auch andere Router besucht werden.) 1 http://www.iana.org
  • 19. Linux – Advanced 18 • Record Route ( Die Knoten, die dieses Datengramm durchläuft, werden angewiesen ihre IP-Adresse an das Optionsfeld anzuhängen. Damit lässt sich ermitteln, welche Route ein Datengramm genommen hat. Wie anfangs schon gesagt, ist die Größe für das Optionsfeld auf 40 Byte beschränkt. Deshalb kommt es heute auch oftmals zu Problemen mit dieser Option, da weit mehr Router durchlaufen werden, als dies zu Beginn des ARPANET der Fall war.) • Time Stamp (Diese Option ist mit der Option Record Route vergleichbar. Zusätzlich zur IP-Adresse wird bei dieser Option die Uhrzeit des Durchlaufs durch den Knoten vermerkt. Auch diese Option dient hauptsächlich zur Fehlerbehandlung, wobei zusätzlich z.B. Verzögerungen auf den Netzstrecken erfasst werden können.) Weitere Details zu den Optionen sind in RFC 791 zu finden. 1.5 Address Resolution Protocol (ARP) In lokalen Netzen wird zur Bindung einer Protokolladresse mit einer Hardwareadresse meist das Address Resolution Protocol (ARP) verwendet, welches in RFC 826 standardisiert ist. Es wird ein ARP-Format definiert, welches für beliebige Adressformate gelten soll. Abbildung 14: ARP ARP-Nachrichten im Ethernet werden anhand des Ethernet-Typ-Feldes (Kennung 80616) kenntlich gemacht. Anfragen und Antworten werden durch unterschiedliche Einträge im Operationsfeld dargestellt. In der Regel besitzt jeder Rechner einen Speicher für Adressbindungen (Cache), in welchem die entsprechenden Adressen abgelegt sind. Sobald er ein Paket an einen anderen Rechner senden muss, untersucht der Rechner, ob sich die Protokolladresse in diesem Speicher befindet. Ist dieses der Fall, so wird das IP-Datagramm in ein Frame verpackt. Dieses wird
  • 20. Linux – Advanced 19 mit der entsprechenden Zieladresse versehen. Ist das nicht der Fall, muss eine Adressauflösung durchgeführt werden. Dazu sendet der Rechner eine beschränkte Rundspruch-Nachricht an alle anderen Rechner im eigenen Netz aus, in die er im ARP-Format seine eigene Internet- und Hardwareadresse einfügt. Das Operationsfeld ist auf Anfrage (Wert=1) gesetzt. Der angesprochene Rechner erkennt als einziger seine Internetadresse und liefert in einem Frame dem anfragenden Rechner seine Hardware- und Internetadressen (falls er mehrere besitzt) zurück. Dazu wird das Protokollfeld auf Antwort (Wert = 2) gesetzt. Außerdem verwendet er die Senderadressen, um eine eigene Bindung herzustellen, da er vermutlich, auf ein demnächst von diesem Rechner zu erwartendes Paket, eine Antwort zu senden hat. Auf diese Weise wird der ARP-Verkehr optimiert. Der Cache für die Adressbindung wird in gewissen zeitlichen Abständen (z.B. 20 Minuten) gelöscht, um Änderungen im Netz besser folgen zu können. Daher würde auch eine überflüssige Speicherung einer Bindung bald wieder korrigiert werden. Meldet sich auf eine ARP-Anfrage kein Rechner, so ist dieser entweder abgestellt oder er befindet sich in einem anderen physikalischen Netz. Dann sollte der Router dieses feststellen. Er kann dann seine eigene Hardwareadresse zurücksenden und das folgende Paket weitersenden. 1.6 Reverse Address Resolution Protocol (RARP) Um zu einer bekannten physikalischen Adresse die Internetadresse zu finden, wird das Reverse Address Resolution Protocol (RARP) verwendet. Es ist in RFC 903 standardisiert. Dieses Problem tritt auf, wenn Arbeitsrechner ohne Plattenspeicher (Diskless Workstation) eingeschaltet werden. Sie können zwar ihre Netzhardware nach ihrer physikalischen Hardwareadresse abfragen, aber ihre Internetadresse ist ihnen unbekannt. Durch Senden der physikalischen Adresse als Rundspruch-Nachricht können sie ihren Server auffordern, ihnen ihre Internetadresse mitzuteilen.
  • 21. Linux – Advanced 20 Abbildung 15: RARP Das RARP-Protokoll verwendet das gleiche Datenformat wie ARP, benutzt jedoch den Operationswert 3 für Anfragen und 4 für Antworten. In der Anfrage wird in der Regel nur die Hardwareadresse des Absenders gesetzt. Alle anderen Werte sind undefiniert (u.U. wird auch die Hardwareadresse des Empfängers gesetzt, ersatzweise ist deren Wert gleich der des Absenders.) Ein RARP-Server erkennt die Anfrage und setzt sowohl seine Bindung ein (um eine zusätzliche ARP-Anfrage zu vermeiden), als auch die Bindung des Empfängers. Das Operationsfeld wird auf den Wert 4 gesetzt. Auf diese Weise erhält der Empfänger die gewünschte Information. 1.7 Internet Control Message Protocol (ICMP) Das Internet Control Message Protocol (ICMP) benutzt wie TCP und UDP das Internet Protocol IP, ist also ein Teil der Internet-Protokoll-Familie. Es dient in Netzwerken zum Austausch von Fehler- und Informationsmeldungen. Obwohl ICMP eine Ebene über IP angeordnet ist, ist es in IP integriert. Es wird von jedem Router und PC erwartet, ICM-Protokoll zu sprechen. Die meisten ICMP-Pakete enthalten Diagnose-Informationen. Sie werden vom Router zur Quelle (source) zurückgeschickt, wenn der Router Pakete verwirft. (z.B. weil das Ziel (destination) nicht erreichbar ist, die TTL abgelaufen ist, usw.) Es gilt der Grundsatz, dass ein ICMP-Paket niemals ein anderes ICMP- Paket auslöst, d.h. die Tatsache, dass ein ICMP Paket nicht zugestellt werden konnte wird nicht durch ein Weiteres signalisiert. Eine Ausnahme zu diesem Grundsatz bildet die Echo- Funktion. Echo-ICMP-Pakete werden z.B. durch das Programm Ping verschickt. ICMP-Nachrichten werden beim Versand im Datenteil von IP-Datagrammen eingekapselt. Dabei sind im IP-Header der Servicetyp immer 0 und die Protokollnummer immer 1.
  • 22. Linux – Advanced 21 Abbildung 16: ICMP Paket Tabelle 1: ICMP Typ - Code-Kombinationen Typ Typname Code Bedeutung 0 Echo Reply 0 Echo Reply 3 Destination Unreachable 1 Host Unreachable 3 Port Unreachable 4 Fragmentation Needed, DF Set 8 Echo Request 0 Echo Request 11 Time Exceeded 0 TTL Exceeded 1 Fragment Reassembly Timeout 30 Traceroute Traceroute 33 IPv6 Where-Are-You IPv6 Where-Are-You
  • 23. Linux – Advanced 22 34 IPv6 I-Am-Here IPv6 I-Am-Here 1.8 Transmission Control Protocol (TCP) TCP (Transmission Control Protocol) hat die folgenden Merkmale. • Verbindungsorientiert Zwischen den kommunizierenden Stationen ist vor der Übermittlung von Information eine virtuelle Verbindung aufzubauen und nach der Kommunikation wieder abzubauen. • Duplex-Verbindung Beide Anwendungsprozesse können unabhängig voneinander Daten übermitteln. • Punkt-zu-Punkt TCP überträgt Daten zwischen genau zwei Teilnehmern mit symmetrischen Rechten. • Zuverlässigkeit TCP garantiert dem Benutzer eine hohe Zuverlässigkeit der Datenübermittlung bezüglich Verfälschung und Verlust von Daten. • Stromorientiert Jede Folge von Bytes, die der Sender abschickt, wird unverändert (d.h. gleiche Bytes und gleiche Reihung) dem Empfänger übermittelt. • Gepufferte Übertragung Daten werden byteweise an die Kommunikationsinstanz geliefert, welche diese in Paketen sammelt und selbsttätig übermittelt. Durch einen Push-Mechanismus kann der Sender das System zwingen, alle bisher abgesetzten Daten unverzüglich dem Empfänger abzuliefern. • Unstrukturierter Strom Die Anwendungsprozesse müssen die Struktur ihres Datenstroms selbst vereinbaren und überwachen. TCP unterstützt nicht die Segmentierung der Information in Datensätze. • Zuverlässiger Verbindungsauf- und abbau Verbindungen erhalten auch dann keine verfälschten Daten, wenn sie kurz
  • 24. Linux – Advanced 23 nacheinander mit der gleichen Portnummer aufgebaut werden.Beim Abbau werden Daten auch dann zuverlässig übertragen, wenn eine Seite die Verbindung abbaut, ehe alle Daten beim Empfänger eingetroffen sind. Jeder Empfänger kann seine Verbindung unabhängig von der Gegenstelle schließen. TCP-Header Zur Identifizierung einer Verbindung sieht TCP einen Header vor. Dieser kennzeichnet die Port-Adressen von Quell- und Zielrechner in jedem Segment. Ports müssen von den Anwenderprozessen bei jedem Aufruf der entsprechenden Betriebssystemroutinen angegeben werden. Die Werte dieser Portnummern sind teilweise festgelegt, z.B. für elektronische Post (25) oder remote job entry (5). Andere Portnummern sind jedoch frei vereinbar und können vom Betriebssystem beliebig vergeben werden. Eine Liste der Portnummer findet sich in dem RFC "Assigned Numbers" (Internet-Standard 2, zur Zeit RFC 1700). Abbildung 17: TCP-Segment Die Folgenummer gibt die Lage dieser Daten in dem Datenstrom des Senders an. Die Quittungsnummer ist die Nummer jenes Datenbytes in dem Bytestrom, welches der Absender dieses TCP-Segments als nächstes von der Gegenstelle erwartet. Das Feld Offset (4 Bits) gibt an, wie viele 32-Bit-Worte der TCP-Header enthält. Dieses ist nötig, da das Optionenfeld variable Länge haben kann. Das Fenster gibt an, wie viele Bytes der Sender dieses Pakets von der Gegenstelle noch maximal akzeptieren kann. Damit ist eine Flusskontrolle möglich. Sender und Empfänger synchronisieren sich entsprechend der vorhandenen Ressourcen.
  • 25. Linux – Advanced 24 Codes im TCP-Header Da manche Pakete nur Daten, manche nur Quittungen enthalten, gibt Code an, welche Bedeutung dieses Paket hat. Dieses Feld enthält 6 Bits, welche gesetzt oder gelöscht sein können und folgendes bedeuten. Abbildung 18: TCP-Head Der Vorrang-Zeiger zeigt auf jenes Byte innerhalb dieses Pakets, ab welchem Vorrangdaten vorhanden sind. Dieses Feld ist jedoch nur gültig, wenn das URG-Bit (urgent) gesetzt ist. Das PSH-Bit (push) wird gesetzt, wenn Daten vom Sender abgeschickt wurden, ohne dass der Sendepuffer bereits gefüllt ist. Dieses wird besonders beim interaktiven Betrieb benötigt, um beim Zeilenende bei einem Terminalbetrieb die letzten Daten zu übertragen. Das Ack-Bit (acknowledgement) und das SYN-Bit (synchronize) werden beim Verbindungsaufbau, das FIN-Bit (finish) zusätzlich beim Verbindungsabbau benötigt. Wenn eine Verbindung schnell (und nicht durch FIN) beendet werden soll, verwendet man das RST-Bit (reset). Verbindungsaufbau beim TCP-Protokoll Der Verbindungsaufbau beim TCP-Protokoll wird durch ein 3-Wege-Verfahren (three-way handshake) durchgeführt, welches nach folgendem Prinzip arbeitet.
  • 26. Linux – Advanced 25 Abbildung 19: Dreiwege-Handshake (hier Verbindungsaufbau) Nach dem Aufbau der Verbindung wissen somit beide Stationen, dass die andere empfangsbereit ist und wie die jeweiligen Bytes nummeriert werden. Um eine Verbindung zu schließen, wird ein Segment mit dem gesetzten FIN-Bit geschickt. Damit ist die jeweilige Richtung geschlossen. Es dürfen keine Daten mehr übermittelt werden. In der Gegenrichtung können jedoch noch weiter Daten gesendet werden. Erst wenn beide Stationen ein FIN-Segment geschickt haben, ist die Verbindung vollständig beendet. Bei fehlerhaften Situationen besteht die Möglichkeit, durch Setzen des RST-Bits die Verbindungen sofort abzubrechen. Portnummern TCP ist außerdem dafür verantwortlich, die empfangenen Daten an die korrekte Applikation weiterzuleiten. Zur Adressierung der Anwendungen werden auf der Transportebene deshalb so genannte Portnummern (Kanalnummern) verwendet. Portnummern sind 16 Bit groß. Theoretisch kann ein Host somit bis zu 65.535 verschiedene TCP-Verbindungen aufbauen. Auch UDP verwendet Portnummern zur Adressierung. Portnummern sind nicht einzigartig zwischen den Transportprotokollen, die Transportprotokolle haben jeweils eigene Adresseräume. Das bedeutet TCP und UDP können die gleichen Portnummern belegen. Die Portnummer 53 in TCP ist nicht identisch mit der Portnummer 53 in UDP. Der Gültigkeitsbereich einer Portnummer ist auf einen Host beschränkt.
  • 27. Linux – Advanced 26 Die Verwaltung der Portnummern ist nun auch von der Internet Assigned Numbers Authority2 (IANA) übernommen worden. Portnummern sind dabei in drei Bereiche aufgeteilt worden: well-known ports, registered ports und dynamic ports. Tabelle 2: Ports 0 - 1023 Well-known ports (von der IANA verwaltet). Der Bereich der well-known ports ist bis 1023 erweitert worden, damit sind auch die UNIX- spezifischen Dienste als Standarddienste festgelegt. 1024 - 49151 Registered ports. Registrierte Ports dienen für Dienste, die üblicherweise auf bestimmten Ports laufen. Ein Beispiel ist hier der Port 8080, der als "zweiter" bzw. alternativer Port für das http dient. 49152 - 65535 Dynamic and/or private ports. Dieser Bereich ist für die sogenannten dynamischen Ports festgelegt. Dynamische Ports dienen zur Kommunikation zwischen den beiden TCP-Schichten, die an einer Kommunikation beteiligt sind. Ein dynamischer Port wird nicht von bestimmten Standarddiensten belegt. 1.9 User Datagram Protocol (UDP) Das User Datagram Protocol (UDP) stellt dem Anwender einen Mechanismus zur verbindungslosen Kommunikation zur Verfügung. Das Konzept ist ähnlich dem des IP. Es setzt jedoch auf der Anwendungsschicht auf. UDP erlaubt es Anwendungsprozesse auf anderen Rechnern Datagramme zu senden. Der Anwendungsprozess wird durch eine Portnummer identifiziert. UDP ist in RFC 768 standardisiert. Das Feld Protocol im IP-Header identifiziert UDP mit dem Wert 1710. Die teilweise festgelegten Portnummern werden aktuell in RFC 1700 spezifiziert und sind aktueller unter der URL http://www.iana.org zu finden. UDP-Nachricht Eine UDP-Nachricht (UDP-Message) besteht aus einem Kopf und einem Datenteil. Die UDP- Nachricht wird in einem IP-Datagramm wie ein Datenpaket behandelt. 2 http://www.iana.org
  • 28. Linux – Advanced 27 Abbildung 20: UDP Datagramm Der UDP-Kopf hat den folgenden Aufbau. Abbildung 21: UDP-Kopf Der Quell- bzw. Ziel-Port identifiziert eindeutig den Anwendungsprozess, der dieses Datagramm entweder sendet oder empfängt. Dabei ist der Quell-Port optional, d.h. entweder enthält er die Adresse des Absenders, an die der Empfänger Antworten schicken soll, oder er enthält den Wert null. 1.10 Adressierung im TCP/IP Siehe Vogl, H. Der Linux Schulserver.
  • 29. Linux – Advanced 28 Tabelle 3: Netzklassen Netzklasse Adressbereich Netzmaske CIDR-Schreibweise Klasse A 0.0.0.0 bis 255.0.0.0 0.0.0.0/8 127.255.255.255 Klasse B 128.0.0.0 bis 255.255.0.0 128.0.0.0/16 191.255.255.255 Klasse C 192.0.0.0 bis 255.255.255.0 192.0.0.0/24 223.255.255.255 Tabelle 4: Private IP-Adressen Netzklasse Adressbereich CIDR- Anzahl der möglichen Schreibweise Hosts Klasse A 10.0.0.0 - 10.255.255.255 10.0.0.0/8 16777216 Klasse B 172.16.0.0 - 172.31.255.255 172.16.0.0/12 1048576 Klasse C 192.168.0.0 - 192.168.0.0/16 65536 192.168.255.255 Das Netzwerk 127.0.0.0/8 bezeichnet man als loopback-device. Es bezieht sich auf den lokalen Computer. Mit der IP-Adresse 127.0.0.1 wird der lokale Rechner adressiert. Diese Adresse dient der Kommunikation lokaler Clients mit dem lokalen Server. So wird am Rechner mit dem URL http://127.0.0.1/ immer der lokale Webserver erreicht. 1.11 Subnetze Ein Subnetz entsteht durch die Unterteilung aller möglichen IP-Adressen in Teilnetze. Die logische Unterteilung des Netzes in Subnetze entspricht meist der physikalischen
  • 30. Linux – Advanced 29 Unterteilung in lokale Teilnetze. Das Unterteilen einer Netzklasse mittels Netzmaske in weitere Subnetze nennt man Subnetting. 1.11.1 Grundlagen Die Zuordnung von IP-Adressen zu Subnetzen und die Bezeichnung des Subnetzes erfolgen durch Angabe einer IP-Adresse und einer Netzmaske. Dabei bestimmt die Netzmaske die Bits der IP-Adresse, die für alle IP-Adressen des Subnetzes gleich sind. Die restlichen Bits können variieren und bestimmen den Adressraum. Hieraus ergeben sich folgende Besonderheiten: • Die erste IP-Adresse (alle Hostbits auf 0) eines Subnetzes adressiert das Subnetz selbst (Netzwerkkennung) und kann deshalb keinem Host zugewiesen werden. • Die letzte IP-Adresse (alle Hostbits auf 1) eines Subnetzes dient als Broadcast- Adresse für das Netz und kann ebenfalls keinem Host zugewiesen werden. • Es gibt einige IP-Bereiche, die für spezielle Zwecke vorgesehen sind. Dazu gehören z.B die loopback-Adresse oder Private IP-Adressen. Ein Router arbeitet auf der Vermittlungsschicht des OSI-Modells und kann durch bitweise Und-Verknüpfung von Netzmaske und IP-Adresse ermitteln, ob letztere zum eigenen oder in anderes Subnetz gehört. Dadurch sind Router in der Lage, Subnetze zu verbinden. Mit dem Routing Information Protocol war es lediglich möglich Netze in gleich große Subnetze zu unterteilen. Da man dort für jedes Netz die gleiche Subnetzadresse mit der gleichen Anzahl an Einsern benutzt hatte, sprach man auch vom Fixed Length Subnet Masks (FLSM). OSPF und statisches Routing unterstützen inzwischen auch Subnetzmasken unterschiedlicher Länge oder Variable Length Subnet Masks (VLSM). 1.11.2 Vorgehensweise zur Aufteilung in Subnetze Die Standard-Aufteilung, nach der die Netzmasken bestimmt werden, folgt dabei einer bestimmten Rechenmethode: Gegeben sei: gewünschte Netze 40, gewünschte Hosts 720 je Netz, verfügbarer Hostbereich 181.45.x.x Schritt 1: Kontrolle ob Adressressourcen ausreichen
  • 31. Linux – Advanced 30 Dazu ist eine n-te Potenz von 2 (zwei hoch n) zu finden, die um 2 größer als die Anzahl der gewünschten Netze oder Hosts ist: Es stehen also zwei Oktette bzw. 16 Bit zur Verfügung. Adressresourcen = 2n = (Anzahl + 2) n Erklärung: 1 Bit hat zwei mögliche Werte. Für n Bit gibt es also 2n mögliche Bitkombinationen. Es können also 2n Netze/Hosts abgebildet werden, wobei von den darstellbaren Adressen zwei wegfallen (Netzadresse und Broadcast, siehe oben). Die ersten zehn Zweierpotenzen sind: 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024. Da also 25 = 32 < 40 < 64 = 26, müssen n = 6 Bit für die Netze reserviert werden. Analog für die Anzahl der Hosts gilt: 29 = 512 < 720 < 1024 = 210, d.h. 10 Bit werden für die Hosts benötigt. Alternativ lässt sich n auch durch den Logarithmus zur Basis 2 (Logarithmus dualis) ermitteln: Netze: 2log(40)=5,32 Aufrunden auf 6 Hosts: 2log(720)=9,49 Aufrunden auf 10 Das Ergebnis der Überprüfung lautet, dass die Summe der benötigten Bits 16 beträgt. Da auch 16 Bit verfügbar sind, kann mit dem gegebenen Adressenbereich 181.45.x.x die Anforderung also erfüllt werden. Schritt 2: Ermitteln der Netzmaske Wie bereits berechnet, müssen für den Hostanteil 10 Bit verwendet werden. Host-Bit sind immer die letzten in einer IP-Adresse: Gemischte Dezimal-Binär-Darstellung: 181.45.NNNNNNHH.HHHHHHHH (N für Netzwerkbits, H für Hostbits) Die Netzmaske soll 32 Bit umfassen, wobei sämtliche Netzwerkbit durch 1 und sämtliche Host-Bits (im Beispiel 10) durch 0 dargestellt werden: Es ergibt sich folgende Binärdarstellung: 11111111.11111111.11111100.00000000 Jedes Oktett dieser Netzmaske wird nun vom Dualsystem ins Dezimalsystem umgerechnet: 00000000 (Dual) = 0 (Dezimal)
  • 32. Linux – Advanced 31 11111100 (Dual) = 252 (Dezimal) 11111111 (Dual) = 255 (Dezimal) Die Netzmaske lautet dementsprechend: 255.255.252.0. Schritt 3: IP-Adressen der Netze finden Zur Festlegung der IP-Adressen muss wieder gerechnet werden: Erstes Netz • Netzadresse des ersten Netzes: 181.45.NNNNN1HH.HHHHHHHH =10110101.00101101.00000100.00000000 =181.45.4.0 • Erster Host im ersten Netz: 181.45.NNNNN1HH.HHHHHHH1 =10110101.00101101.00000100.00000001 =181.45.4.1. Der letzte Host im ersten Netz orientiert sich an der maximalen Anzahl von Einsern, die für Hosts zur Verfügung stehen. Das letzte Bit kann dann nicht 1 sein, da es sich sonst um den Netzbroadcast handeln würde: 181.45.(NNNNN1)11.11111110 = 10110101.00101101.00000111.11111110 = 181.45.7.254 Demnach ist 181.45.7.255 der Broadcast für das 1. Netz. Letztes Netz Das letzte Netz ist auch anhand der möglichen Bits festgelegt: • 181.45.(111110)00.00000000 Netzadresse für das letzte Netz. (181.45.248.0) • 181.45.(111110)11.11111110 letzter Host im letzten Netz. (181.45.251.254) Vereinfachung Bei kleineren Subnetzen lassen sich die Adressen der einzelnen Subnetze folgendermaßen berechnen: Zuerst ermittelt man die Anzahl der möglichen Adressen pro Subnetz. Diese erhält man, indem man die Anzahl der Adressen des aufzuteilenden Netzes durch die Anzahl der Subnetze teilt. Nun beginnt jedes Subnetz mit einem Vielfachen der Anzahl der Adressen pro Subnetz.
  • 33. Linux – Advanced 32 Beispiel: Das Netz 192.168.44.X soll in 8 Teilnetze aufgeteilt werden. Ein Oktett kann 256 verschiedene Werte annehmen. Jedes Subnetz hat 30 verwendbare Adressen (256:8=32-2 (Netzadresse und Broadcastadresse)) Folgende Netze entstehen: • 192.168.44.0 • 192.168.44.32 • 192.168.44.64 • 192.168.44.96 • 192.168.44.128 • 192.168.44.160 • 192.168.44.192 • 192.168.44.224 Sollte ein Netz in mehrere, unterschiedlich große, Subnetze aufgeteilt werden, so wird mit der größten Adressanzahl begonnen. Host-Range Der Host-Range bezeichnet den Teil in einem Subnetz der tatsächlich für IP-Adressen verwendet werden kann. In jedem Subnetz ist die erste und die letzte Adresse reserviert. Bei einem Subnetz mit der Adresse 200.10.57.8 lautet der Host-Range: 200.10.57.9 - 200.10.57.14 Die reservierten Adressen lauten in diesem Fall 200.10.57.8 und 200.10.57.15 Das nächste Subnetz mit der Adresse 200.10.57.16 hätte einen Hostrange von 200.10.57.17 bis 200.10.57.22 Vereinfachung von Subnetting Beispiel: Ein Klasse B-Netz mit der Nummer 172.16.0.0 und der Subnetzmaske 255.255.0.0
  • 34. Linux – Advanced 33 Ziel: In einem B-Netz können ca. 65.000 Hosts adressiert werden. Da mehrere Teilnetze benötigt werden, wird diese Anzahl unterteilen. Im Beispiel sollen 20 Teilnetze gebildet werden. Lösung: (Erspart binäres Rechnen!) Schritt 1: Wir suchen die 2er Potenz, die größer 20 ist : 2^5 = 32 Schritt 2: Wir teilen die Anzahl der Bitkombinationen durch das Ergebnis aus dem 1.Schritt: 256 : 32 = 8 Schritt 3: Wir bilden die Subnetzmaske: 256 - 8 = 248 Die neue Subnetzmaske lautet: 255.255.248.0 Schritt 4: Wir bilden den Adressbereich eines gesuchten Teilnetzes. Beispiel: Wir suchen das 5. Teilnetz: 5 x 8 = 40 6 x 8 = 48 - 1 = 47 Der Adressbereich lautet: 172.16.40.1 bis 172.16.47.254 mit der Subnetzmaske 255.255.248.0 Beispiel: Wir suchen das 7. Teilnetz: 7 x 8 = 56 8 x 8 = 64 - 1 = 63 Der Adressbereich lautet: 172.16.56.1 bis 172.16.63.254 mit ebenfalls der Subnetzmaske 255.255.248.0 Für diese Berechnungen gibt es natürlich auch Programme, wie den IP Calculator3. 1.12 Classless Inter Domain Routing (CIDR) Classless Inter-Domain Routing (CIDR) beschreibt ein Verfahren zur effektiveren Nutzung des bestehenden 32-Bit-IP-Adress-Raumes. Es wurde 1993 eingeführt, um die Größe von Routing-Tabellen zu reduzieren und um die verfügbaren Adressbereiche besser auszunutzen. 3 http://jodies.de/ipcalc
  • 35. Linux – Advanced 34 Mit CIDR entfällt die feste Zuordnung einer IP-Adresse zu einer Netzklasse und die eventuelle Unterteilung (Subnetting) in weitere Netze oder die Zusammenfassung (Supernetting) mehrerer Netze einer Klasse. Es existiert nur noch eine Netzmaske, welche die IP-Adresse in den Netzwerk- und Hostteil aufteilt. Bei CIDR führte man als neue Notation so genannte Suffixe ein. Das Suffix gibt die Anzahl der 1-Bits in der Netzmaske an. Diese Schreibform ist viel kürzer als die dotted decimal notation und auch eindeutig. Beispiel: 192.168.0.0/24 entspricht im alten klassenbasierten Verfahren der Adresse 192.168.0.0 mit der Netzmaske 255.255.255.0. In binärer Schreibweise ergibt sich bei der Netzmaske 11111111.11111111.11111111.00000000, womit die Anzahl der einer Bit 3*8 = 24 beträgt. CIDR bietet außerdem Route aggregation. Dabei können verschiedene Netze unter einer einzigen Adresse angesprochen werden. 1.13 Dynamic Host Configuration Protocol (DHCP) Das Dynamic Host Configuration Protocol (DHCP) weist auf Anfrage einem Rechner dynamisch eine Adresse zu. Es erledigt also eine ähnlich Aufgabe wie das RARP, wobei allerdings die IP-Adressen nicht notwendigerweise unverändert dem jeweiligen Host zugewiesen werden. Es baut auf dem BOOTP-Protokoll auf, welches für das Starten von Computern über das Netz benutzt wird. Abbildung 22: DHCP Startet ein Rechner in einem neuen oder seinem bisherigen Netz, so sendet er eine entsprechende Anfrage ab. Der zuständige DHCP-Server antwortet und sendet diesem
  • 36. Linux – Advanced 35 Rechner verschiedene Daten. Die aktuelle IP-Adresse, aber auch die Adresse des Routers und des Nameservers. Im Unterschied zu ARP wird die IP-Adresse nur optional fest einem Rechner zugewiesen. In der Regel werden Server, Drucker und ähnliche Geräte in einem lokalen Netz jeweils die gleiche IP-Adresse erhalten. Clients erhalten evtl. auch jeweils ihre letzte Adresse, u.U. aber auch eine neue. Jede dynamische Adresse verfällt nach einer gewissen Zeit und kann dann wieder einem neuen Rechner zugewiesen werden. Auf diese Weise lassen sich beispielsweise einige wenige Adressen einer großen Anzahl an Teilnehmern zuordnen, die nicht ständig auf das Netz zugreifen. So vergeben Internet-Provider IP-Adressen nur dynamisch, da sie in der Regel sehr viel mehr Kunden haben als ihnen IP-Adressen zustehen. 1.14 Domain Name Service (DNS) Das Domain Name System (DNS) löst die Namen im Internet auf. Das DNS ist eine verteilte Datenbank. Hauptsächlich wird das DNS zur Umsetzung von Namen in Adressen (forward lookup) benutzt. Dies ist vergleichbar mit einem Telefonbuch, das die Namen der Teilnehmer in ihre Telefonnummer auflöst. Das DNS bietet somit eine Vereinfachung, weil Menschen sich Namen weitaus besser merken können als Zahlenkolonnen. So kann man sich den Domainnamen www.bpa-graz.at sehr einfach merken, die dazugehörende IP-Adresse 207.142.131.236 dagegen nicht ganz so einfach. Mit dem DNS ist auch eine umgekehrte Auflösung von IP-Adressen in Namen (reverse lookup) möglich. Darüber hinaus ermöglicht das DNS eine Entkoppelung vom darunter liegenden Aufbau. (Änderung der IP-Adresse, ohne den Domainnamen ändern zu müssen). Das DNS löste die hosts-Dateien ab, die bis dahin für die Namensauflösung zuständig waren. Es zeichnet sich aus durch: • dezentrale Verwaltung • hierarchische Strukturierung des Namensraums in Baumform • Eindeutigkeit der Namen • Erweiterbarkeit
  • 37. Linux – Advanced 36 Komponenten des DNS Das DNS besteht aus drei Hauptkomponenten: • Domänennamensraum • Nameservern • Resolver Domänennamensraum Der Domänennamensraum hat eine baumförmige Struktur. Die Blätter und Knoten des Baumes werden als Labels bezeichnet. Ein kompletter Domänenname eines Objektes besteht aus der Verkettung aller Labels. Label sind Zeichenketten (alphanumerisch, früher war als einziges Sonderzeichen '-' erlaubt, im Jahre 2004 kamen auch noch Umlaute wie: ä, ö, ü, é, à, è, usw. dazu), die mindestens ein Zeichen und maximal 63 Zeichen lang sind. Die einzelnen Label werden durch Punkte voneinander getrennt. Ein Domänenname wird mit einem Punkt abgeschlossen (der hinterste Punkt wird normalerweise weggelassen, gehört rein formal aber zu einem vollständigen Domänennamen dazu). Ein korrekter, vollständiger Domänenname (auch FQDN) lautet z.B. www.bpa-graz.at. (der letzte Punkt gehört zum Domänennamen). Nameserver Nameserver sind Programme, die Anfragen zum Domänennamensraum beantworten. Man unterscheidet zwischen autoritativen und nicht autoritativen Nameservern. Ein autoritativer Nameserver ist verantwortlich für eine Zone. Seine Informationen über diese Zone werden deshalb als gesichert angesehen. Für jede Zone existiert mindestens ein autoritativer Server, der Primary Nameserver. Dieser wird im SOA Resource Record einer Zonendatei aufgeführt. Aus Redundanz- und Lastverteilungsgründen werden autoritative Nameserver fast immer als Server-Cluster realisiert, wobei die Zonendaten identisch auf einem oder mehreren Secondary Nameservern liegen. Die Synchronisation zwischen Primary und Secondary Nameservern erfolgt per Zonentransfer. Ein nicht autoritativer Nameserver bezieht seine Informationen über eine Zone von anderen Nameservern. Seine Informationen werden als nicht gesichert angesehen. Da sich DNS- Daten normalerweise nur sehr selten ändern, speichern nicht autoritative Nameserver die einmal von einem Resolver angefragten Informationen im lokalen RAM ab. Diese liegen bei einer erneuten Anfrage schneller vor. Diese Technik wird als Caching bezeichnet. Jeder
  • 38. Linux – Advanced 37 dieser Einträge besitzt ein eigenes Verfallsdatum (TTL time to live). Nach dem Ablauf wird der Eintrag aus dem Cache gelöscht. Die TTL wird dabei durch einen autoritativen Nameserver für diesen Eintrag festgelegt und wird nach der Änderungswahrscheinlichkeit des Eintrages bestimmt (sich häufig ändernde DNS-Daten erhalten eine niedrige TTL). Das kann u. U. aber auch bedeuten, dass der Nameserver in dieser Zeit falsche Informationen liefern kann, wenn sich die Daten zwischenzeitlich geändert haben. Ein Spezialfall ist der caching only Nameserver. In diesem Fall ist der Nameserver für keine Zone verantwortlich und muss alle eintreffenden Anfragen über weitere Nameserver auflösen. Ein Domänenname darf inklusive aller Punkte maximal 255 Zeichen lang sein. Ein Domänenname wird immer von rechts nach links delegiert und aufgelöst, d. h. je weiter rechts ein Label steht, umso höher steht es im Baum. Der Punkt ganz rechts wird auch als root (Wurzel) im Namensraum bezeichnet. Das erste Label (das links vom Punkt für 'root' steht) wird im Allgemeinen auch als Top Level Domain (TLD) bezeichnet. Die DNS-Objekte einer Domäne (zum Beispiel die Rechnernamen) werden als Satz von Resource Records meist in einer Zonendatei gehalten, die auf einem oder mehreren autoritativen Nameservern vorhanden sind. Statt Zonendatei wird meist der etwas allgemeiner Ausdruck Zone verwendet. Resolver Resolver sind Ansammlungen von Bibliotheken, die Informationen aus den Nameservern abrufen können. Sie bilden die Schnittstelle zwischen Anwendung und Nameserver. Der Resolver übernimmt die Anfrage einer Anwendung, ergänzt sie falls notwendig zu einem FQDN und übermittelt sie an den fest konfigurierten Nameserver. Ein Resolver arbeitet entweder iterativ oder rekursiv und informiert den Nameserver über die verwendete Arbeitsweise. Übliche Resolver von Clients arbeiten ausschließlich rekursiv, sie werden dann auch als Stub-Resolver bezeichnet. Bei einer rekursiven Anfrage schickt der Resolver eine Anfrage an einen ihm bekannten Nameserver und erwartet von ihm eine eindeutige Antwort. Diese Antwort enthält entweder den gewünschten Resource Record oder "gibt es nicht". Rekursiv arbeitende Resolver überlassen also die Arbeit zur vollständigen Auflösung anderen.
  • 39. Linux – Advanced 38 Bei einer iterativen Anfrage bekommt der Resolver entweder den gewünschten Resource Record oder die Adresse eines weiteren Nameserver, den er als Nächsten fragt. Der Resolver fragt so von Nameserver zu Nameserver, bis er bei einem autoritativen Nameserver landet. Die so gewonnene Antwort übergibt der Resolver an das Programm, das die Daten angefordert hat, beispielsweise an den Webbrowser. Bekannte Programme zur Überprüfung der Namensauflösung sind nslookup, host und dig. Weitere Informationen zur iterativen/rekursiven Namensauflösung finden sich unter rekursive und iterative Namensauflösung. DynDNS Es kann nur Rechnern mit fester, sich also nie ändernden IP-Adresse ein fester Rechnername zugeordnet werden. Da jedoch sehr viele Nutzer mit Heimrechnern eine variable IP-Adresse haben (mit jeder Einwahl in das Internet wird eine andere IP-Adresse aus einem Pool zugeteilt), gibt es inzwischen DynDNS-Betreiber (z.B. DynDNS.org), die dafür sorgen, dass man auch mit solch rasch ändernden Adressen möglichst immer über denselben Rechnernamen erreichbar ist. Domain-Registrierung Um DNS-Namen im Internet bekanntmachen zu können, muss der Besitzer die Domain, die diese Namen enthält, registrieren. Durch eine Registrierung wird sichergestellt, dass bestimmte formale Regeln eingehalten werden und dass Domain-Namen weltweit eindeutig sind. Domain-Registrierungen werden von Organisationen (Registrars) vorgenommen, die dazu von der IANA bzw. ICANN autorisiert wurden. In Österreich ist nic.at dafür verantwortlich. Registrierungen sind gebührenpflichtig. 1.15 Übungsbeispiele 1. Wofür steht die Abkürzung OSI? 2. Benennen Sie die Schichten des OSI-Models. 3. Welche Ziele wurden bei der Entwicklung von TCP/IP definiert? 4. Benennen Sie die Schichten des TCP/IP-Modells? 5. Nenne Sie drei Protokolle der Applikationsschicht.
  • 40. Linux – Advanced 39 6. Nennen Sie die zwei Protokolle der Transportschicht. 7. Vergleichen Sie das OSI- mit dem TCP/IP-Modell? 8. Was bedeutet Encapsulation? 9. Wie bezeichnet man die Daten auf den verschiedenen Schichten des TCP/IP- Modells? 10. Aus welchen Bereichen besteht ein Datagramm? 11. Was bedeutet fragmentieren? 12. Was bedeutet reassemblieren? 13. Wie ist der IP-Header aufgebaut? 14. Wofür wird das Address Resolution Protocol verwendet? 15. Was bedeutet RARP? 16. Wofür wird ICMP verwendet? 17. Welche Merkmale hat das Transmission Control Protocol? 18. Wie ist der TCP-Header aufgebaut? 19. Wie funktioniert der Verbindungsaufbau beim TCP-Protokoll? 20. Was sind Ports? 21. Welche Organisation verwaltet die Portnummern? 22. Wie heißen die drei Bereiche in denen Portnummern aufgeteilt werden? 23. Worin unterscheidet sich UDP von TCP? 24. Mit welchen Protokollen können Rechnern IP-Adressen zugeordnet werden? 25. Ordnen Sie die folgenden IP-Adressen den einzelnen Standard-Netzwerkklassen zu: 192.168.1.44, 190.34.45, 77.55.123.234 26. Wie lautet der Netzwerkteil der Adresse 192.168.1.44, wenn es sich um ein Klasse-C- Netz handelt.
  • 41. Linux – Advanced 40 27. Wozu werden Subnetzmasken eingesetzt? 28. Wandel Sie die IP-Adresse 193.171.90.34 in das Binärformat um. 29. Ermitteln Sie den Netzwerkteil der folgende IP-Adresse (http://jodies.de/ipcalc): 10101100 00010100 01100111 11011001 = 172.20.103.217 der dir folgende Subnetmaske zugeordnet wurde: 11111111 11111111 11111000 00000000 = 255.255.248.0 30. Wofür benötigt man eine Broadcast-Adresse? 31. Kann die IP-Adresse 192.168.4.255 mit der Subnetmaske 255.255.255.0 an ein Endgerät vergeben werden? 32. Wie lautet die Loopback-Adresse eines lokalen Systems? 33. Geben Sie die IP-Adresse 192.168.1.55 mit der Netzmaske 255.255.255.0 in einer anderen Schreibweise an. 34. Was ist ein Subnet? 35. Gegeben ist folgende IP-Adresse und Subnetmaske: 172.192.0.0, 255.255.255.0 Es sollen Subnetz mit jeweils 40 Hostadressen berechnet werden. 36. Wie lange darf ein Domänenname sein? 37. Was ist ein Resolver? 38. Wo kann man in Österreich eine Domain registrieren? 39. Wer ist der Domaininhaber der Domain bpa-graz.at?
  • 42. Linux – Advanced 41 2 Einrichten der Schulungsumgebung Für die Schulungsumgebung wird die Linux-Distribution SUSE Linux 10.0 OSS Beta 24 verwendet. Als Testumgebung kann VMware5 , MS Virtual PC6 oder OEMU7 verwendet werden. Als Installationsmedium wird ein boot.iso Image verwendet. Dieses Image kann von einem Mirror geladen werden (z.B. http://suse.inode.at/opensuse/distribution/SL-10.0-OSS- beta2/inst-source/boot/boot.iso). Sowohl in VMware als auch unter Virtual PC muss eine Virtuelle Hardware konfiguriert werden. 2.1 VMware VMware ist eine Softwarefirma, die sich auf Emulation und Virtualisierung spezialisiert hat und deren bekanntestes Produkt VMware Workstation ist. Mit VMware Workstation kann unter Linux sowie Microsoft Windows ein kompletter PC virtualisiert werden. In dem virtualisierten PC können unterschiedliche Betriebssysteme installiert werden. Es bestehen aber Restriktionen hinsichtlich der technischen Fähigkeiten des zugrunde liegenden Betriebssystems. Eine mit Windows 2000 eingerichtete virtuelle Maschine, die auf einem Rechner mit dem älteren Windows NT 4 läuft, kann beispielsweise dennoch keinen USB-Zugriff durchführen. Für den Betrieb von Servern gibt es die Produkte VMware GSX, sowie das Flaggschiff ESX- Server. Letzterer basiert auf einem Vmware eigenen Kernel und benötigt daher kein Wirtsbetriebssystem. Mittlerweile lassen sich mit VirtualCenter komplette virtuelle Infrastrukturen darstellen. Das bedeutet, dass man z.B. in einem Netzwerk 40 Server sieht, es tatsächlich aber nur 2 physikalische Server gibt. Der Rest sind virtuelle Server. VMware bietet mittels der Software VMotion die Möglichkeit, einen virtuellen Server von einem physikalischen Host zum nächsten zu transferieren, ohne dass der virtuelle Server herunter gefahren werden muss. Das hat den Vorteil, dass wenn an der physikalischen Maschine z.B. Hardware getauscht oder erweitert werden muss, die User weiterarbeiten können. Für sie ist "ihr" Server nicht down. 4 http://www.opensuse.org/ 5 http://www.vmware.com/ 6 http://www.microsoft.com/windows/virtualpc/ 7 http://fabrice.bellard.free.fr/qemu/
  • 43. Linux – Advanced 42 Es lassen sich auch mehrere Maschinen mit verschiedenen Betriebssystemen gleichzeitig virtualisieren. Die virtualisierten Betriebssysteme sind in Abhängigkeit vom Speicherausbau etwas langsamer als vergleichbare Installationen auf identischer Hardware. Im Bereich der Softwareentwicklung erleichtern virtuelle Maschinen den Entwicklungsprozess, da verschiedene Instanzen gleichzeitig parallel laufen können. Damit können verschiedene Releasestände bequem getestet werden. Durch Snapshots können Wiederanlaufpunkte gesichert werden, zu denen wieder zurückgekehrt werden kann. Die Installationen werden als Imagedateien abgelegt und können damit über eine Netzwerkanbindung verschiedenen Entwicklern mit gleichem Stand zur Verfügung gestellt werden. Nach dem Start von Vmware, beginnt mit File, New Virtual Machine die Konfiguration. Abbildung 23: VMware Konfiguration für Opensuse10beta2 Außerdem wird eine zweite Netzwerkkarte benötigt. Diese wird Host-only konfiguriert.
  • 44. Linux – Advanced 43 Abbildung 24: NIC2 Host-only Das boot.iso Image wird direkt in das virtuelle CD-Rom Laufwerk eingebunden. Abbildung 25: VMware boot.iso einbinden Nach dem Start bootet die Virtuelle-Maschine direkt vom boot.iso Image.
  • 45. Linux – Advanced 44 Abbildung 26: Vmware 2.2 Virtual PC Virtual PC ist eine Virtualisierungssoftware von Microsoft und wird für Windows, wie auch für Mac OS angeboten. Es ist Bestandteil des Produktes Microsoft Office Professional für Mac OS. Mit Virtual PC wird ein kompletter PC virtualisiert, das heißt, mit Hilfe einer so genannten virtuellen Maschine wird ein PC emuliert. So wie die Java-VM dem Applet eine Rechenumgebung vorgaukelt, erzeugen Programme wie Virtual PC einen kompletten virtuellen Rechner. Dadurch wird es möglich, mehrere Betriebssysteme gleichzeitig auf nur einem PC zu betreiben. Virtual PC simuliert jedoch nicht den PC auf dem es ausgeführt wird, sondern einen Standard-PC mit bis zu drei Festplatten, einem CD- oder DVD-Laufwerk, einem Arbeitspeicher einstellbarer Größe (abhängig von der Arbeitsspeicherkapazität im echten PC), einer 100-MBit-Netzwerkkarte, einer Audio-Karte und einer 8-MB-Grafikkarte. Eine Unterstützung für lokale USB- oder PCI-Geräte fehlt. Die Festplatten werden als so genannte Image-Dateien auf der lokalen Festplatte angelegt. Nach dem Start von Virtual PC erscheint die Virtual PC Konsole. Mit Neu… startet die Konfiguration eines neuen Virtuellen PCs.
  • 46. Linux – Advanced 45 Abbildung 27: Virtual PC-Konsole Nach der Begrüßung durch den Assistenten wird ein Virtueller Computer erstellt. Abbildung 28: Virtuellen Computer erstellen Für das Konfigurationsfile und die virtuelle Hard Disk empfiehlt es sich einen eigenen Ordner pro PC einzurichten.
  • 47. Linux – Advanced 46 Abbildung 29: Ordner des virtuellen Computers Abbildung 30: Name und Pfad des virtuellen Computers Virtul PC erkennt, dass es sich nicht um ein Windows Betriebsystem handelt. Als Vorschlag wird Anderes übernommen.
  • 48. Linux – Advanced 47 Abbildung 31: Virtual PC Betriebsystem Vorgeschlagener werden 128 MB Arbeitsspeicher. Für effektiveres Arbeiten sollte dieser Wert erhöht werden. Abbildung 32: Speicher Die virtuelle Festplatte wird mit 4 GB erstellt. Der Speicherort entspricht dem Speicherort des Konfigurationsfiles.
  • 49. Linux – Advanced 48 Abbildung 33: Neue virtuelle Festplatte Abbildung 34: Speicherort der virtuellen Festplatte
  • 50. Linux – Advanced 49 Abbildung 35: Abschluss der Konfiguration Nach der Konfiguration wird in der Virtual PC Konsole über Einstellungen der Adapter 2 auf lokal gesetzt. Abbildung 36: Netzwerkadapter 2
  • 51. Linux – Advanced 50 Abbildung 37: Start Virtual PC Nach dem Start des virtuellen Computers, muss im Menü CD das boot.iso Image erfasst werden. Abbildung 38: boot.iso wählen 2.3 QEMU QEMU8 ist ein CPU-Emulator bzw. eine virtuelle Maschine für die Betriebssysteme Linux, Windows, FreeBSD, NetBSD, OpenBSD und Mac OS X. 8 http://free.oszoo.org/
  • 52. Linux – Advanced 51 Er emuliert bereits x86, x86-64 bzw. AMD64, PowerPC und Sparc32/64 Hardware. Alpha, ARM und S390 werden noch getestet. Geplant sind eine Unterstützung für IA-64, m68k und MIPS. Das PC-BIOS stammt von Bochs9 und das VGA-BIOS von Plex86/Bochs. Diverse Betriebssysteme wie z.B. AROS, DOS incl. dessen grafische Bedienoberflächen PC/GEOS, OpenGEM und SealOS (VM86 Mode wird unterstützt, um DOSEMU ausführen zu können), FreeBSD, NetBSD, OpenBSD, Linux, MenuetOS, OS/2, QNX, ReactOS, Syllable, Unununium und Windows laufen unter QEMU. Emuliert wird neben der CPU auch: • PCI und ISA-System (i440FX host PCI bridge und PIIX3 PCI to ISA bridge) • Grafikkarte (Cirrus CLGD 5446 PCI VGA card oder Standard-VGA-Grafikkarte mit Bochs VESA Extensions (Hardware Level, inclusive aller nicht Standard Modi) • PS/2 Maus und Tastatur • zwei PCI ATA-Schnittstellen mit Unterstützung für maximal vier Festplatten-Images im eigenen Format oder im Format von VMWare, VirtualPC, Bochs, Knoppix (cloop) und dd • CD-ROM/DVD-Laufwerk über ISO-Abbild oder reales Laufwerk • Diskettenlaufwerk • Netzwerkkarte (NE2000 PCI Netzwerk Adapter) und ein DHCP-Server • Serieller Port • Paralleler Port • Soundkarte (Soundblaster 16) Das Starten von Live-CD- und Boot-Disketten-Images ist problemlos möglich. 9 http://bochs.sourceforge.net/
  • 53. Linux – Advanced 52 Abbildung 39: QEMU Manager Die Installation und Konfiguration von QEMU wird im Wikibook QEMU10 beschrieben. Zur leichteren Bedienung kann das Programm QEMU Manager11 verwendet werden. 10 http://de.wikibooks.org/wiki/QEMU 11 http://www.davereyn.co.uk/qemu.htm
  • 54. Linux – Advanced 53 Abbildung 40: Opensuse 10 unter QEMU 2.4 Netzwerk – Installation Nach dem Start des virtuellen Computers wird vom boot.iso Image gebootet. Es erscheint der gewohnte Suse Installations-Bildschirm.
  • 55. Linux – Advanced 54 Abbildung 41: Netzwerk-Installation Die Sprache wird mit gewählt. Der Modus Installation wird bestätigt. Abbildung 42: Keine Installationsquelle Die Fehlermeldung, keine Installations-Quelle wird übernommen.
  • 56. Linux – Advanced 55 Abbildung 43: Linuxrc Der Installationsmanager Linuxrc startet. Die Tastaturbelegung Deutsch wird aktualisiert. Abbildung 44: Linuxrc Hauptmenü Im Hauptmenü von Linuxrc wird Installation / System starten gewählt.
  • 57. Linux – Advanced 56 Abbildung 45: Linuxrc - Installation Abbildung 46: Linuxrc Quellmedium Als Quellmedium wird Netzwerk ausgewählt.
  • 58. Linux – Advanced 57 Abbildung 47: Linuxrc – Netzwerkprotokoll Es empfiehlt sich das FTP-Protokoll oder HTTP-Protokoll zu verwenden. Die Netzwerkkarte eth0 muss verwendet werden. Abbildung 48: Linuxrc - DHCP aktivieren
  • 59. Linux – Advanced 58 Ist im Netzwerk ein DHCP-Server aktiv, kann dieser verwendet werden. Ohne DHCP – Server, müssen IP-Adresse, Netzmaske und Gateway händisch vergeben werden, Abbildung 49: Linuxrc - HTTP Server Die möglichen Mirror-Server12 sind auf der OpenSuSE Homepage eingetragen. Für die Installation wird die IP-Adresse des Servers benötigt. Durch Ping auf den Hostnamen kann die Adresse ausgelesen werden. Zum Beispiel: / # ping suse.inode.at PING suse.inode.at (81.223.20.170) 56(84) bytes of data. 64 bytes from 81.223.20.170: icmp_seq=1 ttl=64 time=… Abbildung 50: Linuxrc – HTTP-Proxy Wird im Netzwerk ein Proxy-Server verwendet, muss dieser bekannt gegeben werden. 12 http://www.opensuse.org/index.php/Mirrors_Released_Version#Europe
  • 60. Linux – Advanced 59 Abbildung 51: Linuxrc – Verzeichnis Das Installationsverzeichnis wird angegeben. Dieses kann je nach Server variieren (z.B. http://suse.inode.at/: /opensuse/distribution/SL-10.0-OSS-beta3/inst-source). Das Bereitstellen der Netzwerk-Installation einer neuen SuSE-Linux Version erfolgt erst einen gewissen Zeitraum nach dem Verkaufsstart. Die weitere Installation entspricht der Grundinstallation. Folgende Einstellungen sollten bei der Installation verwendet werden. Uhr und Zeitzone Region: Europa Zeitzone: Österreich Rechneruhr eingestellt auf: lokale Zeit Bildschirm-Einstellungen KDE oder GNOME Installationseinstellungen … Software-Auswahl: simple Web Server with Apache2 … Root-Passwort rooti Benutzer Username: tester Passwort: te123er Direkt anmelden: deaktiviert Netzwerk eth0: DHCP, wenn vorhanden eth1: 192.168.0.254/255.255.255.0 Host: linux00.schule.local
  • 61. Linux – Advanced 60 DNS: 193.171.90.37, 193.171.4.60 Firewall: deaktiviert 2.5 Übungsbeispiele 40. Von welchen Netzwerkquellen kann Opensuse installiert werden? 41. Wodurch unterscheidet sich die FTP von der http Installationsquelle? 42. Nennen Sie drei Opensuse Mirror-Server. 43. Wie erhalten Sie die IP-Adresse eines Mirror-Servers?
  • 62. Linux – Advanced 61 3 Serverdienste 3.1 Network File Service (NFS) Der Network File Service - abgekürzt NFS (früher: Network File System) - ist ein von Sun Microsystems entwickeltes Protokoll, das den Zugriff auf Dateien über ein Netzwerk ermöglicht. Dabei werden die Dateien nicht (wie z.B. bei FTP) übertragen, sondern die Benutzer können auf Dateien, die sich auf einem entfernten Rechner befinden, so zugreifen, als wenn sie auf ihrer lokalen Festplatte abgespeichert wären. Bei diesem UNIX-Netzwerkprotokoll handelt es sich um einen Internet-Standard (RFC 1094, RFC 1813), der auch als verteiltes Dateisystem (engl. Distributed File System) bezeichnet wird. NFS-Dienste sind auch auf Microsoft-Windows-Servern verfügbar, wodurch UNIX- Workstations Zugang zu deren Dateien erhalten können. Die Entsprechung zu NFS heißt unter Windows- und OS/2-Umgebungen Server Message Block (SMB). Sowohl NFS als auch SMB regeln Funktionen, um Dateien zu öffnen und zu schließen. Ferner regeln sie die Zugriffskontrolle, welcher Benutzer Lese- und/oder Schreibzugriff auf eine Ressource erhält. Abbildung 52: NFS im OSI-Schichtenmodell NFS arbeitet auf dem Netzwerk-Transportprotokoll TCP/IP. NFS ist ursprünglich ein zustandsloses UDP-Protokoll. Mittlerweile gibt es aber auch NFS über TCP. Derzeit wird NFS Version 4 entwickelt, welches schneller und nicht mehr zustandslos sein soll. 3.1.1 NFS - Server Benötigte Pakete: nfsserver, nfs-utils, portmap Die Konfiguration des NFS-Servers erfolgt direkt mit YaST.
  • 63. Linux – Advanced 62 Abbildung 53: Yast - Modul NFS-Server In YaST wird die Kategorie Netzwerkdienste gewählt. Mit NFS-Server startet die Konfiguration. Abbildung 54: NFS-Server starten Der Schalter Starten muss aktiviertet werden. Ist die Firewall aktiviert, muss zusätzlich der NFS-Dienst und der Portmapper13 frei geschalten werden. 13 Ein Portmapper übernimmt in der Informationstechnik die Koordination der durch den Client gewünschten Funktionsaufrufe.
  • 64. Linux – Advanced 63 Abbildung 55: Zu exportierendes Verzeichnis wählen Das zu exportierende Verzeichnis kann mit Durchsuchen direkt aus dem Dateibaum gewählt werden. Abbildung 56: Rechner und Zugriffsoptionen für NFS Unter Rechner-Wildcard können die IP-Adressen der Clients angeführt werden. Alternativ kann * für alle Rechner verwendet werden, *.domain nur für eine bestimmte Domäne und 192.168.100.0/255.255.255.0 für ein bestimmtes Subnet. Tabelle 5: Optionen für den NFS-Export ro "read only" (schreibgeschützt) rw "read/write" (volle Lese- und Schreibrechte für den Client) noaccess Zugriffsverweigerung für Unterverzeichnisse root_squash root erhält die UserID des Pseudobenutzers nobody, eine sichere (Default-)Einstellung, da so der root-Benutzer des Client-Rechners nicht mit root-Rechten auf dem Server schreiben kann.
  • 65. Linux – Advanced 64 no_root_squash root-Account auf dem Client wird dem auf dem Server gleichgestellt. Hier ist der root-User des Client-Rechners auch root auf dem Server! all_squash Alle Zugreifenden erhalten die Nobody-UID anongid=gid Squashing der Gruppe. Die Gruppen-ID wird auf gid gesetzt. Bei dieser Option kann root entscheiden, mit welcher Server-GID die Client-User arbeiten sollen, sobald sie Zugriff auf den Server haben. anonuid=uid Squashing des Users. Die zugreifenden User bekommen die User-ID uid verpasst. 3.1.2 NFS – Client Freigegebene Verzeichnisse können direkt mit YaST in den Dateibaum eingebunden werde. Abbildung 57: Yast - Modul NFS-Client In YaST wird die Kategorie Netzwerkdienste gewählt. Mit NFS-Client startet die Konfiguration.
  • 66. Linux – Advanced 65 Abbildung 58: Konfiguration des NFS-Client Mit Hinzufügen kann ein NFS-Server gewählt werden. Abbildung 59: NFS-Verzeichnis einbinden Wurde der Server gefunden, kann ein exportiertes Verzeichnis gewählt werden. Nach der Angabe des lokalen Mountpointes können Optionen für das Einbinden gesetzt werden. Tabelle 6: Mount-Parameter für über NFS-Verzeichnisse rw, ro Schreib- und Lesezugriff bzw. Nur-Lese-Zugriff
  • 67. Linux – Advanced 66 fg Mount-Vorgang im Vordergrund ("foreground") bg Mount-Vorgang im Hintergrund ("background") retrans=zahl Anzahl der Wiederholungsversuche, um einen Mount durchzuführen. Der Default-Wert liegt bei 5. hard "Hartes" Mounten, d. h., es werden Anfragen abgesetzt, bis der Server antwortet (default). soft "Weiches" Mounten, d. h., wenn ein Zähler abgelaufen ist (retrans), gibt es eine Fehlermeldung, und der Versuch wird abgebrochen. intr, nointr Möglichkeit des Abbruchs durch eine Tastenkombination ("interrupt") bzw. das Verhindern derselben. remount Aushängen eines Verzeichnisses, um es sofort wieder (beispielsweise mit neuen Optionen) einzuhängen. suid, nosuid Möglichkeit zur Benutzung des SUID-Bits auf dem eingehängten Dateisystem. retry=zahl Anzahl der erfolglosen Mount-Versuche (Default ist 10000), bis endgültig abgebrochen wird. wsize=zahl Größe des Puffers für Schreibzugriffe (Default liegt zwischen 2048 und 32 kB, je nach Unix-System und -Version). rsize=zahl Puffergröße für Lesezugriffe (Default siehe oben). timeo=zahl Zeitspanne für Wiederholversuche, angegeben in Zehntelsekunden.
  • 68. Linux – Advanced 67 proto=protokoll ab Version 3: Angabe des Protokolls (UDP oder TCP). nfsstat Mit diesem Befehl werden NFS Statisken ausgegeben / # nfsstat Server rpc stats: calls badcalls badauth badclnt xdrcall 20860 0 0 0 0 Server nfs v3: null getattr setattr lookup access readlink 0 0% 264 1% 0 0% 1148 5% 14726 70% 32 … Tabelle 7: nfsstat Optionen -s Gibt nur serverseitige Informationen aus. Voreingestellt sind sowohl Client- als auch Serverinformationen. -c Gibt nur clientseitige Informationen aus. Voreingestellt sind sowohl Client- als auch Serverinformationen. -n Gibt nur NFS-Statistiken aus. Voreingestellt sind NFS und RPC Statistiken. -r Gibt nur RPC-Statistiken aus. Tabelle 8: NFS Konfigurations-Datein /etc/export Im File /etc/exports sind alle zu exportierenden Verzeichnisse aufgeführt. Dazu kommen Angaben, wer (welche Clients) wie (mit welchen Rechten) auf die Freigaben zugreifen dürfen. /etc/hosts.allow Die Datei hosts.allow dient der Zugangskontrolle von
  • 69. Linux – Advanced 68 Nutzern/Diensten anderer Rechner. Für bestimmte Hosts/Netzwerke kann hier der Zugriff auf bestimmte lokale Dienste explizit gestattet werden. /etc/hosts.deny In hosts.deny kann der Zugang zu bestimmten Diensten des Rechners für bestimmte Hosts/Netzwerke explizit untersagt werden. /etc/fstab In der Datei /etc/fstab des lokalen NFS-Client-Rechners stehen alle Dateisysteme, Schnittstellen und Devices, die irgendwann einmal gemountet werden bzw. werden können. 3.2 DHCP – Server Das DHCP (Dynamic Host Configuration Protocol) ermöglicht mit Hilfe eines entsprechenden Servers die dynamische Zuweisung einer IP-Adresse und weiterer Konfigurationsparameter an Computer in einem Netzwerk (vgl. 1.13 Dynamic Host Configuration Protocol). Benötigte Pakete: dhcpcd, dhcp-server Dynamisches DHCP Die Konfiguration des dynamischen DHCP erfolgt direkt mit YaST. Abbildung 60: Yast - Modul DHCP-Server In YaST wird die Kategorie Netzwerkdienste gewählt. Mit DCHP-Server startet die Konfiguration.
  • 70. Linux – Advanced 69 Abbildung 61: DHCP auf Netzwerkkarte eht1 binden Der DHCP Server wird auf die Netzwerkkarte eth1 gebunden. Händisch müsste eine Route mit der Adresse 255.255.255.255 der Netzwerkkarte zugeordnet werden. / # route add 255.255.255.255 eth0 Abbildung 62: DHCP Konfiguration Die globalen Einstellungen werden in Schritt 2 gesetzt. Im Schritt 3 wird der dynamische Adressbereich vergeben.
  • 71. Linux – Advanced 70 Abbildung 63: Dynamisches DHCP Das Ergebnis der Konfiguration kann in der Datei /etc/dhcpd.conf betrachtet werden. Abbildung 64: /etc/dhcpd.conf Statisches DHCP Beim Einrichten von statischen DHCP, muss die Datei /etc/dhcpd.conf editiert werden. # DHCP-Server statisch #/etc/dhcpd.conf
  • 72. Linux – Advanced 71 # # -> Kommentarzeile # Folgende Options gelten für alle Rechner option domain-name "schule.local"; option domain-name-servers 193.171.90.37; option subnet-mask 255.255.255.0; option broadcast-address 192.168.0.255; option routers 192.168.0.254; #Verfallsdauer default-lease-time 86400; max-lease-time 2592000; subnet 192.168.0.0 netmask 255.255.255.0 { # Alle Clients bekommen IP-Adresse nach ihrer MAC-Adresse host client10 { hardware ethernet 00:10:5f:58:43:9b; fixed-address 192.168.0.10; } host client11 { hardware ethernet 00:10:5f:47:3b:05; fixed-address 192.168.0.11; } } Gemischtes DHCP Der Normalfall wird das gemischte DHCP sein. Die ganze Konfigurationsdatei /etc/dhcpd.conf sieht dann so aus: # DHCP-Server Konfiguration gemischtes DHCP #/etc/dhcpd.conf # # -> Kommentarzeile # Folgende Options gelten für alle Rechner option domain-name "schule.local"; option domain-name-servers 193.171.90.37 193.171.4.60; option subnet-mask 255.255.255.0; option broadcast-address 192.168.0.255; option routers 192.168.0.254; #Verfallsdauer default-lease-time 86400; max-lease-time 2592000; subnet 192.168.0.0 netmask 255.255.255.0 { # Alle Clients bekommen IP-Adresse nach ihrer MAC-Adresse host client10
  • 73. Linux – Advanced 72 { hardware ethernet 00:10:5f:58:43:9b; fixed-address 192.168.0.10; } host client11 { hardware ethernet 00:10:5f:47:3b:05; fixed-address 192.168.0.11; } } #Die Adressen 192.168.0.100 bis 192.168.0.200 werden→ dynamisch vergeben range 192.168.0.100 192.168.0.200; } Tabelle 9: DHCP Konfigurations-Datein /etc/dhcpd.conf Das File /etc/dhcpd.conf ist das zentrale Konfigurations-File für den DHCP-Server. 3.3 DNS – Server Das Domain Name System (DNS) ist einer der wichtigsten Dienste im Internet. Das DNS ist eine verteilte Datenbank, die den Namensraum im Internet verwaltet (vgl. 1.14 Domain Name Service). Ein weit verbreiteter Nameserver unter Linux ist bind. Benötigte Pakete: bind Der erste Schritt ist das Ändern der Konfiguration der Netzwerkkarten. Als Nameserver wird die IP des Rechners selber als Nameserver 1 eingetragen.
  • 74. Linux – Advanced 73 Abbildung 65: Netzwerkkarte für DNS vorbereiten Die forward Zone kann direkt mit Yast eingerichtet werden. In YaST wird die Kategorie Netzwerkdienste gewählt. Mit DNS-Server startet die Konfiguration. Abbildung 66: DNS-Server Im ersten Schritt wird der Start des Nameservers festgelegt. Um eine funktionierende Namensauflösungen zu gewährleisten, muss der Dienst beim Systemstart aktiviert werden.
  • 75. Linux – Advanced 74 Abbildung 67: DNS-Server starten Als Forwarders werden weitere DNS-Server bezeichnet. Kann der eigene Server die Namensauflösung nicht durchführen, wird die Anfrage an diese Server weitergeleitet. Abbildung 68: DNS-Forwarder Abbildung 69: DNS-Protokollierung
  • 76. Linux – Advanced 75 3.3.1 Forward Zone Nach der Einstellung der Protokollierung wird die erste DNS-Zone erstellt. Die Zone schule.local wird eine Locale-Masterzone. Der Zonen-Transport kann aktiviert werden, muss aber nicht. Abbildung 70: DNS-Master-Zone Abbildung 71: DNS Zonen-Transport Der NS-Eintrag bestimmt den zuständigen Nameserver der Zone. Pro Zone sollten zwei zuständige Nameserver eingetragen werden (Primary und Sekondary). Abbildung 72: NS (Nameserver) der Zone schule.local
  • 77. Linux – Advanced 76 Abbildung 73: MX (Mailserver) der Zone schule.local Der MX-Eintrag bestimmt den zuständigen Mailserver für die Zone. Abbildung 74: SOA (Start of Authority) Neu seit Bind8.2 ist der Eintrag TTL. In früheren Versionen wurde diese Option an anderer Stelle aufgeführt, aber seit der Veröffentlichung von RFC 2308 musste die TTL-Anweisung an einem anderen Ort angegeben werden und hierfür wurde die erste Zeile gewählt. Dieser Wert gibt an, wie lange ein abfragender Nameserver die Daten in seinem Cache halten darf, bevor er die Daten aus dem Cache wieder entfernt.