Laberthread zu Anleitung IPv6 und Cardsharing

[Osprey]

AW: Laberthread zu Anleitung IPv6 und Cardsharing

Wenn die Hardware aber kein ipv6 kann, dann musst du ja zwangsläufig etweder neue Hardware kaufen oder dich mit ipv4 verbinden.

 

[darky]

AW: Laberthread zu Anleitung IPv6 und Cardsharing

Daher ja die Frage, ob ein portproxy serverseitig funktioniert. :emoticon-0138-think

 

[Osprey]

AW: Laberthread zu Anleitung IPv6 und Cardsharing

evtl. sowas? :

Sie müssen registriert sein, um Links zu sehen.

 

[darky]

AW: Laberthread zu Anleitung IPv6 und Cardsharing

Wenn es serverseitig nicht irgendwie geht (per Portproxy oder so), scheint das wohl die einzige Möglichkeit, nicht IPv6-fähigen Clients eine IPv6-Adresse zuzuweisen. Aber da dann eh IPv4 und IPv6 dual laufen (zumindest intern im LAN), macht das keinen Sinn. Hätte mich trotzdem interessiert, ob es auch anders geht.

EDIT: Das Ding ist doch nichts anderes als ein rpi, also muss es ja auch eine Möglichkeit geben, dass der rpi, der auch als Server fungiert, dem nicht IPv6-fähigen Client eine IPv6-Adresse zuweist.

 

[Schimmelreiter]

AW: Laberthread zu Anleitung IPv6 und Cardsharing

Ich kann ja nun nicht direkt auf Clientseite einen portproxy einrichten (oder doch, wenn ja wie?),

Hast Du sogar schon gemacht ...

Dein

netsh interface portproxy add v4tov6 listenport=12345 meinserver.dyn.dns 12345

war ja genau das ... ein client-seitiger Port-Proxy ...

Der funktioniert ja genauso, wenn das Ziel im selben LAN liegt ... IPv6 hebt die nur durch NAT und private IPv4-Adressen künstlich entstandene Trennung von LAN-Adressen einerseits und WAN-Adressen andererseits auf.

Auf einem Linux würdest Du natürlich 6tunnel o.ä. nutzen:

6tunnel 12345 meinserver.dyn.dns 12345

... hätte denselben Effekt wie obiges netsh portproxy ...

Voraussetzung ist natürlich, daß es auch irgendeine Form von Shell-Zugriff auf dem Client gibt.
Auf einem Diablo geht's also nicht grad, aber z.B. auf einer an sich IPv6-fähigen Box, die aber partout weiterhin CCcam nutzen soll, ginge es (Wenn Du 6tunnel für mips hast).

der das auf IPv6 umwandelt. Kann ich jedoch einen portproxy auf dem raspberry einstellen (d.h. serverseitig), der mir dann die Anfragen für den Client auf IPv6 umwandelt? Oder wie funktioniert das?

Auch das ginge.
Wo der Port-Proxy steht, ist ja erst einmal zweitrangig, solange der Client ihn technisch erreichen kann und der Port-Proxy den Server technisch erreichen kann.

Wenn Du z.B. auf dem oscam-Server

6tunnel 22345 ::1 12345

(Selber Port geht in diesem Fall nicht, da der Port 12345 ja bereits von oscam belegt ist) starten würdest, dann würden alle IPv4-Clients die sich mit dem (IPv4-)Port 22345 des Servers verbinden auf dem IPv6-Port 12345 des selben Servers und damit im oscam auskommen.

Das ist aber wirklich eine ziemlich akademische Betrachtung, denn wenn der Client sich bis zum Server nur mit IPv4 verbinden kann, dann ist der Port-Proxy ja wirklich nur noch was für's Auge.

Es birgt auch ein Sicherheitsrisiko:
Verbindungen "von lokal" werden von vielen Servern anders behandelt als von extern eingehende (z.B. entfällt dann teilweise der Passwort-Schutz).

Beim client-seitigen Port-Proxy siehst Du auf dem Server wenigstens die tatsächliche Client-IP(v6) und wenn Du es hinkriegst, daß jeder Client sich - ob direkt oder via eigenem Port-Proxy - per IPv6 mit dem Server verbindet, kannst Du z.B. die IPv4-Portweiterleitung löschen, so daß Verbindungen wirklich nur noch per IPv6 möglich sind.
Aber eine IPv4-Verbindung bis zum Server dann auf diesem doch noch umzumappen macht nicht wirklich Sinn ...

 

[darky]

AW: Laberthread zu Anleitung IPv6 und Cardsharing

Voraussetzung ist natürlich, daß es auch irgendeine Form von Shell-Zugriff auf dem Client gibt.

Das ist natürlich der Knackpunkt, wenn es clientseitig nicht geht.

Auch das ginge.
Wo der Port-Proxy steht, ist ja erst einmal zweitrangig, solange der Client ihn technisch erreichen kann und der Port-Proxy den Server technisch erreichen kann.

Wenn Du z.B. auf dem oscam-Server

6tunnel 22345 ::1 12345

(Selber Port geht in diesem Fall nicht, da der Port 12345 ja bereits von oscam belegt ist) starten würdest, dann würden alle IPv4-Clients die sich mit dem (IPv4-)Port 22345 des Servers verbinden auf dem IPv6-Port 12345 des selben Servers und damit im oscam auskommen.

Interessant, zumindest würde es funktionieren. Wofür steht das "::1"? Ist das localhost nach IPv6-Definition?

EDIT:

Sie müssen registriert sein, um Links zu sehen.

.

 

[Schimmelreiter]

AW: Laberthread zu Anleitung IPv6 und Cardsharing

Der Hauptzweck eines Port-Proxies ist ja, eine IPv4-only-Teilstrecke (oder eine IPv6-only-Teilstrecke, wobei das in 2015 eigentlich kein Problem mehr sein darf) zu überwinden.
- = IPv4
= = IPv6
≡ = Dual-Stack

Dabei macht es keinen Unterschied, wo auf dem Dual-Stack-Abschnitt der Port-Proxy sitzt:

• Client -Port-Proxy≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡ Server
  Das wäre das Schema für Deinen acamd oder einen anderen IPv4-only-Client in einem Dual-Stack-Client-LAN:
  Der Client selber, also acamd, ist IPv4-only, aber Du mappst die IPv4-Anfrage schon auf demselben Rechner (oder auf einem anderen Gerät im Client-LAN) auf IPv6
  
  Der Port-Proxy ist so wie abgebildet nicht wirklich nötig, sondern nur was für's Auge.
  
  Bei nur per IPv6 erreichbaren Servern wäre er aber eine Alternative zum Port-Proxy im Internet und hätte den Vorteil, daß man auf dem Server eine echte Client-IPv6 sieht und nicht die des Port-Proxy im Internet (Die für alle Clients dieselbe ist).
• Client -≡≡≡≡≡≡≡≡≡≡≡≡≡Port-Proxy≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡ Server
  Das wäre das Schema für einen Port-Proxy im Internet:
  IPv4-only-Clients greifen auf den Port-Proxy per IPv4 zu (ungeachtet der Verfügbarkeit von IPv6 bereits ab Client-Netzwerk) und der Port-Proxy leitet per IPv6 zum Server weiter (ungeachtet der Verfügbarkeit von IPv4 bis zum Server)
  
  So wie abgebildet ist auch dieser Port-Proxy nicht wirklich nötig, sondern nur was für's Auge.
  
  Das ist der gängigste Standort für den Proxy, weil er eben auch in dieser Situation funktioniert:
  Client -≡≡≡≡≡≡≡≡≡≡≡≡≡Port-Proxy≡≡≡≡≡≡≡≡≡≡≡≡≡=≡ Server
  In diesem Fall ist der Server nur per IPv6 von außen erreichbar, es muß also jemand (Der Port-Proxy) die Anfragen auf IPv6 mappen, damit sie bis zum Server gelangen können.
• Client -≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡Port-Proxy Server
  Das wäre das Schema für einen Port-Proxy im Zielnetz:
  IPv4-only-Clients greifen auf den Port-Proxy per IPv4 zu (ungeachtet der Verfügbarkeit von IPv6 bereits ab Client-Netzwerk) und der Port-Proxy leitet per IPv6 zum Server weiter (ungeachtet der Verfügbarkeit von IPv4 bis zum Server)
  Macht eigentlich nur Sinn, wenn der Server an sich kein IPv6 kann, z.B. CCcam.

 

[darky]

AW: Laberthread zu Anleitung IPv6 und Cardsharing

Auf einem Linux würdest Du natürlich 6tunnel o.ä. nutzen:

[/COLOR][COLOR=#333333]6tunnel 12345 meinserver.dyn.dns 12345[/COLOR][COLOR=#333333]

Muss ich das auch bei jedem Start des Linux-Receivers machen oder wie macht man das beim Booten/Starten unter Linux, dass automatisch der tunnel verwendet wird?

Und wie kann man den tunnel wieder entfernen?

 

[Schimmelreiter]

AW: Laberthread zu Anleitung IPv6 und Cardsharing

Muss ich das auch bei jedem Start des Linux-Receivers machen oder wie macht man das beim Booten/Starten unter Linux, dass automatisch der tunnel verwendet wird?

Du kannst den Aufruf von 6tunnel auch in der /etc/rc.local eintragen (Hat unter Linux in etwa die Bedeutung wie weiland unter DOS die AUTOEXEC.BAT).

Dann aber bitte die Zeile mit einem "&" beenden, sonst bleibt die Abarbeitung der rc.local an dieser Stelle stehen:

6tunnel 12345 meinserver.dyn.dns 12345 &

Und wie kann man den tunnel wieder entfernen?

In der rc.local auskommentieren (Mit einem "#") oder entfernen und neu starten oder den 6tunnel-Prozess abschießen (kill/killall).