Full cone nat что это в роутере

    Introduction

    This document describes the need for Session Traversal Utilities for NAT (STUN) servers, the types of Network Address Translation (NAT) setups with respect to STUN servers, how NAT causes an issue in this setup and the solution.

    Background Information

    The primary purpose of NAT devices is to allow devices with private IP addresses in a local-area network (LAN) to communicate with devices in public address spaces, such as the Internet. However, although NAT devices are supposed to allow internal hosts to connect with the public space, when it comes to Point-to-Point (P2P) applications like VoIP, gaming, WebRTC, and file-sharing where the end-users need to act as both client and server to maintain 2-way end-to-end communication, NAT provides difficulty to establish those UDP connections. NAT traversal techniques are typically required to make these applications work.

    Need for NAT Traversal

    Real-time voice and video communication on the Internet are mainstream today with several popular instant messengers (IMs) that support VoIP calls. A big hurdle in the initial adoption of VoIP was the fact that most PCs or other devices sit behind firewalls and use private IP addresses. Multiple private addresses (IP address and port) in the network are mapped to a single public address by a firewall with NAT. But the end device is not aware of its public address, and hence cannot receive voice traffic from the remote party on the private address it advertises in its VoIP communication.   

    Unilateral Self-Address Fixing (UNSAF) processes are processes whereby some originating endpoint attempts to determine or fix the address (and port) by which it is known to another endpoint — for example, to be able to use address data in the protocol exchange or to advertise a public address from which it receives connections. 

    The P2P connections under discussion are hence UNSAF processes. One common way P2P applications establish peering sessions and remain NAT-friendly is when they use a publicly addressable rendezvous server for registration and peer discovery purposes.

    Session Traversal Utilities for NAT

    As per RFC 5389, STUN provides a tool that deals with NATs. It provides a means for an endpoint to determine the IP address and port allocated by a NAT device that corresponds to its private IP address and port. It also provides a way for an endpoint to keep a NAT binding alive.

    Types of NAT Implementations

    It has been observed that the NAT treatment of UDP varies among implementations. The four treatments observed in implementations are:  

    Full Cone: A full cone NAT is one where all requests from the same internal IP address and port are mapped to the same external IP address and port. Furthermore, any external host can send a packet to the internal host, and it sends a packet to the mapped external address.

    Restricted Cone: A restricted cone NAT is one where all requests from the same internal IP address and port are mapped to the same external IP address and port. Unlike a full cone NAT, an external host (with IP address X) can send a packet to the internal host only if the internal host had previously sent a packet to IP address X.   

    Port Restricted Cone: A port-restricted cone NAT is like a restricted cone NAT, but the restriction includes port numbers. Specifically, an external host can send a packet, with source IP address X and source port P, to the internal host only if the internal host had previously sent a packet to IP address X and port P.   

    Symmetric: A symmetric NAT is one where all requests from the same internal IP address and port to a specific destination IP address and port, are mapped to the same external IP address and port.  If the same host sends a packet with the same source address and port, but to a different destination, a different mapping is used.  Furthermore, only the external host that receives a packet can send a UDP packet back to the internal host.

    Consider a topology where the source (A, Pa) (where A is the IP Address, and Pa is the source port) communicates with the destination (B, Pb) and (C, PC) through a NAT device.

    Type of NAT implementation

    Public source when destined to (B, Pb)

    Public source when destined to (C, Pc)

    Can destination (for example: (B, Pb) ) send traffic to (A, Pa)?

    Full Cone

    (X1,Px1)

    (X1,Px1)

    Yes

    Restricted Cone

    (X1,Px1)

    (X1,Px1)

    Only if (A, Pa) had first sent the traffic to B

    Port Restricted Cone

    (X1,Px1)

    (X1,Px1)

    Only if (A, Pa) had first sent the traffic to (B, Pb)

    Symmetric

    (X1,Px1)

    (X2,Px2)

    Only if (A, Pa) had first sent the traffic to (B, Pb)

    Issues with NAT Traversal and Symmetric NAT

    STUN servers respond to STUN binding requests sent by STUN clients and provide the public IP/port of the client. Now, this address/port combination is used by the STUN client in its peer-to-peer communication signaling. However, now that the endhost uses the same private address/port (let us assume that is bound to the public IP/port provided in the STUN response) the NAT device translates it to the same IP but a different port if symmetric NAT implementation is used. This breaks the UDP communication because the signalling had established the connection based on the previous port. 

    Cisco IOS® routers’ NAT implementation when it performs PAT is symmetric by default. Therefore, you are expected to see UDP connection issues with these routers that perform NAT.

    However, the Cisco IOS-XE routers’ NAT implementation when it performs PAT is not symmetric. When you send two different streams with the same source IP and port but to different destinations, the source gets NATED to the same inside global IP and port.

    The Solution to the Issue

    From this description, it is clear that the issue can be resolved if you perform Endpoint-Independent mapping. 

    As per RCFC 4787: With Endpoint-Independent Mapping (EIM), the NAT reuses the port mapping for subsequent packets sent from the same internal IP address and port (X:x) to any external IP address and port. 

    From a client, when the endhost runs the commands nc -p 23456 10.0.0.4 40000 and nc -p 23456 10.0.0.5 50000, on two different terminal windows, here are the results of the NAT translations if you use EIM:

    Pro Inside global       Inside local             Outside local        Outside global
    tcp 10.0.0.1:23456   192.168.0.2:23456  10.0.0.4:40000 10.0.0.4:40000
    tcp 10.0.0.1:23456   192.168.0.2:23456  10.0.0.5:50000 10.0.0.5:50000 

    Here you can see that different traffic flows that have the same source address and port get translated to the same address/port regardless of the destination port/address. 

    On Cisco IOS routers, you can enable Endpoint Agnostic Port Allocation with the command ip nat service enable-sym-port.

    https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_nat/configuration/15-mt/nat-15-mt-book/iadnat-fpg-port-alloc.html

    Summary

    Cisco IOS NAT implementation is symmetric by default when you use Port Address Translation (PAT) and it can cause issues when it passes P2P UDP traffic that requires servers like STUN for NAT traversal. You need to explicitly configure EIM on the NAT device to make this work.

    Источник

    NAT – трансляция сетевых адресов, позволяет локальным (частным) сетям, использующим незарегистрированные IP-адреса, подключаться к Интернету. NAT работает на маршрутизаторе, обычно соединяя две сети вместе, и преобразует частные адреса во внутренней сети в публичные адреса, прежде чем пакеты будут перенаправлены в другую сеть.

    В рамках этой возможности NAT может быть настроен для объявления только одного адреса для всей сети внешнему миру. Это обеспечивает дополнительную безопасность, эффективно скрывая за этим адресом всю внутреннюю сеть. NAT предлагает двойные функции безопасности и сохранения адресов и обычно реализуется в средах удаленного доступа.

    Как работает

    NAT позволяет одному устройству, например маршрутизатору, действовать как агент между Интернетом и локальной сетью, представляя доступ устройствам за пределами своей сети.

    Зачем это нужно

    В качестве примера возьмем игровые консоли. Когда вы подключаете PlayStation 4/5 или Xbox к беспроводному маршрутизатору, хотя вы можете подключиться к Xbox Live / PlayStation Network, однако возникают следующие проблемы:

    • Не слышно голоса друзей в онлайн-играх или на вечеринках
    • Не можете организовать многопользовательскую онлайн-игру или присоединиться к ней

    Например, PlayStation 4/5 необходимо установить Type NAT 1 (позволяет создавать многопользовательскую игру) или Type NAT 2 (не позволяет создавать многопользовательскую игру, но можно подключиться к другим игрокам).

    Full Cone NAT

    Все запросы с одного и того же внутреннего IP-адреса и порта с одним и тем же внешний IP-адресом и портом. Любой внешний хост может отправить пакет внутреннему хосту, отправив пакет на назначенный внешний адрес.

    Restricted Cone NAT

    Все запросы с одного и того же внутреннего IP-адреса и порта с одним и тем же внешний IP-адресом и портом. В отличие от Full Cone NAT, внешний хост (с IP-адресом X) может отправить пакет на внутренний хост только в том случае, если внутренний хост ранее отправил пакет на IP-адрес X.

    Port Restricted NAT

    То же, что и Restricted Cone NAT, но в этом случае обращается внимание на соответствие номера порта источника, и не обращает внимания на адрес источника. Маршрутизатор будет транслировать входящие пакеты с любым адресом источника, но порт источника при этом обязан быть 53, в противном случае пакет будет уничтожен маршрутизатором.

    Symmetric NAT

    Все запросы с одного и того же внутреннего IP-адреса и порта на определенный IP-адрес и порт назначения, сопоставляется с одним и тем же внешний IP-адресом и портом. Если один и тот же хост отправляет пакет с тем же адресом источника и портом, но в другое место назначения, используется другое сопоставление. Только внешний хост, который получает пакет от внутреннего хоста, может отправить пакет обратно.

    Проблемы

    В Symmetric NAT некоторые онлайн-игры или потоковые сервисы могут работать некорректно. В настоящее время вы можете переключиться на Fullcone NAT, чтобы обеспечить нормальное использование связанных сервисов, однако с менее безопасным.

    Если у вас нет особых потребностей или после завершения игры, рекомендуется настроить тип NAT на Symmetric NAT по умолчанию, чтобы сделать внутреннюю сетевую среду более безопасной.

    Дополнительные материалы

    • Cisco: NAT
    • NAT Types and Hole-Punching
    Источник

    Table of Contents

    • NAT Types and NAT Traversal

      • Basic Concepts

        • Transport Address

        • Packet transmission

        • Inbound NAT transmission

      • Types of NAT

        • Full Cone NAT

        • (Address-)Restricted Cone NAT

        • Port-Restricted Cone NAT

        • Symmetric NAT

      • Types of NAT in the Real World

      • NAT Traversal

        • Do-It-Yourself hole punching

        • PyNAT

    Sources:

    • Wikipedia: Network address translation

    • Symmetric NAT and It’s Problems (archive)

    • Peer-to-Peer Communication Across Network Address Translators (archive)

    • The hole trick — How Skype & Co. get round firewalls (archive)

    • What type of NAT combinations requires a TURN server?

    • Under what scenarios Server- and Peer-Reflexive candidates differ?

    Basic Concepts

    Transport Address

    A Transport Address is the combination of a host’s IP address and a port. When talking about transmission of packets between hosts, we’ll refer to them in terms of the transport addresses of both the source and the destination.

    Packet transmission

    In order to talk about traffic flows in this document, we’ll refer to packet transmissions as the fact of sending data packets from a source to a destination host. The transmission is represented by the transport addresses of each host, plus a direction:

    (SRC_ADDR, SRC_PORT) -> (DST_ADDR, DST_PORT)

    Note

    • -> denotes the direction of the transmission.

    • (ADDR, PORT) denotes a transport address.

    • (SRC_ADDR, SRC_PORT) is the transport address of the host that sends packets.

    • (DST_ADDR, DST_PORT) is the transport address of the host that receives packets.

    Inbound NAT transmission

    A NAT maintains inbound rules which are used to translate transport addresses between the NAT’s external and internal sides. Usually, the external side of the NAT is facing the public internet (WAN), while the internal side of the NAT is facing a private local network (LAN).

    The inbound rules have the form of a hash table (or map), which stores a direct relationship between a pair of external transport addresses (a quadruplet) and a uniquely corresponding internal transport address. In other words:

    • Given the quadruplet formed by the NAT external transport address, and a remote host’s transport address …

    • … there is an inbound rule for an internal transport address.

    Typically, these NAT rules are created automatically during an outbound transmission that originated from within the LAN towards some remote host: it is at that moment when the NAT creates a new entry into its table (this is step 1 in the following visualizations). Later, this entry in the NAT table is used to decide which local host needs to receive the response that the remote host might send (this is step 2 in the visualizations). Rules created in this way are called “dynamic rules”; on the other hand, “static rules” can be explicitly created by an administrator, in order to set up a fixed NAT table.

    Visualization:

        {NAT internal side}  |    {NAT external side}  |  {Remote host}
                         |                         |
1. (INT_ADDR, INT_PORT) => [ (EXT_ADDR, EXT_PORT) -> (REM_ADDR, REM_PORT) ]
2. (INT_ADDR, INT_PORT) <= [ (EXT_ADDR, EXT_PORT) <- (REM_ADDR, REM_PORT) ]

    Meaning: Some host initiated an outbound packet transmission from the IP address INT_ADDR and port INT_PORT, towards the remote host at REM_ADDR and port REM_PORT. When the first packet crossed the NAT, it automatically created a dynamic rule, translating the internal transport address (INT_ADDR, INT_PORT) into the external transport address (EXT_ADDR, EXT_PORT). EXT_ADDR is the external IP address of the NAT, while EXT_PORT might be the same as INT_PORT, or it might be different (that is up to the NAT to decide).

    Note

    • -> and <- denote the direction of the transmission in each step.

    • => denotes the creation of a new rule in the NAT table.

    • [ (ADDR, PORT), (ADDR, PORT) ], with square brackets, denotes the transport address quadruplet used to access the NAT mapping table.

    • <= denotes the resolution of the NAT mapping.

    • (INT_ADDR, INT_PORT) is the source transport address on the internal side of the NAT for a local host making a transmission during step 1, and it is the destination transport address for the same host receiving the transmission during step 2.

    • (EXT_ADDR, EXT_PORT) is the source transport address on the external side of the NAT from where a transmission is originated during step 1, and it is the destination transport address for the transmission being received during step 2.

    • (REM_ADDR, REM_PORT) is the destination transport address of some remote host receiving a transmission during step 1, and it is the source transport address of a remote host that makes a transmission during step 2.

    Types of NAT

    There are two categories of NAT behavior, namely Cone and Symmetric NAT. The crucial difference between them is that the former will use the same port numbers for internal and external transport addresses, while the latter will always use different numbers for each side of the NAT. This will be explained later in more detail.

    Besides, there are 3 types of Cone NATs, with varying degrees of restrictions regarding the allowed sources of inbound transmissions. To connect with a local host which is behind a Cone NAT, it’s first required that the local host performs an outbound transmission to a remote one. This way, a dynamic rule will be created for the destination transport address, allowing the remote host to connect back. The only exception is the Full Cone NAT, where a static rule can be created beforehand by an administrator, thanks to the fact that this kind of NAT ignores what is the source transport address of the remote host that is connecting.

    Full Cone NAT

    This type of NAT allows inbound transmissions from any source IP address and any source port, as long as the destination tuple exists in a previously created rule.

    Typically, these rules are statically created beforehand by an administrator. These are the kind of rules that are used to configure Port Forwarding (aka. “opening the ports”) in most consumer-grade routers. Of course, as it is the case for all NAT types, it is also possible to create dynamic rules by first performing an outbound transmission.

    Visualization:

        {NAT internal side}  |    {NAT external side}  |  {Remote host}
                         |                         |
1. (INT_ADDR, INT_PORT) => [ (EXT_ADDR, INT_PORT) -> (REM_ADDR, REM_PORT) ]
2. (INT_ADDR, INT_PORT) <= [ (EXT_ADDR, INT_PORT) <- (   *    ,    *    ) ]

    Note

    • * means that any value could be used: a remote host can connect from any IP address and port.

    • The source IP address (REM_ADDR) in step 2 can be different from the destination IP address that was used in step 1.

    • The source IP port (REM_PORT) in step 2 can be different from the destination IP port that was used in step 1.

    • The same port (INT_PORT) is used in the internal and the external sides of the NAT. This is the most common case for all Cone NATs, only being different for Symmetric NATs.

    (Address-)Restricted Cone NAT

    This type of NAT allows inbound transmissions from a specific source IP address but allows for any source port. Typically, an inbound rule of this type was previously created dynamically, when the local host initiated an outbound transmission to a remote one.

    Visualization:

        {NAT internal side}  |    {NAT external side}  |  {Remote host}
                         |                         |
1. (INT_ADDR, INT_PORT) => [ (EXT_ADDR, INT_PORT) -> (REM_ADDR, REM_PORT) ]
2. (INT_ADDR, INT_PORT) <= [ (EXT_ADDR, INT_PORT) <- (REM_ADDR,    *    ) ]

    Note

    • The source IP address (REM_ADDR) in step 2 must be the same as the destination IP address that was used in step 1.

    • The source IP port (REM_PORT) in step 2 can be different from the destination IP port that was used in step 1.

    • The same port (INT_PORT) is used in the internal and the external sides of the NAT.

    Port-Restricted Cone NAT

    This is the most restrictive type of Cone NAT: it only allows inbound transmissions from a specific source IP address and a specific source port. Again, an inbound rule of this type was previously created dynamically, when the local host initiated an outbound transmission to a remote one.

    Visualization:

        {NAT internal side}  |    {NAT external side}  |  {Remote host}
                         |                         |
1. (INT_ADDR, INT_PORT) => [ (EXT_ADDR, INT_PORT) -> (REM_ADDR, REM_PORT) ]
2. (INT_ADDR, INT_PORT) <= [ (EXT_ADDR, INT_PORT) <- (REM_ADDR, REM_PORT) ]

    Note

    • The source IP address (REM_ADDR) in step 2 must be the same as the destination IP address that was used in step 1.

    • The source IP port (REM_PORT) in step 2 must be the same as the destination IP port that was used in step 1.

    • The same port (INT_PORT) is used in the internal and the external sides of the NAT.

    Symmetric NAT

    This type of NAT behaves in the same way of a Port-Restricted Cone NAT, with an important difference: for each outbound transmission to a different remote transport address (i.e. to a different remote host), the NAT assigns a new random source port on the external side. This means that two consecutive transmissions from the same local port to two different remote hosts will have two different external source ports, even if the internal source transport address is the same for both of them.

    This is also the only case where the ICE connectivity protocol will find Peer Reflexive candidates which differ from the Server Reflexive ones, due to the differing ports between the transmission to the STUN server and the direct transmission between peers.

    Visualization:

        {NAT internal side}  |    {NAT external side}  |  {Remote host}
                         |                         |
1. (INT_ADDR, INT_PORT) => [ (EXT_ADDR, EXT_PORT1) -> (REM_ADDR, REM_PORT1) ]
2. (INT_ADDR, INT_PORT) <= [ (EXT_ADDR, EXT_PORT1) <- (REM_ADDR, REM_PORT1) ]
...
3. (INT_ADDR, INT_PORT) => [ (EXT_ADDR, EXT_PORT2) -> (REM_ADDR, REM_PORT2) ]
4. (INT_ADDR, INT_PORT) <= [ (EXT_ADDR, EXT_PORT2) <- (REM_ADDR, REM_PORT2) ]

    Note

    • When the outbound transmission is done in step 1, EXT_PORT1 gets defined as a new random port number, assigned for the new remote transport address (REM_ADDR, REM_PORT1).

    • Later, another outbound transmission is done in step 3, from the same local address and port to the same remote host but at a different port. EXT_PORT2 is a new random port number, assigned for the new remote transport address (REM_ADDR, REM_PORT2).

    Types of NAT in the Real World

    Quoting from Wikipedia:

    This terminology has been the source of much confusion, as it has proven inadequate at describing real-life NAT behavior. Many NAT implementations combine these types, and it is, therefore, better to refer to specific individual NAT behaviors instead of using the Cone/Symmetric terminology. RFC 4787 attempts to alleviate this issue by introducing standardized terminology for observed behaviors. For the first bullet in each row of the above table, the RFC would characterize Full-Cone, Restricted-Cone, and Port-Restricted Cone NATs as having an Endpoint-Independent Mapping, whereas it would characterize a Symmetric NAT as having an Address- and Port-Dependent Mapping. For the second bullet in each row of the above table, RFC 4787 would also label Full-Cone NAT as having an Endpoint-Independent Filtering, Restricted-Cone NAT as having an Address-Dependent Filtering, Port-Restricted Cone NAT as having an Address and Port-Dependent Filtering, and Symmetric NAT as having either an Address-Dependent Filtering or Address and Port-Dependent Filtering. There are other classifications of NAT behavior mentioned, such as whether they preserve ports, when and how mappings are refreshed, whether external mappings can be used by internal hosts (i.e., its Wikipedia: Hairpinning behavior), and the level of determinism NATs exhibit when applying all these rules.[2]

    Especially, most NATs combine symmetric NAT for outbound transmissions with static port mapping, where inbound packets addressed to the external address and port are redirected to a specific internal address and port. Some products can redirect packets to several internal hosts, e.g., to divide the load between a few servers. However, this introduces problems with more sophisticated communications that have many interconnected packets, and thus is rarely used.

    NAT Traversal

    The NAT mechanism is implemented in a vast majority of home and corporate routers, and it completely prevents the possibility of running any kind of server software in a local host that sits behind these kinds of devices. NAT Traversal, also known as Hole Punching, is the procedure of opening an inbound port in the NAT tables of these routers.

    To connect with a local host which is behind any type of NAT, it’s first required that the local host performs an outbound transmission to the remote one. This way, a dynamic rule will be created for the destination transport address, allowing the remote host to connect back.

    In order to tell one host when it has to perform an outbound transmission to another one, and the destination transport address it must use, the typical solution is to use a helper service such as STUN. This is usually managed by a third host, a server sitting on a public internet address. It retrieves the external IP and port of each peer, and gives that information to the other peers that want to communicate.

    STUN / TURN requirements:

    • Symmetric to Symmetric: TURN.

    • Symmetric to Port-Restricted Cone: TURN.

    • Symmetric to Address-Restricted Cone: STUN (but probably not reliable).

    • Symmetric to Full Cone: STUN.

    • Everything else: STUN.

    Do-It-Yourself hole punching

    It is very easy to test the NAT capabilities in a local network. To do this, you need access to two machines:

    • One outside the NAT, e.g. by directly connecting it to the internet, with no firewall. We’ll call this the [Server].

    • One sitting behind a NAT. This is the typical situation for consumer-grade home networks, so this one will be the [Client].

    Set some helper variables: the public IP address of each host, and their listening ports:

    SERVER_IP="203.0.113.2"  # Public IP address of the Server
SERVER_PORT="1111"       # Listening port of the Server

CLIENT_IP="198.51.100.1" # Public IP address of the NAT that hides the Client
CLIENT_PORT="2222"       # Listening port of the Client

    1. [Client] starts listening for data. Leave this running in [Client]:

    2. [Server] tries to send data, but the NAT in front of [Client] will discard the packets. Run in [Server]:

      echo "TEST" | nc -vnu -p "$SERVER_PORT" "$CLIENT_IP" "$CLIENT_PORT"

    3. [Client] performs a hole punch, forcing its NAT to create a new inbound rule. [Server] awaits for the UDP packet, for verification purposes.

      Run in [Server]:

      sudo tcpdump -n -i eth0 "src host $CLIENT_IP and udp dst port $SERVER_PORT"

      Run in [Client]:

      sudo hping3 --count 1 --udp --baseport "$CLIENT_PORT" --keep --destport "$SERVER_PORT" "$SERVER_IP"

      As an alternative to hping3, it’s also possible to use plain netcat:

      echo "TEST" | nc -vnu -p "$CLIENT_PORT" "$SERVER_IP" "$SERVER_PORT"

    4. [Server] tries to send data again. Run in [Server]:

      echo "TEST" | nc -vnu -p "$SERVER_PORT" "$CLIENT_IP" "$CLIENT_PORT"

      After this command, you should see the “TEST” string appearing on the Client.

    Note

    The difference between a Cone NAT and a Symmetric NAT can be detected during step 3:

    • If the tcpdump command on [Server] shows a source port equal to $CLIENT_PORT, then the NAT is respecting the source port chosen by the application, which means that it is one of the Cone NAT types.

      In this case, the data sent from [Server] should arrive correctly at [Client] after step 4.

    • However, if tcpdump shows that the source port is different from $CLIENT_PORT, then the NAT is changing the source port during outbound mapping, which means that it is a Symmetric NAT.

      When this happens, the data sent from [Server] won’t arrive at [Client] after step 4, because $CLIENT_PORT is the wrong destination port. If you write the correct port (as discovered in step 3) instead of $CLIENT_PORT, then the data should arrive at [Client].

    PyNAT

    PyNAT is a tool that uses STUN servers in order to try and detect what is the type of the NAT, when running from a host behind it. To install and run:

    sudo apt-get update ; sudo apt-get install --no-install-recommends \
    python3 python3-pip

sudo -H python3 -m pip install --upgrade pynat

pynat

    You will see an output similar to this:

    $ pynat
Network type: Restricted-port NAT
Internal address: 192.168.1.2:54320
External address: 203.0.113.9:54320
    Источник

    В свое время, когда я пытался понять как работают различные типы NAT маршрутизаторов. С одной стороны количество статей на эту тему оказалось крайне мало. С другой стороны, исходя из того что было, понять их было крайне сложно. Попробую написать понятное объяснение с максимумом картинок и минимумом определений. Перевод оригинальной английской терминологии на русский язык резанул по ушам, поэтому решил ее оставить как есть.

    Cone NAT

    Внутренний адрес (192.168.0.2:2210) проецируются на внешний адрес (1.1.1.2:8801). Любой пакет посланный с 192.168.0.2:2210 будет послан через 1.1.1.2:8801. Любой пакет с внешнего хоста, посланный на адрес 1.1.1.2:8801 будет отправлен на 192.168.0.2:2210

    Full cone nat

    Full cone nat

    Address-Restricted cone NAT или Restricted cone NAT.

    Внутренний адрес (192.168.0.2:2210) проецируются на внешний адрес (1.1.1.2:8801). Любой пакет посланный с 192.168.0.2:2210 будет послан через 1.1.1.2:8801. Пакет с любого порта внешнего хоста, посланный на адрес 1.1.1.2:8801 будет отправлен на 192.168.0.2:2210 только в случае, если 192.168.0.2:2210 предварительно посылал пакет на этот внешний хост.

    Address-Restricted cone NAT

    Port-Restricted cone NAT

    Внутренний адрес (192.168.0.2:2210) проецируются на внешний адрес (1.1.1.2:8801). Любой пакет посланный с 192.168.0.2:2210 будет послан через 1.1.1.2:8801. Внешний хост (1.1.1.30:1234) модет послать пакет на 192.168.0.2:2210 через 1.1.1.2:8801 только в случае если ранее 192.168.0.2:2210 слал пакет на 1.1.1.30:1234

    Port-Restricted cone NAT

    Symmetric NAT

    Каждый пакет с определенного внутреннего IP адреса:порта на определенный внешний IP адрес:порт будет иметь после трансляции уникальный внешний адрес порт. Соответственно, пакет с одного и того-же внутреннего адреса:порта, но посланный на другой внешний хост или порт после трансляции будет иметь другой внешний адрес-порт. Внешние хосты могут послать обратный пакет только на те хосты:порты откуда они получили пакеты.

    Symmetric NAT

    Symmetric NAT

    Еще одна, часто встречающаяся особенность NAT, так называемый port preservation, такой гибрид Port-Restricted и Symmetric NAT, будет рассмотрен в другой статье.

    Источник

    Network address translation between a private network and the Internet

    Network address translation (NAT) is a method of mapping an IP address space into another by modifying network address information in the IP header of packets while they are in transit across a traffic routing device.[1] The technique was originally used to bypass the need to assign a new address to every host when a network was moved, or when the upstream Internet service provider was replaced, but could not route the network’s address space. It has become a popular and essential tool in conserving global address space in the face of IPv4 address exhaustion. One Internet-routable IP address of a NAT gateway can be used for an entire private network.[2]

    As network address translation modifies the IP address information in packets, NAT implementations may vary in their specific behavior in various addressing cases and their effect on network traffic. The specifics of NAT behavior are not commonly documented by vendors of equipment containing NAT implementations.[2]

    Basic NAT

    The simplest type of NAT provides a one-to-one translation of IP addresses (RFC 1631). RFC 2663 refers to this type of NAT as basic NAT; it is also called a one-to-one NAT. In this type of NAT, only the IP addresses, IP header checksum, and any higher-level checksums that include the IP address are changed. Basic NAT can be used to interconnect two IP networks that have incompatible addressing.[2]

    One-to-many NAT

    Network address mapping

    The majority of network address translators map multiple private hosts to one publicly exposed IP address.

    Here is a typical configuration:

    1. A local network uses one of the designated private IP address subnets (RFC 1918[3]).
    2. The network has a router having both a private and a public address. The private address is used by the router for communicating with other devices in the private local network. The public address (typically assigned by an Internet service provider) is used by the router for communicating with the rest of the Internet.
    3. As traffic passes from the network to the Internet, the router translates the source address in each packet from a private address to the router’s own public address. The router tracks basic data about each active connection (particularly the destination address and port). When the router receives inbound traffic from the Internet, it uses the connection tracking data it stored during the outbound phase to determine to which private address (if any) it should forward the reply.[2]

    All IP packets have a source IP address and a destination IP address. Typically, packets passing from the private network to the public network will have their source address modified, while packets passing from the public network back to the private network will have their destination address modified. To avoid ambiguity in how replies are translated, further modifications to the packets are required. The vast bulk of Internet traffic uses Transmission Control Protocol (TCP) or User Datagram Protocol (UDP). For these protocols, the port numbers are changed so that the combination of IP address (within the IP header) and port number (within the Transport Layer header) on the returned packet can be unambiguously mapped to the corresponding private network destination. RFC 2663 uses the term network address and port translation (NAPT) for this type of NAT.[3] Other names include port address translation (PAT), IP masquerading, NAT overload and many-to-one NAT. This is the most common type of NAT and has become synonymous with the term «NAT» in common usage.

    This method allows communication through the router only when the conversation originates in the private network, since the initial originating transmission is what establishes the required information in the translation tables. Thus a web browser within the private network would be able to browse websites that are outside the network, whereas web browsers outside the network would be unable to browse a website hosted within.[a] Protocols not based on TCP and UDP require other translation techniques.

    An additional benefit of one-to-many NAT is that it mitigates IPv4 address exhaustion by allowing entire networks to be connected to the Internet using a single public IP address.[b]

    Methods of translation

    Network address and port translation may be implemented in several ways. Some applications that use IP address information may need to determine the external address of a network address translator. This is the address that its communication peers in the external network detect. Furthermore, it may be necessary to examine and categorize the type of mapping in use, for example when it is desired to set up a direct communication path between two clients both of which are behind separate NAT gateways.

    For this purpose, RFC 3489 specified a protocol called Simple Traversal of UDP over NATs (STUN) in 2003. It classified NAT implementations as full-cone NAT, (address) restricted-cone NAT, port-restricted cone NAT or symmetric NAT, and proposed a methodology for testing a device accordingly. However, these procedures have since been deprecated from standards status, as the methods are inadequate to correctly assess many devices. RFC 5389 standardized new methods in 2008 and the acronym STUN now represents the new title of the specification: Session Traversal Utilities for NAT.

    NAT implementation classifications

    Full-cone NAT, also known as one-to-one NAT

    • Once an internal address (iAddr:iPort) is mapped to an external address (eAddr:ePort), any packets from iAddr:iPort are sent through eAddr:ePort.
    • Any external host can send packets to iAddr:iPort by sending packets to eAddr:ePort.
    (Address)-restricted-cone NAT

    • Once an internal address (iAddr:iPort) is mapped to an external address (eAddr:ePort), any packets from iAddr:iPort are sent through eAddr:ePort.
    • An external host (hAddr:any) can send packets to iAddr:iPort by sending packets to eAddr:ePort only if iAddr:iPort has previously sent a packet to hAddr:any. «Any» means the port number doesn’t matter.
    Port-restricted cone NAT Like an address restricted cone NAT, but the restriction includes port numbers.

    • Once an internal address (iAddr:iPort) is mapped to an external address (eAddr:ePort), any packets from iAddr:iPort are sent through eAddr:ePort.
    • An external host (hAddr:hPort) can send packets to iAddr:iPort by sending packets to eAddr:ePort only if iAddr:iPort has previously sent a packet to hAddr:hPort.
    Symmetric NAT

    • The combination of one internal IP address plus a destination IP address and port is mapped to a single unique external source IP address and port; if the same internal host sends a packet even with the same source address and port but to a different destination, a different mapping is used.
    • Only an external host that receives a packet from an internal host can send a packet back.

    Many NAT implementations combine these types, so it is better to refer to specific individual NAT behavior instead of using the Cone/Symmetric terminology. RFC 4787 attempts to alleviate confusion by introducing standardized terminology for observed behaviors. For the first bullet in each row of the above table, the RFC would characterize Full-Cone, Restricted-Cone, and Port-Restricted Cone NATs as having an Endpoint-Independent Mapping, whereas it would characterize a Symmetric NAT as having an Address- and Port-Dependent Mapping. For the second bullet in each row of the above table, RFC 4787 would also label Full-Cone NAT as having an Endpoint-Independent Filtering, Restricted-Cone NAT as having an Address-Dependent Filtering, Port-Restricted Cone NAT as having an Address and Port-Dependent Filtering, and Symmetric NAT as having either an Address-Dependent Filtering or Address and Port-Dependent Filtering. Other classifications of NAT behavior mentioned in the RFC include whether they preserve ports, when and how mappings are refreshed, whether external mappings can be used by internal hosts (i.e., its hairpinning behavior), and the level of determinism NATs exhibit when applying all these rules.[2] Specifically, most NATs combine symmetric NAT for outgoing connections with static port mapping, where incoming packets addressed to the external address and port are redirected to a specific internal address and port.

    Type of NAT and NAT traversal, role of port preservation for TCP

    The NAT traversal problem arises when peers behind different NATs try to communicate. One way to solve this problem is to use port forwarding. Another way is to use various NAT traversal techniques. The most popular technique for TCP NAT traversal is TCP hole punching.

    TCP hole punching requires the NAT to follow the port preservation design for TCP. For a given outgoing TCP communication, the same port numbers are used on both sides of the NAT. NAT port preservation for outgoing TCP connections is crucial for TCP NAT traversal because, under TCP, one port can only be used for one communication at a time, so programs bind distinct TCP sockets to ephemeral ports for each TCP communication, rendering NAT port prediction impossible for TCP.[2]

    On the other hand, for UDP, NATs do not need port preservation. Indeed, multiple UDP communications (each with a distinct endpoint) can occur on the same source port, and applications usually reuse the same UDP socket to send packets to distinct hosts. This makes port prediction straightforward, as it is the same source port for each packet.

    Furthermore, port preservation in NAT for TCP allows P2P protocols to offer less complexity and less latency because there is no need to use a third party (like STUN) to discover the NAT port since the application itself already knows the NAT port.[2][4]

    However, if two internal hosts attempt to communicate with the same external host using the same port number, the NAT may attempt to use a different external IP address for the second connection or may need to forgo port preservation and remap the port.[2]: 9 

    As of 2006, roughly 70% of the clients in P2P networks employed some form of NAT.[5]

    Implementation

    Establishing two-way communication

    In bidirectional NAT the session can be established both from inside and outside realms.

    Every TCP and UDP packet contains a source port number and a destination port number. Each of those packets is encapsulated in an IP packet, whose IP header contains a source IP address and a destination IP address. The IP address/protocol/port number triple defines an association with a network socket.

    For publicly accessible services such as web and mail servers the port number is important. For example, port 80 connects through a socket to the web server software and port 25 to a mail server’s SMTP daemon. The IP address of a public server is also important, similar in global uniqueness to a postal address or telephone number. Both IP address and port number must be correctly known by all hosts wishing to successfully communicate.

    Private IP addresses as described in RFC 1918 are usable only on private networks not directly connected to the internet. Ports are endpoints of communication unique to that host, so a connection through the NAT device is maintained by the combined mapping of port and IP address. A private address on the inside of the NAT is mapped to an external public address. Port address translation (PAT) resolves conflicts that arise when multiple hosts happen to use the same source port number to establish different external connections at the same time.

    Telephone number extension analogy

    A NAT device is similar to a phone system at an office that has one public telephone number and multiple extensions. Outbound phone calls made from the office all appear to come from the same telephone number. However, an incoming call that does not specify an extension cannot be automatically transferred to an individual inside the office. In this scenario, the office is a private LAN, the main phone number is the public IP address, and the individual extensions are unique port numbers.[6]

    Translation process

    With NAT, all communications sent to external hosts actually contain the external IP address and port information of the NAT device instead of internal host IP addresses or port numbers. NAT only translates IP addresses and ports of its internal hosts, hiding the true endpoint of an internal host on a private network.

    When a computer on the private (internal) network sends an IP packet to the external network, the NAT device replaces the internal source IP address in the packet header with the external IP address of the NAT device. PAT may then assign the connection a port number from a pool of available ports, inserting this port number in the source port field. The packet is then forwarded to the external network. The NAT device then makes an entry in a translation table containing the internal IP address, original source port, and the translated source port. Subsequent packets from the same internal source IP address and port number are translated to the same external source IP address and port number. The computer receiving a packet that has undergone NAT establishes a connection to the port and IP address specified in the altered packet, oblivious to the fact that the supplied address is being translated.

    Upon receiving a packet from the external network, the NAT device searches the translation table based on the destination port in the packet header. If a match is found, the destination IP address and port number is replaced with the values found in the table and the packet is forwarded to the inside network. Otherwise, if the destination port number of the incoming packet is not found in the translation table, the packet is dropped or rejected because the PAT device doesn’t know where to send it.

    Visibility of operation

    NAT operation is typically transparent to both the internal and external hosts. The NAT device may function as the default gateway for the internal host which is typically aware of the true IP address and TCP or UDP port of the external host. However, the external host is only aware of the public IP address for the NAT device and the particular port being used to communicate on behalf of a specific internal host.

    Applications

    Routing
    Network address translation can be used to mitigate IP address overlap.[7][8] Address overlap occurs when hosts in different networks with the same IP address space try to reach the same destination host. This is most often a misconfiguration and may result from the merger of two networks or subnets, especially when using RFC 1918 private network addressing. The destination host experiences traffic apparently arriving from the same network, and intermediate routers have no way to determine where reply traffic should be sent to. The solution is either renumbering to eliminate overlap or network address translation.
    Load balancing
    In client–server applications, load balancers forward client requests to a set of server computers to manage the workload of each server. Network address translation may be used to map a representative IP address of the server cluster to specific hosts that service the request.[9][10][11][12]

    IEEE Reverse Address and Port Translation (RAPT or RAT) allows a host whose real IP address changes from time to time to remain reachable as a server via a fixed home IP address.[13] Cisco’s RAPT implementation is PAT or NAT overloading and maps multiple private IP addresses to a single public IP address. Multiple addresses can be mapped to a single address because each private address is tracked by a port number. PAT uses unique source port numbers on the inside global IP address to distinguish between translations.[c] PAT attempts to preserve the original source port. If this source port is already used, PAT assigns the first available port number starting from the beginning of the appropriate port group 0–511, 512–1023, or 1024–65535. When there are no more ports available and there is more than one external IP address configured, PAT moves to the next IP address to try to allocate the original source port again. This process continues until it runs out of available ports and external IP addresses.

    Mapping of Address and Port is a Cisco proposal that combines Address plus Port translation with tunneling of the IPv4 packets over an ISP provider’s internal IPv6 network. In effect, it is an (almost) stateless alternative to carrier-grade NAT and DS-Lite that pushes the IPv4 address/port translation function (and the maintenance of NAT state) entirely into the existing customer premises equipment NAT implementation. Thus avoiding the NAT444 and statefulness problems of carrier-grade NAT, and also provides a transition mechanism for the deployment of native IPv6 at the same time with very little added complexity.

    Issues and limitations

    Hosts behind NAT-enabled routers do not have end-to-end connectivity and cannot participate in some internet protocols. Services that require the initiation of TCP connections from the outside network, or that use stateless protocols such as those using UDP, can be disrupted. Unless the NAT router makes a specific effort to support such protocols, incoming packets cannot reach their destination. Some protocols can accommodate one instance of NAT between participating hosts («passive mode» FTP, for example), sometimes with the assistance of an application-level gateway (see § Applications affected by NAT), but fail when both systems are separated from the internet by NAT. The use of NAT also complicates tunneling protocols such as IPsec because NAT modifies values in the headers which interfere with the integrity checks done by IPsec and other tunneling protocols.

    End-to-end connectivity has been a core principle of the Internet, supported, for example, by the Internet Architecture Board. Current Internet architectural documents observe that NAT is a violation of the end-to-end principle, but that NAT does have a valid role in careful design.[14] There is considerably more concern with the use of IPv6 NAT, and many IPv6 architects believe IPv6 was intended to remove the need for NAT.[15]

    An implementation that only tracks ports can be quickly depleted by internal applications that use multiple simultaneous connections such as an HTTP request for a web page with many embedded objects. This problem can be mitigated by tracking the destination IP address in addition to the port thus sharing a single local port with many remote hosts. This additional tracking increases implementation complexity and computing resources at the translation device.

    Because the internal addresses are all disguised behind one publicly accessible address, it is impossible for external hosts to directly initiate a connection to a particular internal host. Applications such as VOIP, videoconferencing, and other peer-to-peer applications must use NAT traversal techniques to function.

    Fragmentation and checksums

    Pure NAT, operating on IP alone, may or may not correctly parse protocols with payloads containing information about IP, such as ICMP. This depends on whether the payload is interpreted by a host on the inside or outside of the translation. Basic protocols as TCP and UDP cannot function properly unless NAT takes action beyond the network layer.

    IP packets have a checksum in each packet header, which provides error detection only for the header. IP datagrams may become fragmented and it is necessary for a NAT to reassemble these fragments to allow correct recalculation of higher-level checksums and correct tracking of which packets belong to which connection.

    TCP and UDP, have a checksum that covers all the data they carry, as well as the TCP or UDP header, plus a pseudo-header that contains the source and destination IP addresses of the packet carrying the TCP or UDP header. For an originating NAT to pass TCP or UDP successfully, it must recompute the TCP or UDP header checksum based on the translated IP addresses, not the original ones, and put that checksum into the TCP or UDP header of the first packet of the fragmented set of packets.

    Alternatively, the originating host may perform path MTU Discovery to determine the packet size that can be transmitted without fragmentation and then set the don’t fragment (DF) bit in the appropriate packet header field. This is only a one-way solution, because the responding host can send packets of any size, which may be fragmented before reaching the NAT.

    Variant terms

    DNAT

    Destination network address translation (DNAT) is a technique for transparently changing the destination IP address of a routed packet and performing the inverse function for any replies. Any router situated between two endpoints can perform this transformation of the packet.

    DNAT is commonly used to publish a service located in a private network on a publicly accessible IP address. This use of DNAT is also called port forwarding, or DMZ when used on an entire server, which becomes exposed to the WAN, becoming analogous to an undefended military demilitarized zone (DMZ).

    SNAT

    The meaning of the term SNAT varies by vendor:[16][17][18]

    • source NAT is a common expansion and is the counterpart of destination NAT (DNAT). This is used to describe one-to-many NAT; NAT for outgoing connections to public services.
    • stateful NAT is used by Cisco Systems[19]
    • static NAT is used by WatchGuard[20]
    • secure NAT is used by F5 Networks[21] and by Microsoft (in regard to the ISA Server)

    Secure network address translation (SNAT) is part of Microsoft’s Internet Security and Acceleration Server and is an extension to the NAT driver built into Microsoft Windows Server. It provides connection tracking and filtering for the additional network connections needed for the FTP, ICMP, H.323, and PPTP protocols as well as the ability to configure a transparent HTTP proxy server.

    Dynamic network address translation

    How dynamic NAT works.

    Dynamic NAT, just like static NAT, is not common in smaller networks but is found within larger corporations with complex networks. Where static NAT provides a one-to-one internal to public static IP address mapping, dynamic NAT uses a group of public IP addresses.[22][23]

    NAT hairpinning

    NAT hairpinning, also known as NAT loopback or NAT reflection,[24] is a feature in many consumer routers[25] where a machine on the LAN is able to access another machine on the LAN via the external IP address of the LAN/router (with port forwarding set up on the router to direct requests to the appropriate machine on the LAN). This notion is officially described in 2008, RFC 5128.

    The following describes an example network:

    • Public address: 203.0.113.1. This is the address of the WAN interface on the router.
    • Internal address of router: 192.168.1.1
    • Address of the server: 192.168.1.2
    • Address of a local computer: 192.168.1.100

    If a packet is sent to 203.0.113.1 by a computer at 192.168.1.100, the packet would normally be routed to the default gateway (the router)[d] A router with the NAT loopback feature detects that 203.0.113.1 is the address of its WAN interface, and treats the packet as if coming from that interface. It determines the destination for that packet, based on DNAT (port forwarding) rules for the destination. If the data were sent to port 80 and a DNAT rule exists for port 80 directed to 192.168.1.2, then the host at that address receives the packet.

    If no applicable DNAT rule is available, the router drops the packet. An ICMP Destination Unreachable reply may be sent. If any DNAT rules were present, address translation is still in effect; the router still rewrites the source IP address in the packet. The local computer (192.168.1.100) sends the packet as coming from 192.168.1.100, but the server (192.168.1.2) receives it as coming from 203.0.113.1. When the server replies, the process is identical to an external sender. Thus, two-way communication is possible between hosts inside the LAN network via the public IP address.

    NAT in IPv6

    Network address translation is not commonly used in IPv6 because one of the design goals of IPv6 is to restore end-to-end network connectivity.[26] The large addressing space of IPv6 obviates the need to conserve addresses and every device can be given a unique globally routable address. Use of unique local addresses in combination with network prefix translation can achieve results similar to NAT.

    The large addressing space of IPv6 can still be defeated depending on the actual prefix length given by the carrier. It is not uncommon to be handed a /64 prefix – the smallest recommended subnet – for an entire home network, requiring a variety of techniques to be used to manually subdivide the range for all devices to remain reachable.[27] Even actual IPv6-to-IPv6 NAT, NAT66, can turn out useful at times: the APNIC blog outlines a case where the author was only provided a single address (/128).[28]

    Applications affected by NAT

    Some application layer protocols, such as File Transfer Protocol (FTP) and Session Initiation Protocol (SIP), send explicit network addresses within their application data. FTP in active mode, for example, uses separate connections for control traffic (commands) and for data traffic (file contents). When requesting a file transfer, the host making the request identifies the corresponding data connection by its network layer and transport layer addresses. If the host making the request lies behind a simple NAT firewall, the translation of the IP address or TCP port number makes the information received by the server invalid. SIP commonly controls voice over IP calls, and suffer the same problem. SIP and its accompanying Session Description Protocol may use multiple ports to set up a connection and transmit voice stream via Real-time Transport Protocol. IP addresses and port numbers are encoded in the payload data and must be known before the traversal of NATs. Without special techniques, such as STUN, NAT behavior is unpredictable and communications may fail. Application Layer Gateway (ALG) software or hardware may correct these problems. An ALG software module running on a NAT firewall device updates any payload data made invalid by address translation. ALGs need to understand the higher-layer protocol that they need to fix, and so each protocol with this problem requires a separate ALG. For example, on many Linux systems, there are kernel modules called connection trackers that serve to implement ALGs. However, ALG cannot work if the protocol data is encrypted.

    Another possible solution to this problem is to use NAT traversal techniques using protocols such as STUN or Interactive Connectivity Establishment (ICE), or proprietary approaches in a session border controller. NAT traversal is possible in both TCP- and UDP-based applications, but the UDP-based technique is simpler, more widely understood, and more compatible with legacy NATs.[citation needed] In either case, the high-level protocol must be designed with NAT traversal in mind, and it does not work reliably across symmetric NATs or other poorly behaved legacy NATs.

    Other possibilities are Port Control Protocol (PCP),[29] NAT Port Mapping Protocol (NAT-PMP), or Internet Gateway Device Protocol but these require the NAT device to implement that protocol.

    Most client–server protocols (FTP being the main exception[e]), however, do not send layer 3 contact information and do not require any special treatment by NATs. In fact, avoiding NAT complications is practically a requirement when designing new higher-layer protocols today.

    NATs can also cause problems where IPsec encryption is applied and in cases where multiple devices such as SIP phones are located behind a NAT. Phones that encrypt their signaling with IPsec encapsulate the port information within an encrypted packet, meaning that NAT devices cannot access and translate the port. In these cases, the NAT devices revert to simple NAT operations. This means that all traffic returning to the NAT is mapped onto one client, causing service to more than one client behind the NAT to fail. There are a couple of solutions to this problem: one is to use TLS, which operates at layer 4 and does not mask the port number; another is to encapsulate the IPsec within UDP – the latter being the solution chosen by TISPAN to achieve secure NAT traversal, or a NAT with «IPsec Passthru» support; another is to use a session border controller to help traverse the NAT.

    Interactive Connectivity Establishment is a NAT traversal technique that does not rely on ALG support.

    The DNS protocol vulnerability announced by Dan Kaminsky on July 8, 2008,[30] is indirectly affected by NAT port mapping. To avoid DNS cache poisoning, it is highly desirable not to translate UDP source port numbers of outgoing DNS requests from a DNS server behind a firewall that implements NAT. The recommended workaround for the DNS vulnerability is to make all caching DNS servers use randomized UDP source ports. If the NAT function de-randomizes the UDP source ports, the DNS server becomes vulnerable.

    Examples of NAT software

    • Internet Connection Sharing (ICS): NAT & DHCP implementation included with Windows desktop operating systems
    • IPFilter: included with (Open)Solaris, FreeBSD and NetBSD, available for many other Unix-like operating systems
    • ipfirewall (ipfw): FreeBSD-native packet filter
    • Netfilter with iptables/nftables: the Linux packet filter
    • NPF: NetBSD-native packet filter
    • PF: OpenBSD-native packet filter
    • Routing and Remote Access Service (RRAS): routing implementation included with Windows Server operating systems
    • VPP: user space packet forwarding implementation for Linux
    • WinGate: third-party routing implementation for Windows

    See also

    • Anything In Anything (AYIYA) – IPv6 over IPv4 UDP, thus working IPv6 tunneling over most NATs
    • Carrier-grade NAT – NAT behind NAT within ISP.
    • Gateway (telecommunications) – Connection between two network systems
    • Internet Gateway Device Protocol (UPnP IGD) NAT-traversal method
    • Middlebox – Intermediary box on the data path between a source host and destination host
    • NAT Port Mapping Protocol (NAT-PMP) NAT-traversal method
    • Port Control Protocol (PCP) NAT-traversal method
    • Port triggering – NAT traversal mechanism
    • Subnetwork – Logical subdivision of an IP network
    • Teredo tunneling – NAT traversal using IPv6

    Notes

    1. ^ Most NAT devices today allow the network administrator to configure static translation table entries for connections from the external network to the internal masqueraded network. This feature is often referred to as static NAT. It may be implemented in two types: port forwarding which forwards traffic from a specific external port to an internal host on a specified port, and designation of a DMZ host which passes all traffic received on the external interface (on any port number) to an internal IP address while preserving the destination port. Both types may be available in the same NAT device.
    2. ^ The more common arrangement is having computers that require end-to-end connectivity supplied with a routable IP address, while having others that do not provide services to outside users behind NAT with only a few IP addresses used to enable Internet access.
    3. ^ The port numbers are 16-bit integers. The total number of internal addresses that can be translated to one external address could theoretically be as high as 65,536 per IP address. Realistically, the number of ports that can be assigned a single IP address is around 4000.
    4. ^ Unless an explicit route is set in the computer’s routing tables.
    5. ^ This issue can be avoided by using SFTP instead of FTP

    References

    1. ^ Network Protocols Handbook (2 ed.). Javvin Technologies Inc. 2005. p. 27. ISBN 9780974094526. Retrieved 2014-09-16.
    2. ^ a b c d e f g h François Audet; Cullen Jennings (January 2007). Network Address Translation (NAT) Behavioral Requirements for Unicast UDP. IETF. doi:10.17487/RFC4787. RFC 4787.
    3. ^ a b Wing, Dan (2010-07-01). «Network Address Translation: Extending the Internet Address Space». IEEE Internet Computing. 14 (4): 66–70. doi:10.1109/MIC.2010.96. ISSN 1089-7801. S2CID 31082389.
    4. ^ «Characterization and Measurement of TCP Traversal through NATs and Firewalls». December 2006.
    5. ^ «Illuminating the shadows: Opportunistic network and web measurement». December 2006. Archived from the original on 2010-07-24.
    6. ^ «The Audio over IP Instant Expert Guide» (PDF). Tieline. January 2010. Archived from the original (PDF) on 2011-10-08. Retrieved 2011-08-19.
    7. ^ «Using NAT in Overlapping Networks». August 2005.
    8. ^ «VPNs with Overlapping Subnets Problem Scenario». September 2017.
    9. ^ Srisuresh, Pyda; Gan, Der-Hwa (August 1998). «Load Sharing using IP Network Address Translation». doi:10.17487/RFC2391.
    10. ^ «What Is Layer 4 Load Balancing?». June 2020.
    11. ^ «What is load balancing?». November 2018.
    12. ^ «Configure Server Load Balancing Using Dynamic NAT». June 2018.
    13. ^ Singh, R.; Tay, Y.C.; Teo, W.T.; Yeow, S.W. (1999). «RAT: A quick (and dirty?) push for mobility support». Proceedings WMCSA’99. Second IEEE Workshop on Mobile Computing Systems and Applications. pp. 32–40. CiteSeerX 10.1.1.40.461. doi:10.1109/MCSA.1999.749275. ISBN 978-0-7695-0025-6. S2CID 7657883.
    14. ^ Bush, R.; Meyer, D. (2002). Some Internet Architectural Guidelines and Philosophy. IETF. doi:10.17487/RFC3439. RFC 3439.
    15. ^ Velde, G. Van de; Hain, T.; Droms, R.; Carpenter, B.; Klein, E. (2007). Local Network Protection for IPv6. IETF. doi:10.17487/RFC4864. RFC 4864.
    16. ^ «Enhanced IP Resiliency Using Cisco Stateful NAT». Cisco.
    17. ^ «Use NAT for Public Accessto Servers with Private IP Addresses on the Private Network (WatchGuard configuration example)» (PDF). www.watchguard.com. Archived from the original (PDF) on 2013-01-17.
    18. ^ «K7820: Overview of SNAT features». AskF5. August 28, 2007. Retrieved February 24, 2019.
    19. ^ «Enhanced IP Resiliency Using Cisco Stateful NAT». Cisco.
    20. ^ «Use NAT for Public Accessto Servers with Private IP Addresses on the Private Network (WatchGuard configuration example)» (PDF). www.watchguard.com. Archived from the original (PDF) on 2013-01-17.
    21. ^ «K7820: Overview of SNAT features». AskF5. August 28, 2007. Retrieved February 24, 2019.
    22. ^ «Dynamic NAT». 26 January 2016. Retrieved 2022-04-19.
    23. ^ «Dynamic NAT». Retrieved 2022-04-19.
    24. ^ «What is NAT Reflection/NAT Loopback/NAT Hairpinning?». NYC Networkers. 2014-11-09. Retrieved 2017-04-27.
    25. ^ «NAT Loopback Routers – OpenSim» (MediaWiki). OpenSimulator. 2013-10-21. Retrieved 2014-02-21.
    26. ^ Iljitsch van Beijnum (2008-07-23). «After staunch resistance, NAT may come to IPv6 after all». Ars Technica. Retrieved 2014-04-24.
    27. ^ Dupont, Kasper (Aug 18, 2015). «subnet — IPv6 subnetting a /64 — what will break, and how to work around it?». Server Fault. Retrieved 2023-04-20.
    28. ^ Cilloni, Marco (2018-02-01). «NAT66: The good, the bad, the ugly». APNIC Blog. Retrieved 2023-04-20.
    29. ^ D. Wing, Ed; Cheshire, S.; Boucadair, M.; Penno, R.; Selkirk, P. (2013). Port Control Protocol (PCP). IETF. doi:10.17487/RFC6887. RFC 6887.
    30. ^ Messmer, Ellen (2008-07-08). «Major DNS flaw could disrupt the Internet». Network World. Archived from the original on 2009-02-13. Retrieved 14 June 2021.

    External links

    • Characterization of different TCP NATs at the Wayback Machine (archived 2006-01-11) – Paper discussing the different types of NAT
    • Anatomy: A Look Inside Network Address Translators – Volume 7, Issue 3, September 2004
    • Jeff Tyson, HowStuffWorks: How Network Address Translation Works
    • Routing with NAT at archive.today (archived 2013-01-03) (Part of the documentation for the IBM iSeries)
    • Network Address Translation (NAT) FAQ – Cisco Systems
    Источник

  • Fttx роутер что это такое
  • Fttb или роутер wi fi что это
  • Fttb wifi роутер ростелеком цена
  • Fttb wifi роутер zxhn h298a
  • Fttb wifi роутер s1010 mts цена