Skip to main content

 

Druva Documentation

About the inSync Edge Server

inSync Private Cloud Editions: File:/tick.png Elite File:/tick.png Enterprise

Overview

In an inSync Private Cloud deployment, the inSync client might back up data outside the organization's firewall. This means providing access to the inSync Master and the inSync Storage Nodes from outside the firewall. As a security policy, your organization might not allow connections or requests that come from devices outside the firewall. In such scenarios, we recommend the use of inSync Edge Servers.

The inSync Edge Server sits in a demilitarized zone (DMZ), outside your organization's firewall and facilitates communication between the inSync client and the inSync Master, or the inSync client and the inSync Storage Node. By validating the requests that the inSync client sends to the inSync Master or to the inSync Storage Node, the inSync Edge Server introduces an additional layer of security. The inSync Edge Server acts as a gateway that filters requests via unauthorized networks to counteract the vulnerability of the Private Cloud setup.

inSync Edge Server deployment architecture

The following diagram illustrates a sample deployment of inSync Private Cloud with inSync Edge Servers. The organization has geographically distributed location, and each location is protected by a firewall.

As illustrated in the diagram, at least one inSync Edge Server is required for each location. Once inSync Edge Server is configured for the inSync Master or the inSync Storage Node. inSync Master and inSync Storage Nodes that are within the same network communicate directly. When the inSync Master needs to communicate with inSync Storage Nodes that are outside the network, the inSync Master communicates through the inSync Edge Server. The inSync client communicates with the inSync Master or the inSync Storage Node through the inSync Edge Server.

Prerequisites

  • Ensure inSync Master maintains a persistent connection with the Edge Server.
  • Ensure the inSync Storage Node maintains a persistent connection with the Edge Server. 
  • Under Manage > Settings > Network > SERVER IP/FQDN, enter the Internal IP of the inSync Master or the FQDN of the Master.
  • Under Manage > Settings > Edge Servers  > IP Address/FQDN, provide the FQDN for the Edge server.
  • The user web access URL should be a FQDN.
  • Under Manage > Storage List > Storage Node, enter a FQDN for the Storage Node. 
  • Under Manage > Storage List > Storage Node > Advanced options, enter a FQDN for the Edge Server for the inSync Storage Node. 
  • inSync Master should be able to connect to the Edge Server. (Telnet should work ideally).
  • Storage Node should be able to connect to Edge. (Telnet should work ideally).

 

The FQDN should be used as mentioned below:

FQDN for Master inStnc Master FQDN should point to the Public IP of Edge Server for External requests and Internal IP of inSync Master for Internal requests.
FQDN for Edge Edge Server FQDN should point to the Public IP of Edge Server for External requests and Internal IP of Edge Server for Internal under (Master > Edge communication).
User Web access URL It should ideally be equal to inSync Master FQDN.
FQDN for Storage Node It should point to the Public IP of the Edge Server (for the Storage Node) for External requests and Internal IP of the Storage node for Internal requests.
FQDN for Edge Server for Node Edge Server FQDN should point to Public IP of Edge Server for External requests and Internal IP of Edge Server for Internal under (Node > Edge communication).

inSync Edge Server deployment scenarios

You can have any of the following Edge Server deployment scenarios in your inSync Private Cloud environment.

Deployment scenario Implementation

Single Master Server and Storage Node on the same machine.

Requires only one Edge Server.

Master Server and multiple remote Storage Nodes. All in the same geographical location.

Requires only one Edge Server.

Master Server and multiple remote Storage Nodes that are in different geographical locations.

Requires one Edge Server per network if you want the remote Storage Nodes to be accessible from all the networks.

Authentication and security

The following diagram illustrates the communication between the inSync client, inSync Edge Server, inSync Storage Node, inSync Master, and your firewall.

  • All communication between various components are encrypted by using 256-bit SSL encryption.
     
  • When the inSync Master connects with the inSync Edge server, inSync uses a shared unique key between the inSync Master and the Edge Server to authenticate the connection. This ensures that no untrusted application acts as the Edge Server or the inSync Master. Once the authentication is successful, a persistent connection is established between the inSync Master and the inSync Edge Server. The same authentication mechanism is used between the Storage Node and the Edge Server.
     
  • No incoming connection is required from anywhere outside the network to the inSync Master or the inSync Storage Node. Additionally, there are no outgoing connections from the Edge Server to the inSync Master or the inSync Storage Node. Therefore, you do not need to open any port on your firewall for inSync servers.
     
  • By default, the Edge Server has self-signed SSL certificates loaded. Customers can also choose to load their own certificates for production use.
     
  • When inSync client users who are outside the enterprise network try to connect with the Edge Server, the inSync client checks for certificate fingerprint and also refers to the root CA repository to verify the Edge Server identity. If the certificate fingerprint check fails, the inSync client stops communicating with the Edge Server.
     
  • The inSync Master also authenticates the inSync client and ensures that requests are coming from an authentic client. This prevents any man-in-the-middle attack.

Data flow through the inSync Edge Server

The following table explains the data flow between the inSync client, inSync Master, inSync Storage Node, and inSync Edge Server.

Step Description
1 The inSync client initiates a backup or restore request to inSync Edge Server.
2

The inSync Edge Server validates the request. The security mechanism in place for this stage is as follows:

a. The inSync client initiates an SSL connection with the Edge Server.

b. The Edge Server performs the parameter validation.

c. The Edge Server forwards the inSync client request to the inSync Master for authentication.

d. If the authentication is successful, the Edge Server creates the communication tunnel between the inSync Client and the inSync Master. This tunnel is SSL-encrypted.

If the authentication failed, the connection between the inSync client and the Edge Server is closed.

3 The inSync Master receives the backup or restore request from the inSync Client over a secure tunnel. The inSync Master then redirects the inSync Client to the appropriate inSync Storage Node. During this redirection, the inSync Master sends an encrypted token to the inSync Client. This encrypted token is used for the authentication of the inSync Client with the inSync Storage Node.
4

The inSync client sends the request to the inSync Edge Server that is configured for the inSync Storage Node with which the inSync client wants to communicate.

The security mechanism in place for this stage is as follows:

a. The inSync client initiates an SSL connection with the Edge Server.

b. The Edge Server performs the parameter validation.

c. The Edge Server forwards the inSync client authentication request to the inSync Storage Node to validate the encrypted token received from the inSync Master in step 3.

d. If the authentication is successful, the Edge Server creates the communication tunnel between the inSync Client and the inSync Storage Node. This tunnel is SSL-encrypted.

If the authentication failed, the connection is closed.

5

Data is backed up or restored over the SSL-encrypted tunnel. This data is stored on the inSync Storage Node by using AES encryption.

Data Flow through Client Activation

The following table explains the data flow required to activate the Client:

Step Description
1 Activate the Client (which is sitting outside the DMZ), using the Edge Server FQDN/Public IP address.
2

The Client contacts the Edge Server.

a. The inSync Master maintains a persistent connection with the Edge server.

b.  If the authentication is successful, the Edge Server creates the communication tunnel between the inSync Client and the inSync Storage Node. This tunnel is SSL-encrypted.

Data Workflow for Backup & Restore

The following table explains the data flow required to activate the Client:

Step Description
1 The inSync Master receives the backup or restore request from the inSync Client over a secure tunnel. The inSync Master then redirects the inSync Client to the appropriate inSync Storage Node. During this redirection, the inSync Master sends an encrypted token to the inSync Client. This encrypted token is used for the authentication of the inSync Client with the inSync Storage Node.
2

The inSync client sends the request to the inSync Edge Server that is configured for the inSync Storage Node with which the inSync client wants to communicate.
The security mechanism in place for this stage is as follows:
a. The inSync client initiates an SSL connection with the Edge Server.
b. The Edge Server performs the parameter validation.
c. The Edge Server forwards the inSync client authentication request to the inSync Storage Node to validate the encrypted token received from the inSync Master in step 3.
d. If the authentication is successful, the Edge Server creates the communication tunnel between the inSync Client and the inSync Storage Node. This tunnel is SSL-encrypted.

If the authentication failed, the connection is closed.

Data flow for Web traffic

The following example explains the data flow of web traffic and contains following components:

Component Description
inSync Master FQDN Master.druva.com
Edge Server FQDN Edge.druva.com
Storage Node FQDN storage.druva.com
User Web Access URL Master.druva.com/home

The following table explains how to setup a connection between Client and Web console:

Step Description
1

When the Client clicks on Web, It is directed to the User Web Access URL i.e. Master.Druva.com/home.

If the client is present outside the DMZ, this connection would fail and hence the Web console will not open. To ensure the connection does not fail, configure the following:

  • Master.druva.com should resolve to Public IP of the Edge Server (For connections outside the DMZ).
  • Master.druva.com should resolve to Internal IP of the inSync Master (For connections within the network).

The following table explains the data flow to download files from the Web:

Step Description
1

On the Web Console click Download. The request is sent to the Storage Node and the CLient tries to connect to the Storage Node. For the connection to work ensure the following:

  • Use a FQDN instead of IP address.
  • Storage Node FQDN should resolve to Public IP of the Edge (For connections outside the DMZ).
  • Storage Node FQDN should resolve to Internal IP of the Node. (For connections within the network).

Edge Server for inSync Share

After you have Edge Server configured in your inSync Private Cloud deployment, the Edge Server lets you access all features of inSync Share. You can install and activate the inSync client, back up and restore data by using the inSync client or inSync Web, launch inSync Web from the inSync client, create and share links with others, and so on.

The advantages of configuring the Edge Server for inSync Share include:

  • Access to inSync functionalities, even if you are on a public network and do not have VPN access.
  • Access to inSync functionalities, even if you are on an enterprise private network that is on a geographically different site.

The inSync Edge Server is located in a demilitarized zone (DMZ) outside the organization's firewall, and acts as a gateway to the public internet. The DMZ has only one port available for incoming connections. The enterprise private network has only one port available for outgoing connections in their firewall. The Edge Server addresses all the requests from port 443, such as the client Remote Procedure Call (RPC) traffic and browser HTTP traffic. 

Edge Server deployment scenarios

You can have any of the following Edge Server deployment scenarios in your inSync Private Cloud environment.

Deployment scenario Implementation

Single Master Server and Storage Node on the same machine.

Requires only one Edge Server.

Master Server and multiple remote Storage Nodes. All in the same geographical location.

Requires only one Edge Server.

Master Server and multiple remote Storage Nodes that are in different geographical locations.

Requires one Edge Server per network if you want the remote Storage Nodes to be accessible from all the networks.

How the Edge Server resolves IP addresses

This section provides an example to help you understand how the Edge Server resolves IP addresses for the inSync Server and the inSync Storage Node. Consider the following scenario for an inSync Private Cloud deployment.

edge_server_resolve_IPs.png

The scenario illustrated in the diagram involves the following components:

Component Description

Master

The inSync Server that contains the configuration server, sync server, and inSync Master Management Console

Storage Node 1

The server that contains the Storage Node server and web restore server for remote storage 1.

Storage Node 2

The server that runs Storage Node server and web restore server for remote storage 2.

Edge Server 1

The Edge Server that serves the Master Server and Storage Node 1, which is connected to the Edge Server.

Edge Server 2

The Edge Server that serves Storage Node 2, which is connected to the Edge Server. 

In this deployment scenario, the Edge Server resolves the configured IP/FQDN setting as follows:

Host IP resolved in private network IP resolved in public network

master.example.com

198.51.100.101

203.0.113.2

node1.example.com

198.51.100.102

203.0.113.2

node2.example.com

198.51.100.103

203.0.113.3

For more information about the authentication workflow of Edge Server, see Edge Server FAQs.

Disclaimer:

  • You can enter the  User Web Access URL as Public IP of Edge as well.

However, the drawback would be that the internal clients would also be able to connect to the particular URL to access the Web console.

  • In order to download files from the Web, you need to have a FQDN for the Storage Node or a Public IP of the Node (which defeats the purpose of the Edge Server). Having an Internal IP will not help as the download would fail. 
  • Was this article helpful?