Charles M. Kozierok The TCP-IP Guide

Подождите немного. Документ загружается.

R2 won't know how to translate back the destination address on the incoming datagram. Of

course, this makes dynamic mapping extremely difficult: routers would have to coordinate

their address mappings.

Key Concept: In unidirectional (traditional) NAT, the NAT router translates the

source address of an outgoing request from inside local to inside global form. It then

transforms the destination address of the response from inside global to inside local.

The outside local and outside global addresses are the same in both request and reply.

IP NAT Bidirectional (Two-Way/Inbound) Operation

Traditional NAT is designed to handle only outbound transactions; clients on the local

network initiate requests and devices on the Internet send back responses. However, in

some circumstances, we may want to go in the opposite direction. That is, we may want to

have a device on the outside network initiate a transaction with one on the inside. To permit

this, we need a more capable type of NAT than the traditional version. This enhancement

goes by various names, most commonly Bidirectional NAT, Two-Way NAT and Inbound

NAT. All of these convey the concept that this kind of NAT allows both the type of trans-

action we saw in the previous topic and also transactions initiated from the outside network.

The Problem With Inbound NAT: Hidden Addresses

Performing NAT on inbound transactions is more difficult than conventional outbound NAT.

To understand why, remember that the network configuration when using NAT is inherently

asymmetric: the inside network generally knows the IP addresses of outside devices,

since they are public, but the outside network doesn't know the private addresses of the

inside network. Even if they did know them, they could never be specified as the target of

an IP datagram initiated from outside since they are not routable—there would be no way to

get them to the private network's local router.

Why does this matter? Well, consider the case of outbound NAT from device A on the inside

network to device B on the outside. The local client, A, always starts the transaction, so

device A's NAT router is able to create a mapping between device A's inside local and

inside global address during the request. Device B is the recipient of the already-translated

datagram, so the fact that device A is using NAT is hidden. Device B responds back and the

NAT router does the reverse translation without device B ever even knowing NAT was used

for device A.

Now, let's look at the inbound case. Here, device B is trying to send to device A, which is

using NAT. Device B can't send to device A's private (inside local) address. It needs device

A's inside global address in order to start the ball rolling. However, device A's NAT router

isn't proximate to device B. In fact, device B probably doesn’t even know the identity of

device A’s NAT router!

Facilitating Inbound NAT Using DNS

There only two methods to resolve the hidden address problem. One is to use static

mapping for devices like servers on the inside network that need to be accessed from the

outside. When static mapping is employed, the global address of the device that is using

the static mapping will be publicly known, which solves the “where do I send my request to”

problem.

The other solution is to make use of the TCP/IP Domain Name System (DNS). As explained

in detail in the section on DNS, this protocol allows requests to be sent as names instead of

IP addresses; the DNS server translates these names to their corresponding addresses. It

is possible to integrate DNS and NAT so they work together. This process is described in

RFC 2694, DNS extensions to Network Address Translators (DNS_ALG)

In this technique, an outside device can in fact make use of dynamic mapping. The basic

process (highly simplified) is as follows:

1. The outside device sends a DNS request using the name of the device on the inside

network it wishes to reach. For example, it might be “www.ilikenat.com”.

2. The DNS server for the internal network resolves the “www.ilikenat.com” name into an

inside local address for the device that corresponds to this DNS entry.

3. The inside local address is passed to NAT and used to create a dynamic mapping

between the inside local address of the server being accessed from the outside, and

an inside global address. This mapping is put into the NAT router's translation table.

4. When the DNS server sends back the name resolution, it tells the outside device not

the inside local (private) address of the server being sought, but the inside global

(public) address mapped in the previous step.

Bidirectional NAT Example

Once the inside global address of the device on the inside network is known by the outside

device, the transaction can begin. Let's use the same example as in the previous topic, only

we reverse it, so that outside device 204.51.16.12 is initiating a request (and is thus now the

client) to inside device 10.0.0.207 (which is the server). Let's say that either static mapping

or DNS has been used so that the outside device knows the inside global address of

10.0.0.207 is actually 194.54.21.6. Table 76 describes the transaction in detail; it is illus-

trated in Figure 113 as well.

As you can see, once the outside device knows the inside device's inside global address,

inbound NAT is very similar to outbound NAT. It just does the exact opposite translation.

Instead of modifying the source address on the outbound request and the destination on

the inbound response, the router changes the destination on the inbound request and the

source on the outbound reply.

Table 76: Operation Of Bidirectional (Two-Way/Inbound) NAT

Step

Description

Data-

gram

Type

Datagram

Source

Address

Datagram

Destination

Address

Outside Client Generates Request And Sends

To NAT Router: Device 204.51.16.12 generates

a request to the inside server. It uses the inside

global address 194.54.21.6 as the destination.

The datagram will be routed to the local router for

that address, which is the NAT router that

services the inside network where the server is

located.

Request

(from

outside

client to

inside

server)

204.51.16.12

(Outside Global)

194.54.21.6

(Inside Global)

NAT Router Translates Destination Address

and Sends To Inside Server: The NAT router

already has a mapping from the inside global

address to the inside local address of the server.

It replaces the 194.54.21.6 destination address

with 10.0.0.207, and performs checksum recalcu-

lations and other work as necessary. The source

address is not translated. The router then delivers

the modified datagram to the inside server at

10.0.0.207.

204.51.16.12

(Outside Local)

10.0.0.207

(Inside Local)

Inside Server Generates Response And

Sends Back To NAT Router: The server at

10.0.0.207 generates a response, which it

addresses to 204.51.16.12 since that was the

source of the request to it. This is then routed to

the server's NAT router.

Response

(from

inside

server to

outside

client)

10.0.0.207

(Inside Local)

204.51.16.12

(Outside Local)

NAT Router Translates Source Address And

Routes Datagram To Outside Client: The NAT

router sees the private address 10.0.0.207 in the

response and replaces it with 194.54.21.6. It then

routes this back to the original client on the

outside network.

194.54.21.6

(Inside Global)

204.51.16.12

(Outside Global)

Key Concept: In traditional NAT, a transaction must begin with a request from a

client on the local network, but in bidirectional (two-way/inbound) NAT, it is possible

for a device on the public Internet to access a local network server. This requires the

use of either static mapping or DNS to provide to the outside client the address of the server

on the inside network. Then the NAT transaction is pretty much the same as in the unidirec-

tional case, except in reverse: the incoming request has its destination address changed

from inside global to inside local; the response has its source changed from inside local to

inside global.

Figure 113: Operation Of Bidirectional (Two-Way/Inbound) NAT

This figure is very similar to Figure 112, except that the transaction is in reverse, so please start at the upper

right and go counter-clockwise. Translated addresses are shown in bold. Table 76 contains a complete expla-

nation of the four steps. Refer to Figure 111 for an explanation of address types.

Source 204.51.16.12

Destination 194.54.21.6

Request

Source 204.51.16.12

Destination

10.0.0.207

Translated Request

Source

194.54.21.6

Destination 204.51.16.12

Translated Response

Source 10.0.0.207

Destination 204.51.16.12

Response

1. Client Sends Request

2. NAT Router Translates

Destination Address

NAT

Router

3. Server Sends Response

4. NAT Router Translates

Source Address

Internet

Local Network

("Inside")

Public Internet

("Outside")

Inside Local Address

Outside Local Address

Inside Global Address

Outside Global Address

Server

10.0.0.207

Server

204.51.16.12

IP NAT Port-Based ("Overloaded") Operation: Network Address Port

Translation (NAPT) / Port Address Translation (PAT)

Both traditional NAT and bidirectional NAT work by swapping inside network and outside

network addresses as needed to allow a private network to access a public one. For each

transaction, there is a one-to-one mapping between the inside local address of a device on

the private network, and the inside global address that represents it on the public network.

We can use dynamic address assignment to allow a large number of private hosts to share

a small number of registered public addresses.

However, there is a potential snag here. Consider our earlier NAT example, where 250

hosts share 20 inside global (public) addresses. If 20 hosts already have transactions in

progress, what happens when the 21st tries to access the Internet? There aren't any inside

global addresses available for it to use, so it won't be able to.

Using Ports to Multiplex Private Addresses

Fortunately, there is a mechanism already built into TCP/IP that can help us alleviate this

situation. The two TCP/IP transport layer protocols, TCP and UDP, both make use of

additional addressing components called ports. The port number in a TCP or UDP message

helps identify individual connections between two addresses. It is used to allow many

different applications on a TCP/IP client and server to talk to each simultaneously, without

interference. For example, you use this capability when you open multiple browser windows

to access more than one Web page on the same site at the same time. This sharing of IP

addresses amongst many connections is called multiplexing. The section on TCP and UDP

ports describes all of this in much more detail.

Now, let's come back to NAT. We are already translating IP addresses as we send

datagrams between the public and private portions of the internetwork. What if we could

also translate port numbers? Well, we can! The combination of an address and port

uniquely identifies a connection. As a datagram passes from the private network to the

public one, we can change not just the IP address but also the port number in the TCP or

UDP header. The datagram will be sent out with a different source address and port. The

response will come back to this same address and port combination (called a socket) and

can be translated back again.

This method goes by various names. Since it is a technique whereby we can have multiple

inside local addresses share a single inside global address, it is called overloading of an

inside global address, or alternately, just overloaded NAT. More elegant names that better

indicate how the technique works include Port-Based NAT, Network Address Port Trans-

lation (NAPT) and Port Address Translation (PAT).

Whatever its name, the use of ports in translation has tremendous advantages. It can allow

all 250 hosts on our private network to use only 20 IP addresses—and potentially even

fewer than that. In theory you could even have all 250 share a single public IP address at

once! You don't want to share so many local hosts that you run out of port numbers, but

there are thousands of port numbers to choose from.

Port-based NAT of course requires a router that is programmed to make the appropriate

address and port mappings for datagrams as it transfers them between networks. The

disadvantages of the method include this greater complexity, and also more potential

compatibility issues (such as with applications like FTP) since we must now watch for port

numbers at higher layers and not just IP addresses.

Key Concept: Port-based or “overloaded” NAT is an enhancement of regular NAT

that allows a large number of devices on a private network to simultaneously “share”

a single inside global address by changing the port numbers used in TCP and UDP

messages.

Port-Based NAT Example

The operation of NAPT/PAT is very similar to the way regular NAT works, except that port

numbers are also translated. For a traditional outbound transaction, the source port number

is changed on the request at the same time that the source address is modified; the desti-

nation port number is modified on the response with the destination address.

Let's consider again the example we looked at in the topic on Traditional NAT, but this time

in a PAT environment. Device 10.0.0.207 was one of 250 hosts on a private network

accessing the WWW server at 204.51.16.12. Let's say that because PAT is being used, to

save money all 250 are sharing a single inside global address, 194.54.21.7, instead of a

pool of 20. The transaction would proceed as described in Table 77 and diagrammed in

Figure 114.

Table 77: Operation Of Port-Based (“Overloaded”) NAT

Step

Description

Data-

gram

Type

Datagram

Source

Address:Port

Datagram

Destination

Address:Port

Inside Client Generates Request And Sends

To NAT Router: Device 10.0.0.207 generates

an HTTP request to the server at 204.51.16.12.

The standard server port for WWW is 80, so the

destination port of the request is 80; let's say

the source port on the client is 7000. The

datagram is sent to the NAT-capable router that

connects the organization's internal network to

the Internet.

Request

(from

inside

client to

outside

server)

10.0.0.207:7000

(Inside Local)

204.51.16.12:80

(Outside Local)

NAT Router Translates Source Address And

Port And Sends To Outside Server: The NAT

router realizes that 10.0.0.207 is an inside local

address and knows it must substitute an inside

global address. Here though, there are multiple

hosts sharing the single inside global address

194.54.21.7. Lets say that port 7000 is already

in use for that address by another private host

connection. The router substitutes the inside

global address and also chooses a new source

port number, say 7224, for this request. The

destination address and port are not changed.

The NAT router puts the address and port

mapping into its translation table. It sends the

modified datagram out, which arrives at the

server at 204.51.16.12.

194.54.21.7:7224

(Inside Global)

204.51.16.12

(Outside Global)

Outside Server Generates Response And

Sends Back To NAT Router: The server at

204.51.16.12 generates an HTTP response. It

of course has no idea that NAT was involved; it

sees an address of 194.54.21.7 and port of

7224 in the request sent to it, so it sends back

to that address and port.

Response

(from

outside

server to

inside

client)

204.51.16.12:80

(Outside Global)

194.54.21.7:7224

(Inside Global)

NAT Router Translates Destination Address

And Port And Delivers Datagram To Inside

Client: The NAT router sees the address

94.54.21.7 and port 7224 in the response that

arrived from the Internet. It consults its trans-

lation table and knows this datagram is

intended for 10.0.0.207, port 7000. This time

the destination address and port are changed

but not the source. The router then delivers the

datagram back to the originating client.

204.51.16.12:80

(Outside Local)

10.0.0.207:7000

(Inside Local)

Key Concept: In port-based NAT, the NAT router translates the source address and

port of an outgoing request from inside local to inside global form. It then transforms

the destination address and port of the response from inside global to inside local.

The outside local and outside global addresses are the same in both request and reply.

One other issue related to NAPT/PAT is worth mentioning: it assumes that all traffic uses

either UDP or TCP at the transport layer. While generally the case, this may not always be

true. If there is no port number, port translation cannot be done and the method will not

work.

Figure 114: Operation Of Port-Based (“Overloaded”) NAT

This figure is very similar to Figure 112, except that the source and destination port numbers have been

shown, since they are used in this type of NAT. Translated addresses/ports are in bold. Table 77 contains a

complete explanation of the four steps in port-based NAT. Refer to Figure 111 for an explanation of address

types.

Source 10.0.0.207 7000

Destination 204.51.16.12 80

Request

Source

194.54.21.7 7224

Destination 204.51.16.12 80

Translated Request

Source 204.51.16.12 80

Destination

10.0.0.207 7000

Translated Response

Source 204.51.16.12 80

Destination 194.54.21.7 7224

Response

1. Client Sends Request

2. NAT Router Translates

Source Address & Port

NAT

Router

3. Server Sends Response

4. NAT Router Translates

Destination Address & Port

Internet

Client

10.0.0.207

Server

204.51.16.12

Local Network

("Inside")

Public Internet

("Outside")

Inside Local Address

Outside Local Address

Inside Global Address

Outside Global Address

IP NAT "Overlapping" / "Twice NAT" Operation

All three of the versions of NAT discussed so far—traditional, bidirectional and port-based—

are normally used to connect a network using private, non-routable addresses to the public

Internet, which uses unique, registered, routable addresses. With these kinds of NAT, there

will normally be no overlap between the address spaces of the inside and outside network,

since the former are private and the latter public. This enables the NAT router to be able to

immediately distinguish inside addresses from outside addresses just by looking at them.

In the examples we've seen so far, the inside addresses were all from the RFC 1918 block

10.0.0.0. These can't be public Internet addresses so the NAT router knew any address

referenced by a request from the inside network within this range was a local reference

within the inside network. Similarly, any addresses outside this range are easy to identify as

belonging to the “outside world”.

Cases With Overlapping Private and Public Address Blocks

There are circumstances however where there may indeed be an overlap between the

addresses used for the inside network, and the addresses used for part of the outside

network. Consider the following cases:

☯ Private Network To Private Network Connections: Our example network using

10.0.0.0 block addresses might want to connect to another network using the same

method. This situation might occur if two corporations merge and happened to be

using the same addressing scheme (and there aren't that many private IP blocks, so

this isn't that uncommon).

☯ Invalid Assignment of Public Address Space To Private Network: Some networks

might have been set up not using a designated private address block but rather a

block containing valid Internet addresses. For example, suppose an administrator

decided that the network he was setting up “would never be connected to the Internet”

(ha!) and numbered the whole thing using 18.0.0.0 addresses, which belong to the

Massachusetts Institute of Technology (MIT). Then later, this administrator's short-

sightedness would backfire when the network did indeed need to be connected to the

'net.

☯ “Stale” Public Address Assignment: Company A might have been using a particular

address block for years that was reassigned or reallocated for whatever reason to

company B. Company A might not want to go through the hassle of renumbering their

network, and would then keep their addresses even while Company B started using

them on the Internet.

What these situations all have in common is that the inside addresses used in the private

network overlap with addresses on the public network. When a datagram is sent from

within the local network, the NAT router can't tell if the intended destination is within the

inside network or the outside network. For example, if we want to connect host 10.0.0.207

in our private network to host 10.0.0.199 in a different network, and we put 10.0.0.199 in the

destination of the datagram and send it, how does the router know if we mean 10.0.0.199

on our own local network or the remote one? For that matter, we might need to send a

request to 10.0.0.207 in the other private network, our own address! Take the network that

was numbered with MIT's address block. How does the router know when a datagram is

actually being sent to MIT as opposed to another device on the private network?

Dealing With Overlapping Blocks By Using NAT Twice

The solution to this dilemma is to use a more sophisticated form of NAT. The other versions

we have seen so far always translate either the source address or the destination address

as a datagram passes from the inside network to the outside network or vice versa. To cope

with overlapping addresses, we must translate both the source address and the destination

address on each transition from the inside to the outside or the other direction. This

technique is called Overlapping NAT in reference to the problem it solves, or “Twice NAT”

due to how it solves it. (Incidentally, despite the latter name, regular NAT is not called “Once

NAT”.)

Twice NAT functions by creating a set of mappings not only for the private network the NAT

router serves, but also for the overlapping network (or networks) that conflict with the inside

network's address space. In order for this to function, Twice NAT relies on the use of the

TCP/IP Domain Name System (DNS), just like bidirectional NAT. This lets the inside

network send requests to the overlapping network in a way that can be uniquely identified.

Otherwise, the router can't tell what overlapping network our inside network is trying to

contact.

“Overlapping” / “Twice” NAT Example

Let's try a new example. Suppose our network has been improperly numbered so that it is

not in the 10.0.0.0 private block but in the 18.0.0.0 block used by MIT. A client on our private

network, 18.0.0.18, wants to send a request to the server “www.twicenat.mit.edu”, which

has the address 18.1.2.3 at MIT. Our client can't just make a datagram with 18.1.2.3 as the

destination and send out, as the router will think it's on the local network and not route it.

Instead, 18.0.0.18 uses a combination of DNS and NAT to get the outside device address

as follows:

1. The client on our local network (18.0.0.18) sends a DNS request to get the address of

“www.twicenat.mit.edu”.

2. The (Twice-NAT compatible) NAT router serving our local network intercepts this DNS

request. It then consults its tables to find a special mapping for this outside device.

Let's say, it is programmed to translate “www.twicenat.mit.edu” into the address

172.16.44.55. This is a private non-routable RFC 1918 address.

3. The NAT router returns this value, 172.16.44.55 to the source client, which uses it for

the destination.

Once our client has the translated address, it initiates a transaction just as before. NAT now

will perform both translation of the inside devices and the outside devices as well. The

outside device address must be translated because the inside device is using

172.16.44.55, which isn't a valid address for the server it is trying to reach. The inside