WinFuture-Forum.de: Netzwerkgrundlagen - Was ist was im TCP-IP-Netz? - WinFuture-Forum.de

Zum Inhalt wechseln

Nachrichten zum Thema: Netzwerk
Seite 1 von 1

Netzwerkgrundlagen - Was ist was im TCP-IP-Netz? Begrifflichkeiten - Zusammenhänge - Fehlerquellen

#1 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 7.767
  • Beigetreten: 20. Juli 07
  • Reputation: 859

geschrieben 17. August 2013 - 22:19

*
BELIEBT

Hier mal ein paar Grundlagen zu TCP/IP-basierten Netzwerken... in der Hoffnung, daß es dem geneigten Leser beim Verständnis und auch der Fehlersuche in seinem Netzwerk behilflich sein möge.

Groß in die Tiefe gegangen wird nicht; insbesondere bleiben DNS und DHCP weitestgehend außen vor.


Zuallererst: die BEGRIFFSKLÄRUNG.


Was ist TCP/IP?

Die kürzestmögliche Antwort auf diese Frage: TCP/IP ist ein Netzwerk-Protokollstapel, welcher - entgegen des Namens --- nicht nur aus den Protokollen TCP und IP besteht, sondern auch weitere, unterstützende Protokolle beinhaltet.
Die beiden wichtigsten für unsere Zwecke sind UDP und ARP. Näheres dazu später. Erwähnung finden müssen jedoch ICMP - darüber laufen Pings - und TLS, die Transport Layer Security - das, was gemeinhin als SSL bezeichnet wird. Allerdings soll hierauf nicht weiter eingegangen werden.

Noch einmal zur Verdeutlichung: TCP/IP selbst ist KEIN Protokoll oder sonst eine isolierte Entität; stattdessen gibt es Schnittstellen nach oben (in Richtung der Anwendungen) und nach unten (in Richtung der eigentlichen, physischen Datenverbindung). Hierbei spielt es keine Rolle, wie diese aussehen - ob also ein Browser oder Emailprogramme darauf zugreift bzw. ob ein verkabeltes Netzwerk oder ein Funknetzwerk oder irgendeine andere Form darunterliegt (also PowerLAN, Glasfaser oder dergleichen).


Wichtig fürs Verständnis ist hierbei insbesondere: die einzelnen Protokolle agieren völlig unabhängig voneinander. TCP interessiert sich beispielsweise nicht dafür, was der Internet Explorer über ihm will oder an was für eine IP das geschickt werden soll; ebensowenig interessiert sich IP dafür, was es durchs Netzwerk schickt oder über welches Medium die Daten ans Ziel kommen sollen. Eben so, wie sich der Endbenutzer auch nicht dafür interessiert, was da im Hintergrund abläuft - er möchte einfach winfuture-forum.de angezeigt bekommen und mehr nicht.


NB. Diese Trennung ist zusammen mit dem Weg, den die Daten von der Anwendung über TCP/IP durchs Netzwerk gehen, im TCP-IP-Schichtenmodell fest spezifiziert. Auch hierauf soll jedoch nicht weiter eingegangen werden; der interessierte Leser findet weitergehende Informationen zum TCP-IP-Schichtenmodell ebenso wie den übrigen Protokollen aus der TCP/IP-Protokollfamilie unter anderem bei der deutschen Wikipedia.

2. Was ist TCP?
3. Was ist IP?
3.1 IP-Adressen und ihr Aufbau - klassifiziert und klassenlos
3.2 Die Subnetzmaske
3.3 Exkurs: Die Broadcast-Adresse
3.4 Routing - Wie die Pakete durchs Netzwerk kommen
3.4.1 Der Standardgateway
3.4.2 Exkurs: ARP - Wie die Pakete in den Rechner kommen
3.5 Fehlerquellen
4. In den Tiefen des Internetprotokolls
4.1 Adresstypen

Dieser Beitrag wurde von RalphS bearbeitet: 25. August 2013 - 17:54

"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
10

Anzeige

#2 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 7.767
  • Beigetreten: 20. Juli 07
  • Reputation: 859

geschrieben 19. August 2013 - 03:59

Was ist TCP?

TCP - Transmision Control Protocol, zu deutsch: Übertragungskontrollprotokoll oder Protokoll mit Übertragungskontrolle --- ist, um es stark vereinfacht zu formulieren, eine virtuelle Punkt-zu-Punkt-Verbindung zwischen zwei Anwendungen, nämlich dem Client (zum Beispiel dem Browser) und dem Server (zum Beispiel einem Webserver). Dieses geschieht über vorher festgelegte Ports (in diesem Fall wäre das 80 für HTTP oder 443 für HTTPS). In Verbindung mit der IP-Adresse des Servers erreicht man dann das konkrete bereitgestellte Angebot. Dieses Konstrukt aus IP-Adresse und TCP-Port nennt man übrigens Socket; wenn dieser Begriff irgendwo auftaucht, ist eben diese Kombination gemeint. Im übrigen bezeichnet "Port" nichts weiter als eine Anschlußnummer.

Die Aufgabe von TCP ist es, dafür zu sorgen, daß Datenpakete in der richtigen Reihenfolge und möglichst intakt beim Empfänger ankommen.

Das Geschwisterprotokoll von TCP ist UDP (User Datagram Protocol; Benutzerdaten(paket)-Protokoll). Dies ist, wieder stark vereinfacht, ganz einfach TCP, bei welchem die Übertragungskontrolle abgeschaltet wurde. Praktisch heißt das, daß Datenpakete einfach von oben nach unten durchgereicht werden, ohne diese weiter anzuschauen (daher leitet sich der Name ab - UDP überläßt die Kontrollfunktion, die normalerweise TCP obliegt, dem Benutzer (User) des Protokolls (üblicherweise also diejenige Anwendung, die UDP nutzt). Dieses muß sich dann selbst um die Verwaltung der Pakete (Datagrams) kümmern).


Typische TCP-Probleme und deren Behandlung

[*] Wenn auf einen speziellen Dienst nicht zugegriffen werden kann - wenn also keine Webseiten geladen werden oder keine Mails empfangen werden können oder FTP nicht funktioniert - während aber alle anderen Dienste normal angesprochen werden können, kann die Ursache beim TCP-Protokoll liegen. Für gewöhnlich ist dann der fragliche TCP-Port in der Firewall nicht freigegeben. Zur Verifizierung genügt es hier, testweise die Firewall abzustellen - wenn es dann geht, fehlt einfach eine entsprechende Regel, die den Verkehr für den - oder ggf die - fraglichen Ports zuläßt. Welche das sind, findet man beispielsweise in /etc/services (*nix-basierte Systeme) bzw in %SystemRoot%\System32\drivers\etc\services (Windows-basierte Betriebssysteme). Wenn man dort keinen passenden Eintrag findet, hilft oft eine Anfrage bei Google nach "< Anwendungsname > Ports".

[*] Wenn der Rechner plötzlich nicht mehr willens ist, *irgendwelche* neuen Verbindungen nach außen herzustellen, liegt das oft daran, daß die maximale mögliche Anzahl der (gleichzeitigen) TCP-Verbindungen erschöpft ist. Dann kann es helfen, den Befehl netstat mit der Option -b (Windows) bzw --program (*NIX) auszuführen; beide liefern eine Liste der gerade aktiven Sockets, deren Zustand und welches Programm sie geöffnet hat. Dann einfach diejenige(n) Anwendung(en) schließen, welche ungewöhnlich viele Verbindungen beanspruchen; nach einer kurzen Weile sollte dann alles wie gehabt funktionieren. Oft sind dies Torrent-basierte Anwendungen.

Achtung: die Zuordnung der Verbindungen zu den dahinterstehenden Prozessen mittels der -b / --program - Option von netstat erfordert Admin- bzw. Root-Rechte.
"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
1

#3 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 7.767
  • Beigetreten: 20. Juli 07
  • Reputation: 859

geschrieben 19. August 2013 - 04:24

3. Was ist IP?

Anders als man vielleicht vermuten könnte, gibt es "das Internet" als solches zunächst nicht. Es gibt nur viele einzelne Netze und die Kommunikation zwischen diesen: jedes dieser einzelnen Netze hat jedoch einen anderen Besitzer.

Die Art und Weise, WIE diese Kommunikation geschieht, wird durch ein Protokoll festgelegt, welches entsprechend seines Zuständigkeitsbereichs bezeichnet ist: also dasjenige Protokoll, das sich um die Kommunikation zwischen den einzelnen Netzen kümmert.
Zu Englisch also mehr oder weniger Inter-Network Communication Protocol; bzw verkürzt (und offiziell) InterNet Protocol, abgekürzt mit IP.


An dieser Stelle soll sich auf IP in der Version 4 beschränkt werden. Grundsätzlich unterscheidet sich dabei IPv6, abgesehen von der Adresslänge (128bit statt 32bit) und ein paar Begrifflichkeiten (Präfix statt Subnetzmaske) nicht von IPv4. Unterschiede gibt es insbesondere in der Konfiguration und in der Implementierung; aber darauf soll hier nicht eingegangen werden.


Das Internet-Protokoll hat letztlich nur eine Aufgabe: dafür zu sorgen, daß die Pakete, die es vom TCP-Protokoll erhält, durch sämtliche dazwischenliegenden Netze an das Zielnetz und den Zielrechner darin zu schicken (welchen, wie oben erwähnt, TCP selbst nicht kennt) sowie einkommende Pakete entgegenzunehmen und an das TCP-Protokoll weiterzureichen, um so die von TCP erwartete logische Punkt-zu-Punkt-Verbindung bereitzustellen.


Dazu wird die IP-Adresse verwendet. IP interessiert sich nicht mehr für die Portnummer; hier zählt nur noch die IP-Adresse des anfragenden sowie die des Zielrechners.
"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
1

#4 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 7.767
  • Beigetreten: 20. Juli 07
  • Reputation: 859

geschrieben 19. August 2013 - 04:39

3.1 Wie geht das?

Um diese Frage zu beantworten, müssen wir uns IP-Adressen einmal genauer anschauen:

Zunächst gibt es derzeit zwei Spezifizierungen für IP-Adressen: einmal die klassifizierte und einmal die klassenlose.

Bei der KLASSIFIZIERTEN Methode wird die Gesamtheit der IP-Adressen nach einem relativ einfachen Schema in 5 Klassen (A-E) eingeteilt. Wenn jemand von einem Klasse-X-Netzwerk spricht, ist diese Klassifizierung gemeint:

Klasse A: Das erste Bit der IP (von links gesehen) ist 0.
Damit erhalten wir einen theoretischen Adressbereich von 0.0.0.0 - 127.255.255.255. Dieser Adressbereich war für "große Unternehmen" vorgesehen. Jedes der 2^7 (128) A-Netze beinhaltet 2^24 = 16.7 Millionen Adressen.
Innerhalb der A-Klasse gibt es einen einzelnen reservierten Bereich für die freie Vergabe, welcher nicht durch die Internet-Dienstanbieter geroutet werden darf: das ist dasjenige Netz mit der Kennung 10.0.0.0, das sogenannte Private Netz.

Klasse B: Das erste Bit der IP (wieder von links) ist 1 und das zweite ist 0.
Damit erhalten wir einen theoretischen Adressbereich von 128.0.0.0 - 191.255.255.255. Dieser Bereich war für "nicht ganz so große Unternehmen" gedacht. Die 2^14 (16384) B-Netze umfassen jeweils 2^16, also etwa 65.500 Adressen.
Auch hier gibt es einen Adressbereich, der für die Eigengebrauch reserviert ist: nämlich die 16 aufeinanderfolgenden Netze von 172.16.0.0 bis 172.31.0.0.

Klasse C: Die ersten beiden Bits der IP sind 1; das dritte 0.
Damit erhalten wir (wieder theoretisch) 192.0.0.0 - 223.255.255.255. Dieser Bereich war für mittelständische Unternehmen reserviert; die 2^21 (~ 2.1 Millionen) Netze umfassen jeweils 256 (2^8) Adressen.
Wie für die vorstehenden beiden Klassen gibt es auch hier einen privaten Bereich: nämlich genau 256 Netze von 192.168.0.0 bis 192.168.255.0.

Klasse D: Analog sind hier die ersten drei Bits jeweils 1 und das vierte 0;
das ergibt einen Bereich 224.0.0.0 - 239.255.255.255. Diese Adressen waren - und sind immer noch - für sogenannte Multicast-Adressen reserviert. (Auf die verschiedenen Adresstypen - Unicast, Multicast, Anycast, Broadcast -- soll hier bis auf Broadcast nicht weiter eingegangen werden. Nur soviel: "normale" IP-Adressen sind samt und sonders Unicast-Adressen. Über Multicast kann mit ihnen jedoch NICHT kommuniziert werden und können einer Netzwerkschnittstelle auch nicht manuell zugewiesen werden. Der interessierte Leser findet in den Tiefen des Internet-Protokolls etwas mehr Informationen hierzu.)

Und schließlich die Klasse E: die ersten vier Bits sind 1;
damit werden also alle übrigen IP-Adressen abgedeckt (von 240.0.0.0 - 255.255.255.255). Diese Adressen sind ungültig im Sinne von "normalen" IP-Adressen; sie sind reserviert von der Vergabestelle für IP-Adressen (der IANA = Internet Assigned Numbers Authority = sinngemäß Zuweisungsstelle für Internetnummern). Auch sie können im Netzwerk nicht vergeben werden.

Für die D- und die E-Klasse sind keine Netze definiert; beide sind einfache Adressblöcke.

Klassifizierte IPs unterscheiden sich praktisch von klassenlosen insbesondere dadurch, daß sie keiner Subnetzmaske bedürfen - diese ist implizit in der Klassendefinition selbst mit festgeschrieben: nämlich A.*.*.*, B.B.*.* und C.C.C.*, wobei die Werte für A, B und C vorgegeben werden und die Inhaber die Werte an den * selbst vergeben dürfen. Die Ausnahme bilden hier die privaten Adressbereiche; diese darf jeder nach freien Gutdünken selbst verwenden und verwalten - aber nur diese.

Aus der klassifizierten Methode erwuchsen schnell Probleme: die IP-Adressen gingen kurzfristigst aus. Da die Adressen klassifiziert waren und Adressbereiche immer in vollständigen Netzen vergeben wurden. Da es nur knapp 130 A-Netze gab, hieß das, daß auf ca. 130 Unternehmen die Hälfte des gesamten IP-Adressraums entfiel. Diese IP-Adressen waren auch nicht anderweitig vergebbar, egal, ob diese nun genutzt wurden oder nur herumlagen. Dazu kam dann, daß diejenigen, die Klasse-C Netzwerke bekommen sollten, mehr als rund 250 Rechner verwalten wollten - mehr passen aber in ein Klasse-C Netzwerk nicht hinein. Also bekamen sie ein -B Netzwerk zugewiesen - das waren dann aber üblicherweise viel zu viele IPs (B= 2^16 Adressen vs C= 2^8 Stück) mit dem Endergebnis, daß die B-Netze ebenso schnell ausgingen und nun noch mehr IP-Adressen unzuweisbar brachlagen.

Daher wurden die KLASSENLOSE IP-Adressierung und mit ihr die SUBNETZMASKE eingeführt. Damit wurden die Klassen irrelevant und man konnte Netzgrößen unabhängig von dessen Klasse festlegen: man konnte also aus dem einzelnen privaten A-Netz 10.0.0.0 mit seinen 2^24 (16.7 Millionen) IP-Adressen kleinere Teilnetze ("Subnetze") bauen, die sich dann wie ein "niederwertigeres" Netz verhielten. Dafür wird die Subnetzmaske verwendet.

Dieser Beitrag wurde von RalphS bearbeitet: 25. August 2013 - 17:55

"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
1

#5 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 7.767
  • Beigetreten: 20. Juli 07
  • Reputation: 859

geschrieben 19. August 2013 - 04:50

3.2 Was ist denn nun diese Subnetzmaske?

Jede IP-Adresse besteht, unsichtbar, aus zwei bzw. drei Teilen:
1. Der sogenannten Netz-ID. Das ist der Anteil, der von der IP-Vergabestelle zugewiesen wurde. Für die Netz-ID ist immer die erste IP im Bereich reserviert; das ist oft - aber beleibe nicht immer - die 0. Diese wird dann verwendet, um das Netzwerk als Ganzes anzugeben.
2. Der Subnetz-ID. Das sind kein oder mehrere Bits innerhalb der IP-Adresse, die unmittelbar auf die Netz-ID folgen. Sie dient dazu, um es dem Inhaber zu ermöglichen, innerhalb ihres zugewiesenen Bereiches weitere Teilnetze anzulegen. Für den Privatnutzer wird sie in 99.9% der Fälle weder gebraucht noch verwendet.
3. Die Host-ID. Das ist der restliche Teil der IP und gibt den eigentlichen Zielrechner im Netz (genauer: im Subnetz) an.

Um diese Teile voneinander unterscheiden zu können, gibt es die Subnetzmaske. Deren Bits sind über die gesamte Länge der Netz-ID (plus ggf. der Subnetz-ID) auf 1 gesetzt; der Bereich, der die Host-ID ausmacht, hat in der Subnetzmaske den Wert 0.
Wichtig: die Subnetzmaske ist in diesem Sinne nur genau EINMAL geteilt; es gibt links eine Anzahl von Einsen und rechts eine Anzahl von Nullen; in der Summe sind das immer 32 Stellen (da die IP 32bit lang ist); einzig die Aufteilung der Einsen und Nullen ist variabel.
Damit ist 255.0.0.0 (1111 1111 0000 ...b) eine gültige Subnetzmaske. 253.0.0.0 (1111 1101 0000 ....b) jedoch nicht.

Für die Darstellung werden zwei Schreibweisen verwendet: einmal die "gepunktete" Notation, zum Beispiel 255.0.0.0 ; und einmal die sogenannte Classless Inter-Domain Routing (CIDR) Notation, welche einfach die Anzahl der Eins-Bits der Subnetzmaske angibt und mit einem Schrägstrich eingeleitet wird, zum Beispiel /8.

Nochmal zur Veranschaulichung: die klassifizerten IPs stellen sich in der klassenlosen Schreibweise so dar:
A = bspw. 1.0.0.0 / 255.0.0.0 == 1.0.0.0/8
B = bspw. 130.3.0.0 / 255.255.0.0 == 130.3.0.0/16
C = bspw. 180.15.4.0 / 255.255.255.0 == 180.15.4.0/24

Und die privaten Bereiche:

A = 10.0.0.0 / 255.0.0.0, 10.0.0.0/8
B = 172.16.0.0 / 255.240.0.0, 172.16.0.0/12
C = 192.168.0.0 / 255.255.0.0, 192.168.0.0/16

Wie man unschwer erkennt, können die Netze hier zusammengefaßt werden, indem die Subnetzmaske einfach geändert wird - in Klasse A gibt es nur das eine Netz, aber in Klasse B und C können die 16 bzw. 256 einzelnen Teilnetze mit einer passenden Subnetzmaske einfach "zusammengeworfen" werden. Diesen Vorgang nennt man Supernetting; wenn also jemand diesen Begriff verwendet, meint er eigentlich nur, daß mehrere aufeinanderfolgende Netze zusammengelegt werden.
"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
1

#6 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 7.767
  • Beigetreten: 20. Juli 07
  • Reputation: 859

geschrieben 19. August 2013 - 05:02

3.3 Exkurs: Die Broadcast-Adresse

Damit werden alle im Netzwerk verfügbaren Adressen angesprochen; zum Beispiel dann, wenn es keine bekannte IP gibt, an die man sich wenden könnte. DHCP funktioniert über Broadcast - der Rechner hat ja noch keine IP und kennt auch die Netzwerkkonfiguration nicht; also muß er sinngemäß laut schreien, sodaß jeder ihn hört... und hoffen, daß jemand antwortet (= der DHCP-Server).

Per Definition ist Broadcast die LETZTE Adresse im Subnetz; üblicherweise - aber beileibe nicht immer - ist das die 255.

Dies bedeutet schlußendlich, daß in ein klassenloses Netzwerk immer 2^(32-n)-2 Adressen hineinpassen, wobei n die Länge der Netz-ID (nochmal zur Erinnerung: die Anzahl der Eins-Bits in der Subnetzmaske) ist. So passen beispielsweise in ein Netz, welches mit 192.168.0.0/30 bzw / 255.255.255.252 spezifiziert ist, genau ZWEI Geräte hinein: nämlich .1 und .2; die .0 und die .3 fallen jeweils für die Netz-ID und die Broadcastadresse weg. /31 wäre ein leeres Netz (die beiden möglichen Adressen wären bereits für die Netz-ID und die Broadcastadresse reserviert) und 192.168.0.1/32 spezifiziert exakt die Schnittstelle, die zu dieser IP gehört - mehr paßt in dieses "Netz" nämlich nicht hinein. Oder anders gesagt: Subnetzmasken, sind üblicherweise kleiner oder gleich 30 (also 255.255.255.252).

Nochmal zur Verdeutlichung:
* 192.168.0.0/30 wäre EIN Subnetz mit 4 IPs (.0-.3) und 2 möglichen Geräten (.1 und .2) darin.
* 192.168.0.4/30 wäre ein ANDERES Subnetz mit ebenfalls 4 IPs (.4-.7) und zwei möglichen Geräten (nämlich .5 und .6); hier wäre dann die .4 die Netz-ID und die .7 die Broadcastadresse und damit nicht vergebbar - auch wenn weder die eine den Wert 0 noch die andere den Wert 255 im letzten Oktett hat.
* Und, nicht zu vergessen: wenn nun der Rechner an der .1 mit dem an .6 kommunizieren will, geht das NUR über den Router, da die Netz-ID verschieden ist; wenn dieses Beispielnetz jedoch kein /30-Subnetz wäre, sondern ein "normales" /24-Subnetz (also mit der Subnetzmaske 255.255.255.0), wäre das NICHT der Fall.
* Der Vollständigkeit halber: beide Netze können zu einem zusammengefaßt werden, weil sie unmittelbar aufeinanderfolgen. Das wäre dann das Netz mit der Kennung 192.168.0.0/29.
"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
1

#7 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 7.767
  • Beigetreten: 20. Juli 07
  • Reputation: 859

geschrieben 19. August 2013 - 05:14

3.4 Routing - Wie die Pakete durchs die Netzwerke kommen

Routing ist die Kernaufgabe von IP und bezeichnet die Art und Weise, wie die Datenpakete durch die einzelnen Teilnetze immer weitergereicht werden, bis sie irgendwann am Bestimmungsort angelangt sind.

Dazu werden Routen verwendet. Am einfachsten kann man sich so eine Route als eine Regel nach folgendem Schema vorstellen:

1. Wenn ein Paket mit der Ziel-Netz-ID X ankommt...
2. ... Wird in eine Tabelle geschaut, ob ein passender Eintrag vorhanden ist, und...
3. ... Das Paket entsprechend der Regel an den dem eigentlichen Ziel näherliegenden Router weitergeleitet; und zwar genau DEN Router, der direkt an den aktuellen Router angeschlossen ist (heißt: es befindet sich kein weiterer Router zwischen ihnen).
4. Wenn das Paket das Gerät verlassen hat, wird es "vergessen" und das nächste wird in die Hand genommen.

Ein bißchen anschaulicher: wenn man mit dem Auto von Potsdam nach Stuttgart will (als IP-Paket), interessiert einen immer nur das aktuelle Teilstück der Strecke (Route): zunächst muß man von seinem Startpunkt auf die nächste Autobahnabfahrt gelangen (über mehrere Kreuzungen = Router); dann wissen wir zwar nicht, wie wir von dort nach Stuttgart kommen, aber wir wissen, daß wir über Berlin müssen - also fahren wir erstmal da hin und schauen weiter (das ist unser nächster Router) während wir unseren bisherigen, nun hinter uns liegenden Weg vergessen; von dort werden wir nach München geleitet (nächster Router) -an welcher Stelle wir die Situation in und um Berlin ebenfalls vergessen- und von da mehr oder weniger direkt (über weitere Router) ans Ziel in Stuttgart. Darüberhinaus: wenn wir mit mehreren Autos fahren (mehrere IP-Pakete), ist zwar nicht unbedingt klar, ob jedes Auto denselben Weg nimmt (einer fährt vielleicht über die A2 und die A7); aber am Ende kommen trotzdem alle an (allerdings ist nicht unbedingt klar, in welcher Reihenfolge => Streckenlänge, Stau, etc).

Und wenn man an dieser Stelle die Passagiere als Nutzlast versteht, könnte man das mit den TCP-Paketen gleichsetzen: denn das Auto interessiert ja auch nicht, wieviele Fahrgäste oder sonstiges Gepäck da drin sitzen / liegen oder wie die aussehen - es fährt einfach als Einheit und nimmt alles mit, was drin ist. Außerdem obliegt es ebenfalls den Passagieren, die Zusammenhänge NACH der Reise wiederherzustellen (Ehefrau in dem Auto und Sohn in dem und Tochter dort == ergo, wir müssen auf mehrere Autos (Pakete) warten und die Gesamtladung (die Familie) selbstständig wiederherstellen; das macht das Auto (= IP) NICHT für uns.


Im Beispiel wäre die Startadressse (Potsdam) die Quell-IP-Adresse und die Zieladresse (Stuttgart) die Ziel-IP-Adresse. Damit wird vielleicht auch klarer, daß IPs eindeutig sein müssen: denn die Netz-IDs verhalten sich wie Telefonvorwahlen (oder Postleitzahlen), Subnetz-IDs zu einzelnen Postleitzahlen innerhalb einer Großstadt - können vorhanden sein, müssen aber nicht - aber wenn sie da sind, sind sie wichtig; und die Host-IDs schließlich geben das Haus an, welches gefunden werden soll (also Straße+Hausnummer).


Nochmal zur Erinnerung: IPs bestehen aus einer Netz- und einer Host-ID; wenn also zwei IP-Adressen genau gleich sind, muß davon ausgegangen werden, daß sie im selben Subnetz zu finden sind (da Netz-ID (PLZ) gleich) und dieselbe Maschine bezeichnen (da Host-ID (Straße+Hausnummer) gleich); anders gesagt: eine IP bezeichnet immer genau DEN EINEN Rechner (etwas genauer: seine Netzwerkschnittstelle) und niemals mehrere (wenn zwei UNTERSCHIEDLICHE Telefone dieselbe Vorwahl und Rufnummer haben, geht das auch schief).
Ausnahmen bilden hier Netzwerkcluster; aber auch das sind letztlich "nur" mehrere Netzwerkschnittstellen, die logisch zu einer zusammengefaßt wurden.


Und noch etwas anderes geht hieraus hoffentlich hervor: innerhalb EINES Subnetzes müssen ALLE Rechner dieselbe Netz-ID haben - müssen also über die gesamte Länge der Subnetzmaske identisch sein -- und sich im Hostbereich unterscheiden; und analog MÜSSEN sich die Netz-IDs unterscheiden, wenn sich ein Router ZWISCHEN den Rechnern befindet.

Vorsicht: handelsübliche Router sind keine Router im eigentlichen Sinne, sondern Kombigeräte aus Router und Switch; "ein WAN-Port und 4 LAN-Ports" heißt hier, daß an den Router ZWEI Netze angeschlossen werden können (WAN und LAN) und daß auf der LAN-Seite ein Switch eingebaut ist (mit 4 Ports = Netzwerkbuchsen). Heißt ganz genau: wenn es einen Rechner auf der WAN-Seite gibt und einen auf der LAN-Seite, dann MUß die Netz-ID verschieden sein; wenn sie aber auf der GLEICHEN Seite stehen (üblicherweise auf der LAN-Seite) dann MUß die Netz-ID GLEICH sein und die Host-ID verschieden. Anderenfalls kann der fragliche Rechner nicht angesprochen werden, weil der Router die Pakete dorthin weiterleitet, wo er den Rechner anhand seiner Netz-ID vermutet (dieser aber da nicht steht) oder es schlicht und ergreifend eine Kollision gibt, weil die Host-ID gleich ist und nicht mehr aufgelöst werden kann, WELCHER Rechner denn nun gemeint war.

Was passiert eigentlich, wenn ich zuhause IPs außerhalb der für den Privatgebrauch reservierten Bereiche verwende?

Diese Frage sollte sich mit Hilfe der vorstehenden Absätze beantworten lassen:
wenn das Netz zuhause zum Beispiel auf die Netz-Id 123.0.0.0/8 hört, dann passiert einfach folgendes: man kann dann keinen der Rechner erreichen, denen offiziell diese Netzkennung zugewiesen wurde. Warum? Weil der Router, der eine Anfrage nach beispielsweise 123.1.2.3 erhält, das mit seiner eigenen Kennung vergleicht und feststellt: halt, Moment, das ist ja mein Netz. Das muß ich nicht rausschicken. Das Ergebnis ist dann, daß versucht wird, die IP 123.1.2.3 im eigenen Netz zu erreichen... und nur da.
Andersherum hat das natürlich keinen Einfluß, da es ja keine Route gibt, die Anfragen nach 123.0.0.0/8 von ANDEREN an den eigenen Router schicken; diese gehen ordnungsgemäß ans richtige Ziel.
"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
2

#8 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 7.767
  • Beigetreten: 20. Juli 07
  • Reputation: 859

geschrieben 19. August 2013 - 05:27

Der Standardgateway

ist, einfach gesagt, eine Art Catch-All Adresse, die statt Routen verwendet werden kann (und wird). Hier werden alle Pakete hingeschickt, die nicht aufgelöst werden können (im Klartext: die Pakete, für die ARP keine MAC auflösen kann und für die keine Route existiert - das ist auch der Grund, warum in netzfremden Paketen keine Ziel-MAC-Adresse drinsteht; sie ist dem Absender schlicht und ergreifend unbekannt). Statt eines Gateways könnte man auch Routen konfigurieren, die dann die IPs anhand ihrer Beschaffenheit ins Netzwerk schicken.
Haken an der Sache - wenn man das so nennen kann: üblicherweise existiert in einem Heimnetz nur genau ein Router, der weiterleiten kann - das ist der, der am DSL/Kabel/XXX-Modem hängt. Mit anderen Worten: konfigurierte Routen würden am Ende genau dasselbe tun wie der viel einfacher zu konfigurierende Standardgateway; ob jetzt "dieses Netz" und "jenes Netz" und "dieses andere Netz da" jeweils entsprechend der Routenkonfiguration immer an diesen einen Router weitergeleitet werden oder ob man einfach sagt: alles was ich nicht kenne, soll DA hin macht praktisch keinen Unterschied.
"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
1

#9 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 7.767
  • Beigetreten: 20. Juli 07
  • Reputation: 859

geschrieben 19. August 2013 - 05:38

Exkurs: ARP - Address Resolution Protocol -- Adressenauflösungsprotokoll

IP-Adressen sind logische Konstrukte, die aber, wie eben erwähnt, fest mit einer Netzwerkschnittstelle verbunden werden. Solche Netzwerkschnittstellen haben ebenfalls eine Adresse, die sogenannte MAC-Adresse (Media Access Control = Medienzugriffssteuerung). Diese sind, zumindest in der Theorie, global eindeutig.
Über MAC-Adressen funktioniert die Zustellung im eigenen Subnetz, wo sie tatsächlich eindeutig sein müssen (ebenso wie IP-Adressen). Sie werden jedoch nicht geroutet: auf diesem Weg werden auch "eigene" von "fremden" Paketen unterschieden: in lokalen Pakete steht eine MAC-Adresse drin; in netz-fremden Pakete aber nicht.

Eine Netzwerkschnittstelle kann aber, physisch, NUR über die MAC-Adresse angesprochen werden; es muß also eine Übersetzung stattfinden zwischen IP-Adresse und MAC-Adresse; insbesondere dann, wenn das Paket von außen kam. Das besorgt das Address Resolution Protocol (ARP). Wie diese Zuordnung aussieht, bekommt man mit dem Befehl arp -a heraus (Windows und *NIX).

NB. Hier ist auch der tatsächliche Grund zu suchen, warum EINE IP an ZWEI Netzwerkschnittstellen schiefgeht: entweder gibt ARP unbestimmbare Zieladressen zurück und der Gesamtzustand ist undefiniert; oder ARP gibt für die eine IP-Adresse mehrere MAC-Adressen zurück; das hieße dann, das da Strom in einer Form fließt, in der er aber nicht fließen sollte und es crasht auf der Leitung.

ARP baut damit die Brücke zwischen dem TCP/IP-Protokollstapel insgesamt und der darunterliegenden Ebene (Richtung Hardware).
"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
1

#10 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 7.767
  • Beigetreten: 20. Juli 07
  • Reputation: 859

geschrieben 19. August 2013 - 05:54

Typische IP-Probleme und deren Behebung

- Was leider gerne vergessen wird: IP liegt mehr oder weniger allen anderen Anwendungen zugrunde: wenn es also auf IP-Ebene hakt, werden weder Websites noch Emails noch FTP-Daten noch sonst etwas abrufbar sein. Erst wenn auf der IP-Ebene alles paßt, kann man sich den darüberliegenden Anwendungen widmen und schauen, ob es dort noch Probleme gibt. Einfachster Vergleich: wenn man das Netzwerkkabel hinten rauszieht, geht winfuture-forum.de nicht... egal, was man tut; solange wie das Kabel draußen ist, wird sich an der Symptomatik überhaupt nichts ändern. (WLAN übernimmt in diesem Zusammenhang übrigens die Rolle des Kabels - ohne stehende WLAN-Verbindung gibt es kein funktionierendes IP.)


- Ein bestimmter Zielrechner ist insgesamt nicht erreichbar:
Hier empfiehlt es sich immer, zunächst die Firewall abzuschalten, damit diese nicht bei der Fehlersuche stört - möglicherweise blockt sie Pinganforderungen und man sucht auch dann noch Fehler, wo es gar keine gibt. Wenn das nichts hilft, besteht eine gute Chance, daß der Rechner am anderen Ende ein ernsthafteres (Netzwerk)Konfigurationsproblem hat... oder er so konfiguriert ist, daß er nicht auf Ping-Anfragen antworten darf.

- Gar kein Rechner ist erreichbar:
IP-Konfiguration überprüfen - das heißt im Klartext: Adresse, Subnetzmaske und Standardgateway (soweit es um Zugriff auf externe Ressourcen geht).
- Stimmt die Netz-ID für alle Rechner im Subnetz überein? Das heißt auch: stimmt die Subnetzmaske für alle Rechner im Netz überein? Wenn nicht, kann es daran durchaus liegen.
- Ist die Host-ID eindeutig - beziehungsweise etwas allgemeiner: sind die IP-Adressen insgesamt eindeutig? Wenn nicht, geht es schief.
- Erreiche ich andere Geräte in meinem Subnetz, komme aber nicht raus? Das kann dann am fehlenden bzw falschen Standardgatewayeintrag liegen (bzw weitergehend: daran, daß eine ungültige Route eingetragen wurde). Hierfür gibt es den tracert-Befehl (Windows) bzw traceroute (*NIX) - dieser gibt Auskunft darüber, über welche Router mein Paket gesendet wird. Wenn schon die erste Zeile einen Fehler auswirft, liegt das daran, daß der eigene Router nicht erreicht wird (oder, falls dort eine falsche IP ausgewiesen wird, stimmt der Standardgateway nicht bzw eine Route ist eingetragen, die sich um das Paket kümmern soll und aber nicht zum Ziel führt). Etwas weitergehen sieht man hier auch, ob der eigene Router in etwa so weiterleitet, wie er soll: wenn die ZWEITE Zeile einen Fehler wirft, ist entweder der Router selbst falsch konfiguriert oder (wahrscheinlicher) die Verbindung nach draußen ist zusammengebrochen und der Router des ISP ist nicht erreichbar. In einer Standardkonfiguration kann man davon ausgehen, daß man auf Fehler ab der zweiten Zeile KEINEN Einfluß mehr hat - das ist zwar ärgerlich, kann aber auch ungemein beruhigen, weil man dann sicher sagen kann: okay, es geht nicht; aber es liegt NICHT an mir.

- Läßt sich ein gesamtes Subnetz nicht erreichen, liegt das in den allermeisten Fällen an der Routerkonfiguration - die einzige Frage, die sich stellt, ist: welcher Unterwegs-Router ist schuld. Zumindest diese Frage läßt sich mit traceroute beantworten; irgendwann in der Liste gibt es dann erwartungsgemäß Timeouts oder andere Fehler. Dann betrachtet man den letzten erfolgreichen Eintrag und den ersten nicht-erfolgreichen; eines dieser beiden Geräte ist dann der Übeltäter (welches, kann man allerdings nicht genau vorhersagen: entweder hat der erste falsch weitergeleitet und der zweite Router weiß nichts mit dem Paket anzufangen; oder der erste hat ordentliche Arbeit geleistet und der zweite ist fehlkonfiguriert). Hier muß man dann anhand der Ausgabe schauen, ob die fraglichen Router der eigenen Kontrolle unterliegen (und man das Problem selber lösen kann bzw muß) oder ob wer anders für den Fehler bzw. dessen Behebung verantwortlich ist.
"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
1

#11 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 7.767
  • Beigetreten: 20. Juli 07
  • Reputation: 859

geschrieben 25. August 2013 - 17:53

In den Tiefen des Internet-Protokolls: Adresstypen (in Kurzform)

Was folgt, ist ein Exkurs in die Tiefen des Internet-Protokolls, der für den "normalen" Nutzer nicht von Bedeutung ist; für den an Netzwerktechnik interessierten Leser finden sich allerdings etwas tiefergehende Informationen.

Es existieren mehrere IP-Adresstypen. Diese unterscheiden sich insbesondere dadurch, wie die Kommunikation zwischen ihnen aussieht.

[*] Unicast-Adresse.
Derjenige Adresstyp, der für Verbindungen mit jeweils EINEM Start- und Endknoten (= Netzwerkgerät) verwendet wird. Genauer: es ist ein 1:1-Mapping; ein Gerät kommuniziert mit einem anderen.

[*] Broadcast-Adresse.
Derjenige Adresstyp, der für Verbindungen von EINEM Startknoten zu allen im Subnetz verfügbaren Endknoten verwendet wird. Wie eine Radiosendung (Broadcast) weiß der Sender nichts über den Empfänger; er sendet einfach drauflos und "irgendwer wird's schon mitkriegen". Dies ist ein sogenanntes 1:viele-Mapping.
Wie schon angemerkt: die Broadcastadresse ist immer die LETZTE IP-Adresse im Subnetz.
DHCP funktioniert fast ausschließlich über Broadcast.

[*] Multicast-Adresse.
Eine Gruppen-Adresse, die für Verbindungen mit EINEM Start- und MEHREREN Endknoten verwendet wird. Im Unterschied zu Broadcast-Verbindungen weiß hier aber der Sender über die Empfänger Bescheid; diese müssen sich für die Verbindung registrieren (erst dann erhalten sie eine für diese Verbindung gültige Multicast-Adresse aus der Klasse D.) Eine Multicast-Verbindung unterscheidet sich von mehreren Unicast-Verbindungen insbesondere dadurch, daß der Sender (normalerweise ein Server) seine Daten nur genau EINMAL (statt so oft, wie Empfänger da sind) losschicken muß.
Wie schon angedeutet, stammen Multicastadressen aus der Klasse D; also dem Bereich von 224.0.0.0 bis 239.255.255.255.
Softwareverteilung in Unternehmen und serverbasierte Backuplösungen funktionieren oft über Multicast.

[*] Anycast-Adresse.
Der Adresstyp, der für Verbindungen von einem bekannten Sender zu einem nicht unmittelbar bekanntem Empfänger verwendet wird. Anycastverbindungen sind auf den ersten Blick mit Unicast-Verbindungen identisch; der Unterschied ist, daß die Ziel-IP-Adresse nicht zu einem, sondern zu mehreren, nicht bestimmbaren Netzwerkknoten gehört. Das sind beispielsweise Netzwerkcluster; also mehrere Server, die zu einem logischen Verbund zusammengeschaltet wurden. Multicast und Anycast sind beides 1:n-Mappings - ein Sender, n viele Empfänger; der Unterschied ist insbesondere, daß bei Multicast die Empfänger bekannt sein MÜSSEN und bei Anycast NICHT bekannt sein KÖNNEN.
Anycastadressen unterscheiden sich nicht sichtbar von Unicastadressen, folgen also derselben Einteilung wie diese.
Die DNS-Rootserver funktionieren beispielsweise über Anycast.
"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
1

#12 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 7.767
  • Beigetreten: 20. Juli 07
  • Reputation: 859

geschrieben 12. November 2013 - 19:30

Bindeglieder des TCP-IP-Protokollstapels: DNS und DHCP

Bisher ging es in erster Linie um die Protokolle TCP und IP aus der gleichnamigen Protokollsuite, sowie - in Ansätzen - um eines der Bindeglieder an die darunterliegende Netzwerkebene, das Data Link Layer (die Datenverknüpfungsschicht, die nicht mehr Bestandteil des TCP-IP-Protokollstapels ist). Das war ARP, welches auf jedem Rechner die MAC-Adresse der Netzwerkkarte mit der ihr zugeordneten IP-Adresse verbindet.

Wenden wir uns nun für einen Moment der Konfiguration zu - und zwar beidseitig, einmal von 'oben' aus Sicht der Anwendungen (und Benutzer) und einmal von unten (aus Sicht der Maschine).

Das sind diejenigen Dienste, die den Geräten im Netzwerk (üblicherweise, wie in einem echten Netz, 'Knoten' genannt) eine zu diesem Netzwerk passende Konfiguration zuweisen: und zwar zum einen so, daß die Knoten selbst eine gültige Konfiguration erhalten und zum anderen, daß die Anwendungen (und weitergehend die Benutzer) eine Konfiguration erhalten, sodaß sie sich - und zwar unabhängig von der Maschinenkonfiguration - im Netzwerk bewegen können.

Das ist zum einen das dynamische Host-Konfigurations-Protokoll (DHCP) und zum anderen das Domänennamenssystem (DNS), die in diesem Sinne zusammenarbeiten und, wenn man so will, zusammengehören.

Beide tun letztlich genau daselbe: sie ordnen Adresstypen einander zu, setzen aber jeweils am entgegengesetzten Ende des Protokollstapels an: DNS bildet die Brücke zwischen leicht verständlichen Namen und IP-Adressen, während DHCP die Brücke zwischen IP-Adressen und MAC-Adressen schlägt.

Beide führen Buch über diese Zuordnungen, und beide gestatten es, diese Zuordnung entweder statisch von Hand oder aber vollautomatisch und letztlich ungesteuert vornehmen zu lassen. Eine Kombination aus beidem ist natürlich ebenso möglich (das ist sogar die überwiegend verwendete Konfiguration).

Beides zusammen ermöglicht es, sich sein TCP-IP-Netzwerk faktisch "wie von selbst" konfigurieren zu lassen - aber mit dem Zusatz, daß es trotzdem ohne weitere Eingriffe "einfach läuft", obwohl man die spezifische Konfiguration der einzelnen Netzgeräte nicht mehr unbedingt kennt (bzw. kennen muß).

- Für die Konfiguration im Netz sorgt DHCP.
- Für die Abstraktion, d.h. also für die Trennung der Namensebene von der IP-Konfiguration, sorgt DNS.

Hier soll es wirklich NUR um DHCP und DNS als Abstraktionsebenen im TCP-IP-Netz gehen; alles andere würde den Rahmen bei Weitem sprengen. Beide Anwendungsgebiete füllen für sich genommen bereits Bücher. So detailliert kann und soll das hier nicht werden.


DHCP
stellt jedem Gerät im Netzwerk für eine bestimmte Zeit eine bestimmte Konfiguration zur Verfügung. Diese Zuordnung wird Lease genannt - so wie man beispielsweise auch ein Auto least, so 'least' ein Netzwerkgerät seine Konfiguration vom DHCP-Server.

Wichtig hierbei ist a) die Zeitkomponente - Leases haben ein Ablaufdatum --- und b) der Datensatz, der dem Netzwerkgerät zugeteilt wird. Der Datensatz ist, anschaulich, einfach ein Array aus Schlüsseln ("DHCP-Optionen") und dessen Werten, von dem die IP-Adresse selbst einer ist (aber nicht als DHCP-Option verstanden wird).
Die wichtigsten dieser Optionen sind sicherlich einmal die Option 3 (der Router- / Gateway-Eintrag), die Option 6 (eine Liste von DNS-Servern, die das Gerät verwenden soll) sowie die Option 15 (das ist der DNS-Domänenname des Gerätes (NICHT der Hostname, nur der Domänennname). Mit diesen drei Optionen läßt sich ein Netzwerkgerät bereits so konfigurieren, daß es in einer DNS-Domäne automatisch registriert werden kann (Option 15) und wo (Option 6) und es aus dem lokalen Subnetz herauskommt (zB ins Internet) (Option 3). Weitergehend kann man aber auch noch einen Zeitserver mitgeben, von dem er seine Uhrzeit holen soll oder eine Netzwerk-Bootkonfiguration, damit der Rechner vollautomatisch den Weg ins Netz finden kann, sich dort eine gültige Startdatei holen kann und letztlich, ohne auch nur ein einziges Mal auf seinen eigenen Festspeicher zugreifen zu müssen, ein Betriebssystem aus dem Netzwerk laden und ausführen kann.
Es gibt über 100 solcher DHCP-Optionen - und das sind nur die vordefinierten. Es steht dem Administrator des DHCP-Servers frei, weitere Optionen zu definieren und vorhandene anzupassen. Allen voran sind das die Benutzerklassen, mit denen Rechner automatisch in Rechnergruppen gesteckt und gemeinsam, aber unabhängig von anderen Gruppen konfiguriert werden können.


Bevor eine zugewiesene Lease abläuft, wird sie erneuert, falls das Gerät denn noch im Netzwerk vorhanden ist (und nicht alsgeschaltet wurde oder das Netz verlassen hat (WLAN)). In diesem Fall wird die Adresse nach einer Weile einfach neu vergeben - und zwar (standardmäßig) an das nächste Gerät, das eine Adresse haben will.

Das ist auch der Grund, warum Buch geführt werden muß über die Vergabe der Leases: der DHCP-Server muß wissen, wer welche Adresse hat, wie lange noch, ob und wann er nochmal nachfragen muß, oder ob es abgelaufene Leases gibt, die er neu vergeben kann.

NB: Weil der DHCP-Server SELBST Buch führt, rumst es, wenn man händisch Adressen aus seinem Bereich vergibt. Denn diese kennt er nicht (und prüft sie auch nicht ab) sodaß es "irgendwann" tatsächlich passieren WIRD, daß "diese konkrete Adresse" mehrfach vergeben ist: nämlich einmal die statisch zugewiesene und einmal die vom DHCP-Server zugeteilte, und wie weiter oben bereits dargelegt, geht das schmerzhaft schief.

Genauso übrigens, wenn MEHR als ein DHCP-Server im Netz ist. Dieser weiß nämlich nichts davon, was sein Kollege bereits vergeben hat - und es besteht auch keine Möglichkeit, ein Gerät an einen spezifischen DHCP-Server zu "binden", wenn mehrere davon da sind. Hier gilt dann einfach: wer zuerst kommt, mahlt zuerst. Man kann sich vielleicht vorstellen, daß ZWEI DHCP-Server, die auch DENSELBEN Adressbereich bedienen, das Netzwerk eher lahmlegen als lauffähig machen.

Warum eigentlich, bzw. warum eigentlich nicht?

Das liegt an der Funktionsweise von DHCP, welche systemisch begründet ist: DHCP ist insbesondere dafür da, Rechnern IP-Adressen zu geben. Das heißt: um dies zu erreichen, kann das IP-Protokoll selbst NICHT (ohne weiteres) verwendet werden... denn es gibt ja noch keine IP-Adressen. Die sollen ja erst vergeben werden.

DHCP funktioniert daher auf IP-Ebene nur und ausschließlich über Broadcast - das ist die einzige Möglichkeit, auf dieser Ebene einen Rechner anzusprechen, der nicht bekannt ist (mehr dazu im entsprechenden Abschnitt weiter oben).
Die eigentliche Zuordnung funktioniert aber auf MAC-Adressbasis: ein 'bedürftiger' Rechner schickt seine MAC-Adresse in einem speziellen Paket blindlings ins Netz (an die Broadcast-Adresse 255.255.255.255, die alle vorhandenen Rechner im Netz erreicht). Das ist das 'Entdeckungspaket', DHCPDISCOVER. Es antwortet darauf der DHCP-Server (die restlichen Geräte verwerfen es). Gibt es mehrere DHCP-Server, antworten eben alle und dann kommt es darauf an, welche Antwort zuerst beim Anfrager ankommt - das nennt man eine Race Condition, weil es ein 'Wettrennen' mit ungewissem Ausgang ist und NICHT klar ist, wer denn der Erste sein wird - diesmal war es vielleicht #1, aber nächstes Mal ist es dann möglicherweise #2, #4 oder #3. Oder gar #5.
Wenn diese erste Kommunikation erstmal zustande gekommen ist, fliegen alle anderen evtl. vorhandenen DHCP-Server aus der Kommunikation raus - aber sie werden immer noch mit Paketen versorgt, weil die Kommunikation weiterhin NUR über Broadcast funktioniert (denn der neue Rechner hat ja nach wie vor keine gültige IP). Der "richtige" DHCP-Server und das neue Gerät identifizieren sich dann über die mitgelieferte MAC-Adresse.

Insgesamt setzt DHCP auf ein sogenanntes Vier-Wege-Handshake, das heißt also, es müssen insgesamt genau VIER Pakete über die Leitung gegangen sein, bevor Erfolg (oder Fehlschlag) gemeldet werden können. Dies sind das erwähnte DHCPDISCOVER (neu -> DHCP), ein unverbindliches Angebot DHCPOFFER (DHCP -> neu), die konkrete Anforderung des gemachten Angebots DHCPREQUEST (neu -> DHCP) und die Bestätigung DHCPACK bzw. die Ablehnung DHCPNAK (DHCP -> neu). Erst dann hat das neue Gerät eine gültige Konfiguration, die auch verwendet werden darf; bis dahin muß über Broadcast kommuniziert und über MAC identifiziert werden.

Dieser Beitrag wurde von RalphS bearbeitet: 13. November 2013 - 03:39

"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
1

#13 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 7.767
  • Beigetreten: 20. Juli 07
  • Reputation: 859

geschrieben 13. November 2013 - 03:26

DNS
Wie bereits angedeutet, beschränken wir uns hier lediglich auf einen kleinen Teilaspekt des Domänennamenssystems: nämlich der dynamischen Namenszuteilung (auch DynDNS genannt).

Rein formal ist der Vorgang genau derselbe wie bei DHCP: die Maschine hat einen Namen (dieser wurde ihr selbst bereits zugewiesen) und eine IP-Adresse (die jedoch nicht statisch ist); der DNS-Dienst sorgt nun dafür, daß (im Gegensatz zum klassischen DNS) dem statischen Namen diese Adresse zugeordnet wird, und zwar ebenfalls mit einem Ablaufdatum. Je nach Konfiguration kann das mehr oder weniger sicher passieren (abhängig davon, ob sich das fragliche Netzgerät irgendwo authentifizieren kann oder nicht) und der Ablauf hängt ebenfalls von der Konfiguration (oder ggf. den Fähigkeiten) des Netzgerätes zussammen (insbesondere wenn es darum geht, WER denn den Namen zur neuen IP zuordnet: entweder der Rechner selbst, oder derjenige DHCP-Server im Auftrag, welcher auch die Lease verteilt hatte).

Das ist eigentlich auch schon alles. Abgesehen von der Absicherung der DNS-Domäne selbst und der Aktivierung der dynamischen Updates muß man dazu (fast) nichts weiter tun (zumindest dann, wenn dem Netzgerät bereits der richtige Domänenname via DHCP zugewiesen wurde - siehe weiter oben).

Das Endergebnis davon ist dann schlußendlich:
1. Der DHCP-Server gibt für alle Geräte dieselbe Konfiguration aus (insbesondere den Domänennamen und die Adresse des DNS-Servers).
2. Alle Geräte im Netz erhalten ihre Konfiguration vom DHCP-Server.
3. Wegen (1) und (2) versuchen nun alle Geräte, Namen über den in (1) festgelegten DNS-Server aufzulösen und, sollten sie sich neu registrieren müssen, dies auch über diesen DNS-Server zu tun (soweit sie können/dürfen).
4. Der DNS-Name ist von der eigentlichen Adresse abgekoppelt, weil neue IP-Adressen sofort auf den alten Namen registriert werden und damit keine Beziehung mehr zwischen dem bekannten Namen und der nun nicht mehr gültigen Adresse besteht.

Das ist der eigentliche Vorteil eines DNS-Servers im Heimnetz, wenn man DHCP ebenfalls verwendet (und nicht nur Windows, sondern auch Linux, Android, irgendwelche eingebetteten Systeme wie TVs, Blu-ray Player, Drucker und so weiter verwendet: man kann die IP-Adressen vergessen (muß man sogar, da sie nur zeitlich eingeschränkt bekannt sind) und kann jederzeit seine Geräte über den einmal zugewiesenen Namen erreichen, egal wie letztlich die jeweilige Maschine an ihren Namen kam.

Und noch einen weiteren Aspekt sollte man im Hinterkopf behalten: man kann sich seine Firewall durchaus so konfigurieren, daß DNS *nur und ausschließlich* im lokalen Netz erreichbar sein soll. An diesem konfiguriert man dann eine Weiterleitung für unbekannte Adressen (an den Internetdienstanbieter). Jeder handelsübliche Router, auf dem der DHCP läüft, arbeitet so.

Nun mag das auf den ersten Blick trivial und/oder nutzlos erscheinen. Aber man schiebt damit der DNS-Manipulation zumindest auf der letzten Meile einen Riegel vor: wenn irgendeine Malware die DNS-Konfiguration am Endknoten (also am PC, Laptop etc) auf einen fremden DNS-Server umbiegt, klappt das zwar; aber dieser DNS-Server kann wegen der Firewall nicht mehr angesprochen werden. Dann geht die Namensauflösung nicht mehr - spätestens dann wird man hellhörig werden und schauen, was zur Hölle an einer automatischen Konfiguration denn nicht hinhauen könnte. Dann merkt man das gleich, und kann sich zumindest insoweit sicher sein, daß die Kontodaten nicht aus *eigenem* Verschulden auf einem fremden Server landen, weil da ein manipulierter DNS-Server untergeschoben wurde.

Okay, und wie geht das mit der Registrierung vonstatten?
Der eigentliche Registrierungsvorgang hängt insbesondere davon ab, ob authentifiziert werden muß oder nicht.

- Wenn nicht, wird im einfachsten Fall einfach eine Anforderung losgeschickt "das ist mein Name, die IP hab ich, registrier das mal" und von da an interessiert es die neue Maschine nicht mehr, was da passiert.
Auf der (DNS-)Serverseite muß dann zumindest die zugehörige DNS-Domäne bekannt und konfiguriert sein. Irgendwo muß das Gerät ja eingetragen werden können.

- Wenn doch, müssen zunächst ein paar Anforderungen erfüllt sein - insbesondere muß das Gerät zusätzlich ein Konto in einer sogenannten Authentifizierungsdomäne haben. Das ist unter Windows das Active Directory und unter *NIX beispielsweise Kerberos (wobei anzumerken ist, daß auch das Active Directory Kerberos für die Authenzifizierung verwendet - aber es gibt halt feine Unterschiede im 'Wie'). Grundlegend:
1. Der Rechner versucht sich zu registrieren (wie oben).
2. Der DNS-Server sagt, Nö mach ich nicht, beweis mir erstmal, daß Du auch wirklich DU bist.
3. Der Rechner hält dem DNS-Server gültige Anmeldedaten hin (üblicherweise ein passendes Kerberos-Ticket) - wenn er diese hat.
4. Der DNS-Server prüft diese Daten (bzw. läßt sie prüfen) und versieht, falls die Authentifizierung durchgeht, die DNS-Konfiguration mit einer Signatur, die die Konfigurationsdaten mit ganz genau DIESER Maschine verbindet (ohne Authentifizierung wäre dies nicht möglich). Dies stellt sicher, daß wirklich nur DIESE konkrete Maschine DIESE Registrierung vornehmen DARF; bzw. anders formuliert: unbekannte Rechner bekommen keine DNS-Registrierung, und wenn Bösewicht A ankommt und seinen Laptop namens "login.winfuture-forum.de" im Netz registrieren will, damit Anmeldedaten an IHN gehen (und er Benutzernamen und Paßwörter im Klartext abgreifen kann) dann wird ihm das mangels Authentifizierung einfach verweigert.

Unter Windows funktioniert das mehr oder weniger vollautomatisch, wenn ein Rechner in eine (Windows-)Domain gesteckt wird. Dann gibt es dort ein Computerkonto, welches dem Gerät zugeordnet ist; damit kann sich das Gerät dann am DNS-Server authentifizieren.

Unter *NIX ist es etwas umständlicher. Dort muß man Kerberos selbst konfigurieren - und das ist nicht unbedingt trivial, denn Kerberos hängt selbst von einer funktionierenden DNS-Konfiguration ab: ohne DNS kein Kerberos, und ohne Kerberos keine sichere Anmeldung.

Dieser Beitrag wurde von RalphS bearbeitet: 13. November 2013 - 03:49

"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
1

Thema verteilen:


Seite 1 von 1

1 Besucher lesen dieses Thema
Mitglieder: 0, Gäste: 1, unsichtbare Mitglieder: 0