Grundlagen Computernetze Prof. Jürgen Plate

TCP/IP

Die Schichten 5 - 7 des OSI-Standards werden hier in einer Anwendungsschicht zusammengefaßt, da die Anwendungsprogramme alle direkt mit der Transportschicht kommunizieren.

In Schicht 4 befindet sich außer TCP, welches gesicherten Datentransport (verbindungsorientiert, mit Flußkontrolle (d. h. Empfangsbestätigung, etc.) durch Windowing ermöglicht, auch UDP (User Datagram Protocol), in welchem verbindungsloser und ungesicherter Transport festgelegt ist. Beide Protokolle erlauben durch die Einführung von sogenannten Ports den Zugriff mehrerer Anwendungsprogramme gleichzeitig auf ein- und dieselbe Maschine.

In Schicht 3 ist das verbindungslose Internet-Protokoll (IP) angesiedelt. Datenpakete werden auf den Weg geschickt, ohne daß auf eine Empfangsbestätigung gewartet werden muß. IP-Pakete dürfen unter bestimmten Bedingungen (TTL=0, siehe unten) sogar vernichtet werden. In Schicht 3 werden damit auch die IP-Adressen festgelegt. Hier findet auch das Routing, das heißt die Wegsteuerung eines Paketes von einem Netz ins andere statt. Ebenfalls in diese Ebene integriert sind die ARP-Protokolle (ARP - Address Resolution Protocol), die zur Auflösung (= Umwandlung) einer logischen IP-Adresse in eine physikalische (z. B. Ethernet-) Adresse dienen und dazu sogenannte Broadcasts (Datenpakete, durch die alle angeschloßenen Stationen angesprochen werden) verwenden. ICMP, ein Protokoll, welches den Austausch von Kontroll- und Fehlerpaketen im Netz ermöglicht, ist ebenfalls in dieser Schicht realisiert.

Die Schichten 1 und 2 sind gegenüber Schicht 3 protokolltransparent. Sie können durch standardisierte Protokolle (z. B. Ethernet (CSMA/CD), FDDI, SLIP (Serial Line IP), PPP (Point-to-Point Protocol)) oder andere Übertragungsverfahren realisiert werden.

Zur TCP/IP-Familie gehören mehrere Dienstprogramme der höheren OSI-Schichten (5 - 7), z. B.:

• Telnet (RFC 854)
  Ein virtuelles Terminal-Protokoll, um vom eigenen Rechensystem einen interaktiven Zugang zu einem anderen System zu realisieren.
  
• FTP (RFC 959)
  Dieses (File-Transfer-) Protokoll ermöglicht, die Dateidienste eines Fremdsystems interaktiv zu benutzen sowie die Dateien zwischen den Systemen hin und her zu kopieren.
  
• NFS (RFC 1094)
  Das Network File System ermöglicht den Zugriff auf Dateien an einem entfernten System so, als wären sie auf dem eigenen. Man nennt dies auch einen transparenten Dateizugriff. NFS basiert auf den zur TCP/IP-Familie gehörenden UDP- (User- Datagramm-) Protokollen (ebenfalls Schicht 4), RFC 768. Im Unterschied zu TCP baut UDP keine gesicherten virtuellen Verbindungen zwischen kommunizierenden Hosts auf. Aufgrund dieser Eigenschaft ist es für den Einsatz in lokalen Netzen vorgesehen.
  
• NNTP (RFC 977)
  Das Network News Transfer Protocol spezifiziert Verteilung, Abfrage, Wiederauffinden und das Absetzen von News-Artikeln innerhalb eines Teils oder der gesamten Internet-Gemeinschaft. Die Artikel werden in regional zentralen Datenbasen gehalten. Einem Benutzer ist es möglich, aus dem gesamten Angebot nur einzelne Themen zu abonnieren.
  
• SMTP (RFC 821/822)
  Das Simple-Mail-Transfer-Protokoll (RFC 821) ist ein auf der IP-Adressierung sowie auf der durch den RFC 822 festgelegten Namensstruktur basierendes Mail-Protokoll.
  
• DNS (RFC 920)
  Der Domain Name Service unterstützt die Zuordnung von Netz- und Host-Adressen zu Rechnernamen. Dieser Service ist z. B. erforderlich für die Anwendung von SMTP sowie in zunehmendem Maße auch für Telnet und FTP. Aus Sicherheitsgründen wendet sich der fremde Host an den DNS, um zu prüfen, ob der IP-Adresse des ihn rufenden Rechners auch ein (Domain-)Name zugeordnet werden kann. Falls nicht, wird der Verbindungsaufbau abgelehnt.

Die TCP/IP-Protokolle

• LANs (Ethernet, Token-Ring, usw.)
  
• WANs (X.25, usw.)
  
• Punkt-zu-Punkt-Verbindungen (SLIP, PPP)
  

Es ist offensichtlich, daß die Gateways neben dem Routing weitere nichttriviale Funktionen haben, wenn sie zwischen den unterschiedlichsten Teilnetzen vermitteln (z. B. unterschiedliche Protokolle auf Ebene 2, unterschiedliche Datenpaketgröße, usw.).

Aus diesem Grund existieren in einem Internet drei unabhängige Namens- bzw. Adressierungsebenen:

• Physikalische Adressen (z. B. Ethernet-Adresse)
  
• Internet-Adressen (Internet-Nummer, IP-Adresse)
  
• Domain-Namen
  

Die Ethernet-Adresse wurde bereits behandelt, auf die anderen beiden Ebenen wird in den folgenden Abschnitten eingegangen. Die Umsetzung der höchsten Ebene (Domain-Namen) in IP-Adressen erfolgt durch das oben erwähnte DNS, worauf die Dienstprogramme der Schichten 5-7 zurückgreifen.

ARP

Die Station A will Daten an eine Station B mit der Internetadresse I(B) senden, deren physikalische Adresse P(B) sie noch nicht kennt. Sie sendet einem ARP-Request an alle Stationen im Netz, der die eigene physikalische Adresse und die IP-Adresse von B enthält.

Alle Stationen erhalten und überprüfen den ARP-Request und die angesprochene Station B antwortet, indem sie einen ARP-Reply mit ihrer eigenen physikalischen Adresse an die Station A sendet. Letztere speichert die Zuordnung in einer Tabelle (Address Resolution Cache).

Auch für die Umkehrfunktion gibt es eine standardisierte Vorgehensweise, den RARP (Reverse ARP). Hier sendet die Station A unter Angabe ihrer physikalischen Adresse P(A) einen RARP-Request. Wenn im Netz nur eine Station als RARP-Server eingerichtet ist (eine Station, die alle Zuordnungen von P(x) <--> I(x) "kennt"), antwortet diese mit einem RARP-Reply an die anfragende Station, der I(A) enthält. Diese Funktion ist z. B. für sogenannte "Diskless Workstations" wichtig, die ihre gesamte Software von einem Server laden.

ARP ist für den Benutzer unsichtbar, so dass das Vorhandensein dieses Protokolls meist nur bemerkt wird, wenn seltene Fehler auftreten. Die Dauer der Gültigkeit eines ARP-Eintrags (normalerweise wenige Minuten) kann ein Problem darstellen, wenn falsche Einträge vorhanden sind. Solange ein fehlerhafter Eintrag existiert, kann mit dem betreffenden Host nicht kommuniziert werden. Die Fehlfunktion wird häufig nicht dem ARP-Protokoll zugeschrieben, sondern dem Netz oder einem Fehler in der Netzwerkimplementierung. Darüber hinaus ermöglicht nicht jedes Betriebssystem das Erzeugen eines korrigierten Eintrags oder einer Anforderung. Mit ARP-Spoofing ist es möglich, absichtlich eine falsche Hardwareadresse in einem Netz zu verteilen. Dadurch kann der Datenverkehr für einen Rechner auf einen anderen umgelenkt und eventuell von diesem sogar verändert werden.

Proxy ARP

Sendet Computer 1 eine ARP-Anforderung an Computer 2, reagiert der dazwischen liegende Router anstelle des Computers 2 mit einer ARP-Antwort und der MAC-Adresse des Ports am Router, auf dem die Anfrage empfangen wurde. Der anfragende Computer 1 sendet dann seine Daten an den Router, der sie dann an Computer 2 weiterleitet.

Gratuitous ARP

• Normalerweise darf keine Antwort kommen, denn eine IP-Adresse muss in einem Netz eindeutig sein. Bekommt er trotzdem eine Antwort, ist das für den Administrator ein Hinweis darauf, dass ein Host nicht richtig konfiguriert ist.
• Jeder Host aktualisiert seinen ARP-Cache. Das ist beispielsweise dann nützlich, wenn die Netzwerkkarte eines Rechners ausgetauscht wurde und die anderen Hosts über die neue MAC-Adresse informiert werden sollen. Gratuitous ARP geschieht deshalb normalerweise beim Booten eines Computers.
• Wenn zwei Server aus Gründen der Ausfallsicherheit als Server und Ersatzserver aufgebaut sind (Hochverfügbarkeit, HA-Server) und sich daher eine IP-Adresse teilen. Wird der aktive Verkehr vom einem auf den anderen Server umgeschaltet, ist die IP-Adresse über eine andere MAC-Adresse erreichbar. Diese neue MAC-IP-Adresskombination muss bekannt gemacht werden. Sonst bekommt niemand den Wechsel mit.
• In einem Mobile IP-Szenario sendet der Home Agent einen Gratuitous ARP, wenn sich der Mobile Host aus dem Heimatnetz entfernt, um die Pakete stellvertretend für diesen zu empfangen. Analog sendet der Mobile Host einen Gratuitous ARP, sobald er sich wieder im Netz befindet.

IP - Internet Protocol

IP ist ein verbindungsloses Protokoll. Es ist also nicht notwendig, eine IP-Verbindung zu einem Rechner zu 'öffnen', bevor man Daten zu diesem Rechner senden kann, sondern es genügt, das IP-Paket einfach abzusenden und darauf zu vertrauen, daß es schon ankommen wird. Bei einem verbindungsorientierten Protokoll wird beim Öffnen einer Verbindung getestet, ob der Zielrechner überhaupt erreichbar ist. Ein verbindungsloses Protokoll macht das nicht und kann demnach auch nicht garantieren, daß ein Datenpaket überhaupt beim Empfänger ankommt. IP garantiert auch nicht, daß von einem einmal abgeschickten Datenpaket nur eine Kopie beim Empfänger ankommt oder daß in einer bestimmten Reihenfolge abgeschickte Datenpakete auch wieder in dieser Reihenfolge empfangen werden.
Normalerweise laufen die IP-Pakete über mehrere Zwischenstationen, bis sie am Zielrechner ankommen. Bricht irgendwann während der Übertragung ein Übertragungsweg zusammen, so wird ein neuer Weg zum Ziel gesucht und benutzt. Da der neue Weg zeitlich länger oder kürzer sein kann als der alte, kann man keine allgemeingültigen Aussagen darüber machen, in welcher Reihenfolge IP-Pakete beim Empfänger eintreffen. Es kann auch sein, daß bei dieser Umschalterei IP-Pakete verlorengehen oder sich verdoppeln. Das Beheben der so entstehenden Probleme überläßt das IP-Protokoll anderen, höherliegenden Schichten.

Das Internet-Protokoll ist somit ein verbindungsloser Dienst mit einem 'Unreliable Datagram Service', d. h. es wird auf der IP-Ebene weder die Richtigkeit der der Daten noch die Einhaltung von Sequenz, Vollständigkeit und Eindeutigkeit der Datagramme überprüft. Ein zuverlässiger verbindungsorientierter Dienst wird in der darüberliegenden TCP-Ebene realisiert.

Ein IP-Datagramm besteht aus einem Header und einem nachfolgenden Datenblock, der seinerseits dann z. B. in einem Ethernet-Frame "verpackt" wird. Die maximale Datenlänge wird auf die maximale Rahmenlänge des physikalischen Netzes abgestimmt. Da nicht ausgeschlossen werden kann, daß ein Datagramm auf seinem Weg ein Teilnetz passieren muß, dessen Rahmenlänge niedriger ist, müssen zum Weitertransport mehrere (Teil-)Datagramme erzeugt werden. Dazu wird der Header im Wesentlichen repliziert und die Daten in kleinere Blöcke unterteilt. Jedes Teil-Datagramm hat also wieder einen Header. Diesen Vorgang nennt man Fragmentierung. Es handelt sich um eine rein netztechnische Maßnahme, von der Quell- und Zielknoten nichts wissen müssen. Es gibt natürlich auch eine umgekehrte Funktion, "Reassembly", die kleine Datagramme wieder zu einem größeren packt. Geht auf dem Übertragungsweg nur ein Fragment verloren, muß das gesamte Datagramm wiederholt werden. Es gilt die Empfehlung, daß Datagramme bis zu einer Länge von 576 Bytes unfragmentiert übertragen werden sollten.

Format des IP-Headers

Version

Kennzeichnet die IP-Protokollversion

IHL (Internet Header Length)

Die Angabe der Länge des IP-Headers erfolgt in 32-Bit-Worten (normalerweise 5). Da die Optionen nicht unbedingt auf Wortlänge enden, wird der Header gegebenenfalls aufgefüllt.

Type of Service

Alle Bits haben nur "empfehlenden" Charakter. 'Precedence' bietet die Möglichkeit, Steuerinformationen vorrangig zu befördern.

Total Length

Gesamtlänge des Datagramms in Bytes (max. 64 KByte).

Identification

Dieses und die beiden folgenden Felder steuern die Reassembly. Eindeutige Kennung eines Datagramms. Anhand dieses Feldes und der 'Source Address' ist die Zusammengehörigkeit von Fragmenten zu detektieren.

Flags

Die beiden niederwertigen Bits haben folgende Bedeutung:

• Don't fragment: Für Hosts, die keine Fragmentierung unterstützen
• More fragments: Zum Erkennen, ob alle Fragmente eines Datagramms empfangen wurden

Fragment Offset

Die Daten-Bytes eines Datagramms werden numeriert und auf die Fragmente verteilt. Das erst Fragment hat Offset 0, für alle weiteren erhöht sich der Wert um die Länge des Datenfeldes eines Fragments. Anhand dieses Wertes kann der Empfänger feststellen, ob Fragmente fehlen. Beispiel siehe unten.

Time-to-live (TTL)

Jedes Datagramm hat eine vorgegebene maximale Lebensdauer, die hier angegeben wird. Auch bei Routing-Fehlern (z. B. Schleifen) wird das Datagramm irgendwann aus dem Netz entfernt. Da Zeitmessung im Netz problematisch ist, und keine Startzeit im Header vermerkt ist, decrementiert jeder Gateway dieses Feld --> de-facto ein 'Hop Count'.

Protocol

Da sich unterschiedliche Protokolle auf IP stützen, muß das übergeordnete Protokoll (ULP, Upper Layer Protocol) angegeben werden. Wichtige ULPs sind

• 1: ICMP Internet Control Message P.
• 3: GGP Gateway-to-Gateway P.
• 6: TCP Transmission Control P.
• 8: EGP Exterior Gateway P.
• 17: UDP User Datagram P.

Header Checksum

16-Bit-Längsparität über den IP-Header (nicht die Daten)

Source Address

Internet-Adresse der Quellstation

Destinantion Address

Internet-Adresse der Zielstation

Options

Optionales Feld für weitere Informationen (deshalb gibt es auch die Header-Länge). Viele Codes sind für zukünftige Erweiterungen vorgesehen. Die Optionen dienen vor allem der Netzsteuerung, der Fehlersuche und für Messungen. Die wichtigsten sind:

• Record Route: Weg des Datagramms mitprotokollieren
• Loose Source Routing: Die sendende Station schreibt einige Zwischenstationen vor (aber nicht alle)
• Strict Source Routing: Die sendende Station schreibt alle Zwischenstationen vor.
• Timestamp Option: Statt seiner IP-Adresse (wie bei Record Route) trägt jeder Gateway den Bearbeitungszeitpunkt ein (Universal Time).

Padding

Füllbits

Die Hauptaufgabe von IP ist es also, die Unterschiede zwischen den verschiedenen, darunterliegenden Netzwerkschichten zu verbergen und eine einheitliche Sicht auf die verschiedensten Netztechniken zu präsentieren. So gibt es IP nicht nur in Netzen, sondern auch als SLIP (Serial Line IP) oder PPP (Point to Point Protocol) für Modem- oder ISDN-Verbindungen. Zur Vereinheitlichung gehören auch die Einführung eines einheitlichen Adressierungsschemas und eines Fragmentierungsmechanismus, der es ermöglicht, große Datenpakete durch Netze mit kleiner maximaler Paketgröße zu senden: Normalerweise existiert bei allen Netzwerken eine maximale Größe für ein Datenpaket. Im IP-Jargon nennt man diese Grenze die 'Maximum Transmisson Unit' (MTU). Natürlich ist diese Obergrenze je nach verwendeter Hardware bzw. Übertragungstechnik unterschiedlich. Die Internet-Schicht teilt IP-Pakete, die größer als die MTU des verwendeten Netzwerks sind, in kleinere Stücke, sogenannte Fragmente, auf. Der Zielrechner setzt diese Fragmente dann wieder zu vollständigen IP-Paketen zusammen, bevor er sie an die darüberliegenden Schichten weitergibt. Der Fragement Offset gibt an, an welcher Stelle in Bezug auf den IP-Datagramm-Anfang das Paket in das Datagramm einzuordnen ist. Aufgrund des Offset werden die Pakete in die richtige Reihenfolge gebracht. Dazu ein Beispiel:

Es soll ein TCP-Paket mit einer Länge von 250 Byte über IP versandt werden. Es wird angenommen, daß ein IP-Header eine Länge von 20 Byte hat und eine maximale Länge von 128 Byte pro Paket nicht überschritten werden darf Der Identifikator des Datagramms beträgt 43 und der Fragmentabstand wird in 8-Byte-Schritten gezählt. Das Datenfragment muß also durch 8 dividierbar sein.

Da alle Fragmente demselben Datagramm angehören, wird der Identifikator für alle Fragmente beibehalten. Im ersten Fragment ist das Fragment Offset natürlich noch Null, das MF-Bit jedoch auf 1 gesetzt, um zu zeigen, daß noch Fragmente folgen. Im IP-Header des zweiten Fragments beträgt das Fragment Offset 13 (104/8 = 13) und zeigt die Position des Fragments im Datagramm an. Das MF-Bit ist noch immer 1, da noch ein Datenpaket folgt. Der Header des dritten Fragments enthält dann ein MF-Bit mit dem Wert 0, denn es handelt sich um das letzte Datenpaket zum Datagramm 43. Das Fragment Offset ist auf 26 gesetzt, da vorher schon 208 Daten-Bytes (8 * 26 = 208) übertragen wurden.
Sobald das erste Fragment (gleich welches) im Empfänger ankommt, wird ein Timer gesetzt. Sind innerhalb der dort gesetzten Zeit nicht alle Pakete zu einem Datagramm eingetroffen, wird angenommen, daß Fragmente verlorengingen. Der Empfänger verwirft dann alle Datenpakete mit diesem Identifikator.

Was geschieht aber, wenn der Kommunikationspartner nicht erreichbar ist? Wie schon erwähnt, durchläuft ein Datagramm mehrere Stationen. Diese Stationen sind in der Regel Router oder Rechner, die gleichzeitig als Router arbeiten. Ohne Gegenmaßnahme würde das Datenpaket für alle Zeiten durch das Netze der Netze irren. Dazu gibt es im IP-Header neben anderer Verwaltungsinfo auch ein Feld mit dem Namen TTL (Time To Live). Der Wert von TTL kann zwischen 0 und 255 liegen. Jeder Router, der das Datagramm transportiert, vermindert den Wert dieses Feldes um 1. Ist der Wert von TTL bei Null angelangt, wird das Datagramm vernichtet.

Die Adressen, die im Internet verwendet werden, bestehen aus einer 32 Bit langen Zahl. Damit sich die Zahl leichter darstellen läßt, unterteilt man sie in 4 Bytes (zu je 8 Bit). Diese Bytes werden dezimal notiert und durch Punkte getrennt (a.b.c.d). Zum Beispiel:

    141.84.101.2
    129.187.10.25

Netzklassen

Besondere Adreßklassen

Grundsätzlich gilt:

• Alle Rechner mit der gleichen Netzwerkadresse gehören zu einem Netz und sind untereinander erreichbar.
• Zur Koppelung von Netzen unterschiedlicher Adresse wird eine spezielle Hardware- oder Softwarekomponente, ein sogenannter Router, benötigt.
• Je nach Zahl der zu koppelnden Rechner wird die Netzwerkklasse gewählt.

• Die Netzwerkadresse 127.0.0.1 bezeichnet jeweils den lokalen Rechner (loopback address). Sie dient der Konsistenz der Netzwerksoftware (jeder Rechner ist über seine Adresse ansprechbar) und dem Test (eigentlich wird hier ein ganzes C-Netz belegt, nämlich 127.0.0.x).

Damit man nun lokale Netze ohne Internetanbindung mit TCP/IP betreiben kann, ohne IP-Nummern beantragen zu müssen und um auch einzelne Rechnerverbindungen testen zu können, gibt es einen ausgesuchten Nummernkreis, der von keinem Router nach außen gegeben wird. Diese "privaten" Adressen sind im RFC 1597 festgelegt. Es gibt ein Class-A-Netz, 16 Class-B-Netze und 255 Class-C-Netze:

• Class-A-Netz: 10.0.0.0 - 10.255.255.255
• Class-B-Netze: 172.16.0.0 - 172.31.255.255
• Class-C-Netze: 192.168.0.0 - 192.168.255.255

Zusätzlich hat die IANA auch das folgende Class-B-Netz für private Netze reserviert, das schon von Apple- und Microsoft-Clients verwendet wird, sofern kein DHCP-Server zur Verfügung steht. Das Verfahren heißt APIPA (Automatic Private IP Addressing):

• 169.254.0.0 - 169.254.255.255

Weitere Adressen mit speziellen Aufgaben sind:

• 100.64.0.0 - 100.127.255.255: Adressbereich für Carrier Grade NAT (CGN, RFC 6264). Aus diesem Bereich teilen Internet-Provider ihren Kunden Adressen zu, wenn ihnen die öffentlichen IP-Adressen ausgegangen sind.
• 192.0.0.0 - 192.0.0.255 sind reserviert. Das Netz wird bei Bedarf in das Vergabeverfahren übernommen.
• 192.0.2.0 - 192.0.2.255, 198.51.100.0 - 198.51.100.255 und 203.0.113.0 - 203.0.113.255 sind reserviert als Beispieladressen in Dokumentationen (wie die Domain-Namen "example.com" und "example.net"). Adressen aus diesem Bereich dürfen nicht im öffentlichen Internet auftauchen.
• 192.88.99.0 - 192.88.99.255 sind Adressen für die Verbindung von IPv6-Netzwerken über IPv4 ("6to4 anycast address").
• 198.18.0.0 - 198.19.255.255 sind Adressen für den Test von Netzwerkkomponenten.

• Dynamische Vergabe von IP-Adressen: Dieses Verfahren wird beim Dial-In beim Provider verwendet. Es eignet sich auch im lokalen Netz, wenn davon auszugehen ist, daß immer nur ein Teil der Rechner in Betrieb ist. Der Benutzer bekommt für die Dauer einer Verbindung eine IP-Adresse zugeteilt. Das bekannteste Verfahren heißt DHCP (dynamic host configuration protocol).
• Weiterentwicklung des IP-Protokolls: Mit IP Version 6 wird ein auf 128 Bit erweiterter Adressraum geschaffen. Damit stehen genügend Adressen zur Vefügung.
• Network Address Translation (NAT): Über ein Gateway wird im Internet eine andere IP-Adresse verwendet als im lokalen Netz (private Adressräume). Die Umsetzung erlaubt sogar, ein komplettes privates Netz (siehe oben) mit einer einzigen externen IP-Adresse zu betreiben.

Network Address Translation (NAT) und IP-Masquerading

• NAT (Network Address Translation)
  Beim NAT (Network Address Translation) werden die Adressen eines privaten Netzes über Tabellen öffentlich registrierten IP-Adressen zugeordnet. Der Vorteil besteht darin, daß Rechner, die in einem privaten Netz miteinander kommunizieren, keine öffentlichen IP-Adressen benötigen. IP-Adressen interner Rechner, die eine Kommunikation mit Zielen im Internet aufbauen, erhalten in dem Router, der zwischen dem Internet Service Provider (ISP) und dem privaten Netzwerk steht, einen Tabelleneintrag. Durch diese Eins-zu-Eins-Zuordnung sind diese Rechner nicht nur in der Lage, eine Verbindung zu Zielen im Internet aufzubauen, sondern sie sind auch aus dem Internet erreichbar. Die interne Struktur des Firmennetzwerkes bleibt jedoch nach außen verborgen.
  

• IP Masquerading
  IP Masquerading, das manchmal auch als PAT (Port and Address Translation) bezeichnet wird, bildet alle Adressen eines privaten Netzwerkes auf eine einzelne öffentliche IP-Adresse ab. Dies geschieht dadurch, daß bei einer existierenden Verbindung zusätzlich zu den Adressen auch die Portnummern ausgetauscht werden. Auf diese Weise benötigt ein gesamtes privates Netz nur eine einzige registrierte öffentliche IP-Adresse. Der Nachteil dieser Lösung besteht darin, daß die Rechner im privaten Netzwerk nicht aus dem Internet angewählt werden können. Diese Methode eignet sich daher hervorragend, um zwei und mehr Rechner eines privaten Anschlusses per DFÜ-Netzwerk oder ISDN-Router an das Internet zu koppeln.
  

  IP Masquerading rückt mit dieser Funktionalität sehr nahe an Proxy- und Firewall-Lösungen heran, wobei ein Proxy explizit für ein Protokoll (z. B. HTTP) existieren und aufgerufen werden muß.

Subnetze

• Subnetze sind Strukturierungsmöglichkeit für Netze, ohne daß man zusätzliche Klasse-A-, Klasse-B- oder Klasse-C-IP-Adressen braucht.
• Die Standardprozedur, um ein Netz in Unternetze (Subnetze) zu teilen, nennt man "Subnetting".
• Die Hostadresse des A-, B- oder C-Netzes teilt sich in die Bereiche Subnetzadresse (Subnet-ID, Teilnetz-ID) und Hostadresse (verbleibende, verkürzte Host-ID). Ein Teil des Hostadressbereiches wird also genutzt, um die Subnetze zu unterscheiden.
• Die Netzadresse und den Subnetzanteil des Hostadressraumes bezeichnet man als "erweiterte Netzadresse" (extended network prefix).
• Die interne Subnetz-Struktur von A-, B- oder C-Netzen ist nach außen hin unsichtbar.
• Damit Router in der Lage sind, Datagramme in das richtige Netz zuzustellen, müssen sie bei der IP-Adresse den Netz- und Hostanteil unterscheiden können.
• Dies geschieht traditionell durch die Netzmaske bzw. Subnetzmaske (subnet mask).

Eine Subnet-Maske für ein Netz der Klasse C lautet daher 255.255.255.0. Das bedeutet, daß die ersten drei Bytes die Netzadresse angeben und das vierte Byte die Rechner adressiert. Eine Subnetz-Maske mit dem Wert 255.255.0.0 würde folglich ein Netz der Klasse B angeben und für ein C-Netz steht die Maske 255.255.255.0.

Aufteilung in Subnetze

Anmerkungen:

*)  Die erste und letzte bei der Unterteilung entstehenden Adressen dürfen nicht verwendet werden (Verwechslung mit Netz- und Broadcast-Adresse des übergeordneten Netzes). Die Anzahl der Subnetze verringert sich somit jeweils um zwei:
Ist der Netzwerkanteil der IP-Adresse n Bits, dann erhält man (2ⁿ) - 2 Subnetze.

**) Die Rechneranzahl verringert sich ebenfalls um zwei wegen Subnetz-Adresse (alle Rechnerbits auf 0) und Broadcast-Adresse (alle Rechnerbits auf 1):
Ist der Hostanteil der IP-Adresse m Bits, dann erhält man (2^m) - 2 Hosts pro Subnetz.

Besitzt breispielsweise ein Unternehmen ein Netz der Klasse C, möchte man dieses vielleicht in zwei Segmente unterteilen, die voneinander getrennt sind. Der Broadcastverkehr des ersten Segments kann so das andere nicht beeinträchtigen. In diesem Fall kommt die Subnetz-Maske zum Einsatz, welche die Rechneradressen in zwei Bereiche gliedert. Sollen die Rechner in vier gleich große Subnetze mit je 64 Knoten eingeteilt werden, lautet die Subnetz-Maske 255.255.255.192. Es gilt die folgende Formel für das Maskier-Byte:

Bytewert = 256 - (Anzahl der Knoten in einem Segment)

Als das Subnetting erstmals standardisiert wurde, war es verboten die Subnetze zu nutzen, in denen alle Subnetzbits den Wert 0 oder 1 hatten (siehe Anmerkungen oben). Damit ergeben sich im Beispiel nur zwei Subnetze mit je 62 Hosts. Inzwischen beherrschen fast alle Systeme korrektes Subnetting ("classless" routing).

Beispiel: Aufteilung in 4 Subnetze

Allgemein ergibt sich für ein C-Netz folgende Aufstellung:

Subnetze eines C-Netzes

Beispiel: Aufteilung in 8 (6) Subnetze

Damit sind die acht zur Verfügung stehenden Subnetze bekannt:

192.168.0.0/27
192.168.0.32/27
192.168.0.64/27
192.168.0.96/27
192.168.0.128/27
192.168.0.160/27
192.168.0.192/27
192.168.0.224/27

Anmerkung:

Die Zahl hinter dem Schrägstrich (oben ist das die 27) gibt an, wieviele Bits der 32 Bit langen IP-Adresse als Netzanteil verwendet werden.

Diese Subnetze können jetzt einzelnen Netzen zugeordnet werden. Die folgende Tabelle zeigt die Netz- und Broadcastadressen von jedem einzelnen Subnetz und die Rechneradressen.

Als kleine Hilfe gibt es hier noch einen Subnetz-Rechner als Javascript-Programm. Eingegeben wird eine IP-Netzadresse in CIDR-Form (Classless Inter-Domain Routing, z.B. 10.1.2.0/24). Nach dem Klick auf "Berechnen" erscheinen im unteren Feld die Werte der Netzadresse, der Subnet-Maske und der Bereich der zugehörigen IP-Adressen, wobei die erste Adresse des angebenen Bereichs die Netzadresse darstellt und die letzte Adresse die Broadcast-Adresse.

ICMP - Internet Control Message Protocol

Die ICMP-Nachricht ist im Datenteil des IP-Datagramms untergebracht, sie enthält ggf. den IP-Header und die ersten 64 Bytes des die Nachricht auslösenden Datagramms (z. B. bei Timeout).

Die fünf Felder der ICMP-Message haben folgende Bedeutung:

Type

Identifiziert die ICMP-Nachricht

• 0 Echo reply
• 3 Destination unreachable
• 4 Source quench
• 5 Redirect (Change a Route)
• 8 Echo request
• 11 Time exceeded for a datagram
• 12 Parameter Problem on a datagram
• 13 Timestamp request
• 14 Timestamp reply
• 15 Information request
• 16 Information reply
• 17 Address mask request
• 18 Address mask reply

Code

Detailinformation zum Nachrichten-Typ

Checksum

Prüfsumme der ICMP-Nachricht (Datenteil des IP-Datagramms)

Identifier und Sequence-Nummer

dienen der Zuordnung eintreffender Antworten zu den jeweiligen Anfragen, da eine Station mehrere Anfragen aussenden kann oder auf eine Anfrage mehrere Antworten eintreffen können.

Wenden wir uns nun den einzelnen Nachrichtentypen zu:

Echo request/reply

Überprüfen der Erreichbarkeit eines Zielknotens. Es können Testdaten mitgeschickt werden, die dann unverändert zurückgeschickt werden (--> Ping-Kommando unter UNIX).

Destination unreachable

Im Codefeld wird die Ursache näher beschrieben: 0 Network unreachable 1 Host unreachable 2 Protocol unreachable 3 Port unreachable 4 Fragmentation needed 5 Source route failed

Source quench

Wenn mehr Datagramme kommen als eine Station verarbeiten kann, sendet sie diese Nachricht an die sendende Station.

Redirect

wird vom ersten Gateway an Hosts im gleichen Teilnetz gesendet, wenn es eine bessere Route-Verbindung über einen anderen Gateway gibt. In der Nachricht wird die IP-Adresse des anderen Gateways angegeben.

Time exceeded

Für diese Nachricht an den Quellknoten gibt es zwei Ursachen:

• Time-to-live exceeded (Code 0): Wenn ein Gateway ein Datagramm eliminiert, dessen TTL-Zähler abgelaufen ist.
• Fragment reassembly time exceeded (Code 1): Wenn ein Timer abläuft, bevor alle Fragmente des Datagramms eingetroffen sind.

Parameter problem on a Datagramm

Probleme bei der Interpretation des IP-Headers. Es wird ein Verweis auf die Fehlerstelle und der fragliche IP-Header zurückgeschickt.

Timestamp request/reply

Erlaubt Zeitmessungen und -synchronisation im Netz. Drei Zeiten werden gesendet (in ms seit Mitternacht, Universal Time):

• Originate T.: Sendezeitpunkt des Requests (vom Absender)
• Receive T.: Ankunftszeit (beim Empfänger)
• Transmit T.: Sendezeitpunkt des Reply (vom Empfänger)

Information request/reply

Mit dieser Nachricht kann ein Host die Netid seines Netzes erfragen, indem er seine Netid auf Null setzt.

Address mask request/reply

Bei Subnetting (siehe unten) kann ein Host die Subnet-Mask erfragen.

Für den User nutzbar ist ICMP vor allem für die Kommandos ping und traceroute (bei Windows "tracert"). Diese Kommandos senden ICMP-Echo-Requests aus und warten auf den ICMP-Echo-Reply. So kann man die Erreichbarkeit eines Knotens feststellen. Will man alle Knoten im lokalen Netz erkennen genügt ein ping auf die Broadcast-Adresse, z. B.:

ping 192.168.33.255

Führt man das obige ping-Kommando und das arp-Kommando nacheinander aus, erhält man eine liste der IP- umd MAC-Adressen der aktiven lokalen Knoten, z.B.:

ping -b -c1 192.168.33.255
arp -a

UDP - User Datagram Protocol

Source Port

Identifiziert den sendenden Prozeß (falls nicht benötigt, wird der Wert auf Null gesetzt).

Destination Port

Identifiziert den Prozeß des Zielknotens.

Length

Länge des UDP-Datagramms in Bytes (mindestens 8 = Headerlänge)

UDP-Checksum

Optionale Angabe (falls nicht verwendet auf Null gesetzt) einer Prüfsumme. Zu deren Ermittlung wird dem UDP-Datagramm ein Pseudoheader von 12 Byte vorangestellt (aber nicht mit übertragen), der u. a. IP-Source-Address, IP-Destination-Address und Protokoll-Nummer (UDP = 17) enthält.

TCP - Transmission Control Protocol

Die Aufgabe von TCP ist es, die oben geschilderten Defizite von IP zu verbergen. Für den TCP-Benutzer soll es nicht mehr sichtbar sein, daß die darunterliegenden Protokollschichten Datenpakete versenden, sondern es soll der Benutzer mit einem Byte-Strom wie bei einer normalen Datei (oder einem Terminal) arbeiten können. TCP garantiert vor allen Dingen den korrekten Transport der Daten - jedes Paket kommt nur einmal, fehlerfrei und in der richtigen Reihenfolge an. Zusätzlich können bei TCP mehrere Programme die Verbindung zwischen zwei Rechnern quasi-gleichzeitig nutzen. TCP teilt die Verbindung in viele virtuelle Kanäle ("Ports") auf, die zeitmultiplex mit Daten versorgt werden. Nur so ist es möglich, daß beispielsweise mehrere Benutzer eines Rechners zur selben Zeit das Netz in Anspruch nehmen können oder daß man mit einer einzigen Wählverbindung zum Provider gleichzeitig E-Mail empfangen und Dateien per FTP übertragen kann.

Dieses Protokoll implementiert also einen verbindungsorientierten, sicheren Transportdienst als Schicht-4-Protokoll. Die Sicherheit wird durch positive Rückmeldungen (acknowledgements) und Wiederholung fehlerhafter Blöcke erreicht. Fast alle Standardanwendungen vieler Betriebssysteme nutzen TCP und das darunterliegende IP als Transportprotokoll, weshalb man die gesamte Protokollfamilie allgemein unter 'TCP/IP' zusammenfaßt. TCP läßt sich in lokalen und weltweiten Netzen einsetzen, da IP und die darunterliegenden Schichten mit den unterschiedlichsten Netzwerk- und Übertragungssystemen arbeiten können (Ethernet, Funk, serielle Leitungen, ...). Zur Realisierung der Flußkontrolle wird ein Fenstermechanismus (sliding windows) verwendet (variable Fenstergröße). TCP-Verbindungen sind vollduplex. Wie bei allen verbindungsorientierten Diensten muß zunächst eine virtuelle Verbindung aufgebaut und bei Beendigung der Kommunikation wieder abgebaut werden. "Verbindungsaufbau" bedeutet hier eine Vereinbarung beider Stationen über die Modalitäten der Übertragung (z. B. Fenstergröße, Akzeptieren eines bestimmten Dienstes, usw.). Ausgangs- und Endpunkte einer virtuellen Verbindung werden wie bei UDP durch Ports identifiziert. Allgemein verfügbare Dienste werden über 'well known' Ports (--> feste zugeordnete Portnummer) erreichbar. Andere Portnummern werden beim Verbindungsaufbau vereinbart.

Damit die ständige Bestätigung jedes Datensegments den Transport nicht über Gebühr hemmt, werden zwei Tricks verwendet. Zum einen kann die Empfangsbetätigung einem Segment in Gegenrichtung mitgegeben werden - das spart ein separates Quittungssegment. Zweitens muß nicht jedes Byte sofort bestätigt werden, sondern es gibt ein sogenanntes 'Fenster'. Die Fenstergröße gibt an, wieviele Bytes gesendet werden dürfen, bis die Übertragung quittiert werden muß. Erfolgt keine Quittung, werden die Daten nochmals gesendet. Die empfangene Quittung enthält die Nummer des Bytess, das als nächstes vom Empfänger erwartet wird - womit auch alle vorhergehenden Bytes quittiert sind. Die Fenstergröße kann dynamisch mit der Quittung des Empfängers geändert werden. Werden die Ressourcen knapp, wird die Fenstergröße verringert. Beim Extremfall Null wird die Übertragung unterbrochen, bis der Empfänger erneut quittiert. Neben einem verläßlichen Datentransport ist so auch die Flußkontrolle gewährleistet.

Das Prinzip des Fenstermechanismus ist eigentlich ganz einfach. Wenn man das Bild betrachtet, ergibt sich folgende Sachverhalt:

• Die Fenster größe im Beispiel beträgt drei Bytes.
• Byte 1 wurde von der Datenquelle gesendet und vom Empfänger quittiert.
• Die Quelle hat die Bytes 2, 3 und 4 gesendet, sie wurden aber vom Empfänger noch nicht quittiert (Quittung eventuell noch unterwegs).
• Byte 5 wurde von der Quelle noch nicht gesendet. Er geht erst dann auf die Reise, wenn die Quittung für Byte 2 (oder höher) eingetroffen ist.

Das TCP-Paket wird oft auch als 'Segment' bezeichnet. Jedem TCP-Block ist ein Header vorangestellt, der aber wesentlich umfangreicher als die bisherigen ist:

Source Port

Identifiziert den sendenden Prozeß.

Destination Port

Identifiziert den Prozeß des Zielknotens.

Sequence Number

TCP betrachtet die zu übertragenden Daten als numerierten Bytestrom, wobei die Nummer des ersten Bytes beim Verbindungsaufbau festgelegt wird. Dieser Bytestrom wird bei der Übertragung in Blöcke (TCP-Segmente) aufgeteilt. Die 'Sequence Number' ist die Nummer des ersten Datenbytes im jeweiligen Segment (--> richtige Reihenfolge über verschiedene Verbindungen eintreffender Segmente wiederherstellbar).

Acknowledgement Number

Hiermit werden Daten von der Empfängerstation bestätigt, wobei gleichzeitig Daten in Gegenrichtung gesendet werden. Die Bestätigung wird also den Daten "aufgesattelt" (Piggyback). Die Nummer bezieht sich auf eine Sequence-Nummer der empfangenen Daten; alle Daten bis zu dieser Nummer (ausschließlich) sind damit bestätigt --> Nummer des nächsten erwarteten Bytes. Die Gültigkeit der Nummer wird durch das ACK-Feld (--> Code) bestätigt.

Data Offset

Da der Segment-Header ähnlich dem IP-Header Optionen enthalten kann, wird hier die Länge des Headers in 32-Bit-Worten angegeben.

Res.

Reserviert für spätere Nutzung

Code

Angabe der Funktion des Segments:

• URG Urgent-Pointer (siehe unten)
• ACK Quittungs-Segment (Acknowledgement-Nummer gültig)
• PSH Auf Senderseite sofortiges Senden der Daten (bevor Sendepuffer gefüllt ist) und auf Empfangsseite sofortige Weitergabe an die Applikation (bevor Empfangspuffer gefüllt ist) z. B. für interaktive Programme.
• RST Reset, Verbindung abbauen
• SYN Das 'Sequence Number'-Feld enthält die initiale Byte-Nummer (ISN) --> Numerierung beginnt mit ISN + 1. In der Bestätigung übergibt die Zielstation ihre ISN (Verbindungsaufbau).
• FIN Verbindung abbauen (Sender hat alle Daten gesendet), sobald der Empfänger alles korrekt empfangen hat und selbst keine Daten mehr loswerden will.

Window

Spezifiziert die Fenstergröße, die der Empfänger bereit ist anzunehmen - kann dynamisch geändert werden.

Checksum

16-Bit Längsparität über Header und Daten.

Urgent Pointer

Markierung eines Teils des Datenteils als dringend. Dieser wird unabhängig von der Reihenfolge im Datenstrom sofort an das Anwenderprogramm weitergegeben (URG-Code muß gesetzt sein). Der Wert des Urgent-Pointers markiert das letzte abzuliefernde Byte; es hat die Nummer <Sequence Number> + <Urgent Pointer>.

Options

Dieses Feld dient dem Informationsaustausch zwischen beiden Stationen auf der TCP-Ebene, z. B. die Segmentgröße (die Ihrerseits von der Größe des IP-Datagramms abhängen sollte, um den Durchsatz im Netz optimal zu gestalten).

Ablauf einer TCP-Session

Beim Öffnen einer TCP-Verbindung tauschen beide Kommunikationspartner Kontrollinformationen aus, die sicherstellen, daß der jeweilige Partner existiert und Daten annehmen kann. Dazu schickt die Station A ein Segment mit der Aufforderung, die Folgenummern zu synchronisieren.
Das einleitende Paket mit gesetztem SYN-Bit ("Synchronise-" oder "Open"-Request) gibt die Anfangs-"Sequence Number" des Client bekannt. Diese Anfangs-"Sequence Number wird zufällig bestimmt. Bei allen nachfolgenden Paketen ist das ACK-Bit ("Acknowledge", "Quittung") gesetzt. Der Server antwortet mit ACK, SYN und der Client bestätigt mit ACK. Das sieht dann so aus:

Die Station B weiß jetzt, daß der Sender eine Verbindung öffnen möchte und an welcher Position im Datenstrom der Sender anfangen wird zu zählen. Sie bestätigt den Empfang der Nachricht und legt ihrerseits eine Folgenummer für Übertragungen in Gegenrichtung fest.

Station A bestätigt nun den Empfang der Folgenummer von B und beginnt dann mit der Übertragung von Daten.

Diese Art des Austausches von Kontrollinformationen, bei der jede Seite die Aktionen der Gegenseite bestätigen muß, ehe sie wirksam werden können, heißt "Dreiwege-Handshake". Auch beim Abbau einer Verbindung wird auf diese Weise sichergestellt, daß beide Seiten alle Daten korrekt und vollständig empfangen haben. Im zeitlichen Zusammenhang stellt sich eine TCP/IP-Verbindung folgendermaßen dar:

Das folgende Beispiel zeigt die Arbeitsweise des TCP/IP - Protokolls. Es wird eine Nachricht von einem Rechner im grünen Netz zu einem Rechner im orangen Netz gesendet.

	Die Nachricht wird in mehrere Pakete aufgeteilt und auf der besten Route auf die Reise geschickt. Das verbindungslose IP-Protokoll sorgt zusammen mit den Routern für den Weg.
Da eine Strecke überlastet ist, werden die Pakete 3, 4 und 5 auf einer anderen Strecke weiter transportiert. Dieser Transport erfolgt zufälligerweise schneller als jener der Pakete 1 und 2.
	Die Pakete wandern ihrem Bestimmungsnetz entgegen. Das erste Paket ist bereits angekommen. Paket 3 kommt vor Paket 2 am Ziel an.
Die Pakete 1, 2 und 3 sind - in falscher Reihenfolge - am Zielrechner angekommen. Auf der Strecke, auf der Pakete 4 und 5 transportiert werden, tritt eine Störung auf.
	Paket 4 ist bei der Störung verloren gegangen. Paket 5 wird auf einer anderen Route zum Zielnetz geschickt (wären die Routen statisch am Router eingetragen, ginge auch Paket 5 verloren).
Alle überlebenden Pakete sind am Zielrechner angekommen. Das TCP-Protokoll setzt die Pakete wieder in der richtigen Reihenfolge zusammen und fordert das fehlende Paket 4 nochmals beim Sender an. Für den Empfänger ergibt sich ein kontinuierlicher Datenstrom.

TCP-Zustandsübergangsdiagramm

Erklärung der Zustände:

• LISTEN: Warten auf ein Connection Request.
• SYN-SENT: Warten auf ein passendes Connection Request, nachdem ein SYN gesendet wurde.
• SYN-RECEIVED: Warten auf Bestätigung des Connection Request Acknowledgement, nachdem beide Teilnehmer ein Connection Request empfangen und gesendet haben.
• ESTABLISHED: Offene Verbindung.
• FIN-WAIT-1: Warten auf ein Connection Termination Request des Kommunikationspartners oder auf eine Bestätigung des Connection Termination, das vorher gesendet wurde.
• FIN-WAIT-2: Warten auf ein Connection Termination Request des Kommunikationspartners.
• CLOSE-WAIT: Warten auf ein Connection Termination Request (CLOSE) der darüberliegenden Schicht.
• CLOSING: Warten auf ein Connection Termination Request des Kommunikationspartners. LAST-ACK: Warten auf die Bestätigung des Connection Termination Request, das zuvor an den Kommunikationspartner gesendet wurde.

Zeitüberwachung

Paketwiederholungs-Wecker oder Retransmission Timeout

SRTT:     S = aS + (1 - a)R
RTO:      T = min[U, max[L,ßS]]
          (L < T < U)

Die beiden Formeln werden durch den RFC 793 spezifiziert: zunächst den SRTT-Filter, danach die Ermittlung des RTO. Falls nach der Wiederholung des Pakets der Wiederholungstimer ein weiteres Mal abläuft, wird der RTO in der Regel bis zu zwölfmal exponentiell erhöht. Erst wenn auch diese Erhöhung keinen Effekt zeigt, gilt die Verbindung als unterbrochen.

Persistance Timer

Stillhaltezeit oder Quiet Time

Keep Alive Timer und Idle Timer

Algorithmen zur Steigerung der Effizienz

Acknowledgement Delay

Silly Window Syndrome Avoidance

Nagle Algorithmus oder Small Packet Avoidance

Slow Start with Congestion Avoidance

Ports für jeden Dienst

• Die Portnummern werden auf dem Host-System konfiguriert und haben zwei Funktionen:
  • Allgemein verfügbare Dienste werden über 'well known' Ports (--> feste, per RFC zugeordnete Portnummer) erreichbar. Sie stehen also für ein Protokoll, das über die Nummer direkt angesprochen wird
  • oder sie werden beim Verbindungsaufbau vereinbart und einem Server-Programm zugewiesen
• Die Portangabe ist nötig, wenn mehrere Serverprogramme auf dem adressierten Rechner laufen.
• Die Portnummer steht im TCP-Header und ist 16 Bit groß. Theoretisch können also bis zu 65535 TCP-Verbindungen auf einem Rechner mit einer einzigen IP-Adresse aufgebaut werden.
• Portnummern werden oft auch bei der Konfiguration von Internet-Clients als Parameter gefordert.
• Die Client-Prozesse verwenden normalerweise freie Portnummern, die vom lokalen Betriebssystem zugewiesen werden (Portnummer > 1024).

Die "well known" Portnummern (0 bis 1023), die weltweit eindeutig adressiert werden müssen, werden durch die IANA (Internet Assigned Numbers Authority) vergeben. Einige Beispiele für TCP-Ports (UDP verwendet eine andere Zuordnung):

Eine vollständige Portliste erhält man bei http://www.isi.edu/in-notes/iana/assignments/port-numbers.

IP-Adresse und Portnummer definieren einen Kommunikationsendpunkt, der in der TCP/IP-Welt "Socket" genannt wird. Die Grenze zwischen der Anwendungsschicht und der Transportschicht ist in den meisten Implementierungen zugleich die Grenze zwischen dem Betriebssystem und den Anwendungsprogrammen. Im OSI-Modell ist diese Grenze in etwa die Grenze zwischen den Schichten 4 und 5. Daher ordnet man IP meist ungefähr in die Ebene 3 und TCP ungefähr in Ebene 4 des OSI-Modells ein. Da TCP/IP jedoch älter und einfacher als das OSI-Modell ist, kann diese Einordnung nicht genau passen.

Port-Scans

• TCP-Connect-Scan
  Bei dieser Methode wird versucht, eine Verbindung zu einem Port auf dem Zielrechner aufzubauen. Der Scanner läßt einen vollständigen Dreiwege-Handshake zu, bevor er die Verbindung wieder unterbricht. Diese Art der Scans ist allerdings sehr leicht zu entdecken und kann auch leicht mit Hilfe von Firewalls abgeblockt werden.

• TCP-SYN-Scan
  Diese Methode wird oft als "Half-Open-Scan" bezeichnet. Der Scanner sendet ein SYN-Packet an den Zielrechner, wie bei einem ganz normalen Verbindungsaufbau. Wenn der Zielrechner mit einem RST antwortet, weiß der Scanner, daß dieser Port geschlossen ist. Antwortet der Zielrechner jedoch mit einem SYN/ACK, handelt es sich um einem offenen Port. In diesem Falle wird die Verbindung vom Scanner sofort mit einem RST beendet. Diese Art des Scannens ist nicht ganz so leicht auf dem Zielrechner zu entdecken wie der Connect Scan.

• Stealth FIN-Scan
  Stealth Scans sollen vom Zielrechner nicht entdeckt werden. Allerdings gibt es Programme, die genau solche Scans entdecken. Beim "Stealth FIN Scan" wird nur ein Packet mit einem FIN-Flag, ohne begleitendes ACK-Flag gesendet. Diese Art von Paket ist unzulässig. Wenn der Port offen ist, wird das Paket des Scanners vom Zielrechner ignoriert. Wenn der Port geschlossen ist, antwortet der Zielrechner mit einem RST-Paket.

• Stealth Xmastree-Scan
  Bei diesem Scan sind die FIN-, URG-, und PUSH-Flags alle gemeinsam gesetzt. Auch dieses Paket ist unzulässig. Wenn der Port offen ist, wird das Paket des Scanners vom Zielrechner ignoriert. Wenn der Port geschlossen ist, antwortet der Zielrechner mit einem RST-Paket.

• Stealth Null-Scan
  Bei diesem Scan sind alle Flags auf Null gesetzt. Alles Weitere wie oben.

• ACK-Scan
  Dieser Scan wird verwendet, um Firewalls zu testen ob sie mit "stateful inspection" arbeiten (z.B. Firewall 1) oder ob es sich nur um einfache Packetfilter handelt, die eingehende SYN Packete verwerfen. Der ACK-Scan sendet ein Packet mit gesetztem ACK-Flag und zufälliger Sequenznummer an die Ports. Wenn das Paket von der Firewall durchgelassen wird, sendet der Server ein RST, da das Paket nicht zuzuordnen ist. In diesem Fall wird der Port als "ungefiltert" klassifiziert. Wenn die Firewall den Status einer Verbindung überwacht, wird das Paket ohne eine Antwort vom Zielrechner abgewiesen oder es wird dem Scanner mit einer ICMP Destination unreachable Nachricht geantwortet.

PPP

• Das Data Link Layer Protocol ermöglicht die Übertragung (Encapsulation) von Datagrammen über serielle Verbindungen mit Hilfe von HDLC.
• Das Link Control Protocol (LCP) steuert Aufbau, Konfiguration und Test der Verbindung.
• Das Network Control Protocol (NCP) ermöglicht die Übertragung von Konfigurationsdaten für verschiedene Protokolle der Vermittlungsschicht.

PPP ist ein verbindungsorientiertes Protokoll und unterscheidet drei Phasen Verbindungsaufbau, Datenübertragung und Verbindungsabbau. Die Realisierung dieser Phasen unter Berücksichtigung der Teilprotokolle von PPP zeigt das Bild unten.

1. Der anrufende PPP-Knoten sendet LCP-Rahmen zum Aufbau und zur Konfiguration der Verbindung (Data Link). Die LCP-Pakete verfügen über ein Feld mit Konfigurations-Optionen. Zu diesen Optionen zählen beispielsweise die Maximum Transmission Unit (MTU). Hierbei handelt es sich um die Angabe, ob bestimmte PPP-Felder komprimiert werden, oder das Link Authentication Protocol (LAP).
2. In einer optionalen Phase wird überprüft, ob die Qualität der Verbindung für den Aufbau einer Übertragung der Pakete der Vermittlungsschicht ausreicht.
3. Es folgt eine Authentifizierungsphase.
4. Der anrufende PPP-Knoten sendet NCP-Rahmen zur Auswahl und Konfiguration des zu übertragenden Protokolls der Vermittlungsschicht.
5. Nun können die Daten übertragen werden.
6. Die Verbindung bleibt bis zur Beendigung durch LCP- oder NCP-Rahmen bestehen oder bis ein externes Ereignis auftritt. Zu diesen kann eine Unterbrechung durch den Anwender, der Abbruch der Übertragung oder der Ablauf eines "Inactivity Timers" zählen.

PPP unterstützt verschiedene Protokolle zur Authentifizierung. Dabei realisieren alle Protokolle nur eine einseitige Authentifizierung. Dies bedeutet, dass sich der anrufende Knoten bzw. dessen Anwender authentifizieren und der angerufene Knoten diese Authentifizierung überprüfen muss. Der angerufene Knoten authentifiziert sich durch seine Verfügbarkeit unter dieser physischen Verbindung. Die wichtigsten Authentifizierungsprotokolle sind:

• das Password Authentication Protocol (PAP),
• das Shiva Password Authentication Protocol(SPAP),
• das Challenge Handshake Authentication Protocol (CHAP) sowie
• eine Variante des CHAP, das Microsoft-CHAP (MS-CHAP), das in zwei Versionen vorliegt.

Die Authentifzierungsprotokolle mit der größten Verbreitung sind PAP und CHAP. Auch MS-CHAPv2 ist recht häufig anzutreffen. Die meisten ISPs fragen beim einwählenden Host zunächst CHAP an.

PAP unterstützt ein so genanntes Zwei-Wege-Handshake. Die Kombination "Username/Password" wird vom anrufenden Knoten so lange übertragen, bis die Authentifizierung bestätigt oder abgelehnt wird. Im Falle der Ablehnung wird die Verbindung abgebrochen. Dieses Vorgehen bietet allerdings nur eine geringe Sicherheit: Das Passwort wird unverschlüsselt übertragen. Es ist eine beliebige Anzahl von Wiederholungen möglich. Und schließlich werden Häufigkeit und Geschwindigkeit der Versuche vom anrufenden Knoten bestimmt, so dass ein Brute-Force-Angriff möglich wird.

CHAP bietet ein erhöhtes Sicherheitsniveau im Rahmen eines so genannten Drei-Wege-Handshakes. Der anrufende Knoten darf erst die Authentifizierung beginnen, wenn er vom angerufenen Knoten dazu aufgefordert wurde. Auf diese Weise werden Häufigkeit und Geschwindigkeit der Versuche vom angerufenen Knoten bestimmt. Zusätzlich wird die Kombination "Username/Password" nur im Rahmen einer Ein-Wege-Hash-Funktion (Message Digest 5, MD5) übertragen. Die Überprüfung kann also nicht nur beim Verbindungsaufbau, sondern auch periodisch während der Verbindung stattfinden.

IP Next Generation

Das rasche (exponentielle Wachstum) des Internet zwingt dazu, das Internet Protokoll in der Version 4 (IPv4) durch ein Nachfolgeprotokoll (IPv6 Internet Protocol Version 6) zu ersetzen.

Vinton Cerf (der 'Vater' des Internet) bezeichnet in einem Interview mit der Zeitschrift c't das Internet "(...) als die wichtigste Infrastruktur für alle Arten von Kommunikation.". Auf die Frage, wie man sich die neuen Kommunikationsdienste des Internet vorstellen könne, antwortete Cerf:

"Am spannendsten finde ich es, die ganzen Haushaltsgeräte ans Netz anzuschließen. Ich denke dabei nicht nur daran, daß der Kühlschrank sich in Zukunft mit der Heizung austauscht, ob es in der Küche zu warm ist. Stromgesellschaften könnten beispielsweise Geräte wie Geschirrspülmaschinen kontrollieren und ihnen Strom genau dann zur Verfügung stellen, wenn gerade keine Spitzennachfrage herrscht. Derartige Anwendungen hängen allerdings davon ab, daß sie zu einem erschwinglichen Preis angeboten werden. Das ist nicht unbedingt ferne Zukunftsmusik; die Programmierer müßten eigentlich nur damit anfangen, endlich Software für intelligente Netzwerkanwendungen zu schreiben. Und natürlich muß die Sicherheit derartiger Systeme garantiert sein. Schließlich möchte ich nicht, daß die Nachbarkinder mein Haus programmieren!"

Auf die Internet Protokolle kommen in der nächsten Zeit also völlig neue Anforderungen zu.

Classless InterDomain Routing - CIDR

Der Verknappung der Internet-Adressen durch die ständig steigende Benutzerzahl wird zunächst versucht, mit dem Classless Inter-Domain Routing (CIDR) entgegen zu wirken. Durch die Vergabe von Internet-Adressen in Klassen (A,B,C,...) wird eine große Anzahl von Adressen verschwendet. Hierbei stellt sich vor allem die Klasse B als Problem dar. Viele Firmen nehmen ein Netz der Klasse B für sich in Anspruch, da ein Klasse A Netz mit bis zu 16 Mio. Hosts selbst für eine sehr große Firma überdimensioniert scheint, ein Netz der Klasse C mit 254 Hosts aber zu klein.

Ein größerer Host-Bereich für Netze der Klasse C (z. B. 10 Bit, 1022 Hosts pro Netz) hätte das Problem der knapper werdenden IP-Adressen vermutlich gemildert. Ein anderes Problem wäre dadurch allerdings entstanden: die Einträge der Routing-Tabellen hätten sich um ein Vielfaches vermehrt.

Ein anderes Konzept ist das Classless Inter-Domain Routing (RFC 1519): die verbleibenden Netze der Klasse C werden in Blöcken variabler Größe zugewiesen. Werden beispielsweise 2000 Adressen benötigt, so können einfach acht aufeinanderfolgende Netze der Klasse C vergeben werden. Zusätzlich werden die verbliebenen Klasse-C-Adressen restriktiver und strukturierter vergeben (RFC 1519). Die Welt ist dabei in vier Zonen aufgeteilt, von denen jede einen Teil des verbliebenen Klasse C Adreßraums erhält:

Jede der Zonen erhält dadurch in etwa 32 Millionen Adressen zugewiesen. Vorteil bei diesem Vorgehen ist, daß die Adressen einer Region im Prinzip zu einem Eintrag in den Routing-Tabellen komprimiert worden sind und jeder Router, der eine Adresse außerhalb seiner Region zugesandt bekommt diese getrost ignorieren darf.

Internet Protokoll Version 6 - IPv6 (IP Next Generation, IPnG)

• Unterstützung von Milliarden von Hosts, auch bei ineffizienter Nutzung des Adreßraums
• Reduzierung des Umfangs der Routing-Tabellen
• Vereinfachung des Protokolls, damit die Router Pakete schneller abwickeln können
• Höhere Sicherheit (Authentifikation und Datenschutz) als das heutige IP
• Mehr Gewicht auf Dienstarten, insbesondere für Echtzeitanwendungen
• Unterstützung von Multicasting durch die Möglichkeit, den Umfang zu definieren
• Möglichkeit für Hosts, ohne Adreßänderung auf Reise zu gehen (Laptop)
• Möglichkeit für das Protokoll, sich zukünftig weiterzuentwickeln
• Unterstützung der alten und neuen Protokolle in Koexistenz für Jahre

Als die Entwickler mit den Arbeiten an der neuen Version des Internet Protokolls begannen, wurde ein Name für das Projekt bzw. das neue Protokoll benötigt. Angeregt durch die Fernsehserie "Star Trek - Next Generation", wurde als Arbeitsname IP - Next Generation (IPnG) gewählt. Schließlich bekam das neue IP eine offizielle Versionsnummer zugewiesen: IP Version 6 oder kurz IPv6. Die Protokollnummer 5 (IPv5) wurde bereits für ein experimentelles Protokoll verwendet.

Die Merkmale von IPv6

• Adreßgröße: Statt bisher 32 Bit stehen nun 128 Bit für die Adressen bereit. Theoretisch lassen sich damit 2¹²⁸ = 3.4*10³⁸ Adressen vergeben.
• Header-Format: Der IPv6-Header wurde vollständig geändert. Der Header enthält nur sieben statt bisher 13 Felder. Diese Änderung ermöglicht die schneller Verarbeitung der Pakete im Router. Im Gegensatz zu IPv4 gibt es bei IPv6 nicht mehr nur einen Header, sondern mehrere Header. Ein Datengramm besteht aus einem Basis-Header, sowie einem oder mehreren Zusatz-Headern, gefolgt von den Nutzdaten.

  

• Erweiterte Unterstützung von Optionen und Erweiterungen: Die Erweiterung der Optionen ist notwendig geworden, da einige der bei IPv4 notwendige Felder nun optional sind. Darüber hinaus unterscheidet sich auch die Art, wie die Optionen dargestellt werden. Für Router wird es damit einfacher, Optionen, die nicht für sie bestimmt sind, zu überspringen.
• Dienstarten: IPv6 legt mehr Gewicht auf die Unterstützung von Dienstarten. Damit kommt IPv6 den Forderungen nach einer verbesserten Unterstützung der Übertragung von Video- und Audiodaten entgegen, z. B. durch eine Option zur Echtzeitübertragung.
• Sicherheit: IPv6 beinhaltet nun im Protokoll selbst Mechanismen zur sicheren Datenübertragung. Wichtige neue Merkmale von IPv6 sind hier Authentifikation, Datenintegrität und Datenverlässlichkeit.
• Erweiterbarkeit: IPv6 ist ein erweiterbares Protokoll. Bei der Spezifikation des Protokolls wurde nicht versucht, alle möglichen Einsatzfelder für das Protokoll in die Spezifikation zu integrieren. Über Erweiterungs-Header kann das Protokoll erweitert werden.

Aufbau des IPv6-Basis-Headers

Version:

Mit dem Feld Version können Router überprüfen, um welche Version des Protokolls es sich handelt. Für ein IPv6-Datengramm ist dieses Feld immer 6 und für ein IPv4-Datengramm dementsprechend immer 4. Mit diesem Feld ist es möglich für eine lange Zeit die unterschiedlichen Protokollversionen IPv4 und IPv6 nebeneinander zu verwenden. Über die Prüfung des Feldes Version können die Daten an das jeweils richtige "Verarbeitungsprogramm" weitergeleitet werden.

Priority:

Durch das Feld Priority (oder Traffic Class) kann angegeben werden, ob ein Paket bevorzugt behandelt werden muß. Dies ist für die Anpassung des Protokolls an die neuen Real Time Anwendungen nötig geworden. Damit können zum Beispiel Videodaten den E-Maildaten vorgezogen werden. Bei einem Router unter Last besteht damit die Möglichkeit der Flusskontrolle. Pakete mit kleinerer Priorität werden verworfen und müssen wiederholt werden.Mit den vier Bit lassen sich 16 Prioritäten angeben, wovon 1 bis 7 für "Non Real Time"- und 8 bis 15 für "Real Time"-Anwendungen reserviert sind. Die Zahl Null gibt an, dass die Priorität des Verkehrs nicht charakterisiert ist.

Flow Label

Mit Hilfe des Feldes Flow Label können Eigenschaften des Datenflusses zwischen Sender und Empfänger definiert werden. Das Flow Label selbst ist nur eine Zufallszahl. Die Eigenschaften müssen durch spezielle Protokolle oder durch den Hop-by-Hop-Header in den Routern eingestellt werden. Eine Anwendung ist zum Beispiel, daß die Pakete eines Flusses immer den gleichen Weg im Netz nehmen. Durch Speichern der Informationen für das jeweilige Flow-Label, muß der Router bestimmte Berechnungen nur für das erste Paket ausführen, und kann danach für alle Folgepakete die Resultate verwenden. Erst die Einführung des Flow Labels ermöglicht die Einführung von Quality-of-Service-Parametern im IP-Verkehr.

Payload Length

Das Feld Payload Length (Nutzdatenlänge) gibt an, wie viele Bytes dem IPv6-Basis-Header folgen, der IPv6-Basis-Header ist ausgeschlossen. Die Erweiterungs-Header werden bei der Berechnung der Nutzdatenlänge mit einbezogen. Das entsprechende Feld wird in der Protokollversion 4 mit Total Length bezeichnet. Allerdings bezieht IPv4 den 20 Byte großen Header auch in die Berechnung ein, wodurch die Bezeichnung "total length" gerechtfertigt ist.

Next Header

Das Feld Next Header gibt an, welcher Erweiterungs-Header dem IPv6-Basis-Header folgt. Jeder folgende Erweiterungs-Header beinhaltet ebenfalls ein Feld Next Header, das auf den nachfolgenden Header verweist. Beim letzten IPv6-Header, gibt das Feld an, welches Transportprotokoll (z.B. TCP oder UDP) folgt.

Hop Limit

Im Feld Hop Limit wird festgelegt, wie lange ein Paket überleben darf. Der Wert des Feldes wird von jedem Router vermindert. Ein Datengramm wird verworfen, wenn das Feld den Wert Null hat. IPv4 verwendete hierzu das Feld Time to Live. Die Bezeichnung bringt mehr Klarheit, da schon in IPv4 die Anzahl Hops gezählt und nicht die Zeit gemessen wurde.

Source Address, Destination Address

Die beiden Felder für Quell- und Zieladresse dienen zur Identifizierung des Senders und Empfängers eines IP-Datengramms. Bei IPv6 sind die Adressen vier mal so groß wie IPv4: 128 Bit statt 32 Bit.

Das Feld Length (Internet Header Length - IHL) von IPv4 ist nicht mehr vorhanden, da der IPv6-Basis-Header eine feste Länge von 40 Byte hat. Das Feld Protocol wird durch das Feld Next Header ersetzt. Alle Felder die bisher zur Fragmentierung eines IP-Datengramms benötigt wurden (Identification, Flags, Fragment Offset), sind im IPv6-Basis-Header nicht mehr vorhanden, da die Fragmentierung in IPv6 gegenüber IPv4 anders gehandhabt wird. Alle IPv6-kompatiblen Hosts und Router müssen Pakete mit einer Größe von 1280 Byte unterstützen. Empfängt ein Router ein zu großes Paket, so führt er keine Fragmentierung mehr durch, sondern sendet eine Nachricht an den Absender des Pakets zurück, in der er den sendenden Host anweist, alle weiteren Pakete zu diesem Ziel aufzuteilen. Es wird also vom Hosts erwartet, daß er von vornherein eine passende Paketgröße wählt. Die Steuerung der Fragmentierung erfolgt bei IPv6 über den Fragment Header. Das Feld Checksum ist nicht mehr vorhanden.

Erweiterungs-Header im IPv6

Derzeit sind sechs Erweiterungs-Header definiert. Alle Erweiterungs-Header sind optional. Werden mehrere Erweiterungs-Header verwendet, so ist es erforderlich, sie in einer festen Reihenfolge anzugeben.

IPv6-Adressen

  xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx

• Führende Nullen
  Die führenden Nullen können mit Nullen oder Doppelpunkten zusammengefasst werden.

  1234:0000:0000:0000:0000:0000:0000:1234
                    -->
           1234:0:0:0:0:0:0:1234
                    -->
                 1234::1234
  

• IPv4 kompatible Adressen haben die Form:

  0:0:0:0:0:0:C206:AFFE
        oder
  ::C206:AFFE
  

  Um die Lesbarkeit zu erhöhen kann man auch eine gemischt Form verwenden:

  ::196.6.175.254
  

• IPv4 gemappte IPv6 Adressen haben die Form:

  ::FFFF:C206:A17E
  

• Die Loopback Adresse ist neu (anstelle 127.0.0.1):

  ::1
  

In IPv4 wurden die Adressen anfänglich in die bekannten Klassen eingeteilt. Ein weiteres Problem bei den IPv4 Adressen ist, daß die Router keine Hierarchie in den Adressen erkennen können. Auch IPv6 ist in der allgemeinen Form unstrukturiert, es kann aber durch definierte Präfixe strukturiert werden. Die allgemein strukturiert Adresse sieht danach wie folgt aus:

Die Strukturierung erlaubt die Einteilung der Adresse in Adresstypen. Jeder Präfix identifiziert somit einen Adresstyp. Die bereits definierten Adresstypen und die zugehörigen Präfixe sind:

Wie man in der Tabelle erkennen kann, werden die Adressen grob in die Typen Unicast, Multicast und Anycast eingeteilt, deren Eigenschaften nachfolgend kurz erklärt werden sollen.

• Unicast
  Als Unicast-Adressen bezeichnet man die Adressen, die für Punkt-zu-Punkt-Verbindungen verwendet werden. Sie werden in verschiedene Gruppen eingeteilt:
  • Geographisch basierte Unicast-Adresse
    Für diese Adressen wurde erst der Adressbereich und der Präfix reserviert. Die Idee ist, dass ein hierarchisches Routing aufgrund der geographischen Lage - ähnlich wie beim Telefon - möglich sein soll.
  • Anbieterbasierte Unicast-Adressen
    Dieser Adresstyp erlaubt ein hierarchisches Routing aufgrund der Adressräume der Anbieter. Diese Adressen werden von einem Register über ein großes Gebiet verwaltet. Diese Register geben die Adressen an die Anbieter weiter, welche ihrerseits Adressen weitergeben können. Somit ergibt sich eine Adress-Struktur, die wie folgt aussieht:

    

    Die Einführung von nationalen Registern ergibt eine Aufteilung der Anbieter- und Subscriber-ID in National-Register-, Anbieter- und Subscriber-ID.

• Linklokale und standortlokale Adressen
  Diese Adressen werden für die TCP/IP-Dienste innerhalb eines Unternehmens genutzt. Die Linklokalen Adressen werden nicht in das Internet geroutet und haben den folgenden Aufbau:

  

  Im Gegensatz dazu stehen die standortlokalen Adressen, die nur innerhalb eines Subnetzes gültig sind und deshalb von keinem Router behandelt werden.

  

• Multicast-Adressen
  In IPv4 wird das Rundsenden eines Paketes an mehrere Stationen durch das IGMP (Internet Group Management Protokoll) realisiert. In IPv6 ist das Prinzip übernommen, aber ein eigener Adresstyp definiert worden. IGMP entfällt somit gänzlich. Das Paket für Multicast-Meldungen sieht wie folgt aus:

  

  Das Flag gibt an, ob die Gruppen ID temporär, oder von der IANA zugewiesen ist. Der Scope gibt den Gültigkeitsbereich der Multicast Adresse an. Dieser reicht vom nodelokalen bis zum globalen Bereich.

• Anycast Adressen
  Diese Adressen sind neu definiert worden. es können mehrere Rechner zu einer Gruppe zusammengefasst werden und sie sind dann unter einer einzigen Adresse erreichbar. Damit ist beispielsweise eine Lastverteilung möglich: der Rechner, der am wenigsten belastet ist, behandelt das Paket. Die Adresse hat die folgende Struktur:

  

Sicherheit

Authentisierungsmechanismen liefern den Beweis auf Unverfälschtheit der Nachricht und identifiziert den Absender (Digitale Unterschrift). Hier werden verschiedene kryptographische Verfahren eingesetzt. Die Verfahren für die Verschlüsselung und die Authentisierung können auch getrennt angewandt werden. Verwaltung und Verteilung der Schlüssel wird nicht von IPv6 gelöst. Das Standardverfahren für den IPv6-Authentisierungsmechanismus ist MD5 mit 128 Bit langen Schlüsseln. IPv6 schreibt keinen Verschlüsselungsmechanismus vor, jedes System im Internet muß jedoch den DES mit CBD (Cipher Block Chaining) unterstützen.

Domain Name System (DNS)

Beim "Domain-Name-System" (oder kurz: DNS) handelt es sich um einen Dienst, der zu einem Rechnernamen die zugehörige IP-Nummer liefert und umgekehrt. Das ist in etwa mit der Funktionsweise einer Telefonauskunft vergleichbar: Der Kunde ruft bei einer bestimmten Telefonnummer an und fragt nach der Rufnummer eines Teilnehmers. Nachdem er Name und Wohnort der gesuchten Person durchgegeben hat, erhält er als Antwort die gewünschte Nummer aus einem Verzeichnis. Genauso läuft eine DNS-Abfrage ab.

http://www.VereinGegenZuLangeDomainnamenEV.de

ein, dann sorgt ein Teil der Netzwerk-Software auf seinem lokalen Rechner dafür, daß ein Name-Server nach der IP-Adresse des Rechners www.vereingegenzulangedomainnamenev.de gefragt wird. Dieser Softwareteil wird als Resolver bezeichnet und entspricht in obigem Beispiel dem Kunden, der die Auskunft anruft. Welche IP-Adresse dieser Server hat, muß dem Klientenrechner natürlich bekannt sein, genauso wie der Kunde eine einzige Telefonnummer wissen muß, nämlich die der Auskunft selbst. Auf der Serverseite arbeitet eine Software, die als "Domain-Name-Server" oder kurz "Name-Server" bezeichnet wird und anhand einer Datenbank ("Zone-File") die passende IP-Nummer zum Rechnernamen liefert, oder einen anderen Name-Server fragt, wenn die Adresse unbekannt ist.

• Strukturierung der Namen. (Domänen-Konzept)
• Zuteilung und Verwaltung von Namen.
• Auflösen von Namen (="Nachschlagen") in beide Richtungen (Name zu Adresse und Adresse zu Name)
• Zwischenspeichern von Adressen (Caching)
• Einteilung der Daten in hierarchische Ebenen
• Verteilung der Daten auf verschiedene Knoten
• Bereitstellung von Redundanz (Secondary-DNS, Caching-Only-Server)

Domänen-Konzept

B ~ N²

Als Relikt aus dieser Zeit kennt fast jedes Betriebssystem auch heute noch eine Hosts-Datei, in der für kleine Netze Rechner/Nummern-Zuordnungen abgelegt werden könen. (Bei Windows im Verzeichnis \WINDOWS\HOSTS, bei Unix unter /etc/hosts, bei Novell unter SYS:SYSTEM/ETC/HOSTS, etc.) Die Syntax aller dieser Hosts-Dateien ist einfach. Für jeden Rechner gibt es eine eigene Zeile mit dem Inhalt:

IP-Nummer	Hostname Alias Alias ....

192.168.112.1    chef dumpfbacke
192.168.112.2    Snow-White
192.168.112.3    Doc
192.168.112.4    Happy
192.168.112.5    Bashful
192.168.112.6    Sneezy
192.168.112.7    Sleepy
192.168.112.7    Grumpy
192.168.112.8    Dopey

Bei einer kleinen Menge von Rechnern ist die Namensverwaltung mit einer Datei noch möglich; für einen so großen und ständig wechselnden Verbund wie das Internet ist sie aber nicht geeignet. Hier ist eine dezentrale Verwaltung mit einem eigens darauf abgestimmten Namensraum nötig.

Der Namensraum des DNS ist in sogenannte Domänen eingeteilt. Die Domänen sind hierarchisch als Baum angeordnet,

Ausgehend von der Wurzel (=Root) des Baumes ist der Namensraum in sogenannte "Toplevel-Domains" eingeteilt. Man unterscheidet dabei zwischen zwei verschiedenen Klassen von Toplevel-Domänen: Den generischen und den länderspezifischen.

Unterhalb der Toplevel-Domänen folgen Subdomänen, die wiederum Domänen enthalten könen und schliesslich, als Blatt des Baumes, ein einzelner Rechner. Der Name www.netzmafia.de ist also so zu verstehen. In der Toplevel-Domäne ".de" ist die Subdomain "Netzmafia" bekannt. Innerhalb der Subdomain "netzmafia" gibt es einen Rechner namens "www". Analog zu unserem Beispiel mit der Telefonauskunft, ist mit "de" das Land, mit "netzmafia" der Ort und die Straße und mit "www" der Name eines Teilnehmers bestimmt. Die komplette Adresse eines Rechners in der beschriebenen Notation, z.B. bezeichnet man (www.netzmafia.de) als FQDN (Full-Qualified-Domain-Name).

Für die Aufnahme einer Verbindung zwischen zwei Rechnern muß in jedem Fall der Rechnername in eine zugehörige IP- Adresse umgewandelt werden. Aus Sicherheitsaspekten ist es manchmal wünschenswert, auch den umgekehrten Weg zu gehen, nämlich zu einer sich meldenden Adresse den Namen und damit die organisatorische Zugehörigkeit offenzulegen.

Komponenten des DNS

1. Der Domain Name Space, ein baumartig, hierarchisch strukturierter Namensraum und die Resource Records. Das sind Datensätze, die den Knoten zugeordnet sind.
2. Name Server sind Programme bzw. Rechner, die die Informationen über die Struktur des Domain Name Space verwalten und aktualisieren. EinNameserver hat normalerweise nur eine Teilsicht des Domain Name Space zu verwalten. Oft wird auch der Rechner, auf dem das Nameserverprogramm läuft, als 'Nameserver' oder 'DNS-Server' bezeichnet.
3. Resolver sind die Programme, die für den Client Anfragen an den Nameserver stellen. Resolver sind einemNameserver zugeordnet; bei Anfragen, die er nicht beantworten kann (anderer Teilbereich des Domain Name Space). kann er aufgrund von Referenzen andere Nameserver kontakten, um die Information zu erhalten.

Der Nameserver des DNS verwaltet also einzelne Zonen, die einen Knoten im DNS-Baum und alle darunterliegenden Zweige beinhalten. Auf jeder Ebene des DNS-Baums kann es Namesever geben, wobei jeder Nameserver seinen nächsthöheren und nächstniedrigeren Nachbarn kennt. Aus Sicherheitsgründen gibt es für jede Zone in der Regel mindestens zwei Nameserver (primary und secondary), wobei beide die gleiche Information halten. Nameservereinträge können nicht nur die Zuordnung Rechnername - IP-Adresse enthalten, sondern (neben anderem) auch weitere Namenseinträge für einen einzigen Rechner und Angaben für Postverwaltungsrechner einer Domain (MX, mail exchange).

Basis des Nameservice bilden die "Root-Nameserver", die für die Top-Level-Domains zuständig sind. Federführende Organistation ist hier die ICANN (=Internet Corporation for Assigned Names and Numbers , Adresse: http://www.icann.org). Gründung 1998. ICANN beauftragt die Verwalter der Zone "." (Wurzel des DNS-Baumes) mit 13 Servern. Bis auf die Server I (Stockholm), K (London) und M (Tokio) stehen alle Server in den USA.

Der Server A ist der primäre Server, alle anderen sind seine Secondaries. Eine Liste dieser Root-Server muss jeder DNS-Server haben (Ausnahme: Cache-Only-Server). Erzeugung der Liste mit dem Kommando:

dig @rs.internic.net . ns > root.servers

Die Namen, die im Internet verwendet werden müssen dabei einige Spezifikationen erfüllen:

• Die Länge eines Namensteiles (Domänen- oder Rechnername) darf maximal 63 Zeichen betragen.
• Die Gesamtlänge des Full-Qualified-Domain-Names darf 255 Zeichen nicht überschreiten.
• Nur Buchstaben, Ziffern und "-" sind in den Namen zugelassen. Dabei muss jeder Name mit einem Buchstaben oder einer Ziffer beginnen und enden. ("3bla-fasel" ist zulässig, "3bla-" aber nicht.)
• Zwischen Groß- und Kleinschreibung wird nicht unterschieden.
• Die Domains "example.com" und "example.net" sind für Dokumentationen vorgesehen und werden nicht vergeben.

• Der Domainname muß mindestens 3 Zeichen haben. Insgesamt gibt es in ".de" noch 4 Domains mit nur 2 Buchstaben, die aus Besitzstands-Gründen beibehalten werden.
• Wegen eines weit verbreiteten Fehlers in der Named-Server-Software sind Domains mit den gleichen Namen wie Toplevel-Einträge verboten. (Also z.B.: "at.de") Das ist in RFC 1535 näher beschrieben.
• KFZ-Kennzeichen können nicht registriert werden.

Ein wichtiger Bestandteil des DNS-Konzeptes ist die Aufteilung der benötigten Datenbank auf viele verschiedene Rechner. Da das Gesamtsystem voll funktionsfähig bleiben muß, auch wenn ein Server ausgefallen ist, wird die Datenhaltung mit Hilfe von Zuständigkeiten gelöst: Zu jeder Domain gibt es mindestens einen zugehörigen Server, der verantwortlich die darin enthaltenen Subdomains oder Rechner verwaltet, oder die Verwaltung an einen weiteren Server weiterdelegiert. Am Stamm des DNS-Baumes sitzen dazu die "Root-Server", die alle Einträge ihrer jeweiligen Domain kennen. Das heißt, daß der Root-Nameserver der Domäne ".de" einen Eintrag für den Named-Server der Domain "netzmafia.de" besitzt. Dieser Server hat wieder eine Liste der in "netzmafia.de" enthaltenen Rechner und Subdomains.

Die Frage eines Clients nach der IP-Nummern eines Rechners wird wie folgt abgewickelt:

1. Der Client-Rechner "grumpy.zwerge.org" stellt die DNS-Anfrage nach "www.netzmafia.de" an seinen zuständigen DNS-Server. Dessen IP-Nummer muss dem Client bekannt sein.
2. Kennt der Nameserver der Domain "zwerge.org" die Antwort nicht, so erkundigt er sich beim Root-Nameserver nach der Adresse des Nameservers von ".de"
3. Der Root-Nameserver antwortet dem zuständigen DNS-Server der Domain "zwerge.org" mit der Adresse des Nameservers von ".de"
4. Der Nameserver der Domain "zwerge.org" erkundigt sich beim Nameserver von ".de" nach der Adresse des Nameservers von "netzmafia.de".
5. Der Nameserver von ".de" antwortet dem zuständigen DNS-Server der Domain "zwerge.org" mit der Adresse des Nameservers von "netzmafia.de"
6. Der Nameserver der Domain "zwerge.org" erkundigt sich beim Nameserver von "netzmafia.de" nach der Adresse des Rechners "www.netzmafia.de".
7. Der Nameserver von "netzmafia.de" antwortet dem zuständigen DNS-Server der Domain "zwerge.org" mit der Adresse des Rechners von "www.netzmafia.de".
8. Der DNS-Server von "zwerge.org" liefert die IP-Nummer an den anfragenden Client. Damit ist die DNS-Abfrage abgehandelt.

DNS-Typen

• Cache-Only
  • Besitzt keine eigenen Tabellen mit Rechnernamen (Zone-Files).
  • Alle Anfragen werden an einen übergeordneten Server weitergegeben.
  • Adressen werden zwischengespeichert.
  • Zweck: Z.B. Entlastung einer Providerleitung
  • Sehr einfach einzurichten.
• Secondary-DNS
  • Besitzt eigene Tabellen, die er vom Primary-DNS kopiert.
  • Die Tabellen können aber nicht verändert werden.
  • Zweck: Lastteilung, Backup
  • Einfach einzurichten.
• Primary-DNS
  • Besitzt eigene Tabellen für eine oder mehrere Zonen.
  • Tabellen können lokal verändert werden.
  • Server ist "authoritative" für seine Zone.
  • Relativ hoher Aufwand für Einrichtung und Pflege.

DNS Resource Records

• SOA-Records (Source of Authority) enthalten die technischen Angaben für die gesamte Zone sowie einige Steuerdaten für die Zusammenarbeit der Nameserver untereinander. SOA-Records sind weiter unten genauer erklärt.
• NS-Records (Name Server) verweisen auf die Nameserver, die für eine Zone authoritativ sind. Auf den eigenen Namen zeigende NS-Records dienen der Plausibilitätsprüfung; NS-Records für eine Subdomain weisen darauf hin, dass die Informationen für die Subdomain auf einem anderen Nameserver zu finden sind (Delegation).
• A-Records (Address) verknüpfen einen Domainnamen mit einer IP-Adresse. Um IPv4- und IPv6-Adressen zu unterscheiden, wird seit einiger Zeit für IPv4 der A-Record und für IPv6 der AAAA-Record verwendet.
• PTR-Records (Pointer) verknüpfen eine IP-Adresse "rückwärts" mit einem Domainnamen.
• CNAME-Records Canonical Name) definieren einen Domainnamen als Alias für einen anderen. Es gibt also für jedes System einen A-Record und ggf. noch beliebig viele CNAME-Records.
• MX-Records (Mail Exchanger) definieren, bei welchen Rechnern Mail für eine Domain eingeliefert werden soll. Auf diese Weise sind geneische Mailadressen wie z.B. "plate@fhm.edu" möglich.
• TXT-Records (Text) enthalten beliebige alphanumerische Informationen zu einem Domainnamen.

Aufbau der Zonendatei

; Zonendatei fuer die Domaene serverzwerge.de
;
$TTL 1D
@       in      SOA     aella.serverzwerge.de.  dnsadmin.aella.serverzwerge.de. (
                2002051505        ; Seriennummer
                10800   ; Refresh : 3 Stunden
                3600    ; Retry   : 1 Stunde
                604800  ; Expire  : 1 Woche
                86400)  ; Min. TTL: 1 Tag
                NS              aella.serverzwerge.de.
                MX              10 aella.serverzwerge.de.
                MX              50 mail.irgendeinprovider.de.

aella           A       10.23.200.100
snowwhite       A       10.23.200.17
doc             A       10.23.200.18
happy           A       10.23.200.19
bashful         A       10.23.200.20
sneezy          A       10.23.200.21
sleepy          A       10.23.200.22
grumpy          A       10.23.200.23
dopey           A       10.23.200.24
                HINFO   "Hexium 7.5" "Linux"

beispiel        CNAME   aella

Der SOA-Record

$TTL 1D
@       in      SOA     aella.serverzwerge.de.  dnsadmin.aella.serverzwerge.de. (
                2002051505        ; Seriennummer
                10800   ; Refresh : 3 Stunden
                3600    ; Retry   : 1 Stunde
                604800  ; Expire  : 1 Woche
                86400)  ; Min. TTL: 1 Tag

• Das erste Feld im SOA-Record benennt den primary master server. Dies ist der Server, der die endgültige Autorität über den Inhalt der Zone ist. Dort ist das Zonefile selbst abgelegt.
• Das zweite Feld des SOA-Records nennt die Mailbox der für die Zone verantwortlichen Person. Das @-Zeichen der E-Mail-Adresse wird hier durch einen Punkt ersetzt. Links vom @ stehende Punkte müssen als \. notiert werden, um eine eindeutige Zuordnung für den Punkt zu erreichen, der für den @ steht.
• Die Seriennummer spielt eine wichtige Rolle im Zusammenspiel zwischen Master-DNS und Slave-DNS: Slaves führen nur dann einen Zonentransfer durch, wenn die vom Master übermittelte Seriennummer größer ist als die der lokal gehaltenen Zone. Sie wird meist nach dem Schema yyyymmddnn gebildet: yyyy = Jahr (4-stellig), mm = Monat (2-stellig), dd = Tag (2-stellig) und nn die Viertelstunde (2-stellig) des aktuellen Tags.
• Der Refresh-Wert legt fest, wie häufig ein Slave beim Master nachfragt, ob sich die Zone verändert hat.
• Der Retry-Wert legt fest, wie häufig ein Slave einen fehlgeschlagenen Zonentransfer wiederholt, bis er aufgibt.
• Der Expire-Wert legt fest, wie lange ein Slave seine Kopie einer Zone noch als gültig ansieht, wenn er den Master nicht erreichen kann.
• Der Minimum-TTL-Wert legt fest, wie lange eine negative Antwort vom Client zwischengespeichert werden darf. Er ist einer der beiden wichtigsten Timer in einer Zonendatei (TTL = Time To Live).
• Der Eintrag in der $TTL-Zeile oberhalb des SOA-Records legt fest, welche Lebensdauer die Resource Records des Zonefiles in den Caches nicht authoritativer Nameserver haben sollen.

Wird eine Nameserver-Anfrage positiv beantwortet, übermittelt der authoritative Nameserver zusammen mit dem angefragten Resource Record die gewünschte Lebenszeit des Eintrags in Form der TTL. Ist im Zonefile für den Resource Record keine TTL angegeben, so übermittelt der authoritative Nameserver den mit $TTL im Zonefile gesetzten Defaultwert. Der Forwarder übermittelt die Antwort weiter an die Quelle der Anfrage und speichert die Antwort für die übermittelte Zeitdauer zwischen, so dass weitere Anfragen nach dem gleichen Resource Record innerhalb dieser Zeitdauer ohne erneuten Zugriff auf den authoritativen Server beantwortet werden können.

Bevor man zeitkritische Änderungen an einer Zone vornimmt (z.B. Umzug eines Web- oder Mailservers auf eine andere IP-Adresse), ist zu empfehlen, zuerst einen oder beide TTL-Werte herunterzusetzen. Dies sollte mindestens einen TTL-Zeitraum vor der eigentlichen Änderung geschehen, damit die kürzere TTL sich herumgesprochen hat. Nachdem die Änderung erfolgreich durchgeführt wurde, kann die TTL wieder heraufgesetzt werden.

Der MX-Record

Gibt es für einen Domainnamen keinen MX-Record, sondern nur einen A-Record, wird die Mail an diesen zugestellt. Dieses Verhalten ist historisch bedingt und nicht mehr sinnvoll. Trotzdem wird es immer noch so gehandhabt. Soll eine Domain nicht am E-Mailverkehr teilnehmen, so ist es sinnvoll, einen MX-Record auf ein System zu setzen, das für den Domainnamen eingehende E-Mail mit einem permanenten Fehler ablehnt.

Zero Configuration Networking

Für LANs ohne DHCP-Server gibt es auch eine recht einfache Lösung zum automatischen Konfigurieren der Netzwerkadressen. Bei IPv4 ist der Block 169.254.0.0/16 für die so genannten Link Local Addresses (IPv4LL) reserviert, bei IPv6 ist es der Adressbereich fe80::/10 und das Verfahren nennt sich Stateless Automatic Autoconfiguration (SLAAC) (siehe auch RFCs 3927 und 4862) bzw. Automatic Private IP Adressing (APIPA). Um an eine IP-Adresse zu kommen, wählt sich das Gerät eine zufällige Adresse aus diesem Bereich unter Zuhilfenahme seiner MAC-Adresse zusammen mit einem Zufallsgenerator. Dann stellt es durch ARP-Tests sicher, dass diese nicht bereits vergeben ist. Auf diese Weise können sich mehrere Geräte zu einem Ad-Hoc-Netz vereinigen. Die Netzmaske bei IPv4 lautet demnach 255.255.0.0, wobei die ersten und letzten 256 Adressen nicht verwendet werden dürfen.

Jedes Gerät macht seine so erworbene Adresse allen anderen per ARP-Announcement im Abstand von zwei Sekunden bekannt. Hierbei verwendet er als Absender- und Empfänger-IP die eben erworbene Adresse. Das Gerät muss aber weiterhin auf Adresskonflikte achten, die durch andere Rechner verursacht werden. Dies erkennt er, wenn ARP-Pakete mit seiner Adresse als Absenderadresse von anderen Teilnehmern eintreffen. Hat das Gerät offene TCP-Verbindungen und wurden noch keine kollidierenden ARP-Pakete empfangen (nur ein ARP-Probe), sendet es ein klarstellendes ARP-Announcement. In allen anderen Fällen wird es sich eine neue Adresse berechnen.

Damit sind zwar alle Rechner eine IP-Adresse, aber noch keinen aussagekräftigen Namen. Für einige Geräte einen DNS-Server aufzusetzen wäre overkill. Abhilfe schafft hier der Multicast DNS (MDNS, www.multicastdns.org). Er arbeitet ähnlich wie der "nbormale" DNS, nur eben über Multicast. Jedes Gerät hat DNS-Records gespeichert und tritt der Multicast-Gruppe bei. Zur Namensauflösung schickt ein Gerät seine Anfrage an die IPv4-Multicastadresse 224.0.0.251 (bei IPv6: ff02::fb). Ein Rechner mit dem passenden Eintrag liefert dann die Antwort. Bei MDNS haben alle Systeme die Top-Level-Domain ".local".

Es gibt sogar noch eine Erweiterung, DNS Service Discovery (DNS-SD, www.dns-sd.org). Mittels DNS-SD werden Informationen über angebotene Dienste unter Verwendung der bestehenden DNS-Typen wie SRV, TXT oder PTR publiziert. Alle diese Möglichkeiten sind unter Zeroconf Netwirking spezifiziert ( www.zeroconf.org). Bei Apple ist die Implementierung unter dem Namen "Bonjour" erfolgt und auch für Windows-Rechner erhältlich, die Open-Source-Variante heißt "Avahi" (www.avahi.org).

Netzwerkkonfiguration am Beispiel Linux

• /etc/HOSTNAME oder /etc/hostname
• /etc/hosts
• /etc/networks
• /etc/host.conf
• /etc/resolv.conf
• /etc/nsswitch.conf
• ifconfig
• route
• ip
• netstat
• ping
• traceroute

Auf den (Hardware-)Treiber des Netzwerk-Interface wird aus diesem Grund nicht eingegangen. Um festzustellen, ob überhaupt ein Treiber geladen wurde, genügt das Kommando

dmesg | more

...

8139cp 10/100 PCI Ethernet driver v0.0.6 (Nov 19, 2001)
8139cp: pci dev 00:0f.0 (id 10ec:8139 rev 10) is not an 8139C+ compatible chip
8139cp: Try the "8139too" driver instead.
8139too Fast Ethernet driver 0.9.24
PCI: Found IRQ 9 for device 00:0f.0
eth0: RealTek RTL8139 Fast Ethernet at 0xe081af00, 00:00:e8:76:2f:ea, IRQ 9
eth0:  Identified 8139 chip type 'RTL-8139A'

...

Im Folgenden werden die wichtigsten Konfigurationsdateien für das Netz besprochen, wobei viele der Dateien - eventuell leicht modifiziert oder mit ähnlichem Nanen - auch bei Windows zu finden sind. Bei Linux findet man diese Daten traditionsgemäß im Verzeichnis /etc.

Setzen des Hostnamens

hostname name

/etc/hosts

Um sicherzustellen, daß alle Programme ausschließlich /etc/hosts verwenden, um die Adresse eines Systems zu suchen, müssen Sie ggf. die Datei /etc/nsswitch.conf editieren. Interessant ist die Zeile, die mit "hosts:" beginnt. Dort sollte "files dns" stehen, was bedeutet, daß erst in der lokalen Datei /etc/hosts nachgesehen und dann erst ein Nameserver kontaktiert wird. Typischerweise sieht die Datei im Ausschnitt so aus:

# /etc/nsswitch.conf
#
...
hosts:          files dns
networks:       files
...

Die Datei hosts enthält einen Eintrag pro Zeile, bestehend aus der IP-Adresse, dem Hostnamen und einer optionalen Liste von Aliasen für den Hostnamen. Die Felder sind durch Leerzeichen oder Tabulatoren voneinander getrennt, und das Adreßfeld muß in Spalte eins beginnen. Ein Doppelkreuz (#) leitet immer einen Kommentar ein.

Namen können entweder mit voller Domainangabe (Full Qualified Domain Name, FQDN) oder relativ zur lokalen Domain sein. So ist das System sowohl unter seinem offiziellen als auch unter dem kürzeren lokalen Namen bekannt. Man kann in der Datei auch die Namen und IP-Adressen beliebiger anderer Rechner eintragen. Immer notwendig ist der Eintrag für den Rechner selbst, "127.0.0.1 localhost", denn sonst funktionieren gewisse Dienste (z.B. lpd) nicht.

Für alle folgenden Beispiele werden für die Rechnernamen Schneewittchen und die sieben Zwerge (in der englischen Fassung von Walt Disney) verwendet. Damit keine Kollision mit real existierenden Internet-Domains auftreten, kann man als Domainnamen beispielsweise "zwerge.local" nehmen. Als Netz verwenden wir das private B-Netz 172.20.y.x - und davon sogar nur ein C-Subnetz, 172.20.20.x.

Das folgende Beispiel zeigt, wie die Datei /etc/hosts im Zwergenwald aussehen könnte.

#
# Hostdatei fuer Snowwhite and Friends
#
# IP            FQDN                        Aliase
127.0.0.1       localhost

# die Zwerge
10.27.210.17    snowwhite.zwerge.local    snowwhite
10.27.210.18    doc.zwerge.local          doc
10.27.210.19    happy.zwerge.local        happy
10.27.210.20    bashful.zwerge.local      bashful
10.27.210.21    sneezy.zwerge.local       sneezy
10.27.210.22    sleepy.zwerge.local       sleepy
10.27.210.23    grumpy.zwerge.local       grumpy
10.27.210.24    dopey.zwerge.local        dopey
...

Jetzt wissen Sie auch, daß der Eintrag "127.0.0.1 www.microsoft.com" in der /etc/hosts beispielsweise zu komischen Effekten führen würde (welchen?).

/etc/networks

# /etc/networks
zwergenwald      172.20.20.0

/etc/protocols

ip      0     IP         # internet protocol, pseudo protocol number
icmp    1     ICMP       # internet control message protocol
igmp    2     IGMP       # Internet Group Management
ggp     3     GGP        # gateway-gateway protocol
ipencap 4     IP-ENCAP   # IP encapsulated in IP
tcp     6     TCP        # transmission control protocol
egp     8     EGP        # exterior gateway protocol
udp     17    UDP        # user datagram protocol
...

/etc/services

...
ftp       21  tcp
ssh       22  tcp
telnet    23  tcp
smtp      25  tcp
whois     43  tcp
domain    53  tcp
gopher    70  tcp
finger    79  tcp
www       80  tcp
www       80  udp
...

/etc/nsswitch.conf

In der Datei /etc/nsswitch.conf kann der Systemadministrator eine Vielzahl verschiedener Datenbanken konfigurieren. Wir besprechen hier nur diejenigen Optionen, die sich auf die Auflösung von Host- und Netzwerk-IP-Adressen beziehen. Optionen in /etc/nsswitch.conf müssen in getrennten Zeilen erscheinen, wobei die Argumente durch Leerzeichen oder Tabulatorzeichen voneinander getrennt sein müssen. Ein Doppelkreuz (#) leitet einen Kommentar ein, der sich bis zum Zeilenende erstreckt. Jede Zeile beschreibt einen bestimmten Dienst, z.B. die Auflösung von Hostnamen. Das erste Feld jeder Zeile gibt den Namen der Datenbank an und endet mit einem Doppelpunkt. Der Rest jeder Zeile enthält Optionen, die die Art des Zugriffs auf die betreffende Datenbank regeln. Die folgenden Optionen sind verfügbar:

In der Reihenfolge, in der die Dienste angegeben sind, werden sie auch abgefragt, wenn ein Name aufgelöst werden soll. Anspruch genommen, in der sie aufgelistet sind. Diese Liste befindet sich in der Datei /etc/nsswitch.conf in dem Abschnitt, in dem die Beschreibung der Dienste erfolgt. Die Dienste werden von links nach rechts abgefragt, und die Suche wird standardmäßig beendet, wenn ein Wert (oder Name) erfolgreich aufgelöst wurde. Zum Beispiel:

# /etc/nsswitch.conf
#
hosts:          dns files
networks:       files

Sie können das Suchverhalten noch genauer kontrollieren, indem Sie zusätzlich Aktionen (action items) angeben, die festlegen, welche Aktion nach dem jeweils letzten Namensauflösungsversuch durchgeführt werden soll. Auf diese Erweiterungen wird an dieser Stelle nicht weiter eingegangen.

/etc/resolv.conf

Die wichtigste Option in /etc/resolv.conf ist daher nameserver, welche die Adresse eines Name-Servers angibt. Wenn Sie die Option mehrmals angeben, werden die Server in der angegebenen Reihenfolge verwendet. Deshalb sollten Sie unbedingt den zuverlässigsten Server an erster Stelle eintragen. Wenn Sie keinen Name-Server eintragen, nimmt der Resolver an, daß einer auf der lokalen Maschine läuft. Gegenwärtig werden bis zu drei nameserver-Einträge in /etc/resolv.conf unterstützt.

Zwei weitere Befehle, domain und search, geben Domainnamen an, die der Resolver an einen Namen anhängt, wenn die zugehörige Adresse beim ersten Versuch nicht gefunden wird. Mit domain können Sie eine Default-Domain angeben, die immer dann angehängt werden soll, wenn ein Name nicht aufgelöst werden konnte. Wird dem Resolver z.B. der Name "sleepy" übergeben, findet dieser den Namen "sleepy." nicht im DNS, da es eine solche Top-Level-Domain nicht gibt. Wird "zwerge.local" als Standarddomäne angegeben, wiederholt der Resolver seine Anfrage und hängt diese Standarddomäne an den Hostnamen an. Die Abfrage nach "sleepy.zwerge.local" ist nun erfolgreich (natürlich nur, wenn es einen Nameserver gibt).

Mit der Option search kann eine Suchliste angegeben werden, gewissermaßen eine Verallgemeinerung der domain-Anweisung. Während bei domain nur eine einzelne Domain angeben werden darf, akzeptiert search eine ganze Liste davon, deren Einträge alle der Reihe nach durchprobiert werden, bis ein gültiger DNS-Eintrag gefunden wird. Die einzelnen Namen der Liste müssen durch Leerzeichen oder Tabulatoren voneinander getrennt werden.

Die Befehle search und domain schließen einander aus und dürfen höchstens einmal auftauchen. Wenn keiner der beiden Befehle angegeben ist, versucht der Resolver, die Default-Domain mit Hilfe der Systemfunktion getdomainname(2) aus dem lokalen Hostnamen zu raten. Hat der Hostname keinen Domain-Teil, wird als Default-Domain die Root-Domain (.) angenommen.

Werfen Sie einen Blick auf die Datei resolv.conf des Zwergenwaldes:

# /etc/resolv.conf
# Unsere Domain
domain         zwerge.local
#
# Wir benutzen "doc" als zentralen Name-Server:
nameserver     172.20.20.1

Netzwerk-Konfiguration für IP

Schnittstellenkonfiguration mit dem ifconfig-Kommando

• das Loopback-Interface,
• Broadcast-Interfaces und
• Point-to-Point-Interfaces.

ifconfig dient dazu, eine Schnittstelle für die Netzwerkschicht des Kernels sichtbar zu machen. Das beinhaltet die Zuweisung einer IP-Adresse und verschiedener anderer Parameter sowie die Aktivierung des Interface, damit der Kernel die IP-Pakete über diese Schnittstelle senden und empfangen kann. Die einfachste Art, es aufzurufen, ist:

ifconfig <interface> <ip-addresse> netmask <maske>

Initialisiert wird das Loopback-Interface durch das Kommando:

ifconfig lo 127.0.0.1

ifconfig eth0 192.168.0.1 netmask 255.255.255.0 broadcast 192.168.0.255

Neben den Broadcast-Schnittstellen gibt es noch die sogenannten Point-to-Point-Schnittstellen. Sie sind dadurch gekennzeichnet, daß man nur über sie ein anderes System erreichen kann. Beispiele sind SLIP (Serial Line IP) und das Point-to-Point-Protokoll PPP, die Verbindungen über die serielle Schnittstelle oder per Modem/ISDN-Adapter WAN-Verbindungen zulassen. Die Initialisierung einer Point-to-Point-Schnittstelle hat z.B. die folgende Form:

ifconfig ppp0 192.168.1.1 192.168.1.2 netmask 255.255.255.240

So eine PPP-Verbindung bildet ein eigenständiges Netzwerk. Sollen mehrere Verbindungen kombiniert werden, so muß eine Unterteilung in Subnetze erfolgen. Das heißt, daß eine entsprechende Netzmaske gewählt werden muß.

ifconfig kennt eine ganze Reihe von Optionen. Der allgemeine Programmaufruf lautet:

ifconfig interface [address [parameters]]

Ein Aufruf nur mit dem Interface-Namen gibt die Konfiguration des Interface aus. Wird es ganz ohne Parameter aufgerufen, zeigt es alle bisher konfigurierten Schnittstellen an; die Option -a erzwingt zusätzlich die Anzeige der inaktiven. Beispiel:

# ifconfig eth0
eth0      Link encap 10Mbps Ethernet  HWaddr 00:00:C0:90:B3:42
          inet addr 172.20.20.2 Bcast 172.20.20.255 Mask 255.255.255.0
          UP BROADCAST RUNNING  MTU 1500  Metric 0
          RX packets 3136 errors 217 dropped 7 overrun 26
          TX packets 1752 errors 25 dropped 0 overrun 0

Die folgende Liste zeigt die Parameter, die ifconfig versteht; die Namen der zugehörigen Flags stehen in Klammern. Optionen, die eine bestimmte Eigenschaft des Interface aktivieren, können mit vorangestelltem Minuszeichen (-) auch benutzt werden, um ihn wieder auszuschalten.

Das route-Kommmando

route [add|del] [-net|-host] <target> [dev <if>]

Den Rechner konfigurieren

ifconfig lo 127.0.0.1

Manchmal wird anstelle der IP-Adresse auch der Name localhost verwendet. Der Befehl ifconfig sucht diesen Namen in der Datei /etc/hosts, wo er als Hostname für 127.0.0.1 definiert sein muß.

Zur Anzeige der Konfiguration eines Interface rufen Sie ifconfig mit dem Namen des Interface auf. Ganz ohne Parameter wird die Konfiguration aller Interfaces gezeigt:

ifconfig lo
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:3924  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          Collisions:0

Nun fehlt noch ein Eintrag in der Routing-Tabelle, der festlegt, daß dieses Interface als Route für das Zielsystem 127.0.0.1 dient. Dazu geben Sie folgendes ein:

route add 127.0.0.1

Es wäre auch möglich, das Netz von localhost einzutragen:

route add -net 127.0.0.0

ping localhost
PING localhost (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.4 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=255 time=0.4 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=255 time=0.4 ms
^C
--- localhost ping statistics ---

3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.4/0.4/0.4 ms

Die bisher beschriebenen Schritte reichen aus, um Netzwerk-Programme auf einem alleinstehenden Rechner zu benutzen. Die oben angegebenen Zeilen müssen in das Netzwerk-Initialisierungsskript eingetragen werden, damit sie beim Systemstart ausgeführt werden. In der Regel wird zumindest die Konfiguration von "lo" beim Installieren des Systems bereits erledigt. Zur Einstimmung war das obige aber keine schlechte Übung. Nun sollte zum Beispiel telnet localhost eine telnet-Verbindung aufbauen und Ihnen den Login-Prompt Ihres Systems geben.

Die Konfiguration von Ethernet-Schnittstellen geht fast genauso vonstatten wie eben. Man braucht nur ein paar Parameter mehr, um auch Subnetze verwenden zu können.

Im Zwergenwald wird vom Klasse-B-Netz nur ein C-Subnetz verwendet. Um dies dem Interface mitzuteilen, sieht der ifconfig-Aufruf so aus:

ifconfig eth0 172.20.20.2 netmask 255.255.255.0

ifconfig eth0 doc netmask 255.255.255.0

ifconfig eth0
eth0      Link encap 10Mps Ethernet HWaddr  00:00:C0:90:B3:42
          inet addr 172.20.20.2 Bcast 172.20.20.255 Mask 255.255.255.0
          UP BROADCAST RUNNING  MTU 1500  Metric 1
          RX packets 0 errors 0 dropped 0 overrun 0
          TX packets 0 errors 0 dropped 0 overrun 0

Wie bereits bei der Loopback-Schnittstelle muß noch eine Route eingetragen werden. Für den Zwergenwald gilt:

route add -net 172.20.20.0

Vielleicht haben Sie bemerkt, daß die Angabe des Interface fehlt. Der Kernel prüft alle bisher konfigurierten Interfaces und vergleicht das Zielnetz (in unserem Fall 172.20.20.0) mit der Netznummer der Interface-Adresse, d.h. dem bitweisen UND der Interface-Adresse und der Netzmaske. Die einzige Schnittstelle, bei der diese beiden Werte übereinstimmen, ist eth0.

Die Option -net ist nötig, da route sowohl Routen zu Netzwerken als auch zu einzelnen Hosts einrichten kann. Wenn man route eine IP-Adresse übergibt, versucht das Kommando festzustellen, ob es sich dabei um eine Host- oder Netzadresse handelt, indem es den Hostteil betrachtet. Ist der Hostteil null, wird angenommen, daß es sich um eine Netz-Adresse handelt, andernfalls ist es eine Hostadresse. Deshalb würde route in unserem Beispiel davon ausgehen, daß 172.20.20.0 eine Hostadresse ist (Netz: 172.20.0.0, Host: ...20.0). Da ein Subnetz verwendet wird, braucht das route-Kommando den Parameter "-net".

Unter Verwendung des Eintrags in /etc/networks wird das Kommando einfacher:

route add zwergenwald

Nun sollte man überprüfen, ob das Ethernet tatsächlich arbeitet. Wählen Sie irgendeine bereits konfigurierte Maschine auf Ihrem lokalen Ethernet, z.B. grumpy, und geben Sie folgenden Befehl ein:

# ping grumpy
PING grumpy: 64 byte packets
64 bytes from 172.20.20.1: icmp_seq=0. time=10. ms
64 bytes from 172.20.20.1: icmp_seq=1. time=7. ms
64 bytes from 172.20.20.1: icmp_seq=2. time=8. ms
^C

----doc.zwerge.local PING Statistics----

4 packets transmitted, 4 packets received, 0 packets lost

route -n
Kernel routing table
Destination  Gateway  Genmask         Flags Metric Ref Use    Iface
127.0.0.1    *        255.255.255.255 UH    1      0   112    lo
172.20.20.0   *       255.255.255.0   U     1      0    10    eth0

Die Spalte "Flags" enthält eine Liste von Flags für jedes Interface. U ist für aktive Schnittstellen immer gesetzt. Ein Flag H in dieser Spalte besagt, daß die Zieladresse einen einzelnen Host bezeichnet. Wenn eine eingetragene Route benutzt wird, ändert sich der Wert im Use-Feld ständig.

Bisher wurde eine Maschine auf einem isolierten Ethernet eingerichtet (z.B. in einem Heimnetz). Der Regelfall ist allerdings, daß mehrere Netze durch Gateways miteinander verbunden sind (man will ja auch "nach draußen"). Diese Gateways verbinden zwei oder mehrere Ethernets miteinander, oder sie stellen das Tor zum Internet bereit. Um einen Gateway zu nutzen, muß der Netzwerkschicht zusätzliche Routing-Informationen zur Verfügung stehen.

Zum Beispiel sind die Ethernets des Zwergenwaldes und des Feenreichs durch solch ein Gateway miteinander verbunden, nämlich doc, der bereits konfiguriert sei. Auf allen Maschinen des Zwergenwaldes muß nur noch eine weitere Route eingetragen werden, die angibt, daß alle Maschinen im Netzwerk der Feen über doc erreichbar sind. Der entsprechende Aufruf von route sieht so aus (sofern feenreich in /etc/networks eingetragen wurde):

route add feenreich gw doc

Das war nun ein Gateway, das Pakete zwischen zwei isolierten Netzen befördert. Nehmen Sie nun an, daß doc außerdem eine Verbindung ins Internet hat. Dann wäre es wünschenswert, daß Pakete für beliebige Zieladressen, die nicht im Zwergen-Netz liegen, an doc weitergereicht werden. Das erreicht man, indem doc zum Default-Gateway wird:

route add default gw doc                 oder
route add default gw 172.20.20.1         bei Angabe der IP-Adresse

Es ist ziemlich einfach, eine Maschine als Gateway einzurichten. Nehmen wir an, wir befänden uns wieder auf doc, der mit zwei Ethernet-Karten ausgestattet ist, die jeweils mit einem der beiden Netze verbunden sind. Man muß nur beide Schnittstellen getrennt konfigurieren und ihnen eine Adresse auf dem jeweiligen Subnetz zuzuweisen. Dabei ist es recht nützlich, zusätzlich zum offiziellen Hostnamen doc zwei Namen für die beiden Schnittstellen in /etc/hosts zu definieren:

172.20.20.1      doc.zwerge.local    doc   doc-if1
172.20.21.1      doc-if2

Mit diesen Einträgen lautet die Befehlsreihenfolge für die Einrichtung der beiden Interfaces:

ifconfig eth0 doc-if1 ...
route add zwergenwald
ifconfig eth1 doc-if2 ...
route add feenreich

echo '1' > /proc/sys/net/ipv4/ip_forward

Sie brauchen nicht einmal eine zweite Netzwerkkarte, denn es gibt sogenannte "Device-Aliase". Dies sind virtuelle Geräte, die mit der gleichen physischen Hardware verbunden sind, jedoch gleichzeitig aktiviert werden können, um unterschiedliche IP-Adressen zu haben. Sie werden normalerweise mit dem Gerätennahmen gefolgt von einem Doppelpunkt und einer Zahl dargestellt (zum Beispiel eth0:1). Wenn Sie einen Alias verwenden, können weder das Interface noch der Alias zur Verwendung von DHCP konfiguriert werden. eth0:1 ist der erste Alias für eth0. Der zweite Alias hätte den Namen eth0:2, usw. Die Befehle um beide Netze über eine Netzwerkkarte zu routen, würden lauten:

ifconfig eth0 doc-if1 ...
route add zwergenwald
ifconfig eth0:1 doc-if2 ...
route add feenreich

Die Fehlermeldungen des route-Kommandos sind relativ kryptisch. Bei Linux kann - im Gegensatz zu anderen Unixen - die Metrik-Angabe entfallen. Man kann mehrere Routen zu einem Ziel (mit identischer Netzmaske) eingeben, sofern jeweils ein anderer Gateway angegeben wird.

Fehlermeldungen des route-Kommandos:

• SIODELRT ist eine Fehlermeldung beim Löschen einer Route (DELeting a RouTe)
• SIOADDRT ist eine Fehlermeldung beim Anlegen einer Route (ADDing a RouTe)

SIOCADDRT: Network is unreachable

route add default gw 1.2.3.4
Die angebene Adresse gehört nicht zum eigenen Netzwerk und so kann der Rechner keine Pakete dorthin weiterleiten.

SIOCADDRT: File exists

Die angegebene Route existiert bereits.

SIOCADDRT: No such device

Es wurde das Schlüsselwort gw vor der Default-Gateway-Adresse vergessen; also nicht:
route add -net 10.2.2.76/24 10.1.1.22
sondern:
route add -net 10.2.2.76/24 gw 10.1.1.22

SIOCDELRT No such process

Versuch, eine Route zu löschen, die nicht existiert.

SIOCADDRT: Operation not supported by device

Es wurde das Schlüsselwort gw oder die Gateway-Adresse vergessen; also nicht:
route add -net 10.0.0.0/8 10.1.1.254 oder
route add -net 172.23.24.128/25
sondern:
route add -net 10.0.0.0/8 gw 10.1.1.254 oder
route add -net 172.23.24.128/25 gw 10.1.1.22

SIOCADDRT: Operation not permitted

Sie arbeiten nicht mit root-Berechtigung.

SIOCADDRT: Invalid argument

Falsche Kommandosyntax (z.B. vergessene Netzmaske); also nicht:
route add -net 10.2.2.0 gw 10.1.1.254 oder
route del -net 172.23.0.0
sondern:
route add -net 10.2.2.0 netmask 255.255.255.0 gw 10.1.1.254 oder
route add -net 10.2.2.0/24 gw 10.1.1.254 bzw.
route del -net 172.23.0.0/16 oder
route del -net 172.23.0.0 netmask 255.255.0.0

route: netmask doesn't match route address

Die Netzmaske passt nicht zur Host- und Gateway-Adresse.

route: netmask 00ffffff doesn't make sense with host route

Meist wurde der Parameter -net vergessen. Das Kommando nimmt dann an, dass man eine Host-Route angeben will. Oder man hat bei einer Host-Route eine Netzmaske angegeben.

addr: Unknown host

Meist wurde eine falsche Netzmaske angegebn, die das Kommando falsch interpretiert.

route: bogus netmask 255.255.255.25

Die Netzmaske ist falsch angegeben worden (z.B. '25' oder '2555' statt '255').

Anmerkung: Die Syntax des route-Kommandos variiert von System zu System.

Linux Netzwerk-Konfiguration mit ip

• ip address <parameter> richtet die Netzwerkschnittstellen ein (ersetzt ifconfig),
• ip route <parameter> richtet das Routing ein (ersetzt route),
• ip rule <parameter> richtet Policy Routing ein (erweitertes Routing in Linux) und
• ip neigh <parameter>: Verwaltet die ARP-Tabelle (ersetzt das Kommando arp).

Der ip-Aufruf zeigt wie ifconfig, route und arp den aktuellen Zustand an. Der Befehl horcht auf folgende Syntax:

ip [Optionen] Objekt [Kommando [Argumente]]

ip address add 129.187.206.140/24 dev eth0
ip address add 129.187.206.148/24 dev eth0

ip address add 129.187.206.140/24 dev eth0
ip address add 129.187.206.148/24 dev eth0 label eth0:1

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:0e:0c:07:e7:72 brd ff:ff:ff:ff:ff:ff
    inet 129.187.206.140/24 brd 129.187.206.255 scope global eth0
    inet 129.187.206.148/24 brd 129.187.206.255 scope global secondary eth0:1
    inet 129.187.206.149/24 brd 129.187.206.255 scope global secondary eth0:2
    inet 129.187.206.152/24 brd 129.187.206.255 scope global secondary eth0:3
    inet 129.187.206.153/24 brd 129.187.206.255 scope global secondary eth0:4
    inet 129.187.206.154/24 brd 129.187.206.255 scope global secondary eth0:5
    inet 129.187.206.156/24 brd 129.187.206.255 scope global secondary eth0:6
    inet 129.187.206.157/24 brd 129.187.206.255 scope global secondary eth0:7
    inet 129.187.206.158/24 brd 129.187.206.255 scope global secondary eth0:8
    inet6 fe80::20e:cff:fe07:e772/64 scope link
       valid_lft forever preferred_lft forever

ip address del 129.187.206.157/24 dev eth0
ip address del 129.187.206.158/24 dev eth0

ip link set dev eth0 down
ip link set dev eth0 name test0
ip link set dev test0 up

Manchmal sind die Fehlermeldungen von ip etwas irreführend, zum Beispiel:

ip address add 129.187.206.159/24 dev eth0 label eth0:1
RTNETLINK answers: File exists

Der Befehl ip erlaubt auch fortgeschrittenes Routing wie z. B. Policy-Routing. Die Routen können mit folgendem Kommando angezeigt werden:

ip route show
129.187.206.0/24 dev eth0  proto kernel  scope link  src 129.187.206.140
default via 129.187.206.254 dev eth0

Angelegt werden die Routen mittels ip route add und dann der Angabe die praktisch der Ausgabe von ip route show entspricht:

ip route add 127.0.0.0/8 dev lo scope link
ip route add 129.187.206.0/24 dev eth0 proto kernel scope link src 129.187.206.140
ip route add default via 129.187.206.254 dev eth0

• Einrichten der Standard-Route auf 129.187.206.254 als Gateway:
  ip route add default via 129.187.206.254 dev eth0
• Schicken der Pakete in das Netz 192.168.150.0 über die zweite Netzwerkschnittstelle eth1:
  ip route add 192.168.150.0/24 dev eth1
• Schicken dder Pakete des Subnetzes 192.168.200.0/24 über ein Gateway:
  ip route add 192.168.200.0/24 via 192.168.150.1
• Löschen der vorherigen Route aus der Routing-Tabelle:
  ip route del 192.168.200.0/24

Offene Ports und Anwendungen finden mit netstat

Für eine Kontrolle der offenen Ports ruft man "netstat -nlp" auf.

netstat -npl
Proto Recv-Q Send-Q Local Address        Foreign Address   State   PID/Program name
tcp        0      0 72.139.238.24:80     0.0.0.0:*         LISTEN  25671/apache
tcp        0      0 72.139.238.24:21     0.0.0.0:*         LISTEN  16417/ftpd
tcp        0      0 72.139.238.24:22     0.0.0.0:*         LISTEN  1345/sshd
tcp        0      0 72.139.238.24:25     0.0.0.0:*         LISTEN  26007/exim4
tcp        0      0 72.139.238.24:443    0.0.0.0:*         LISTEN  1022/apache-ssl

Das System zeigt mit diesen Parameter nur Ports im Status "Listen" an. Zusätzlich wird in der letzten Spalte die Prozessnummer und der Name des zuständigen Dämons angezeigt. Alternativ kann unter Linux auch das Kommando "lsof" benutzt werden. Mit dem Aufruf

lsof -i | grep -e LISTEN

Einsatz von nmap

nmap -sT 192.168.1.1

Starting nmap 3.20 ( www.insecure.org/nmap/ ) at 2004-10-16 23:17 CEST
Interesting ports on Router (192.168.1.1):
(The 1610 ports scanned but not shown below are in state: closed)
Port       State       Service
80/tcp     open        http

Nmap run completed -- 1 IP address (1 host up) scanned in 6.533 seconds

tcpdump

tcpdump -i Interface

tcpdump hat eine eigene Art Abfragesprache, die Befehle ermöglicht wie

  tcpdump host blackhole

  tcpdump host doc and grumpy

Die ARP-Tabelle

arp [-v] [-t hwtype] -a [hostname]
arp [-v] [-t hwtype] -s hostname hwaddr

Der erste Aufruf gibt den ARP-Eintrag für die angegebene IP-Adresse bzw. Hostnamen aus. Fehlt hostname, werden Informationen über alle bekannten Hosts ausgegeben. Zum Beispiel ergibt die Ausgabe von arp auf www.netzmafia.de etwa folgendes:

arp
Address                  HWtype  HWaddress           Flags Mask  Iface
129.187.206.254          ether   00:04:DE:FE:78:00   C           eth0
ns.e-technik.fh-muenche  ether   00:07:E9:24:EC:15   C           eth0
proxy1.e-technik.fh-mue  ether   00:07:E9:24:EC:15   C           eth0
web1.e-technik.fh-muenc  ether   00:07:E9:24:EB:F5   C           eth0

Die Option -s dient dazu, die Hardwareadresse von hostname manuell in die ARP-Tabelle einzutragen. Das Argument hwaddr spezifiziert die Hardwareadresse, die normalerweise als Ethernet-Adresse aus sechs Byte in hexadezimaler Notation angegeben ist. Sie können solche Adressen auch bei anderen Hardwaretypen verwenden, wenn Sie zusätzlich die Option -t angeben. Die Festverdrahtung von Hardwareadressen im ARP-Cache ist eine drastische Maßnahme, um Maschinen aus Ihrem Ethernet daran zu hindern, sich als jemand anderes auszugeben.

Wenn Sie arp mit der Option -d aufrufen, entfernt es alle Einträge für einen bestimmten Host. Es kann dazu benutzt werden, das Interface anzuweisen, eine bereits angeforderte Hardwareadresse einer IP-Adresse nochmals anzufordern, und ist besonders dann nützlich, wenn ein fehlerhaft konfiguriertes System falsche ARP-Informationen sendet (natürlich muß zuerst das fehlerhafte System erneut konfiguriert werden).

Zum vorhergehenden Abschnitt

Zum Inhaltsverzeichnis

Zum nächsten Abschnitt

Copyright © Hochschule München, FK 04, Prof. Jürgen Plate
Letzte Aktualisierung: