I have an application running on my local network (localhost). I want to connect to some external sever (outside of my local network) on a non-standard port.
The only way I can think of is to create an EC2 instance and have a nodejs server running on port 1024 for example.
The problem with this is that I don't want the expensive cost of an EC2 instance for a server that I will be using very sporadically. I don't think I can run a lambda on a specific port or create an api in api gateway to be served over a specific port.
Do you know what will be the best way to run some server on a specific port? The only thing I need is an OK response. I just need to make sure that I can make a connection from my app to a service outside of my local network running on a non-standard port.
I'd say maybe you are looking for ngrok.
It lets you expose a secure port to something that is hosted locally.
I just need to make sure that I can make a connection from my app to a service outside of my local network running on a non-standard port.
Could you clarify on the application here? Are you just trying to check that there is a connection to an outside resource? If so, then you could just ping almost any external resource and see if you get a 200 back.
Related
I have deployed an application hosting Kestrels server bindded to a specific port as web job .I want to access that port in order to have to access to APIs implemented in that application.
If I try to bind with port 443 it fails on other ports the server starts but cant interact with external requests.Is there any way I can expose this port to listen to incoming requests
Azure Web App only support port 443 and 80. And webjob host in Azure App Service.
After a lot of searching for information and trying. I can tell you with certainty that other ports cannot be used.
For more details, you can read below post.
Opening ports to Azure Web Job
Is it possible to use an Azure Web Job to listen on a public socket
The above is a statement of port restrictions in webjob.
For you want webjob to monitor and process incoming requests, my suggestion is that webjob monitors ports 443 and 80 instead of binding. You can use RawSocket.
Monitor all requests, analyze whether the request content contains instructions that need to be executed, and then proceed to the next business operation.
If you already have completed project, you also can choose VM or Cloud Services.
I have a compiled Go project that I want to deploy to an AWS EC2 instance. I just simply upload the application and run ./application on the remote server.
In the terminal, the application is running and says he's listening to localhost:3000.
I've already added the 3000 port to the security group.
However, when I tried to access it in my browser using <public-ip>:3000, it always shows connection refused, whether I've run the application or not.
I tried to run the app locally, it does work.
So is it because I deploy it incorrectly?
It is a bit difficult to help you because of no code being shared.
Some reasons why you got connection refused:
Your application is listening only localhost:3000
EC2 security group does not expose port 3000
How to fix:
Most applications are defining the host address on a config file or env variables. If you have access to change it, change it from localhost:3000 to 0.0.0.0:3000 to accepts connection from all IP or to your_ec2_public_ip:3000
If host address is hardcoded and you have access to code, change the code per above
If you don't have access to config or code to change the host address, then add a reverse proxy to route the incoming call to localhost:3000. This is a good link about using Nginx as reverse proxy https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/
Ensure EC2 Security Group allowing inbound connection for the designated port, in this case, is 3000 if you manage to route the incoming to your_ip:3000
I have a hardware device which is sending the data continuously to an configured IP and port
for example : 192.168.137.2:8080
Actually if it is AWS instance then using AWS console it is possible to see the data coming from the device directly without any web-service or application.
So i want to know whether Is there any way to see the data coming from device on dedicated server without any application?
Is it possible to add a listener or something similar to that so that we can read the data in dedicated server?
The problem was solved by TCP sockets.
I created a simple socket application which was expecting an IP and listening to a PORT and established the connection between the device and the server.
I developed our websocket project on wildfly. When we test it on localhost or within our local network, everything work fine. But when I deployed it on AWS, websocket don't work any longer. We can access other html pages. But when we conenct to "ws://ip/project location ", chrome just says hand shake error. I have experienced the same web socket problem on jelastic hosting too. My question is
Why it is happening like this?
Is websocket protocol not stable enough?
Is there any suitable hosting for websocket projects in java?
So far balancers don't forward websocket headers. To make WS working you must have a public IP address and no other services in front of your application.
I suggest you try deploying to the cloud provider : Heroku - their sample app code using node.js and websockets will get you up and running quickly. A locally running websocket app which uses a specific port - say 8888 will run fine on heroku with :
var port = process.env.PORT || 8888;
as heroku internally will deploy your app with a run-time generated port visible via PORT .
If you are using node.js with websockets I suggest using the einaros ws implementation
var WebSocketServer = require("ws").Server;
which seamlessly handles the notion of ws port -vs- the http port
Currently ELB doesn't support Websocket in HTTP mode. To be able to handle Websocket you need to configure the ELB in tcp mode (the payload of the tcp connection will be send directly to the server, so the ELB doesn't impact the http and ws flow). With this set up you won't be able to see the caller ip.
Without the ELB Websocket works perfectly (AWS only sees ip traffic and the OS only tcp one), we haven't change any thing for a plain old http server in order to use WS (except the WS handling code in the web server).
To know if you are using ELB look at the bill, AWS can provide you a lot of very interesting services, for a fee.
We just made our web system more secure by converting a single web server/database server into a 2 tier system with the webserver in front of the database server. The webserver has 2 NIC's, one for the outside world and one for an internal network. The database server has one NIC for the inside network.
In the old days, I could use Navicat's SSH feature to connect to the single websever/database server. Now the database server is hidden.
Using the command line I can ssh to webserver and then ssh into database server. But I miss my graphical tools. Is there any way to get Navicat to connect to the database server? Is there something I can set up on the webserver that will proxy to the database?
Short answer: You shouldn't connect to the database server through the web server. Yes, there are ways you could set this up, but I wouldn't recommend it if your goal is increased security.
There ought to be a way for you to VPN in to the internal network, and then ssh to both hosts from there. The security benefit is largely in reducing the attack surface on your externally accessible machines, so you'd be better off turning off ssh entirely on the external interface, then VPN-ing in to the internal network (which I hope is firewalled to only allow database traffic between the two servers, not that the web server has a NIC that's on your internal network!) Once you're on the internal network you can have Navicat connect directly to the server, without the need for ssh tunneling. (Obviously you'd need to set the firewall policies on your VPN tunnel correctly to allow this.)
If this setup is not possible, such as if you're using a low-end shared webhost, see these instructions to set up an HTTP Tunneling connection through the webhost. I really would recommend using the VPN solution if you can, but if you can't, HTTP Tunneling is the most secure way to support connecting directly through the web server to the db server.