- Anzeige -

Kleiner TCP/IP-Workshop - IPv6 und IPv4

In vielen Netzen von Unitymedia sind Internet und Telefonie bereits verfügbar.
Wichtig:
  • Kunden aus Hessen und Nordrhein-Westfalen können über die Rufnummer 0221 / 466 191 00 Hilfe bei allen Problemen in Anspruch nehmen.
  • Kunden aus Baden-Württemberg können über die Rufnummer 0711 / 54 888 150 Hilfe bei allen Problemen in Anspruch nehmen.

Kleiner TCP/IP-Workshop - IPv6 und IPv4

Beitragvon SpaceRat » 14.08.2013, 21:33

Hallo!

Vorwort

Da zum Thema IPv6 viel Un- und Halbwissen existiert, habe ich mich entschlossen, mal einen kleinen "Workshop" zu machen, wie man mit IPv6 arbeitet und z.B. IPv6-Freigaben einrichtet.

Für Lesefaule, Eilige und technisch weniger Interessierte mache ich am Ende der "Backgroundwissen"-Kapitel eine stark vereinfachende Zusammenfassung.

Wer bereits meine erste Fassung des "Kleiner IPv6-Workshop" gelesen und verstanden hat, kann sich das erneute Durchlesen der beiden ersten Grundlagen-Kapitel sparen, sie wurden nur unwesentlich verändert und teilweise etwas vereinfacht. Alle weiteren Kapitel wurden grundlegend überarbeitet.

Ich bitte darum, keine Antworten bzw. Rückfragen in diesem Thread zu (er)stellen, sondern dafür diesen Thread zu benutzen.


Inhalt

Zuletzt geändert von SpaceRat am 15.08.2013, 04:50, insgesamt 19-mal geändert.
Benutzeravatar
SpaceRat
Glasfaserstrecke
 
Beiträge: 2423
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen

Rückblick IPv4 / Warum eigentlich IPv6?

Beitragvon SpaceRat » 14.08.2013, 21:34

Rückblick IPv4 / Warum eigentlich IPv6?

Als das Protokoll erfunden wurde, auf dem unser aller Internet basiert, also TCP/IP, gab es das Internet noch gar nicht. Es hieß da noch Arpanet und war ein Forschungsnetzwerk, welches unterschiedliche US-amerikanische Universitäten, die für das US-Verteidigungsministerium forschten, verband. Für diesen Zweck erschien der von TCP/IP v4 angebotene Adressraum von 4 Mrd. Adressen noch mehr als ausreichend. Zur zeitlichen Einordnung: Wir reden hier von den späten 60er und den 70er Jahren.

Adressierung in einem TCP/IP-Netzwerk

Das Protokoll TCP/IP sieht eigentlich vor, daß jedes netzwerkfähige Gerät eine eigene Adresse (IP) erhält und durch Angabe einer Port-Nummer der anzusprechende Dienst bestimmt wird. Die IP unterteilt sich noch weiter in einen Netzwerk- und einen Hostteil.

Vergleichbar ist die IP mit einer Postadresse:
  • Anschrift samt Nachname (Familie Mustermann, Sowiesostraße 10, 12345 Musterhausen) könnte man mit der Netzwerkadresse,
  • den Vornamen mit der Hostadresse
    und
  • den Betreff eines Briefes an diese Anschrift mit dem Port
vergleichen.

Somit ist jede Person in jeder Wohnung und um was es geht (Z.B. eine Zahlungsaufforderung, die Aufforderung zu einer Antwort, die Bekanntgabe einer Erbschaft, ...) eindeutig adressierbar.

Wenn ich möchte, daß Max Mustermann seine Rechnung bezahlt, dann adressiere ich auch an Max Mustermann und schreibe "Zahlungsaufforderung" in den Betreff. Das Netzwerk "Familie Mustermann" weiß dann, daß das Familienmitglied Max gemeint ist und Max weiß, daß er vergessen hat, etwas zu bezahlen.

Exakt das selbe läuft ab, wenn ich einen Web-Server aufrufe. Um http://www.heise.de aufzurufen, wird dieser Name in die IP 193.99.144.85 aufgelöst, was unseren Postboten im Netzwerk (Also den Routern) sagt, daß unser Paket ins Netzwerk 193.96.0.0/14 zum Rechner 0.3.144.85 muß. Und weil ich den Web-Server erreichen will, füge ich der Adresse noch den Port 80 hinzu, damit der Rechner weiß, daß ich eine Webseite von ihm geschickt haben möchte.


Grenzen der Adressierbarkeit mit TCP/IP v4

Solange das ArpaNet ein reines Forschungsnetz war, war dieses Schema auch ohne weiteres einzuhalten. 1990 aber wurde das Arpanet für die kommerzielle Nutzung freigegeben und 1993 kam der erste grafische Webbrowser (Mosaic). Danach begann die wachsende Verbreitung des Internets und es war klar, daß der Adressraum von 4 Mrd. Adressen auf Dauer nicht reichen würde. Deshalb begann man zum einen mit der Entwicklung von IPv6 und auf der anderen Seite mit Maßnahmen, um mit den IPv4-Adressen besser zu haushalten.


Workaround 1: Dynamische IPs

Als Folge der Adressknappheit haben private Endkunden eigentlich nie einen vollwertigen IPv4-Anschluß bekommen, sondern z.B. nur dynamische IPs. Durch dynamische IPs konnte dieselbe IP an Einwahlverbindungen für mehrere Kunden genutzt werden: War Kunde A offline, dann bekam Kunde B die freigewordene Adresse und umgekehrt. Solange die Kunden den Internetzugang nach Zeit bezahlt haben, funktionierte das auch einigermaßen.

Mit der steigenden Verbreitung von Flatrates und DSL entfiel der Kostendruck, die Verbindung zu trennen, allerdings bekam man zu Beginn i.d.R. auch nur ein DSL-/Kabel-Modem, so daß nach wie vor der angeschlossene PC die Verbindung herstellen mußte und da viele Nutzer ihren PC nicht durchlaufen lassen, hatte man so nach wie vor eine gewisse Reserve durch dynamische IPs.

Durch das Aufkommen von SOHO-(Small Office/Home Office)-Routern wurde es dann aber zunehmend zur Normalität, daß die Kunden ihre Internet-Verbindung dauerhaft aufrecht hielten. Mit dynamischen IPs kann man nun nur noch unwesentlich Adressen sparen, denn selbst bei ausgeschalteten PC ist ja der Router bzw. die Modem/Router-Kombi noch online.

Dynamische IPs und die Zwangstrennung haben nur noch den Zweck, den Betrieb von Servern an Privatkundenanschlüssen zu erschweren. Eine Sicherheitsfunktion oder Privatsphärenschutz ist mit dynamischen IPs nicht verbunden!
Durch die Hinzunahme von Protokollen und Datum/Zeitpunkt des Zugriffs läßt sich problemlos jederzeit jede IP einem Anschluß zuordnen und eine genauere Zuordnung ist auch nicht nötig, da sowieso der Anschlußinhaber haftet.

Damit bleibt als wahrer Grund für dynamische IPs nur die technische Beeinträchtigung der Erreichbarkeit eines Anschlusses für Serverdienste.
Noch mal am Beispiel der Postadressen:
Ich weiß zwar, daß ich einen Web-Server (Port 80) bzw. einen Max erreichen will, ich kenne aber seine IP und damit Postanschrift nicht mehr, da sich diese ständig ändert. Die bekannte Krücke zur Lösung des Problems sind DynDNS-Dienste, also praktisch Nachsendeaufträge.


Workaround 2: NAT (Network Address Translation)

  • Adressierung im LAN mit privaten IPs

    Um IPv4 einzusparen, nutzt man NAT. Statt jedem Kunden auch wirklich ein Subnet zuzuweisen, mit dem man jedem Gerät im Heimnetz seine eigene IP zuteilen könnte, bekommt man auch im Zeitalter von Routern und Zweit-PCs/Notebooks weiterhin nur eine einzige öffentlich erreichbare IP und muß seine Geräte zuhause über NAT anbinden. Dabei erhält zwar jedes Gerät eine eigene IP, die jedoch nur im heimischen Netzwerk eindeutig ist.
    Um die Konsequenz klar auszusprechen: Hierbei wird das Grundprinzip der TCP/IP-Netzwerkadressierung verletzt, daß jeder Rechner seine eigene Adresse hat. Aus Sicht des Internets ist jeder solche NAT-Anschluß nur ein einziges Gerät und erst vor Ort gibt es eindeutige Adressen für alle Geräte, die aber nach außen hin nicht sichtbar sind.

    Um bei unserem Beispiel zu bleiben:
    Max, Franz und Petra Mustermann wissen zwar voneinander und können sich auch innerhalb der eigenen Wohnung gezielt ansprechen, aber nach außen hin treten sie nur als "Familie Mustermann" in Erscheinung.

    Für diesen Zweck sind die bekannten Adressen im Muster 192.168.x.y sowie die weniger bekannten Adressbereiche 10.x.y.z und 172.16.0.0 bis 172.31.255.255 reserviert und werden im Internet nicht durchgeleitet.

  • Kommunikation aus einem LAN mit privaten IPs ins Internet

    Diese Adressen werden nur innerhalb von privaten Netzen genutzt und erst der Router "bündelt" den ausgehenden Traffic aller Geräte dieses Netzwerkes auf der einen öffentlichen IP, leitete ihn mit dieser als Absender ins Internet und sorgte dafür, daß die eingehenden Antworten auch wieder an den PC im Heimnetz gehen, der auf diese Antwort wartet.

    Dieser Vorgang der Network Address Translation (NAT) ist mit der Frage "Max, hast Du was bei Amazon bestellt?" vergleichbar, die auftritt, wenn Petra Mustermann ein an "Familie Mustermann" adressiertes Paket annehmen soll, selber aber nichts damit anzufangen weiß. Eine Frage, die nicht nötig wäre, wenn schon in der Anschrift "Max Mustermann" oder eben "Franz Mustermann" stünde. Petra Mustermann ist in diesem Beispiel der Router, der versucht, das eingegangene Paket demjenigen im Netzwerk/der Familie zuzuordnen, der es auch angefordert hat.

    Somit können alle angeschlossenen Geräte sich eine Internetverbindung und -adresse teilen, solange alles von außen eingehende auch von irgendeinem Rechner erwartet wird, analog unserem Paket von Amazon, das ja irgendjemand bestellt hat. Direkt von außen erreichbar sind die einzelnen Geräte aber nicht.

    Genau wie ständige Nachfragerei, wer etwas bei Amazon, Bonprix, Otto, Conrad, ... bestellt hat, ist auch beim Router die Zuordnung von Antworten zu dem Gerät, welches darauf wartet, mit erheblichem (Rechen-)Aufwand verbunden.

  • Zugriffe vom Internet auf ein LAN mit privaten IP-Adressen

    Unangeforderte Zugriffe von außen enden am Router, der nichts damit anzufangen weiß.

    Durch Port-Weiterleitungen kann man dem Router nun sagen, daß z.B. Zugriffe auf einen Web-Server (Erkennbar daran, daß Port 80 angesprochen wird) auf einen ganz bestimmten Rechner im Heimnetz geleitet werden sollen, auf dem eben der Web-Server läuft. Das konnte man mit jedem einzelnen der 65535 Ports machen, mit jedem davon aber nur ein Mal.

    Ein zweiter Web-Server ist also nicht möglich (Da der dafür benutzte Port 80 schon für den ersten Web-Server benutzt wird), bzw. der zweite Web-Server müßte dann einen anderen, nicht standardgemäßen, Port nutzen.

    Beispiel: Im Heimnetz steht ein NAS mit Web-Zugriff und ein Receiver mit Web-Interface. Der NAS habe die lokale IP 192.168.1.10 und der Receiver die lokale IP 192.168.1.11. Das Heimnetz habe die öffentliche IP 176.198.22.67.
    Im lokalen Netzwerk kann man nun per Webbrowser durch Eingabe der o.g. lokalen IPs beide Geräte direkt ansprechen. Für den Zugriff von außen müßte man in der Fritz!Box aber Portfreigaben nach diesem Muster einrichten:
    Als Freigabe namens "Receiver WebInterface" leite TCP-Anfragen von Port 80 an das Gerät Receiver auf Port 80
    Als Freigabe namens "NAS WebInterface" leite TCP-Anfragen von Port 81 an das Gerät NAS auf Port 80
    Nun kann man von außen mittels Eingabe der Adresse 176.198.22.67 direkt auf den Receiver zugreifen, für den Zugriff auf den NAS muß man aber 176.198.22.67:81 eingeben, da Port 81 nicht der Standardport für Web-Server ist.

    Am Beispiel unserer Postadresse würde das bedeuten, daß z.B. nur Max Mustermann alle Rechnungen für "Familie Mustermann" auf den Tisch gelegt bekäme. Franz hingegen könnte so keine Rechnungen bekommen, es sei denn, ich schriebe in den Betreff explizit "Rechnung Franz Mustermann" hinein.

Workaround 3: CGN (Carrier Grade NAT, also "Network Address Translation durch den Anbieter")

Das bisher am Heimanschluß vorherrschende Szenario war
- eine einzige öffentliche IPv4
- NAT für das lokale Heimnetz mit privaten IP-Adressen

Beim CGN kommt nun eine NAT-Ebene hinzu, d.h. die Pakete werden bereits beim Provider durch eine "Adressübersetzungen" gejagt.
Vereinfacht gesagt funktioniert diese ganz genau so, wie im vorherigen Abschnitt beschrieben, nur daß in diesem Fall nicht nur die diversen Geräte im Heimnetz via NAT-Router über nur eine IP gebündelt nach außen kommunizieren, sondern zusätzlich auch mehrere Kunden bzw. Anschlüsse nur noch private IPv4-Adressen erhalten und wiederum über einen NAT-Router beim Anbieter (Das "AFTR-Gateway") über eine gemeinsame öffentliche IPv4 auf das Internet zugreifen.
Als Konsequenz "sieht" das Internet hier nicht nur keine einzelnen Geräte, sondern auch den kompletten einzelnen Anschluß nicht mehr. Stattdessen scheinen alle Zugriffe aus dem CGN heraus von nur einem einzigen Rechner zu stammen.

Auf unser Beispiel mit der Postadresse übertragen bedeutet dies, das nun ein Portier alle Antwort-Pakete annimmt. Dieser kann - weil er die Bestellungen im Auftrage der Familien selber weggeschickt hat - die Pakete einer im Hause wohnenden Familie zuordnen, nicht aber einer Person aus der Familie. Letztere Zuordnung erledigt weiterhin die Person in der Familie, die immer die Pakete annimmt (Also Petra, unser Router).

Genauso wie unsere Petra/unser normaler NAT-Router zuhause ist auch der Portier/das AFTR-Gateway nicht in der Lage, unverlangt eingehende Pakete zuzuordnen. Somit kann die ganze Familie Mustermann (Genauso wie die Schmitzens, Müllers und Meiers aus demselben CGN-Haus) keine Anfragen von außen/aus dem Internet beantworten, da diese nie bei ihnen ankommen.
Anders als unser NAT-Router zuhause kann das AFTR-Gateway auch nicht mit Portfreigaben dazu gebracht werden, zumindest auf bestimmte Betreffs/bestimmten Ports zu reagieren.

Ergebnis: Die Rechner bzw. Netze hinter einem AFTR-Gateway sind von außen gar nicht mehr ansprechbar, sie können nur Antworten auf Anfragen von innen heraus erhalten.


Grundlagen zu IPv6

Änderungen durch IPv6

Mit all diesem Humbug räumt IPv6 auf. Durch eine längere Adresse stehen nun nicht mehr nur 4 Mrd. (3,7 Mrd. nutzbare) IPv4-Adressen, sondern 340 Sextillionen IPv6-Adressen zur Verfügung und damit genug für alle. Dank IPv6 kann jedes Smartphone, jeder PC im Heimnetz, jede Spielkonsole, jeder Receiver, jeder NAS usw. seine eigene Adresse erhalten und ohne Umwege angesprochen werden.

Ansonsten bleibt eigentlich alles genau wie vorher, abgesehen davon, daß ich jetzt wieder mit dem ursprünglichen Adressierungskonzept arbeiten kann, welches ja nur deshalb im privaten Umfeld nicht ging, weil ich nicht genug Adressen zur Verfügung hatte.


Aufbau von IPv6-Adressen im Vergleich zu IPv4-Adressen

  • Während IPv4-Adressen aus 4 Blöcken a 256 Werten aufgebaut sind, also z.B. 176.198.22.67, sind es bei IPv6 8 Blöcke mit jeweils 65536 Werten.
  • Zur Unterscheidung zu IPv4 nutzt man zum Trennen der Blöcke keine Punkte mehr, sondern Doppelpunkte.
  • Und weil 8193:19920:65280:33837:547:4607:65044:57278 sehr unhandlich aussieht, schreibt man diese Adressen in Hexadezimal, also so: 2001:db8:affe:c0c0:223:11ff:fe14:1234.
  • Wie bei IPv4 gibt es Subnetze und die werden auch fast genauso beschrieben.

    Da man als Privatkunde bei IPv4 selten einen vollwertigen IPv4-Zugang bekommen hat, dürfte vielen nur das private Subnetz
    192.168.x.y Subnetzmaske 255.255.255.0 bzw. 192.168.x.y/24
    etwas sagen.

    Beide Schreibweisen bezeichnen das selbe Subnetz, nämlich das, bei dem der Teil 192.168.x feststeht und die Stelle y für Hosts im Subnetz (Also die Vornamen der Familienmitglieder) vergeben werden kann.
    Der erste Teil hätte - wie zu Beginn beschrieben - normalerweise die Funktion der eigentlichen Postanschrift, um die Familie Mustermann an sich zu erreichen. Da es sich aber nur um einen speziell reservierten privaten Adressbereich handelt, fehlt ihm diese Aussagekraft, weil dieser Teil nur "Irgendein lokales, nicht ins Internet geroutetes LAN" beschreibt. Praktisch wie die Antwort "Zuhause" auf die Frage, wo man wohnt.

    Die Maske drückt aus, welche Bits unveränderlich sind.
    255 = 11111111 in Dual, d.h. alle 8 Bits sind unveränderlich.
    Da wir bei der Subnetzmaske 255.255.255.0 die 255 für die ersten drei Blöcke haben, heißt das, das sich an den Zahlen der ersten drei Blöcke auch nichts ändern darf, sonst wären wir in einem anderen Subnetz.
    Weil die Schreibweise mit Maske lang und unhandlich ist und die Bits auch immer von hinten zwischen Subnetz und Hosts verschoben wird, geht man immer mehr dazu über, einfach die Anzahl der festgelegten Bits anzugeben, also z.B. 192.168.178.0/24 für das Standard-Subnetz einer Fritz!Box, bei dem der Teil 192.168.178 (Die ersten 24 Bit) unveränderlich ist.

    Innerhalb eines Subnetzes sind die erste und die letzte Adresse reserviert als Netzwerk- und Broadcastadresse, stehen also für Hosts nicht zur Verfügung.
    Im Netzwerk 192.168.178.0/24 sind das die 192.168.178.0 als Netzwerk- und die 192.168.178.255 als Broadcast-Adresse.

    Bei Unitymedia-Business-Anschlüssen mit fester IPv4 erhält man übrigens auch Subnetze, nämlich entweder
    a.b.c.d/30 ("1" IPv4-Adresse) oder a.b.c.d/29 ("5" IPv4-Adressen)
    bzw. an zwei praktischen Beispielen:
    • 176.198.22.64/30
      entspricht dem Adressraum 176.198.22.64 bis 176.198.22.67,
      da von den 32 Bits nur 2 (32-30) für Hosts genutzt werden können, also die Bits für die 1 und die 2, also 64+0 (=64) , 64+1, 64+2 und als letzte 64+1+2 (= 67)

      Von diesem Adressraum mit 4 Adressen ziehen wir die Netzwerk- und Broadcastadressen ab, bleiben 2 IPs, eine kriegt der Router und schon sind wir bei genau einer statischen IP für die angeschlossenen Geräte.

      Ergebnis:
      176.198.22.64 = Netzwerkadresse
      176.198.22.65 = Für den Unitymedia-Router verwendete IP
      176.198.22.66 = 1. Host-IP, zur Verwendung durch den Router/Rechner des Kunden
      176.198.22.67 = Broadcast-Adresse
    • 176.198.22.64/29
      entspricht dem Adressraum 176.198.22.64 bis 176.198.22.71,
      diesmal sind es 3 Host-Bits, also die für die 1, die 2 und die 4, somit also 64+0 (=64), 64+1, 64+2, 64+1+2, 64+4, 64+4+1, 64+4+2, 64+4+2+1 (=71)

      Von diesem Adressraum mit 8 Adressen ziehen wir die Netzwerk- und Broadcastadressen ab, bleiben 6 IPs, eine kriegt der Router und schon sind wir bei fünf statischen IPs für die angeschlossenen Geräte:
      176.198.22.64 = Netzwerkadresse
      176.198.22.65 = Für den Unitymedia-Router verwendete IP
      176.198.22.66-176.198.22.70 = 1. bis 5. für Hosts verwendbare IP
      176.198.22.71 = Broadcast-Adresse
  • Subnetze funktionieren bei IPv6 genauso wie bei IPv4,
    wobei hier nur die Schreibweise mit der Anzahl der feststehenden Bits (/64) üblich ist,
    denn 65535:65535:65535:65535:0:0:0:0 oder FFFF:FFFF:FFFF.FFFF:0:0:0:0 sähe doch arg bescheuert aus.

    Bei IPv6 ist es vorgesehen, daß jeder Endkunde mindestens ein 64er Präfix und Subnetz kriegt. Bei einem Subnetz 2001:db8:affe:c0c0::/64 haben wir den feststehenden Teil 2001:db8:affe:c0c0 (Die ersten 64 Bit) und dahinter Platz für Hostadressen von ::0 bis FFFF:FFFF:FFFF:FFFF. Ich mag das jetzt nicht vorrechnen, aber das sind 18446744073709551616 Adressen (2^64), vorerst genug auch für kleine WGs und Familien.
    Im Gegensatz zu unserem bekannten IPv4-Subnetz 192.168.x.y ist dieses Subnetz auch ein vollwertiges, routingfähiges Subnetz, das nicht nach außen hin durch eine andere, öffentliche IP ersetzt werden muß!

    Subnetze kleiner als 64 sind bei IPv6 unüblich, weil das die Mindestgröße für die Adressvergabe per SLAAC (State-Less Address Auto Configuration bzw. zustandslose Adressautokonfiguration) ist.
  • Zur Schreibweise (Notation) von IPv6-Adressen gibt es Vereinfachungen, um Adressen kürzer zu schreiben:
    • Führende Nullen kann man streichen. Statt 2001:0db8:affe:0000:0000:01ff:0e14:1234 dürfte ich also schreiben: 2001:db8:affe:0:0:1ff:e14:1234
    • Aufeinanderfolgende Blöcke zu 0 dürften einmalig zusammengefaßt werden und werden durch zwei aufeinanderfolgende Doppelpunkte gekennzeichnet. Die o.g. Adresse dürfte ich also so schreiben: 2001:db8:affe::1ff:e14:1234
      Einmalig heißt, das ich das nur ein einziges Mal in einer Adresse machen darf. Die Adresse 2001:0:0:0:01ff:0:0:0fbe darf ich also zu 2001::01ff:0:0:0fbe zusammenfassen, die hinteren zwei Blöcke mit Nullen müssen stehenbleiben, weil es ja sonst zwei Möglichkeiten gäbe, wieder auf 8 Blöcke zu kommen, nämlich vorne zwei plus hinten drei einerseits und vorne drei und hinten zwei andererseits. Wenn man also einer Adresse mit mehreren Sequenzen von 0er Blöcken begegnet, streicht man natürlich den größeren zusammen.
  • Spezielle Adressen IPv4 und IPv6 im Vergleich

    Sowohl bei IPv4 als auch bei IPv6 gibt es einige spezielle Adressen.
    Die wohl bekannteste davon bei IPv4 ist die 127.0.0.1 oder "localhost". Diese adressiert sozusagen "sich selbst". Man begegnet ihr daher z.B. dann, wenn ein Dienst auf dem eigenen Rechner im Hintergrund läuft und über eine entsprechende Schnittstelle konfiguriert werden kann. Man nutzt sie auch, wenn man z.B. auf seinen eigenen FTP-Server zugreifen will, oder oder oder.
    Die entsprechende Adressse bei IPv6 lautet ::1/128 (Also in lang: 0:0:0:0:0:0:0:1 bzw. in ganz lang 0000:0000:0000:0000:0000:0000:0000:0001).
    Ansonsten gibt es noch spezielle Adressen in Form der Netzwerk-Adresse oder der Broadcast-Adresse, die ich oben bereits erwähnt hatte, die zu erklären hier aber zu weit führen würde. Vergleichbares gibt es auch bei IPv6, es ist aber zum weiteren Verständnis nicht notwendig.
    Eingehen möchte ich noch auf die link-local-Adressen, die mit fe80:0000:0000:0000 oder fe80::/64 beginnen. Adressen in diesem Subnet gelten nur lokal, also in einem abgeschlossenen Netzwerk und spielen hauptsächlich für die Adressvergabe eine Rolle.


Adressvergabe IPv6

  • DHCP vs. DHCPv6
    • Bei IPv4 nutzen wir vor allem DHCP zur Adressvergabe.
      Sei es, weil wir eine einfache Einwahlverbindung nutzen und uns der Einwahlserver so eine Adresse zuweist, oder weil wir hinter einem Heim-Router sitzen, der so den angeschlossenen Geräten eine Adresse zuweist. Auch der Router selber erhält meist auf diese Weise seine öffentliche IP.

      Daneben gibt es noch die statische IP, bei der wir auf einem Gerät eine feste IP (Meist eine aus dem Heimnetz) fest eintragen, z.B. weil wir wollen, daß der Receiver oder ein Netzwerkdrucker auch immer unter der selben IP erreichbar ist. Diese Methode ist, ohne da weiter drauf eingehen zu wollen, großer Mist, da wir selber Buch darüber führen müßten, welches Gerät nun welche IP hat, damit wir z.B. nicht dieselbe IP nochmals vergeben. Bei einer Änderung des Subnetzes, z.B. bei einem Routerwechsel, stünde ein derart konfigurierter Host auch auf einmal außerhalb des angestammten Subnetzes.

      Eleganter ist da die statische Adressvergabe per DHCP. Dazu sagen wir einfach dem DHCP-Server, daß er dem Gerät mit einer bestimmten Hardware-Adresse (MAC) immer eine bestimmte IP zuweisen soll. Die Adresskonfiguration erfolgt dann immer noch per DHCP, nur eben immer mit derselben Adresse. In der Fritz!Box geht das, indem man auf der Seite Heimnetz beim gewünschten Gerät einen Haken in die Box "Diesem Gerät immer dieselbe Adresse zuweisen" machen. Bei einer Änderung des Subnetzes müssen wir so wenigstens nur an einer Stelle, im Router, eingreifen.
      Heutzutage erfolgt meist auch die Zuweisung von DNS-Servern und die Definition des "Standard-Gateways" (Wohin angeschlossene Geräte alle Daten-Pakete hinschicken sollen, wenn sie nicht selber wissen, was damit zu tun ist) über DHCP.
    • Auch für IPv6 kann man DHCP zur Adressvergabe verwenden, also DHCPv6.
      Das ist aber relativ unüblich, i.d.R. wird man SLAAC verwenden wollen. Bei SLAAC weisen sich die angeschlossenen Geräte den Host-Teil der Adresse selber zu und das bereits bevor sie eine Verbindung haben. Daher auch das "State-Less" bzw. "Zustandslos" in "StaleLess Address AutoConfiguration".

      Dazu verwendet das Gerät seine Hardware-Adresse (MAC), die folgendes Format hat
      AA:BB:CC:DD:EE:FF, also 48 Bit
      fügt in der Mitte "FF:FE" ein (Damit haben wir die benötigten 64 Bit) und kippt das 7. Bit (Wert = 2) des ersten Blocks. Zu guter Letzt wird das ganze noch in 16 Bit-Blöcke geschrieben.
      Aus der MAC 00:22:15:15:BE:7D wird also ...
      ... Einfügen von FF:FE -> 00:22:15:FF:FE:15:BE:7D
      ... Kippen des 7. Bits: -> 02:22:15:FF:FE:15:BE:7D
      ... in 16 Bit Blöcken -> 0222:15ff:fe15:be7d
      Damit hat jedes Gerät schon einen fertigen Host-Teil für eine IPv6-Adresse.

      Um die Adresskonfiguration abschließen zu können, braucht es aber noch ein Subnet. Hierzu nimmt es einfach fe80:: und fertig ist eine link-local-Adresse, also z.B. fe80::222:15ff:fe15:be7d oder in lang fe80:0:0:0:222:15ff:fe15:be7d
      Sobald das Gerät Informationen über das verwendete öffentliche IPv6-Präfix weiß, weist es sich dieselbe Adresse mit diesem Präfix zusätzlich als öffentliche IPv6-Adresse zu. Bei dem Präfix 2001:db8:affe:0 wäre das also die 2001:db8:affe:0:222:15ff:fe15:be7d.

      Auf einer Kommandozeile kann man sich das mit "ipconfig /all" sehr schön ansehen (Vgl. die Parallelen zwischen "physikalischer Adresse" (=MAC) und IPv6, 2. Hälfte):
      Code: Alles auswählen
      Beschreibung. . . . . . . . . . . : Marvell Yukon 88E8001/8003/8010 PCI Gigabit Ethernet Controller
      Physikalische Adresse . . . . . . : 00-22-15-XX-XX-XX
      DHCP aktiviert. . . . . . . . . . : Ja
      Autokonfiguration aktiviert . . . : Ja <-- = SLAAC
      IPv6-Adresse. . . . . . . . . . . : 2001:db8:affe::222:15ff:feXX:XXXX(Bevorzugt)
      Verbindungslokale IPv6-Adresse  . : fe80::222:15ff:feXX:XXXX%11(Bevorzugt)


      Was das Gerät auf diese Weise nicht konfigurieren kann, sind das Standardgateway und der oder die DNS-Server. Hierzu verwendet man auch weiterhin meistens DHCP bzw. DHCPv6, nur eben ohne Adressvergabe.
      Die Kombination aus SLAAC für die Adresskonfiguration und DHCPv6 für die Zuweisung von Gateway und DNS nennt sich auch "Stateless DHCPv6".
  • Privacy Extension
    Weil es Paranoiker gibt, die die Preisgabe der MAC-Adresse für heikel halten, gibt es die sog. Privacy Extensions.

    Die Adressbildung erfolgt genauso wie zuvor beschrieben bei SLAAC, es wird jedoch ein anderer konstanter Wert für die Adressbildung verwendet wird und nicht die MAC-Adresse.
    Zusätzlich weisen sich Geräte mit Privacy Extensions eine zweite öffentliche IP zu, bei der der Hostteil NICHT konstant ist, sondern regelmäßig gewechselt wird, also praktisch eine dynamische IPv6 (Innerhalb des zugewiesenen Subnetzes natürlich).

    Ein Gerät kann auch mehrere öffentliche IPv6 haben, z.B. eine mit Privacy Extensions und gewürfeltem IP-Hostteil zum Surfen und eine mit statischem Hostteil, um Dienste/Server daran zu binden. Bei Windows ist dies übrigens der Standard.
  • Öffentliche IP-Bereiche (Routingfähige IP-Bereiche)
    Als routingfähig ist Stand heute der Bereich 2000 bis 3fff definiert.

    Adressen aus diesem Bereich sind "normale" öffentliche IPs, mit folgenden Spezialbereichen:
    Beginnend mit 2001:0: = Übergangsmechanismus Teredo
    Beginnend mit 2001:db8: = Für Dokumentationszwecke zu verwenden (Werden nicht vergeben)
    Beginnend mit 2002: = Übergangsmechanismus 6to4
  • IPv6-Subnetze
    Diese werden von den Providern wahlweise statisch (Jeder Kunde erhält immer wieder das selbe Subnetz) oder dynamisch (Das Subnetz ändert sich mit jeder Einwahl) zugewiesen.

    Es ergibt sich aus der Kombination von Autokonfiguration und Subnetzvergabe, daß die resultierenden IPv6-Adressen sein können:
    • komplett statisch
      Statisches Subnetz und SLAAC ohne Privacy Extensions
    • komplett dynamisch
      Dynamisches Subnetz und SLAAC mit Privacy Extensions
    • teilweise dynamisch
      • Bei einem dynamischen Subnetz und SLAAC ohne Privacy Extensions bleibt der Host-Teil der Adresse immer gleich.
        Bei einem unveränderten und offenbar aus einer MAC generierten Hostteil ist die Wahrscheinlichkeit groß, daß es sich trotzdem um denselben Rechner handelt, auch wenn sich das Subnetz geändert hat. Noch größer ist diese Wahrscheinlichkeit, wenn beide Subnetze dem selben Provider oder gar der selben Region zugeordnet werden können.
      • Bei einem statischen Subnetz und SLAAC mit Privacy Extensions bleibt der Subnetz-Teil der Adresse immer gleich.
        In diesem Fall sind alle Vorgänge mit dieser IP eindeutig immer demselben Anschluß zuzuordnen, es ist nur nicht transparent, welches Gerät im Heimnetz ihn veranlaßt hat.

    Statische Subnetze wären also im Sinne eines vollwertigen Zuganges das Ideal, denn damit wäre ohne weitere Verrenkungen ein stabiler Zugriff von außen auf Geräte zuhause möglich (Z.B. NAS, Receiver, IP-Webcam, Heimautomatisierung, ...).
    Es ist aber abzusehen, daß die Provider uns unter dem Vorwand der "Privatsphäre" nur dynamische Subnetze geben werden. Für Zugriffe von außen werden wir also weiterhin DynDNS-Dienste benötigen, während Hinz und Kunz sowieso anhand von Subnetz und Uhrzeit vom Provider gesagt bekommen, welcher Anschluß dahintersteckt.

Zusammenfassung

IPv6 wurde nötig, um bei einer steigenden Anzahl internettauglicher Geräte jedem Gerät eine eigene IP zuweisen zu können und somit einen vollwertigen Internetzugang zu ermöglichen:
Auch Endkunden erhalten nun nicht mehr nur eine einzige IPv4, die über Hilfsmechanismen mit allen Geräte im Heimnetz geteilt werden muß, sondern ein ganzes Subnetz mit Abermillionen Adressen. Bei üblichen Standardeinstellungen werden sich IPv6-taugliche Geräte im Heimnetz selbständig konfigurieren. Ob die resultierenden IP-Adressen statisch oder dynamisch sind, wird im wesentlichen dadurch beeinflußt, ob der eigene Provider ein statisches oder dynamisches Subnetz zuweist, da der Hostteil der IP durch Konfiguration am Gerät beeinflußt werden kann (statisch oder dynamisch oder beides gleichzeitig). IPv6-Adressen haben 128 Bit, die in 8 Blöcken hexadezimal geschrieben werden, z.B. 2001:db8:affe:0:0:1ff:e14:1234. Aufeinanderfolgende Doppelpunkte :: in IPv6-Adressen stehen immer für so viele Blöcke mit dem Wert 0, wie nötig sind, um die Adresse auf 8 Blöcke zu erweitern (::1 = 0:0:0:0:0:0:0:1).

Zwischen einem vollwertigen Zugang mit IPv4 und einem vollwertigen mit IPv6 besteht bezüglich der technischen Möglichkeiten kein Unterschied. Da private Endkunden in der Vergangenheit eigentlich noch nie vollwertige IPv4-Zugänge erhalten haben, hat IPv6 hier technisch betrachtet nur Vorteile.
Eventuelle Nachteile bei der Benutzung von IPv6 entstehen aus der Inkompetenz diverser Hard- und Softwarehersteller und der Trantütigkeit der Internet-Provider und sollen in einem späteren Teil des Workshops beleuchtet werden.
Benutzeravatar
SpaceRat
Glasfaserstrecke
 
Beiträge: 2423
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen

Kommunikation in TCP/IP-Netzen, also auch dem Internet

Beitragvon SpaceRat » 14.08.2013, 21:37

Kommunikation in TCP/IP-Netzen, also auch dem Internet

Dieses Kapitel ist für diejenigen gedacht, die wissen wollen, wie wir über IPv6 kommunizieren können.
Eigentlich stellt sich diese Frage nämlich gar nicht, da es in diesem Punkt keine Unterschiede zu IPv4 gibt.

Funktionsweise

Lassen wir einmal die bekannten Einschränkungen von Privatkunden-IPv4-Anschlüssen beiseite, dann funktioniert die Kommunikation in TCP/IP-Netzen unabhängig von IPv4 oder IPv6 nach folgendem Prinzip (Wobei ich stark vereinfache, das OSI-Schichten-Modell erspare ich Euch):

In einem TCP/IP-Netzwerk hat jedes angebundene Gerät eine IP-Adresse, durch die es eindeutig gekennzeichnet ist. Wenn Rechner A einen Server auf Rechner B erreichen möchte, dann wird ein Paket auf die Reise geschickt, das die IP-Adresse von Rechner A als Absendeadresse und die IP-Adresse von Rechner B als Zieladresse enthält. Zusätzlich enthält das Paket noch Informationen darüber, mit welchem Dienst des Zielrechners Rechner A verbunden werden möchte.
Bei den Diensten gibt es einige "wohlbekannte" (well defined), definierte Dienste mit einem standardisierten Port, wodurch wir selten Ports mit angeben müssen, weil der beteiligte Client einfach den Standardport annimmt, wenn wir keinen angeben.

Beispiel:
  1. Rechner A habe die IP 217.45.67.13 und Rechner B die IP 173.194.70.106
  2. Rechner A möchte den Web-Server auf Rechner B erreichen
  3. Der Web-Client schickt nach Eingabe der Adresse 173.194.70.106 einen Anfrage an 173.194.70.106:80, also die IP-Adresse von Rechner B, ergänzt um den Port 80, den wohlbekannten Port für das http-Protokoll.
  4. Rechner B empfängt das von A geschickte Paket und erkennt anhand des angefragten Ports 80, daß er die Anfrage an den auf ihm laufenden Web-Server (Der ja an eben diesen Port 80 gebunden ist) weiterleiten soll.
  5. Rechner B leitet das Paket an den Web-Server weiter und dieser gibt die gewünschte Antwort raus
  6. Rechner B schickt nun ein an Rechner A rückadressiertes Paket mit der Antwort des Webservers
  7. Rechner B erhält das Antwortpaket, leitet es an den Web-Browser weiter und der kann es nun anzeigen

An diesem Beispiel ändert sich absolut gar nichts, wenn Rechner A nun nicht mehr die IPv4-Adressen 217.45.67.13 sondern die IPv6-Adresse 2001:db8:affe:c0co:27b:d0d1:675:abca und Rechner B nicht mehr die IPv4-Adresse 173.194.70.106 sondern z.B, die IPv6-Adresse 2a00:1450:4001:c02::68 hätte!

Aus diesem Grund reicht es eigentlich völlig, wenn sich ein Server sowohl an die IPv4 als auch an die IPv6 des Rechners bindet, um sowohl mit IPv4-Clients als auch mit IPv6-Clients zusammenarbeiten zu können.
Ich habe das "und" gesondert markiert, weil ein IPv4-Client nicht mit einem IPv6-Server und ein IPv6-Client nicht mit einem IPv4-Server kommunizieren kann, sondern immer nur protokollgleiche Client<>Server-Kombinationen. Dazu später mehr.

Weil wir Menschen uns Zahlenkolonnen schlecht merken können, benutzen wir statt dieser numerischen IP-Adressen lieber sprechende "URL" (Uniform Ressource Locators), also z.B. http://www.google.com statt 2a00:1450:4001:c02::68 oder 173.194.70.106.
Für diese "Magie" findet vor jeder neuen Verbindung zu einem Server ein vergleichbarer Zugriff auf einen anderen Server statt, den DNS-Server (Das S ist hier nicht doppelt gemoppelt, denn DNS steht für Domain-Name-System). Der DNS-Server ist der einzige Rechner, den jedes angebundene Gerät mit Nummer kennen muß, wenn es über URLs auf andere Rechner zugreifen können will.

Für das Beispiel von vorhin heißt das, wenn Rechner A den DNS 217.45.67.1 nutzt:

  1. Rechner A habe die IP 217.45.67.13 und Rechner B die IP 173.194.70.106
  2. Rechner A möchte den Web-Server auf Rechner B erreichen, kennt aber nicht dessen IP, sondern nur seinen Namen "www.google.com".
  3. Der Web-Client schickt nach Eingabe der Adresse http://www.google.com eine Anfrage an den Rechner 217.45.67.1 auf Port 53, also die IP-Adresse des DNS, ergänzt um den Port 53, den wohlbekannten Port für das DNS.
  4. Der Rechner "DNS" mit der IP 217.45.67.1 empfängt ein Paket von Rechner A und erkennt anhand des angefragten Ports 53, daß er die Anfrage an den auf ihm laufenden DNS-Server (Der ja an eben diesen Port 53 gebunden ist) weiterleiten soll.
  5. Rechner "DNS" leitet das Paket an den DNS-Server weiter und dieser gibt die gewünschte Antwort raus (Nämlich, welche IP(s) hinter http://www.google.com steckt/stecken, also 2a00:1450:4001:c02::68 und 173.194.70.106)
  6. Rechner "DNS" schickt nun ein an Rechner A rückadressiertes Paket mit der Antwort des DNS-Servers
  7. Rechner B erhält das Antwortpaket, leitet es an den Web-Browser weiter und der weiß nun, daß er entweder über IPv6 mit 2a00:1450:4001:c02::68 oder über IPv4 mit der 173.194.70.106 sprechen will
  8. Der Web-Browser schickt nun eine Anfrage an 173.194.70.106:80, also die IPv4-Adresse von Rechner B, ergänzt um den Port 80, den wohlbekannten Port für das http-Protokoll.
  9. Rechner B empfängt das von A geschickte Paket und erkennt anhand des angefragten Ports 80, daß er die Anfrage an den auf ihm laufenden Web-Server (Der ja an eben diesen Port 80 gebunden ist) weiterleiten soll.
  10. Rechner B leitet das Paket an den Web-Server weiter und dieser gibt die gewünschte Antwort raus
  11. Rechner B schickt nun ein an Rechner A rückadressiertes Paket mit der Antwort des Webservers
  12. Rechner B erhält das Antwortpaket, leitet es an den Web-Browser weiter und der kann es nun anzeigen

Wieder ändert sich absolut gar nichts, wenn der Rechner A in Schritt 8 entschieden hätte, das Paket an [2a00:1450:4001:c02::68]:80 zu schicken, statt an 173.194.70.106:80 (IPv6-Adressen schreibt man innerhalb von URLs in eckigen Klammern, damit der entsprechende Client die IP von einer eventuellen Port-Angabe unterscheiden kann, die ja ebenfalls mit Doppelpunkt abgetrennt wird). Es wäre lediglich die Antwort entsprechend an die IPv6-Adresse von Rechner A rückadressiert worden, statt an die IPv4-Adresse.


Kommunikationshindernisse

Wie im vorherigen Kapitel beschrieben, reicht es prinzipiell völlig aus, einen Server auf dem einen Rechner zu starten, damit andere Rechner auf diesen Server zugreifen können. Im Heimnetz machen wir das ständig. Hat der neue Sat-Receiver z.B. ein WebInterface, mit dem man ihn programmieren kann, brauchen wir ihn nur ins Netzwerk zu stöpseln und können von anderen Rechnern im Heimnetz direkt per Web-Browser darauf zugreifen. Ich gebe zu, daß Sat-Receiver im Unitymedia-Forum nicht das beste Beispiel sind, aber bei einem NAS, einer IP-Cam o.ä. ist das auch nicht anders ... :)
Indem wir einfach die IP des Sat-Receivers im lokalen Netzwerk in die Adresszeile unseres Browsers eingeben, öffnen wir dessen Web-Interface, fertig.

Grundsätzlich würde das aus dem gesamten Internet heraus ganz genauso klappen, wenn es da nicht ein paar Hindernisse gäbe, die es auszuräumen gilt, wenn wir diesen Zugriff wünschen:
  1. Die Adresse ist blöd zu merken und ändert sich u.U. auch noch ständig
    Aus diesem Grund gibt es das DNS und sprechende URLs. Das Problem ist, daß wir dem DNS erst noch mitteilen müssen, unter welchem Namen wir unser Gerät zuhause ansprechen wollen, also z.B. als "enigma2.heimnetz.org". Weil es sich aufgrund der ständig ändernden IP des Heimanschlusses auch nicht lohnt, das einem DNS dauerhaft mitzuteilen, nutzen wir DynDNS-Dienste, z.B. afraid.org, no-ip.com, DynDNS.org etc. pp.
    Dies erledigt zum Glück bei den meisten Benutzern auf Wunsch die Fritz!Box gleich mit, sobald sie eine Verbindung (neu) aufbaut, so daß man relativ problemlos dieses Ziel erreicht ...
    Code: Alles auswählen
    C:\>nslookup ultimo.blah.com.
    [...]
    Nicht autorisierende Antwort:
    Name:    ultimo.blah.com
    Addresses:  2001:db8:fd23:842d:21d:ecff:fe02:5df6
              176.198.12.15

    ... also daß sich unser gewünschter Name jederzeit zu der aktuellen IP unseres Receivers auflösen läßt.
    Bei IPv6 haben wir hier ein kleines Problem: Die Witz!Box stellt sich etwas störrisch, dazu später mehr ...
  2. Firewalls
    Windows und diverse Linux-Distributionen besitzen standardmäßig eine Firewall oder der Benutzer hat selber eine (oft sogar zusätzliche ;) ) installiert.
    Eine stinknormale "gute" Firewall macht folgendes: Sie reagiert auf allen Ports und läßt alle Pakete fallen, die darauf eingehen. Sie erfüllt damit eine enoooorm wichtige Aufgabe, denn genau das selbe hätte der TCP/IP-Stack auch so gemacht, wenn auf dem entsprechenden Port kein Dienst konfiguriert ist. Eine stinknormale schlechte Firewall antwortet mit Paketen nach der Devise "Du kummst hier net rein" und verrät damit einem potentiellen Angreifer
    • daß es einen Rechner mit dieser Adresse gibt
    • daß dieser Rechner auch läuft und freudig auf Angriffe wartet
    • das verwendete Betriebssystem und damit, auf welche potentiellen Schwachstellen man sich als Angreifer konzentrieren kann
    • die verwendete Firewall-Software und damit, auf welche zusätzlichen potentiellen Schwachstellen - die es ohne die zusätzliche Software gar nicht gäbe - man sich als Angreifer konzentrieren kann
    An dieser Stelle wird der berechtigte Benutzer eine entsprechende Ausnahme zum Firewall-Regelwerk definieren, die Zugriffe von außen auf den gewünschten Dienst ermöglicht, also ein Problem lösen, das er ohne die Firewall nicht hätte. Der unbedarfte Benutzer wird übrigens genauso gut jeder Schadsoftware den Zugriff vom bzw. auf das Internet ermöglichen, weshalb Fachleute auch nichts von "Personal Firewalls" (Das sind solche Firewalls, die direkt auf dem entsprechenden Rechner laufen) halten.
    Besser als eine Personal Firewall ist es allemal, den Rechner vernünftig zu konfigurieren, also Dienste, die nicht benötigt werden, ganz abzuschalten, statt sie offen zu lassen und dann nachträglich durch eine PFW "abzuschranken". Wenn auf einem Rechner eh nur das an Diensten läuft, was auch erreichbar sein soll, dann bringt eine PFW keine zusätzliche Sicherheit mehr (Durch das zusätzliche Stück Software sogar das Gegenteil), weil der Rechner eh nur da angreifbar ist, wo er auch antwortet, diese Dienste würde man in der Firewall aber eh öffnen.
    Ich will nicht so weit gehen, jedem zu empfehlen, den bremsenden Firewall-Kram auf dem PC zu deinstallieren, dafür können einfach zu wenige Normalnutzer einen PC sicher konfigurieren, aber alles, was über die standardmäßige Windows-Firewall hinausgeht ist reine Geldschneiderei. Merkt man auch schon an der nach Aufmerksamkeit heischenden, grellbunten, peppigen Aufmachung dieser ganzen "Security Suites".

    Ausdrücklich ausgenommen von dieser Kritik sind übrigens
    • Die Firewall des Routers
      und/oder
    • externe, dedizierte Firewalls (Also Geräte, deren Hauptaufgabe es ist, nachgeschaltete Geräte zu schützen)
      denn diese verhindern, daß unerwünschte Pakete überhaupt bis zum Angriffsziel kommen.

      Auf jeden Fall lautet die Lösung an dieser Stelle: Wenn wir von außen mit einem Dienst auf einem lokalen Rechner kommunizieren können wollen, dann müssen wir die dazugehörigen Ports auch in der/den Firewall(s) auf dem Weg dorthin freigeben.
  3. IPv4: Network Address Translation (NAT) oder IPv4-Adressmangel
    Wie schon erwähnt sind IPv4-basierte Privatkunden-Internet-Zugänge selten vollwertig. Dies äußert sich darin, daß man als Endkunde nicht genug IPv4-Adressen für alle Geräte bekommt, sondern nur eine einzige für das gesamte Netzwerk.
    Als Abhilfe werden die Geräte im lokalen Netzwerk in einem vom Internet getrennten Netz betrieben und mit privaten IPv4-Adressen versehen, meistens aus dem Bereich 192.168.x.y. Das einzige Gerät, das wirklich eine öffentliche IPv4-Adresse hat, ist der Router. Alle Geräte im Heimnetz können über das Hilfsmittel NAT von innen nach außen mit dem Internet kommunizieren. Dazu muß der Router bei jedem Zugriff nach außen Buch darüber führen, welcher Rechner jetzt welche Antworten erwartet, damit Rechner A aus unserem Beispiel von oben auch wirklich die Antwort von http://www.google.com erhält, die er wollte und nicht die, die zeitgleich das Notebook 1 oder das Smartphone 1 angefordert hat. Im Beispiel aus dem ersten Abschnitt heißt das, daß sich der Router in einem zwischen Schritt 3 und 4 einzufügenden Abschnitt merken muß, daß Rechner A (Der nun nicht mehr über eine öffentliche sondern nur über eine private IP verfügt) eine Anfrage an Rechner B rausgeschickt hat und in einem Zusatzschritt zwischen Schritt 6 und 7 rausklamüsern muß, daß das empfangene Antwortpaket zu dieser Anfrage gehört.
    Der hier beschrieben Vorgang ist letztlich etwas, das auch richtige Firewalls machen: Stateful Packet Inspection (SPI), also eine "zustandsbasierte Paket-Untersuchung". Basierend darauf, daß die eingehenden Pakete zu einer offenen Verbindung (Das ist der besagte "Zustand") gehören, werden sie durchgelassen, bei NAT werden die Pakete noch anhand der Tatsache zu welcher Verbindung sie gehören, an den passenden Rechner umgeleitet.
    All dies kostet übrigens richtig Rechenpower und ist der Grund dafür, daß gerade ältere Fritz!Boxen bei vielen gleichzeitigen Zugriffen so gerne abschmieren!

    Für einen Zugriff von außen nach innen, müssen wir dem Router aber weitere Informationen geben.
    Aus Sicht des Internets kommuniziert ein einziger Rechner mit dem Rest des Internets, nämlich unser Router: Jeder ausgehende Traffic wird dort auf unserer einen IP gebündelt und die Antworten werden a la Müllsortierung wieder den Maschinen im Netz zugeordnet, die darauf warten.
    Eingehende Pakete kann der Router aber nicht nach dem Prinzip der Mülltrennung dem entsprechenden Rechner zuordnen, an den sie weitergeleitet werden sollen. Dazu müssen wir diesem einzigen wirklich mit dem Internet verbundenen Gerät mitteilen, welches Gerät im lokalen Heimnetz diese Anfragen beantworten soll. Dazu dienen Port-Weiterleitungen, die dem Router sagen "Wenn Du eine Anfrage auf Port xx empfängst, dann leite sie zur Beantwortung an Rechner C weiter, der sie auf Port yy beantwortet". Daß hierbei zwei Ports bzw. Portbereiche angegeben werden (müssen) hängt damit zusammen, daß der Router für jeden seiner Port natürlich nur eine einzige Regel haben kann und wir somit bei mehreren gleichen Diensten auf der Außenseite unterschiedliche Ports benutzen müssen.
    Heißt also: Nur ein Webserver kann auf dem Standardport 80 antworten, alle anderen müssen extern auf nicht-standardisierte verbogen werden.
  4. IPv4: CGN / Carrier Grade NAT
    Nutzt zusätzlich auch der Provider NAT, dann CGN (Carrier Grade NAT) genannt, können wir eine wie im vorherigen Abschnitt beschriebene Port-Weiterleitung nicht einrichten, da wir keinen Zugriff auf den NAT-Router des Providers (Das AFTR-Gateway) haben.

    Die unseligen Punkte NAT und CGN können wir dank IPv6 mit seinen ausreichend großen Subnetzen zunehmend aus dem Gedächtnis streichen!
  5. IPv4 vs IPv6: Ein Kommunikationspartner verfügt nicht über IPv6-Konnektivität
    Selbst wenn ansonsten alle Probleme ausgeräumt sind, nutzt uns ein IPv6-angebundener Server samt IPv6-tauglichem Client nichts, wenn uns an dem Anschluß, von dem aus wir auf den Server zugreifen wollen, keine IPv6-Anbindung zur Verfügung steht.
    In einem weiteren Kapitel werde ich erklären, wie man diesem Problem ganz leicht Abhilfe schafft, wenn uns der Internet-Anbieter kein IPv6 zur Verfügung stellt.
  6. IPv4 vs IPv6: Ein Server bzw. Dienst ist nur für IPv4 programmiert
    Ein Client und ein Server können nur dann miteinander kommunizieren, wenn beide dieselbe Sprache sprechen, also entweder beide IPv4 oder beide IPv6.
    Im Idealfall sind Server heutzutage Dual-Stack-kompatibel, funktionieren also sowohl mit IPv4- als auch über IPv6-Clients.
    Da dieser Workshop den Hintergrund IPv6 hat und die Kommunikation über IPv4 in diesem Zusammenhang wegen DS-lite meist ausfällt, werde ich in späteren Kapiteln Wege aufzeigen, wie man einige solcher Serverdienste, die von sich aus nur IPv4 können, IPv6-tauglich macht.

Zusammenfassung:
TCP/IP-Kommunikation erfolgt auf Grundlage der IP-Adressen der Teilnehmer sowie auf der Angabe eines Ports, der angibt, welcher Server-Dienst (HTTP, POP3, IRC, HTTPS, TeamSpeak, ....) erreicht werden soll.
Grundsätzlich funktioniert diese Kommunikation unabhängig davon, ob IP-Adressen im Format IPv4 oder im Format IPv6 verwendet werden.
Für die Kommunikation von "innen nach außen" sind keine weiteren Schritte nötig, diese funktioniert notfalls auch über NAT, da sich Antworten immer ihren zugehörigen Anfragen und damit dem darauf wartenden Rechner zuordnen lassen.
Um selber einen Server/Dienst zu betreiben, genügt es prinzipiell, diesen zu installieren und ihn ggf. in zwischengeschalteten Firewalls zu öffnen.
  • Bei Zugriff über IPv6 sind keine weiteren Maßnahmen nötig.
  • An den üblichen eingeschränkten IPv4-Zugängen muß zusätzlich eine Port-Weiterleitung eingerichtet werden, da nur der Router eine echte Internet-Verbindung hat, i.d.R. aber ein Rechner im mit lediglich privaten IP-Adressen versehenen Heimnetz statt des Routers antworten soll.
  • An IPv4-Zugängen mit CGN (Carrier Grade NAT) kann eine solche Port-Weiterleitung nicht eingerichtet werden.

In den folgenden Kapiteln werde ich mich damit befassen, wie man die o.g. Kommunikationshindernisse ausräumt.
Benutzeravatar
SpaceRat
Glasfaserstrecke
 
Beiträge: 2423
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen

DynDNS für IPv4-Adressen

Beitragvon SpaceRat » 14.08.2013, 21:41

Ab diesem Kapitel werde ich mich der Lösung der im vorherigen Kapitel genannten Kommunikationshindernisse widmen, beginnend mit dem 1. Punkt ...

Lösung Hindernis 1: Nicht zu merkende IP / DynDNS

Damit wir uns nicht unsere - auch immer wieder wechselnde - IP merken müssen, um von unterwegs auf Rechner im Heimnetz zugreifen zu können, gibt es diverse DynDNS-Dienste. Diese ermöglichen es uns, unsere Rechner zuhause unter einer sprechenden Adresse wie z.B. spacerat.dyndns.org o.ä. zu erreichen, hinter der immer die jeweils aktuelle öffentliche IP hinterlegt ist.

DynDNS für IPv4-Adressen

Diesen Abschnitt werde ich extrem kurz halten:
Wer einen DynDNS-Dienst für IPv4 braucht, weiß eh schon, wie es geht oder findet jede Menge Quellen im Internet. Noch eine weitere Auflistung, wie man DynDNS-Dienste in Router A, B, C, D bis ZZZ einrichtet, braucht kein Mensch.

Wichtig sind hier eigentlich nur folgende zwei Aspekte:
  1. Wenn wir keine öffentliche IPv4-Adresse mehr haben, weil unser Anschluß per DS-lite erfolgt, dann brauchen wir auch keinen DynDNS mehr für die IPv4-Adresse! Sie ändert sich sowieso innerhalb von wenigen Minuten und bietet uns auch keinen Zugriff von außen!
  2. Mit IPv4 hatten wir als Privatkunden immer nur eine einzige öffentliche IP-Adresse (Die des Routers) und haben Geräte im Heimnetz nur über den Port bzw. entsprechende Port-Weiterleitungen gezielt ansprechen können.
    Diesen Aspekt einfach im Hinterkopf behalten ...


DynDNS für IPv6-Adressen

Bedeutsam für diesen Workshop ist es, wie wir unsere IPv6-Adresse unter einem sprechenden Namen erreichbar machen.

Leider gibt es hierbei mehrere Probleme:
  1. Es gibt nicht sonderlich viele (kostenfreie) DynDNS-Dienste, die mit IPv6-Adressen umgehen können.
    Eigentlich gibt es überhaupt kaum noch kostenfreie DynDNS-Dienste, fast alle kosten zumindest Nerven, weil man sie ständig aktiv halten muß.
  2. Wir brauchen fortan für jedes Gerät, das aus dem Internet erreichbar sein soll, einen eigenen DynDNS, so wie auch jedes Gerät seine eigene IP hat.
    In vielen Fällen disqualifiziert das "spendable" Dienste wie DynDNS.org, wo man sage und schreibe einen einzigen Host-Eintrag kostenlos kriegt.
  3. Die Unterstützung für IPv6 in DynDNS-Diensten in Routern ist mau bis nicht vorhanden.
  4. Es gibt nicht mehr "die eine" IP-Adresse, die es zu aktualisieren gilt, sondern mehrere (Die wir für ein Update ja auch erst einmal herausfinden müssen).

Aus den vorgenannten Gründen gehe ich hier nur auf den "FreeDNS"-Dienst von afraid.org ein, weil
  • er sich in den Punkten 1 und 2 wohltuend abhebt - Wir erhalten wirklich kostenfrei und ohne ständige Nerv-Mails 5 Einträge.
  • er Optionen bietet, die anderen DynDNS-Diensten fehlen, uns das Leben aber deutlich einfacher machen
  • es gibt Update-Clients für nahezu alle Betriebssysteme, was uns sehr bei den Punkten 3 und 4 hilft.

Um es mit Merkels Worten zu sagen: Für IPv6 ist afraid.org derzeit alternativlos.

Einrichtung von DynDNS-Diensten bei IPv6

Ich gehe davon aus, daß die eigentliche Registrierung eines Kontos bei http://freedns.afraid.org niemandem Probleme bereiten dürfte und vor den weiteren Schritten bereits erfolgt ist.

Prinzipiell erfolgen die Updates von DynDNS-Diensten bei IPv6 genauso, wie bei IPv4 auch. Der Hauptunterschied liegt darin, daß wir nicht mehr mit einem einzigen Update für die eine öffentliche IPv4 fertig sind, sondern die DynDNS-Einträge für alle Geräte aktuell halten müssen, die von außen erreichbar sein sollen.
Bei IPv4-DynDNS-Diensten hat diese Aufgabe meistens unser Router für uns erledigt, denn er kennt seine öffentliche IPv4 und kriegt auch einen IP-Wechsel als Erster mit. Wenn der Router diese Möglichkeit nicht anbot, war es aber auch kein Problem, das Update stellvertretend durch ein beliebiges anderes Gerät im Heimnetz erledigen zu lassen, da die externe/öffentliche IPv4 ja auch für alle gleich war. Das ist so nun nicht mehr der Fall, weshalb solche stellvertretenden Updates auch deutlich schwieriger sind.

Ich werde im Folgenden zwei Wege aufzeigen, diese Updates zu bewerkstelligen, einen einfachen, aber an bestimmte Voraussetzungen (Aktuelle Fritz!Box als Router) gebundenen, Weg und einen allgemeingültigen, aber aufwendigeren.
Benutzeravatar
SpaceRat
Glasfaserstrecke
 
Beiträge: 2423
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen

DynDNS-Updates über MyFritz!

Beitragvon SpaceRat » 14.08.2013, 21:44

Fortsetzung Lösung Hindernis 1: Nicht zu merkende IP / DynDNS

DynDNS-Updates über MyFritz!

Dieser Weg steht allen offen, die eine Fritz!Box 63x0, 73x0, 7270v3, 7270v2 oder diverse 72x0 als Router nutzen und ist kinderleicht einzurichten.
Herausragender Aspekt ist, daß auf diese Weise tatsächlich die Fritz!Box die Aktualisierung beliebig vieler DynDNS-Einträge für uns übernimmt, diese also auch sehr zeitnah nach einem Präfix-Wechsel erfolgen.

  • Auf der Einstiegsseite der Fritz!Box-Oberfläche, die wir durch Eingabe von http://fritz.box in der Adresszeile des Browsers erreichen, wählen wir links aus dem Menü "Internet" und daraus den Unterpunkt "Freigaben" und dann rechts den Reiter "IPv6" (Oder von der Startseite direkt rechts aus den Komfortfunktionen den Punkt "IPv6-Freigabe")
  • Sollten hier bereits Freigaben existieren, dann löschen wir diese nun (Ggf. vorher Screenshots anlegen, um zu wissen, was freigegeben war)
  • Nun wechseln wir über das Menü auf der linken Seite zum "Internet"-Unterpunkt "MyFRITZ!"
  • Von dort aus können wir ein MyFRITZ!-Konto anlegen, sofern nicht bereits geschehen.
  • Sobald das Konto angelegt ist und unsere Fritz!Box damit angemeldet ist, erhalten wir an der vorgenannten Stelle ungefähr folgende Ansicht:
    Bild
  • Jetzt wählen wir, immer noch unter "Internet"->"MyFRITZ!" den Reiter "MyFRITZ!-Freigaben" aus.
  • Unterhalb der, noch leeren, Liste finden wir den Button "Neue MyFRITZ!-Freigabe", den wir anklicken
    Wir erhalten in etwa folgende Ansicht:
    Bild
  • Aus der ersten Dropdown-Auswahl wählen wir das Gerät aus, für das eine Freigabe erstellt werden soll und aus der zweiten den Dienst, der freigegeben werden soll.
    Wenn wir den freizugebenden Dienst hier nicht finden sollten, können wir auch einfach "HTTPS-Server" auswählen, wir können später nämlich noch beliebig viele weitere Dienste hinzufügen.
    Das Ergebnis sieht dann in etwa so aus:
    Bild
  • Mit einem Klick auf "OK" speichern wir unsere neue Freigabe ab.
  • Wir kommen zurück zur Übersicht der MyFRITZ!-Freigaben, wo wir nun unsere neue Freigabe bewundern können:
    Bild
  • Spätestens an diesem Punkt wird wohl klar, wieso ich hier etwas von Freigaben beschreibe, wo wir doch eigentlich einen DynDNS einrichten wollten ...
    Die Fritz!Box hat nämlich mit diesen Schritten mehrere Dinge auf einmal erledigt:
    • Eine neue IPv6-Freigabe für dieses Gerät angelegt
    • Eine neue IPv4-Portweiterleitung auf dieses Gerät eingerichtet (Zumindest an Dual-Stack-Anschlüssen)
    • Und, last but not least, einen DynDNS-Namen für das Gerät angelegt, bestehend aus dem Gerätenamen (Hier: "Plasma") und der MyFRITZ!-Adresse (Der Buchstabensalat, gefolgt von .myfritz.net), komplett also plasma.<Buchstabensalat>.myfritz.net
  • Wem dieser kryptische DynDNS reicht, kann hier aufhören. Zur Not kann man die Adresse auch jederzeit von außerhalb herausfinden, indem man auf "http://myfritz.net" geht und dort vor dem Login unter "Mehr" die "Geräteübersicht" auswählt. Dann kriegt man alle Geräte mit ihrer jeweiligen Adresse angezeigt, für die es MyFRITZ!-Freigaben gibt.
  • Um den doch etwas kryptischen Namen durch einen einfacher zu merkenden zu ersetzen, gehen wir nun im Web-Browser auf http://freedns.afraid.org/subdomain/ , wo wir ja schon ein Konto angelegt haben.
  • Dort können wir nun über das Menü in der Mitte mit "Add" einen neuen Eintrag anlegen.
  • Wir wählen "CNAME" als Record Type aus, suchen uns eine schöne Subdomain (Hostname) und eine schöne Domain aus und tragen die nackte MyFRITZ!-URL für unser Gerät ein, also weder das https:// noch die Portangabe, nur die URL
    Die fertig ausgefüllte Maske sollte wie folgt aussehen:
    Bild
    Optional darf auch noch Wildcard: [X] angekreuz werden.
  • Nur noch eben mit "Save" abspeichern und unser Rechner "Plasma" ist fortan unter der Adresse "plasma.crabdance.com" aus dem Internet erreichbar. Wenn wir im vorherigen Schritt "Wildcard" mit ausgewählt haben, führen uns auch http://www.plasma.crabdance.com, ftp.plasma.crabdance.com, schrompf.plasma.crabdance.com etc. pp. auf unseren Rechner.
    Das können wir überprüfen, indem wir auf einer Windows-/Linux-Kommandozeile eingeben
    Code: Alles auswählen
    nslookup plasma.crabdance.com

    wobei das Ergebnis in etwa so aussehen sollte:
    Code: Alles auswählen
    Server:  fritz
    Address:  192.168.1.1

    Nicht autorisierende Antwort:
    Name:    plasma.ekufgjhnfgjnfggj.myfritz.net
    Addresses:  2001:db8:affe:c0c0:21d:ecff:fe16:1234
    Aliases:  plasma.crabdance.com
  • Fertig.
    Die Fritz!Box erledigt jetzt für uns die Aktualisierung der kryptischen MyFRITZ!-Adresse mit der jeweils aktuellen IP und der FreeDNS ist sowieso nur ein Alias für die MyFritz!-Adresse, braucht also nicht weiter gepflegt werden.
Benutzeravatar
SpaceRat
Glasfaserstrecke
 
Beiträge: 2423
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen

DynDNS-Updates auf dem "klassischen" Weg

Beitragvon SpaceRat » 14.08.2013, 21:47

Fortsetzung Lösung Hindernis 1: Nicht zu merkende IP / DynDNS

DynDNS-Updates auf dem "klassischen" Weg

Wer eine Fritz!Box 63x0, 73x0, 7270v3, 7270v2 oder diverse 72x0 als Router nutzt, ist mit dem zuvor beschriebenen Weg deutlich besser bedient und sollte ihn daher nach Möglichkeit auch nutzen!
Für Besitzer des TC7200 oder des Cisco 3208G wage ich auch die Aussage, daß sich ein Umstieg auf die Fritz!Box 6360 (Durch Buchen von Telefon Komfort) oder 6320 (WLAN-Option) durchaus lohnt, denn bei den erstgenannten Geräten sind zwar die DynDNS-Updates lösbar, aber der Ärger geht bei den Freigaben weiter. Von allen Unitymedia-Zwangsroutern sind die Fritz!Boxen noch am wenigsten kastriert.

Mit der hier beschriebenen Methodik können DynDNS-Updates auf afraid.org auch mit (fast) jedem im Heimnetz angeschlossenen Gerät durchgeführt werden, sie müssen dann aber - mit gewissen, komplizierteren Ausnahmen - durch und für jedes von außen erreichbar zu haltende Gerät einzeln vorgenommen werden.

Um einfach nur den FreeDNS-Eintrag für ein Gerät durch eben dieses Gerät aktuell zu halten, brauchen wir den Update-Client "inadyn-mt". Leider zirkuliert auf vielen Geräten immer noch der antiquierte Client "inadyn" (ohne -mt) herum, der inzwischen eigentlich völlig wertlos ist.

Schritt 1: FreeDNS-Eintrag anlegen

  • Auf http://freedns.afraid.org einen FreeDNS/afraid.org-Account anlegen, sofern noch nicht geschehen.
  • Im Web-Browser die Seite http://freedns.afraid.org/dynamic/ aufrufen.
  • Über das Menü in der Mitte mit "Add" einen neuen Eintrag hinzufügen
  • Als "Type" wählen wir "AAAA" für einen IPv6-Eintrag. (A= IPv4, AAAA= IPv6, CNAME= ein Alias für einen anderen Hostname, ....)
    Nun suchen wir uns eine schöne Subdomain (Hostname) und eine schöne Domain aus. Bei Destination tragen wir vorerst "::1" ein, die wird durch ein späteres Update noch korrigiert.
    Im Ergebnis sieht die Maske nun in etwa so aus:
    Bild
    Optional können wir noch Wildcard: [X] ankreuzen, dann führen uns später auch http://www.plasma.crabdance.com, ftp.plasma.crabdance.com, schrompf.plasma.crabdance.com etc. pp. auf unseren Rechner.
  • Der FreeDNS-Eintrag wird nach einem Klick auf "Save!" abgespeichert und wartet darauf, in Zukunft von uns aktuell gehalten zu werden.
  • Wir brauchen für die spätere Verwendung durch den Update-Client noch den "Hash"-Wert zum aktualisieren dieses Hosts.
    Dazu gehen wir wieder auf http://freedns.afraid.org/dynamic/ und klicken mit der rechten Maustaste auf den Link "Direct URL" (Siehe Bild)
    Bild
    und dort ja nach verwendetem Brower auf "Link-Adresse kopieren", "Adresse des Links kopieren", o.ä.
    Der Link sieht in etwa wie folgt aus, wovon wir später den rot markierten Teil noch benötigen:
    http://freedns.afraid.org/dynamic/update.php?MXY4C0Y5BhBMbkFHVFhXcnllMnpSaWM1Ojk5NzE5NTE=
  • Hinweise:
    • Jeder (weitere) FreeDNS-Eintrag hat hier seinen eigenen Hash-Wert und muß entsprechend separat ausgewertet werden.
    • Wir können für denselben Hostname auch zwei Einträge anlegen, einen mit Type AAAA für IPv6 und einen mit Type A für IPv4, was natürlich nur Sinn ergibt, wenn wir auch wirklich einen Dual-Stack-Anschluß haben.

Schritt 2a: FreeDNS-Update auf Windows-Rechnern

  • Da es im Netz keine brauchbare Windows-Version gab, habe ich selber eine kompiliert und hier hochgeladen.
    Diese bitte zuerst herunterladen und das gesamte in dem ZIP-Archiv gespeicherte Verzeichnis z.B. nach "C:\Programme" bzw. "C:\Program Files (x86)" bzw. "C:\Program Files" auspacken. Ich gehe im weiteren Verlauf von "C:\Programme\inadyn-mt" als Speicherort aus.
  • In das Verzeichnis C:\Programme\inadyn-mt wechseln
  • Es befinden sich drei Beispielkonfigurationen in dem Verzeichnis (Der Bestandteil .reg wird evtl. nicht auf allen Rechnern angezeigt):
    • freedns_DualStack.reg - Für Rechner mit vollwertigem Dual-Stack (z.B. IPv4 durch den Provider und IPv6 per Tunnel)
    • freedns_IPv4.reg - Für Rechner mit IPv4-only (Für den Workshop eher uninteressant, aber der Vollständigkeit halber vorhanden)
    • freedns_IPv6.reg - Für Rechner mit IPv6-only bzw. DS-lite
    Wir suchen uns die passende aus (Für die Leser dieses Workshops i.d.R. freedns_IPv6.reg) , klicken diese mit der rechten Maustaste an und wählen "Bearbeiten", um die Datei in Notepad zu öffnen.
  • Wir sehen nun in Notepad ungefähr Folgendes:
    Code: Alles auswählen
    REGEDIT4
    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\inadyn-mt\Parameters]
    "AppParameters"="--dyndns_system default@freedns.afraid.org --background --update_period 60000 --alias meinpc.mooo.com,KRyPTiScHerHaSHGEHOERTHiERHeREInGEFuEGt....= ip6 --log_file inadyn_srv.log --ip_server_name dhis.org /"

    davon müssen wir die hier rot und grün markierten Teile anpassen:
    --alias meinpc.mooo.com,KRyPTiScHerHaSHGEHOERTHiERHeREInGEFuEGt....= ip6
  • An Stelle des rot markierten Teiles fügen wir unsere in Schritt 1 angelegte Subdomain ein, also in unserem Beispiel "plasma.crabdance.com", der grün markierte Teil wird durch den am Ende von Schritt 1 ermittelten "Hash" ersetzt.
  • Anmerkung: Hätten wir die Konfiguration für IPv4 benutzt, stünde dort
    --alias meinpc.mooo.com,KRyPTiScHerHaSHGEHOERTHiERHeREInGEFuEGt....= ip4
    zum Aktualisieren eines vorher von uns angelegten "A"-Type Records (IPv4) und bei der DualStack-Konfiguration entsprechend beide Einträge, also einen für unseren A-Type Records (IPv4) und unseres AAAA-Type Records (IPv6), die wir analog zur vorher beschriebenen Weise mit ihren jeweiligen Hashes versorgen müßten.
  • Die Änderungen abspeichern und Notepad schließen
  • Durch Doppelklick auf die Datei und bestätigen der Abfrage(n) werden die Angaben aus der Datei in der Registry gespeichert.
  • Durch Doppelklick auf die Datei "install_inadyn-mt_service.bat" (Evtl. ist das .bat nicht zu sehen) wird der inadyn-mt-Dienst installiert
  • Der inadyn-mt-Dienst wird beim nächsten Systemstart gestartet, prüft fortan jede Minute (60000 Millisekunden) , ob sich die IPv6 geändert hat und aktualisiert sie ggf.
  • Wird ein längeres Prüfintervall gewünscht, einfach das gewünschte Intervall in die gewählte Konfigurationsdatei schreiben und diese erneut in die Registry importieren. Sie überschreibt dabei die alten Werte.

Schritt 2b: FreeDNS-Update auf Linux/*ix-Rechnern (Hier läuft Ehnix, weil's Zunix-kompatibel ist)

  • Zuerst einmal müssen wir uns inadyn-mt beschaffen und installieren. Je nach Prozessorarchitektur (Also eigentlich auf jedem Gerät außer normalen PCs) müssen wir es sogar selber kompilieren.
    Für diesen Workshop würde es zu weit führen, alle möglichen Varianten zu beschreiben, wie man inadyn-mt installiert bekommt, da Linux nicht einmal von einer zur anderen Distribution konsistent bleibt.
  • Zumindest in aller Regel sollte die Konfigurationsdatei von inadyn-mt "/etc/inadyn-mt.conf" heißen.
    Sie sollte in etwa folgenden Inhalt haben:
    Code: Alles auswählen
    --dyndns_system default@freedns.afraid.org
    --background
    --update_period 60000
    --alias meinpc.mooo.com,KRyPTiScHerHaSHGEHOERTHiERHeREInGEFuEGt....= ip6
    --ip_server_name dhis.org /

    Genau wie bei Windows müssen wir die hier rot und grün markierten Teile anpassen:
    --alias meinpc.mooo.com,KRyPTiScHerHaSHGEHOERTHiERHeREInGEFuEGt....= ip6
  • An Stelle des rot markierten Teiles fügen wir unsere in Schritt 1 angelegte Subdomain ein, also in unserem Beispiel "plasma.crabdance.com", der grün markierte Teil wird durch den am Ende von Schritt 1 ermittelten "Hash" ersetzt.
  • Die inadyn-mt.conf abspeichern, die Rechte geeignet setzen (Im Zweifelsfall "chmod 777 inadyn-mt.conf" :) ) und gucken, wie die "Methode des Tages" geht, um inady-mt beim Systemstart mit zu laden. Will heißen: Wie die verwendete Version der verwendeten Distribution der verwendeten Unox-Abart Dienste startet.
    Tut mir leid, ich kann dem inkonsistenten Flickwerk aus den 60ern, genannt Unix, GNU, Linux, BSD, oder wie auch immer, nichts abgewinnen. Leider findet man genau dieses System mit Sicherheit spätestens dann vor, wenn man einen Enigma2-Receiver mit erreichbar machen will.

Schritt 2d: FreeDNS-Update auf einem Gerät, stellvertretend für ein oder mehrere andere(s) Gerät(e). (Nur für Profis)

Was jetzt folgt ist keine abschließende Anleitung, die zu einem direkt nutzbaren Ergebnis führt, sondern mehr ein Brainstorming zu einem Lösungsansatz für ein noch zu schreibendes Script/Tool.

  • Wenn es uns nicht möglich ist, die FreeDNS-Updates für ein Gerät auf diesem selber durchführen zu lassen, können wir das auch durch ein anderes Gerät erledigen lassen.
  • Dazu nutzen wir folgende Kenntnis aus:
    An der IP ändert sich, normale Adresskonfiguration vorausgesetzt, immer nur das Subnetz und das ist für alle Rechner im selben Netz gleich. Der Hostteil hingegen ergibt sich ja aus der Hardware-Adresse/MAC und ist damit dauerhaft gleich.
  • Wir benötigen dafür die gesamte "Direct Update URL" aus Schritt 1 statt nur des Hashes
  • An die "Direct Update URL", die ja wie folgt aussieht ...
    http://freedns.afraid.org/dynamic/updat ... k5NzE5NTE=
    ... hängen wir an ...
    &address=
    sowie das durch unser das Update durchführende Gerät ermittelte aktuelle Subnetz (Schlichtweg die ersten 4 Blöcke seiner eigenen öffentlichen IPv6) und den vorher hinterlegten Hostteil der Adresse des Gerätes, für das wir das Update durchführen (Die letzten 4 Blöcke dessen öffentlicher IPv6).
  • Die komplettierte Update-URL, dann in etwa so aussehend ...
    http://freedns.afraid.org/dynamic/update.php?MXY4C0Y5BhBMbkFHVFhXcnllMnpSaWM1Ojk5NzE5NTE=&address=2001:db8:affe:c0c0:02ab:cdff:feef:1234
    (grün = gleichbleibender Teil ; blau = Subnetz, ändert sich zwar, ist aber für alle Geräte im Netz gleich ; rot = Hostteil der Adresse, ändert sich bei normaler SLAAC-Adressvergabe nie, kann also vorher einmalig ermittelt werden)
    .. müssen wir dann nur noch auf irgendeine Weise öffnen, völlig egal ob das im Browser, per wget oder curl und/oder in einem Perl-/Python-/PowerShell-/AutiIt- oder Sonstwas-Script erfolgt, es erfüllt seinen Zweck.
Benutzeravatar
SpaceRat
Glasfaserstrecke
 
Beiträge: 2423
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen

Lösung Hindernis 2 (& 3): Firewalls / IPv4-NAT

Beitragvon SpaceRat » 14.08.2013, 21:49

Lösung Hindernis 2 (& 3): Firewalls / IPv4-NAT

In diesem Abschnitt werde ich erklären, wie man die Router-Firewall für Anfragen von außen öffnet, um einen Server betreiben zu können.
Für IPv4 wird dabei immer auch gleichzeitig eine Port-Weiterleitungsregel erzeugt.

Einrichtung von Port-Weiterleitungen bei IPv4

Ich werde an dieser Stelle kurz die Einrichtung von Port-Weiterleitungen bei IPv4 erklären, um später bei IPv6 auf Gemeinsamkeiten oder eben Unterschiede verweisen zu können.

Wie wir gelernt haben, sind unsere IPv4-Anschlüsse nicht vollwertig, in dem Sinne, daß wir für unsere Server zuhause eine öffentliche IP hätten.
Deshalb müssen wir im Router Port-Weiterleitungen einrichten, was ich hier anhand einer Fritz!Box 7390 mal aufzeigen werden. Bei der 63x0 und anderen aktuellen Fritz!Box-Modellen ist das Prinzip das selbe und bei anderen Routern in ähnlicher Form gegeben.
In englischsprachigen Router-Oberflächen heißt der Menüpunkt für die Konfiguration von IPv4-"Freigaben" meistens "Port-Forwarding".

Wichtiger Hinweis: An einem DS-lite-Anschluß ist die Einrichtung von IPv4-Portweiterleitungen wirkungslos, weil Anfragen von außen erst gar nicht bis zu unserem Router kommen, sondern schon im CGN des Providers hängen bleiben!

  1. Auf der Einstiegsseite der Fritz!Box-Oberfläche, die wir durch Eingabe von http://fritz.box in der Adresszeile des Browsers erreichen, wählen wir links aus dem Menü "Internet" und dann daraus den Unterpunkt "Freigaben" oder direkt rechts aus den Komfortfunktionen den Punkt "Portfreigabe".
  2. Wir landen auf der Seite mit den IPv4-Portfreigaben bzw. Weiterleitungen, die ich hier aus Datenschutzgründen nicht wiedergebe :)
  3. Hier können wir nun durch Klick auf das Notizbuch neben einer bestehenden Portfreigabe diese ändern oder durch Klick auf [Neue Portfreigabe] eine neue anlegen. Da sich diese Erklärung an Einsteiger richtet, gehe ich vom Anlegen einer neuen Freigabe aus ...
  4. Nach Klick auf "Neue Freigabe" erhalten wir in etwa folgende Ansicht (Ich habe bereits in der ersten Drop-Down-Box "Andere Anwendungen" statt "HTTP-Server" (= Web-Server) ausgewählt):
    Bild
    In dieser Ansicht haben wir folgende Eingabemöglichkeiten:
    • Portfreigabe aktiv für ....
      Hier können wir einige wenige bekannte Dienste auch direkt auswählen. Zur Verfügung stehen FTP-Server, HTTP-Server, eMule TCP, eMule UDP, MS Remotedesktop, Andere Anwendungen und Exposed Host.
      Was sich dahinter versteckt ist ganz einfach: Der weiterzuleitende Port, nämlich 21 extern auf 21 intern für FTP, 80 extern auf 80 intern für HTTP, 4662 extern auf 4662 intern, 4672 UDP extern auf 4672 UDP intern, 3389 extern auf 3389 intern, manuelle Eingabe (Andere Anwendungen) oder (fast) alle (Exposed Host).
      Wollen wir einen FTP- oder HTTP-Server betreiben, reicht hier, die entsprechende Auswahl zu treffen. Die Verwendung der Standardports für eMule wird nicht empfohlen, weshalb man lieber andere über "Andere Anwendungen" manuell einstellt und MS Remotedesktop ist unsicher und sollte gar nicht erst freigegeben werden. Die Einstellung "Exposed Host" brauchen wir nur dann, wenn wir einen Rechner als Server für alles definieren wollen, i.d.R. wird man diese Einstellung nur vornehmen, um einen anderen Router hinter der Fritz!Box zu betreiben.
      Die Vorauswahl funktioniert auch nur für je einen einzigen der angegebenen Server. Möchte man also z.B. einen zweiten FTP-Server betreiben, dann ist der Port 21 extern ja schon für den ersten FTP-Server vergeben, so daß man den zweiten FTP-Server nicht mehr mit der Voreinstellung für FTP-Server einrichten kann.
      Meistens wird man hier also "Andere Anwendungen" auswählen, um einen oder mehrere Ports manuell einzugeben.
    • Bezeichnung
      Wenn wir im ersten Schritt "Andere Anwendungen" ausgewählt haben, dann können wir unserer Freigabe hier einen Namen geben, beispielsweise "Enigma2 WebInterface" für das WebInterface unserer Enigma2-Receivers.
    • Protokoll
      Hier haben wir TCP, UDP, ESP und GRE zur Auswahl.
      I.d.R. werden wir nur TCP und UDP benötigen. Welches wir im konkreten Fall benötigen, zeigt uns ein Blick in die Dokumentation der entsprechenden Software.
      Unter Umständen müssen wir auch mehrere Ports und/oder Protokolle für einen Serverdienst freigeben. Dann müssen wir, wenn es nicht um einen aufeinanderfolgenden Portbereich geht, mehrere Freigaben für diesen Server anlegen.
      Für einen HTTP-Server, wie es das Web-Interface eines Sat-Receivers ist, wählen wir hier TCP, wie übrigens meistens.
    • Von Port .... bis Port ...
      Dies spezifiziert, auf welchen externen Ports, also an der öffentlichen IP, die erwarteten Anfragen eintreffen.
      Meistens wird man hier natürlich den oder die gleichen Port(s) wählen, die der Dienst auch tatsächlich nutzt, manchmal haben wir aber entweder die freie Auswahl oder aber wir wollen einen zweiten, gleichartigen Dienst freigeben und müssen deshalb an dieser Stelle einen anderen Port wählen als den "normalen".
      Beispiel: Für das Beispiel HTTP würde man hier von Port 80 bis Port 80 einstellen.
      Wir tun jetzt mal so, als hätten wir schon einen HTTP-Server laufen und weichen daher für unser WebInterface am Receiver auf "Port 81 bis 81" aus.
    • an Computer
      Gibt den Rechner im Heimnetz an, für den diese Freigabe gelten soll. Meistens können wir ihn einfach aus einer Liste von der Fritz!Box bekannten Rechnern auswählen, ansonsten können wir ihn auch durch "manuelle Eingabe der IP-Adresse" angeben.
    • an IP-Adresse
      Wenn wir im vorherigen Schritt einen Rechner ausgewählt haben, dann sehen wir hier zur Kontrolle die IP, unter der die Fritz!Box diesen kennt.
      Ansonsten können wir hier die IP des Ziel-Rechners selber eingeben.
    • an Port
      Der Port, auf dem der Dienst auf dem angegebenen Rechner läuft.
      Welche wir im konkreten Fall benötigen, zeigt uns ein Blick in die Dokumentation der entsprechenden Software, sofern wir die Ports nicht selber auswählen durften.
      Sofern wir unter "von Port ... bis Port ..." durch Angabe zweier unterschiedlicher Werte extern einen ganzen Port-Bereich ausgewählt haben, dann dient die Angabe an dieser Stelle als Start-Wert für den internen Port-Bereich.
      Für das WebInterface unseres Beispiels wählen wir Port 80.
    Fertig ausgefüllt sieht unsere Beispielfreigabe nun in etwa so aus:
    Bild
  5. Nach Klick auf "Ok" wird die neue oder geänderte Freigabe gespeichert und ist auch direkt aktiv

Was wir mit diesen Einstellungen tatsächlich gemacht haben ist folgendes:
  1. Wir haben den externen Port 81 (Also den Port 81 der öffentlichen IPv4-Adresse) auf den internen Port 80 des Gerätes "Ultimo" verbogen bzw. umgeleitet (Deshalb heißt dieser Punkt bei anderen Routern auch "Port-Weiterleitung" oder "Port Forwarding", was eigentlich korrekt wäre)
    und
  2. es wurde der (öffentliche) Port 81 in der internen Firewall der Fritz!Box geöffnet

Bei einem Zugriff auf das Web-Interface von außerhalb passiert nun folgendes:

  1. Der WebClient auf einem Rechner außerhalb öffnet die Adresse "öffentliche_IP_der_Fritz!Box:81"
  2. Die Fritz!Box prüft die Anfrage gegen die eigene Firewall, stellt fest, daß sie zulässig ist
  3. gleichzeitig lenkt sie den Zugriff auf die interne IP des Enigma-Receivers um (Da sie ja nicht selber antworten soll)
  4. Das Web-Interface des Receivers erhält die Anfrage von außerhalb und schickt die Antwort über die Fritz!Box zurück ins Internet, also an den Rechner, der die Anfrage gestartet hat.
Benutzeravatar
SpaceRat
Glasfaserstrecke
 
Beiträge: 2423
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen

Einrichtung von Port-Freigaben bei IPv6

Beitragvon SpaceRat » 14.08.2013, 21:51

Lösung Hindernis 2: Firewalls

Einrichtung von Port-Freigaben bei IPv6

Kommen wir nun zu dem für viele spannendsten Teil des Ganzen, den IPv6-Freigaben. Vielleicht ist dem ein oder anderen aufgefallen, daß ich hier von "Freigaben" spreche, während ich bei IPv4 von "Weiterleitungen" sprach. Das hängt damit zusammen, daß jeder Rechner im Netz eine eigene IPv6-Adresse hat, was einerseits bedeutet, daß die Freigaben etwas anders funktionieren und zum anderen, daß keine "Weiterleitung" im Sinne einer "Umleitung" mehr nötig ist. Daher fehlt auch in diesem Kapitel das "Problem 3 - NAT" in der Überschrift ... es stellt sich nämlich nicht.

Wieder beschreibe ich die Freigaben anhand einer Fritz!Box 7390, wobei sich diese bei den Fritz!Boxen 63x0, 7270v3, 7270v2 usw. identisch gestalten. Leider läßt sich diese Vorgehensweise wesentlich schlechter auf andere Router übertragen, weil es anscheinend noch keinen Konsens gibt, wie diese Konfiguration auszusehen hat.
Nach derzeitigem Kenntnisstand hat der Cisco EPC3208G z.B. gar keine Firewall für IPv6 (Man muß also einerseits keine Freigaben einrichten ;), andererseits ist aber auch das gesamte Netzwerk ungeschützt) und beim TC7200 läßt sich die Firewall nur komplett ein- oder eben komplett ausschalten.
Wieder ein Grund, doch noch in Erwägung zu ziehen, durch Produktwechsel zumindest an eine Fritz!Box 6320 oder gar 6360 zu kommen, immerhin steht man mit den anderen Routern entweder mit dem Schw... in der Hand nackt im Regen oder ist - beim TC7200 - wahlweise komplett ausgesperrt.

  1. Auf der Einstiegsseite der Fritz!Box-Oberfläche, die wir durch Eingabe von http://fritz.box in der Adresszeile des Browsers erreichen, wählen wir links aus dem Menü "Internet", daraus den Unterpunkt "Freigaben" und dann rechts den Reiter "IPv6" oder direkt rechts aus den Komfortfunktionen den Punkt "IPv6-Freigabe".
  2. Wir landen auf der Seite mit den IPv6-Freigaben, die ich hier ebenfalls aus Datenschutzgründen nicht wiedergebe :)
  3. Hier können wir nun durch Klick auf das Notizbuch neben einer bestehenden Freigabe diese ändern oder durch Klick auf [Neues Gerät] neue anlegen.
    Schon durch die Wortwahl "Neues Gerät" wird deutlich, daß ein Punkt anders ist als bei IPv4: Für ein Gerät im Heimnetz legen wir nur ein einziges Mal eine neue Freigabe an, danach ändern wir diese nur noch.
    Bei den IPv4-Freigaben ging das nicht, weil unser ganzes Heimnetz aus Sicht des Internets nur ein einziges Gerät ist und Freigaben auf mehreren Rechnern nur eine Krücke sind.
  4. Sofern Ihr bereits Freigaben über MyFRITZ! angelegt habt, dann finden sich diese auch hier wieder.
    In diesem Fall lest bitte erst alles zuende durch, bevor Ihr loslegt!
    Wenn MyFRITZ! benutzt wird, dürfen nur noch die vorhandenen Freigaben geändert werden, da Ihr Euch sonst die DynDNS-Funktionalität der MyFRITZ!-Freigaben zerschießen könnt.
  5. Nach Klick auf "Neues Gerät" erhalten wir in etwa folgende Ansicht:
    Bild

    Auffällig ist, daß wir in dieser Ansicht weniger Einstellungsmöglichkeiten haben als bei den IPv4-Freigaben, was daraus resultiert, daß die IPv6-Freigaben technisch tatsächlich einfacher sind!

    Wir haben lediglich zwei grundlegende Eingabemöglichkeiten:
    • Freigabe aktiviert für
      Name
      Interface-ID

      Gibt den Rechner im Heimnetz an, für den diese Freigaben gelten sollen.
      Meistens können wir ihn einfach aus einer Liste von der Fritz!Box bekannten Rechnern auswählen, ansonsten können wir ihn auch manuell eingeben, wenn wir unter Name "Benutzerdefiniert" auswählen.
      Wählen wir einen bekannten Rechner aus, dann wird auch die Interface-ID (richtig) vorbelegt, ansonsten müssen wir diese selber eingeben.
      Wieso nun aber eine Interface-ID und keine IP?
      Ganz einfach: Die Interface-ID ist im Idealfall ja nichts anderes als der Host-Teil der IPv6 des Ziel-Gerätes!
      Da das Subnet-Präfix dynamisch sein könnte, müßten wir die Freigaben immer und immer wieder ändern, wenn sich das Subnet ändert. Außerdem erfährt die Fritz!Box über sog. "Router Advertisement" sowieso, wie das Präfix lautet, weiß es somit also grundsätzlich selber.
      Wenn wir also in die Verlegenheit kommen sollten, hier einen Rechner manuell eintragen zu müssen, dann ist hier die MAC des Zielrechners gefragt, erweitert um FF FE in der Mitte und dem 7 Bit gekippt, siehe dazu den ersten Teil.
      Zum Glück müssen wir das nicht wirklich selber eintragen, sondern können einfach aus der Liste auswählen, sobald sich ein Gerät mit funktionierender IPv6-Unterstützung das erste Mal an der Fritz!Box angemeldet hatte.
    • Wahlweise "Firewall für dieses Gerät im Heimnetz komplett öffnen." oder "Firewall nur für bestimmte Protokolle öffnen."
      Hier können wir auswählen, ob der Rechner komplett aus dem Internet erreichbar sein soll oder ob wir nur einzelne Ports bzw. Protokolle eintragen wollen.
      Tatsächlich: Da jeder Rechner seine eigene, vollwertige IP hat, könnten wir hier wirklich den ganzen Rechner aus dem Internet erreichbar machen, ohne deshalb bei den Freigaben für andere Rechner eingeschränkt zu sein!
      Es sind eher Sicherheitsbedenken, wegen der wir hier trotzdem lieber "Firewall nur für bestimmte Protokolle öffnen." auswählen.
      In der untenstehenden Liste können wir nun unsere erste Freigabe eintragen, also z.B.
      TCP von Port 80 bis Port 80
      um einen HTTP-Server auf dem ausgewählten Gerät erreichbar zu machen.
      Wichtig: Da steht von Port bis Port und genau das ist auch gemeint: Ein Port-Bereich und keine Port-Umleitung.
      Eine Umleitung im Sinne von einem externen Port(-Bereich), der auf einen völlig anderen internen Port(-Bereich) zeigen soll, brauchen wir bei IPv6 nicht!
      Wir können durchaus für jedes angeschlossene Gerät bezogen auf die freigegebenen Ports dieselben Freigaben machen, also auf Wunsch auch 100 Web-Server betreiben und alle laufen auf dem Standard-Port!
    • Nach Klick auf "Ok" wird die neue Freigabe gespeichert und ist auch direkt aktiv

    Was wir mit diesen Einstellungen tatsächlich gemacht haben ist folgendes:
    Wir haben in der internen Firewall der Fritz!Box den Port 80 für unseren Receiver geöffnet, mehr nicht.

    Bei einem Zugriff auf das Web-Interface von außerhalb passiert nun folgendes:

    1. Der WebClient auf einem Rechner außerhalb öffnet die Adresse "öffentliche_IP_des_Receivers"
    2. Die Fritz!Box prüft die Anfrage gegen die eigene Firewall, stellt fest, daß sie zulässig ist
    3. das Web-Interface des Receivers erhält die Anfrage von außerhalb und schickt die Antwort zurück ins Internet, also an den Rechner, der die Anfrage gestartet hat.

    Beim Ändern oder Zufügen einer Freigabe zu einem vorhandenen Gerät ändert sich die Maske ein wenig:
    1. Name und Interface-ID können manuell eingegeben werden, nicht aber durch eine Drop-Down-Box ausgewählt werden. Das brauchen wir aber auch gar nicht.
    2. Hinter bereits freigegebenen Ports steht ein X zum Löschen dieser Freigabe
    3. Durch Eintragen anderer Ports lassen sich bestehende Freigaben ändern
    4. Per Klick auf [Neue Freigabe] erhalten wir eine neue Zeile, in die wir eine weitere Freigabe eintragen können
    Das Schema bleibt dabei das selbe: Die IPv6-Freigabe macht nichts weiter, als die Firewall auf den angegebenen Ports für den angegebenen Rechner zu öffnen. Eine Port-Umleitung ist niemals nötig.

Abweichungen bei der Nutzung von MyFRITZ!

Wenn wir MyFRITZ!-Freigaben angelegt haben, um damit auch bequem einen immer aktuellen DynDNS-Eintrag zum entsprechenden Gerät zu haben, dann finden wir alle Geräte, für die wir das gemacht haben, bereits hier in der Liste.
Weitere Freigaben bzw. zusätzlich zu öffnende Ports dürfen dann diesen Geräten nur noch durch Klick auf das Notizbuch-Symbol hinzugefügt werden, keinesfalls sollte man versehentlich ein bereits über MyFRITZ! freigegebenes Gerät hier nochmals hinzufügen (Was die Fritz!Box zwar auch meistens, aber eben nicht immer, verhindert).
Leider heißen die Geräte alle "MyFRITZ-::aaaa:bbbb:cccc:dddd", also "MyFRITZ-::" gefolgt von der Interface-ID des Gerätes. Das macht sie relativ schlecht unterscheidbar, aber dennoch sollten wir sie nicht umbenennen, denn dabei geht nicht selten auch die DynDNS-Funktionalität kaputt.
Ebenfalls geht die DynDNS-Funktionalität kaputt, wenn man ein "MyFRITZ-::"-Gerät hier aus der Liste löscht, selbst wenn man es unmittelbar danach unter selbem Namen wieder hinzufügt, oder wenn man den ursprünglich in MyFRITZ! freigegebenen Port rausnimmt.

Also: Vorhandenen MyFRITZ!-Freigaben können wir zwar freizugebende Ports hinzufügen oder auch wieder wegnehmen (Außer dem, den wir in MyFRITZ! selber zugefügt haben, in meinem Beispiel war das immer Port 443), dies aber immer nur über das "Notizbuch".
Wenn wir hier versehentlich ein MyFRITZ!-Gerät ganz löschen oder ihm den beim Anlegen der MyFRITZ!-Freigabe freigegebenen Port abnehmen, dann müssen wir zur Wiederherstellung inkl. der DynDNS-Aktualisierung das Gerät unter "IPv6-Freigaben" komplett löschen - sofern noch nicht geschehen - und auch die MyFRITZ!-Freigabe erst löschen und dann auch zuerst also solche neu anlegen.


Aus diesem Grunde übrigens auch meine Präferenz für Port 443/HTTPS-Server:
Diese Freigabe ist i.d.R. unbedenklich, denn entweder
- will man ihn eh freigeben
oder
- es läuft gar kein entsprechender Server auf dem Gerät, die Freigabe ist also wirkungslos
oder
- der Server, den man erreichen kann, obwohl wir das eigentlich gar nicht wollten, dürfte einigermaßen sicher sein.
Demzufolge kann man sie in den meisten Fällen bedenkenlos mißbrauchen, um das Gerät bei MyFRITZ! bekannt zu machen, ohne daß man in die Verlegenheit kommt, diese Freigabe später wieder löschen zu wollen.
Benutzeravatar
SpaceRat
Glasfaserstrecke
 
Beiträge: 2423
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen

Lösung Hindernis 4: IPv4: CGN / Carrier Grade NAT

Beitragvon SpaceRat » 14.08.2013, 21:54

Lösung Hindernis 4: IPv4: CGN / Carrier Grade NAT

Für dieses Hindernis gibt es keine einfache Lösung auf Basis irgendwelcher Konfigurationsänderungen. Man ist und bleibt über CGN per IPv4 von außen unerreichbar.

Es ergeben sich somit zwei Lösungsansätze:
  1. Man versucht, dieselbe Funktionalität über IPv6 zu erreichen, was i.d.R. auch funktioniert.
    Insgesamt ist dies die einfachere Lösung, da man früher oder später sowieso mit IPv6 konfrontiert wird. Tut man das früher, dann reicht das alleine aus.
  2. Man stellt volle IPv4-Konnektivität wieder her.
    "Kostenlos" und einfach kriegt man das nur hin, wenn man dazu einfach nur einen Produktwechsel beim Internet-Provider rückgängig machen muß oder sich wieder - was auch nur bei KabelBW geht oder ging, nicht aber bei Unitymedia - auf IPv4 umstellen läßt oder alternative Anbieter zur Auswahl hat, die auch in der sonstigen Leistung mithalten können.
    Anderenfalls ist es mit - teils erheblichen - Mehrkosten verbunden, sei es durch Wechsel auf einen Business-Tarif (Bei denen es noch IPv4 gibt, optional sogar statisch und mit Subnetz) oder durch einen bezahlten Tunnel.
    Insbesondere das Aufsetzen eines solchen Tunnels erfordert eine Menge Wissen, wenn es richtig gemacht werden soll und am Ende wird man sich dann doch irgendwann mit IPv6 beschäftigen müssen, da sich auch die Welt um uns herum weiter dreht.
    In diesem Fall wäre dann der Aufwand für die möglichst lange Gegenwehr zusätzlich zu dem angefallen, sich in IPv6 einzuarbeiten.

Ich halte also nicht sonderlich viel von der gelegentlich vorgebrachten Lösung, einen IPv4-in-IPv6-Tunnel zu buchen, um weiterhin eingehende IPv4-Konnektivität zu haben, auch weil diese Lösung eben nur so lange funktioniert, wie man dafür bezahlt.

Trotzdem möchte ich diesen Lösungsansatz nicht unbesprochen lassen.

IPv4-in-IPv6-Tunnel mit öffentlicher IPv4 an unserem Tunnel-Endpunkt

Es gibt bei mehreren Dienstleistern im Internet die Möglichkeit, VPN-Tunnel zu buchen, z.B. bei Portunity. Bei vielen dieser Tunnel erhält man eine öffentliche IPv4, teilweise sogar statisch, über den Tunnel. Über diese IPv4 ist man von außen erreichbar, solange der Tunnel aufrecht erhalten wird.

Dabei gibt es aber einige Aspekte zu bedenken:
  • Per se ist man gegenüber dem Tunnel nicht durch eine Firewall geschützt. Dies muß separat konfiguriert werden.
  • Es erfordert Planung, über welches Gerät man den Tunnel aufbauen möchte, denn nur solange dieses Gerät läuft, ist man auch über den Tunnel erreichbar.
  • Viele Anbieter bieten ihre Tunnel nur über IPv4 an, d.h. wir tunneln am Ende eine IPv4-Verbindung über eine andere IPv4-Verbindung, welche wiederum über IPv6 getunnelt wird. Das bedeutet, daß die Nutzlast eines Paketes im Verhältnis zur transportierten Datenmenge immer kleiner wird.
  • PPTP-Tunnel funktionieren über das IPv4-CGN gar nicht.

Der Idealfall sähe demnach so aus:
  • Der Tunnel kann auch direkt über IPv6 aufgebaut werden.
    Da auch das IPv4-CGN eigentlich ein über die IPv6-Anbindung laufender Tunnel ist, hätte man somit mit dem VPN-Tunnel auch keine Nachteile bzgl. der in einem Paket transportierbaren Nutzlast mehr gegenüber der vorhandenen IPv4-Anbindung.
  • Es steht ein Gerät zur Verfügung, das permanent - zumindest während man Zugriff von außen benötigt - durchläuft und dabei einigermaßen wenig Strom verbraucht.
    Hierfür kommen insbesondere erweiterbare Router (Fritz!Boxen mit Freetz, OpenWRT-Router) oder NAS (Network Attached Storage) Systeme mit VPN-Funktionalität in Frage. Prinzipiell eignen sich auch Enigma2-Receiver, allerdings ist deren Netzwerk- und Prozessor-Leistung nicht selten dürftig und es steht auch keine brauchbare Firewall zur Verfügung.
  • Man kann sicherstellen, daß das Heimnetz am Übergabepunkt zum/vom VPN durch eine Firewall geschützt ist.

Ergo: Die Kosten/Aufwand<>Nutzen-Relation sieht sehr schlecht aus für diese Lösung.
Auch mangels eigener Erfahrung gebe ich hierzu keine weiteren Tips. Wer diesen Weg gehen will, sollte selber über grundlegende Kenntnisse verfügen und/oder sich intensiv in das Thema einlesen, um nicht der Allgemeinheit einen zusätzlichen Zombierechner/Spam-Bot zu verschaffen!
Benutzeravatar
SpaceRat
Glasfaserstrecke
 
Beiträge: 2423
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen

Einrichtung von IPv6-Konnektivität in Routern

Beitragvon SpaceRat » 14.08.2013, 21:55

Lösung Hindernis 5: IPv4 vs. IPv6: Ein Kommunikationspartner verfügt nicht über IPv6-Konnektivität

Nicht selten ist das einzige wirkliche Problem, unser Heimnetz von außerhalb zu erreichen, die fehlende IPv6-Konnektivität des Netzes, von dem aus wir Zugriff wollen.

Die Lösung zu Hindernis 5 stellt meist die einfachere und günstigere Alternative zu der für Hindernis 4 dar:
Anstatt uns selber gegen Geld einen IPv4-Tunnel zu beschaffen, versorgen wir die Gegenseite kostenlos mit IPv6.
Eigentlich ist dies auch nur logisch und konsequent, denn es ist die Seite ohne IPv6, die nicht das gesamte Internet erreichen kann. Es wäre zwar schöner, selber zusätzlich auch per IPv4 erreichbar zu sein, aber immerhin ist von einem DS-lite-Anschluß ausgehend das ganze Internet erreichbar, statt nur einem Teil wie bei einem IPv4-only-Zugang.


Einrichtung von IPv6-Konnektivität in Routern

Im ersten Teil zeige ich, wie man IPv6 im Router einrichtet, auch hier wieder am Beispiel einer Fritz!Box, beginnend mit Unterstützung für natives IPv6, welches durchaus längst vorhanden, aber deaktiviert sein könnte.

Aktivierung eigentlich schon verfügbarer IPv6-Konnektivität bei der Gegenseite

Z.B. an Telekom-AllIP-Anschlüssen ist vollwertiger DualStack (öffentliche IPv4, öffentliches IPv6-Subnetz) bereits geschaltet und wird nur deshalb nicht genutzt, weil IPv6 im Router noch deaktiviert ist.
Bei neueren Fritz!Boxen (ab 7270v2) genügt es oft schon, unter "Internet -> Zugangsdaten" auf dem Reiter "IPv6", diese Einstellung
Bild
durch diese
Bild
zu ersetzen, um zumindest eine grundlegende IPv6-Konnektivität (Ausreichend, um unser Heimnetz zu erreichen) zu erhalten.



Nutzung eines IPv6-Tunnels zur Versorgung der Gegenseite mit IPv6

Wenn die reine Aktivierung von IPv6 nicht zum Erfolg führt, heißt das lediglich, daß auf "automagische" Weise keine Zugangsmöglichkeit gefunden wurde. In diesem Fall kann immer noch manuell ein Tunnel konfiguriert werden.
Der konfigurierte Tunnel bietet sich auch an, wenn bei der automatischen Konfiguration nur ein 6rd-Tunnel herauskommt, wir aber ein eigenes, statisches Subnetz haben wollen.
Auch andere Router als die Fritz!Box bieten teilweise die Möglichkeit, einen IPv6-Tunnel einzurichten.


Einrichten eines SixXS-Tunnels in einer Fritz!Box

SixXS bietet bereits seit einigen Jahren kostenlose IPv6-in-IPv4-Tunnel an, die auch durchaus mit hoher Geschwindigkeit funktionieren, wenn man sich den richtigen "PoP" - also Tunnel-Provider - aussucht. Zudem sind sie in Fritz!Boxen ab 7270v2 auch einfachst einzurichten.

  1. Um einen SixXS-Tunnel nutzen zu können, muß man sich zuerst als Benutzer auf http://www.sixxs.net anmelden.
    Diese Anmeldung wird vor der Freischaltung manuell (Phantasieangaben bei der Anmeldung sollte man also besser vermeiden) geprüft, was auch schon mal einige Stunden dauern kann.
  2. Hat man sich als Benutzer registriert und wurde freigeschaltet, kann man einen Tunnel anfordern ("Request Tunnel")
    Dabei darf man sich aussuchen, über welchen Anbieter man gerne einen Tunnel hätte.
    Für Unitymedia-Kunden drängt sich NetCologne förmlich auf, denn NetCologne hat direktes Peering mit Unitymedia, der Traffic zum Tunnelendpunkt muß also nicht erst über DECIX geschweige denn über Aorta. Im Ergebnis ist der IPv6-Traffic über den Tunnel (Der dann von NC über DECIX, statt wie der IPv4-Traffic von Unitymedia über Aorta, gepeert wird) oft sogar schneller als der über Unitymedias IPv4 ...
    Auch als Vodafone- oder Telekom-Kunde macht man mit NetCologne als PoP nicht viel falsch.
    Zusätzlich müssen wir auswählen, welche technische Variante eines Tunnels wir wünschen:
    • Static (Erfordert eine statische IPv4, könnte man also an Unitymedia-Business-Anschlüssen mit statischer IP nutzen)
    • Heartbeat (Erfordert eine öffentliche IPv4, funktioniert also an allen DSL- und Kabel-Anschlüssen, an denen kein DS-lite geschaltet ist ... aber dann bräuchten wir auch keinen IPv6-Tunnel)
    • ayiya (Anything-in-Anything, funktioniert eigentlich immer, hat aber auch mehr Overhead als ein Heartbeat-Tunnel
    Die beste Wahl für einen normalen DSL- oder Kabel-Anschluß mit IPv4 ist also "Heartbeat", für den Zugang von einem Smartphone oder generell unterwegs aus würden wir "ayiya" wählen.
    Der Tunnel-Request wird nun ebenfalls manuell geprüft, bevor er freigeschaltet wird, was ebenfalls wieder einige Stunden dauern kann.
  3. Im Ergebnis haben wir nun:
    • Einen SixXS-Benutzernamen a la SRX5-SIXXS
    • Ein Kennwort (Bei der Benutzer-Registrierung selber gewählt)
    • Eine Tunnel-ID a la T12345 (Bei der Anmeldung/Bewilligung des Tunnels zugewiesen)
  4. In der Fritz!Box stellen wir unter "Internet->Zugangsdaten" auf dem Reiter "IPv6" ein
    [X] Unterstützung für IPv6 aktiv
    (*) Immer ein Tunnelprotokoll für die IPv6-Anbindung nutzen
    (*) SixXS
    und können dann weiter unten die vorgenannten Daten eintragen:
    Bild
  5. Mit einem Klick auf "Übernehmen" werden die Änderungen gespeichert und der Tunnel aufgebaut.
  6. Et voila, der so konfigurierte Anschluß hat - bis auf die reduzierte MTU von 1280 - vollwertiges IPv6, inkl. eines statischen Subnetzes!

Ein Nachteil der SixXS-Tunnel soll nicht verschwiegen werden:
SixXS nutzt ein "Credit"-System, bei dem man Credits (genannt "ISK") erhält, wenn man die angelegten Tunnel auch nutzt (5 ISK pro Woche) und es Credits kostet (15 ISK insgesamt), weitere Tunnel oder Subnetze zu beantragen.
Die Credits zu Beginn (25 ISK) reichen für den ersten Tunnel (-15 ISK), einen zweiten kann man dann erst beantragen, wenn der erste Tunnel bereits eine Woche aktiv war (25-15+5=15), danach sind alle Credits weg und mindestens einer der Tunnel muß erst einmal für eine ganze Zeit wieder dauerhaft aktiv sein (Insgesamt 3 Wochen für 3x5 ISK, entsprechend kürzer, wenn beide Tunnel dauerhaft aktiv sind...), bevor man wieder genug Credits für einen dritten hat, usw.
Dieses System belohnt jetzt natürlich diejenigen, die sich bereits frühzeitig mit IPv6 beschäftigt, einen Tunnel beschafft und einen solchen schon lange aktiv haben, dadurch sind SixXS-Tunnel aber leider keine schnelle Abhilfe, wenn man jetzt mehrere Tunnel auf einen Schlag dringend benötigt.
Insbesondere "Reserve-Tunnel", die man sich auf dem Smartphone und/oder Notebook nur für den Fall bereit halten will, wenn man sie später mal braucht, erzeugen natürlich kaum bis keine neuen Credits für weitere Tunnel.
Daher sollte man mit einem stationären und dauerhaften Tunnel (z.B. am Zweitanschluß, bei Eltern oder Verwandten, für die man den Internet-Zugang pflegt, oder oder oder) anfangen, die Credits für einen unproduktiven Tunnel kriegt man dann immer wieder rein.

Einrichten eines 6in4-Tunnels in einer Fritz!Box

Eine Alternative zu SixXS-Tunneln steht mit den 6in4-Tunneln zur Verfügung.
Genau betrachtet sind SixXS-Tunnel übrigens auch nur 6in4-Tunnel, für die aber ein eigener Client genutzt wird, welcher uns einen Teil der Arbeit abnimmt. Das bedeutet, daß nackte 6in4-Tunnel etwas aufwendiger zu konfigurieren sind.
Für einen 6in4-Tunnel benötigt man darüber hinaus auch eine öffentliche IPv4, von einem CGN-Anschluß (z.B. Mobilfunk) aus geht es demnach nicht.

  1. Um einen 6in4-Tunnel nutzen zu können, muß man sich zuerst bei einem Tunnelbroker anmelden, ich nutze für das Beispiel Hurricane Electric, neben SixXS einer der bekanntesten Dienste.
    Die Anmeldung bei Hurricane Electric (HE) läuft automatisiert, das Konto kann also fast direkt genutzt werden.
  2. Hat man sich als Benutzer registriert und wurde freigeschaltet, kann man einen Tunnel anfordern ("Create Regular Tunnel")
    Auch hier darf man sich einen Tunnel-Endpunkt aussuchen.
    Wer mag, kann mittels Traceroute auf die neben den zur Auswahl stehenden Endpunkten verzeichneten IPs der Endpunkte den besten ermitteln ... oder einfach Frankfurt auswählen.
  3. Der Tunnel wird direkt angelegt und kann nun im Router konfiguriert werden.
    Die benötigten Informationen finden wir auf tunnelbroker.net, wenn wir den Tunnel anklicken, um die "Tunnel Details" angezeigt zu bekommen.
  4. In der Fritz!Box stellen wir unter "Internet->Zugangsdaten" auf dem Reiter "IPv6" ein
    [X] Unterstützung für IPv6 aktiv
    (*) Immer ein Tunnelprotokoll für die IPv6-Anbindung nutzen
    (*) 6in4
    (Vergleiche Punkt 4 der Anleitung für den SixXS-Tunnel)
    Darunter folgen dann die "Tunnel Details", hier in einer direkten Gegenüberstellung gezeigt:
    Bild
  5. Mit einem Klick auf "Übernehmen" werden die Änderungen gespeichert.

Der Nachteil eines 6in4-Tunnels ist es, daß der Tunnelanbieter immer unsere aktuelle öffentliche IPv4 wissen muß, da er sonst nicht weiß, wohin er die IPv4-Pakete schicken muß, welche die IPv6-Nutzdaten enthalten.
Bei SixXS dienen die heartbeats ("Herzschläge") eines Heartbeat-Tunnels genau diesem Zweck, also am Tunnel-PoP unsere IPv4 aktuell zu halten, was uns die Sorge um diesen Aspekt abnimmt.
An einem nackten 6in4-Tunnel steht diese Funktionalität nicht zur Verfügung, weshalb man dem Tunnel-Broker die aktuelle IPv4 auf anderem Wege mitteilen muß, Hurricane Electric nutzt hierzu einen Mechanismus, wie er auch für diverse DynDNS-Dienste genutzt wird.
Die Update URL für diesen Mechanismus lautet
https://ipv4.tunnelbroker.net/nic/update?username=<USERNAME>&password=<PASSWORD>&hostname=<TUNNEL_ID>&myip=<IP ADDRESS>
Dabei ist <USERNAME> durch unseren HE-Benutzernamen, <PASSWORD> durch unser HE-Passwort, <TUNNEL_ID> durch die ID des Tunnels (Zu sehen bei den Tunnel Details, auf dem Bild oben blau markiert) und <IP ADDRESS> durch die aktuelle IPv4 zu ersetzen (Ebenfalls bei den Tunnel Details blau markiert).
Alternativ kann man die IP auch weglassen, um auf die zu aktualisieren, über die man die Update-Seite aufruft:
https://ipv4.tunnelbroker.net/nic/update?username=<USERNAME>&password=<PASSWORD>&hostname=<TUNNEL_ID>

Um das Dyn-IP-Update durch die Fritz!Box durchführen zu lassen, würde man unter "Internet->Freigaben" auf dem Reiter "DynDNS" als Anbieter "Benutzerdefiniert" auswählen und folgende Update-URL eingeben:
Code: Alles auswählen
ipv4.tunnelbroker.net/nic/update?username=<username>&password=<pass>&hostname=<domain>&myip=<ipaddr>

Danach kann man Benutzername und Kennwort sowie die Tunnel ID (Im Feld "Domainname") normal in die Maske eintragen. Die Fritz!Box übernimmt nun die Aktualisierung der öffentlichen IPv4, wird allerdings für diesen DynDNS-Dienst immer "Fehler" anzeigen, da die Auswertung, ob das Update erfolgreich war, darauf basiert, daß sich der eingegebene Domainname auf unsere IPv4 auflösen läßt. Da die Tunnel ID kein auflösbarer Domain Name ist, kann dieser Test nicht funktionieren.
Man kann dieses Problem umgehen, indem man die Tunnel ID fest in die Update-URL einträgt und als "Domainname" die MyFRITZ!-Adresse einträgt, sofern vorhanden.

Das funktioniert soweit und sobald die IP-Updates erfolgen, funktioniert unser Tunnel auch genauso gut wie ein SixXS-Tunnel, inklusive statischem Präfix.

Da es für viele eher unbefriedigend sein dürfte, wenn sie das einzig mögliche DynDNS-Update in der Fritz!Box für den IPv6-Tunnel verbraten müssen, zeige ich hier eine Möglichkeit auf, wie man beliebig viele DynDNS-Dienste auf einmal aktualisieren kann.
Zuletzt geändert von SpaceRat am 14.08.2013, 22:03, insgesamt 1-mal geändert.
Benutzeravatar
SpaceRat
Glasfaserstrecke
 
Beiträge: 2423
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen

Nächste

Zurück zu Internet und Telefon über das TV-Kabelnetz

Wer ist online?

Mitglieder in diesem Forum: Baidu [Spider], elo22, MSNbot Media und 45 Gäste