Socket Applet Client bekommt keine GLOBALE Verbindung zum Server

[Stevo]

Hallo Leute,
ich schreibe eine einfach Chat Anwendung. Der Server läuft als Standalone Server auf meinem Rechner.
Als Client wird ein Applet verwendet. Testumgebung ist Firefox 13.0.1.

Wenn ich dem Client mitteile er soll sich über eine lokale Netzwerk-IP mit dem Server verbinden funktioniert alles super (ZB. 192.168.2.106 = ServerIP). Auch mit einem zweiten Rechner funktionierts im LAN.

Das Problem: Wenn ich meine globale IP verwende, erreicht der Client den Server nicht. Es wird allerdings von der Connect Klasse auch kein Fehler ausgegeben. Die globale IP hab ich vorher mit einer der bekannten "Wie ist meine IP" Webseite ermittelt. Das ist doch auch wirklich meine IP, oder?

Die Windows-Firewall ist bereits ausgeschalten. Als Server Port verwende ich 5433. Könnte der Router hier eine Verbindung verhindern?

Mein ISP ist die Telekom. Als Dienst nutze ich DSL 6000. Sind die IPs vielleicht irgendwie so geschared, das man von außen nicht an den Rechner rankommt? Kann ich mir eigentlich nicht vorstellen.

Nachtrag:
Ich verwende diese Funktion um eine Verbindung zum Server über Socket herzustellen:

Socket s = new Socket( ServerIP, _PortID);

 

[Bizzi]

Das Problem: Wenn ich meine globale IP verwende, erreicht der Client den Server nicht.

Was bezeichnest du als "Globale IP"?
Meinst du eine Statische-IP Adresse?
Vielleicht solltest du die jeweiligen Ports für Ein- & Ausgang freischalten.

Es wird allerdings von der Connect Klasse auch kein Fehler ausgegeben.

Dann nutz Try/Catch-Blöcke??

Die globale IP hab ich vorher mit einer der bekannten "Wie ist meine IP" Webseite ermittelt. Das ist doch auch wirklich meine IP, oder?

OK, das meinst du nun als "Globale IP".

Nutze DynDNS um dein Rechner online verfügbar zu machen!

 

[PortForwarding]

Ich würde mal behaupten das dein in deinem Router der entsprechende Port nicht an den Rechner gelinkt wurde. Das was du suchst nennt sich Port-Forwarding.

Wir hatten das Thema erst und ich fand dort folgende Erklärung recht "einsteigerfreundlich" :

*sinngemäßes Zitat* : Wenn du auf deinem Rechner einen ServerSocket erstellst und diesen auf einem bestimmten Port laufen lässt dann ist dieser Port erstmal nur auf deinem Rechner "offen". Dein Router weis davon aber nichts. Also ist bei ihm der Port nach außenhin "zu". Um nun den Router anzuweisen den gewünschten Port von außen an deinen Rechner innen weiterzuleiten musst du ihm das erst sagen. Das geht am einfachsten über "Port-Forwarding" oder auch "Port-Weiterleitung" genannt, oder aber auch teils über UPnP und andere Schnittstellen. *Zitat ende*

Es reicht also nicht wenn du nur einen ServerSocket auf machst. Du musst dann auch allen geräten zwischen deinem Modem und dem Rechner (meist NAT-Router) genau das eben mitteilen das der entsprechende Port an das gewünschte Ziel weiterzuleiten ist (bei mehreren hintereinander geschalteten Routern halt ne Chain bilden).

DynDNS muss man jetzt nicht unbedingt verwenden, kann man aber da man so einen festen Host-NAMEN verwenden kann. Der DynDNS-Provider kümmert sich dann um dessen Auflösung.
Da du aber von einem Applet sprichst solltest du hier zur Bestimmung des Hosts grundsätzlich [c]this.getCodeBase().getHost();[/c] verwenden. Setzt natürlich vorraus dass das Applet auch richtig via HTTP geladen wurde (was einen HTTP-Server wie Apache vorraussetzt).

 

[Stevo]

Ja, ich verwende try- catch Blöcke. Anders würde sich der Code gar nicht kompilieren lassen.
Das Applet ist außerdem signiert.
Es wird, eingebunden in eine Test-HTML-Seite von der URL Hallo Welt heruntergeladen.

Dabei handelt es sich übrigens um einen anderen Server als den, zu dem das Applet Kontakt aufnehmen möchte. Könnte das das Problem sein?
Warum funktioniert es dann aber mit der lokalen Netzwerk-IP Adresse?

Ich habe es jetzt geschafft, das mir eine Fehlermeldung angezeigt wird.
error: connection refused.
Die Verbindung wurde also aus irgendeinem Grund zurückgewiesen.

Gibts denn Tools die einem da bei der Fehlersuche noch helfen könnten? Port-Test oder ähnliches?

Es muss einen Fehler beim Zugriff von außen geben. Die Windows Firewall hatte ich testweise komplett deaktiviert. In meinem Speedport-Router wird der Port an meinen Rechner weitergeleitet. Der Forward ist also eingerichtet.
Die globale IP-Adresse habe ich jetzt im Router nochmal überprüft. Die stimmt ebenfalls. Kanns mir einfach nicht erklären..

 

[PortForwarding]

Schonmal gleich der total falsche Ansatz : "Applet baut zu einem anderen Server eine Verbindung auf als von dem es geladen wurde" : AUTSCH !

Wenn es dir NICHT Möglich ist den Chat-Server auf dem selben Host laufen zu lassen wie den Webspace von dem das Applet geladen wird, dann lassen den Webspace auf dem Host laufen auf dem der Chat-Server läuft. Alles andere ist totaler Käse und braucht eine Signierung des Applets. Und da nun mal ein signiertes Applet "alles" auf dem Client-PC machen kann wird niemand für einen simplen Chat dies zulassen.

Ergo : schon mal total falsches Grundkonzept -> wirf den Code weg und fang noch mal in der Design- und Konzept-Phase neu an, weil das was du hier willst endet nur in einer Katastrophe und kostet dich mehr "Umbauzeit" als noch mal von "null" neu zu beginnen.

Mehr sag ich dazu nicht weil ich auch gar nicht weiter gelesen habe.

 

[Stevo]

Alles andere ist totaler Käse und braucht eine Signierung des Applets.
[...]
Mehr sag ich dazu nicht weil ich auch gar nicht weiter gelesen habe.

Du hättest aber weiter lesen sollen.
Wie gesagt - das Applet ist signiert. Sonst würde es gar nicht funktionieren!
Denn ein unsigniertes Applet kann sich nur mit dem Server verbinden, von dem die Webseite geladen wurde! Und der steht in der Testumgebung auch nicht in meinem lokalen Netzwerk.

Außerdem wird das ganze in ein bestehendes Projekt eingebunden. Das heißt der Webspace ist vorgegeben, und die Anwendung soll darin integriert werden.

Dieser erste kleine Chat ist eine Versuchsumgebung. Das fertige Programm wird ein gutes Stück Ressourcen-Intensiver. Deswegen wird es verteilte Server geben, welche die User je nach Bedarf einrichten können.

 

[PortForwarding]

Hmm -.-' ...
Erlich ... die Info hättest du dir sparen können. Denkst du wirklich ich hätte Applet-Signierung erwähnt wenn ich nicht wüsste das es eben notwendig ist damit ein Applet eine Verbindung zu einem anderen Server aufbauen kann als von dem es geladen wurde ? Naja ... dazu mal kein weiteren Kommentar.


Und wenn du Load-Balancing implementieren willst mach das nicht mit solchen "dreckingen Hacks". Machs anständig mit DNS-Load-Balancing und Host-Names. Oder nimm einen dedizierten Server der nur für den "Chat" ausgelegt ist und die Resourcen hat. Aber nur um halt auf ein paar andere Server zu connecten ein Applet signieren, nur für einen Chat mit Load-Balancing oder was auch immer du da umsetzen willst, das ist 1) totaler Overkill 2) totaler Schwachwinn 3) wird niemand so einfach irgendeinem Zertifikat vertrauen wenn es die Möglichkeit bietet Schadsoftware auszuführen (ein entsprechender Hinweis wird ja in der Meldung auch gegeben).

Außerdem gibt es dafür bereits Techniken die sich durchgesetzt haben. Ich denke da mal ganz spontan an IRC. Auch wenn natürlich ein IRC-Client-Applet eine Signierung bräuchte um sich an andere Server zu verbinden könnte man dem mit DNS-Load-Balancing vorgreifen in dem dann das Applet gleich vom entsprechenden Server geladen wird und somit halt Rechte hat sich zu diesem zu verbinden.

Konzept 6, setzen.

 

[Stevo]

Nein - es geht dabei nicht um Load Balancing. Die Server Anwendung ist konfigurierbar- das bedeutet das dann einfach verschiedene Instanzen des Servers laufen. Den Usern wird auf der Webseite eine Lobby geboten. Sie können sich zu einem bestehenden Client verbinden, oder aber einen eigenen Server starten.
Natürlich könnte ich das ganze auch als herkömmliche Desktop Anwendung schreiben, aber ich möchte für Comfort sorgen.

Eine Umsetzung mit einem Dedicated Server ist mir zu kostenintensiv. Html 5 und JavaScript sind leider noch nicht so weit um solche Echtzeitanwendungen umzusetzen. Sonst hätte ich auf WebSockets gesetzt. Würde aber auch eine Manipulation des Webservers voraussetzen. Und das ist derzeit einfach nicht drin..

Ich werde wohl mal zum Testen den Client in ActionScript schreiben. Keine Ahnung ob bei Flash auch Warnmeldungen ausgegeben werden. Wenn nicht, werde ich einfach die Plattform wechseln.

Versteh mich nicht falsch. Aber ich habe das Gefühl du denkst zu sehr in starren Strukturen. Gerade Entwicklung fürs Web bedeutet immer wieder neue Wege gehen. Und das finde ich auch gut so. Wenn keiner den Mut dazu hätte, würden wir noch in Höhlen wohnen.

 

[Stevo]

Ich habe mittlerweile auch Dyndns eingerichtet. Das Problem ist noch immer das selbe.

Um Fehler im Client auszuschließen teste ich jetzt mit Telnet. Auch hier das selbe Problem. Verbindungen im lokalen Netzwerk sind möglich. Verbindungen von aussen nicht. Das macht mich echt verrückt.. :\

Vielleicht hilft auch noch diese Information.
Java startet den Server mit diesen Einstellungen:

ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=5433]

Nachtrag: Über nslookup wurde mir zur Domain (die ich bei no-ip angelegt habe) die korrekte ip ausgegeben.

 

[Stevo]

Und jetzt noch etwas sehr verdächtiges:

Ich habe das ganze mal über Open Port Check Tool getestet. Damit kann man prüfen ob Ports geöffnet sind. Und tatsächlich ist eine erfolgreiche Verbindung zustande gekommen.


Your IP: 79.211.227.95
What Port?
Success: I can see your service on 79.211.227.95 on port (5433)
Your ISP is not blocking port 5433

Auch auf dem Server hatte ich eine erfolgreiche Ausgabe. Es funktioniert also. Nur Rechner die hinter meinem Router liegen schaffen es scheinbar nicht, auf den Server zuzugreifen.

 

[PortForwarding]

Gut, dann drück ich das ganze mal so aus :

Ohne Code und genaue Fehlermeldungen kann dir nicht wirklich helfen. Das wird hier leider alles nur rätzelraten und was genau du eigentlich so wirklich willst hat immer noch keiner verstanden.

Das einzige was ich bis jetzt mitbekommen habe ist das es eine relativ große/umfangreiche Chat-Anwendung werden soll die als Client ein Applet nutzt und sich zu verschiedenen Servern verbinden kann.

Und das gibt es schon : nennt sich IRC und der dazu passende Applet-Client pjirc.

Ansonsten rall ich grad irgendwie echt nicht was du überhaupt machen willst und wo dabei deine Probleme sind.

Vielleicht solltest du noch mal in der FAQ nachlesen : Wie man Fragen richtig stellt.

 

[Stevo]

Ist doch okay wenn du mir nicht helfen kannst. Verlangt ja auch keiner das DU das jetzt machen musst. Ich bin trotzdem dankbar für jede Anregung.

Ich hab schonmal gesagt -> das ist eine Testumgebung. Deswegen auch erstmal nur ein Chat. Später werden darauf verschiedene Projekte aufsetzen. Ich muss hier nur erstmal die Grundlagen zusammenbekommen.

Das Problem konnte ich so weit eingrenzen:

1. Der Server funktioniert
2. Aus dem Lan kann ich über die Lan-interne IP zum Server verbinden. Sowohl mit meiner Client Anwendung als auch mit Telnet.
3. Aus dem Wan (hier- Internet) kann ich ebenfalls Verbindung zum Server aufnehmen - über die WAN IP. Habe es mit einem Bekannten getestet, der sich jetzt mal von sich zu Hause aus eingeloggt hat. Der sitzt also hinter einem anderen Router - nicht in meinem Heimnetzwerk.

4. Jetzt kommts aber:
Aus dem Lan kann ich mich nicht über die WAN-IP mit dem Server verbinden. Wieso wird die Verbindung an dieser Stelle blockiert?

Das erscheint mir vollkommen rätselhaft. Selbst nach Verwendung von DynDNS.

Ich kann dieses eigenartige Verhalten einfach nicht nachvollziehen.

Die genauen Fehlermeldungen:
Java meldet: Connection refused: connect
telnet meldet: Es konnte keine Verbindung mit dem Host hergestellt werden, auf Port 5433: Verbindungsfehler

 

[HoaX]

Das ist ganz normales, zu erwartendes Verhalten.
Dein Portforwarding sagt dass Verbindungen _aus dem Internet_ auf deine interne IP weitergeleitet werden. Wenn du aber versuchst aus dem internen Netz auf die externe IP zu verbinden, dann landest du im Routing trotzdem/korrekt im internen Netz -> deine Weiterleitung trifft nicht zu.

 

[Stevo]

Okay. Sieht so aus als würde es wirklich daran liegen. Und damit teilweise am Router.

Es gibt eine Einstellung die sich NAT Reflection nennt. Ob man sowas bei dem billigen Telekom Router allerdings konfiguriert bekommt.. :\

Genaueres kann ich erst sagen wenn ich ein anderes Gerät habe..

 

[PortForwarding]

Hmm, damit hatte ich noch nie Probleme. Habe einen D-Link DIR100 und wenn ich von "innen" meine DynDNS verwende kann ich mich korrekt verbinden und die Server-Anwendung gibt mir dann auch als Remote-IP meine WAN-IP, obwohl ich ja eigentlich bereits von "innen" komme. Weis nicht ob es an diesen Telekom-Schrottteilen liegt, aber selbst wenn kann man die glaub alle auf "als Modem" einstellen und dann halt einen ganz normalen D-Link oder Netgear Router dahinter setzen. Gleiches gilt übrigens auch für alle FrizBox. Die haben i-wie die selbe Macke.

Das einzige was ich als kleines Problemchen anzumerken hätte am DIR100 wäre das wenn ich versuche von innen UDP HolePunching "mit mir selbst" zu machen der Router das nicht will. Von externer Quelle funktioniert es aber.

 

[Poltergeist]

Stevo,
du verwechselst dein internal LAN IP mit einem external IP .
192.168.2.106 = ServerIP sagt mir, dass diese IP eine internal IP ist und nur bekannt innerhalb deinem LAN (local).
External IP ist die IP, die von deinem Internet Provider vergeben wurde. Wenn du surfst What Is My IP Address? Lookup IP, Hide IP, Change IP, Trace IP and more... wirst du sehen, welche external IP du hast. External IP kann statisch oder dynamisch sein. Statisch ist eine feste IP, dynamische IP bekommt man immer wenn man sie von seinem provider nicht explizit verlangt.
Also in kurz: Server mit internal IP soll man NICHT explizit nutzen, sondern entweder localhost oder 127.0.0.1 somit kann ein Internet Client via the external IP zugreifen.

 

[HoaX]

Stevo,
du verwechselst dein internal LAN IP mit einem external IP .
192.168.2.106 = ServerIP sagt mir, dass diese IP eine internal IP ist und nur bekannt innerhalb deinem LAN (local).
External IP ist die IP, die von deinem Internet Provider vergeben wurde. Wenn du surfst What Is My IP Address? Lookup IP, Hide IP, Change IP, Trace IP and more... wirst du sehen, welche external IP du hast. External IP kann statisch oder dynamisch sein. Statisch ist eine feste IP, dynamische IP bekommt man immer wenn man sie von seinem provider nicht explizit verlangt.

Darum gehts doch garnicht, seine Konfiguration passt prinzipiell.

Also in kurz: Server mit internal IP soll man NICHT explizit nutzen, sondern entweder localhost oder 127.0.0.1 somit kann ein Internet Client via the external IP zugreifen.

Die Aussage stimmt hinten und vorne nicht. Probier am Besten mal aus was du da erzählst

 

[Stevo]

Danke Hoax. Was Poltergeist da schreibt stimmt tatsächlich nicht.

Die Grundlagen von Netzwerken versteh ich ohne Probleme. Es lag hier wirklich an der Einstellung meines billigen Routers, den ich von meinem Provider bekommen habe. Mit NAT Reflection lässt sich das Problem lösen.
Der Zweitrechner - mit dem ich die Verbindung im Lan getestet habe, kann nicht localhost oder 127.0.0.1 verwenden. Denn das ist die "interne" IP des eigenen Rechners. Er muss schon mindestens die LAN-IP verwenden.

Der externe Zugriff stellte von Anfang an kein Problem dar. Das ist mir allerdings erst im Verlauf des Testens aufgefallen. (Bekommt man mit wenn man dem Verlauf des Threads folgt.)

Ich habe in der Zwischenzeit eine Lauffähige Anwendung zu Stande gebracht.
(Quizzn, Chatquiz). Wir haben da schon einige Stunden rumexperimentiert.
Ein Chat mit Quizbot. Man kann den Server selbst laufen lassen - (als Applet) - und sich als Client mit den Servern verbinden (als Applet). Da es trotzdem immer wieder kleine Problemchen mit den Java-Versionen und Browsern gibt, werde ich ergänzend in diesem Fall noch eine Standalone Anwendung schreiben. Die größte Schwachstelle ist an dieser Stelle jetzt der Endanwender. ;D

Kann man den Thread hier irgendwie als erledigt markieren?

Nochmal für alle die nur das letzte lesen:
In diesem hier geschilderten Fall musste NAT Reflection im Router eingeschalten werden.
Das geht aber nicht mit allen Routern. Vor allem die Gratis-Router der ISPs bieten diese Einstellmöglichkeiten nicht.

 

[tuxedo]

Nochmal für alle die nur das letzte lesen:
In diesem hier geschilderten Fall musste NAT Reflection im Router eingeschalten werden.
Das geht aber nicht mit allen Routern. Vor allem die Gratis-Router der ISPs bieten diese Einstellmöglichkeiten nicht.

Nur zur weiteren Ergänzung: Mit diversen DSL Fritz-Boxen und DSL Telekom Speedports sind mir da keine Probleme bekannt. Da funktioniert das nach einrichten des Portforwardings automatisch. Einen extra Menüpunkt "NAT Reflection" gibt's da AFAIK nicht.

 

[Stevo]

Also das Port-Forwarding funktioniert hier auch ohne Probleme.
Das Problem ist ja die Reflection ins "Innere" des Netzwerkes - und nicht die Verbindung von außen.

Einen Menüpunkt NAT Reflection gibts bei den billigen Geräten tatsächlich nicht. Die meisten Fritz-Boxen bieten das aber an. Einige Telekom Router sind eigentlich auch FritzBoxen und lassen sich mit ner speziellen Software wieder mit Fritz-Box Software betreiben, wodurch man mehr Konfigurationsmöglichkeiten erhält..

 

[tuxedo]

Erzähl mir mal was neues...

Ich formulier meinen Beitrag mal etwas anders: Es gibt viele billige Standardboxen bei denen man weder NAT Reflection einschalten kann, noch muss um von innen eine Verbindung zu sich über die externe IP zu machen (local -> eigene extern -> portforwarding -> wieder intern).

Oder anders ausgedrückt: Ich hatte schon >10 verschiedene DSL-Router (Modelle und Hersteller) in den Fingern. Bei allen hat diese "spezielle Art der Verbindung" out-of-the-box (abgesehen vom Port-Forwarding an sich) funktioniert.

Ergo: Meiner Erfahrung nach ist das manuelle einschalten von NAT Reflection (sofern es der Router unterstützt) deutlich die Ausnahme als die Regel.

 

[Stevo]

Okay. Aber wie hilft mir das jetzt weiter? Oder jemand anderem bei dem dieses Problem auftritt?

 

[Spacerat]

Anscheinend wird das Problem nun wirklich zu einem Problem. Ich kenn das Ganze noch unter dem Namen IP-Loopback und so nach und nach verschwindet eine solche Unterstützung aus Otto-Normal-Routern oder wird zumindest konfigurierbar. Allerdings habe ich keine Ahnung, warum diese Unterstützung immer seltener wird, ein Sicherheits-Leck kann ich mir da kaum vorstellen.
Was bekommst du denn zu sehen, wenn du deine externe IP im Browser eingibst - also sprich, versuchst, sie als Internet-Seite zu öffnen? lmr: Du bekommst das Web-Interface des Routers odergar nichts zu sehen.
Versuch mal ein Trace-Route. Ich bin mir fast sicher, dass Pakete mit Anforderungen auf deine externe IP den Router kaum in ein anderes Netz gelangen. Das ist aber notwendig, wenn das Portforwarding greifen soll, selbst wenn das nur über das Loopback-Interface (127.0.0.1) des Routers geschieht. Ich hab' ein solches Problem gelöst, indem ich beim Kauf eines neuen Routers auf die Unterstützung von IP-Loopback geachtet habe.

 

[Stevo]

Nein. Ein Loopback wäre jetzt wieder was anderes. Das hat jetzt nur indirekt was mit dem Problem zu tun. Ich greif ja nicht von dem Server-PC auf den Server (Applikation) zu, sondern von einem zweiten Rechner im lokalen Netzwerk.

Wenn ich meine WAN-IP eingebe erhalte ich nur ne 404 Meldung.

Übrigens steht der Thread hier als Gelöst da- und ich hatte die Lösung nach ganz unten geschrieben. Jetzt muss wieder jeder suchen.. oO

 

[Spacerat]

Nein. Ein Loopback wäre jetzt wieder was anderes. Das hat jetzt nur indirekt was mit dem Problem zu tun. Ich greif ja nicht von dem Server-PC auf den Server (Applikation) zu, sondern von einem zweiten Rechner im lokalen Netzwerk.

Wenn ich meine WAN-IP eingebe erhalte ich nur ne 404 Meldung.

Übrigens steht der Thread hier als Gelöst da- und ich hatte die Lösung nach ganz unten geschrieben. Jetzt muss wieder jeder suchen.. oO

So ein Pech. Dann schreib' die Lösung halt noch mal hin.
Wenn die Lösung allerdings "Nat-Reflection im Router -> On" hies ('ne andere finde ich im Verlauf dieses Threads nicht), steht sie ja immer noch als letztes hier.
Ja, Loopback ist ganz was anderes und indirekt hängt das Problem mit einer im Router nicht vorhandenen oder nicht eingeschalteten Loopbackschnittstelle zusammen. Ohne diese bleiben Pakete, welche an den Router selbst gerichtet sind, gleich bei diesem hängen, weil er nur seine WAN- und seine LAN-IP, und damit auch nur diese beiden Neztwerke kennt. Sich selbst könnte er nur per LAN-LOCAL-WAN bzw. WAN-LOCAL-LAN addressieren, bei WAN-LAN bzw. LAN-WAN hätten Pakete an eine IP des Routers diesen bereits erreicht und es wird nichts mehr geroutet, geschweige denn geportforwarderd.

 

[tuxedo]

Okay. Aber wie hilft mir das jetzt weiter? Oder jemand anderem bei dem dieses Problem auftritt?

Ist 1 und 1 zusammenzählen so schwer??

Viele überfliegen Threads nur noch. Ganz oben steht "Applet Client bekommt keine GLOBALE Verbindung zum Server", ganz unten "stand" --> Lösung ist "NAT Reflection".

Da die meisten Router wohl kein NAT Reflection Problem haben, würde es viele Anfänger wohl verwirren wenn als Lösung nur NAT Reflection hier im Thread steht. Meiner Erfahrung nach scheitert es in 9 von 10 Fällen am fehlenden Portforwarding (die meisten haben von Netzwerk leider kaum Ahnung). Von daher folgende Lösungsreihenfolge:

1. Sicherstellen dass Port-Forwarding konfiguriert ist

falls das nicht reicht:

2. Checken ob man NAT Reflection im Router einschalten kann

Wenn auch das nicht reicht: Neuen Thread aufmachen

Gruß
Alex