I have a simple gRPC service(written in C#) running on my Raspberry Pi. I'm using Kreya to send a message and get a response back. It seems to only work if I send a message from a client running on the Pi but can't do the same from another computer. It shows the port is LISTENING so I'm confused. I'm not experienced in networking so any help would be appreciated.
UPDATE FOR .NET 6.0
All that is required to get the application to listen for any ip connection is to simply add the following to the Program.cs file. This will override any other configurations.
var builder = WebApplication.CreateBuilder(args);
builder.WebHost.ConfigureKestrel(options => options.ListenAnyIP(9000));
localhost which generally resolves to 127.0.0.1 is a special network address.
It is a way for a host to refer to itself (generally) without using the (full) network stack.
In this case, it appears your gRPC server is only bound to localhost and, as a result, is only accessible to itself from other connections using the localhost address.
This explains why it can talk to itself but why other hosts are unable to access it. NOTE The other hosts using localhost are referring to their own localhost|loopback address.
You will need to reconfigure your gRPC server to bind to a specific network address. Often you can achieve this using 0.0.0.0 instead of localhost (or 127.0.0.1)
Related
I have set up a mosquitto-broker on my raspberry pi which I have running on my local network. I've tested this locally using the paho-mqtt package in python which is working, however I want to access this broker remotely (outside my local network).
From what I understand, the safest way to do this is to use TLS-authentication and configure mosquitto to listen on port 8883, rather than opening the un-encrypted 1883 port, where login credentials can be sniffed. This is where my problems start, as I suspect my ISP doesn't allow forwarding port 8883 to the (static) IP-address of my RPi. (Port wont open no matter what I try, and I've tried googling this specific issue.)
So my question is:
Is it possible to use another port than the default 1883 or 8883 (which my ISP hopefully allows to be opened) for accessing my locally hosted mosquitto-broker? For example one of the higher-valued ports, which I understand is not reserved for anything.
I'm imagining connecting to the broker by using my external IP-address with this port (xxx.xxx.xxx.xxx:yyyyy) and either tunneling this data to the 8883-port on the local network, or configuring mosquitto to listen on the selected port. Any tips on how I can solve this issue?
EDIT
Thanks for your answers! I just got off the phone with my ISP, and unfortunately they don't allow opening ANY ports because I live in a university dorm, so opening a different port won't work either. I guess using a cloud broker is the only option.
You can use any ports you want (or that your operating system will permit). MQTT uses certain ports by convention but is not restricted to using those ports. You're even welcome to encrypt on port 1883 if you want.
You'll need to do four things:
write the listener configuration directive correctly to use the port you want to use and make sure that you're listening on 0.0.0.0 in order to listen on all network interfaces, or the IP address of a specific network interface to listen on.
correctly configure encryption after the listener directive
ensure that the port you chose is accessible through any firewall your server may be running
properly configure any clients to use the port you configured and work with the encryption you configured
If you want to make it accessible over the Internet you'll need to open a port on your router as well.
If you do make it accessible over the Internet, please require authentication. Encryption won't stop strangers from connecting to your broker, it will just stop eavesdropping on them. Turn off allow_anonymous and set up some Mosquitto accounts.
In the project I am working on, there is an application that works on many docker containers. To access one of the containers I need to add the following path in the /etc/hosts file
127.0.0.1 my.domain.com
Then App of course is available on http://my.domain.com in my computer.
Unfortunately, This is large complicated application and I cannot change the configuration to add a port (then i would use 192.168.X.X:PORT from other device)? so How I would to be able to access the application from other device in local network (WIFI or other way)? I try using localtunnel or ngrok but this works too slow and aren't good in this case.
Maybe someone knows another way?
If your server is running on ip 192.168.X.X on you local network, adding the line:
192.168.X.X my.domain.com
to the second device on your network should do the job
Another solution is to run a proxy server on the same instance as your server and send all the requests to the proxy server. The proxy server will listen on another port but it will forward all the requests to my.domain.com with the original port, it will work since it uses the same /etc/hosts.
try using nginx-webserver proxy it's free version it offers the feature what you want.
add a reverse proxy and host your app with my.domain.com
OR
Host your app on port :80 ie. the default port
I have created a local websocket server using the ktor framework, which is available locally in the below IP.
[main] INFO Application - Responding at http://192.168.1.10:8080
And I'm able to access it locally from postman by hitting
ws://192.168.1.10:8080/chat
I would like to connect to this socket from the internet, But when I setup port forwarding (using NAT virtual server configuration), this doesn't seem to work. I get timed out error.
I tried this because, it is working fine for the http server (express app) I created in another port. From the below NAT virtual server configuration, I was able to do port forwarding and access the webservice from the internet.
I'm quite new to socket programming and networking. Kindly advice.
You can't have a single External Port mapped to two different Server ports. Each Server needs a distinct External Port mapped to it. Right now, you have External Port 80 mapped to both 192.168.1.10:3000 and 192.168.1.10:8080.
Once you fix that issue to use a separate External Port for each Server, then http://<externalIP>:<externalPort1> and ws://<externalIP>:<externalPort2> should work properly to reach the HTTP and WebSocket servers, respectively, from the outside world.
I have got chef-server installed on a centos machine.
Everything is working as expected except that I cannot access the chef-server web interface from another machine on my local network.
I can access the web interface from the centos machine itself:
telnet mychefserver.local 4000
Connected
If I do the same from my machine I have got:
telnet: Unable to connect to remote host: No route to host
I can successfully ping mychefserver.local from my machine
Any idea how to configure nginx with chef-server to access the chef-server from the network?
Since Chef Server 10, the web interface uses normal HTTPS (TCP 443), it only listens on the high ports locally, and nginx proxies as needed to the different backend services. I would try with a normal web browser as telnet isn't exactly great at error messages. Normally I would expect that to mean telnet is getting TCP transmission errors, but maybe it is just confused? If it is really a TCP transmit error then more likely the internal DNS is having issues. .local often means mDNS which has uneven support in some places, I would try an actual IP address to be sure.
My issue was iptables.
I stopped iptables and I can access the chef-server from my local network again.
My web server is running on localhost (127.0.0.1:8800) and I would like to send HTTP posts from another machine to that server.
Does anyone know how I will be able to access the server from the outside? (I did a SSL port forwarding from the external address to localhost, but it is a kind of hack and some aspects do not working properly, e.g. web socket does not detect traffic that's been forwarded)
127.0.0.1 is the loopback address of your network card. Only your computer can access that. 127.0.0.1 on any other computer will be that other computer.
You will have to run your server on your internal ip-address (if you're doing this in an internal network). It will probably look something like 192.168.0.x. If you're instead connecting to the computer using the internet you will of course have to bind the server to the external ip-address.
You can find your internal ip-address on Windows by opening cmd.exe and typing ipconfig. On OSX or Linux/BSD you run ifconfig in a terminal.