Introduction

A NAT (Network Address Translation) gateway provides access to the Internet for private networks, and supports multiple cloud servers to share public network IP host to access the Internet. The NAT gateway can bind EIP instances and shared bandwidth packets to implement a many-to-one or many-to-many address translation service from the internal network IP to the public network IP for the cloud server.

Basic functions of NAT gateway:

• It can better manage the public network bandwidth resources and control the cost. Multiple cloud servers (BCC, BBC, DCC exclusive instances) accessing the public network can share one or more EIP by the NAT gateway.
• It can improve the security of cloud servers, and avoid that these servers are directly exposed to the public network and accessed.

The subnets are divided into general subnet and NAT exclusive subnet, and the cloud server to which the EIP is bound is placed in the general subnet; the cloud server accessing the public network by the NAT gateway is placed in the NAT exclusive subnet. The EIP cannot be bound to the instances of the NAT exclusive subnet.

Scenario 1

We will introduce how to reasonably regulate the deployment of subnets from scratch.

Example scenarios

As shown in the figure below, the cloud server to which the EIP is bound is placed in the general subnet A, the cloud server accessing the public network by the NAT gateway is placed in the NAT exclusive subnet B, and the EIP is bound to the NAT gateway.

Operation steps

1. Log in to Baidu AI Cloud console, and enter "Private Network VPC" to create one VPC instance. Respectively create a general subnet and NAT exclusive subnet in the instance.

2. Add a host (e.g. BCC) in the general subnet, bind EIP to BCC to enable BCC to access the public network.

3. Add a host (e.g. BCC) to the NAT exclusive subnet.

   • Create a NAT gateway and bind EIP to it.

   

   • Configure the route table. The NAT exclusive subnet can be selected for the source segment, and the target segment can be 0.0.0.0/0. The route type is NAT gateway, and the created NAT gateway instance can be selected for the next-hop instance.

   

   Up to this point, you can enter the ping public network address of the cloud server to test the connectivity.

Scenario 2

The users purchase the shared bandwidth, and bind multiple IP of the shared bandwidth to the NAT gateway to realize the many-to-many address conversion service.

Example scenarios

Based on Scenario I, the binding of EIP to the NAT gateway changes to the binding of the shared bandwidth.

Operation steps

1. Enter the page of "Elastic Public Network IP" to purchase the shared bandwidth.
2. Create a NAT gateway in the private network VPC, bind the shared bandwidth and select the required IP.

Up to this point, you can enter the ping public network address of the cloud server to test the connectivity.

Note: After the shared bandwidth is bound to the NAT gateway, and the IP can be unbound flexibly.

Scenario III

The user has completed the service deployment at the early stage. Due to the following business adjustment, the EIP should be re-bound to the cloud server previously accessing the public network by the NAT gateway to directly access the public network. In the subnet migration process, the cloud server should be restarted, and the service is interrupted for a short time.

Example scenarios

As shown in the figure below, the user has completed the service deployment at the early stage. Due to the business adjustment, a few cloud servers should be migrated from the NAT exclusive subnet B to the general subnet A.

Operation steps

1. In the page of the NAT exclusive subnet, click the name of cloud server instance to be migrated, and enter the details page of the instance. Configure "Change a Subnet" in the configuration information, select the subnet to be migrated to complete migration.

   

2. Bind EIP to the migrated cloud server to enable the cloud server to access the public network.

Up to this point, you can enter the ping public network address of the cloud server to test the connectivity.

Example scenarios

Similarly, the user has completed the service deployment at the early stage. Due to the following business adjustment, the cloud server previously accessing the public network by EIP should access the public network by the NAT gateway. In the subnet migration process, the cloud server should be restarted, and the service is interrupted for a short time.

As shown in the figure below, the user has completed the service deployment at the early stage. Due to the business adjustment, a few cloud servers should be migrated from the general subnet A to the NAT exclusive subnet B.

Operation steps

1. Enter the general subnet, and unbind EIPs from the cloud servers to be migrated.
2. Click the name of cloud server instance to be migrated, and enter the details page of the instance. Configure "Change a Subnet" in the configuration information, select the subnet to be migrated to complete migration.

Up to this point, you can enter the ping public network address of the cloud server to test the connectivity.

Note: The users can modify the intranet IP of the migrated instance.

Scenario IV

Because of the complex business of the user, the cloud server cannot be migrated due to the conditions. In the same subnet, some cloud servers access the public network by binding EIP, and other cloud servers access the public network by the NAT gateway. It has a complex but flexible configuration, and the users should be pay special attention.

Example scenarios

As shown in the figure below, in the general subnet A, the BCC accessing the public network by the NAT gateway and the BCC directly accessing the public network by binding EIP are mixed together.

Operation steps

1. The user submits a Ticket to apply for use of the NAT gateway in the general subnet.
2. Create a NAT gateway and bind EIP to it.
3. Configure the route table by the cloud server accessing the public network by binding EIP. Select the custom configuration for the source segment. You can fill in the intranet IP of the cloud server and the destination segment is 0.0.0.0/0. Select the local gateway for the route type, and the default gateway for the next hop.
4. Configure the route table. First select the general subnet for the source segment and the destination segment is 0.0.0.0/0. Select the NAT gateway for the route type, and select the created NAT gateway instance for the next hop.

Note: In this scenario, if you skip the 3rd step and directly enter the 4th step to configure the NAT gateway route, all the traffic accessing the public network in the subnet is directed to the NAT gateway, and the traffic accessing the public network by EIP in the subnet is interrupted.

Up to this point, you can enter the ping public network address of the cloud server to test the connectivity.