[java] RMI over internet

[Verwijderd]

Het lukt mij niet om RMI over het internet te gebruiken, het werkt wel over het interne netwerk.

In m'n firewalls heb ik de poorten 1098 en 1099 geforward naar de locale client/server.

Op de client verwijs ik als volgt naar de server:

Java:

Naming.lookup("rmi://85.146.6.23:1099/TestSystem");

Op de server:

Java:

Naming.rebind("//192.168.1.23/TestSystem", tm)

De server en client staan op twee verschillende netwerken, het lijkt mij dat ik een fout maak in het verwijzen naar de server of moet ik gebruik maken van http tunneling?

[reddog33hummer]

van http://www.velocityreview...nd-not-over-internet.html

If your server is indeed behind the firewall, and the configuration is
something like:

internet > external NIC > firewall > internal NIC > LAN > server host
(here "external NIC" and "internal NIC" are network cards inside the
firewall, at the public and private ends)

then you have to bind the server object to your _local_ (private) IP address
of the server host, but the java.rmi.server.hostname property must be set to
the external IP address of the firewall. Your client, when locating the
server, will also have to use that same external IP address in order to
connect to the server. Finally, the firewall (or NAT router - whatever it is
called at your location) will have to route packets destined to the server
(based on say port number) from the external to the internal NIC.

Kortom pobeer eens aan de server kant:

code:

Properties systemProperties = 
      new Properties( System.getProperties() );
   systemProperties.put("java.rmi.server.hostname","85.146.6.23");
   System.setProperties(systemProperties);

Naming.rebind("//192.168.1.23/TestSystem", tm)

http://www.eli.sdsu.edu/c.../rmiConfig/rmiConfig.html

[ Voor 3% gewijzigd door reddog33hummer op 17-11-2008 21:22 ]

[Verwijderd]

Ik heb het geprobeerd, nu krijg ik het volgende:
java.rmi.ConnectException: Connection refused to host: 192.168.1.23: nested exception is: java.net.ConnectException: Connection timed out: connect

Java:

Naming.rebind("//192.168.1.23/TestSystem", tm)

Heb ik zoals in de gegeven link staat veranderd in:

Java:

Naming.rebind("//192.168.1.23:1099/TestSystem", tm)

Op dit moment heb ik geen idee waar/wat er fout gaat, hoop dat jullie nog een tip kunnen geven.

[Spiral]

Verwijderd schreef op maandag 17 november 2008 @ 21:11:
In m'n firewalls heb ik de poorten 1098 en 1099 geforward naar de locale client/server.

Dit heb je in zowel de beide computers gedaan én in de router d.m.v. bv. NAT?

[Verwijderd]

Dit is gedaan op beide machines (client/server) en ook in de routers.

Is het niet handiger als ik http tunneling gebruik? Zodat de porten niet open gezet hoeven worden.

[Salandur]

http tunneling is zeker een optie. maar zoals het commentaar van reddog al zegt: je rmi server luistert op dat ip adres, dus zal je je eigen rmi object ook op dat ip adres moeten binden en niet op het interne 192 adres.

[Verwijderd]

Ik denk dat ik toch ga voor webservices omdat:

• Geen gedoe met poorten openen
• Veilig (in tegendeel tot RMI met HTTP tunneling)

Het enige nadeel is dat het iets minder snel is.

[flowerp]

Verwijderd schreef op vrijdag 21 november 2008 @ 14:21:
Ik denk dat ik toch ga voor webservices omdat:

• Geen gedoe met poorten openen
• Veilig (in tegendeel tot RMI met HTTP tunneling)

Dat is waarschijnlijk inderdaad de beste oplossing, Webservices zijn juist zo populair geworden omdat HTTP tunneling default door elke implementatie ondersteund wordt en dit feitelijk de enige manier is om alle beveiligingen die firewalls opwerpen te omzeilen.

RMI, Corba, Dcom, etc is allemaal erg mooi, maar waardeloos tenzij je als applicatie developer de controlle hebt over alle firewalls tussen de 2 systemen die communiceren met elkaar. Dit is zelden het geval. Firewalls proberen expliciet te voorkomen dat applicaties met elkaar communiceren en zijn daar dan ook goed in geslaagd.

(wat betreft dat laatste, mensen die firewalls beheren zijn dus absoluut niet blij met webservices, omdat deze dwars door alle beveilingen heen fietst die zij juist hebben opgeworpen)

[Salandur]

Je moet als programmeur sowiso beveiliging inbouwen. Overigens moet je de firewall nog steeds aanpassen voor inkomend verkeer!

[flowerp]

Salandur schreef op zaterdag 22 november 2008 @ 21:22:
Je moet als programmeur sowiso beveiliging inbouwen. Overigens moet je de firewall nog steeds aanpassen voor inkomend verkeer!

Voor een thuis situatie wel, maar in de meeste corporate omgevingen draait er 99% van de keer al ergens aan de andere kant van de firewall een of andere HTTP server, dus 99% van de keren fiets je er met je applicatie gewoon zo door heen

[Salandur]

Als dat kan doet de netwerk man zijn werk niet goed. Meestal sta je een ip-adres/port combinatie toe, of via een proxy. Maar je kan dan wel alles dicht of open zetten, maar zolang een applicatie geen beveiliging heeft heb je een security probleem. De firewall kan dat niet controleren of tegenhouden.

[flowerp]

Salandur schreef op zaterdag 22 november 2008 @ 22:07:
Als dat kan doet de netwerk man zijn werk niet goed. Meestal sta je een ip-adres/port combinatie toe, of via een proxy.

Je snapt het niet.

De 'netwerk man' (mag vrouw ook trouwens?), doet z'n werk uitstekend. Jarenlang heeft die alle poorten lopen dicht te spijkeren en alle mogelijke loopholes afgesloten.

Communicatie via RMI (JRMP), maar ook DCOM of IIOP (bekend van Corba) was gewoon niet mogelijk zonder heel erg veel problemen. Dan hebben we het over wekenlange authorisatie procedures, uren lange gesprekken met die 'netwerk man' van jou die ondanks een authorisatie van een manager toch niet wilde toegeven, wat weer resulteerde in escalaties, personeels manager erbij, andere college erbij, vuisten die op tafel gingen etc etc. Uiteindelijk gaf die 'netwerk man' dan of toch toe, of toch niet en moest de hele procedure weer herzien worden.

Er waren 2 dingen die wel toegestaan waren: HTTP en SMTP. Mensen moeten mailtjes kunnen versturen en ontvangen, en er moeten HTTP requesten worden gedaan naar een remote web server en in verreweg de meeste gevallen heeft een bedrijf ook een HTTP server waar je requesten heen kunt doen.

HTTP is immers een veilig protocol. Dat wordt gebruikt om hypertext pagina's op te vragen en dat is gewoon text. Niets mis mee. Ondertussen kan een modaal bedrijf ook simpelweg niet meer functioneren zonder email en www.

Toen kwamen echter web services, waarbij je SOAP gewoon over HTTP kon sturen. En guess what? Omdat je SOAP met HTTP kunt versturen gaat dat gewoon ongemerkt door de firewall. Voor mij, als applicatie ontwikkelaar maakt dat het leven ongelooflijk veel makkelijker.

Het duurde heel even voor die 'netwerk man' dit in de gaten had. HTTP was immers toch gewoon text? Maar ondertussen waren we het als applicatie communicatie protocol gaan gebruiken. Opzich vonden wij, de applicatie ontwikkelaars dingen als CORBA IIOP, RMI of DCOM eigenlijk veel beter. Als deze nooit die problemen met de die firewall ondervonden hadden, waren SOAP messages wellicht nooit zo snel zo populair geworden.

Die 'netwerk man' heeft het dus nu wel zeer zeker in de gaten, maar wat kan ie nu nog doen? HTTP port 80 dichtgooien is gewoon geen optie, dus die -moet- ie openlaten staan. Text filteren? SOAP messages zijn gewoon text. Ik snap natuurlijk wel dat ie lichtelijk geirriteerd is. Al die beveiligingen, maar zoals gezegd, ik fiets er gewoon zo doorheen. Kan ie net zo goed de andere poorten weer opengooien eigenlijk...

Maar je kan dan wel alles dicht of open zetten, maar zolang een applicatie geen beveiliging heeft heb je een security probleem. De firewall kan dat niet controleren of tegenhouden.

Dit heeft zeer weinig met de security van je applicatie te maken, maar alleen met de bereikbaarheid van je applicatie. Je applicatie moet -natuurlijk- zelf zorgen dat authorisatie van niet publieke resources goed geregeld is. Eventueel kunnen er wel enkele bestaande systemen voor authenticatie makkelijk hergebruikt worden.