RMI RMI und VPN - callbackObject Connection refused

[Tallan]

Hallo zusammen ich habe folgendes Problem.

Auf einem Server läuft eine java applikation auf die per rmi zugegriffen wird.
Um Verbindung zu dem Server zu bekommen wird sich zunächst per VPN ( OpenVpn ) eingewählt.
Dann wird der client gestartet.
Das Funktioniert soweit auch problemlos.

Nun nutze ich allerdings CallbackObjecte, d.h der Client gibt dem Server eine Referenz von sich selbst mit so das der Server auch Methoden auf dem Client aufrufen kann.
Anbei ein beispiel eines ClientObjects das dem Server dafür übergeben wird.

public class ClientInterfaceImpl extends UnicastRemoteObject implements ClientInterface
{
	
	private static final long serialVersionUID = 1L;

	public ClientInterfaceImpl(int PORT) throws RemoteException
	{
	
        super(PORT,
                new SslRMIClientSocketFactory(),
                new SslRMIServerSocketFactory());
        

	}

....

}

Auch dies funktioniert im Lan ( ohne VPN ) problemlos.

Nutze ich aber nun diese Callback funktion erhalte ich folgende Fehlermeldung :


java.rmi.ConnectException : Connection refused to host : 192.168.0.103; nested exception is :
java.netConnectException : Connection refused.....

Die Stelle im JAVA-Code verweisst auf den Methodenaufruf vom Server auf den Client ( über das Callbackobject )




Der Server will das Callbackobjet unter der Lan IP des Rechners erreichen ( 192.168.0.103 ) und hier ist wenn ich das richtige sehe auch das Problem da ja eigentlich über die VPN Ip 10.x.x.x kommuniziert wird.
Das konnte ich per TCPDUMP bestätigen.

Daher habe ich per

	    System.setProperty("java.rmi.server.hostname","10.x.x.x");

Die IP des Clients gesetzt, nun wird zwar scheinbar auf die richtige ip zugegriffen allerdings
bleibt der fehler der selbe...


Hat jemand eine idee woran das liegen könnte?

 

[FArt]

java rmi callback vpn - Google-Suche

java-forum.org - Suchergebnisse

 

[Tallan]

java rmi callback vpn - Google-Suche

java-forum.org - Suchergebnisse

hab ich selbstverständlich schon getan bevor ich hier gepostet habe...

hab nur leider keine lösung gefunden :/


zumal sich da auch alles etwas unterscheidet...
die callbacks funktionieren ja im lan nur nicht über vpn...
vpn funktioniert mit normalen rmi methoden die einen return haben und kein callback nutzen

also scheint das problem beim aufbau des callback sockets zu liegen, da wurde zum einen ein problem mit der ip gepostet und zum anderen die prioritäten der netzwerkschnittstellen beides habe ich getestet beides ohne erfolg..

 

[tuxedo]

Kannst du das nicht über das setzen eine SocketFactory am Client lösen? Damit lässt sich ja auch der Port einstellen der für die Callbacks genutzt wird. Dann sollte sich ja ebenfalls die verwendete IP-Adresse einstellen lassen, oder?!

- Alex

P.S. *schmunzel* RMI ist halt super wenn um um LAN übergreifende Kommunikation geht. 😀

 

[Tallan]

Kannst du das nicht über das setzen eine SocketFactory am Client lösen? Damit lässt sich ja auch der Port einstellen der für die Callbacks genutzt wird. Dann sollte sich ja ebenfalls die verwendete IP-Adresse einstellen lassen, oder?!

- Alex

P.S. *schmunzel* RMI ist halt super wenn um um LAN übergreifende Kommunikation geht. 😀

Ich glaube ( ja ich weiss glauben ist so ne sache.. ) nicht das es daran liegt der server kann ja dem client etwas senden sonst würden methoden mit return ja nicht funktionieren.

- Vpn verbinden .. Client sendet Ping an Server, Server antwortet mit Pong an client funktioniert
- Vpn verbinden .. Client sendet Daten an den Server ( u.a Callbackobject ) funktioniert
- Vpn verbinden .. Server will über das Callbackobject auf den Client zugreifen -> Connection refused..

Ich hab mir mit netstat das ganze mal beim ping pong angeschaut.. der client hat im vpn einen port auf listen für die antwort des servers, diese verbindung scheint also ohne probleme zu funktionieren, problematisch wird es erst wenn der Server versucht über das callbackobject zuzugreifen ,...

 

[tuxedo]

Ich glaube ( ja ich weiss glauben ist so ne sache.. ) nicht das es daran liegt der server kann ja dem client etwas senden sonst würden methoden mit return ja nicht funktionieren.

Das ist in der Tat so eine Sache mit dem Glauben 🙂 Du befindest dich da nämlich etwa sim irrglauben:

Methodenaufrufe vom Server zum CLient geschehen auf der Verbindung die der Client zum Server aufbaut. Return-Values kommen auf der gleichen Verbindung zurück.

Übergibst du nun ein Callback, und der Server nutzt das, so geht der Server hin, schaut in die interne Callback.Objekt struktur und findet da eine 192er Adresse. Und die ist über's VPN nicht erreichbar. Du musst also dem Client sagen dass er seine Callback-Objekte nicht mit einer 192er Adresse versieht, sondern mit der 10er Adresse aus dem VPN-Netz.

Und das müsste IMHO mit der Socketfactory (Using a Custom RMI Socket Factory) recht gut gehen. Denn so wie man da den Port angibt den der Server für die Rückverbindung benutzt, kann man da auch den host, bzw. IP angeben.

- Alex

P.S. Ausprobiert hab ich's natürlich nicht da ich für soclhe Dinge RMI nicht mehr einsetze 🙂

 

[Tallan]

Das ist in der Tat so eine Sache mit dem Glauben 🙂 Du befindest dich da nämlich etwa sim irrglauben:

Methodenaufrufe vom Server zum CLient geschehen auf der Verbindung die der Client zum Server aufbaut. Return-Values kommen auf der gleichen Verbindung zurück.

Übergibst du nun ein Callback, und der Server nutzt das, so geht der Server hin, schaut in die interne Callback.Objekt struktur und findet da eine 192er Adresse. Und die ist über's VPN nicht erreichbar. Du musst also dem Client sagen dass er seine Callback-Objekte nicht mit einer 192er Adresse versieht, sondern mit der 10er Adresse aus dem VPN-Netz.

Und das müsste IMHO mit der Socketfactory (Using a Custom RMI Socket Factory) recht gut gehen. Denn so wie man da den Port angibt den der Server für die Rückverbindung benutzt, kann man da auch den host, bzw. IP angeben.

- Alex

P.S. Ausprobiert hab ich's natürlich nicht da ich für soclhe Dinge RMI nicht mehr einsetze 🙂

Aber die Returnvalue kommt doch über eine anderen port zurück muss hierfür nicht vom server eine verbindung zum client erstellt werden??



Er greift ja auf die VPN IP zu, durch

System.setProperty("java.rmi.server.hostname","10.x.x.x");

allerdings gibt es trotzdem ein Connection refused auch unter der VPN IP

 

[Gast2]

	    System.setProperty("java.rmi.server.hostname","10.x.x.x");

Die IP des Clients gesetzt, nun wird zwar scheinbar auf die richtige ip zugegriffen allerdings
bleibt der fehler der selbe...

wenn das immer noch exakt Deine Fehlermeldung ist

java.rmi.ConnectException : Connection refused to host : 192.168.0.103; nested exception is :

dann stimmt Deine Aussage nicht ... denn da wird immer noch auf die 192++ zugegriffen

Hat jemand eine idee woran das liegen könnte?

solange Du von VPN ins LAN pingen kannst, hast Du einen Fehler in Deinem Programm ... OpenVPN läuft auf Layer 3 und hat nichts mit TCP/IP (Layer 4) am Hut

hand, mogel

 

[tuxedo]

Aber die Returnvalue kommt doch über eine anderen port zurück muss hierfür nicht vom server eine verbindung zum client erstellt werden??

?? Kann es sein dass du die Port-Sache etwas durcheinander bringst?

Das folgende Beispiel lässt deine VPN verbindung erstmal außer acht:

Wenn ein Client (192.168.0.1) eine Verbindung zu einem Server (192.168.0.2) herstellt, der auf Port 80 (nur als Beispiel, ist bei jedem anderen Port genauso) lauscht, dann wählt das Betriebssystem des Clients lokalen einen anonymen Port aus. Meist irgendwas 4 oder 5 stelliges. Nehmen wir mal an der Port der beim Client genutzt wird wäre 12345.

Die Verbindung sieht dann also so aus:

Client[192.168.0.1:12345] <----------> Server[192.168.0.2:80]

Der Client sendet seinen Request nun zu 192.168.0.2:80. Der Server antwortet darauf hin auf der gleichen Verbindung. Dass er hier den Port des Clients, den den das OS automatisch gewählt hat, nehmen muss ist klar. Die Antwort wird also adressiert an 192.167.0.1:12345

Beim Callback sieht das aber (abstrakt gesehen) so aus, dass auf dieser Verbindung ein Objekt transportiert wird, in dem die IP + Port für Callback-Aufrufe stehen:

Client[192.168.0.1:12345] ----{MyCallbackObject[192.168.0.1:22222]------> Server[192.168.0.2:80]

RMI trägt hier per default einen beliebigen anonymen Port ein. Den kann man mit der CustomSocketFactory aber noch vorbestimmen.

Gut. Jetzt macht der Server einen Callback. Er stellt nun eine zweite Verbindung her:

Client[192.168.0.1:12345] <----------> Server[192.168.0.2:80]
Client[192.168.0.1:22222] <---<Verbindungsaufbau>------- Server[192.168.0.2:80]

Und das macht er mit den Infos die er über's Callback-Objekt bekommen hat.

Und genau das ist/war mein Ansatz mit der CustomSocketFactory. Einfach IP UND PORT damit vordefinieren.

Er greift ja auf die VPN IP zu, durch

System.setProperty("java.rmi.server.hostname","10.x.x.x");

allerdings gibt es trotzdem ein Connection refused auch unter der VPN IP

Wer ist "er"? Der Client? Der Server? Lass doch mal die Property weg und probier's mit der SocketFactory. Sonst diskutieren wir hier an Weihnachten noch über "könnte", "müsste", "sollte" und "ich glaube dass" 🙂

 

[Tallan]

?? Kann es sein dass du die Port-Sache etwas durcheinander bringst?

Das folgende Beispiel lässt deine VPN verbindung erstmal außer acht:

Wenn ein Client (192.168.0.1) eine Verbindung zu einem Server (192.168.0.2) herstellt, der auf Port 80 (nur als Beispiel, ist bei jedem anderen Port genauso) lauscht, dann wählt das Betriebssystem des Clients lokalen einen anonymen Port aus. Meist irgendwas 4 oder 5 stelliges. Nehmen wir mal an der Port der beim Client genutzt wird wäre 12345.

Die Verbindung sieht dann also so aus:

Client[192.168.0.1:12345] <----------> Server[192.168.0.2:80]

Der Client sendet seinen Request nun zu 192.168.0.2:80. Der Server antwortet darauf hin auf der gleichen Verbindung. Dass er hier den Port des Clients, den den das OS automatisch gewählt hat, nehmen muss ist klar. Die Antwort wird also adressiert an 192.167.0.1:12345

Beim Callback sieht das aber (abstrakt gesehen) so aus, dass auf dieser Verbindung ein Objekt transportiert wird, in dem die IP + Port für Callback-Aufrufe stehen:

Client[192.168.0.1:12345] ----{MyCallbackObject[192.168.0.1:22222]------> Server[192.168.0.2:80]

RMI trägt hier per default einen beliebigen anonymen Port ein. Den kann man mit der CustomSocketFactory aber noch vorbestimmen.

Gut. Jetzt macht der Server einen Callback. Er stellt nun eine zweite Verbindung her:

Client[192.168.0.1:12345] <----------> Server[192.168.0.2:80]
Client[192.168.0.1:22222] <---<Verbindungsaufbau>------- Server[192.168.0.2:80]

Und das macht er mit den Infos die er über's Callback-Objekt bekommen hat.

Und genau das ist/war mein Ansatz mit der CustomSocketFactory. Einfach IP UND PORT damit vordefinieren.



Wer ist "er"? Der Client? Der Server? Lass doch mal die Property weg und probier's mit der SocketFactory. Sonst diskutieren wir hier an Weihnachten noch über "könnte", "müsste", "sollte" und "ich glaube dass" 🙂

hm ok dann hab ich da was durcheinander geworfen.
dassieht also in der praxis so aus
client 12345 -> 80 Server
dann macht der server irgend einen port auf zum senden sagen wir 33333 und sendet dann an 12345 client

so richtig ?
anderenfalls wäre es ja bidirektional wenn server 80 -> client 12345 senden würde


----------------


ich hab im client den hostnamen gesetzt auf die vpn ip, der server wirft die connection refused exception mit der vpn ip das ist oben vielleicht etwas ungücklich beschrieben durch den edit,...
die aktuelle fehlermeldung hat die VPN ip..

 

[Tallan]

wenn das immer noch exakt Deine Fehlermeldung ist



dann stimmt Deine Aussage nicht ... denn da wird immer noch auf die 192++ zugegriffen


solange Du von VPN ins LAN pingen kannst, hast Du einen Fehler in Deinem Programm ... OpenVPN läuft auf Layer 3 und hat nichts mit TCP/IP (Layer 4) am Hut

hand, mogel

Die Fehlermeldung ist durch das setzen des hostname im client auf die vpn ip nun :


java.rmi.ConnectException : Connection refused to host : 10.x.x.x ; nested exception is :
java.netConnectException : Connection refused.....


es könnte aber sein das es vielleicht am routing selbst liegt da der vpn server auf dem ich mich einwähle nicht der selbe ist wie der auf dem die server applikation läuft..
ich kann vom vpn server die 10.x.x.x pingen vom server auf dem die applikation läuft allerdings nicht
umgekehrt geht es ( mein pc kann jeden der rechner im lan des vpn servers pingen )
firewall ist bei mir um weiter ursachen zu vermeiden vorerst aus..

nachdem was du geschrieben hast könnte das problem vielleicht an einer fehlenden route liegen ich werde mal nachschauen wie sich das ändern / testen lässt

 

[tuxedo]

In der Tat. Socketverbindungen sind erstmal bidirektional. Auch bei RMI. Aber eben nur für methodenaufrufe die vom Client an den Server gehen. Da geht der Aufruf über diese Verbindung hin und das Result kommt auf dieser Verbindung wieder zurück.

Nur bei Callbacks stellt sich RMI saudoof an und macht eine neue Socketverbindung zu dem Port der irgendwo im Callback-Objekt steht, auf.

Wenn deine Fehlermeldung am Server zum Zeitpunkt des Callbacks ein connection refused auf der VPN IP des Clients aufweist, dann kann das noch eine Firewall beim Client sein. Daran schonmal gedacht?

- Alex

 

[Tallan]

In der Tat. Socketverbindungen sind erstmal bidirektional. Auch bei RMI. Aber eben nur für methodenaufrufe die vom Client an den Server gehen. Da geht der Aufruf über diese Verbindung hin und das Result kommt auf dieser Verbindung wieder zurück.

Nur bei Callbacks stellt sich RMI saudoof an und macht eine neue Socketverbindung zu dem Port der irgendwo im Callback-Objekt steht, auf.

Wenn deine Fehlermeldung am Server zum Zeitpunkt des Callbacks ein connection refused auf der VPN IP des Clients aufweist, dann kann das noch eine Firewall beim Client sein. Daran schonmal gedacht?

- Alex

Die Firewall habe ich um eben diese fehler auszuschließen kurzzeitig deaktiviert ( auf client seite ) somit scheidet dies aus, was ich nicht ausschließen kann ist ein routingproblem durch vpn, hier scheint der appication server nicht auf die vpn ip zugreifen zu können, das könnte das problem schon erklären..
ich versuche grade das dementsprechend anzupassen

 

[tuxedo]

Na wenn du vom RMI Server den RMI Client nicht pingen kannst, dann ist da ganz klar etwas am Netzwerk faul 🙂 (oder eine Firewall verhindert pings, aber dann wird's noch abstruser ... [ja, sowas solls geben])

- Alex