There are two servers:
Local Server
behind a firewall (DSL Router)
connected to microcontrollers (actors & sensors)
Cloud Server
sends commands to Local Servers
The idea is that the Cloud Server sends commands to the Local Server. E.g. to trigger an actor. If there was no firewall, the best way would be IMHO to have a REST API on the Local Server. Unfortunately configuring a NAT is not an option.
What is the simplest and most common way to solve this?
Your other options are:
a) pulling, webrequest from local to online server.
b) service bus, also a pulling pattern but with a queue (i.e. Azure Service Bus or Event Hub in example)
c) server of manufactor, sometimes there is already a online service ready, like meethue-API for the hue Philips IoT Lamps
Let me know if you need more hint's.
Frank
Related
I currently have the following network setup and would like to be able to make WebRTC calls between the two clients in different networks.
I enabled IPv4 forwarding on the openSuse Leap 15.2 server and both devices have either 192.168.2.1 or 192.168.4.1 as their default gateway. The web application as well as the signaling service are both hosted on this server as well.
With the Firewall disabled the call works as suspected, but with the Firewall on the call no longer works. I thought about hosting a Coturn STUN/TURN server on this server, as I've read that you should provision one, if you run into troubles with a firewall.
Is a setup like this doable with lets say Coturn and what would the configuration look like for a scenario like this?
I ended up solving it as I describe in my GitHub issue for this matter.
For the scenario where a firewall/proxy doesn't support IoT Hub's FQDN.
The recommended approach is to script the updating of the firewall's whitelist - not going to happen in our case.
My plan B is to introduce a "gateway" on the IoT Hub side to provide a static IP address, and forward traffic to IoT Hub. I can see a few azure appliances which might serve here:
Azure Application Gateway
Azure Firewall
Azure Load Balancer
Proxy Server on VM
Has somebody been through this? What was your experience, and where did you land?
I have implemented something like this by building an HA proxy solution (based on Squid proxy) on a VM Scale Set with a Load Balancer in front. You can find the full solution here: https://github.com/sebader/azure-samples-collection/tree/master/VmssProxySolution
This one uses an internal LB (private IP) but you can also easily modify this to expose a static, public IP.
I have a set up I would like to implement but just not sure on the details. As you can see in the image below I have a single VPS in the web which I would like to use as a gateway to a number of locally running web servers. Im using the VPN to hide the IP/location of the server farm while maintaining the ability to host locally.
What I am not sure on is the implementation as I have never used a VPN before. My understanding is that I can host the VPN server on the server farm, have the VPS connect to it which will give me another 'local' network interface which I can then use apache to proxy traffic through?
The server farm is basically a small Kubernetes cluster give or take a little.
Is my understanding correct and can you offer any advice on implementaion?
Thanks in advance!
server farm example image
The VPN server should have two network interfaces. The first is the public interface that connects to the Internet and the second is the local interface that connects to the server farm. All the servers in the farm should connect only to the local interface and have the gateway set as the VPN server.
You can use the Reverse Proxy functionality in Apache to route incoming traffic to the appropriate server. See Reverse Proxy Guide
So, we all use TeamViewer for accessing GUI based (Windows / Linux) remotely and of course, it works really well.
Any ideas of how to do the same with headless (Ubuntu) servers? I'm thinking that the headless servers would run some sort of service that connects to a central server, which I can then remote into (somehow) and then route through the central server to the remote server.
It's kinda like the server based TightVNC that was popular a view years ago, where you could host the "server" module and have all your TightVNC clients connect to that server, whilst you do the same on your client, and the server module provides a gateway through to the remote systems. Just like TeamViewer really.
I wonder if the remote servers can connect to the (central) gateway server via SSH, I would do the same (again via SSH) but then the gateway server will provide me a "tunnel" through to the remote server.
I would of course prefer to have the remote servers have SSH ports opened through their firewall and then connect to them directly, but sometimes their IT teams don't like that. Having a server that runs a service, connects to a public server, means that the IT team will typically permit this, as the traffic is initiated internally and would be even more so agreeable to permitting it if that traffic uses an encrypted protocol.
Anyway - I just wondered if there was something out there that I could have a look at and see if it would work??
If you don't want a cloud controlled service (with serious security issues as of late), then check out the self-hostable MeshCentral project. It creates outbound tunnels that allow devices to communicate behind NAT and other networks.
Good news! Teamviewer 11 supports headless Linux servers :)
https://www.teamviewer.com/en/help/1111-How-do-I-install-TeamViewer-on-a-Linux-system-with-no-graphical-user-interface
Try https://www.dwservice.net/en/
Works on RPI, Linux and Windows.Best Part is free and Support for Terminal access
not just GUI ( so works faster in slower internet ) .
Client side- > just run the script ( not need of GUI)
Remote side - > Run just browser.
I am publically distributing an application which can be installed on users PC. Client will periodically communicate with the server to send information from the client. Server have to acknowledge the successful receipt of the information. Occasionally, server will do an one way communication with the client. My question is what is the best/failproof/recommended way to do client-server communication when client is massively distributed? I am currently focusing on self-hosted service to do the communication. What precaution should i take if the clients ip address change frequently?
My suggestions are:
Use HTTP or HTTPS on default ports. By massively I understand you will have no control over the network restrictions, firewalls, NAT traversal, etc. Using HTTP(S) and initiating the connections from the clients with simple web requests will save you a lot of trouble.
Use polling at regular/smart intervals to solve your occasional server initiated data transfer. Clients running on workstations wont have a public IP address, let alone a fixed one.