TechNet網路技術: Linux NAT
摘自: http://linux-ip.net/html/ch-nat.html,
NAT and Networks: http://nuovolabs.fauser.edu/~valeria/materiale-didattico/SeR-quarta/NAT/node4.html
http://bbs.chinaunix.net/thread-2141555-1-1.html
網路位址轉換(NAT)，從本質上來講，是通過修改IP資料首部中的位址，以實現將一個位址轉換成另一個位址的技術。當然，在某些情況下，修改的不僅僅是IP首部的來源或目的地址，還包括其他要素。
隨著接入Internet的電腦數量的不斷猛增，IP位址資源也就愈加顯得捉襟見肘。目前NAT技術更多地被使用在將一個私網IP位址網段，轉換為一個或幾個公網IP位址，以實現私網與Internet的互相通訊。
Netfilter在連接跟蹤的基礎上，實現了兩種類型的位址轉換：源位址轉換和目的地址轉換。顧名思義，源位址轉換就是修改IP包中的源位址（或許還有源埠），而目的地址轉換，就是修改IP包中的目的地址（同樣，或許還有目的埠）。前者通常用於將內網主機私網位址轉換為公網位址，訪問Internet，後者通常用於將公網IP位址轉換為一個或幾個私網位址，實現向互聯網提供服務。
模組初始化
NAT模組對應的原始檔案是ip_nat_standard.c,
init_or_cleanup是它的初始化函數：
函数主要完成四个工作：
1. NAT规则表的初始化；
1. NAT规则表的初始化；
2. NAT所需的重要的数据结构的初始化；
3. 注册Hook；
4. 清除工作；
Conntrack
1. 什麼是連接跟蹤
連接跟蹤（CONNTRACK），顧名思義，就是跟蹤並且記錄連接狀態。Linux為每一個經過網路堆疊的資料包，生成一個新的連接記錄項（Connection entry）。此後，所有屬於此連接的資料包都被唯一地分配給這個連接，並標識連接的狀態。連接跟蹤是防火牆模組的狀態檢測的基礎，同時也是位址轉換中實現SNAT和DNAT的前提。
那麼Netfilter又是如何生成連接記錄項的呢？每一個資料，都有“來源”與“目的”主機，發起連接的主機稱為“來源”，回應“來源”的請求的主機即為目的，所謂生成記錄項，就是對每一個這樣的連接的產生、傳輸及終止進行跟蹤記錄。由所有記錄項產生的表，即稱為連接跟蹤表。
2. 連接跟蹤表
Netfilter使用一張連接跟蹤表，來描述整個連接狀態，這個表在實現演算法上採用了hash演算法。我們先來看看這個hash 表的實現。
整個hash表用全局指針ip_conntrack_hash
指針來描述，它定義在ip_conntrack_core.c中：
struct
list_head *ip_conntrack_hash;
這個hash表的大小是有限制的，表的大小由ip_conntrack_htable_size 總體變數決定，這個值，用戶態可以在模組插入時傳遞，默認是根據記憶體大小計算出來的。
NAT and Networks
http://linux-ip.net/html/ch-nat.html5.1. Rationale for and Introduction to NAT
Network address translation (NAT) is a technique of transparently mapping an IP address or range to another IP address or range. Any routing device situated between two endpoints can perform this transformation of the packet. Network designers must however take one key element under consideration when laying out a network with NAT in mind. The router(s) performing NAT must have an opportunity to rewrite the packet upon entry to the network and upon exit from the network [30].
Because network address translation manipulates the addressing of a packet, the NAT transformation becomes a passive but critical part of the conversation between hosts exchanging packets. NAT is by necessity transparent to the application layer endpoints and operates on any type of IP packet. There are some application and even network layer protocols which will break as a result of this rewriting. Consult Section 5.2, “Application Layer Protocols with Embedded Network Information” for a discussion of these cases.
Here are a few common reasons to consider NAT along with potential NAT solution candidates shown in parentheses.
- Publicly accessible services need to be provided on registered Internet IPs which change or might change. NAT allows the separation of internal IP addressing schemes from the public IP space, easing the burden of changing internal addressing or external IPs. (NAT, DNAT, PAT with DNAT PAT from userspace)
- An application requires inbound and outbound connections. In this case SNAT/masquerading will not suffice. See also Section 6.3, “Where Masquerading and SNAT Break”. (NAT, SNAT and application-aware connection tracking)
- The network numbering scheme is changing. Clever use of NAT allows reachability of services on both IP addresses or IP address ranges during the network numbering migration. (NAT, DNAT)
- Two networks share the same IP addressing space and need to exchange packets. Using network address translation to publish NAT network spaces with different numbering schemes would allow each network to retain the addressing scheme while accessing the other network. (NAT,DNAT, SNAT)
These are the commonest reasons to consider and implement NAT. Other niche applications of NAT, notably as part of load balancing systems, exist although this chapter will concentrate on the use of NAT to hide, isolate or renumber networks. It will also cover inbound connections, leaving the discussion of many-to-one NAT, SNAT and masquerading for Chapter 6, Masquerading and Source Network Address Translation.
One motivator for deploying NAT in a network is the benefit of virtualizing the network. By isolating services provided in one network from changes in other networks, the effects of such changes can be minimized. The disadvantage of virtualizing the network in this way is the increased reliance on the NAT device.
Providing inbound services via NAT can be accomplished in several different ways. Two common techniques are to use iproute2 NAT and netfilter DNAT. Less common (and possibly less desirable) one can use port redirection tools. Depending on which tool is employed, different characteristics of a packet can trigger the address transformation.
The simplest form of NAT under linux is iproute2 NAT. This type of NAT requires two matching commands, one to cause the kernel to rewrite the inbound packets (
ip route add nat $NATIP via $REAL) and one to rewrite the outbound packets (ip rule add from $REAL nat $NATIP). The router configured in this fashion will retain no state for connections. It will simply transform any packets passing through. By contrast, netfilter is capable of retaining state on connections passing through the router and selecting packets more granularly than is possible with only iproute2 tools.
Before the advent of the netfilter engine in the linux kernel, there were several tools available to administer NAT, DNAT and PAT. These tools were not included in many distributions and weren't adopted broadly in the community. Although you may find references to ipmasqadm, ipnatadmand ipportfw across the Internet in older documentation, these tools have been superseded in functionality and widespread deployment by the netfilter engine and its userspace partner, iptables.
The netfilter engine provides a more flexible language for selection of packets to be transformed than that provided by the iproute2 suite and kernel routing functionality. Additionally, any NAT services provided by the netfilter engine come with the labor-saving and resource-consuming connection tracking mechanism. DNAT translates the address on an inbound packet and creates an entry in the connection tracking state table. For even modest machines, the connection tracking resource consumption should not be problematic.
Netfilter DNAT allows the user to select packets based on characteristics such as destination port. This blurs the distinction between network address translation and port address translation. NAT always transforms the layer 3 contents of a packet. Port redirection operates at layer 4. From a practical perspective, there is little difference between a port redirection and a netfilter DNAT which has selected a single port. The manner in which the packet and contents are retransmitted, however, is tremendously different.
One other less common technique for furnishing inbound services is the use of port redirection. Although there are higher layer tools which can perform transparent application layer proxying (e.g. Squid), these are outside the scope of this documentation.
There are a number of IP addresses involved in any NAT transformations or connection states. The following list identifies these names and the convention used to describe each IP address. Beware that the prevalance of NAT to publish services on the Internet via public IP addresses has lead to the server/client lingo common in discussions of NAT.
- server NAT IP, NAT IP
- The IP address to which packets are addressed. This is the address on the packet before the device performing NAT manipulates it. This is frequently also described as the public IP, although any given application of NAT knows no distinction between public and private address ranges.
- real IP, server IP, hidden IP, private IP, internal IP
- The IP address after the NAT device has performed its transformation. Frequently, this is described as the private IP, although any given application of NAT knows no distinction between public and private address ranges.
- client IP
- The source address of the initial packet. The client IP in a NAT transformation does not change; this IP is the source IP address on any inbound packets both before and after the translation. It is also the destination address on the outbound packet.
留言
張貼留言