- 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.

Einrichtung von IPv6-Konnektivität direkt auf einem PC

Beitragvon SpaceRat » 14.08.2013, 21:56

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

Die im vorherigen Kapitel beschriebene Lösung hat einen ganz gewaltigen Haken:
Sie funktioniert nur, wenn man uns den Router umkonfigurieren läßt. Bei Verwandten und Bekannten ist es mit Sicherheit die eleganteste Lösung, weil man deren Anschlüsse so auch gleich fit für die Zukunft macht, aber unterwegs in fremden Netzen ist das nicht wirklich praktikabel.
Auch wenn der Router vor Ort noch kein IPv6 kann und/oder keine Tunnel unterstützt, funktioniert das so nicht.

Kommen wir daher zu einer Alternative ...

Einrichtung von IPv6-Konnektivität direkt auf einem PC

Wir können natürlich unseren Tunnel auch direkt auf einem PC aufbauen lassen.
Für den im vorherigen Kapitel im Router verwendeten SixXS-heartbeat-Tunnel bzw. den HE 6in4-Tunnel müßte man dazu allerdings sicherstellen, daß es im Router vor Ort eine Weiterleitungsregel für "protocol-41" auf unseren Rechner gibt.
Viele Router (z.B. Fritz!Boxen) können das gar nicht oder müßten dazu unseren PC zum "exposed host" machen bzw. in die "DMZ" stellen, so daß wir von dieser Möglichkeit lieber Abstand nehmen.

Es bleibt als relativ einfach aufzusetzende und trotzdem zuverlässig laufende Möglichkeit ...

Einrichtung eines SixXS-ayiya-Tunnels

Ein ayiya-Tunnel nutzt UDP für den Aufbau des Tunnels und funktioniert auch durch NAT, ja selbst durch CGN, und ist damit die beste Wahl für den mobilen Einsatz oder den Einsatz hinter einem Router.

  • Abgesehen davon, daß wir in Schritt 2 abweichend von der Anleitung für einen SixXS-Tunnel für eine Fritz!Box einen "ayiya-Tunnel" statt eines heartbeat-Tunnels wählen, sind die Schritte 1-3 identisch, bzw. Schritt 1 entfällt, wenn wir schon ein SixXS-Konto haben.
  • Um den Tunnel auf unserem PC nutzen zu können, brauchen wir noch den "aiccu"-Client, den man sich hier herunterladen kann.
    Unter Windows wählen wir die Windows-Konsolenversion.
  • Die Windows-Version benötigt zusätzlich noch den tun/tap-Treiber aus OpenVPN.
    Um diesen zu installieren, lädt man sich hier die aktuelle OpenVPN-Version herunter (Auf passende Version für 32 Bit bzw. 64 Bit achten) und installiert mit dessen Installer nur den "TAP Virtual Ethernet Adapter", alle anderen Optionen können abgewählt werden.
  • Wir können uns nun ein Verzeichnis für AICCU anlegen,
    z.B. C:\Programme\AICCU,
    in dieses Verzeichnis kopieren wir auch die heruntergeladene Version von aiccu (z.B. aiccu-2012-02-02-windows-console.exe)
  • Im selben Verzeichnis müssen wir nun noch, z.B. mit Notepad, eine Konfigurationsdatei namens "aiccu.conf" anlegen, welche ungefähr folgenden Inhalt haben sollte:
    Code: Alles auswählen
    # AICCU Configuration

    username SRX7-SIXXS
    password Weltraumrattenpasswort
    tunnel_id T123456

    ipv6_interface sixxs
    verbose false
    daemonize true
    automatic true
    requiretls false

    wobei natürlich hinter username, password und tunnel_id die geeigneten eigenen Werte eingetragen werden müssen.
  • Durch Doppelklick auf aiccu-2012-02-02-windows-console.exe wird nun der Tunnel aufgebaut.
  • Fertig.
    Solange die Anwendung aiccu-2012-02-02-windows-console.exe läuft, haben wir IPv6-Konnektivität auf diesem PC.
  • Wird der Tunnel nicht mehr benötigt, kann aiccu durch Drücken von Strg+C beendet werden.

Man kann die Funktion des Tunnels übrigens wunderbar vorab zuhause prüfen, indem man bei den Adaptereinstellungen des PCs (LAN- bzw.- WLAN-Verbindung) die Bindung an "Internet-Protokoll Version 6" entfernt (Der PC hat dann kein IPv6 mehr über das Heimnetz, sondern nur noch das geNATtete CGN ...) und dann aiccu startet.
Wenn der Tunnel so funktioniert, dann funktioniert er auch hinter dem CGN des Mobilfunk-Providers, an einem WLAN-Hotspot, etc. pp.
Benutzeravatar
SpaceRat
Kabelkopfstation
 
Beiträge: 2614
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen

Einrichtung von IPv6-Konnektivität auf einem Android-Smartph

Beitragvon SpaceRat » 14.08.2013, 21:58

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

Mit den Lösungen aus den vorherigen zwei Kapiteln sind wir schon für alle Fälle gut gerüstet, in denen wir mit "eigenen" Computern von außerhalb auf unser Heimnetz und andere IPv6-Seiten zugreifen willen.
Wie aber kommen wir auf unserem Smartphone an IPv6-Unterstützung?

Auch dafür gibt es einen Weg ...

Einrichtung von IPv6-Konnektivität auf einem Android-Smartphone

Für unser Smartphone gelten die selben Aspekte wie sie im vorherigen Kapitel zum Problem mit SixXS-heartbeat-Tunnel bzw. den HE 6in4-Tunneln hinter einem Router gesagt wurden:
Um sicher zu gehen, daß unser Tunnel auch unter widrigen Umständen (Also in einem geNATteten WLAN, im Mobilfunknetz, etc. pp.) funktioniert, benötigen wir einen SixXS-ayiya-Tunnel.

Einrichtung eines SixXS-ayiya-Tunnels

  • Die Schritte 1-3 sind wieder identisch zu denen für einen SixXS-Tunnel im Router oder auf dem PC.
    Wie für unseren PC beantragen wir einen ayiya-Tunnel.
  • Um den Tunnel auf dem Androiden einrichten zu können, muß dieser "gerootet" sein.
    Wie man das macht, werde ich nicht erklären, da es deutlich zu weit führen würde.
    Es ist aber wirklich kein Hexenwerk, inzwischen gibt es genug einfache Möglichkeiten, z.B. hier eine One-Click-Lösung.
  • Wie für den PC auch, benötigen wir aiccu
    Auf Androiden heißt der Client "androiccu" und kann hier im Google Play Store geladen werden.
  • Bei einigen wenigen Android-Geräten fehlt noch der Tunnel-Treiber, den man mit diesem Tool nachinstallieren kann.
    Es schadet nicht, diese App einfach mal zu installieren und auszuführen.
    Wenn wir schon den Tunnel-Treiber haben, wird uns die App das nach Aufruf mitteilen, indem sie in grüner Schrift vermeldet "Tun module is loaded".
    Tut sie das nicht, dann können wir ihn durch Klick auf den Button "Install" nachinstallieren.
  • Nun können wir Androiccu einrichten
    Wenn wir Androiccu zum erste Mal aufrufen, wird uns dieser darauf hinweisen, daß noch nichts installiert wurde:
    Bild
    Durch Antippen der Menü-Taste am Smartphone und Auswahl von "Setup" gelangen wir in den Einrichtungsassistenten.
    In diesem brauchen wir lediglich die Menüpunkte "1. Download", "2. Install" und "3. Configure" von oben nach unten der Reihe nach anzutippen:
    Bild
  • Den Punkt "Configure" kann man später auch jederzeit über "Menü-Taste -> Configure" erreichen.
  • Wie gehabt werden unter "Configure" drei Eingaben erwartet:
    SixXS-Benutzername, SixXS-Kennwort und die Tunnel-ID.
    Die ersten beiden müssen wir eingeben, die letztere können wir sogar einfach aus einem Drop-Down-Menü auswählen.
    Dann noch "Save" antippen, fertig.
  • Zurück auf der Startseite können wir jetzt den Tunnel-Status sehen
    Bild
    Ein grünes Häkchen für "Tunnel läuft" und ein rotes X für "Tunnel läuft nicht".
    Unter dem Status befinden sich dann noch die zwei Buttons "Start" und "Stop", die man wohl kaum erklären muß.
  • Nach dem Start des Tunnels bleibt dieser, dank ayiya, kontinuierlich aufrecht
    Er übersteht Mobilfunkzellen-Wechsel und sogar die Umschaltung zwischen WLAN und Mobilfunk.
  • Et voila:
    Alle IPv6-Tests bestanden:
    Bild
    Sofern man nur 9/10 Tests besteht und der DNS-Test scheitert, benötigt man noch einen DNS-Umschalter, z.B. DNS Changer Root, um andere DNS-Server als die des Mobilfunkanbieters zu nutzen, z.B. die von Google.
Benutzeravatar
SpaceRat
Kabelkopfstation
 
Beiträge: 2614
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen

Tuning: Mehrere DynDNS-Updates mit nur einem Aufruf

Beitragvon SpaceRat » 14.08.2013, 21:59

Tuning: Mehrere DynDNS-Updates mit nur einem Aufruf

Da der nächste Abschnitt eine Endlosgeschichte werden wird, möchte ich an dieser Stelle einschieben, wie man komfortabel mehrere DynDNS-Konten mit nur einem Aufruf aktualisieren kann.
Das macht dann Sinn, wenn wir mehrere solcher Konten über unseren Router aktuell halten wollen, dieser aber nur einen DynDNS-Anbieter bedienen kann.

Mehrere DynDNS-Anbieter wiederum machen vor allem dann Sinn, wenn wir zusätzlich zum eigentlichen DynDNS-Dienst, der uns einen leicht zu merkenden Hostnamen als Ersatz für die dynamische IP verschafft, auch noch andere Funktionen brauchen, die über DynDNS-Update-Mechanismen laufen, aber anderen Zwecken dienen, wie z.B. dem Aktualisieren unseres IPv4-Tunnelendpunktes bei einem 6in4-Tunnel.
Mit nur einem DynDNS-Dienst müßten wir uns ja entscheiden, ob wir unsere DynDNS-Adresse oder unseren Tunnel-Endpunkt aktuell halten wollen, es geht aber eben auch beides (und noch mehr).

DNS-o-matic als Multi-DynDNS-Update-Dienst

DNS-O-Matic an sich ist kein DynDNS-Dienst, sondern aktualisiert seinerseits einfach nur beliebig viele DynDNS-Dienste auf einen Schlag. Besonders interessant ist das dann, wenn man z.B. OpenDNS als DNS-Server nutzen und dabei auch vom angebotenen Web Content Filtering profitieren möchte oder Hurricane Electric als Tunnelbroker nutzt, denn dieser Tunnel muß genau wie ein DynDNS-Dienst über jeden IP-Wechsel informiert werden.
Das kann man zwar über benutzerdefinierte DynDNS-Provider im Router machen, aber eben meistens nur für einen einzigen.

Nutzt man hingegen DNS-o-Matic, dann kann man im Nachgang in den Account-Einstellungen von DNS-o-Matic beliebig viele DynDNS-Dienste und ähnliche Updates eintragen.

DNS-o-Matic aktualisiert z.B. bei mir:
1 Hurricane-Electric Tunnelbroker
1 OpenDNS-Account
1 DynDNS-Account
1 No-IP-Account
1 FreeDNS-Account

  • Um DNS-o-Matic nutzen zu können, muß man sich zuerst einmal dort anmelden.
  • Hat man ein Konto angelegt, können beliebig viele Services zugefügt werden, die durch DNS-o-Matic aktualisiert werden sollen.
    Die Einrichtung der meisten Services ist selbsterklärend.

    Um den IPv4-Tunnelendpunkt eines 6in4-Tunnels bei Hurricane Electric aktuell zu halten,
    • wählt man als Service "Tunnelbroker" (und nicht etwa HE DNS!)
    • Als "User ID" geben wir den Tunnelbroker-"Username" ein
    • Das "Password ist entsprechend das Tunnelbroker-"Password" ein
    • Für "Host/Identifier" verwenden wir die Tunnel-ID, also die Nummer des zu aktualisierenden Tunnels (Zu sehen in den "Tunnel Details")
  • Wenn alle gewünschten Services eingetragen wurden, werden diese jedes Mal alle aktualisiert, sobald bei DNS-o-Matic ein Update angestoßen wird.


DNS-o-matic als benutzerdefinierten DynDNS-Dienst in der Fritz!Box eintragen

  • 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 "Dynamic DNS"
  • Hier "Benutzerdefiniert" auswählen
  • Die einzutragenden Daten lauten dann:
    Code: Alles auswählen
    Update-URL: http://updates.dnsomatic.com/nic/update?hostname=all.dnsomatic.com&wildcard=NOCHG&mx=NOCHG&backmx=NOCHG&myip=<ipaddr>
    Domain-Name: irgendeinen der DynDNS-Hosts, die von DNS-O-Matic aktualisiert werden
    Benutzername: <DNS-O-Matic-Benutzername>
    Kennwort: <DNS-O-Matic-Kennwort>
  • Der Domain-Name ist für das Update gar nicht von Relevanz, da DNS-O-Matic ja alle Einräge aktualisieren soll (hostname=all.dnsomatic.com in der Update-URL), er ist aber für die Fritz!Box wichtig, um den Erfolg des Updates überprüfen zu können (Nach einem erfolgreichen Update löst die Fritz!Box den aktualisieren Domain-Namen auf, um zu überprüfen, daß da auch wirklich die aktuelle IP rauskommt).

DNS-o-matic als DynDNS-Dienst fest in der Fritz!Box eintragen

Eleganter als den benutzerdefinierten Eintrag finde ich es, DNS-o-Matic dauerhaft (Bis zu einem Rücksetzen auf Werkseinstellungen oder Einspielen einer Recovery-Firmware) zu den von der Fritz!Box angebotenen DynDNS-Diensten hinzuzufügen. Das funktioniert sogar mit den Kabel-Modellen 63x0.

  • 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ü "System" und daraus den Unterpunkt "Einstellungen sichern"
  • Im rechten Teil geben wir nun ein Kennwort nach Wahl ein und klicken auf "Sichern"
  • Die Fritz!Box speichert nun alle Einstellungen in eine Datei mit der Erweiterung .export
  • Diese Dari öffnen wir, z.B. mit NotePad
  • Am Anfang der Datei suchen für nach den Zeilen
    Code: Alles auswählen
    Language=de
    **** CFGFILE:ar7.cfg

    und ändern sie zu
    Code: Alles auswählen
    Language=de
    NoChecks=yes
    **** CFGFILE:ar7.cfg

  • Wir suchen den Abschnitt
    Code: Alles auswählen
    ddns {

    und darin die Sektion
    Code: Alles auswählen
            types {


    Dort sollte bisher am Anfang stehen:
    Code: Alles auswählen
            types {
                    type = "dyndns";
                    url = "/nic/update?system=dyndns&hostname=<domain>&myip=<ipaddr>&wildcard=NOCHG";
            } {


    Dies ändern wir zu
    Code: Alles auswählen
            types {
                    type = "dnsomatic";
                    url = "/nic/update?myip=<ipaddr>&hostname=all.dnsomatic.com&wildcard=NOCHG&mx=NOCHG&backmx=NOCHG";
            } {
                    type = "dyndns";
                    url = "/nic/update?system=dyndns&hostname=<domain>&myip=<ipaddr>&wildcard=NOCHG";
            } {

  • Wir suchen die Sektion
    Code: Alles auswählen
            provider {


    Diese sieht bisher in etwa so aus:
    Code: Alles auswählen
            provider {
                    name = "dyndns.org";
                    type = "dyndns";
                    livedelay = 0w;
                    touchtime = 30d;
                    server = "members.dyndns.org";
                    ip6server = "";
                    infourl = "http://www.dyndns.org/";
                    ddnsmode = ddns_both;
            } {

    und wird geändert in
    Code: Alles auswählen
            provider {
                    name = "DNS-o-matic";
                    type = "dnsomatic";
                    livedelay = 0w;
                    touchtime = 30d;
                    server = "updates.dnsomatic.com";
                    ip6server = "";
                    infourl = "http://www.dnsomatic.com";
                    ddnsmode = ddns_v4;
            } {
                    name = "dyndns.org";
                    type = "dyndns";
                    livedelay = 0w;
                    touchtime = 30d;
                    server = "members.dyndns.org";
                    ip6server = "";
                    infourl = "http://www.dyndns.org/";
                    ddnsmode = ddns_both;
            } {

  • Die geänderte .export-Datei können wir jetzt über das Fritz!Box-Menü wieder einlesen.
  • Die Fritz!Box startet daraufhin neu. Wenn alles geklappt hat, kann man danach unter "Dynamic DNS benutzen" auch direkt DNS-O-Matic benutzen und braucht nur noch den dazugehörigen Benutzernamen/Passwort und einen beliebigen von DNS-O-Matic aktualisierten DynDNS-Host einzutragen, aber nie wieder die Update-URL.
  • Wenn es nicht geklappt hat startet die Fritz!Box zwei mal neu und hat einen Werksreset gemacht! Deshalb ist das Backup der Konfigurationsdatei auch so wichtig!


DNS-o-matic als benutzerdefinierten DynDNS-Dienst in einem anderen Router

  • Sofern ein Router benutzerdefinierte DynDNS-Dienste erlaubt, können wir auch DNS-o-Matic als solchen Eintragen
  • Die Daten für DNS-o-Matic lauten:
    Code: Alles auswählen
    Update-URL: http://updates.dnsomatic.com/nic/update?hostname=all.dnsomatic.com&wildcard=NOCHG&mx=NOCHG&backmx=NOCHG&myip=<ipaddr>

    wobei <ipaddr> durch die IP zu ersetzen ist, oder
    Code: Alles auswählen
    Update-URL: http://updates.dnsomatic.com/nic/update?hostname=all.dnsomatic.com&wildcard=NOCHG&mx=NOCHG&backmx=NOCHG

    um DNS-o-Matic die IP automatisch erkennen zu lassen.
  • Wo diese Informationen konkret eingetragen werden müssen und ob sie überhaupt eingetragen werden können, hängt vom verwendeten Gerät ab.
Benutzeravatar
SpaceRat
Kabelkopfstation
 
Beiträge: 2614
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen

Lösung Hindernis 6: Ein Server bzw. Dienst ist nur für IPv4

Beitragvon SpaceRat » 14.08.2013, 22:00

Lösung Hindernis 6: IPv4 vs IPv6: Ein Server bzw. Dienst ist nur für IPv4 programmiert

Wer diesen Workshop bis hierher durchgearbeitet und die Lösungen
  • Die zu erreichenden Server auf den freizugebenden Geräten sind über IPv6 freigegeben
  • Die zu erreichenden Geräte verfügen über leicht zu merkende DynDNS-Hosts statt nur über eine elendig lange IPv6
  • Die zugreifenden Rechner/Netze haben IPv6, ggf. haben wir dazu dort Tunnel installiert
nachvollzogen hat (Sofern mit der verwendeten Hardware möglich :( ), kann zu diesem Zeitpunkt bereits die meisten Serverdienste ganz normal mit IPv6 weiter benutzen.

Dazu gehören z.B. MyFRITZ!, Fritz!Box-Fernwartung, RDP/Windows Remote Desktop und viele mehr.

Bei einem großen Teil dieser Dienste wird es sogar so sein, daß unser Leben durch IPv6 nun einfacher geworden ist:
Ich brauche nicht mehr zu überlegen, ob ich nun lieber dem Receiver im Schlafzimmer oder doch dem im Wohnzimmer oder dem NAS vergönne, sein WebInterface auf dem Standard-Port erreichbar zu haben. Es ist nicht mehr nötig, sich zu merken, daß die Fernsteuerung vom 1. PC über ganzes.heimnetz.org:4899 und die vom 2. PC über ganzes.heimnetz.org:4900 erreichbar ist oder aber der 2. PC durch "proxying" der Anfrage über den 1. PC erreicht wird.
Ich kann über schlafzimmer.heimnetz.org direkt den Receiver im Schlafzimmer, mit wohnzimmer.heimnetz.org den im Wohnzimmer und mittels NAS.heimnetz.org den NAS ansprechen.
Bei meinpc.heimnetz.org reagiert wirklich mein eigener PC und bei goettergattin.heimnetz.org der meiner Frau ...

Leider wird es aber auch einen erklecklichen Teil an Diensten/Servern geben, die trotz aller äußeren Voraussetzungen erst einmal nicht über IPv6 erreichbar sein werden.

Der/die Haken an der ganzen Sache

Viele Entwickler haben Eier wie Medizinbälle und daher in der Vergangenheit immer wieder die Arbeiten an IPv6-Unterstützung für ihren Schrott in die Zukunft verschoben:
TeamSpeak und IPv6? *rschlecken!
Steam und IPv6? Pustekuchen!
Remote Administrator und IPv6? Später.
eMule und IPv6? Braucht kein Mensch.

Wenn man einfach einmal bei Google nach "IPv6 + beliebiges, noch nicht IPv6-taugliches Produkt" sucht, wird man fast immer auf Hersteller-/Support-Foren stoßen, in denen IPv6-Support für die (ferne) Zukunft versprochen wird oder auch nicht und das Problem des knappen IPv4-Adressraumes geleugnet wird. Teilweise nicht nur vor einigen Jahren, sondern sogar noch zu einem Zeitpunkt, zu dem die Adresspools in Asien/Pazifik und Europa bereits erschöpft waren.

Diese Paarung von Arroganz, Ignoranz und blanker Unfähigkeit wirft nun den Endkunden Knüppel zwischen die Beine, denn die müssen das jetzt ausbaden.

Jetzt haben wir, schon mit 2 Jahren Verzögerung gegenüber den Asiaten, tatsächlich auch für stationäre Internetzugänge keine IPv4-Adressen mehr übrig und immer noch wurstelt die Industrie rum und drückt sich vor dem Unausweichlichen.
Die einzig richtige Lösung des Problems ist es, den Firmen ihren Plunder vor die Füsse zu werfen, also entweder Geräte ohne "IPv6" mit dem Vermerk "kaputt" an den Hersteller/Händler zurückschicken und/oder keine Software zu kaufen, die kein IPv6 kann. IPv6 ist seit 1998 standardisiert und sollte IPv4 inzwischen komplett ersetzt haben. Für unsere ganzen Smartphones haben die Netzbetreiber noch nie genug IPs gehabt, weshalb man - IPv6 ist den Hochwohlgeborenen ja zuviel Arbeit - unterwegs auch mit CGN-IPv4-only surft, also nicht einmal DS-lite!

Wie gesagt, das wäre die richtige Lösung. Wenn Microsoft & Co. Zigtausende von XBox 360 & Co. vor der Tür abgekippt bekämen, dann gäbe es mit Sicherheit Updates.
Ich halte das für durchaus erfolgversprechend, denn erstens sind dt. Gerichte sehr verbraucherfreundlich und der Mangel ist problemlos als ursprünglich vorhanden nachzuweisen, so daß die zweijährige gesetzliche Gewährleistung voll greift. Ich würde es mit in den letzten zwei Jahren gekauften Artikeln definitiv so handhaben, vor allem, wenn es IPv6-taugliche Alternativen gibt, z.B. bei Heimautomatisierung, IP-Cams, etc. pp.

Was machen wir aber nun mit Programmen oder Geräten, die wir entweder nicht mehr zurückgeben können oder bei denen wir das nicht wollen?

Workarounds

Für einige Anwendungsfälle, in denen Dienste und Server nicht mit IPv6 nutzbar sind, kann man diese Nutzbarkeit durch kleine Tricks nachrüsten. In den wenigsten Fällen hat die Nichtfunktion irgend etwas mit einer Einschränkung von IPv6 zu tun, sondern sie ist in aller Regel im wahrsten Sinne des Wortes eine Fehlfunktion des verwendeten Gerätes bzw. der Software.
Das bedeutet, daß die Notwendigkeit für solche Verrenkungen durch Fehler im Produkt verursacht ist und wieder entfällt, wenn und sobald die fehlende IPv6-Unterstützung nachgereicht wird. Dies im Gegensatz zu den bisher beschriebenen Maßnahmen zur Portfreigabe und dem Pflegen von DynDNS-Dienste, die wir auch schon bei IPv4 zu erledigen hatten und die auch bei IPv6 weiterhin nötig sein werden, weil sie in der Natur der Kommunikationstechnik liegen.

Dies zu wissen und im Hinterkopf zu behalten ist deshalb wichtig, weil einige der folgenden Workarounds später - wenn echter IPv6-Support in den geflickten Anwendungen zur Verfügung steht - zu Fehlfunktionen führen können und werden und deshalb dann wieder rückgängig gemacht werden müssen.
Benutzeravatar
SpaceRat
Kabelkopfstation
 
Beiträge: 2614
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen

Re: Kleiner TCP/IP-Workshop - IPv6 und IPv4

Beitragvon SpaceRat » 15.08.2013, 01:53

Fortsetzung Lösung Hindernis 6: IPv4 vs IPv6: Ein Server bzw. Dienst ist nur für IPv4 programmiert
Workaround für Enigma2-basierende DVB-S/DVB-C/DVB-T (Sat-/Kabel-/Terrestrisches TV) Receiver

Enigma2-basierende Receiver setzen auf einem Linux-System auf, einem System das prinzipiell mit als erstes IPv6-tauglich war.

Leider ist das alleine noch kein Garant für eine einwandfreie Funktion, wie Enigma2 eindrucksvoll demonstriert:
Von Hause aus funktioniert auf den meisten Enigma2-Receivern fast gar nichts mit IPv6, auf manchen Boxen auch genau gar nichts.

Zum Glück läßt sich das ändern, so daß wir am Ende fast 100%igen IPv6-Support haben.

Prüfung auf IPv6-Support im Kernel

Um überhaupt irgendwie IPv6 mit unserem Enigma2-Receiver nutzen zu können, muß der Linux-Kernel auf der Box mit IPv6-Support gebaut worden sein.
Das läßt sich herausfinden, indem man sich per ssh oder Telnet mit der Box verbindet und folgenden Befehl eingibt:
Code: Alles auswählen
cat /proc/net/if_inet6

Wenn das Resultat so aussieht:
Code: Alles auswählen
cat: can't open '/proc/net/if_inet6': No such file or directory

Fehlt uns jegliche IPv6-Unterstützung im Kernel.
Ggf. hilft uns ein Wechsel auf ein neueres oder anderes "Image", also eine neuere Firmware oder eine andere Variante der Firmware (z.B. HDMU statt OpenAAF).

Es gibt nicht nur genau eine mögliche Firmware, mit der ein bestimmtes Receiver-Modell versehen sein kann, sondern meistens mehrere verschiedene "Images" von verschiedenen Anbietern. Diese unterschiedlichen Images sind mit unterschiedlichen Linux-Distributionen (Ubuntu, SuSE, Red Hat, ...) vergleichbar und jede Variante kann einen unterschiedlichen Grad an IPv6-Funktionalität haben.
Somit läßt sich die Funktionalität oft durch einen Firmware-Wechsel steigern, weshalb ich vorab den Stand bei einigen dieser Firmware aufzeigen werde.

OpenPLi
Aktuelle OpenPLi-Images, also mindestens OpenPLi 3.0 und 4.0, haben im Linux-Kernel IPv6-Support freigeschaltet. Der Zugang auf die Box per SSH klappt daher meistens auch direkt per IPv6. Mehr geht leider ohne Nachhilfe nicht.

VTi Team Image
Ein Image für Boxen des Herstellers Vu+, basierend auf dessen jeweils aktuellem Original-Image. Zumindest die aktuelle Version (6), hat im Linux-Kernel IPv6-Support freigeschaltet. Der Zugang auf die Box per SSH klappt daher meistens auch direkt per IPv6. Mehr geht leider ohne Nachhilfe nicht.

HDMU Image
Das gängigste, wenn nicht gar das einzig in Frage kommende Image für Boxen mit sh4-Architektur (Kathrein, Topfield TF7700 HD PVR, Spark, ...). Aktuelle Versionen (>=11152) haben im Linux-Kernel IPv6-Support freigeschaltet. Ein SSH-Server fehlt hier, aber der Zugang per Telnet funktioniert auch per IPv6 (Sollte aber auf gar keinen Fall im Internet freigegeben/genutzt werden). Mehr geht leider ohne Nachhilfe nicht.

Wie man sieht, ist der IPv6-Support "out of the box" bei allen Boxen/Images eher mau, obwohl die Grundlagen (Ein IPv6 unterstützendes Betriebssystem) zumeist da wären.

Immerhin können wir auf dieser Grundlage aufbauen ...

Web-Interface IPv6-tauglich machen

Weder "OpenWebIf" noch das ältere WebInterface von Dream binden sich an IPv6. Umso erstaunlicher ist es, daß z.B. DreamDroid IPv6 für den Zugriff auf das Web-Interface unterstützt. D.h., wenn wir das Web-Interface der Box zur Zusammenarbeit mit IPv6 überreden, können wir unsere Box daher auch ohne weitere Tricks vom Androiden aus fernsteuern.

Um das Web-Interface (und optional auch ein paar andere Dinge) IPv6-tauglich zu machen, benötigen wir HAproxy. HAproxy ist ein "load-balancing proxy", d.h. eigentlich dafür gedacht, eingehende Anfragen auf mehrere physikalische Server zu verteilen. Wir brauchen diese Funktionalität gar nicht, nutzen aber die Möglichkeit von HAproxy aus, Internet-Traffic über Protokollgrenzen hinweg (Also zwischen IPv4 und IPv6) vermitteln zu können.

Da HAproxy ein Binärprogramm ist, also immer für einen bestimmten Prozessortyp kompiliert wurde, müssen wir erst einmal wissen, auf welcher dieser Architekturen unser Receiver basiert.

Als kleine Hilfe, hier eine Sammlung gängiger Architekturen und von Receivern, die diese nutzen:

  • MIPS
    Alle Vu+ (Ultimo, Uno, Solo, Solo2, Duo, Duo2), alle aktuellen DreamBoxen (7025(+), 800HD, 8000, 500HD, 800HD se, 7020HD), alle aktuellen X-Trend (ET4x00, ET5x00, ET6x00, ET9x00) und viele mehr.
  • sh4
    Topfield 77x0 HD PVR; Kathrein UFS910, UFS912, UFS913, UFS922, UFC960; (fast) alle Golden Media/Spark; ABCom/IP-Box 9000, 900, 910, 91; QBox HD; Octagon SF 918 SE+, SF 908g, SF 918G SE+, SF 1008, 1008 SE+, 1008P SE+, 1008G SE+, 1008G+ SE+, 1008C SE+, SF 1028P
  • ppc
    Alle alten Dreamboxen außer DreamBox 100 (56x0, 7000, 7020, 500(+), 600 PVR)

Die verwendete Architektur kann man auch herausfinden, indem man sich per ssh oder telnet mit dem Receiver verbindet und auf die Ausgabe des Befehls
Code: Alles auswählen
uname -m

guckt.
Die Ausgabe sollte eine Prozessorarchitektur sein, also z.B. "mips", "sh4", ...

Ich habe für Boxen mit MIPS hier und für solche mit sh4 hier fertige Pakete bereitgestellt. Das MIPS-Paket ist getestet mit den Images OpenPLi und VTi, das sh4-Paket mit dem HDMU-Image.

Die Installation ist relativ einfach:
  • Das passende Paket ins Hauptverzeichnis ("/") des Receiver kopieren
  • Per Telnet oder ssh mit dem Receiver verbinden und folgende Befehle eingeben:
    Code: Alles auswählen
    cd /
    tar -xzf haproxy-mips.tgz

    auf einer MIPS-Box
    bzw.
    Code: Alles auswählen
    cd /
    tar -xzf haproxy-sh4.tgz

    auf einer sh4-Box.
  • Receiver neu starten

Die Arbeitsweise des Paketes:
  • Da wir keine aufwendigen Load-Balancing-Konfigurationen o.ä. brauchen, konfiguriert sich der HAproxy vollautomatisch.
  • Das Start-/Stop-Script /etc/init.d/haproxy wertet hierzu die Datei /etc/haproxy/services aus und schreibt eine temporäre haproxy.cfg
  • Die Datei /etc/haproxy/services sieht so aus:
    Code: Alles auswählen
    http;80;;
    https;443;;
    stream;8001;;

    In jeder Zeile steht eine Proxy-Definition:
    Name;Port;Ziel-Host;Ziel-Port
    Leerzeichen sind nicht erlaubt.

    In den meisten Fällen reicht allein der Name und die Port-Angabe. Diese Angaben genügen, um jeweils einen Proxy zu definieren, der per IPv6 auf dem angegebenen Port lauscht und jeglichen eingehenden Traffic über IPv4 an denselben Port weiterleitet. Als IPs für den "Listener" (Das Lauschen) werden einfach alle momentan bekannten IPv6-Adressen verwendet und als IPv4 für die Weiterleitung die private IP des Receivers, also z.B. 192.168.1.17.
    Die erste Zeile würde z.B. zu folgender Konfiguration führen:
    Code: Alles auswählen
    listen http-proxy
       bind 0000:0000:0000:0000:0000:0000:0000:0001:80
       bind fd5b:0db8:0bfa:affe:023e:9eff:fe7d:1234:80
       bind 2001:0470:1f0b:c0c0:023e:9eff:fe7d:1234:80
       server http 192.168.1.17:80


    Vordefiniert sind Proxies für das Web-Interface per http (Port 80), per https (Port 443) und Streaming (Port 8001).
    Weitere Proxies kann man entsprechend in /etc/haproxy/services hinzufügen, z.B. würde die zusätzliche Zeile
    cccam-if;16001;;
    auch noch das CCcam-Web-Interface über IPv6 verfügbar machen (Sofern es auf den Port 16001 konfiguriert ist).

  • Die Einschränkung bei meinem Paket:
    Es stellt nicht fest, wenn sich das IPv6-Präfix ändert, dann müßte der HAproxy nämlich mit veränderter Konfiguration neu gestartet werden. Da ich an meinem Tunnel ein statisches Präfix habe, hat mich das bisher nicht berührt ...
  • Voraussichtliche Fehlfunktion, wenn IPv6 nativ im Web-Interface oder einem anderen Dienst, für den ein Proxy definiert ist, verfügbar wird
    Sobald das Web-Interface von sich aus auch auf IPv6-Verbindungen lauscht, werden entweder das Web-Interface oder haproxy nicht mehr starten.

    Hintergrund ist der, daß es für jeden Port nur einen "Listener" geben kann. Der zuerst gestartete erhält den Port, der zweite bekommt einen Fehler gemeldet.
    HAproxy startet nicht, wenn es auch nur einen einzigen Listener nicht anlegen kann, selbst wenn andere Proxies noch gültig wären.
    Das OpenWebIf bindet sich einfach nicht an die Ports, für die es keinen Listener anlegen kann, da aber in HAproxy alle Ports des WebInterfaces definiert sind, bindet es sich an gar keinen Port mehr.
  • Notwendige Änderungen, wenn IPv6 nativ im Web-Interface oder einem anderen Dienst, für den ein Proxy definiert ist, verfügbar wird

    Löschen der zugehörigen Definitionen aus der Datei /etc/services ; wenn dann keine Services mehr verbleiben, Deinstallation des Paketes.
Benutzeravatar
SpaceRat
Kabelkopfstation
 
Beiträge: 2614
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen

Vorherige

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

Wer ist online?

Mitglieder in diesem Forum: Bing [Bot] und 57 Gäste