Hilfe Verbindungsprobleme mit dyndns

Moin

Folgendes
Ich habe meine Gigblue 800se mal wieder angeschmissen
Jetzt habe ich folgendes Problem .

Wenn ich auf meinen Server connecte über die Server Ip ist alles in Ordnung und funktioniert,möchte ich aber jetzt über eine dyndns connecten ,schreibt er mir Usr/Pw falsch
Das gleiche auch wenn ich über die Ip vom Anbieter ,in meinem Fall Vodafon draufmöchte

Ich habe 2 dyndns ausprobiert beide gleich ,sobald ich wieder die Home Ip angebe connectet er sofort.
Das komische ist ,das andere von ausen auf den Server kommen .
Ich habe Username und pw mal geändert ,das gleiche . Hat hier irgendeiner eine Idee?

Auf dem Server ist die Version

• OSCam: 1.20_svn Build: r11517 Compiler: i686-linux-gnu

Auf dem Client ist die Version

• OSCam: 1.20_svn_cw_64_hardcoded Build: r11518 Compiler: mipsel-dreambox_fpu-linux-gnu-ssl-libusb

Nachtrag

Es liegt nicht an der Box ,auf meiner anderen Box ,ist das gleiche Problem ...

Nun, das ist eines der unzähligen Probleme von IPv4:
Du kriegst von Deinem Anbieter für ein ganzes Netzwerk mit zig Geräten (PC, Smartphones, Receiver, ....) nur eine einzige IPv4-Adresse, obwohl eigentlich jedes Gerät eine eigene IP-Adresse braucht.

Dieses Problem umgeht man durch die Krücke "NAT" (Network Address Translation):
Alle Geräte im Heimnetz erhalten IPv4-Adressen aus einem relativ kleinen Adressbereich, der auch von der ganzen restlichen Welt für diesen Zweck benutzt wird, sogenannte "private IP-Adressen".
"Privat", weil sie nicht durch das Internet geroutet werden können, denn von 10 Nachbarn haben 8 genau denselben Adressbereich in Gebrauch, die anderen 2 einen ähnlichen, je nachdem wie viel Mühe sich jemand beim Einrichten seines Heimnetzes gibt.

Sobald Pakete das Heimnetz verlassen, werden sie auf die eine einzige "richtige" IPv4 umgemappt die Du hast und reingehende Pakete werden an derselben Stelle auf Deine privaten IP-Adressen umgemappt, je nachdem, welches Gerät das Paket angefordert hat (Wenn es ein Antwort-Paket ist) oder welches Gerät es verarbeiten soll (Wenn es ein Zugriff von außen auf einen Server in Deinem Netzwerk ist).

Genau das erledigt Dein Router:
Über Portweiterleitungen hast Du ihm z.B. gesagt "Wenn auf Deiner WAN-Seite (Internet) ein Paket mit Zielport 12000 aufschlägt, dann leite es LAN-seitig an die private IPv4 192.168.0.25 Port 12000 weiter."
Schickt 192.168.0.25 nun ein Paket in die Welt (WAN) hinaus, dann merkt sich der Router das und wenn die Antwort an seiner WAN-Seite wieder ankommt, adressiert er sie wiederum an 192.168.0.25 um.

Geräte innerhalb des Heimnetzes kommunizieren aber eigentlich gar nicht über den Router und auch nicht über Deine öffentliche IPv4-Adresse miteinander, sondern vielmehr direkt (über einen Switch und wenn es nur die Switch-Komponente im Router ist).

Wenn Du nun innerhalb des Heimnetzes als Server-Adresse nicht die private IPv4 aus Deinem Heimnetz verwendest, sondern Deine eine öffentliche (denn die ist es, die hinter dem DynDNS steckt), dann zwingst Du das Paket durch den Router, obwohl es nur geswitched werden müßte.

Für den Router bedeutet das:
Der Router muß erkennen, daß an seiner LAN-Seite ein Paket mit einer Zieladresse des anderen Netzes (WAN/Internet) angekommen ist und diese Ziel-Adresse eigentlich seine eigene in diesem anderen Netzwerk ist. Dann kann er es seinen Portweiterleitungsregeln unterwerfen und statt ins WAN (Wohin es adressiert war) doch wieder - umadressiert - ins LAN zurückschicken.

Prinzipiell ist das wenig clever, weil es nur unnötige Zusatzarbeit für den Router ist. Aus diesem Grunde können viele Router dieses sogenannte "Reverse-NAT" erst gar nicht.

poste mal die Configs vom Server und einem Client Reci,
verwendest du Hostname etc vielleicht?
bevor man anfängt rumzuraten, zeig mal alles bitte

SERVER:
CLIENT

du hast doch am server in der oscam.conf Port 34002 für cccam eingestellt, dann muss im client in der oscam.server auch dieser Port rein (= 34002) und nicht 34005.
Du willst dein client wohl nicht mit sich selbst verbinden.

Port ist von außen erreichbar?

gleiche Node ID bei Server und Client geht auch nicht ....

Sorry hab es geändert
War schon der port 34002 hab mich verklickt

Aber es geht ja mit der Home IP wie man ja in der Log sieht
Eigentlich müsste ich nur wissen , ob es von außen geht,weil der Receiver zum Bekannten kommt und er weiter weg wohnt ,bin mir unsicher.
Von aussen ist der port erreichbar ,sind ja auch andere connectet

lösche doch mal beim Client den CCcam Abschnitt und starte mal neu....

m2k schrieb:

Aber es geht ja mit der Home IP wie man ja in der Log sieht
Eigentlich müsste ich nur wissen , ob es von außen geht,weil der Receiver zum Bekannten kommt und er weiter weg wohnt ,bin mir unsicher.
Von aussen ist der port erreichbar ,sind ja auch andere connectet :smile:

Zum Vergrößern anklicken....

Wenn
- andere User - denen Du denselben DynDNS eingetragen hast - per IPv4 verbunden sind
und
- es bei lokalen Tests mit der privaten IPv4 funktioniert
und
- Du rechtzeitig vor der Weitergabe des guten Stücks die private IPv4 durch den den im ersten Punkt genannten DynDNS ersetzt,
dann kann er sich auch verbinden.

Soviel Vertrauen muß man einfach haben.

Wie gesagt, Deinen eigenen DynDNS kannst Du aus dem eigenen Netzwerk genauso wenig testen wie ein VPN aus dem eigenen Netzwerk zum eigenen Netzwerk:
Selbst wenn Dein Router Reverse-NAT beherrschen würde, durchliefen die Pakete den Router immer noch anders, als wenn die Pakete wirklich aus dem WAN kämen.

dodo83 schrieb:

lösche doch mal beim Client den CCcam Abschnitt und starte mal neu....

Zum Vergrößern anklicken....

Geht auch nicht

@
Schimmelreiter

Danke fuer deine ausführliche Beschreibung

Also wenn es ja von außen geht,soll es mir ja Recht sein , jetzt bleibt noch die Frage ,warum connectet er ,und sagt dann User/ PW falsch :=)

Naja wenn es ja halt nicht geht so ,dann ist das so :=)

Vielen Dank an euch da oben

Schimmelreiter schrieb:

Wie gesagt, Deinen eigenen DynDNS kannst Du aus dem eigenen Netzwerk genauso wenig testen

Zum Vergrößern anklicken....

ein nslookup sollte schon möglich sein und die aktuelle öffentliche IP bringen (und es gibt auch Router die die eigene Dyndns unterstützen - geht hier Problemlos :smirk: )
wenn dem nicht so ist, dann sollte kein connect stehen und wo nichts ist kann auch kein User/Passwort falsch sein

m2k schrieb:

Das komische ist ,das andere von ausen auf den Server kommen .

Zum Vergrößern anklicken....

Konfiguriere den GigaBlue 800 SE wie alle anderen Receiver und gut ist es. Wo ist das Problem? Wenn es nicht funktioniert, liegt es am Internet-Anschluss und der Konfiguration vom Router beim „Bekannten“, wo der GigaBlue benutzt werden soll.

Kind regards schrieb:

(und es gibt auch Router die die eigene Dyndns unterstützen - geht hier Problemlos :smirk: )

Zum Vergrößern anklicken....

Ja, gibt es.
Trotzdem durchlaufen diese Pakete den Router dann immer noch anders (LAN->LAN), als wenn sie wie später wirklich von außen kommen (WAN->LAN).

Das extremste Beispiel für "lokaler Test funktioniert und extern geht gar nichts" wäre CGN (Carrier-Grade-NAT):
Die Fratz!Büchsen haben oder hatten zumindest kein Problem damit, DynDNS-Hosts mit IPv4-Adressen aus dem CGN-Bereich 100.64.0.0/10 (Wie man ihn z.B. bei Glasfaser Deutschland hat) zu aktualisieren.
Diese Situation kann einen als Anfänger schon richtig verwirren:
Mit einem Router, der Reverse-NAT kann, funktioniert der Test dann aus dem Heimnetz problemlos, auch von Anschlüssen bei Bekannten, Freunden und Familie geht es wunderbar, wenn diese auch bei Glasfaser Deutschland sind, aber von außerhalb (Anderer Anbieter) geht es nicht.

Kind regards schrieb:

wenn dem nicht so ist, dann sollte kein connect stehen und wo nichts ist kann auch kein User/Passwort falsch sein

Zum Vergrößern anklicken....

Wer weiß, wo der Router diese Anfragen hin leitet.
Hinter der Vodafone-Station steckt meines Wissens auch wieder ein TechniColor-Gerät und diese Geräte sind eigentlich bekannt dafür, sehr wenig von dem zu können, was "wir" von einer Fratz!Büchse gewohnt sind.
Bei den bisherigen Geräten war ja selbst ein DNS-Proxy und lokale Namensauflösung schon Utopie.

Schimmelreiter schrieb:

Diese Situation kann einen als Anfänger schon richtig verwirren:

Zum Vergrößern anklicken....

also halten wir Fest, eigenen DynDNS sollte man nicht in seinem HOME-Network verwenden
ein nslookup auf die eigene DynDNS sollte die aktuelle eigene öffentliche IP bringen
Deutsche Glasfaser ( IPV6) lassen wir jetzt mal weg :grinning: