About the inSync Edge Server
Elite 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
> Settings > Network > SERVER IP/FQDN, enter the Internal IP of the inSync Master or the FQDN of the Master. - Under
> Settings > Edge Servers > IP Address/FQDN, provide the FQDN for the Edge server. - The user web access URL should be a FQDN.
- Under > Storage List > Storage Node, enter a FQDN for the Storage Node.
- Under > 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 | inSync 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. |
| 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. |
| 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. 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:
|
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:
|
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.
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 an 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.