Document Version	01
Released on	Jul. 29, 2024

Copyright © Sangfor Technologies 2024. All rights reserved.

Unless otherwise stated or authorized, Sangfor Technologies (hereinafter referred to as "Sangfor") and its affiliates reserve all intellectual property rights, including but not limited to copyrights, trademarks, patents, and trade secrets, and related rights to text, images, pictures, photographs, audio, videos, charts, colors, and layouts as presented in or concerning this document and content therein. Without prior written consent of Sangfor, this document and content therein must not be reproduced, forwarded, adapted, modified or displayed or distributed by any other means for any purpose.

Disclaimer

Products, services or features described in this document, whether wholly or in part, may be not within your purchase scope or usage scope. The products, services or features you purchase must be subject to the commercial contract and terms as agreed by you and Sangfor. Unless otherwise provided in the contract, Sangfor disclaims warranties of any kind, either express or implied, for the content of this document.

Due to product version upgrades or other reasons, the content of this document will be updated from time to time. Unless otherwise agreed, this document is used for reference only, and all statements, information, and recommendations therein do not constitute any express or implied warranties

Technical Support

For technical support, please visit: https://www.sangfor.com/en/about- us/contact-us/technical-support

Send information about errors or any product related problem to tech.support@sangfor.com.

About This Document

This document describes the architecture, features, installation, and O&M management of Network Secure.

Intended Audience

This document is intended for:

Network design engineers
O&M personnel

Note Icons

English Icon				Description
				Indicates an imminently hazardous situation which, if not avoided, will result in death or serious injury.

				Indicates a potentially hazardous situation which, if not avoided, could result in death or serious injury.
				Indicates a hazardous situation, which if not avoided, could result in minor or moderate injury.
				Indicates a hazardous situation, which if not avoided, could result in settings failing to take effect, equipment damage, or data loss. NOTICE addresses practices not related to personal injury.

				Calls attention to important information, best practices, and tips. NOTE addresses information not related to personal injury or equipment damage.

Contents

Preparations 6
Upgrade Procedure 15
Client Download Methods 40
1. Local Download 40
2. CDN-Based Download 40
  1. Sangfor Cloud 41
  2. Self-Owned CDN Server 41
Rollback Solutions 42
1. Rollback of SPs and Custom Packages 42
2. Rollback in Virtual Deployment Environment 43

Preparations

Clarify Upgrade Goals

Before the upgrade, clarify the upgrade goals.

For example, the customer hopes to upgrade the system to V2.2.16 or later by using a custom package, or upgrade the system to V2.4.10.

For example, the customer hopes that the upgrade can be performed during complete business interruptions, the upgrade has minimal impact on businesses, specific features are available after the upgrade, or specific issues are eliminated after the upgrade.

Perform the upgrade based on customer goals and expectations. After the upgrade is completed, perform business verification based on the goals to ensure that the upgrade can successfully meet customer requirements.

Precautions

Enable Gray Client Upgrade

In V2.4.10, significant optimizations are made to the aTrust client. Specifically, client localization is achieved, and the loading time of a link in Workspace is reduced to less than 3 seconds, which significantly enhances product competitiveness and user satisfaction. These optimizations provide the following benefits:
1. Improve the performance of persistent connections and short-lived connections across all endpoints (including Windows, macOS, and Linux endpoints).
2. Optimize the visual interface of the PC client, and improve the startup speed.
3. Allow access to C/S applications from the macOS or Ubuntu workspace.
4. Achieve a download speed approximate to the native Internet speed for tunnel resources.
5. Fix existing client issues, and improves compatibility and stability.
If the aTrust server such as the Manager, Proxy Gateway, or Integrated Gateway is upgraded to V2.4.10, the corresponding aTrust clients on all endpoints must also be upgraded to V2.4.10 or later. Otherwise, the endpoint user may fail to log in to aTrust to access business resources. To be specific, the following impacts may be caused:
1. When a user attempts to access the aTrust address from an endpoint whose client version is earlier than V2.4.10, a message appears to prompt the endpoint user to forcibly upgrade the client to V2.4.10.
2. If the endpoint user does not upgrade the client to V2.4.10 or later, the user cannot perform authentication or access resources.
After the aTrust server is upgraded, the aTrust clients also need to be upgraded. If the customer has a low network throughput or high concurrency, to download clients from the aTrust console may result in network congestion and performance degradation. In this case, the gray client upgrade feature needs to be enabled ( to control the client download concurrency) or a CDN needs to be used, so as to reduce the workload and network throughput of the aTrust device and ensure business continuity. Specifically, CDN-based methods include Sangfor Cloud (public network) and the self-owned CDN server (in the customer intranet). For more information, see Section 3.2 in this document.
As described in the second point above, before you upgrade the aTrust device to V2.4.10 or later, first upgrade the client as instructed below. Otherwise, the aTrust device may fail to be upgraded or customer businesses may be affected.
1. Trial upgrade phase: Send the update package to an endpoint user to perform a trial upgrade. The purpose is to check whether the issues of the original version are successfully resolved after the upgrade and whether compatibility issues exist especially when the client has installed security software.
2. Gray upgrade phase: Before the upgrade, log in to the Manager (or Integrated Gateway) console, and go to System > Upgrade > System Upgrade to upgrade clients to V2.4.10 based on the update package. To obtain the update package, contact Sangfor technical support for help.

Download the V2.4.10 update package to the local computer in advance.
Update packages for Windows, macOS, Ubuntu, and VDI are provided. Download the update package based on your actual business environment.

Steps

Step 1. Log in to the Manager console, go to System > System Maintenance >

Gray Client Upgrade, and click Edit next to Grayscale Upgrade Policy on the Windows Clients, macOS Clients, and UOS/Kylin/Ubuntu Clients tabs as needed. In the dialog box that appears, select Enable for Grayscale Upgrade, and configure Upgrade Rule and Conversion Conditions to gradually roll out the beta version to more users.

Upgrade Rule: It is recommended to randomly remind 500 earlier-version clients each day to upgrade to the beta version.
Conversion Conditions: Set this parameter based on your actual requirements. It is recommended that when more than 50% of total clients have been upgraded to the beta version, the beta version can be converted to the stable version.

Step 2. Log in to the Manager console, go to Management > Policies > Global Policies > Client Options, and select Download/Update client via third-party platform, as shown in the following figure. We recommend that you select all check boxes for Applicable OS and Sangfor Cloud for Download/Update Address. Alternatively, you can make selections based on your actual requirements.

Step 3. If a high percentage (such as 60%) of endpoints are upgraded to the beta version, the purpose of the gray client upgrade is achieved. Then, disable the gray client upgrade to convert the beta version to the stable version.

Formal release phase: Convert V2.4.10 from the beta version to the stable version, so that the version is available for all users. To do this, go to System > System Maintenance > Gray Client Upgrade, and select Disable for Grayscale Upgrade, as shown in the following figure.

Disable the gray client upgrade feature on the Windows Clients, macOS Clients, and

UOS/Kylin/Ubuntu Clients tabs one by one.

Forcible upgrade phase: Enable forcible upgrade to ensure that all clients are upgraded to V2.4.10. Otherwise, after the server is upgraded to V2.4.10, endpoint users whose client versions are earlier than V2.4.10 may fail to log in. To enable this feature, go to Management > Policies > Global Policies > Client Options, and select Force upgrade to the latest client version, as shown in the following figure.

During the server upgrade, the system checks the number of endpoints whose clients have been upgraded to V2.4.10 in the last two weeks. If the endpoint count is less than 100, more client upgrades are allowed. If the endpoint count is more than 100, more client upgrades are not allowed (if the client upgrade is blocked due to this reason but the upgrade does not cause risks, contact Sangfor technical support for help).

Install SPs for aTrust Server V2.2.16 (Optional)

During aTrust server upgrade, there will occur Chinese captcha, as shown in below diagram. You can ignore that and continue to upgrade. However, if you want to fix it, it requires to install SP package firstly before upgrade aTrust server.

$C:\Users\Sangfor\Documents\WXWork\1688854308415341\Cache\Image\2024-07\企业微信截图_17211884791198.png$

$C:\Users\Sangfor\Documents\WXWork\1688854308415341\Cache\Image\2024-07\企业微信截图_17211902031164.png$

Check the Distributed Cluster Module License

In V2.4.10, the distributed cluster module uses a module-level license.

If the distributed cluster feature in System > Advanced Features in the Manager console is enabled, the distributed cluster module is automatically licensed after the aTrust server is upgraded to V2.4.10.

If the distributed cluster feature in System > Advanced Features in the Manager console is disabled, the distributed cluster module is unlicensed after the aTrust server is upgraded to V2.4.10.

To combine multiple aTrust devices into a distributed cluster, make sure that the distributed cluster modules on these devices are all licensed. Otherwise, the cluster fails to be created.

Perform Environment Checks

Before the upgrade, check and record the environment information of each aTrust device to be upgraded. The information includes but is not limited to the following items:

The app version of the aTrust device.
Whether the device belongs to a cluster (local cluster or distributed cluster).
The IP address of the aTrust device. This helps determine the device upgrade sequence.
The super admin account and password of the aTrust device. The information will be used during the upgrade.
The upgrade network environment of the customer. Specifically, check whether the customer needs to perform an on-site upgrade or a remote upgrade. The on-site upgrade is recommended for a complex scenario, such as a scenario in which the cluster mode is used or more than four aTrust devices are deployed.
The update package information and its corresponding MD5 value. Download the update package to the local computer in advance to ensure that the correct package is applied during the upgrade.

In addition, check whether the disk size of the virtual machine meets the deployment requirements.

Concurrent Users/Licenses	Recommended Disk Size for a Single Device
1-20,000	500 GB
20,000-600,000	1 TB
More than 600,000	1.5 TB

If the aTrust device is deployed in a virtual platform such as VMWare or Hyper-Converged Infrastructure (HCI), make sure that a multi-queue NIC is configured. In other words, make sure that the performance optimization tool of the virtual platform is installed.

In this guide, the following IP addresses are used as examples for description:

Manager

Cluster IP address: 10.243.3.100

IP address of the master node in the cluster: 10.243.3.71 IP address of the slave node in the cluster: 10.243.3.70

Proxy Gateway

Cluster IP address: 10.243.3.101

IP address of the master node in the cluster: 10.243.3.83 IP address of the slave node in the cluster: 10.243.3.84

Make Pre-Upgrade Preparations

To upgrade a device deployed in a virtual environment, create a snapshot for the virtual environment before the upgrade, so as to restore the environment in case of an upgrade failure.
Make sure that the performance optimization tool of the virtual environment is installed before the upgrade.

Download Update Packages

Obtain the update package from the Sangfor cloud driver or Sangfor Community (https://community.sangfor.com).

Take note of the following items before the download:

The default update package applies only to Windows and macOS clients. The update packages for Ubuntu and VDI clients need to be downloaded separately.
The update package name for Ubuntu clients is UbuntuClient.
The update package name for VDI clients is VDIClient.

Before the upgrade, make sure that all necessary packages such as the update package, SP, and custom package are downloaded and their corresponding MD5 values are correct. We recommend that you record all package names, MD5 values, and download URLs to prevent package omission or error.

Determine the Upgrade Method

For aTrust V2.2.16 or later, upgrade the aTrust device in the frontend web console. To be specific, log in to the console, go to System > Upgrade > System Upgrade, and perform the upgrade by using the *.bin package.

Pre-Upload the Update Package (Optional)

The pre-upload of the update package can significantly reduce the upgrade duration without affecting business continuity. We recommend that you upload the update package to the device console in advance.

To do this, log in to the device console, and go to System > Upgrade > System Upgrade

to import the update package in advance.

Upgrade Procedure

Overview

Before the upgrade, determine the upgrade solution. Specifically, the solution consists of the following procedure:

Step 1. Before you upgrade the aTrust server to V2.4.10, first upgrade the aTrust client. Make sure that clients on all endpoints are upgraded to V2.4.10 or less than 100 active endpoint users have used clients of an earlier version in the last 14 days.

Step 2. After all clients are upgraded, upgrade the server. For details, see Sections 2.4 to 2.6.

Replace the IP addresses involved in this guide with actual IP addresses.

Example Upgrade Solution

In this example, two Managers (Manager 1 and Manager 2) in a local cluster and two Proxy Gateways (Proxy Gateway 1 and Proxy Gateway 2) in another local cluster are to be upgraded.

Steps

Remove the slave node Manager 2 from the cluster.
Remove the slave node Proxy Gateway 2 from the cluster.
Upgrade Manager 2 and Proxy Gateway 2, and install SPs and custom packages (if necessary) for the two devices. After the devices are upgraded, perform health checks on the devices to ensure that the devices can normally operate.
Integrate Proxy Gateway 2 with Manager 2. Then, log in to Manager 2 and access applications, to verify whether businesses can normally operate. After the verification, separate Proxy Gateway 2 from Manager 2. At this point, two of the four devices are

successfully upgraded and verified.

Disband the clusters that contain Manager 1 and Proxy Gateway 1. As a result, business operations are interrupted. Then, use Proxy Gateway 2 and Manager 2 to create two single-node clusters based on the settings of the disbanded clusters. Subsequently, add the cluster that contains Proxy Gateway 2 to the cluster that contains Manager 2. As a result, business operations resume.
Upgrade Manager 1 and Proxy Gateway 1 in the same way as Manager 2 and Proxy Gateway 2. After Manager 1 and Proxy Gateway 1 are upgraded, add them as slave nodes to the clusters that contain Manager 2 and Proxy Gateway 2.
Check the app version information of the four devices to ensure that all devices are properly upgraded without omissions or errors.
Perform health checks on the four devices to ensure that the devices are fully upgraded without failed items. For help, contact Sangfor technical support representatives.
Perform an overall business verification to ensure that the clients are successfully updated, users can successfully log in, core applications can be successfully accessed, and SPs and custom packages can function normally.

The example solution is for reference only. Perform upgrades based on the actual environments and requirements.

Back Up Device Configurations

Create a device backup to restore the device in case of an upgrade failure. Specifically:

If the aTrust device is deployed in a virtual environment, create a snapshot for the device before the upgrade.
If the upgrade process involves cluster splitting, take screenshots of cluster settings before the upgrade, including local cluster settings and distributed cluster settings.
If virtual IP addresses are used, take screenshots of the virtual IP address settings before the upgrade.
If the Proxy Gateway needs to be removed and then added during the upgrade process, take screenshots of the access address settings of the region where the Proxy Gateway resides.

Upgrade aTrust Client (About 1.5 Hour)

aTrust client installation does not affect the business continuity of the aTrust device. During the installation, only read and write operations performed by administrators in the console are affected. Therefore, in the aTrust client installation process, the nodes in the Manager cluster can be concurrently upgraded without cluster splitting.

Update aTrust Client Package in Manager

Steps

Before the upgrade, create a snapshot for the device on the virtual platform so that the aTrust can be rolled back to the original version in case of an upgrade failure.
Download the V2.4.10 update package in the BIN format to the local computer in advance based on the actual environment. The following update packages are provided:

Update package for Windows and macOS clients
Update package for Ubuntu clients
Update package for VDI clients

For more information about how to obtain the update package, see Section 1.5.

Upload the update package to the device through the web console during off-peak hours. In the following example, the update package is uploaded only without instantly starting the upgrade process.

Specifically:

Log in to the Manager console as an administrator, go to System > Upgrade > System Upgrade, and click Import update package to import the update package to the device.
After

the update package is imported, click Upgrade Later to upgrade the device later in a proper time window. If you click Upgrade Now, the upgrade process starts instantly.

During the proper time window, go to System > Upgrade > System Upgrade, and click

Upgrade Now.

Wait for the upgrade environment check to complete. During the environment check,

you can click View Logs in the Operations column on the right to view the progress. If the environment checking fails, a message is prompted to indicate the specific item that causes the check failure. Then, make modifications based on the prompted message to ensure that the environment check succeeds.

We recommend that you create a aTrust snapshot firstly on the virtual platform before the upgrade.

Click Confirm. The configuration backup and upgrade process starts. The entire process takes about 30 minutes to 60 minutes, depending on the aTrust performance. After the upgrade is completed, the device automatically exits the O&M mode.

During the upgrade, do not switch to other pages. After the upgrade is completed, click

Details to check whether the upgrade is successful.

Go to Management > Policies > Global Policies > Client Options, and select Download/Update client via third-party platform. Then, select Windows, macOS, UOS/Kylin, and Ubuntu for Applicable OS and Sangfor Cloud for Download/Update Address. Make sure that Sangfor Cloud is selected to prevent device operation interruptions caused due to excessively large bandwidth consumption during the upgrade.

Enable Gray Client Upgrade

Background

The upgrade from V2.2.16 to V2.4.10 is special. To be specific, the server upgrade can be started only after most of the clients are upgraded to V2.4.10. If the server is firstly upgraded, the clients on all endpoints can function normally only after they are all upgraded to V2.4.10.
If a large number of endpoints exist (for example, more than 1,000 endpoints exist), it is advised to enable the gray client upgrade feature before upgrading aTrust server due to the following reasons:
- aTrust sends prompts to all online clients of earlier versions, to prompt the clients to be upgraded to V2.4.10. Consequently, traffic congestion occurs due to a large number of concurrent client downloads, and severe impacts are caused to business operations.
- After the gray client upgrade feature is enabled, clients are downloaded and upgraded in different phases. This helps effectively limit the impact scope.

Steps

Log in to the console of the Manager cluster as an administrator, go to System > System Maintenance > Gray Client Upgrade, and click Edit next to Grayscale Upgrade Policy. In the dialog box that appears, select Enable for Grayscale Upgrade, and configure Upgrade Rule and Conversion Conditions based on requirements.

After the upgrade is completed, log in to the console again. Go to System > System Maintenance > Gray Client Upgrade, and check whether the beta version under Client Version is V2.4.10.

Server Upgrade

Upgrade Cluster Slave Nodes

The entire process takes about 1.5 hours.

We recommend that you upgrade slave nodes in clusters in single-node cluster mode to minimize business impacts. Make sure that a screenshot is captured for each upgrade step

and all involved IP addresses are replaced by actual IP addresses, to prevent mis- operations during the upgrade.

Upgrade the Manager

For major customers, pay special attention to the following items:

Capture a screenshot for each upgrade step to prevent misoperations.
Perform the upgrade in strict accordance with the upgrade procedure. Otherwise, businesses may be affected.
Install update packages in the following sequence: Server update package -> Client update package -> SPs and custom packages (the packaging sequence of custom packages must be in strict accordance with the custom package documentation).

Before the server upgrade, first upgrade the aTrust client. It is advised to start the server upgrade when more than 90% of the clients on all endpoints are successfully upgraded.

The following content describes how to upgrade the server.

In the following content, the upgrade of the Manager is used as an example for description. The upgrade procedures of the Integrated Gateway and Proxy Gateway are the same as that of the Manager, and details are not elaborated herein.
aTrust devices in separate deployment (that is, Manager and Proxy Gateway) can be upgraded without the need to be disconnected from each other.
During the server upgrade, the server update package can be uploaded in advance without performing the upgrade instantly. You can proceed to upgrade the server during off-peak hours.

Steps

The Managers and Proxy Gateways are in cluster mode. Therefore, the slave nodes in the clusters need to be upgraded first, so that the master nodes can still provide services to ensure business continuity.

Log in to the Manager console as an upgrade operator, and go to System > Cluster Management > Local Cluster. Find the Manager that serves as the slave node, click

Operation, and select Delete to remove the slave node from the cluster.

After being removed from the cluster, the slave node no longer carries business traffic of the cluster and does not affect the service capabilities of the cluster. In other words, the cluster (IP address: 10.243.3.100) can normally operate and still provide services.

Check whether only the master node still provides services. The slave node does not provide services, as shown in the following figure.

Log in to the console of the Manager (IP address: 10.243.3.70) that serves as the slave node, go to System > Upgrade > System Upgrade, and click Import update package to upload the V2.4.10 update package to the slave node device.
After the update package is successfully uploaded, click Upgrade Later to start the upgrade at a proper time window. If you click Upgrade Now, the upgrade starts instantly.

During the proper time window, go to System > Upgrade > System Upgrade, and click

Upgrade Now.

Wait for the upgrade environment check to complete. During the environment check, you can click View Logs in the Operations column on the right to view the progress. If the environment check fails, a message is prompted to indicate the specific item that causes the check failure. Then, make modifications based on the prompted message to ensure that the environment check succeeds.

Click Confirm. Then, the configuration backup and upgrade process starts. The entire process takes about 30 minutes to 60 minutes, depending on the device performance. After the upgrade is completed, the device automatically exits the O&M mode.
During the upgrade, do not switch to other pages. After the upgrade is completed, click

Details to check whether the upgrade is successful.

After the upgrade, click Details to view the details of the current version and check whether the upgrade meets the requirements.

Perform Health Checks on the Manager

After the upgrade is completed, perform a health check on the device in strict accordance with the following steps to ensure that the device is healthy after the upgrade.

Steps

Enter https://10.243.3.70:4433 in the address bar of the browser to check whether you can successfully log in to the Manager console. Then, go to System > Upgrade > System Upgrade, and click Details to check whether the upgrade meets the requirements.
Go to System > System Maintenance > Health Check > System Health Check to perform a standard check.

After the standard check, go to System > System Maintenance > Web Console, and run the atrust_tool health command to view the health check result.

Upgrade the Proxy Gateway and Perform Health Checks

The upgrade and health check procedures of the Proxy Gateway are the same as those of the Manager.

Follow the upgrade procedure described in Section 2.3.1 to upgrade the Proxy Gateway (IP address: 10.243.3.84) that serves as the slave node. Details are not elaborated herein.

Perform Business Verification

Overview

To this point, the Manager and Proxy Gateway that serve as slave nodes are upgraded. Then, business verification needs to be performed on the two devices to verify whether business resources on the devices can be normally accessed after the upgrade.

Steps:

Integrate the upgraded Manager (IP address: 10.243.3.70) and Proxy Gateway (IP address: 10.243.3.84).
Log in to the Manager (https://10.243.3.70) over the intranet, and attempt to access core businesses, to check whether businesses can normally operate.

Integrate the Manager with Proxy Gateway

Perform the following steps to integrate the Manager with Proxy Gateway. Take note that relevant IP addresses must be replaced by actual IP addresses, and a screenshot must be provided for each step.

Steps

Log in to the Manager (IP address: 10.243.3.70) console as an administrator, go to System > Proxy Gateways > Gateways, and click Key Settings. In the dialog box that appears, click View Key.

Log in to the Proxy Gateway (IP address: 10.243.3.84) console as an administrator, go to System > Device Management, and click Add to Manager. In the dialog box that appears, set Key to the key that is obtained in Step 1, and click OK.

Log in to the Manager console again, and activate the Proxy Gateway to complete the

integration.

Access Businesses

Steps

Enter https://10.243.3.70 (replace this IP address with your actual IP address) in the address bar of the browser. In the login page that appears, enter the username and password, and click Log In to go to the Workspace.
Attempt to access core businesses to ensure that businesses can normally operate after the upgrade. It is advised that customers verify business operations in their actual business environments.

Separate the Proxy Gateway from the Manager

After the health check and business verification, separate the Proxy Gateway (IP address: 10.243.3.84) from the Manager (IP address: 10.243.3.70).

Specifically, log in to the Proxy Gateway (IP address: 10.243.3.84) console, and go to System > Device Management to separate the Proxy Gateway from the Manager (IP address: 10.243.3.70).

Upgrade Cluster Master Nodes

The entire process takes about 1 hour with businesses affected for about 5 minutes.

Procedure Introduction

Till now, the slave nodes (IP addresses: 10.243.3.70 and 10.243.3.84) are upgraded to V2.4.10 and can normally provide services. Then, the master nodes in the clusters need to be upgraded.

The general procedure is as follows:

Disband the clusters. After the clusters are disbanded, the aTrust devices that serve as master nodes (IP addresses: 10.243.3.71 and 10.243.3.83) do not provide services, and businesses are interrupted.
Use the upgraded Manager (IP address: 10.243.3.70) and Proxy Gateway (IP address: 10.243.3.84) to create two single-node clusters, and integrate the clusters so that they

can collaboratively provide services. Make sure that the IP addresses of the single-node clusters are the same as those of the disbanded clusters.

Upgrade the Manager (IP address: 10.243.3.71) and Proxy Gateway (IP address: 10.243.3.83) that serve as the master nodes.

In the entire process, businesses are interrupted for about 15 minutes.

Perform Business Verification

According to Section 2.5.1, it can be learned that after the original clusters are disbanded, the IP addresses of the disbanded clusters are vacant and can be allocated to new clusters to provide services. Before the master nodes in the disbanded clusters are upgraded, perform the following steps:

Use the upgraded Manager (IP address: 10.243.3.70) and Proxy Gateway (IP address: 10.243.3.84) to create two single-node clusters whose IP addresses are the same as those of the disbanded clusters. Then, integrate the clusters.
Perform business verification on the integrated clusters, including health checks and business access verification.

The following content describes the detailed steps:

Log in to the console of the Manager that originally servers as the master node (https://10.243.3.71:4433), and go to System > Cluster Management > Local Cluster. Find the master node, click Operation, and select Disband Cluster. Similarly, disband the cluster containing the Proxy Gateway that originally serves as the master node in the same way.

After the clusters are disbanded, all users cannot connect to the aTrust devices to access resources.

Log in to the console of the upgraded Manager (https://10.243.3.70:4433), go to

System > Cluster Management > Local Cluster, and click Enable Cluster. On the page that appears, click Configure Cluster Link.

On the page that appears, select a heartbeat link and an interface IP address, and specify the cluster address (10.243.3.100) and the netmask. Then, click Detect Link.

After the link detection, click OK. A single-node cluster is created.

Repeat Steps 2 to 4 to create a single-node cluster based on the upgraded Proxy Gateway (IP address: 10.243.3.84). The IP address of the single-node cluster is 10.243.3.101.
After the two single-node clusters are created, integrate the clusters. Then, business operations resume, and all users can continue to access businesses after logins. To

this step, all aTrust servers are upgraded to V2.4.10. In this case, the clients whose versions are earlier than V2.4.10 cannot connect to the upgraded aTrust servers, and must be forcibly upgraded to V2.4.10. For more information, see Section 1.2.

Log in to the Manager (through the cluster IP address 10.243.3.100) and Proxy Gateway (through the cluster IP address 10.243.3.101), go to System > System Maintenance > Web Console > Web Console, and run the atrust_tool health command to perform health checks, to ensure that businesses can normally operate.

Check whether the health check result contains a failed item. If there is a failed item, contact Sangfor technical support for help.

Verify whether businesses in the two new clusters can normally operate. Specifically, log in to the clusters as a core user, and verify whether proxy services are normal.

Upgrade the Manager and Proxy Gateway

After ensuring that new clusters can continue to provide services, upgrade the Manager (IP address: 10.243.3.71) and Proxy Gateway (IP address: 10.243.3.83) that originally serve as the master nodes. For the upgrade steps, see Sections 2.4.1 to 2.4.3. Details are not elaborated herein.

Restore Clusters

Restore the Manager Cluster

At this point, the IP address of the master node in the new Manager cluster is 10.243.3.70, and the IP address of the new Manager cluster is 10.243.3.100. In addition, the Manger whose IP address is 10.243.3.71 has also been upgraded to V2.4.10. Therefore, the next step is to add the Manager whose IP address is 10.243.3.71 to the new Manager cluster.

To do this, perform the following steps:

Log in to the console of the new Manager cluster (https://10.243.3.100:4433) as an administrator through the browser, go to System > Cluster Management > Local Cluster, and click Add Node.

In the Add Node dialog box that appears, select Slave Node, set Management Interface IP to 10.243.3.71, enter the administrator username and password, and then click OK.

Click Configure Cluster Link to go to the cluster link configuration page. On this page, configure the IP addresses of the heartbeat link and distributed link, and click OK.

Wait for the cluster synchronization to complete. After the synchronization is completed,

the Manager whose IP address is 10.243.3.71 is successfully added to the new Manager cluster.

View the result, as shown in the following figure.

Businesses are not affected during the process of adding the Manager whose IP address is 10.243.3.71 to the cluster.

Restore the Proxy Gateway Cluster

At this point, the IP address of the master node in the new Proxy Gateway cluster is 10.243.3.84, and the IP address of the new Proxy Gateway cluster is 10.243.3.101. In addition, the Proxy Gateway whose IP address is 10.243.3.83 has also been upgraded to V2.4.10. Therefore, the next step is to add the Proxy Gateway whose IP address is 10.243.3.83 to the new Proxy Gateway cluster.

For more information about the detailed steps, refer to Section 2.6.1.

Perform Overall Business Verification

After all upgrade operations are completed, perform overall business verification on the devices. Specifically:

Check whether all devices are upgraded to V2.4.10, including the major versions, SPs, and custom packages. In other words, make sure that devices of the same type have the same app version information.
Check whether the upgrade goals in Section 1.1 are achieved.
Log in to the console of each device, and perform a health check on each device as instructed in Section 2.4.2 to ensure that the device can normally operate.
Invite several typical users to upgrade their clients to V2.4.10 and then access businesses, to test whether the clients can be successfully upgraded and businesses

can be normally accessed.

Check Device Versions

After the devices are upgraded, check the device version information.

Specifically, log in to the console of each device as an administrator, and go to System >

Upgrade > System Upgrade to view the version information.

Alternatively, move the pointer over the version icon in the upper-left corner to view the version information.

Perform Business Verification

After the aTrust devices are upgraded, log in to the console of each device, go to System > System Maintenance > Web Console > Web Console, and run the atrust_tool health command. Then, view the command result to check whether a failed item or alert information exists. If a key process failure or alert exists, contact Sangfor technical support for help.

Business verification can be performed after the aTrust devices are upgraded. If the Manager and Proxy Gateway are in separate deployment, make sure that they are integrated.

Various methods can be used to perform business verification. The most commonly used method is to access applications directly. Specifically:

Log in to the aTrust device as an O&M administrator or user to check whether the authentication server of the device can normally operate.
After the login, access a web application to check whether web traffic can be normally forwarded on the device.
After the login, access a tunnel application to check whether the tunnel connections and traffic forwarding on the device are normal.

In a remote login scenario, business verification needs to be performed even if the user remotely logs in from the Internet. The verification methods described above also apply to this scenario.
It is assumed that the virtual IP address pool is enabled for the Manager, and the Proxy Gateway is separated from the Manager during the upgrade process. In this case, when the Proxy Gateway is added to the cluster where the Manager resides again, the Manager needs to enable the virtual IP address pool again.

Client Download Methods

Clients can be downloaded in two manners: local download and CDN-based download.

The local download is to download the client from the Manager console. The CDN-based download is to download the client through a CDN, that is, Sangfor Cloud or a self-owned CDN server in the customer intranet.

Local Download

In this scenario, it is advised to enable the gray client upgrade feature to prevent the device from being overloaded due to high download concurrency.

Steps

Enter the access address (for example, https://10.243.3.100) in the address bar of the browser. On the Download page, click the specific client type to download the client.

CDN-Based Download

If a large number of endpoints exist and a large number of clients need to be downloaded and upgraded, it is advised to download and upgrade the clients through a CDN.

Specifically, two CDN-based download methods are provided. The first method is to

download and upgrade clients through Sangfor Cloud. The other method is to download and upgrade clients through a self-owned CDN server in the customer intranet. The latter method applies to scenarios in which the customer accesses aTrust only in the intranet and cannot connect to the Internet.

Sangfor Cloud

Step

Log in to the master node of the Manager cluster as an administrator, go to Management > Policies > Global Policies > Client Options, select Download/Update client via third- party platform, and set Download/Update Address to Sangfor Cloud, as shown in the following figure.

In this case, the user needs to make sure that the endpoints where the clients are installed can communicate with Sangfor Cloud.

Self-Owned CDN Server

The customer can access aTrust only in the intranet but cannot connect to the Internet. In addition, the customer needs to update a large number of clients, for example, more than 1,000 clients. In this case, the customer needs to build a CDN for client downloads in the intranet.

Step

Log in to the master node of the Manager cluster as an administrator, go to Management >

Policies > Global Policies > Client Options, select Download/Update client via third- party platform, and set Download/Update Address to Self-owned platform, as shown in the following figure.

In this scenario, the customer needs to ensure that the endpoints where the clients are installed can communicate with the self-owned CDN server.

Rollback Solutions

Rollback of SPs and Custom Packages

Steps

Log in to the console of the aTrust device as an administrator to enable the SSH O&M interface. Then, use the SSH tool to log in to the device backend through the quickstart account. The default password is sangforquickstart. If the default password is invalid, use the new password with format of admin password suffixed with @sdp.
Run the atrust_uctl rollback command.
Enter the password of the quickstart account, specify the sequence numbers of the SPs or custom packages to be rolled back, and press the Enter key.

Rollback rule: SPs or custom packages are rolled back in reverse chronological order based on the time when the SP or custom package is installed. The SPs or custom packages that are installed later will be

rolled back first.

For example, SP 1 is first installed. Then, SP 2 is installed. Finally, SP 3 is installed. In this case, SP 3 is first rolled back, then SP 2, and finally SP 1.

Enter the uppercase letter Y, press the Enter key, and wait for the rollback process to complete.
View the app version information to check whether the SPs or custom packages are rolled back.
Log in to the Manager or Proxy Gateway console, go to System > System Maintenance > Web Console > Web Console, and run the atrust_tool health command to check whether the device can normally provide services. For more information, see Section 2.4.2.

Rollback in Virtual Deployment Environment

If the aTrust device is deployed in a virtual environment, two rollback methods can be used.

Method 1: Restore from the virtual management platform

To upgrade a device deployed in a virtual environment, create a snapshot for the virtual environment on the virtual management platform before the upgrade.
If the device fails to be upgraded, log in to the virtual management platform as an administrator, and go to the snapshot restoration page.
Restore the environment based on the snapshot created before the upgrade.

Method 2: Contact Sangfor technical support

If no snapshot is created on the virtual management platform, contact Sangfor technical support for help.

AF 8.0.47