I have an exposed GraphDB instance in an ip address and port with http protocol. I want to make it more secure so I decided to expose it through https and a domain (with the port included in it). The problem is when I try to call the instance from Java code with the library rdf4j, if I the ip address and port as repository endpoint the code connects perfectly and adds the statements, nevertheless, if I set the domain as endpoint it returns a timeout. This is the code I am using:
HTTPRepository repository = new HTTPRepository("https://example.com", "repository_name");
RepositoryConnection dataSource = repository.getConnection();
dataSource.add(statements);
This is the thrown exception:
org.apache.http.conn.HttpHostConnectException: Connect to example.com:80 [example.com/"here there is the resolved ip address"] failed: Connection timed out: connect
Rdf4j uses apache http library which supports https connection. However, in the exception the port 80 is shown, that's make my think it is attacking the port without considering the https at the begining of the address.
If more information is required I can add it.
Related
I am testing on java.net.ServerSocket.
What I want is the following.
When connecting to aaa.com, you get aaa.com,
Getting bbb.com when connecting to bbb.com.
My etc/hosts file configuration is as follows.
127.0.0.1 aaa.com
127.0.0.1 bbb.com
I used the following java source.
ServerSocket server = new ServerSocket(port);
Socket request = server.accept();
request.getInetAddress().getHostName();
And when connecting to aaa.com, aaa.com is returned.
When connecting to bbb.com, aaa.com is returned.
How can I get bbb.com when connected to bbb.com?
This code is not connecting to anything. It is accepting connections from ... something.
So ... I presume that you have some client code (not shown) that is connecting to port port using hostnames "aaa.com" and "bbb.com" respectively. And you want this server side to know which hostname that the client side used.
It is not possible.
The client resolves the hostnames to an IP address and then makes the connection using the IP address (and only the IP address). Since the IP address is the same in both cases, the server side cannot distinguish the two cases.
It follows that if the application level of the server needs to know the hostname that the client used to make the connection, then the application protocol must pass this information from the client to the server. (That is what protocols like HTTP, FTP and so on do.)
I am playing with the code https://cs.lmu.edu/~ray/notes/javanetexamples/#chat at the moment.
In the line
var client = new ChatClient(args[0]);
of the clients' main method you pass a host name to the constructor.
I am still getting a "ConnectException: connection refused" trying to connect to my server as a client over the internet (with my public IP), whereas I can connect to it locally (with "localhost"). I have checked the firewall, all ports and the server itself, but still getting it. The ping to my IP works, but the connection is being refused.
Is it possible for me to connect as a client over the internet from my laptop to the server running at my laptop?
The trace:
Exception in thread "main" java.net.ConnectException: Connection refused: connect
at java.base/sun.nio.ch.Net.connect0(Native Method)
at java.base/sun.nio.ch.Net.connect(Net.java:503)
at java.base/sun.nio.ch.Net.connect(Net.java:492)
at java.base/sun.nio.ch.NioSocketImpl.connect(NioSocketImpl.java:588)
at java.base/java.net.SocksSocketImpl.connect(SocksSocketImpl.java:333)
at java.base/java.net.Socket.connect(Socket.java:648)
at java.base/java.net.Socket.connect(Socket.java:597)
at java.base/java.net.Socket.<init>(Socket.java:520)
at java.base/java.net.Socket.<init>(Socket.java:294)
at ChatClient.run(ChatClient.java:71)
at ChatClient.main(ChatClient.java:97)
So, calling client.run() the exception occurs when trying to open a socket at the passed IP address at
var socket = new Socket(serverAddress, 50000);
and I use the port 50000 for both.
It is extremely unlikely that you would be able to connect directly to your computer from the internet without extra work.
Minimally you would need to do port forwarding in your router to redirect all connections to port 59001 to your machine.
In suggest using something like ngrok for this instead:
ngrok http 59001
and now you should be able to connect to your service
var socket = new Socket("http://CUSTOM_URL_PROVIDED_BY_NGROK.ngrok.io", 59001);
I need some help with doing netty socket io over https. I have got it to in my local env but not on a server with secure domain. The server starts but client isn't able to connect. Tried by starting the socket server with IP as well as domain name. For the server to start with domain name as hostname value in setHostname method, I added an entry in /etc/hosts file as following
127.0.0.1 localhost example.com
Socket server started by giving example.com as hostname but client isn't able to connect using the same hostname over https as following
var socket = io.connect('https://example.com:10443')
Tried with options - { secure: true, reconnect: true, rejectUnauthorized : false } too but the same issue.
On server side my configuration is as following
Configuration configuration = new Configuration();
configuration.setHostname("example.com");
configuration.setPort(10443);
configuration.setKeyStorePassword("mypassword");
InputStream stream = getClass().getClassLoader().getResourceAsStream("keystore.jks");
configuration.setKeyStore(stream);
The jsk file was created using keytool command for the same domain (example.com)
Is there something more to be done for the port - 10443 to be used by the socket server? Or is there any other configuration to be done?
Got the solution! I had not mentioned that the domain was set up on cloudflare. Here the issue was with the port I used - 10443. It's not supported by cloudflare. Changed it to 8443 and it worked!
For those who come across this, please find here the list of supported ports that Cloudflare work with. May save much of your time unlike me.
Also, please note that I used my public IP as hostname in setHostname() method so that I don't need anything added in my hosts file. Then gave the actual domain name with https on client side to connect to the server. That's it. Thank you all!
Sandeep
I've looked online, and everything I find shows how to make a separate server to connect to the main server if it's behind a nat or firewall.
But in my case the client is behind the NAT, and the server is on the local network.
So it's set up kinda like below:
Client Actual:10.0.0.1 -> Client NAT:100.0.0.2:1111 <--> Server 10.0.0.0:1099
The Java code I use to connect to the server is as below:
String serviceUrl = "service:jmx:rmi:///jndi/rmi://10.0.0.0:1099/jmxrmi";
String[] credentials = new String[] {"username", "password"};
String objectName = "org.apache.activemq:type=Broker,brokerName=test";
JMXServiceURL url = new JMXServiceURL(serviceUrl);
Map<String, String[]> env = new HashMap<String, String[]>();
env.put(JMXConnector.CREDENTIALS, credentials);
JMXConnector jmxc = JMXConnectorFactory.connect(url, env);
conn = jmxc.getMBeanServerConnection();
broker = MBeanServerInvocationHandler.newProxyInstance(conn, new ObjectName(objectName), BrokerViewMBean.class, true);
And the error it throws is:
java.rmi.ConnectException: Connection refused to host: 10.0.0.0; nested exception is:
java.net.ConnectException: Connection timed out: connect
So my question is, how do I make this client behind NAT connection work?
First of all: there is nothing special in with regard with network configuration for ActiveMQ to work. ActiveMQ's protocol is single port, and can be easily routed just like most other TCP/IP protocol.
Therefore, given that the server is properly listening on its TCP port and that a client can successfully connect to it locally, then this problem can be analyzed as if it was any other network-related problem.
Can the client machine ping the server machine? It is difficult from the IP address scheme that you present to properly understand your network, but as it is presented right now, the client machine will simply assume that the server is on the local network and therefore send an ARP request asking for the MAC address of "10.0.0.0" (which will timeout because there is no such machine to answer the request) rather than forward the request to its NAT gateway. If that is indeed the problem you have, then there are three possible solutions: a) modify the network layout (have the client use a different IP scheme), b) setup a static route for the server's IP on the client machine to force its routing through the gateway, or c) add a port redirect on the gateway and have the client connect to the IP address of the gateway instead. Now solution a is not very practical, unless your setup is barely a lab configuration. Solution b is a possibility, but a really bad one. Solution C, that is setting up port redirection on the gateway, is the most common solution to this kind of problem.
Use hostnames on both sides, by setting the same -Djava.rmi.server.hostname=XXX. Be sure that hostname is resolvable on both sides. You can have a look at http://docs.oracle.com/javase/8/docs/technotes/guides/rmi/faq.html#nethostname
I have a java rmi application i simply do:
Client:
Registry registry = LocateRegistry.getRegistry("localhost");
costApi = (CostApi) registry.lookup("server.CostApi");
Everything works fine when I host the server at localhost. When I start the same program at another machine withing the local network, at 192.168.x.x and change to:
Client:
Registry registry = LocateRegistry.getRegistry("192.168.x.x");
costApi = (CostApi) registry.lookup("server.CostApi");
it does not work anymore and it fails with a very strange error:
java.rmi.ConnectException: Connection refused to host: 127.0.1.1; nested exception is:
java.net.ConnectException: Connection refused
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619)
at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:129)
at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:194)
at java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:148)
at com.sun.proxy.$Proxy0.dataCost(Unknown Source)
at billing.data.DataBiller.performBilling(DataBiller.java:57)
at billing.data.DataBiller.consumeMessage(DataBiller.java:46)
at general.templates.RabbitWorker.run(RabbitWorker.java:124)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
I'm not even trying to connect to 127.0.1.1 but to 192.168.x.x, how do I solve this? I prefer to use java code only and not modify my machine with config files. I'm using linux
This is usually caused by a misconfiguration. Check your /etc/hosts file to ensure that:
localhost maps to 127.0.0.1
your real hostname maps to your real host address
Some Linux distributions are known to have this back to front.
If the problem persists, try setting java.rmi.server.hostname at the server to the IP address the client should use when executing remote method calls. It needs to be set before you export any remote objects, including the Registry.
The problem is caused by the IP address embedded in the stub, which ultimately comes from something like InetAddress.getLocalAddress(), which is fallible as above. It is overridden by java.rmi.server.hostname.
This is item A.1 in the FMI FAQ, but note that the item is mistitled. It doesn't happen during lookup(), it happens when you call a remote method on the resulting stub.
I just ran into the same issue. I'm doing something very similar to what you are doing. What I noticed was that the first time I ran the client program, and it failed ( by design of the firewall test ) - that it failed with an error message showing the actual ip address of the host that I originally specified ( the 192.168.x.x address ), but all subsequent failures show that it is failing to make a connection to 127.0.0.1. Currently I'm suspecting some kind of caching on the client - has the JVM marked that ip address as never accessible again and it's refusing to ever try to connect to it again?
UPDATE: In my case, the JVM on the RMI Server side was not able to properly set the java.rmi.server.hostname property at JVM startup. This property was being left as null. When clients connect to a specific RMI Registry and ask for a stub to a particular named object, they receive a stub containing the ip address of the remote machine where the actual object can be found. The RMI server copies the contents of the java.rmi.server.hostname property into the stubs it returns to clients, so if the java.rmi.server.hostname property is "" and it copies that to each stub it creates, each stub contains a reference to remote server with an IP address of "". By default the client jvm reacts to this by attempting to connect to the server object on the localhost, 127.0.0.1. To work around the problem, try this line of code before exporting any remote objects on the server side:
System.setProperty( "java.rmi.server.hostname", "192.168.RMIServer.IP" ) ;
This property will be automatically copied to all remote stubs exported on that server, and clients who receive that stub should then be able to reach the remote server ( assuming any firewalls are configured correctly ).