Wirtschaftsinformatik (Bachelor-Studiengang): Rechnernetze/Onlinedienste (2. Semester)
Sie sind hier: Startseite › Wirtschaftsinformatik › Rechnernetze/Onlinedienste: TCP/IP (Teil 2)
BM / CM, Kurs vom 01.10.2002 - 31.03.2003
- Internet Control Message Protocol (ICMP)
- Adressauflösung (ARP)
- Dynamic Host Configuration Protocol (DHCP)
- Network Address Translation (NAT)
- Domain Name Service (DNS)
- Werkzeuge für die Netzanalyse
OSI-Einbindung:
Bildbeschreibung "OSI-Einbindung": Übertragungs- und Sicherungsschicht = Lokales Netz bzw. WAN; Vermittlungsschicht = ARP und RARP (Teilschicht 1), IP (Teilschicht 2), IGMP und ICMP (Teilschicht 3); Transportschicht = TCP und UDP; Anwendungsschicht (oberste Schicht) = DHCP und DNS.
Internet Control Message Protocol (ICMP)
- Definiert in RFC 792 (1981)
Für IPv6: RFC 1885, RFC 2463 - Austausch von Verwaltungsinformationen und Fehlermeldungen
- Mit dem IP in die Netzwerkschicht integriert
- Erkennungsprotokoll für Router: RFC 1256 (1991)
Aufbau des ICMP-Pakets
Bildbeschreibung "Aufbau des ICMP-Pakets": Der ICMP-Teil des 32 bit Paketes setzt sich zusammen aus Type (8 bit), Code (8 bit), Checksumme (16 bit) und ICMP-Datenbereich (32 bit). Des Weiteren enthält ein ICMP-Paket den typischen IP-Frame mit Version, IHL, Paketlänge, Kennung, Flags, Fragment Offset, TTL, Header-Checksumme, Quell-/Ziel-IP-Adresse und Optionen/Füllbits. Protokoll ist hier 1, Service ist 0.
Das ICMP ist in dem Sinne in IP integriert, als dass es im Datenteil eines IP-Pakets integriert ist und dass bestimmte Felder im IP-Header gesetzt sind.
Die verschiedenen Arten von ICMP-Paketen werden durch eine bestimmte Nummer im Type-Feld unterschieden.
Eine Auswahl:
- Typ 3: Destination unreachable
- Typ 4: Source quench (Puffer sind verbraucht)
- Typ 5: Redirect (Pfadumleitung)
- Typ 11: Time exceeded (Lebenszeit des Datagramms überschritten)
- Typ 0: Echo reply (Ping-Antwort)
- Typ 8: Echo request (Ping-Anforderung)
- Typ 13: Time Stamp (Zeitangabe-Anforderung)
- Typ 14: Time Stamp reply (Zeitangabe)
Der Aufbau des ICMP-Pakets ist abhängig vom Type-Wert.
Erläuterungen:
Das Feld Code enthält in Abhängigkeit vom Typ noch weitere Informationen, z.B. bei Anforderungen die Art bzw. bei Antworten Fehlercodes.
Das Feld Checksumme enthält die ICMP-Kopf-Prüfsumme, d.h. über die ersten 8 byte.
Häufig wird im ICMP-Datenteil das betroffene IP-Paket (IP-Header mit 8 byte Daten) angefügt, um dem Empfänger eine Möglichkeit der Rekonstruktion zu geben.
Funktion: Source Quench dient der Flusskontrolle
Funktion: Router Advertisement dient der Bekanntgabe mehrerer Router
(ca. alle 7-10 Min.) - dient jedoch
nicht zum Austausch von Router-Informationen.
Die Bekanntgabe kann auch explizit angefordert werden.
Funktion: Time Exceeded: Wenn maximale Anzahl von Hops erreicht und IP-Frame verworfen wurde.
Echo und Echo Reply
Bildbeschreibung "Echo und Echo Reply": Enthält 8 bit Type (8/0), 8 bit Code (0), 16 bit Checksumme, 16 bit Identifier, 16 bit Sequenznummer und 32 bit Optionale Daten.
ICMP-Typ 8 (echo) ist die Aufforderung, eine Antwort (echo reply) an den Sender zurückzusenden.
Verschiedene Echo-Requests desselben Senders erhalten denselben Identifier-Wert, während jede Aufforderung aufsteigend durchnummeriert (Sequenznummer) wird.
Am Ende dürfen nochmax. 216-1 byte beliebige Daten angehängt werden.
Time exceeded
Bildbeschreibung "Time exceeded": Enthält 8 bit Type (11), 8 bit Code (0/1), 16 bit Checksumme, 32 bit Identifier und Sequenznummer (0), 32 bit IP-Kopf mit den ersten 8 byte Daten.
Dauert die Übertragung eines IP-Pakets zu lange (Ablaufen des TTL-Wertes (a) oder min. ein Fragment wird innerhalb einer bestimmten Zeitspanne vermisst (b)), wird diese ICMP-Meldung an den Sender zurückgesendet und das bzw. die Pakete verworfen.
Im Falle von (a) ist Code 0, bei (b) 1.
In den Daten wird zwecks Rekonstruktion der Anfang des verworfenen IP-Pakets angegeben.
Adressauflösung (ARP/RARP)
Address Resolution Protocol (ARP)
- (LAN-)Address Resolution Protocol (ARP)
- Definition in RFC 826 sowie RFC 814
- Bestandteil der (unteren) OSI-Netzwerkebene
Diese Einordnung ist etwas problematisch, da ein Zugriff auf die Adressen des Link-Layer (MAC-Adresse) notwendig ist. Korrekter wäre eine Einordnung in einen Management-Bereich.
Umsetzung der IP-Adresse in MAC-Adresse (LAN), da nur dann eine andere Station mit Hilfe der IP-Adresse angesprochen werden kann.
MAC-Adressen sind
- "eingebrannt" in die LAN-Karte oder
- per Software eingestellt.
Zielstation im selben Subnetz
Sender und Empfänger benutzen dasselbe LAN - genauer beide befinden sich in derselben Broadcast-Domain:
Prüfung, ob MAC-Adresse schon im Cache ist:
- Vorhanden: diese Adresse verwenden
- Nicht vorhanden: Broadcast-Anfrage
auf Link-Ebene
Die Station mit der bewussten MAC-Adresse meldet sich und teilt IP und MAC-Adresse dem Sender mit. In beide Caches (Sender und Empfänger) werden die neuen Werte eingetragen.
Cache = Zwischenspeicher mit Ergebnissen der vorherigen Anfragen bzw. fest eingestellten Werten.
Zielstation im fremden Subnetz
Sender und Empfänger sind über mindestens einen Router verbunden. Die kann anhand der IP-Adresse und der Netzwerkmaske festgestellt werden.
- Router-MAC-Adresse
in der Cache-Tabelle
- Vorhanden: Adresse verwenden
- Nicht vorhanden: Mac-Adresse des Router bestimmen (wie vorheriges Verfahren)
- Senden des Pakets an den Router
- Router prüft anhand
IP-Adresse,
ob Zielrechner in einem
der direkt an ihm angeschlossenen LAN ist
- Falls nicht: Neuen Router samt dessen MAC-Adresse bestimmen und an diesen senden
- Falls doch: an diese Zielstation direkt senden, nötigenfalls MAC-Adresse bestimmen
- Dies wiederholt sich, bis Zielstation erreicht ist.
Zum Cache:
Einträge sind jeweils ein Paar: (IP-Adresse, MAC-Adresse) ergänzt durch Verwaltungsinformation.
Statische Einträge vom Administrator,
z.B. Kommando arp
(Windows).
Dynamische Einträge mit Zeitstempel
- Potentielle Lebensdauer: 10 Min.
- Veraltete bzw. nicht benutzte Einträge werden gelöscht.
Reverse Address Resolution Protocol (RARP)
- Definiert in RFC 951 und RFC 1532 als Teil von BOOTP
- Umgekehrter Prozess: eine Station kennt seine MAC-Adresse, nicht jedoch seine IP-Adresse.
- Anwendung bei Thin Clients (PC ohne Platten)
- Eigener Ethernettypenwert:
0x8035
- Es wird dasselbe Paketformat wie bei ARP benutzt.
- Die Antwort mit der IP-Adresse wird von einem RARP-Server generiert, der eine Tabelle mit den Zuordnungen hat oder die IP-Adresse dynamisch zuteilt.
- Das Protokoll DHCP leistet das auch und noch mehr, so dass dies benutzt werden sollte.
Dynamic Host Configuration Protocol (DHCP)
- RFC 1533, 1534, 1541, 1542, 2131 und 2132
- Arbeitet oberhalb von OSI-Ebene 4
- UDP, Ports 67 und 68
Ziele:
- Verbesserte Ausnutzung der IP-Adressen
- Automatisierte Initialisierung des TCP/IP-Stack
Auf den Stationen muss sich eine "dynamisch wachsende" Realisierung des TCP/IP-Stack befinden.
Weiterentwicklung des alten BOOTP.
Lease = Vergabe einer IP-Adresse für eine gewisse Zeit.
DHCP-Server und Clients:
Bildbeschreibung "DHCP-Server und Clients": Der DHCP-Server hat Verbindung zum LAN, ebenso wie verschiedene DHCP-Clients. Der Server greift zusätzlich noch auf einen Adress-Pool mit weiteren Parametern zu.
DHCP-Informationen
Über DHCP werden dynamisch vergeben bzw. b ekannt gemacht:
- IP-Adresse
- Subnetzmaske
- Adressen von Namens-Server (DNS, WINS)
- Default-Router
- Name der Domain
Die automatische Vergabe hat neben der besseren Ausnutzung des IP-Adressraums den großen Vorteil der Arbeitsersparnis der System-/Netzwerkadministratoren.
(Fast) alle Internet-Service-Provider arbeiten mit DHCP.
Arbeitsweise
Schritt 1: Lease-Anforderung
- Minimaler Aufbau der TCP/IP-Stack: UDP
- Broadcast ohne Absenderadresse
(0) mit MAC-Adresse:
DHCPDISCOVER
Schritt 2: Lease-Angebot
Alle angesprochenen DHCP-Server antworten mit Broadcast Informationen: MAC-Adresse,
angebotene IP-Adresse samt
Subnetzmaske, DHCP-Server-Adresse, Dauer der Lease: DHCPOFFER
Kommt keine Server-Antwort ( kein DHCP-Server erreicht oder keiner mit freier Adresse): Warten und erneuter Versuch, später Versuche alle 5 Minuten.
Schritt 3: Lease-Auswahl
- Antwort per Broadcast mit
IP-Adresse
des gewählten
DHCP-Server:
DHCPREQUEST
- Alle anderen Server
beenden den Vorgang, da sie aufgrund des
Broadcast den
DHCPREQUEST
mitbekommen haben
Schritt 4: Lease-Bestätigung
- Server schickt direkte Bestätigung mit gültiger IP-Adresse
- Client übernimmt die weiteren Daten und baut mit den Daten den TCP/IP-Stack vollständig auf
- Server kann aber auch ablehnen: neuer Beginn des Verfahrens
Schritt 5: Benutzung der IP-Adresse
Keine nennenswerten Ergänzungen.
Schritt 6: Erneuerung des Lease
- Client versucht nach 50 %
des Lease-Zeitraums eine Erneuerung:
direkte Adressierung mit
DHCPREQUEST
- Falls keine Antwort bis 87,5 % des Lease-Zeitraums:
DHCPREQUEST
mit Broadcast mit Empfang von Ablehnung (neuer Durchlauf) oder Bestätigung (Verlängerung) - Falls keine Antwort 100 %: Sonstige Netzaktivitäten einstellen und wie initial von vorn beginnen
Nach Ablauf einer Lease muss die Adresse sofort freigegeben und alle sonstigen Netzaktivitäten eingestellt werden.
Nach Zusammenbruch des Client: Verkürztes Verfahren unter Verwendung der alten IP-Adresse, so dass oft dann die alte weiterbenutzt werden kann.
Hinweise:
Router müssen so konfiguriert sein, dass sie als Mittler zu den DHCP-Server dienen können: als DHCP-Relay. Diese Router werden als RFC 1542-konform bezeichnet.
Für jedes Subnetz: eigener DHCP-Adressbereich
Möglichst mehrere DHCP-Server (Ausfallsicherheit):
- Eigentlicher Server: ca. 75 % der Adressen
- Ersatz-Server: 25 % der Adressen
Dies hat den Vorteil, dass nach Ausfall des eigentlichen DHCP-Server wenigstens 25 % der Adressen vergeben werden können. Sind im Normalbetrieb alle Adressen des eigentlichen Server (75 %) vergeben, können die restlichen 25 % aufgrund der Broadcast-Anfragen auch vergeben werden.
Ersatz-DHCP-Server:
Bildbeschreibung "Ersatz-DHCP-Server": Zwei Netzwerke mit jeweils einem DHCP-Server und mehreren DHCP-Clients sind durch einen Router gekoppelt.
Network Address Translation (NAT)
Bei der Network Address Translation im allgemeinen wird bestimmten internen Adressen eine oder mehrere externe Adressen mit einem Router zugeordnet:
- Bei Network Address Translation (NAT) werden die Adressen 1:1 auf einander abgebildet.
- Bei Port and Address Translation (PAT) oder Network Address Port Translation (NAPT) in RFC 2663 werden mehrere interne Adressen auf eine externe unter Berücksichtigung der Ports abgebildet.
- IP-Maskerading ist im wesentlichen das PAT/NAPT-Verfahren, wobei hier auch der eingeschränkte Aufbau von Verbindungen von außen erlaubt wird.
Ziele:
- Kopplung von Netzen mit demselben Adressraum
- Zugang eines Netzes über eine IP-Adresse
- Verdecken der eigenen Adressen (Sicherheit)
Anwendungsfälle
Fall 1: 1:1-Umsetzung (klassisches NAT)
- Erhöhung der Sicherheit durch Kontrolle des Übergangs an einer definierten Schnittstelle
- Häufig mit Firewall (Filter) kombiniert
Fall 2: Mehre interne : 1 externe Adresse (PAT)
Zuordnung der internen IP/Port-Adressen auf eine externe IP-Adresse (und umgekehrt).
Fall 3: 1 interne : mehrere externe Adressen
Verschleierung der Anwendungsstationsadresse
Fall 4: Mehre interne : mehrere externe Adressen
- Erhöhung der Sicherheit
- Lastverteilung
Fall 2 ist der in der Praxis am häufigsten vorkommende.
Realisierung:
- Proxy (Stellvertreter)-Prozess
- Verschleiern der Clients
- Cache (Optimierung bei mehrfachem Zugriff auf dieselben Daten)
- Kontrolle der Zugriffe auf beiden Seiten
Anfertigen von Log-Dateien
- Router mit NAT/PAT
Single User Account
Bildbeschreibung "Single User Account": Verschiedene Clients greifen auf ein lokales Netzwerk zu. Ein Router (zuständig für NAT) verbindet das lokale Netz mit dem Internet. Schnittstelle zum Internet ist der Einwahlknoten des Providers (ISP).
Bitte bei derartigen Konstruktionen die Geschäftsbedingungen der Provider beachten.
Erläuterungen:
Dynamischer Aufbau einer Tabelle:
- Interne IP-Adresse
- Externe IP-Adresse
- Interne MAC-Adresse (ARP-Teil)
- Interne Port-Nummern (Sender, Empfänger)
- Externe Port-Nummer (Sender, Empfänger)
- Protokoll
Der Auf-/Abbau der Tabelle muss dynamisch erfolgen.
Alle Verbindungen nach außen müssen in beiden Richtungen eindeutig über folgendes N-Tupel identifizierbar sein:
- IP-Adresse
- Protokoll-Nummer
- Sende- und Empfänger-Port
Domain Name Service (DNS)
- Definiert in RFC 1034, 1035
- Ziele dieses Verzeichnisdienstes
- Umsetzung einer symbolischen Adresse nach IP
- Umsetzung einer IP-Adresse zur symbolischen
- Vermerken der Adressen der E-Mail-Server
- Vermerken von Informationen über Stationen
- Vermerken der Adressen anderer DNS-Server
- Die Adressen werden streng hierarchisch in Domains (Bereiche) zusammengefasst.
- Weiterentwicklung zum Dynamic Domain Name Service (DDNS): RFC 2136, 2137
Namensraum:
Bildbeschreibung "Namensraum": Beispiel
www.fhtw-berlin.de
. www
ist der
Stations-/Service-Name,
fhtw-berlin.de
die Second-Level-Domain. .de
kennzeichnet die Top-Level-Domain. Beispiel für Third-Level-Domain wäre
f4.fhtw-berlin.de
.
Alte Top-Level-Domains:
- Länderkennzeichen
.com
für Unternehmen.net
für Netzwerkbetreiber.org
für Organisationen.edu
für (Hoch-)Schulen.mil
für United-States-Militär.gov
für United-States-Regierung
Neue Top-Level-Domains:
.biz
für Unternehmen.aero
für Fluglinien/Häfen.info
für Allgemein.name
für Namen.pro
für Berufsgruppen.museum
für Museen.coop
für Genossenschaften
Vergabe der Adressen
- NIC: Network Information Center
- Deutschland: DENIC
- Internationale Koordinierung der Top-Level-Domains:
ICANN = Internet Corporation for Assigned Names and Numbers
Begriffe:
Zone = Bereich der DNS-Namen, für die der DNS-Server zuständig ist, d.h. von denen er Daten hat.
Authoritätsszone = Zone.
Intern wird für jede Zone eine Datei angelegt, so dass ein DNS-Server mit mehreren Dateien (Zonen) arbeiten kann.
Hierarchie und Authoritätszonen:
Bildbeschreibung "Hierarchie und
Authoritätszonen": Erster Zonen-Bereich (Hierarchie-Ebene
1) = .de
, .fr
, .edu
(bilden
jeweils eine Zone). Zweiter Zonen-Bereich (Hierarchie-Ebene 2) =
tu-berlin
, fu-berlin
,
fhtw-berlin
. Dritter Zonen-Bereich (Hierarchie-Ebene
3, beispielhaft für fhtw-berlin
) =
rz
, f1
, f2
, f3
,
f4
.
Mechanismus:
Bildbeschreibung "Mechanismus (Teil 1)": Anfrage an einen DNS-Server. Station 1 enthält Anfrager und Resolver, Station 2 den DNS-Server.
Bildbeschreibung "Mechanismus (Teil 2)": Der beauftragte DNS-Server 1 befragt andere, um die Anforderung des Resolvers zu erfüllen: Rekursiver Modus.
Bildbeschreibung "Mechanismus (Teil 3)": Der Resolver befragt selbst andere, um die Anforderung bearbeiten zu können. Ein DNS-Server ohne Antwort gibt eine Adresse eines anderen DNS-Server zurück, von dem geglaubt wird, er hätte die Antwort.
Auflösungsalgorithmus
- Prüfung der Anfrage, ob Antwort in der Datenbank vorhanden ist: Falls ja: Dem Client antworten
- Ermittlung der Top-Level-Domain
- Anfrage an Top-Level-Domain-Server
- Dort Prüfung und Rücksendung der IP-Adresse des zuständigen DNS-Server (Nachsehen in Datenbank aller gültigen Domain-Namen)
- Direkte Nachfrage bei diesem DNS-Server
- Dort Prüfung und Rückantwort mit der IP-Adresse
- Dem Client antworten
Dieses Verfahren läuft entweder automatisch durch den ersten DNS-Server ab (rekursiver Modus), oder durch den Resolver selbst.
DNS-Server-Arten (Rollen)
Für jede Zone (können) existieren:
- Primärer Server mit Originaldaten
- Sekundärer Server
als Spiegel des Primären
Server
Ein Namens-Server kann gleichzeitig primär für die eigene Domain und sekundär für andere sein. - Master-Server ist Herkunft der Daten für Sekundäre Server
- Cache-Only-Server hat keine eigene Zone, vermerkt bzw. lernt Anfragen und Ergebnisse, es gibt für ihn auch keine Zonen-Datei.
Dies sind Rollen, die durch jeden Server eingenommen werden können. Auch gleichzeitig, d.h. ein DNS-Server kann für eine bestimmte Zone der primäre Server sein und für eine andere der sekundäre.
Resource Records (RR)
Die Datensätze der DNS-Datenbank sind in Resource Records (RR) abgelegt. Dies sind ASCII-Zeilen mit einem bestimmten syntaktischen Aufbau.
Für jede Zone gibt es eine Datei mit den notwendigen RR.
Diese Dateien müssen mit einem Replikationsmechanismus regelmäßig zwischen den DNS-Server ausgetauscht werden (Ausnahme: Cache-Only-Server).
Neben der Definition der Zone müssen auch die Verweise auf die höheren Domänen (Zonen) vorhanden sein, damit der obige Auflösungsalgorithmus durchgeführt werden kann.
- SOA: Definition der Zone (Standard of Authority)
- NS: Name Server (die anderen)
- A: Internet-Adresse (IP-Adresse -> Name)
- CNAME: Alias-Name zu einer existierenden Domain
- PTR: Pointer (Name -> IP-Adresse)
- HINFO: Informationen über einen Rechner
- MX: E-Mail-Server der Zone
Die MX-Records definieren die E-Mail-Server der Zonen; hierüber finden die E-Mails ihren Weg zum Ziel, da in der E-Mail-Adresse die Domain und damit indirekt die Zone angegeben ist.
Werkzeuge für die Netzanalyse
Ping (Nach Echolot beim U-Boot):
- ICMP-Echo-Request mit ICMP-Echo sowie ein paar Lastdaten
- Messung der Laufzeit
Trace Route
(traceroute, tracert
):
- Senden ICMP-Echo-Request mit TTL=1
- Empfang ICMP-Time exceed mit Router IP-Adresse
- Dann Wiederholung mit TTL=2 usw. bis Zielstation erreicht
ipconfig/ifconfig
:
Ausgabe der Einstellungen, insbesondere nach DHCP-Konfigurierung; es kann der eigene Name bzw. die Parameter einer (Ethernet-)Schnittstelle ausgegeben und gesetzt werden.
arp
:
Anzeige des Inhalts eines lokalen ARP-Caches sowie Setzen fester Einträge, z.B. MAC/IP-Adressen von häufig benutzten Server (um Netzbelastung durch unnötige ARP-Anfragen zu senken).
netstat
:
Anzeige der aktuellen Verbindungen sowie Statistik, z.B. Anzahl der Pakete, Anzahl der Fehler
nslookup
:
Anfrage von DNS-Einträgen, u.a. welche IP-Adresse ein symbolischer Name hat, dasselbe in umgekehrter Richtung, welche E-Mail-Server eingetragen sind. Es können alle RR abgefragt werden.
tcpdump
:
tcpdump
listet die Pakete auf der IP-Ebene
zwecks Analyse auf.