What is Overlay Networking and how to bring it to your IoT devices?
If you are into IoT development or software development in general, it is very likely that you have at least heard about containers. If not, check out our recent article on this which gives you a general introduction to container technology and outlines some of its most prominent benefits in the context of IoT edge computing applications. Recently, these technologies have gained popularity for software deployment over Virtual Machines. Containers provide another abstraction layer, sitting on top of the kernel of your host OS. A container engine, or usually referred to as a client, sits as a middleware between the registry server and the host machine. This client manages the lifecycle of the containers and most importantly, networking between these containers and their host.
One of the key benefits of using containers is the fact that they provide an isolated environment with its own user profiles, file system, permissions and networking stack. When managed properly, this creates a secure environment, where each container runs its own apps, libraries and dependencies, without interfering or compromising with each other and still sharing resources from the hardware platform.
Overlay networks and the IoT
An overlay network can be defined as a computer network that is layered on top of another network. Nodes in an overlay network can be connected with one another by means of logical or virtual links and each of these links correspond to a path in the underlying network. As an example, you can think of the internet, which was originally built as an overlay upon the telephone network (with the telephone network itself increasingly turning into an overlay network on top of the internet). By utilizing an overlay network one can enable their development teams to create and maintain protocols on the web easily — from data routing to file sharing management and multi-path forwarding. Another great advantage is developers can work across Virtual Machines located at different locations.
The dispersed nature of the Internet of things (IoT), however, presents a major operational challenge that is uncommon in the traditional Internet or enterprise networks. Devices that are managed together, say a fleet of autonomous vehicles, are not physically colocated. Instead, they are geographically distributed. The operational approaches for management and security used in enterprise networks, where most hosts are densely contained in a data centre, building, or campuses, simply do not translate to the IoT. IoT devices operate outside enterprise network security and operational perimeter and the corporate LAN firewall can’t protect them. Dispatching technicians is expensive, so manual provisioning and configuration doesn’t scale. Devices connect to the Internet via a variety of last-mile ISPs, so many devices won’t share a common IP prefix and addresses will change at arbitrary times. Any configuration based on these IPs will require continuous upkeep and will often be out-of-date, exposing hosts and devices to external threats.
A VPN is a virtual network extending a private network across a public network such that the end-users located at different geographic locations can still access a particular private network. A VPN can be built using tunnels or encryption (at essentially any layer of the protocol stack), or both, or alternatively constructed using MPLS or one of the “virtual router” methods. A VPN can consist of networks connected to a service provider’s network by leased lines, Frame Relay, or ATM, or a VPN can consist of dialup subscribers connecting to centralized services or other dialup subscribers. An Overlay Network is like a layer of network laid on top of another base layer, in a way that if the base layer is omitted the layer-2 would not function. In a VPN model, if the service providers implement an abstraction at the customer level and has a 2 or 3 layered structure(“overlaid” on each other) it would be an overlay network.
After weeks playing around with different VPN solutions such as OpenVPN, IPSec, and others, and trying to get them to work under a hybrid VPN-VPC setup, we came across WireGuard. This minimalist, modern VPN tunnelling technology recently found its way into the mainline Linux kernel and is now allegedly being adopted by major cloud providers. WireGuard is secure, extensible, and lightweight, not to mention that everyone seems to agree that it represents the future of VPN tunnelling. Its only downside from our perspective was the lack of a control plane or management API, a limitation that could be circumvented rather easily.
As a matter of fact, that’s how Drago was born. This tool, which is meant for running alongside WireGuard, ensures that network configurations can be updated dynamically across devices. It works by persisting the desired state of the network on a server, and having client agents fetch and apply the most up-to-date configurations locally. Drago has given us the ability to programmatically reconfigure the topology of the virtual network, assigning IP addresses, establishing links, and promptly evicting suspicious nodes. As a way of giving back to the community, we decided to open-source Drago, so that people could employ it wherever they see fit.
How does Drago work?
Drago exposes a comprehensive API through which these configurations can be retrieved and modified, implements authentication mechanisms to prevent unauthorized access, and serves a slick web UI to facilitate the process of managing and visualizing the state of the managed networks.
The Drago client, which runs on every host in the network, is responsible for directly interacting with the server through the API, and for retrieving the most up-to-date configurations. Through a simple reconciliation process, the Drago client then guarantees that the WireGuard configurations on each host match the desired state stored in the database. When running in client mode, Drago also takes care of automatically generating key pairs for WireGuard, and sharing the public key so that hosts can always connect to each other.
The only assumption made by Drago is that each host running the client is also running WireGuard, and that the host in which the configuration server is located is reachable through the network.
Drago does not enforce any specific network topology. Its sole responsibility is to distribute the desired configurations, and guarantee that they are correctly applied to WireGuard on every single registered host. This means that it is up to you to define how your hosts are connected to each other and how your network should look like.
Drago is meant to be simple, and provide a solid foundation for higher-level functionality. Need automatic IP assignment, dynamic firewall rules, or some kind of telemetry? You are free to implement on top of the already existing API.
If you are a developer working on a large application with several business needs with multi-faceted processes, you must have implemented container abstraction for your application. Recently, containerization technologies have been the most popular form of software deployment over Virtual Machines. Containerization is an abstraction sitting on top of the kernel of your host OS and packing in all your application dependencies, into a light-weight image file, which can be pushed/pulled from a “registry” containing several container images, on a client request. A container engine or popularly called the “client” sits as a middleware between the registry and the host machine. This client manages the architecture, the lifecycle of containers and most importantly, networking between these containers.
What works perfectly for a container is it forms an isolated Linux environment of its own in the host machine with its individual users, file systems, namespaces and its own network stack. This makes it a secure and provides an isolated environment, where it runs its own apps, libraries, dependencies for each container on top of the OS kernel, shared by all other containers.
Seashell is a platform of many such open-stack components for all your IoT deployment needs, provided to you at the click of a button. From service discovery to gateway configuration and application orchestration we take care of all your infrastructure needs so that developers can just focus on writing their codes and deploy the application within minutes. Curious? Check out the platform at seashell.sh and request free access for your personal/ professional IoT project at Seashell Contact.
With the Seashell platform, we provide a Wireguard VPN as a component for secure VPN networking to create a unified network spanning devices and cloud hosts and our own custom-made configuration manager Drago to configure these networks, spanning across different geographical regions, MAC addresses and different cloud providers. The Wireguard VPN is a simple, light-weight, cross-platform VPN primarily for embedded applications. Wireguard does not enable its users to dynamically change the network parameters of its connected devices. This is where we try to add Drago as a dynamic configuration manager for these networks, established by Wireguard. The dynamic parameters can be IP addresses, firewall rules for individual containers, which goes a long way in securing the IoT devices from malware attacks over the internet.
