test

Sun Management Center 4.0 Installation and Configuration Guide

Appendix D Network Address Translation

This appendix describes the issues related to using Sun Management Center 4.0 in a Network Address Translation (NAT) environment, and outlines the factors that affect the overall approach to a Sun Management Center NAT solution.

This appendix discusses the following topics.

NAT Concepts

Network Address Translation (NAT) enables servers, hosts, and consoles on different networks to communicate with each other across a common internal network. A NAT solution maps the private local address realm to a public address realm. These mappings can be static or dynamic.

NAT is becoming increasingly prevalent in Sun Management Center client environments. By using NAT, clients can make more efficient use of network addresses and, in some cases, provide secure access to external networks from sensitive internal environments.

Note –

The term Sun Management Center NAT host refers to any host that is running a Sun Management Center component (agent, server, or console) and that must communicate with other Sun Management Center components across a NAT environment.

Use of IP Addresses With NAT

Sun Management Center 4.0 assumes that the IP address and port of a managed node can be used to uniquely identify and access the managed node within a server context. Furthermore, the software assumes that the local IP address and port of a managed node are authoritative.

As a result of these assumptions, Sun Management Center makes extensive use of IP addresses in both its core operation and its management functionality. Specifically, network addresses are used in the following areas:

In environments where Sun Management Center components operate across one or more NAT environments, the assumptions regarding the uniqueness and accessibility of the local IP addresses and ports of managed nodes break down. Furthermore, because administrators might be more familiar with the node's public IP address, the use of local IP addresses to identify managed nodes in a NAT environment might no longer be intuitive.

How NAT Works

The following figure illustrates how NAT works.

Figure D–1 Simple NAT Network Conceptual Diagram

Simple NAT Network Conceptual Diagram

The private subnet 10.1.1.0 has one machine called Machine 1 that runs behind NAT 1, which uses 129.146.63.100, a translated IP address, for all communication from Machine 1 to hosts outside NAT 1. Communication from hosts outside NAT 1 to Machine 1 (129.146.63.100) are redirected to Machine 1 (10.1.1.1) by NAT 1.

A second private subnet (100.1.1.1) has one machine Machine 3 (100.1.1.1) and runs behind NAT 2, which uses 129.146.63.101 (a translated IP) for communication from Machine 3 to hosts outside NAT 2. Communication from hosts outside NAT 2 to Machine 3 (129.146.63.101) is redirected to 100.1.1.1 by NAT 2.

Complexity of the NAT Solution

The extensive use of IP addresses in Sun Management Center complicates deployment in environments that involve simple address or proxy translations. The addresses appear at the driver, library, application, and console integration levels. The solution is further complicated by the types of communication that occur in Sun Management Center.

This software is a distributed application with the following layers:

The software layers can reside on a different host or on different networks that could be subject to routing rules or NAT.

Furthermore, the console, server, or agent components of one Sun Management Center system can potentially communicate with components of another Sun Management Center system on another network. These aspects add to the complexity of the solution.

NAT enables Sun Management Center 4.0 to operate in a network environment where the consoles, servers, and agents are deployed in one or more network addressing realms. As a result, the consoles, servers, and agents must communicate across one or more NAT environments.

The functionality also supports cross-server context operation such as remote reference domains across NAT environments. With NAT, Sun Management Center components can also communicate with other Sun Management Center components in the same addressing realm. Without NAT, Sun Management Center consoles, servers and agents cannot operate across NAT environments.

NAT Configuration

Static NAT mappings must be defined for every Sun Management Center NAT host.

Note –

Dynamic NAT mappings are not supported for Sun Management Center 4.0 operation across the NAT.

Because several undefined ports are used by Sun Management Center, Sun Management Center does not support the ability to specify port restrictions for Sun Management Center NAT support. These ports include SNMP, probe, RMI, and console integration.

To support operation in a NAT environment, NAT enables Sun Management Center 4.0 software to use names rather than IP addresses to identify and communicate with other Sun Management Center hosts. The name must be a host alias that can be resolved to a valid IP address through standard naming services. This name also must be resolvable to the appropriate IP address in the relevant addressing realms in which the Sun Management Center components are deployed.

Thus, common host aliases for all Sun Management Center NAT hosts must be defined in the host maps of all addressing realms in which Sun Management Center components are installed.

The host aliases must be defined in the standard system host maps that can include such things as the files, for example, /etc/hosts, NIS, NIS+, and DNS. For the remainder of this chapter, the common host alias is referred to as the NAT host name.

NAT Solution

The Sun Management Center NAT solution is focused on self-consistency to avoid complex or error-prone translation mechanisms. This solution addresses the fundamental assumption regarding the use of IP addresses in the software.

Sun Management Center 4.0 uses logical identifiers, rather than IP addresses, to uniquely identify and access the nodes managed by the software in NAT environments. The identifiers can be the fully qualified host name of a managed node. This method enables Sun Management Center 4.0 to leverage the existing host name-to-IP address mapping infrastructure in IP-based systems.

In environments where the use of fully qualified host names are not appropriate or feasible, any logical name that is unique and resolvable from the agent and server layer addressing realm can be used. In non-NAT environments, the logical identifiers can default to IP addresses for backward compatibility.

This solution requires that the logical identifier must be unique within a server context. The logical identifiers must be resolvable to valid IP addresses that can be used to access the managed node across a NAT environment. You should be able to use the logical identifiers to intuitively identify managed nodes.

When using the Sun Management Center 4.0 NAT solution, note the following information:

NAT Limitations

The following NAT limitations exist:

NAT Examples

This section provides examples of a single NAT environment and a dual NAT environment.

Single NAT Environment

The basic NAT example involves a single NAT environment where a single server context is deployed on both sides of the NAT.

Figure D–2 Simple NAT Network Configuration Example

Simple NAT Network Configuration Example

The figure shows the console, a server layer, and an agent deployed in the 192.168.0.0 network. A console and three agents are deployed in the 192.168.1.0 network behind the NAT. All of the agents, including the remote agents, are part of the server context managed by the server layer on Host B.

Sun Management Center assumes that these components are configured to operate in the host name logical addressing mode. Therefore, all agents are configured with Host B as their trap and event destinations.

To support this configuration, the network host and NAT maps listed in Figure D–2 must be complete. The three remote agents on Hosts E, F, and G are accessible from the 192.168.0.0 network using static NAT mappings. Furthermore, the logical identifiers of Hosts E, F and G must also be resolvable to valid IP addresses in the 192.168.0.0 network. This step is accomplished through the host mappings for Hosts E, F, and G in the 192.168.0.0 network.

To allow the remote agents to name Host B as their trap and event destinations, a host map entry for Host B is specified in the 192.168.1.0 network host map.

Dual NAT Environment

The following figure illustrates a more complex example. The figure shows a dual NAT environment with three Sun Management Center server contexts with remote reference domains.

Figure D–3 Complex NAT Network Configuration Example

Complex NAT Network Configuration Example

In the figure, the 192.168.0.0 network is in front of the NAT environments, while the 192.168.1.0 and 192.168.2.0 networks are behind the NAT environments. SunScreen 1 provides the 192.168.0.0 network with access to hosts on the 192.168.1.0 network. SunScreen 2 provides the 192.168.0.0 network with access to hosts in the 192.168.2.0 network. Static NAT mappings are assumed.

Host maps in the three addressing realms provide host name resolution for all hosts on which Sun Management Center server and agent components are deployed. All Sun Management Center components are assumed to have been configured with the host name logical addressing mode.