Product Introduction

1.1 Product Introduction

1.1.1 Introduction to Private Network

Private network VPC (Virtual Private Cloud) is a logically isolated network environment belonging to users. In a private network, you can create a VPC of a specified network segment, create a subnet in the VPC, and manage cloud resources independently, and at the same time implement security protection through network ACLs. The private network VPC provides users with the following capabilities:

  • User-defined network segment: three types of network segments can be combined freely, and VPC network segments can be increased or decreased at any time
  • Complete network management: gateway NAT, customroute table, network ACL, private VIP, virtual NIC. Users can freely choose and configure these and set rules according to their needs.
  • Subnetcross availability zone: The subnet can cover any availability zone in the region to realize disaster recovery across the availability zone.
  • High scalability: Cross-regional VPCs can be connected through high-speed channels (UDPN) to achieve stable intranet transmission; combined with dedicated line access, a hybrid cloud architecture with single-point access and global interconnectioncan be achieved.

If the business may involve multiple networks, it is recommended to plan the network in advance.

1.1.2 Private network components

The private network includes components such as VPC, subnet, NAT gateway, and network ACL:

  • VPC: VPC is a logically isolated network environment belonging to users. In a private network, you can create a VPC of a specified network segment, create a subnet in the VPC, and manage cloud resources independently.
  • Subnet: In order to divide the address space in the VPC scientifically and effectively, it is divided into more fine-grained network segments. These independent network segments are called Subnets.
  • NAT gateway: The NAT gateway is an enterprise-level VPC public network gateway that allows cloud resources that are not bound to an elastic IP in the subnet to access the publicnetwork, and can also configure port forwarding rules to enable cloud resources to provide public
  • Network ACL: a security policy at the subnet level, used to control the data flow in and out of the subnet. Users can set up outbound rules and inbound rules to accurately control the traffic entering and leaving the subnet.
  • Routetable: The route table is a VPC-level product that can control the network traffic path of cloud resources. A route table is composed of multiple route rules, which are effective for all resources in the subnet through binding with the subnet.

 

1.2 Introduction to VPC and Subnets

1.2.1 VPC

Private network VPC (Virtual Private Cloud) is a logically isolated network environment belonging to users. In a private network, you can create a VPC of a specified network segment, create a subnet in the VPC, and manage cloud resources independently. When creating a VPC, you can independently plan the network segment and flexibly specify the network segment for the VPC. The current range of network segments supported by VPC is as follows:

  • 0.0.0/8 (10.0.0.0-10.255.255.255) mask range: the maximum is /8 mask, and the minimum is /29 mask.
  • 16.0.0/12 (172.16.0.0-172.31.255.255) mask range: the maximum is /12 mask, and the minimum is /29 mask.
  • 168.0.0/16 (192.168.0.0-192.168.255.255) mask range: the maximum is /16 mask, and the minimum is /29 mask.
  • The default VPC does not support newlyadded network segments.

1.2.2 Subnet

In order to divide the address space in the VPC scientifically and effectively, it is divided into more fine-grained network segments. These independent network segments are called Subnets.

Cloud resources in the subnet support cross availability zone deployment, providing a strong guarantee for cross availability zone disaster recovery.

The minimum mask of the subnet segment is /29 mask. When there are cloud resources in a subnet, the subnet cannot be deleted.

We will create a default VPC and a default subnet in each region, and users can directly create cloud resources in the default VPC.

1.2.3 VPC network interconnection

The networks within the same VPC are interconnected by default, and the networks between different VPCs are blocked by default. The VPC network intercommunication function can realize network intercommunication between VPCs in different projects/different regions. When VPCs in different regions need to communicate together with UDPN.

Network segments between interconnected VPCs are not allowed to overlap.

1.2.4 Product quota

The default quota for each account is as follows:

Name Quota
The number of VPCs in each region 100
The number of subnets per VPC 200

 

1.2.5 VPC planning recommendations

  • The initial VPC network segment (the network segment when the VPC is created) cannot be deleted or modified.
  • It is recommended not to set the VPC network segment too large. After the VPC is created, the network segment can be added or deleted freely (except the initial network segment).
  • The VPC network segment cannot overlap with the public service network segment. The network segments between the VPCs that are connected to the network cannot overlap.

 

1.3 Introduction to NAT Gateway

The NAT gateway is an enterprise-level VPC public network gateway that allows cloud resources that are not bound to an EIP in the subnet to access the public network, and can also configure port forwarding rules to enable cloud resources to provide public services.

1.3.1 Mode options

NAT gateway can choose normal mode and whitelist mode.

In normal mode, all cloud resources in the designated subnet of the NAT gateway that are not bound to an EIP can access the public network through the NAT gateway.

In the whitelist mode, the cloud resources in the designated subnet of the NAT gateway and defined in the whitelist can access to the Internet through the NAT gateway.

Before switching the NAT gateway to the whitelist mode, you can configure the whitelist in advance to ensure that normal services are not affected when the NAT gateway is switched to the whitelist mode. In normal mode, the whitelist can be configured, but it does not take effect.

1.3.2 Port forwarding

Users can configure port forwarding to map the private ports of cloud resources in the VPC to the NAT gateway, so that cloud resources can provide services to the outside world.

Cloud resources bound to EIPs in the designated subnet of the NAT gateway will not appear in the port forwarding configuration options list.

1.3.3 Network exit

You can specify an EIP for a single cloud resource in the designated subnet of the NAT gateway to access the public network, or you can specify the same EIP for all cloud resources to access the public network.

1.3.4 Quota limit

Name Quota
The number of EIPs that NAT can bind 64
The number of export rules 64

1.3.5 NAT supported products

All products out of the intranet through NAT support by default, and the examples of whitelist, export rules and port forwarding currently supported are as follows:

Name Whitelist Export rule Port forwarding
UHost
UPHost x x
UDHost x
UHybrid x x x
UNI
VIP x
UDB
UTSDB
UMem
UHADOOP
UDW
UES x x
UAuditHost

 

1.4 Introduction to VIP

VIP is provided on the SCloud platform for cloud hosts and physical cloud hosts, and serves as a driftable private entry for user-defined high-availability services. When using VIP, users need to combine VIP with high-availability services in order to perform service entry drift when the service fails, achieving high service availability.

Product quota

Name Quota
The number of VIPs supported by a single region 100

 

1.5 Introduction to Network ACL

Network ACL is a security policy at the subnet level, which is used to control the data flow in and out of the subnet. Users can set up outbound rules and inbound rules to accurately control the traffic entering and leaving the subnet.

Network ACL is stateless. For example, if users need to allow certain access, they need to add corresponding inbound rules and outbound rules at the same time. If only the inbound rule is added, but the outbound rule is not added, the access exception will be caused.

ACL rules do not take effect on Outstanding UHost, UPHost and ULB.

1.5.1 Associated Subnet

After creating a network ACL, the user can bind and unbind the ACL with any subnet under the VPC to which it belongs. Before binding the subnet, make sure that the rules in the ACL are correct, so as not to affect the normal communication of cloud resources in the associated subnet.

1.5.2 Outbound/Inbound Rules

Network ACL rules are divided into outbound rules and inbound rules. The user’s updates to the network ACL rules will be automatically applied to the associated subnet.

The maximum number of outbound/inbound rules allowed to be added is 50 each.

Network ACL rules include the following components:

  • Strategy: Allow or Deny.
  • Source IP/Target IP: The network segment targeted by the outbound/inbound rule.
  • Protocol type: Support TCP, UDP, ICMP and GRE protocol types, select ALL to specify all protocol types.
  • Port number: The allowed port range for TCP and UDP protocol types is 1-65535. There is no need to specify the port for other protocol types.
  • Priority: The priority corresponding to the rule. The smaller the number, the higher the priority. The available range is 1-30000. Only one outbound/inbound rule of the same priority can be created.
  • Association target: the effective range of ACL rules. Support all resources in the subnet and designated resources in the subnet. “All resources in the subnet” means that the rule is effective for all resources in the subnet bound to the ACL (except for OutstandingUHost, UPHost and ULB); “Specified resources within the subnet” means that the rule is only effective for the selected resources in the subnet (specified high-availability version UDB is not supported), and it does not take effect on the unselected resources in the subnet.

Note that: After creating a network ACL, the system will automatically add a default outbound rule and a default inbound rule.

The default outbound rule is the outbound permission for all protocols and all port traffic.

 

The default inbound rule is the inbound permission for all protocols and all port traffic.

 

The default rule does not allow editing and deletion, and it exists when the ACL is created.

The default rule has the lowest priority and can be overridden by adding a higher priority rule.

1.5.3 Product quota

Each network ACL quota is as follows (not including default rules):

Name Quota
The number of outbound rules 100
The number of inbound rules 100

 

1.6 Introduction to route tables

1.6.1 Glossary

Default routing table: When creating a VPC, the system defaults to the routing table created by the VPC. The newly created subnet will be bound to the default routing table by default. The default routing table cannot be deleted or edited. The rules in the default routing table are all system routes.

Custom routing table: The routing table created by the user independently, and the routing rules can be custom. custom routing tables can be created, deleted, and edited. Note that the system routes in the custom routing table are only allowed to be viewed and not allowed to be edited.

System routing: The routing rules added by the system to the routing table by default. System routing is only allowed to be viewed.

Custom routing: user-defined routing rules. The routing rules include destination address, next hop type, and next hop. Custom routes can be added, edited, and deleted. The effective granularity of the routing table is the subnet. Each subnet must be bound and only one routing table can be bound. A routing table can be bound by multiple subnets.

1.6.2 Routing rule types 

The next hop types of routing table rules are enumerated as follows:

The type of next hop The next hop Instructions
LOCAL LOCAL System routing. Each network segment in the VPC will add a LOCAL route, indicating that the VPC is accessible by default.
VPC interconnection vnet id System routing, added by default after VPC is opened
Public gateway Public gateway System routing, specify the exit of the public network. If the cloud resource is bound to EIP, it will export to EIP by default; otherwise, if the subnet is bound to a NAT gateway, it will export to the NAT gateway by default.
Public service Public service System routing, pointing to the DNS and YUM sources provided by SCloud, as well as ULB’s proxy address, health check address, etc.
CUSTOM CUSTOM System routing, SCloud internal special services, such as UAEK and other business use
IPSecVPN vpngw id Custom routing, after using the IPSec VPN product, the route added in the VPC pointing to the IPSec VPN gateway. At present, the system will automatically add it, temporarily not allow customers to add it.
Private VIP vip id Custom routing. The next hop is VIP.
Instance Uhost id (phost id) Custom routing. The next hop is cloud host or physical cloud host.

 

1.6.3 Restrictions 

1) The network segments of the destination addresses in the routing rules can overlap, but they cannot be completely the same. If the destination addresses in multiple routing rules are matched at the same time, the priority is determined according to the longest prefix matching algorithm.

2) The next hop type supported by custom routing rules is private VIP and instance (cloud host, physical cloud host).

3) Custom routing rules cannot be added to the default routing table. If you need custom rules, you can create a custom routing table and add custom routing rules.

4) Each routing table supports up to 50 custom routing rules.

 

1.7 Billing instructions

The private network VPC, subnet, and network ACL are all free products and do not need to pay any fees.

The NAT gateway is a free product, but the bound EIP is a charged product, and the specific price refers to the price of EIP.

 

 

 

 

 

 

 

 

 

 

 

Restrictions 

The VPC network segment cannot overlap with the public service network segment. The public service network segments of each region are as follows.

Region Network segment
Hong Kong

10.8.192.0/18

10.7.192.0/18

Los Angeles 10.11.192.0/18
Washington 10.27.192.0/18
Frankfurt 10.29.192.0/18
Bangkok 10.31.192.0/18
South Korea 10.33.192.0/18
Singapore 10.35.192.0/18
Kaohsiung 10.37.192.0/18
Moscow 10.39.192.0/18
Tokyo 10.40.192.0/18
Taipei 10.41.192.0/18
Dubai 10.44.192.0/18
Jakarta 10.45.192.0/18
Mumbai 10.47.192.0/18
Sao Paulo 10.49.192.0/18
London 10.50.192.0/18
Lagos 10.52.192.0/18
Ho Chi Minh 100.64.0.0/20
Manila 100.64.48.0/20

In order to ensure that the various functions provided by SCloud are normal, ACL will release the public service network segment provided by SCloud by default, and the default behavior of ACL will not have any impact on your business security.

Planning proposal

3.1 ACL Planning proposal

The current newly created ACL table is in the blacklist mode by default, and the default outbound and inbound rules are the “All resources in subnet” rules with the lowest priority. In actual scenarios, ACL settings are very complicated due to its stateless nature. The following will introduce the main points of ACL rule setting and how to set appropriate ACL rules according to the scenario.

3.1.1 ACL rule recommendations

When setting ACL rules, the recommendations are as follows:

  • ACL rules are stateless, so when setting rules, you need to consider both the outbound and inbound directions.
  • The default effective level of SCloud ACL products is a single cloud resource. For example, if you add a denial rule with a target address of 0.0.0.0/0, the communication between the host and the host in the same subnet will also be affected. Therefore, an additional release rule for the same subnet network segment needs to be added.
  • Different inbound rules in the same ACL table are not allowed to have the same priority. Different outbound rules in the same ACL table do not allow the same priority.
  • ACL rule settings need to be as close as possible to the source of the traffic. For example, prohibiting a certain IP from accessing subnet resources, blacklisting in outbound rules and inbound rules can achieve the effect. Inbound rules should be set to deny traffic inflows.
  • The SCloud public service network segment needs to be released, otherwise services such as ULB, yum source, NTP, and privateDNS cannot be used normally.

3.1.2 ACL case

The following uses an example to introduce how to configure ACL rules.

The network architecture is as follows:

 

In this example, ACL rules need to be configured for subnet A. Subnet A needs to meet the following rules:

  • The network segment of subnet A is 10.10.1.0/24, and all the internal subnets are interconnected.
  • Port 22 of subnet A can only be accessed by subnet B. The network segment of subnet B is 192.168.1.0/24.
  • The cloud resources of subnet A can only access port 53 (UDP/TCP) of 8.8.8.8, and cannot access other public
  • The cloud resource port 80 of subnet A can be accessed by any address.
  • Subnet A can normally use the public services provided by S
  • The rest of the traffic is prohibited.

Then the ACL rules of subnet A should be configured as follows:

Inbound rules

Priority Port number Protocol Source IP Strategy Description
1 22 TCP 192.168.1.0/24 Allow Allow subnet B to access port 22
2 80 TCP 0.0.0.0/0 Allow Allow any address to access port 80
3 32768-65535 TCP 8.8.8.8/32 Allow Allow hosts in the subnet to access TCP port 53 of 8.8.8.8, and the temporary port is allowed.
4 32768-65535 UDP 8.8.8.8/32 Allow Allow hosts in the subnet to access UDP port 53 of 8.8.8.8, and the temporary port is allowed.
5 ALL ALL 10.10.1.0/24 Allow Allow hosts in the subnet to communicate with each other
6 ALL ALL 10.13.192.0/18 Allow Allow access to public services
30000 ALL ALL 0.0.0.0/0 Deny Deny all traffic by default
* ALL ALL 0.0.0.0/0 Allow All traffic is released by default, and the system automatically adds it with the lowest priority when it is created.

 

Outbound rules

Priority Port number Protocol Source IP Strategy Description
1 53 TCP 8.8.8.8/32 Allow Allow hosts in the subnet to access TCP port 53 of 8.8.8.8.
2 53 UDP 8.8.8.8/32 Allow Allow hosts in the subnet to access TCP port 53 of 8.8.8.8.
3 32768-65535 TCP 0.0.0.0/0 Allow Allow port 80 to access externally, allow port 22 to access subnet B, and release the temporary port.
4 ALL ALL 10.10.1.0/24 Allow Allow hosts in the subnet to communicate with each other
5 ALL ALL 10.13.192.0/18 Allow Allow access to public services
30000 ALL ALL ALL Deny Deny all traffic by default
* ALL ALL 0.0.0.0/0 Allow All traffic is released by default, and the system automatically adds it with the lowest priority when it is created.

 

3.1.3 ACL rule analysis

Take the rule of “port 22 of subnet A, which can and can only be accessed by subnet B, and the network segment of subnet B is 192.168.1.0/24.” as an example, the analysis method is as follows:

 

Temporary ports are ports that can be allocated from a preset range when protocols such as TCP and UDP actively initiate a connection. The port is occupied only during the life cycle of the connection. This range can be obtained in the following ways:

cat /proc/sys/net/ipv4/ip_local_port_range

You can use the following commands to modify the temporary port range:

echo “32768 65535” >  /proc/sys/net/ipv4/ip_local_port_range

This article uses “32768-65535” to refer to temporary ports. As above, respectively mark the four-tuples accessed by subnet B on port 22 of subnet A. Then, if the default rule is deny, you need to add the following inbound and outbound rules:

Inbound rules

Priority Port number Protocol Source IP Strategy Description
1 22 TCP 192.168.1.0/24 Allow Allow subnet B to access port 22

Outbound rules

1 32768-65535 TCP 192.168.1.0/24 Allow Allow subnet B to access port 22

The rest of the scenes can also be obtained by enumerating the five-tuples (source and destination IP, port, and protocol) of the inbound and outbound directions.

 

3.2 VPC Planning proposal

The private network VPC provides the ability to independently plan the network. At present, each regional system will create a default VPC and subnet. How to use it and how to plan its own network requires consideration of various factors such as business scenarios, future business changes, and business expansion. .

The networks between different VPCs are isolated by default, and the network intercommunication between different VPCs can be realized through the VPC connection function. There are many requirements for the VPC network segment when VPC is connected, which is also a problem to be considered when planning a VPC. The following will introduce the main points of VPC planning and the limitations of VPC connectivity to help users plan their own networks reasonably.

3.2.1 VPC rule recommendations

 

When creating a VPC and subnet, the recommendations are as follows:

  • In different projects in the same region, the default VPC and the default subnet network segment are the same. If there are interworking requirements in this scenario, the default VPC should not be used.
  • According to the business scale and the granularity of the division, the private network segment of the VPC is reasonably selected. The maximum number of IPs supported by different VPC network segments is different.
  • The VPC network segment should not be too large. After creation, the network segment cannot be modified, but the VPC can continue to add network segments.
  • Avoid overlapping of the network segments of different VPCs to prepare for possible VPC connectivity.

3.2.2 Examples of VPC scenarios

1) A single VPC and a single subnet can build a simple website service or personal blog.

In this scenario, there is no complicated business isolation requirement, and there is no cross-domain intercommunication scenario. The default VPC and default subnet created by the local domain system can be used to quickly create a cloud host. By binding EIP, external access can be provided. To ensure the security of the cloud host, you can choose the “Web Server Recommendation” firewall provided by default when you create it.

 

 

2) A single VPC with multiple subnets enables the division of different services.

In this scenario, all services are deployed in a single region on the cloud platform. In VPC, different services are divided by dividing different subnets. For example, subnet A provides public access to Web services, subnet B is the core database without public network access rights, and subnet C is a pre-release environment that simulates online service release.

The number of subnets is determined according to specific business needs, and the size of the subnets can be determined according to the number of hosts required in each subnet. The mask in the subnet segment determines how many instances of cloud resources can be launched in the subnet. For example, the subnet segment is 192.168.1.0/24, the mask is 24, and all 0s, broadcast and gateway addresses are removed, which can actually be supported The number of instances is 256-3=253. Since the network segment cannot be modified after the subnet is created, the future expandable margin should also be considered when considering the subnet mask.

After the number of subnets and the size of the subnet are determined, the network segment size of the VPC can be determined.

The networks between different subnets in the VPC are interconnected by default. If you need to set access permissions for the core database business, you can configure the network ACL to achieve it.

 

3) Cross-regional VPC, combined with high-speed channel UDPN to realize cross-regional data backup.

In this scenario, the main service is deployed in a region, and another region is selected as a cross-regional backup node. The data is regularly transmitted to the disaster recovery node every day.

A VPC can only be used in one region. Each region needs to create a VPC, and the networks between different VPCs are isolated by default. If you need to achieve network intercommunication between different VPCs, you can perform “VPC connectivity” on the console. Cross-regional VPC connectivity needs to be used in conjunction with UDPN. First, purchase UDPN between the two regions, and then connect to the network.

Since the VPC of the main service needs to communicate with the VPC of the backup node, when planning the two VPCs, different VPC network segments should be selected to avoid interconnection due to network segment conflicts when the network is connected.

 

4) The VPC on the cloud and the IDC computer room network are interconnected to realize the smooth expansion of IDC.

In this scenario, the user’s business is distributed on the cloud platform and its own IDC computer room, which can realize the smooth migration of IDC to the cloud, and utilize the elastic characteristics of the cloud platform to respond to business emergencies in a timely manner.

There are two ways for connecting VPC and IDC computer rooms on the cloud, dedicated line access or IPSec VPN. Dedicated line access is to connect the local IDC to the SCloud data center through a dedicated line. After access, the local IDC will be virtualized into a VPC on the cloud, and intercommunication can be realized by connecting with the VPC on the cloud. The VPN gateway is based on the Internet and realizes the intercommunication between the VPC on the cloud network and the local IDC through an encrypted data transmission tunnel.

Both methods require that the network segments of the VPC on the cloud and the local IDC cannot overlap. Therefore, when deploying services on the cloud, select the unused network segment of the local IDC during VPC planning.

 

 

 

 

3.2.3 VPC connectivity rules

1) Connectivity restrictions

Same region: The default network segments can overlap (IP cannot conflict), and the custom network segments cannot overlap.

Local end\Opposite end Default VPC with only default network segment Custom VPC with only custom network segments Default VPC with custom network segments
Default VPC with only default network segment There is no IP conflict, and the same network segments can connect. Besides, multiple same default network segments can connect. If the network segments are the same, they cannot connect; if it is the same as the customized network segment that has been connected, they cannot connect. If it is the same as the customized network segment that has been connected, they cannot connect.
Custom VPC with only custom network segments If the network segments are the same, they cannot connect; if it is the same as the customized network segment that has been connected, they cannot connect. If the network segments are the same, they cannot connect; if it is the same as the customized network segment that has been connected, they cannot connect.
Default VPC with custom network segments If the custom network segments are the same, they cannot connect; if the custom network segment is the same as the existing network segment, they cannot connect.

Cross-regional: The local network segment and all network segments of the opposite end cannot be the same, and multiple opposite connected network segments cannot be the same.

 

2) Glossary

  • Default VPC: The VPC converted from the previous basic network, or the VPC created by default in each regional system.
  • Custom VPC: A VPC created by the user.
  • Default network segment: The original network segment of the default VPC, which only exists in the default VPC.
  • Custom network segment: The network segment added by the user independently may exist in all network segments in the default VPC or in a custom VPC.
  • Routing rules: A VPC corresponds to a set of routing rules for routing data packets of the VPC. It consists of target network segment, next hop and route type. There can only be one route with the same target network segment.
  • Local type routing rule: The target network segment is a default network segment, and the type is “Local”. After matching this route, the forwarding plane will query all the opened default network segment information. Therefore, a local route can be routed to the same default network segment of multiple default VPCs that have been opened.
  • VNet type routing rules: The target network segment is a custom network segment, the next hop is the VPC to which the custom network segment belongs, and the routing type is “VNet”. After matching the route, the forwarding plane will send the data packet to the VPC in the next hop.

 

3) The principle of connect

  • When two VPCs are connected, the system will add the routing rules of the connectedopposite VPC network segment to the routing tables of the two VPCs.
  • For the default network segment in the opposite VPC, the local VPC adds a Local type route.
  • For the custom network segment in the remote VPC, the local VPC adds a VNet route.
  • When communicating across VPCs, confirm the VPC information of the opposite end of the communication by querying the route in the VPC routing table.

The following examples illustrate the principle of connect in detail.

 

Example 1: The default VPC is connected to the default VPC

If there is no IP conflict, it is allowed to connect with the default VPC that contains the local default network segment, and it is allowed to connect with multiple default VPCs that contain the same default network segment.

vpc_a and vpc_b are the default VPC with only the default network segment, and vpc_c is the default VPC with the custom network segment.

vpc_a can communicate with vpc_b and vpc_c that contain the same default network segment.

vpc_b can communicate with vpc_a and vpc_c that contain the same default network segment.

 

Example 2: The default VPC is connected with a custom VPC

When the remote network segment is the same as the local network segment, it is forbidden to connect; when the remote network segment contains a custom network segment that has been connected to the local VPC, it is forbidden to connect.

vpc_a is the default VPC with only the default network segment, and vpc_b and vpc_c are both custom VPCs with only the custom network segment.

vpc_a can be connected with vpc_b, the two vpcs do not contain the same network segment, and the existing routing rules do not include the route with the same target network segment and the opposite network segment.

vpc_b is forbidden to communicate with vpc_c because it contains the same “custom network segment 1”. If connection is allowed, when the host in vpc_b accesses “custom network segment 1”, the forwarding plane cannot determine whether it is sent to the VPC or the opposite vpc_c.

If vpc_a has been connected to vpc_b, connection with vpc_c is prohibited because vpc_c contains the same “custom network segment 1” as vpc_b. There are already routing rules in vpc_a whose target network segment is “custom network segment 1” and sent to vpc_b, and it is not possible to add routing rules whose target network segment is “custom network segment 1” and sent to vpc_c.

 

Example 3: Custom VPC is connected with custom VPC

When the network segment of this segment is the same as the network segment of the opposite end, it is forbidden to connect; when the network segment of the opposite end contains a custom network segment that has been opened by the local VPC, it is forbidden to connect.

vpc_a, vpc_b, and vpc_c are all custom VPCs containing only custom network segments.

vpc_a can be connected with vpc_b, the two vpcs do not contain the same network segment, and the existing routing rules do not include the route with the same target network segment and the opposite network segment.

vpc_b is forbidden to communicate with vpc_c because it contains the same “custom network segment 3”. If connection is allowed, when the host in vpc_b accesses “custom network segment 3”, the forwarding plane cannot determine whether it is sent to this VPC or the opposite vpc_c.

If vpc_a has been connected to vpc_b, connection with vpc_c is prohibited because it contains the same “custom network segment 1”, and vpc_a is connected to the same “custom network segment 3” in vpc_b.

 

Example 4: Cross-domain VPC connectivity

The local network segment and all network segments of the opposite end cannot be the same, and multiple connected opposite network segments cannot be the same.

vpc_a is the default VPC of Region I, which only contains the default network segment, and vpc_b and vpc_c are the default VPC of Region II, which only contains the default network segment.

vpc_a can be connected with vpc_b, the two vpcs do not contain the same network segment, and the existing routing rules do not include the cross-domain routing of the same target network segment.

vpc_b can be connected with vpc_c. If there is no IP conflict in the same region, VPCs with the same default network segment are allowed to be connected.

vpc_a is forbidden to communicate with vpc_c. Although the two vpcs do not contain the same network segment, vpc_a is connected with vpc_b, and vpc_b and vpc_c contain the same network segment.

 

Build a VPC network

4.1 Create a VPC

1) Log in to the console and select VPC Virtual Private Cloud in All Products to enter the VPC page.

2) Click the Create VPC button on the VPC tab to create a VPC instance. When creating, you need to fill in the following information:

  • VPC name: Enter a name with a length of 6 to 63 characters.
  • Network segment: Select the corresponding network segment according to the plan. You can add multiple network segments that are not repeated at one time, or you can continue to add them after creation.

3) After the creation is successful, you can view the created VPC instance on the VPC page and manage it, such as modifying remark, editing UGroup, adding network segments, etc.

 

4.2 Create subnet

1) Log in to the console and select VPC Virtual Private Cloud in All Products to enter the VPC page.

2) You can click the Create Subnet button in the Subnet tab to create a subnet instance, and you need to fill in the following information when creating:

  • AssociatedVPC: Select which VPC the subnet will be created in.
  • VPC network segment: select the network segment that has been added in the VPC.
  • Subnet name: Enter a name with a length of 6~63 digits.
  • Subnet networksegment: According to the VPC segment, select the subnet segment. The subnet segments in the same VPC cannot overlap.

3) After the creation is successful, you can view the created subnet instance on the subnet page and manage it, such as modifying remark, editing UGroup, and managing resources.

 

4.3 Add UHost

1) Log in to the console, select UHost in All Products, and enter the cloud host page.

2) Click the “Create Host” button in the Host Management tab to create a host instance. Select the region where your VPC is located and select the corresponding VPC and subnet when creating it.

3) After the creation is successful, the cloud host will exist in the VPC.

 

4.4 Create NAT gateway

1) Log in to the console and select VPC Virtual Private Cloud in All Products to enter the VPC page.

2) In the NAT gateway tab, click Create NAT Gateway to create a NAT gateway instance, and select the created VPC and subnet.

3) After the creation is successful, you can view and manage the created NAT gateway instance on the NAT gateway page.

 

4.5 Bind network ACL

1) Log in to the console and select VPC Virtual Private Cloud in All Products to enter the VPC page.

2) Click Create ACL in the network ACL tab to create an ACL instance. When creating, you need to fill in the following information:

  • AssociatedVPC: Select which VPC the ACL belongs to.
  • ACL name: Enter a name with a length of 6~63 digits.

3) After the creation is successful, you can view the created ACL instance on the subnet page and manage it.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Operation guide

5.1 VPC

5.1.1 Create VPC

Select UVPC in All Products to enter the VPC page. Click the Create VPC button on the VPC tab to create a VPC instance. Fill in the VPC name in the pop-up page and select the desired network segment. The default is 192.168.0.0/16. Then click “OK”.

Multiple independent address segments can exist in a VPC, as long as there is no address overlap with each other.

5.1.2 Add network segment

After the VPC is created, multiple non-overlapping network segments can be added at any time. Click Edit Segment in the VPC tab.

 

In the pop-up dialog box, fill in the network segment information to be added.

 

5.1.3 View VPC details

Click Details in the VPC tab to enter the details page of a VPC.

On the details page, you can see basic information such as the name, resource ID, remarks, business group, number of subnets, and network segments of the VPC.

 

5.1.4 Network interconnection

The two VPCs are originally isolated from each other. For business purposes, the networks of the two VPCs need to be able to communicate with each other, which can be achieved through the VPC’s Edit Interconnection function.

Click Edit Interconnection in the VPC tab to enter the Edit Interconnection operation page, or switch to the Edit Interconnection tab on the VPC details page.

 

Click Connect on the page to enter the Connect page. Select the VPC to be connected, make sure that the network segments between the VPCs do not overlap with each other, and click Purchase Now.

 

Confirm the VPC information that needs to be connected, and click OK.

 

Successfully connected. If the address segments of the VPC that are trying to connect have overlapped, the network communication fails and an error is reported. The connected VPC will be displayed in the Connected VPC list.

 

5.1.5 Cross-project VPC interconnection

In addition to connecting different VPCs of the same project, Edit Interconnection also allows VPCs of different projects to be connected.

As above, enter the Edit Interconnection operation page, and click Connect to enter the connect dialog box. Click the drop-down list next to Associated Project and select the target project.

 

In the VPC list of the target project, select the VPC to be connected, and click OK to confirm to complete the interconnection.

5.1.6 Cross-regional VPC interconnection

In addition to connecting different VPCs in the same region, Network Interconnection also allows VPCs in different regions to connect. The premise is: a UDPN (high-speed channel) connection has been established between the two regions.

As above, enter the Edit Interconnection operation page, and click Connect to enter the connect dialog box. Click the drop-down list next to Location and select the target region.

 

 

In the VPC list of the target region, select the VPC you want to connect to, and click OK to confirm to complete the connection.

Note that: In the high-speed channel UDPN product, it also provides the network interconnection capability, and the function is the same as here.

5.1.7 Disconnect VPC

VPCs that have been connected can choose to disconnect from each other.

In the Connected VPC list, select the VPC you want to disconnect. At this time, the Disconnect button changes from unavailable to available, click the button.

 

In the pop-up Disconnect VPC dialog box, click OK to confirm disconnection.

 

Successfully disconnected. The interconnection information in the Connected VPC list will be updated accordingly.

5.1.8 Delete VPC

In the VPC list, select the VPC to be deleted, and click Delete.

 

Before deleting a VPC, make sure that the cloud resources and subnets in the VPC have been deleted, and that it does not connect with other VPCs, otherwise they cannot be deleted.

 

In the pop-up Delete VPC dialog box, click OK to confirm the deletion.

 

5.2 Subnet 

5.2.1 Create subnet

Log in to the console, select the subnet option under UVPC, and click Create Subnet. Select the VPC to which the subnet belongs, fill in the subnet name and subnet segment. The subnet segment must be in the VPC address segment and cannot overlap with the existing subnet. Click OK.

5.2.2 Delete subnet

The user can delete the created subnet. On the subnet page, select the subnet to be deleted, and click Delete.

Note that: Subnets that still contain resources are not allowed to be deleted. Before deleting a subnet, you need to delete resources such as cloud hosts in the subnet.

After confirming that it is correct, click OK to delete the subnet.

 

5.2.3 Display subnet

On the subnet tab of the console, you can see a list of all subnets in the current region.

 

Click VPC in the list to filter out the list of subnets belonging to a specific VPC.

 

Click the subnet name or Details to enter the subnet overview page. Click Resource Management on the overview page to view the resources under the current subnet, such as the cloud host, database, etc.

 

 

5.3 NAT gateway

The NAT gateway is an enterprise-level VPC public network gateway that allows cloud resources that are not bound to an EIP in the subnet to access the public network, and can also configure port forwarding rules to enable cloud resources to provide public services.

5.3.1 Create NAT gateway

Log in to the console and select VPC Virtual Private Cloud in All Products to enter the VPC page. In the NAT gateway tab, click Create NAT Gateway to create a NAT gateway instance, and select the created VPC and subnet.

Select Normal Mode for the Internet outbound mode, select the EIP, bandwidth and firewall required by the NAT gateway, and then click Purchase Now.

 

After the creation is successful, you can view and manage the created NAT gateway instance on the NAT gateway page.

 

After the NAT gateway is created, the cloud resources that are not bound to the EIP in the specified subnet can access the Internet through the NAT gateway.

5.3.2 Whitelist mode

The NAT gateway additionally provides a whitelist mode.

In the whitelist mode, the cloud resources in the designated subnet of the NAT gateway and defined in the whitelist can access the Internet through the NAT gateway.

To create a NAT gateway, except for selecting the Whitelist mode, the rest is the same as the Normal mode.

The whitelist of the newly built NAT gateway is empty, and no cloud resources can access the public network, and the whitelist needs to be configured. Click the Manage button in the list to enter the NAT gateway details page.

 

Click Mode Setting tab to enter the Whitelist management.

 

Click Add Whitelist to add the main resource you want.

 

After clicking OK, the list takes effect, and the cloud resources in the whitelist can access the Internet.

5.3.3 Port forwarding

Configuring port forwarding allows a certain port of cloud resources to be accessed by the public network for service provision or management.

On the NAT gateway details page, switch to the Port Forwarding tab.

 

Click Add Forwarding Rules to add a new rule.

 

Click Edit to modify the existing rules.

Click Delete to delete the existing rules.

5.3.4 Configure network outbound rule

In the Outbound Rules module, you can manage the exit of the NAT gateway.

 

There is a Default outbound rule, which is used to record the default exit of the NAT gateway. It can be modified through the Edit button, but it cannot be deleted. The default outbound rule has the lowest priority.

 

You can add outbound rules and specify for a single cloud resource.

 

After the addition is successful, the rules can be modified. The default rule can modify the target IP. Other export rules can modify the name and target IP.

 

5.4 VIP

5.4.1 Apply VIP

Log in to the console and select VPC Virtual Private Cloud in All Products to enter the VPC page. In the VIP tab, click Apply VIP.

 

In the application menu, you can select region, Associated VPC, subnet, UGroup, and the number of VIP.

 

Note that: After the application is completed, you can click Edit on the list page to modify the name of the VIP, and perform Edit UGroup operation.

5.4.2 Apply VIP to UHost/UPHost

Note that: A VIP can only be bound to one cloud host/physical cloud host, otherwise it may cause inconsistent ARP information.

 

CentOS system implementation method 1:

Solidify the configuration, write the VIP into the ifcfg configuration file (valid for CentOS7 and lower versions)

1) Copy a ifcfg-eth0 configuration file and name it ifcfg-eth0:0, the command is as follows

cp /etc/sysconfig/network-scripts/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfg-eth0:0

2) Modify the ifcfg-eth0:0 configuration file. The command is as follows

vim /etc/sysconfig/network-scripts/ifcfg-eth0:0

After entering the edit mode, change the IP behind “IPADDR=” to the VIP you applied, change DEVICE=”eth0″ to DEVICE=”eth0:0″, and delete the line “GATEWAY=”.

3) Restart the network. The command is as follows:

service network restart

4) Use the arping command to notify the arp information: if the VIP you applied is 10.4.200.X

arping -U 10.4.200.X

Note that:

  • After restarting the network, use the ip a command to check whether the VIP has been added successfully.
  • The VIP can only be written into the ifcfg-eth0:0 configuration file, and the IPADDR in the ifcfg-eth0 configuration file cannot be modified to the V If the ifcfg-eth0 configuration file is modified incorrectly, it may cause network interruption of the cloud host.

 

For CentOS8 and higher version

CentOS8 began to fully use NetworkManager to manage the network, so the above-mentioned method cannot be used for network management.

1) Check the current connection status.

nmcli con show

The possible results are as follows:

NAME       UUID                                  TYPE    DEVICE

System eth0  5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03  ethernet  eth0

Get the current network connection name: System eth0

2) Add IP

nmcli con mod “System eth0” +ipv4.addresses “192.168.0.30/24”

3) Load configuration

nmcli con up “System eth0”

4) Use the arping command to advertise arp information: If the VIP you applied is 10.4.200.X

arping -U 192.168.0.30

 

CentOS system implementation method 2:

Temporary addition, use commands to manually add VIP

If the VIP you applied is 10.4.200.X

The command is as follows

ip addr add 10.4.200.X/16 dev eth0

Use the arping command to advertise arp information

arping -U 10.4.200.X

Use the ip a command to check whether the VIP has been added successfully

Note that: After the host restarts or the network service restarts, you need to manually add the VIP again

 

Ubuntu system implementation method 1:

solidify the configuration, write the VIP into the ifcfg configuration file

Modify the network configuration file, the command is as follows

sudo vim /etc/network/interfaces

Copy the configuration file section, replace eth0 with eth0:0, and fill in the VIP behind the address.

# The primary network interface

auto eth0

iface eth0 inet static

address 10.4.5.255

netmask 255.255.0.0

gateway 10.4.0.1

dns-nameservers 10.255.255.1

Example of modified Ubuntu configuration file

# The primary network interface

auto eth0

iface eth0 inet static

address 10.4.5.255

netmask 255.255.0.0

gateway 10.4.0.1

dns-nameservers 10.255.255.1

auto eth0:0

iface eth0:0 inet static

address Fill in VIP here

netmask 255.255.0.0

gateway 10.4.0.1

dns-nameservers 10.255.255.1

Restart the network, the command is as follows:

sudo /etc/init.d/networking restart

Use the arping command to advertise arp information:

arping -U 10.4.200.X

Use the ip a command to check whether the VIP has been added successfully

Attention: VIP can only be added in the eth0:0 configuration section, and the address in the eth0 configuration section cannot be modified. If the eth0 configuration section is modified by mistake, the cloud host’s network may be interrupted.

 

Ubuntu system implementation method 2:

Temporary addition, use commands to manually add VIP

If the applied VIP is 10.4.200.X, the command is as follows

ip addr add 10.4.200.X/16 dev eth0

Use the arping command to advertise arp information:

arping -U 10.4.200.X

Use the ip a command to check whether the VIP has been added successfully.

Attention: After the host restarts or the network service restarts, you need to manually add the VIP again.

5.4.3 Remove the VIP configured in the resource

CentOS system writes the VIP into the ifcfg-eth0:0 configuration file

Delete the ifcfg-eth0:0 configuration file, the command is as follows

rm /etc/sysconfig/network-scripts/ifcfg-eth0:0

Restart the network, the command is as follows

service network restart

Use the ip a command to check whether the VIP has been deleted successfully.

 

CentOS system uses commands to manually add VIP

If the applied VIP is 10.4.200.X, the command is as follows:

ip addr del 10.4.200.X/16 dev eth0

Use the ip a command to check whether the VIP has been deleted successfully.

 

Ubuntu system writes the VIP to the configuration file

Modify the network configuration file, the command is as follows

sudo vim /etc/network/interfaces

Delete the auto eth0:0 configuration section in the configuration file section.

Examples of configuration sections that need to be deleted in the Ubuntu configuration file:

auto eth0:0

iface eth0:0 inet static

address VIP here

netmask 255.255.0.0

gateway 10.4.0.1

dns-nameservers 10.255.255.1

Restart the network, the command is as follows:

sudo /etc/init.d/networking restart

Use the ip a command to check whether the VIP has been deleted successfully.

 

Ubuntu system uses command to manually add VIP

If the applied VIP is 10.4.200.X, the command is as follows:

ip addr del 10.4.200.X/16 dev eth0

Use the ip a command to check whether the VIP has been deleted successfully.

 

5.4.4 Release VIP

On the function page of the intranet VIP, check the intranet virtual IP that needs to be released, and click “Release” in the function button.

 

In the pop-up release VIP dialog box, the relevant information of the VIP is displayed. Confirm that it is correct, then click OK to complete the release of VIP.

5.4.5 Use VIP and Keepalive to configure service high availability

Install keepalived

Install directly with yum under CentOS

# yum install -y keepalived

 

Configure VIP

First explain several variables in the following steps (root privileges are used by default):

$node1: private IP of server A

$node2: private IP of server B

$vip: private VIP

Server A (node1)

1) Edit /etc/keepalived/keepalived.conf

global_defs {

router_id LVS_DEVEL

}

vrrp_instance VI_1 {

state MASTER

interface eth0

#unicast peer format must match exactly! And it must be written in three lines.

unicast_peer {

$node2

}

virtual_router_id 51

priority 100 advert_int 1

authentication {

auth_type PASS

auth_pass 1111

}

virtual_ipaddress {

$vip dev eth0

}

}

2) Start keepalived

# service keepalived start

Server B (node2)

1) Edit /etc/keepalived/keepalived.conf

global_defs {

router_id LVS_DEVEL

}

vrrp_instance VI_1 {

state BACKUP

interface eth0

#unicast peer format must match exactly! And it must be written in three lines.

unicast_peer {

$node1

}

virtual_router_id 51

priority 90

advert_int 1

authentication {

auth_type PASS

auth_pass 1111

}

virtual_ipaddress {

$vip dev eth0

}

}

2) Start keepalived

# service keepalived start

 

Test VIP

1) Check the system log and observe whether keepalived is successful

# tail /var/log/messsages

2) Stop keepalived on node1, and then observe the IP information on node1 and node2 respectively

# service keepalived stop

# ip a

 

5.5 Network ACL

Network ACL is a security policy at the subnet level, which is used to control the subnet inbound and outbound data flow. Users can set up outbound rules and inbound rules to accurately control the traffic entering and leaving the subnet.

5.5.1 Create ACL

Log in to the console and select VPC Virtual Private Cloud in All Products to enter the VPC page. In the Network ACL tab, click Create ACL. Select the VPC to which the ACL belongs, fill in the ACL name, and click OK.

 

After the creation is complete, you can see the newly created ACL instance in the list.

 

5.5.2 Edit inbound rules

In the details page, select the Inbound Rules tab. Click Add Inbound Rule to add an inbound rule.

In the pop-up edit box, select the policy, protocol type, and fill in the source IP, port, priority and other information. Click OK to add.

 

After the addition is complete, the rules can be edited and deleted. The default rules do not allow editing and deletion.

5.5.3 Edit outbound rules

In the details page, select the Outbound Rules tab. Click Add Outbound Rule to add an inbound rule.

In the pop-up edit box, select the strategy, protocol type, and fill in the target IP, port, priority and other information. Click OK to add.

 

After the addition is complete, the rules can be edited and deleted. The default rules do not allow editing and deletion.

5.5.4 Associated Subnet

After editing the rules, you can click Details to enter the ACL overview page. Click Bind to bind the ACL with the subnet of the VPC to which it belongs.

 

Click Unbind to unbind the ACL from the subnet. You can perform unbinding operations in batches.

 

5.5.5 Precautions

KUN service network segment release

When using KUN services, the following network segments need to be cleared in the inbound and outbound direction:

Region Network segment
Hong Kong 100.65.64.0/18
Singapore 100.64.208.0/20

 

5.6 Route table

The routing table is a VPC-level product that can control the network traffic path of cloud resources. A routing table is composed of multiple routing rules, which are effective for all resources in the subnet through binding with the subnet.

5.6.1 Create a custom routing table

Log in to the console and select VPC Virtual Private Cloud in All Products to enter the VPC page. In the Route Table tab, click Create Route Table.

 

To create a routing table, you need to fill in the following information. After completing the filling, click OK to create it successfully.

  • Routing table name: required, name the routing table.
  • Remarks: Not required, the remarks of the routing table are convenient for searching and locating the routing table.
  • AssociatedVPC: Required. The routing table is a resource under a VPC. The created routing table can only be applied to the subnets under the VPC.
  • UGroup: mandatory, default is Default. The business group to which the routing table belongs.

 

After the creation is complete, you can see the created routing table instance in the list.

5.6.2 Add custom routing rules

In the details page, click Add Route Rule to fill in the rule. In the pop-up box, fill in the destination , target type, target and other information. Click OK to add.

 

After the addition is complete, the rules can be edited and deleted. The system routing rules are not allowed to be edited or deleted.

5.6.3 Bind subnet

After adding the routing rules, you can enter the Bound Subnet tab page. Click Bind Subnet to bind the routing table to the subnet of the VPC to which it belongs.

 

Select the subnet to be bound and click OK to bind successfully. If the subnet has been bound to other routing tables, it will be replaced with the current routing table.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

FAQ

Can I modify the network segment after the VPC is successfully created?

The created network segment cannot be modified, but you can continue to add network segments. It is recommended to select a smaller network segment when creating a VPC to prevent subsequent scenarios such as VPC connection unable to operate due to network segment reasons.

 

After the subnet is successfully created, can the network segment be modified?

Once the subnet is created successfully, the network segment cannot be modified.

 

How to delete the subnet of the associated resource?

You need to delete all cloud resources in the subnet before you can delete the subnet.

 

The subnet where a cloud host is located is bound with a NAT gateway, and at the same time the cloud host is bound with EIP, how does the cloud host access the Internet?

The host bound with EIP will preferentially access the Internet through EIP and will not pass through the NAT gateway.

 

Does the NAT gateway currently support binding multiple subnets?

The NAT gateway supports multiple subnets in the same region and the same VPC.

 

How many cloud resources can each private network support?

The number of cloud resources is related to the size of the network segment mask of the subnet in your private network, and there will be no additional restrictions.

 

What are the current public service network segments?

For public services, see the public service network segment in the local area in Restrictions.