Identify the processes required to integrate NAT with other services in Windows
Integrating NAT into the Existing Network
The NAT server in your network design must have at least two interfaces: one that connects to the Internet and one that connects to the private network. You should consider this the minimum configuration.
NAT is, however, able to support multiple interfaces with external network connections. Alternatively, you may prefer to have a single external network interface, and bind multiple IP addresses to a single external interface.
Remember that although NAT supports multiple external interfaces, you should limit the internal interface to a single adapter.
Internal interfaces will become an issue if you choose to use the DHCP Allocator. The DHCP Allocator can only support a single network ID, so all internal interfaces must be located on a single internal network ID. Microsoft® documentation suggests that network clients connected to different physical segments may be assigned duplicate IP addresses, which would prevent internetwork communication between the segments.
For each NAT server interface, you must describe the interface characteristics so that you can integrate the NAT server into the existing network.
The following MouseOver discusses the necessary steps for integrating NAT.
One of the decisions you need to make is how do you want to allow your containers to communicate to the corporate network or outside work in general. Figure 3-11 presents a diagram showing how a container connects to the outside world.
As Figure 2-5 demonstrates, each container will connect via vNIC (Windows Server container) or a vmNIC (Hyper-V container) to the vSwitch configured in a host. Each vNIC is isolated from the next and is considered its own compartment.
These vNICs connect to the vSwitch by ports (much like Hyper-V). The Physical Host vNIC is isolated from the containers. Network connectivity to Hyper-V containers is transparent to the utility VM through the vmNIC. External connectivity is provided in a number of ways. Each one depends on the scenario you are using for containers. For example, if you want to offer a container environment for developers, Network Address Translation (NAT) is the best option for container network. It provides a private IP space (IPs issued via DHCP) that is isolated from the outside world.
It restricts cross-container connectivity but does give you the ability to port forward into the container environment with which
you are working. Any traffic arriving on the public NAT IP (the external NIC IP of the host) will be
compared to a table managed via WinNAT and forwarded into the container. If the developers or the business required a small deployment and required that the containers sit on the corporate IP space, you can use transparent networking for containers. This just uses (via DHCP or Static Assignment) your existing IP space to assign IPs to the containers you run. If you do not use DHCP, you are unable to set a Gateway IP address. In transparent networking, containers can communicate with one another and external services like SQL and so on.