The proxy servers configured on the management Console are further used to route traffic from/to Agents.
Basically it's used for two traffic flows:
between Agents and Management Console
between Agents in a job
Connection between Agents and Management Console
By default, agents use the first proxy server listed in their configuration to connect to the Management Console (MC). Agents that connect through a different proxy will appear offline in the MC.
To address this configure the Agent to connect to the Management Console through a proxy server, add the following parameter to the Agent's configuration file "mc_proxy": "proxy_address:port" to the Agent's configuration file. This instructs the Agent to attempt establishing a connection to the MC through the specified proxy. If successful, the Agent will communicate with the MC via this indirect route.
If the Agent may also have a direct path to the MC — for example, when a VPN tunnel becomes active, the user is on a corporate LAN, or simply to maintain a uniform configuration across all agents — it is recommended to additionally specify "mc_address": "mc_direct_address:port" to the configuration file.
When this parameter is present, the Agent will try both connection options - direct connection using the mc_address and proxy connection specified in mc_proxy.
If mc_address is not set, the Agent will only try the proxy.
The Agent configuration always includes the block with management_server connectivity settings. The address specified here can be either a direct MC address or a proxy address, and it serves as a fallback connection target. When both mc_address and mc_proxy are present, the Agent will try them first. If both are unavailable, it will attempt to connect using the management_server.host value. Whether this connection is established directly or through a proxy depends on the actual address specified in the host field.
"management_server": {
"host": "address:8444",
"cert_authority_fingerprint": "fc6....d6",
"bootstrap_token": "MDE...GMA",
"disable_cert_check": false
}
Only one proxy server is supported for this connection, and this is going to be the first in the list of configured proxies on the MC. The Agent does not accept two configured proxies and does not switch from one to another if necessary.
The Agent won't automatically switch to a second proxy in the list of configured proxies.
This tunnel will be used for all communication between agents and the Console - jobs configuration, statistics, recourses usage, etc.
For each Agent, connected to MC through Proxy, a new socket is opened on the MC's host.
If the Agent has been connected to MC through proxy over WAN (never was connected directly) and then is moved to LAN, the Agent won't switch to MC's local address automatically. Additional configuration is required in advance to support this scenario:
- Agents should connect to MC via the configuration file.
- In the MC section specify MC's internal IP as "host":"address:port".
- Add a new parameter "mc_proxy":"address:port" in the config and specify public proxy address there.
Connection between Agents in a job
In the Agent profile enable option Use proxy. Make sure that all agents in the job are configured to "Use proxy".
The Agent will be using the proxy servers from MC settings > Auxiliary servers, that were configured in advance. Agents in already configured Synchronization jobs will re-evaluate network settings and will also try a proxy tunnel. Agents in Distribution and Consolidation jobs will probe proxy tunnel on next job run.
Proxy servers, if several are configured, work in ‘load balancing’ mode: agents distribute their requests to proxies for different jobs. High availability of Proxy is not supported.
By default proxy only routes traffic from/to LAN per "subnet" setting in its configuration. WAN to WAN traffic routing shall be enabled using "Advanced settings" above the table on Auxiliary servers tab.
Proxy can route TCP and ZGT protocols only. Be sure to have these enabled in the Agent profile. Otherwise only proxied tunnel will be possible for a non-selected protocol (as was previously mentioned, agents will try direct connection first). This also means - to force agents to connect only through proxy, uncheck all protocols in the Agent profile.
Proxied connection between Agents is technically established withing a single TLS tunnel, not split into two: from Agent to Proxy and then another TLS from Proxy to the other Agent.
Connection between Agents and Proxy is not authenticated.
Proxy connection is reflected in Connectivity map of the Agent. On the example below direct connection to the (external) address discovered by tracker is not available on all protocols, so connection is established through proxy 192.168.56.200.
Note, since proxy is used per whole agent, the map may show all proxy connection, not necessarily related to this particular job.
Proxied connection is not reported in the Agent UI.
Introducing a proxy into the environment will also have its impact on other Resilio Connect functionality, as described below
Proxied connection is also limited by Bandwidth scheduler.
Since real IP addresses of remote agents are hidden behind the proxy, Known hosts parameter in the Agent profile won't work for a proxied tunnel. In order to preserve the functionality, new parameter was introduced - Allowed peers. It accepts only AgentID as value, multiples lines are supported. AgentID can be learned from the Agent details. For this parameter to work, tracker must be enabled and reachable for the agents involved.
Speed test can also be run through a proxy tunnel. For speed test through a proxy tunnel to be successful, corresponding tunnel shall be enabled in the Agent profile. For example, for speed test to run through Proxy_TCP tunnel, TCP tunnel protocol must be checked in selected agents' profiles. Otherwise speed test will give error "Network is unreachable:"