I have just read through some slightly aged docs on GitHub and came across this section:
[…] [F]or OpenShift you would need to change the socket.io connect URI to the following:
[some code]
Wait, why is it on port 8000? Who knows, and if I didn't run across
this blog post I wouldn't even know I had to use port 8000.
The linked blog post is dead and I doubt it would help me with my question in either case. I have worked with Daphne for a bit now where WebSockets also default to port 8000. This got me curious: Is there a reason why they run on port 8000 or is it just a coincidence/arbitrary choice? Are there any downsides to running WebSockets on another port?
Related
I'm trying to host a SRCDS (among other things) for people to join. But after trying to port forward and talking to my ISP it turns out they are using a CGNAT. I am aware of services like NGROK, Hamachi, and other VLAN and VPN type services. But the issue with VLAN is for my server to appear in the browser everybody needs to install hamachi and log into my VLAN. For obvious reasons that are not possible. One note I need to add is I looked at ZeroTier, but I'm not sure how it works or if it works for what I'm trying to do.
Some things I have tried:
ngrok. it doesn't work with srcds since it only forwards TCP and HTTP. srcds need TCP and UDP ports.
I tried looking for VPN services but neither it doesn't work for what I'm trying to do but I could figure it out.
I looked at ZeroTier but haven't tried it yet since I'm not sure it works.
I tried talking to my ISP about port forwarding but once again they are using CGNAT.
Note: paid server hosting is not an option for me due to multiple reasons. One being I need to host multiple things not just SRCDS.
With that being said. How do I make my server public for people to join etc. I have seen it is possible but I can't reproduce them with the same outcome.
On a Debian machine I'm using an OPCUA server https://github.com/FreeOpcUa/opcua-asyncio. The server does not give the possibility to enable TCP keepalive on the port opened by the server.
Basically, I want to know if it's possible to start the server then in another script, enable the tcp keepalive on that port.
I also found some other information from Redhat https://access.redhat.com/solutions/19029, and https://access.redhat.com/solutions/25773 (requires you to sign up to see the articles). But again I'm still lost as to what to do exactly.
I'll keep reading up on this, but so far I've spent about 10 hours trying to figure out whether it's even possible. So I thought I should ask for some help.
Any advice is welcome, thanks!
For operations of socket of another process socket must be shared from it https://docs.python.org/3/library/socket.html#socket.socket.share or duplicated.
Its easier to patch your server for keepalive.
My provider is Ask4 and they only provide 1:1 NAT which opens ports 22 and all above 1024. No UPnP. However, I want to use ports 80 and 443 for a web server.
Is there a way without changing those ports to host a web server?
Can SSH Dynamic port forwarding or Proxies/Tunnelling software help me with this?
I want to avoid VPNs as they tend to be a slower solution. The more responsive the better.
Thanks!
For me, i looked into it further and after a couple of days found that a reverse proxy was the best.
It works by running on one server running apache, nginx, etc and then basically sending that traffic to the designated IP. You can also select a port!
I have a web page to control a thermostat on a raspberry pi, and I'm running into difficulties when trying to get websockets to work from a remote client. It seems to work fine when on LAN however. I'm obviously missing something (and likely something basic), but I can't seem to figure out what it is.
The pi's local ip is 192.168.1.134. The web page (served from apache server) has the URL http://192.168.1.134:8010/thermostat.html. The page starts up some javascript, which then tries to connect to the pi's main program using websockets via ws://192.168.1.134:9000. (the server on the pi is running libwebsockets). The websocket comes up, and it seems to work fine. I then tried to connect via a remote client (a cell phone, where wifi was turned off) from http:\\23.239.99.99:8010\thermostat.html. The html/js files load fine, but the web socket attempts to connect to uri ws:\\23.239.99.99:9000, and this fials.
As far as I can tell, the NAT seems to be configured properly:
name ext ext protocol int int ip addr interface
port port port port
start end start end
Thermostat3 8010 8010 TCP 8010 8010 192.168.1.134 eth3.1
Thermostat5 8000 8000 TCP/UDP 80 80 192.168.1.134 eth3.1
Thermostat_ws 9000 9000 TCP/UDP 9000 9000 192.168.1.134 eth3.1
I checked, and the router does not have any firewalls set up, neither does my modem. I didn't install a firewall on the pi (I checked, and there's no odd iptables rule). Does anyone know what I'm missing?
--- EDIT ---
I'm still stuck on this. I called my ISP and they assure me there are no firewalls on their servers. Is there any way to tell if port 9000 is being blocked, and by who?
Bind your apache server to 0.0.0.0 address to make it accessible from remote machines
Try this tool to determine if the port is inaccessible (use the custom port): http://www.whatsmyip.org/port-scanner/
Everything else looks fine. As a sanity check I would try putting the ws port to 8010 to see if that works. I would also recommend using a tool like Advanced Web Client to isolate networking issues.
This is interesting. I once had a similar problem. I set up a WebSocket (I was using a nodejs ws) and once I tried to access it from remote client I was not able to reach it with ws://yourip:port but instead I had to use http://yourip:port. I don't know if you have the same problem, mine was due to a proxy I was using.
I still have an advice for you how you might be able to solve your problem. I don't know how concerned you are about security but as far as I understood your idea you basically connect to your raspberry pi through a WebSocket and tell it to change the temperature.
Back when did a similar project I found it rather hard to secure my WebSocket connection. I was basically sending a password plus command through the WebSocket to my server which then checks wether the password is correct. Otherwise everyone on the internet could heat your house. Not cool...
But therefore, I had to tunnel the connection through https to prevent a middleware attack.
I quickly threw the towel and decided to go with a completely different solution. Basically I set up a nodejs express server (can easily be configured with a self signed certificate to use https or used behind a nginx/apache https server) and authenticated with username and password. When someone made a POST request to /api/thermostats?id=0 with a temperature request, the server checks if the user is authenticated and then executes a terminal command from within node.
Maybe this idea also fits your demands.
I currently have a small socket server that I'm trying to convert to a web server. Basically it dumps XML to anyone connecting to it. At the moment, it's not a web server as it listens to a non-web port (1337).
I know that both 80 and 8080 are accepted web ports, but none of those are free on the machine I'm going to use. Are there any other web ports available? Or how do I configure a windows machine so that e.g. port 1337 is web?
Well for the most simplistic method append :port to your URL such as http://192.168.1.1:1337
I may be misunderstanding your question though.
You just start listening on the port. Viola. It's a server. That simple.
Oh, and you have to tell your audience which port to use.
To be more complete: it's a web server not because of the port, but because of the language spoken on that port. You can serve HTTP over any port, which is one of the ways back-door-style malware gets around misconfigured firewalls.
What you probably need is to implement (in order to implement an easily usable web service, which I assume is what you are aiming for) the http protocol and probably SOAP or REST, not select a port number. Tell us what language you are using, and we might be able to suggest a suitable framework.
What #fictoris said. Or setup your webserver to redirect http://myapp.com to the correct port as well.
There's nothing really magic about the ports you are talking about. And really it's just port 80 that's standard HTTP. 443 is the standard for secure HTTP though (HTTPS).
If you have to run on a non-standard port you must specify that port in every (non-relative) URL: http://localhost:13828 ...
If you need to use port 80 you might be able to redirect the incoming client depending on what demain it requested though.
Here is a list of all the TCP/UDP ports that have official designations and the hi-jacked, oh I mean unofficial ports that are known. Hopefully that will give you an idea of what is going on "out there."
Note the "Dynamic, private or ephemeral ports: 49152–65535" section at the bottom.