I have made a simple Jetty server using this tutorial here, http://www.seas.upenn.edu/~cis550/jetty.html
Now that I have the initial steps completed, I can succesfully connect to my server by entering localhost:8080/hello or 127.0.0.1:8080/hello in my browser. Everything is going great up until this point. The servlet is working properly.
I am now interested in connecting to the server using "Machine B". I want to build a server that can be connected by any browser, anywhere.
My IP is XX.173.XXX.216, parts hidden for obvious privacy reasons. On my "Machine B" I try and enter XX.173.XXX.216:8080/hello into the browser URL. The website cannot be found. From experience I questioned my port mapping and opened my 8080 port.
After a few google searches and a while of reading, I give up. Does anyone know a possible solution to my problem? Are there any further steps I need to do in the setup of the Jetty server to make it accessible from external machines?
It is usually not hard getting from the inside of a firewall and out. It is much trickier to get from the outside and in (just have a look at the hoops Skype jumps through to be able to get two computers each behind a firewall to talk to each other directly).
First of all you need to ensure that Jetty listens to the right network devices.
Identify the IP-number of the computer running Jetty (not 127.0.0.1) and see if you can connect to "http://that-ip-number:8080" from the machine itself. If this doesn't work, fix your jetty configuration. Then put another computer on the same network and connect to "http://that-ip-number:8080" too. This MUST work before you go any further. If this doesn't work, fix your firewall configuration on the computer running Jetty.
When the above works,then you can start thinking about exposing the port through your router. The router most likely has a web interface where you can configure this, but the easiest way to do that is to use a uPNP tool (if your router supports that) which can redirect an external port to a specific host and port on your internal network. I use "Port Map" under OS X which has a very simple interface.
Good luck
Related
I'm writing a very simple server-client application in C++, using WinSocks.
When I set client's parameters as: resolveHost ("google.pl") for server's IP and 80 for port, I receive a html (with GET header).
When I run the server first (with port 10000) and then client (port 10000 IP inet_addr("127.0.0.1") it seems to works (I receive something).
But when I change the server's IP in client to inet_addr("188.246.158.171") (my IP for now, I don't have static IP, I've checked my actual IP with some website), it for sure DOES NOT works.
My computer is behind the router - can it be the problem?
If so, can I solve it in the way that don't requite any configuration to router (port forwarding etc.). Also, I don't want to make anything router's model-specific, so I intentionally haven't posted the model of my router ;)
Why I don't want to change configuration?
Because my application will be for "simple people". And simple people won't try to make configuration, and I won't require them to do so.
Also, many applications (on-line games for example) works fine with my router without any configuration - my application cannot be exception (by the example of other applications on my computer, I know it's possible and common to achieve it).
I use Visual Studio 2012, works on Windows 7 x64.
If you run a listening server behind a router, you must configure port forwarding rules on the router if you want outside clients to reach the server through the router. You cannot avoid that. However, if the router supports uPnP (Universal Plug and Play), your server code can configure port forwarding rules programmably, such as with Microsoft's IUPnPNAT interface. Otherwise, you have to use the router's own configuration software (usually an HTTP interface running on the router itself).
You also have to configure ports/permissions on a local firewall, if installed. Some firewalls have APIs for that, such as Microsoft's Firewall.
Online games and other peer-to-peer apps employ several NAT Traversal techniques to get around NATs, firewalls, etc. Hole Punching, Role Reversal, etc. Do some searches, information is readily available.
I am a GIS tech trying to get migrate to Geoserver, unfortunately I am not very savvy on web hosting.
I installed the Windows version 2.3.1.
I was able to build by map and access it through localhost:8080\geoserver\www\
I take that to mean that the jetty server it working.
I understand that I should be able to replace my local IP address where "localhost" is and be able to access it from another computer via Http.
I can't figure out the next step. I have found great tutorials on every part of geoserver process except this. And the user guide does not get into this either.
My set up: Cable Modem > Router > PC with Geoserver
What I have tried: Setting up a virtual server on my router. I have tried changing by router to inbound port 8080 to private port 8080
I also tried 80 to 8080
and 80 to 80
I also tried windows firewall exception. and turning off windows firewall.
I read about using appache tomcat but I have not installed it because it seems that jetty is working (at least as a local host) and I don't want to put another program on 8080. And to my understanding it can work stand alone but I really honestly don't know no.
I am must be missing some vital piece of information on how to do this. I am hoping it is just so basic that it wasn't worth mentioning on tutorials.
Thanks
Karin
This would be a GeoServer configuration question, but since its deployed in jetty the solution is likely in the underlying jetty configuration. That being said it is a guess on my part (the jetty side of things) how they set up this distribution, but if you find a jetty.xml file, perhaps under an /etc directory then you should be able to edit that file and set a proper host in the configuration.
Seriously though, this has to be a pretty common GeoServer question so I bet they have some documentation floating around for setting this properly in their software distribution.
http://docs.geoserver.org/latest/en/user/webadmin/basics.html
That seems to indicate it might be dependent on your container configuration, in which case look through how ever they are configuring jetty for a Host setting that is likely hardcoded to 'localhost'
I have two applications. One is the server app and the other is the client app. The server app listens for connections and then feeds messages to all connected clients.
So far all my testing has been done by running both applications on the same machine, and this is working fine. Now though I am trying to test the server running on one machine and the client running on a different machine.
Each of these machines are within my own home network. That network is behind a router with a firewall. From what I have read, my problem might have to do with port forwarding not setup on my router. Does that sound likely?
Is this something I can fix with just my code? Do I really have to require all my users to manually open the port on their firewalls? I have used plenty of other commercial applications that connect to servers and don't require me to open ports on my firewall. What is different about those applications and mine?
Then again, maybe I am barking up the wrong tree here. Maybe there is some other problem preventing my code from working in this situation?
I can provide any code snippets that might help, but I am unsure as to where to start looking and I don't want to just post my entire solution :)
Thank you in advance
You need to bind to 0.0.0.0 (simplified version) in order to accept connections not coming from the local machine. Have you checked that you don't bind to 127.0.0.1?
When you bind to 0.0.0.0 you actually bind to all current and future addresses of the current host and so will be able to accept connections from everywhere, you can also bind to just the address of one of the network interfaces.
We have a product we are deploying to some small businesses. It is basically a RESTful API over SSL using Tomcat. This is installed on the server in the small business and is accessed via an iPhone or other device portable device. So, the devices connecting to the server could come from any number of IP addresses.
The problem comes with the installation. When we install this service, it seems to always become a problem when doing port forwarding so the outside world can gain access to tomcat. It seems most time the owner doesn't know router password, etc, etc.
I am trying to research other ways we can accomplish this. I've come up with the following and would like to hear other thoughts on the topic.
Setup a SSH tunnel from each client office to a central server. Basically the remote devices would connect to that central server on a port and that traffic would be tunneled back to Tomcat in the office. Seems kind of redundant to have SSH and then SSL, but really no other way to accomplish it since end-to-end I need SSL (from device to office). Not sure of performance implications here, but I know it would work. Would need to monitor the tunnel and bring it back up if it goes done, would need to handle SSH key exchanges, etc.
Setup uPNP to try and configure the hole for me. Would likely work most of the time, but uPNP isn't guaranteed to be turned on. May be a good next step.
Come up with some type of NAT transversal scheme. I'm just not familiar with these and uncertain of how they exactly work. We have access to a centralized server which is required for the authentication if that makes it any easier.
What else should I be looking at to get this accomplished?
Is there no way this service can by hosted publicly by you or a hosting provider rather than with the customer?
I had a similar situation when I was developing kiosks. I never knew what type of network environment I'd have to deal with on the next installation.
I ended up creating a PPTP VPN to allow all the kiosks to connect to one server I hosted publicly. We then created a controller web service to expose access to the kiosks that were all connected via the VPN. I'm not sure how familiar you are with VPN's but with the VPN connection I was able to completely circumvent the firewall in front of each kiosk by accessing the kiosk via the VPN assigned IP.
Each kiosk node was incredibly easy to setup once I had a VPN server setup. It also brought management benefits and licensing revenue I originally didn't think about. with this infrastructure I was easily able to roll out services accessible via mobile phones.
Best of luck!
Solutions exist to "dynamically" access a software on a computer behind a NAT, but usually mostly for UDP communication.
The UDP hole punching technique is one of them. However, this isn't guranteed to work in every possible situation. If both sides of the communication are behind a "Symmetric Cone NAT" it won't.
You obivously can reduce the probability a client can't communicate using UPnP as a backup (or even primary) alternative.
I don't know Web Services enough and don't even know if using UDP for your webservice is an option (or if it is even possible).
Using the same technique for directly TCP is likely to fail (TCP connections aren't stateless - that causes a lot of problems here).
An alternative using the same technique, would be to set up some VPN based on UDP (just like OpenVPN), but as you stated, you'll have to manage keys, certificates, and so on. This can be automated (I did it) but still, it's not really trivial.
===EDIT===
If you really want to use TCP, you could create a simple "proxy" software on the client boxes which would serve as a relay.
You would have the following schema:
Web Service on client boxes, behind a NAT
The "proxy" software on the same boxes, establishing an outgoing (thus non-blocked) TCP connection to your company servers
Your company servers host a WebService as well, which requires a something like a "Client Identifier" to redirect the request to the adequate established TCP connection.
The proxy program interrogates the local WebService and send back the response to the company servers, which relay the response to the originate requester as well.
An alternative: you might ask the proxy software to directly connect to the requester to enhance performance, but then you might encounter the same NAT problems you're trying to avoid.
It's things like this that are the reason people are tunneling everything over http now, and why certain hardware vendors charge a small fortune for Layer 7 packet filtering.
This is a tremendous amount of work to fix one problem when the customer has at least three problems. Besides the one you've identified, if they don't know their own password, then who does? An administrator who doesn't work there anymore? That's a problem.
Second, if they don't know the password, that means they're almost certainly far behind on firmware updates to their firewall.
I think they should seriously consider doing a PROM reset on their firewall and reconfiguring from scratch (and upgrading the firmware while they're at it).
3 birds, one stone.
I had to do something similar in the past and I believe
the best option is the first one you proposed.
You can do in the easy way, using ssh with its -R option, using
publick key auth and a couple of scripts to check for
connectivity. Don't forget the various keep alive and timeout
features of ssh.
Don't worry about the performances. Use unprivileged users and ports
if you can. Don't bother to setup a CA, the public key of each remote
server is easier to maintain unless you are in the thousands.
Monitoring is quite simple. Each server should test the service on the
central server. If it fails either the tunnel is down or there's no connectivity.
Restarting the tunnel will not harm in any case.
Or you can do it at the network level, using IPsec (strongswan).
This can be trickier to setup and it's the option I used but I will
use SSH the next time, it would have saved me a lot of time.
+1 for going with a SSH tunnel. It's well known, widely available and not too hard to configure.
However, as you point out, you are running SSL already, so the SSH encryption is redundant. Instead of SSH you could just use a regular tunneling proxy, that provides the tunnelling without the encryption. I've used this one in the past, and it has worked well, although I didn't load test it - it was used with just a handful of users.
Here's a blog from someone who used the tunnelling proxy to access his webcam from outside his firewall.
Set up an Apache in front of your Tomcat. This Apache should be visible from the internet, where the Tomcat should not.
Configure Apache to forward all traffic to the Tomcat. This can easily be accomplished using mod_proxy (check out the ProxyPass and ProxyPassReverse directives).
Have your SSL certificate located in the Apache, so that all clients can talk HTTPS with the Apache server, which in turn talks plain HTTP with Tomcat.
No tunneling or other nastyness + you will be surprised how easy it is to configure Apache to do this.
If you want to have a RESTful integration to the client server, a tunnel to the central server that works as a proxy, seems the best approach.
But if this is not a hard requirement, you can let the central server handle the RESTfull stuff and integrate the central server and client server with other middleware. Good candidates would be RMI or JMS. For example, a RMI connection initiated by the client allows the server to do RMI calls to the client.
You could try to connect to an pc/ server and tunnel all the data via hamachi (Free VPN Software) because this tool you can install and it will create a reverse connection (from inside your nat to outside) so you can connect to it
site: http://hamachi.cc/
I created a web app with Django and I have it running on localhost (http://127.0.0.1:8000/), my question is, how can I make it available to the world, using Mac OS X's web sharing or something?
Thanks!
While you start the server specify the public ip or for any ip use 0.0.0.0
Example:
sudo python manage.py runserver 0.0.0.0:80
If you start your application without ip and port its bind only for loopback which is 127.0.0.1 and will not accessible in your network.
First off, I would strongly suggest you not to serve a website from your Mac. It's a really bad idea™. Both Mac OS X web sharing and Django's included http server (which I assume you're using) are intended for testing purposes only, for a number of reasons concerning speed, security et al. which is frankly too long to post here (but I hope that someone will :)
Second, it's already open to the world: anyone can connect to your computer using your IP address instead of the loopback 127.0.0.1 (unless you're NATted). This, again, is quite useful to test it (and have your friends/colleagues/boss) test it temporarily, but again is not fit for production use. Really.
It depends what your real purpose is, what you mean by "available to the world...or something". If you do want it to be permanently accessible from the web, you need to host it on a server (be it shared or dedicated), you won't keep your Mac turned on forever, will you? :)
For hosting Django on shared hosting - I'd recommend webfaction, step-by-step tutorials on setting up Django project can be found in their screencasts and forums (9.50$ per month for basic plan, with two months money-back guarantee, which actually works, tried myself:). More options in Djangofriendly.com
For dedicated server, ask yourself if you favor managing whole server(OS, web server, database server, memcache, firewall, backups...)yourself. If the answer is "yes", check out Linode, Rackspace, or Slicehost or even amazon web services, but bear in mind it's more expensive, it's way more complicated, but that's what gives you the ultimated flexibility. Once you are ready to try - this is one of the best tutorials i've found in net for a given subject.
If all you need is a proof of concept, that "whatever i can access from my web browser, should be accessible from anywhere in the world", ask your ISP if you are given the private IPaddress. If not, hm, better go for options mentioned above :) If you do, then find out what IP it is by visiting whatismyipaddress.com. Then start the web server as Prashanth suggested, and enter the IP address from whatismyip.org in your browser. Get nothing? a)turn off firewall of MacOSx. still nothing? b)connect your Mac directly to ethernet cable your ISP provides, without router in between. Retry entering your ouside IP in the browser. Works? great, go google "Port forwarding ", this will tell you have to configure your router to have the same effect when router is being used. Doesn't? Ask separate question in stackoverflow and provide as much details about what you are doing as you can.
Mac os Web sharing is uselless if the packets aren't routed correctly to reach your computer on a network. I guess all it can do is start apache, and open some ports in a firewall. But if your personal router or ISP wont forward external packets to your computer - you won't get what you want.
Good luck!