In zwei Jahrzehnten als Vollzeitnerd hat sich der ein oder andere Text angesammelt, mit denen ich unseren Azubis versucht habe, Grundlagen über unseren Job (TCP/IP, aber auch bevorzugt Telefonie) zu erklären.

Das stelle ich hier, wann immer ich so einen Text nochmal irgendwo finde, zusammen. Diese Texte haben nicht den Anspruch, zu 100% exakt zu sein (sondern manches ist des besseres Verständnisses wegen vereinfacht worden). 

Heute:

Nachdem wir nun wissen, was eine IP-Adresse ist und wie sie auf den PC kommt, gucken wir mal über den Tellerrand.

Was bisher geschah:

Mein PC in diesen Beispielen hat die 192.168.178.10 (eine private IP hinter NAT). Die anderen Geräte hier im Haus sind aus dem gleichen Netz, mein Router z.B. hat die 192.168.178.1, mein Drucker die 192.168.178.8 usw.

Wenn mein PC jetzt drucken will, dann kontaktiert er die IP des Druckers, in dem er per ARP-Request die MAC-Adresse des Druckers erfragt und dann mit dem über das Kabel redet.

Anders sieht es aus, wenn ich www.vollzeitnerd.de aufrufe, also mein PC per http auf Port 80 mit 80.237.226.3 kommunzieren muss. Das ist eine öffentliche IP, die beiden hängen nicht im gleichen Netzwerk, d.h. ein "who has 87.230.226.3? Tell 192.168.178.10" wird unerhört bleiben. Das weiß mein PC aber vorher (und versucht es gar nicht erst), denn er kennt ja seine:

Die Subnet-Mask gehört im Prinzip zwingend zur IP-Adresse dazu, sie sagt dem jeweilgen Rechner nämlich, wie groß sein Netz ist. Also wie viele IP-Adressen sozusagen am gleichen Kabel hängen (und per arp-Rundruf gesucht werden können).

Meine Heimat-IP-Adresse (zumindest beispielhaft) ist ja die 192.168.178.10. Das sind vier jeweils 8 Bit große Blöcke, also vier Teile mit jeweils 256 Möglichkeiten. Aber nicht vergessen: Wir ITler fangen ja bei 0 an zu zählen, d.h. jeder Block kann von 0 bis 255 lauten. Und je weiter hinten ein Block ist, desto näher ist der an mir dran.

Also mein Drucker 192.168.178.8 ist relativ nah bei mir; ein PC mit 192.168.179.25 ist irgendwo in einem Nachbar-Netzwerk, wohingegen ein Server mit z.B. 193.168.178.10 genau gar nichts mit meinem Netzwerk zu tun hat, weil er bereits im ersten Block abweicht (sozusagen ganz anderer Vorwahlbereich).

Die Subnet-Mask gibt jetzt an, wie viele IP-Adressen nicht mehr zu meinem Netzwerk gehören. Bei mir daheim lautet die Subnet-Mask 255.255.255.0. Für den ersten Block (192.) heißt das, dass 255 Möglichkeiten nicht mehr mir gehören. Bleibt nur eine übrig (die habe ich: 192). Damit ist klar: Mein Netzwerk hat im ersten Block immer die 192. stehen. 

Beim zweiten Block (168.) und beim dritten Block (178.) genauso.

Beim vierten Block (bei meinem PC ja die .10) lautet die Netzmaske .0, da gibt es also keine IP-Adressen, die nicht zu meinem Netzwerk gehören. Also gehören im Umkehrschluss alle dazu. Und damit weiß mein PC, dass quasi 192.168.178.* mein Netzwerk ist und er all diese Geräte direkt per arp-Request ansprechen kann.

Wäre die Subnet-Mask 255.255.0.0, dann würde auch im dritte Block alles dazugehören (d.h. auch ein PC mit der 192.168.179.25 ist im gleichen Netzwerk).

Wäre die Subnet-Mask 255.255.255.192, dann wären die erste drei Blocks festgelegt (192.168.178), und im vierten Block sind 192 Möglichkeiten weg, bleiben noch 64 übrig. Das Netzwerk ginge dann von 192.168.178.0 bis 192.168.178.63 und wäre da zuende, danach käme das nächste. Und wenn ich auf meinem Drucker dann 192.168.178.100 mit der gleichen Subnet-Mask 255.255.255.192 eintrage, dann ist der in diesem nächsten Nachbarnetzwerk 192.168.178.64 bis 192.168.178.127 (und dann können wir beide trotzdem am gleichen Kabel hängen, wir können nicht miteinander direkt reden, weil wir in getrennten IP-Netzen sind). Von wo bis wo so ein Teilnetz genau verläuft, kann man ausrechnen (es wird immer weiter halbiert), ich nutze lieber einen IP-Calculator.

A pro pos gleiche Subnet-Mask: Wenn ich auf meinem PC 192.168.178.10 die Subnet-Mask 255.255.255.0 einstelle, und der eben genannte PC 192.168.179.25 stellt sich die 255.255.0.0 ein, dann ist eine Kommunikation zwischen uns beiden vermutlich nicht möglich. Er wird anhand seiner Netzmaske glauben, ich sei im gleichen Netz wie er und wird per arp ins Kabel brüllen. Ich werde anhand seiner Netzmaske glauben, er sei nicht im gleichen Netz wie ich und werde ihm daher nicht "per arp ins Kabel gebrüllt" antworten. Wer auch immer Recht hat: So kommen wir nicht richtig überein.

Vielleicht haben wir auch beide unrecht: Wenn das Netzwerk z.B. nicht komplett 192.168.*.* lautet, sondern nur den Bereich 192.168.178.0 bis 192.168.179.255 beinhaltet, dann lautet die Netzmaske 255.255.254.0.

Die am weitesten verbreitete Subnet-Mask daheim ist aber die 255.255.255.0. Man spricht bei dieser Subnet-Mask auch gerne mal von einem "Class-C-Netz" (stimmt nicht immer 100%ig, versteht aber jeder), und bei statt der Netzmaske kann man auch die Netzgröße mit "/24" angeben (d.h. die Schreibweise 192.168.178.10/24 ist das gleiche wie 192.168.178.10 mit Netzmaske 255.255.255.0). Die Zahl gibt an, wie oft das Netz geteilt wurde (also ein /23 wurde einmal weniger geteilt und ist entsprechend doppelt so groß, das war das mit der Netzmaske 255.255.254.0). Es reicht aber in der Praxis, wenn man die /24 wiedererkennt, für den Rest gibt's den oben verlinkten Calculator.

Wenn man den Calculator anwirft und z.B. 192.168.178.10/24 errechnen lässt, zeigt der einem auch direkt folgende Infos:

Address:   192.168.178.10        
Netmask:   255.255.255.0 = 24   

Network:   192.168.178.0/24      
Broadcast: 192.168.178.255       
HostMin:   192.168.178.1         
HostMax:   192.168.178.254       
Hosts/Net: 254                   (Private Internet)

Das Netz hat in dem Fall 254 benutzbare Adressen. Die erste, 192.168.178.0 ist die Netz-Adresse (die hat protokoll-intern eine eine Aufgabe und darf nicht benutzt werden) und die letzte (.255) ist die Broadcast-IP, die darf ebenfalls nicht benutzt werden, die ist für Broadcast-Nachrichten (also Pakete, die an alle im Netz geschickt werden). Entsprechend sind die erste und letzte nutzbare die .1 und die .254, also sind insgesamt 254 Hosts in diesem Netz erlaubt.

Wie gesagt, will mein PC mit meinem Drucker reden, brüllt er das ins Kabel.

Will mein PC mit dem Server meiner Webseite 87.230.226.3 reden, brüllt er das nicht ins Kabel - er weiß anhand seiner Netzgröße, dass das eh nichts bringen würde. Was macht er dann?

Er fragt sein default gateway, auch Standardrouter genannt. Also sein Tor nach draußen.

Ein Router ist nichts anderes als ein Gerät, das in mehreren (mindestens in zwei) Netzwerken hängt. Und entsprechend auch (mindestens) zwei unterschiedliche IP-Adressen hat. Und es kann Pakete von der einen auf die andere Seite hin- und herrouten.

Wenn mein PC jetzt also den Server erreichen will, im eigenen Netzwerk ist der nicht, geht er hin zum Router. Der Router denkt sich:

• ich habe im LAN eine IP 192.168.178.1 / 255.255.255.0 
• ich habe auf dem DSL-Interface eine IP 79.80.81.82 / 255.255.255.252 (für Netzmasken-Rechner: 2 nutzbare IPs, eine habe ich und eine hat mein DSL-Provider am anderen Ende des Kabels, über dieses Transfernetz reden wir miteinander)
• ich habe als Default-Route 79.80.81.81

Die Ziel-IP 87.230.226.3 liegt in keinem der beiden Netze, also schicke der Router das zu seiner Default-Route. Da ist dann wieder ein Router, der das gleiche macht, und wieder und wieder. Und irgendwann kommt man an Router, die schlauer sind (die über das Border Gateway Protocol BGP Infos bekommen haben, welche IPs wo zu finden sind), und diese schlaueren Router folgen nicht einfach der Default-Route, sondern die lenken den Verkehr. Bis er irgendwann bei meinem Webserver-Provider rauskommt, und da irgendwann auf einem Router, der eine IP 87.230.226.1/24 konfiguriert hat. Und der brüllt dann die Anfrage per arp ins Kabel, wo sie von meinem Server beantwortet wird.

Und was passiert mit der Antwort? Der Server schickt sie an den Absender (=die IP meines DSL-Anschlusses). Entscheidet anhand der Netzmaske "ist nicht hier im Netz", geht an seinen Router, der kennt die IP auch nicht, gibt's an seinen Default-Router usw., bis es irgendwann bei mir daheim landet.

An der Stelle habe ich zwei Sachen ausgelassen: Zum ist die Variante mit dem Transfernetz auf meinem DSL-Router durchaus möglich (würde bei Standleitungen z.B. auch so gemacht), bei reinen DSL-Wählverbindungen läuft das aber meistens minimal anders (können wir an der Stelle ignorieren). Und zum einen haben wir in unserem Netzwerk ja sog. private IPs (192.168.), weshalb der Router nicht einfach so routet, sondern NAT macht - das Grundprinzip hatte ich bei den privaten IP-Adressen schon mal erklärt bzw. ist im Detail noch ein anderes Thema.

Zurück zu der Route von mir zu meinem Webserver. Nachverfolgen kann man das mit einer:

Die sieht so aus:

C:\Users\nerd>tracert vollzeitnerd.de

Routenverfolgung zu vollzeitnerd.de [80.237.226.3]
über maximal 30 Hops:

  1     1 ms     1 ms     1 ms  192.168.178.1
  2     7 ms     6 ms     7 ms  braslns-vc1.netcologne.de [195.14.226.161]
  3     6 ms     6 ms     6 ms  ip-core-eup1-ae16.netcologne.de [195.14.215.49]
  4     7 ms     6 ms     6 ms  ip-core-sto1-et2-2-2.netcologne.de [87.79.17.18]
  5     7 ms     6 ms     7 ms  bdr-sto1-ae1.netcologne.de [81.173.192.114]
  6     8 ms     8 ms     7 ms  as61157.dusseldorf.megaport.com [194.146.118.2]
  7    31 ms    23 ms     9 ms  ae3.cr1.cgn3.plusserver.com [62.138.225.37]
  8     9 ms     8 ms     8 ms  willkommen-bei.dt-internet.de [87.230.108.100]
  9     8 ms     8 ms     8 ms  web12.che.dt-internet.de [80.237.226.3]

Ablaufverfolgung beendet.
 

Das sind die Router, durch die meine Pakete gegangen sind. Erst zu NetCologne (mein Kölner DSL-Provider), von da nach Düsseldorf, dann wieder nach Köln (erkenbar am "cgn3" bein siebten Hop) und von da zu meinem Webhoster. In der Traceroute sieht man die einzelnen Zwischenstationen in Form von einzelnen Pings.

Ein Ping ist eine ICMP-Funktion, also schon direkt im TCP/IP vorgesehen: Mein PC schickt an die Ziel-IP eine ICMP-Nachricht mit der Bitte um Antwort, und diese Antwort kommt wie ein Echo wieder zu mir. Kennt der ein oder andere vielleicht aus U-Boot-Filmen: Da sitzt man mit der Stoppuhr daneben und misst, wie lange das dauert, bis das Echo wieder da ist. Das muss man noch durch zwei teilen (denn das Signal ist ja zum gegnerischen Boot hin- und dann wieder zurückgekommen) und daraus kann man dann die Entfernung zum Ziel berechnen. Wir in der IT begnügen uns mit der Info, dass das Ziel geantwortet hat (dann ist es für uns erreichbar) und ggf. mit der Zeitangabe. Und eine Traceroute ist vereinfacht gesagt ein ping an die Zwischenstationen, jeweils drei Pings pro Ziel (darum auch die drei Zeitangaben).

Was da auffällt: Der Hop Nummer 7 antwortet selbst recht langsam (teilweise 31 ms), die Hops danach aber sind schneller. Das ist irritierend (langsame Paketlaufzeiten klingen ja eher nach einem Problem), das kann auch auf ein Problem hinweisen (der Router ist so überlastet, dass er für so unwichtigen Kram wie ping keine Rechenpower mehr hat). Es kann aber auch harmlos sein (es gibt viele Router, die deutlich schlechter pings beanworten als sie Pakete routen können). 

Und wie gesagt, der Webserver am Ziel macht danach genau das gleiche mit der Antwort, er schickt sie von Router zu Router. Und auch da kann man eine Traceroute machen lassen, die sieh unter Linux minimal anders aus, ist aber das gleiche Prinzip:

traceroute to (87.78.###.###), 30 hops max, 60 byte packets
 1  lilly.che.dt-internet.de (80.237.226.1)  0.037 ms  0.014 ms  0.011 ms
 2  n87-230-108-98.cnet.psmanaged.com (87.230.108.98)  0.414 ms  0.437 ms  0.426 ms
 3  ae6.cr1.dus6.plusserver.com (62.138.225.38)  1.992 ms  2.044 ms  2.058 ms
 4  * * *
 5  ip-core-sto1-ae3.netcologne.de (81.173.192.113)  8.425 ms ip-core-sto2-ae3.netcologne.de (81.173.192.117)  1.950 ms  1.894 ms
 6  braslns-vc1-ae4.netcologne.de (195.14.215.62)  1.648 ms  1.779 ms  1.745 ms
 7  static-87-78-###-###.nc.de (87.78.###.###)
 

Und die ist natürlich erstmal genau anders herum, denn das ist ja der Rückweg.

Wir erkennen auch keine einzige IP wieder. Warum nicht? Weil wir ja in die andere Richtung laufen. Selbst wenn wir also an den gleichen Routern vorbeilaufen, dann passieren wir die aus einem anderen IP-Netzwerk kommend (und weil jeder Router in jedem Netzwerk natürlich eine passende IP hat, sehen wir jetzt jeweils die andere Seite der Tür). Und vielleicht sind wir auch einen ganz anderen Weg gelaufen (es gibt kein Gesetz, dass Hin- und Rückroute gleich sein müssen). Wichtig ist nur, dass es eine Hin- und eine Rückroute gibt, denn ansonsten kommt entweder die Frage gar nicht beim Server, oder die Antwort gar nicht beim User an.

Was ist hier sonst noch auffällig: Der vierte Hop antwortet gar nicht. Das kann durchaus sein, dass das der gleiche ist, der uns auch auf dem Hinweg schon nicht antworten wollte (vielleicht ist der wirklich überlastet). Kann aber auch ein völlig anderer sein. Obwohl ICMP und damit Pings nativ zu TCP/IP gehören ist es durchaus möglich, dass Ping-Antworten abgeschaltet sind.

Letzte Auffälligkeit: Die Traceroute macht ja immer drei einzelne Pings. Und bei Hop 5 wiederum kam die erste Antwort von einem anderen Router (IP .113 am Ende nach 8.4 ms) als die andere beiden (.117 nach knapp 2ms). IP-Pakete können halt auch mal unterschiedliche Wege gehen (Lastverteilung, Ausfallrouting, ...).

Ich hatte zuvor immer vom Standard-Gateway (Default router) gesprochen. Es gibt aber auch die Möglichkeit, sowohl auf dem PC (Befehl "route add ...") oder auf dem Router selbst statische Routen zu setzen. Die werden dann für ein bestimmtes Ziel(netz) gesetzt und haben Vorrang, alles andere folgt dann der Default-Route.

Typischer Anwendungszweck wäre z.B., wenn man auf  z.B. TerminalServer in einem Rechenzentrum zugreift und dafür im Büro einen VPN-Router (oder gerne auch "Cloud Connector" genannt) hat. Die PCs im Büro haben als Netz dann 192.168.178.0/24.

Der TerminalServer im Rechenzentrum hat z.B. die 172.16.12.34. Damit jetzt nicht jeder Mitarbeiter ein Software-VPN ins Rechenzentrum braucht (aber gleichzeitig der TerminalServer ja nicht über's öffentliche Internet erreichbar ist, sondern weiterhin nur per VPN) stellt man ins Netzwerk einen VPN-Router auf (mit z.B. 192.168.178.2) und konfiguriert auf dem eigenen Router (z.B. der FritzBox) eine statische Route: 172.16.12.0/24 mit next hop 192.168.178.2.

Wenn jetzt ein PC eine Verbindung zu 172.16.12.34 aufbaut, geht der PC wie gewohnt hin und schickt es an seinen Default-Router, also z.B. die FritzBox. Und die hat eine statische Route drin und weiß, dass sie das Paket nicht raus zu z.B. NetCologne schicken soll, sondern statt dessen zu 192.168.178.2, dem "Cloud-Connector". Und der ist ja ein VPN-Router, hat also auch wieder zwei IP-Adressen (neben der 192.168.178.2 auch noch eine im VPN-Transfer-Netz des Anbieters) und routet das Paket dann in den Tunnel rein.

Wer keinen Zugriff auf die FritzBox hat, kann die Route auch auf dem PC einstellen. In diesem Fall würde der PC direkt beim Verbindungsaufbau selbst denken "oh, ich kenne einen bessere Weg" und direkt den VPN-Router statt der FritzBox kontaktieren. 

Es gibt noch andere Arten von Spezial-Routen, z.b. das ursprungsabhängige Routing (Source based Routing). 

Ein Anwendungsfall ist z.B. bei mir daheim, ich habe ein Live-Netz, ein Besucher-Netz (i.d.R. WLAN) und ein Testnetz, wo ich Kundenhardware vor dem Versand vorbereite etc. Und weil viele Kunden klassisch eine FritzBox haben, hat mein Testnetz in der Regel 192.168.178.0/24, dann sind die Einstellungen möglichst so wie beim Kunden.

Und ich habe zwei Internet-Zugänge, einerseits NetCologne mit einer festen IP-Adresse (die auch auf Firewalls meines Arbeitgebers mehr darf als andere IPs) und andererseits O2 LTE als Backup-Leitung. Und auf meinem Router gibt es jetzt eine "source-based routing"-Regel, dass Absender=192.168.178.0/24 mit next hop <IP meines Mobilfunkrouters> läuft. Dadurch laufen Verbindungen vom Testnetz zu meinem Arbeitgeber nicht über die NetCologne-IP, was das Testen mit realen Bedindungen verbessert.

Der Vollständigkeit halber erwähnt seien noch zwei Dinge aus dem Umfeld Internet-Provider:

Wenn die Pakete von einem Provider zum nächsten durch's Internet laufen, dann machen sie das im Prinzip den oben beschriebenen Weg: Sie kommen an einen Router, der mehrere Netzwerke verbindet und das Paket von einem Netzwerk ins andere hebt.

Aber irgendwann muss so ein Paket ja wenigstens in die richtige Himmelsrichtung gehen. Wenn ich eine schwedische Webseite aufrufe, muss ja irgendwann mein Paket auch den Weg in Richtung Schweden finden, und umgekehrt müssen die Antwort-Pakete an meine NetCologne-IP 87.78.131.123 (das ist nicht meine, nur ein Beispiel) ja wenigstens bis zu NetCologne kommen.

Und da kommen drei Dinge zum Einsatz:

• Organisatorisch: Die sog. Autonomen Systeme (AS). Statt zehntausende IP-Adressen, die z.B. NetCologne hat, in einzelnen Netzen zu routen, fasst man einfach alles, was NetCologne hat, in einem autonomen System zusammen, in dem Fall ist das das "AS 8422"  
• Physikalisch: Provider haben untereinander Verbindungskabel mit Routern, das sind dann sog. Peerings. Je mehr Router verbunden sind, desto kürzer sind die Wege, die ein Paket gehen muss (weil sich schneller eine Abkürzung ergibt). In Europa z.B. ist das DE-CIX ein riesiger Knoten, wo Provider ihre Kabel tauschen.
• Und beides zusammen wird dann über das Border Gateway Protocol (BGP) an die anderen Provider kommuniziert. Wenn jetzt der schwedische Webserver Daten an mich ausliefert, dann erkennt sein Provider, dass die Ziel-IP zum AS8422 gehört und weiß per BGP, dass es eine Verbindung zwischen AS8422 und AS2119 (Telenor Sweden) gibt, mit denen er selbst vielleicht ein Peering hat.

Aber wie das genau funktioniert, ist ein Thema für sich. Und für "Basiswissen IT-Techniker" auch etwas viel.