• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            posts - 297,  comments - 15,  trackbacks - 0
            NAT的優(yōu)點不必多講,它提供了一系列相關技術來實現(xiàn)多個內(nèi)網(wǎng)用戶通過一個公網(wǎng)ip和外部通信,有效的解決了ipv4地址不夠用的問題.那么位于NAT后 的用戶使用私網(wǎng)ip真的和使用公網(wǎng)ip一樣嗎?NAT解決了所有地址轉換的相關問題了嗎?
            下面主要講一些NAT不支持的方面,以及所謂的NAT 的"缺陷".

            一些應用層協(xié)議(如TCP和SIP),在它們的應用層數(shù)據(jù)中需要包含公網(wǎng)IP地址.拿FTP來說吧,眾所周知,FTP是通過 兩個不同的連接來傳輸控制報文和數(shù)據(jù)報文的.當傳輸一個文件時,FTP服務器要求通過控制報文得到即將傳輸?shù)臄?shù)據(jù)報文的網(wǎng)絡層和傳輸層地址 (IP/PORT).如果這個時候客戶主機是在NAT之后的,那么服務器端收到的ip/port將會是NAT轉化前的私網(wǎng)IP地址,從而會導致文件傳輸失 效.
            SIP(Session Initiation Protocol)主要是來控制音頻傳輸?shù)?這個協(xié)議也面臨同樣的問題.因為SIP建立連接時,需要用到幾個不同的端口來通過RTP傳輸音頻流.而且這些 端口以及IP會被編碼到音頻流中,傳輸給服務器端,從而實現(xiàn)后續(xù)的通信.
            如果沒有一些特殊的技術(如STUN),那么NAT是不支持這些協(xié)議的, 這些協(xié)議經(jīng)過NAT也肯定會失敗.
            Some Application Layer protocols (such as FTP and 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 and/or TCP port number makes the information received by the server invalid. The Session Initiation Protocol (SIP) controls Voice over IP (VoIP) communications and suffers the same problem. SIP may use multiple ports to set up a connection and transmit voice stream via RTP. IP addresses and port numbers are encoded in the payload data and must be known prior to the traversal of NATs. Without special techniques, such as STUN, NAT behavior is unpredictable and communications may fail.

            下 面講一些特殊的技術,來使NAT支持這些特殊的應用層協(xié)議.

            最直觀的想法就是:既然NAT修改了IP/PROT,那么我們也修改應用層數(shù) 據(jù)中相應的IP/PORT.應用層網(wǎng)關(ALG)(硬件或軟件都行)就是這樣來解決這個問題的.應用層網(wǎng)關運行在設置了NAT的防火墻設備中,它會更新傳 輸數(shù)據(jù)中的IP/PORT.所以,應用層網(wǎng)關也必須能夠解析應用層協(xié)議,而且對于每一種協(xié)議,可能需要不同的應用層網(wǎng)關來做.
            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 obviously need to understand the higher-layer protocol that they need to fix, and so each protocol with this problem requires a separate ALG.

            另外一個解決此問題的辦法就是NAT穿透.此方法主要利用STUN或 ICE等協(xié)議或者一些和會話控制相關的特有的方法來實現(xiàn).理論上NAT穿透最好能夠同時適用于基于TCP和基于UDP的應用,但是基于UDP的應用相對比 較簡單,更廣為流傳,也更適合兼容一些種類的NAT做穿透.這樣,應用層協(xié)議在設計的時候,必須考慮到可支持NAT穿透.但一些其他類型的NAT(比如對 稱NAT)是無論如何也不能做穿透的.
            Another possible solution to this problem is to use NAT traversal techniques using protocols such as STUN or 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. 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.


            還有一些方法,比如UPnP (Universal Plug and Play) 或 Bonjour (NAT-PMP),但是這些方法都需要專門的NAT設備.
            Other possibilities are UPnP (Universal Plug and Play) or Bonjour (NAT-PMP), but these require the cooperation of the NAT device.


            大部分傳統(tǒng)的客戶-服務器協(xié)議(除了FTP),都不定義3層以上的數(shù)據(jù)格 式,所以,也就可以和傳統(tǒng)的NAT兼容.實際上,在設計應用層協(xié)議的時候應盡量避免涉及到3層以上的數(shù)據(jù),因為這樣會使它兼容NAT時復雜化.
            Most traditional client-server protocols (FTP being the main exception), however, do not send layer 3 contact information and therefore do not require any special treatment by NATs. In fact, avoiding NAT complications is practically a requirement when designing new higher-layer protocols today.


            NAT也會和利用ipsec加密的一些應用沖突.比如SIP電話,如果有很多SIP電話設備在 NA(P)T之后,那么在電話利用ipsc加密它們的信號時,如果也加密了port信息,那么這就意味著NAPT就不能轉換port,只能轉換IP.但是 這樣就會導致回來的數(shù)據(jù)包都被NAT到同一個客戶端,從而導致通信失敗(不太明白).不過,這個問題有很多方法來解決,比如用TLS.TLS是運行在第四 層(OSI模型)的,所以它不包含port信息.也可以在UDP之內(nèi)來封裝ipsec,TISPAN 就是用這種方法來實現(xiàn)安全NAT轉化的.
            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 which encrypt their signaling with IPsec encapsulate the port information within the IPsec packet meaning that NA(P)T devices cannot access and translate the port. In these cases the NA(P)T devices revert to simple NAT operation. This means that all traffic returning to the NAT will be mapped onto one client causing the service to fail. There are a couple of solutions to this problem, one is to use TLS which operates at level 4 in the OSI Reference Model and therefore does not mask the port number, or to Encapsulate the IPsec within UDP - the latter being the solution chosen by TISPAN to achieve secure NAT traversal.


            Dan Kaminsky 在2008年的時候提出NAPT還會間接的影響DNS協(xié)議的健壯性,為了避免DNS服務器緩存中毒,在NA(p)T防火墻之后的DNS服務器最好不要轉換 來自外部的DNS請求(UDP)的源端口.而對DNS緩存中毒攻擊的應對措施就是使所有的DNS服務器用隨機的端口來接收DNS請求.但如果NA(P)T 使DNS請求的源端口也隨機化,那么在NA(P)T防火墻后面的DNS服務器還是會崩潰的.
            The DNS protocol vulnerability announced by Dan Kaminsky on 2008 July 8 is indirectly affected by NAT port mapping. To avoid DNS server cache poisoning, it is highly desirable to not translate UDP source port numbers of outgoing DNS requests from any DNS server which is behind a firewall which implements NAT. The recommended work-around 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 will be made vulnerable.

            位 于NAT后的主機不能實現(xiàn)真的端對端的通信,也不能使用一些和NAT沖突的internat協(xié)議.而且從外部發(fā)起的TCP連接和一些無狀態(tài)的協(xié)議(利用 udp的上層協(xié)議)也不能正常的進行,除非NAT所在設備通過相關技術支持這些協(xié)議.一些協(xié)議能夠利用應用層網(wǎng)關或其他技術,來使只有一端處于NAT后的 通信雙方正常通信.但要是雙方都在NAT后就會失敗.NAT也和一些隧道協(xié)議(如ipsec)沖突,因為NAT會修改ip或port,從而會使協(xié)議的完整 性校驗失敗.
            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 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 below), but fail when both systems are separated from the Internet by NAT. 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.


            端對端的連接是 internet設計時的一個重要的核心的基本原則.而NAT是違背這一原則的,但是NAT在設計的時候也充分地考慮到了這些問題.現(xiàn)在基于ipv6的 NAT已經(jīng)被廣泛關注,但許多ipv6架構設計者認為ipv6應該摒棄NAT.
            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. 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.


            由于NAT的連接追蹤具有短時效性.所以在特定的地址轉換關系會在一小段時間后失效, 除非遵守NAT的keep-alive機制,內(nèi)網(wǎng)主機不時的去訪問外部主機.這至少會造成一些不必要的消耗,比如消耗手持設備的電量.
            Because of the short-lived nature of the stateful translation tables in NAT routers, devices on the internal network lose IP connectivity typically within a very short period of time unless they implement NAT keep-alive mechanisms by frequently accessing outside hosts. This dramatically shortens the power reserves on battery-operated hand-held devices and has thwarted more widespread deployment of such IP-native Internet-enabled devices.


            一些IPS會直接提供給用戶私網(wǎng)IP地址,這樣用戶就必須通過IPS的 NAT來和外部INTERNET通信.這樣,用戶實際上沒有實現(xiàn)端對端通信,中間加了一個IPS的NAT,這有悖于Internet Architecture Board列出的internal核心基本原則.
            Some Internet service providers (ISPs) provide their customers only with "local" IP addresses.[citation needed]Thus, these customers must access services external to the ISP's network through NAT. As a result, the customers cannot achieve true end-to-end connectivity, in violation of the core principles of the Internet as laid out by the Internet Architecture Board.

            NAT 最后的一個缺陷就是:NAT的推廣和使用,解決了ipv4下IP地址不夠用的問題,大大的推遲了IPV6的發(fā)展.
            (說它是優(yōu)點好呢,還是缺陷好 呢?)
            it is possible that its [NAT] widespread use will significantly delay the need to deploy IPv6

            Reference:
            Network address translation

            from:
            http://blog.chinaunix.net/u2/86590/showart.php?id=2208148
            posted on 2010-07-13 15:28 chatler 閱讀(906) 評論(0)  編輯 收藏 引用 所屬分類: Network
            <2025年8月>
            272829303112
            3456789
            10111213141516
            17181920212223
            24252627282930
            31123456

            常用鏈接

            留言簿(10)

            隨筆分類(307)

            隨筆檔案(297)

            algorithm

            Books_Free_Online

            C++

            database

            Linux

            Linux shell

            linux socket

            misce

            • cloudward
            • 感覺這個博客還是不錯,雖然做的東西和我不大相關,覺得看看還是有好處的

            network

            OSS

            • Google Android
            • Android is a software stack for mobile devices that includes an operating system, middleware and key applications. This early look at the Android SDK provides the tools and APIs necessary to begin developing applications on the Android platform using the Java programming language.
            • os161 file list

            overall

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜

            久久亚洲精品视频| 久久精品国产亚洲一区二区三区| 激情久久久久久久久久| 亚洲伊人久久大香线蕉苏妲己| 久久香蕉国产线看观看乱码| 久久综合给合综合久久| 无码精品久久久天天影视| 好属妞这里只有精品久久| 人人狠狠综合88综合久久| 7777久久亚洲中文字幕| 亚洲日韩欧美一区久久久久我| 精品熟女少妇a∨免费久久| 色婷婷狠狠久久综合五月| 精品久久久久久无码专区不卡| 久久久久久一区国产精品| 99久久免费国产特黄| 久久亚洲精品无码VA大香大香| 青青国产成人久久91网| 亚洲熟妇无码另类久久久| 久久久久久国产精品免费免费| 韩国三级大全久久网站| 久久综合噜噜激激的五月天| 久久天天躁狠狠躁夜夜不卡| 欧美777精品久久久久网| 成人午夜精品无码区久久| 婷婷久久精品国产| 久久亚洲国产精品一区二区| 久久超乳爆乳中文字幕| 亚洲国产精品18久久久久久| 久久综合伊人77777| 开心久久婷婷综合中文字幕| 久久国产美女免费观看精品| 国产成人久久精品激情| 久久精品国产亚洲av水果派| 欧美日韩精品久久久免费观看| 久久精品国产亚洲7777| 一本大道久久a久久精品综合| 久久久国产精品网站| 亚洲国产精品久久久久婷婷软件| 久久人爽人人爽人人片AV| av无码久久久久不卡免费网站 |