Reference Network Architectures
Introduction
When it comes to the implementation of Crosser Node(s) into your infrastructure, the question is where it makes sense to implement and where you can access the required source/destination-systems. In many cases, this is easier said than done. Thanks to the flexibility of the Crosser solution and capabilities like Node-to-Node communication, you have plenty of options to remain compliant with security requirements and still take advantage of all Crosser features.
This article will provide you with some ideas how customers have implemented Crosser Node(s) in different infrastructures.
Keep in mind that in all cases, the Node must be able to reach cloud.crosser.io via HTTPs port 443 in order to communicate.
Fore installation requirements of the Crosser Node, please see following article: Node Requirements →
Flat network
The probably easiest and simplest infrastructure that you can find is a single network. This is barely seen in industrial production sites or factories, but you might face this situation in a lab environment, or when your use case only requires you to interact with devices or services within your network.
The only firewall requirement in this setup is that the Node must be able to contact cloud.crosser.io via HTTPs port 443.
Infrastructure with DMZ network
More common are infrastructures with DMZ zones. In DMZs you usually face a bit more loosened network requirements and connectivity into at least two different network segments that do not have the possibility to communicate directly.
In infrastructures like this, the Node is often connected to two networks where one allows connectivity to sources and the other network which provides access to data destinations.
Beside the access to destination systems, also the network access to cloud.crosser.io is often only available from within these dedicated zones.
In this case, you need to make sure to open up the required communication protocols from the DMZ to the private network. Beside that, make sure that you can reach the public network as well from the DMZ so your Node can connect to cloud.crosser.io and potentially other external services.
The downside of this approach is that you must allow communication into your ‘private network’ from the DMZ. In many industrial environments, this is a no-go and will not be allowed since the guidelines often accept outbound traffic from the private network. Fortunately, there is also a solution to this which is explained next.
Infrastructure with network levels
If inbound connectivity to your data sources is restricted, you have to put a Crosser Node in the same network level in order to be able to connect to your required sources. Once you can connect to your data sources from that level, you might run into the limitation that you can not connect to your destination systems anymore from this network level. If that is the case, you can utilize the Node-to-Node communication concept to use a Node as some sort of Aggregator or Bridge to the outside world.
Keep in mind that in this concept the Node in the private network still needs access to cloud.crosser.io via HTTPs.
Infrastructure with distributed assets
When you have to deal with a setup where your Node(s) run on Edge Gateways or similar in distributed environments/assets, your main challenge is usually to get outbound connectivity to your services.
On the southbound-side, you usually do not find any firewall, hence the connectivity to sources is most likely easy to set up without any network configuration.
In this scenario, we highly recommend using protocols like HTTPs / REST to send out the payload data to your destination. Especially if your network connection to the outside world is not that reliable (ie. Cellular), protocols like MQTT and AMQP are not recommended.