AW: IPv6, VPN & ECM-Zeiten
Bei feste-ip.net muss man allerdings eine Mobilfunkrufnummer zur Anmeldung angeben...
Gibt es einen ähnlichen Service ohne derartige Sachen bzw. im EU/US-fernen Ausland...?
Letztlich ist dieser Dienst low-tech und kann auch von jedem selbst betrieben werden, z.B. auf einem anderen Anschluß mit Dual-Stack, einem vServer, o.ä.
Mehr als
Code:
6tunnel <local port> <remote host> [<remote port>]
steckt da nicht hinter.
Beispiel:
Gegeben sei
- ein vServer mit Dual-Stack-Anbindung und der IPv4-Adresse 123.50.100.200 und dem Hostname mein.vserver.net
- ein Home-Server mit IPv6-Anbindung oder DS-lite, dynamischem Präfix (bäh) und der MyFritz!-Adresse
raspberry.abcdefghijklm.myfritz.net
- ein Dienst, nennen wir ihn oscam, der auf dem Homeserver auf Port 10005 lauscht
Führt man nun auf dem vServer
Code:
6tunnel 10005 raspberry.abcdefghijklm.myfritz.net
aus, dann ist der Dienst "oscam" danach
- von Dual-Stack-Clients aus unter mein.vserver.net:10005, 123.50.100.200:10005 oder
raspberry.abcdefghijklm.myfritz.net:10005
- von IPv4-only-Clients aus unter mein.vserver.net:10005 oder 123.50.100.200:10005
- von IPv6-only-Clients aus unter
raspberry.abcdefghijklm.myfritz.net:10005
erreichbar.
Dabei muß der Proxy nicht einmal wirklich auf einem vServer laufen.
Gegeben sei:
- ein Home-Server mit IPv6-Anbindung oder DS-lite, dynamischem Präfix (bäh) und der MyFritz!-Adresse raspberry.abcdefghijklm.myfritz.net
- ein Dienst, nennen wir ihn oscam, der auf dem Homeserver auf Port 10005 lauscht
- ein Client-Rechner in einem fremden Heimnetz (Bei einem Freund, Share-Partner)
- der Client selber ist partout nicht IPv6-tauglich zu machen (z.B. CAM-Modul a la Diablo WiFi)
- das fremde Heimnetz an sich ist aber per Dual-Stack angebunden
- im fremden Heimnetz steht auch ein dauerhaft laufender Rechner/Gerät mit dem Namen durchlaufend.fritz.box, der mit Lunix, Mac OS X oder Windows läuft
In diesem Fall kann der Share-Partner auf dem durchlaufenden Rechner in seinem Netz genauso gut
Code:
6tunnel 10005 raspberry.abcdefghijklm.myfritz.net
bzw. unter Windows
Code:
nt6tunnel 10005 raspberry.abcdefghijklm.myfritz.net
oder unter Windows mit Bordmitteln
Code:
netsh interface portproxy add v4tov6 listenport=10005 raspberry.abcdefghijklm.myfritz.net 10005
ausführen, danach kann der IPv6-untaugliche Client einfach mit
durchlaufend.fritz.box:10005
als Server gefüttert werden und nimmt dann trotzdem (durch den Port-Proxy) Kontakt über IPv6 mit
raspberry.abcdefghijklm.myfritz.net:10005 auf.
Letzteren Trick nutze ich z.B. in meinem eigenen Heimnetz, um vPlug/acamd über IPv6 statt über IPv4 mit meinem oscam Kontakt aufnehmen zu lassen. Tierisch überflüssig, weil ich natürlich den oscam im eigenen Netz auch über IPv4 kontaktieren könnte, aber es sieht halt hübscher aus, wenn im oscam gar keine IPv4-Clients mehr zu sehen sind.
Man kann die Port-Proxies übrigens bis zum Exzess durchspinnen ...
Gegeben seien
- ein IPv6-untauglicher Client in Heimnetz A
- ein IPv6-untauglicher Server in Heimnetz B, innerhalb von Heimnetz B als "box" ansprechbar
- je ein Raspberry Pi je Heimnetz, im jeweiligen Netz als raspberry-A und raspberry-B bekannt und ansprechbar
- Heimnetz A sei per Dual-Stack angebunden, Heimnetz B per DS-lite
Problem(e):
- Da Heimnetz B keine öffentlich erreichbare IPv4-Adresse besitzt kann der Client aus Heimnetz A keine direkte Verbindung mit dem Server in Heimnetz B aufnehmen.
- Weil der Server in Heimnetz B kein IPv6 beherrscht, kann er auch nicht unmittelbar per IPv6 erreichbar gemacht werden
- Selbst wenn der Server über IPv6 erreichbar wäre, könnte ein IPv4-only-Client wie in Heimnetz A immer noch keine Verbindung mit ihm aufnehmen.
Lösung:
Auf
raspberry-A:
Code:
6tunnel 10005 raspberry-B.abcdefghijklm.myfritz.net
Auf
raspberry-B:
Im Client im Heimnetz A wird nun als Server eingestellt:
raspberry-A:10005
Der Client im Heimnetz A verbindet sich über
IPv4 mit dem Port-Proxy auf dem
raspberry-A im selben Heimnetz, dieser leitet per
IPv6 über das Internet weiter an Port 10005 auf dem
raspberry-B im entfernten Netz und dieser verbindet dann schließlich
per IPv4 durch zur Box.
Port-Proxies innerhalb der eh beteiligten Netze fressen dabei - z.B. in Bezug auf die Antwortzeiten - nicht wirklich Brot, so daß diese Lösung auch tatsächlich praktikabel ist.
