Routing (Netzwerkgrundlagen) – Anwendungsentwickler-Podcast #140

Dieser Beitrag ist Teil 4 von 5 in der Serie Netzwerkgrundlagen.

Um private IP-Adressbereiche und das Routing von Netzwerkpaketen geht es in der einhundertvierzigsten Episode des Anwendungsentwickler-Podcasts.

Probeabo bei Audible (Affiliate)

Inhalt

Private IP-Adressbereiche

  • Da es im aktuellen Standard IPv4 nicht genug IP-Adressen für alle Teilnehmer auf der Welt gibt, muss eine Möglichkeit geschaffen werden, IP-Adressen abgeschlossen vom Internet zu vergeben, um interne Netzwerke betreiben zu können.
  • Es gibt einige fest definierte IP-Adressbereiche, die im Internet nicht verfügbar sind: die privaten IP-Adressbereiche 10.0.0.0, 172.16.0.0 (bzw. genauer 172.16.0.0 bis 172.31.255.255) und 192.168.0.0.
  • Aber wenn sie im Internet nicht verfügbar sind, wie kommt man dann ins Netz?

Routing und NAT

  • Es wird ein Gerät benötigt, dass zwischen das private und das öffentliche Netz geschaltet wird: ein Router. Der „übersetzt“ quasi zwischen Intra- und Internet.
  • Private IP-Adressen sind im Internet nicht auffindbar (sie werden nicht „geroutet“). Daher ersetzt der Router auf dem Hinweg die private Quell-IP-Adresse des Clients durch seine eigene öffentliche IP-Adresse des Internetanschlusses (z.B. per DSL oder Kabel). An diese kann der Webserver die Antwort auf die Anfrage dann zurückschicken.
  • Wenn dann später die Antwort des Webservers im Router eintrifft, muss dieser die Ziel-IP-Adresse des Pakets wieder auf die private IP-Adresse des Clients setzen und das Paket an diesen weiterleiten.
  • Dafür muss sich der Router „merken“, welcher Client welche Anfrage an welchen Server gestellt hat, damit er die Antworten passend zuordnen kann.
  • Dieses Prinzip heißt NAT (Network Address Translation) und ermöglicht mehreren Clients mit verschiedenen privaten IP-Adressen über einem gemeinsamen Router mit einer einzigen öffentlichen IP-Adresse ins Internet zu gelangen.
  • Auch der Router hat meist keine direkte Verbindung zum Zielserver, sondern muss die Pakete auf eine „Reise“ durch das Netzwerk schicken, bis es (ggfs. über mehrere weitere Router hinweg) beim Ziel ankommt. Aber woher weiß der Router, an welchen anderen Router er das Paket ggfs. schicken muss?
  • Das Default Gateway ist der „nächste Knoten“ im Netzwerk auf dem Weg zur Zieladresse. Dieser wird immer angesprungen, wenn der Zielknoten nicht direkt erreichbar ist. Diese Übersetzung kann man beliebig fortführen. Ein Client muss dazu nur die Adresse seines Routers kennen, der dann wiederum einen Router kennt, der dann das weitere Routing übernimmt usw. Irgendwann landet das Paket bei einem Knoten, der direkt mit dem Ziel kommunizieren kann, und es wird zugestellt.
  • In unserem Heimnetzwerk übernimmt die Fritzbox übrigens mehrere Rollen gleichzeitig: DHCP- und DNS-Server sowie Router und Default Gateway.
  • Gateways müssen nicht immer Router sein, aber de facto sind sie es heute so gut wie immer, da die historische Aufgabe, Netzwerke unterschiedlicher Technologien (z.B. IP und IPX/SPX) miteinander zu verbinden, durch den flächendeckenden Einsatz von IP nicht mehr benötigt wird.
  • Mit dem Kommandozeilentool tracert (oder traceroute unter Linux) kann man den Weg zum Ziel über alle Knoten dazwischen verfolgen. Dazu wird der TTL-Eintrag (Time to live) des IP-Pakets genutzt, den jeder Knoten automatisch herunterzählt. Bei 0 angekommen wird das Paket verworfen. Dabei wird aber eine Info an den Sender mit der Adresse des verwerfenden Knotens geschickt. tracert verschickt nun der Reihe nach Pakete mit TTL 1, 2, 3, 4 usw. und gibt die Adressen der verwerfenden Knoten aus.
    Beispiel für das Verfolgen einer Route mit tracert unter Windows

Literaturempfehlungen

Im guten alten IT-Handbuch für Fachinformatiker* werden in Kapitel 4 Netzwerkgrundlagen die meisten hier genannten Inhalte ausführlich erläutert. In meinem Buchclub gehe ich auf die Inhalte auch noch einmal im Detail ein.

Sascha Kersken - IT-Handbuch für Fachinformatiker: Für Fachinformatiker der Bereiche Anwendungsentwicklung und Systemintegration. Inkl. Prüfungsfragen und Praxisübungen (Affiliate)*

Links

Navigation der Serie<< DNS und DHCP (Netzwerkgrundlagen) – Anwendungsentwickler-Podcast #138Ports und Protokolle (Netzwerkgrundlagen) – Anwendungsentwickler-Podcast #141 >>
Polyglot Clean Code Developer
About the Author
Ausbildungsleiter für Fachinformatiker Anwendungsentwicklung und Systemintegration, IHK-Prüfer und Hochschuldozent für Programmierung und Software-Engineering.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax