• <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>
            隨筆 - 85  文章 - 47  trackbacks - 0

            常用鏈接

            隨筆分類

            隨筆檔案

            搜索

            •  

            最新評論

            STUN是RFC3489規定的一種NAT穿透方式,它采用輔助的方法探測NAT的IP和端口。毫無疑問的,它對穿越早期的NAT起了巨大的作用,并且還將繼續在ANT穿透中占有一席之地。
            STUN的探測過程需要有一個公網IP的STUN Server,在NAT后面的UAC(User Agent Client)必須和此Server配合,互相之間發送若干個UDP數據包。UDP包中包含有UAC需要了解的信息,比如NAT外網 IP,PORT等等。UAC通過是否得到這個UDP包和包中的數據判斷自己的NAT類型。
            假設有如下UAC(B),NAT(A),STUN SERVER(C),UAC的IP為IPB,NAT的IP為IPA,SERVER的IP為IPC1、IPC2。請注意,STUN 服務器C有兩個IP,后面你會理解為什么需要兩個IP。

            STEP1:
            B向C的IP1的port1端口發送一個UDP包。C收到這個包后,會把它收到包的源IP和port寫到UDP包中,然后把此包通過IP1和port1發還給B。這個IP和port也就是NAT的外網IP和port,也就是說UAC在STEP1中就得到了NAT的外網IP。
            如果在UAC向一個STUN服務器發送數據包后,沒有收到STUN的任何回應包,那只有兩種可能:1、STUN服務器不存在,或者port弄錯了;2、你的NAT拒絕一切UDP包從外部向內部通過(我們公司的NAT就是)。
            當B收到此UDP后,把此UDP中的IP和自己的IP做比較,如果是一樣的,就說明自己是在公網。如果不一樣,說明有NAT的存在,系統進行STEP2的操作。

            STEP2:
            B向C的IP1發送一個UDP包,請求C通過另外一個IP2和PORT(不同與SETP1的IP1)向B返回一個UDP數據包(現在知道為什么C要有兩個IP了吧,呵呵)。
            我們來分析一下,如果B收到了這個數據包,那說明什么?說明NAT來者不拒,不對數據包進行任何過濾,這也就是STUN標準中的full cone NAT。遺憾的是,full cone NAT太少了,這也意味著你能收到這個數據包的可能性不大。如果沒收到,那么系統進行STEP3的操作。

            STEP3:
            B向C的IP2的port2發送一個數據包,C收到數據包后,把它收到包的源IP和port寫到UDP包中,然后通過自己的IP2和port2把此包發還給B。和step1一樣,B肯定能收到這個回應UDP包。此包中的port是我們最關心的數據,下面我們來分析:
            如果這個port和step1中的port一樣,那么可以肯定這個NAT是個CONE NAT,否則是對稱NAT。道理很簡單:根據對稱NAT的規則,當目的地址的IP和port有任何一個改變,那么NAT都會重新分配一個port使用,而在step3中,和step1對應,我們改變了IP和port。因此,如果是對稱NAT,那這兩個port肯定是不同的。
            如果在你的應用中,到此步的時候PORT是不同的,恭喜你,你的STUN已經死了。如果不同,那么只剩下了restrict cone和port restrict cone。系統用step4探測是是哪一種。

            STEP4:
            B向C的IP2的一個端口PD發送一個數據請求包,要求C用IP2和不同于PD的port返回一個數據包給B。
            我們來分析結果:如果B收到了,那也就意味著只要IP相同,即使port不同,NAT也允許UDP包通過。顯然這是restrict cone NAT。如果沒收到,沒別的好說,port restrict NAT.
            posted on 2009-01-14 16:57 w2001 閱讀(3592) 評論(2)  編輯 收藏 引用 所屬分類: Linux開發

            FeedBack:
            # re: STUN檢測NAT類型原理(轉) 2009-04-07 15:07 non
            step3的最后“如果不同,那么只剩下了restrict cone和port restrict cone。系統用step4探測是是哪一種。”
            這里應該是如果相同吧。  回復  更多評論
              
            # re: STUN檢測NAT類型原理(轉) 2013-09-09 16:30 大雪先生
            @non
            確實應該是“如果相同”  回復  更多評論
              
            久久激情亚洲精品无码?V| 欧美伊人久久大香线蕉综合69| 久久久久免费看成人影片| 国产亚洲精品美女久久久| 久久精品国产99国产精品| 日本强好片久久久久久AAA| 精品国产VA久久久久久久冰 | 日韩精品无码久久一区二区三| 久久精品国产99久久久古代| 99久久精品国产高清一区二区| 久久亚洲中文字幕精品一区| 国产91色综合久久免费| 久久久精品久久久久影院| 国产99久久久国产精免费| 久久66热人妻偷产精品9| 久久久久国产一级毛片高清板 | 国产一区二区精品久久凹凸| 一本一道久久综合狠狠老| 日本精品久久久久久久久免费| 久久国产成人精品麻豆| 久久久精品2019免费观看| 亚洲午夜久久久久久噜噜噜| 无码人妻久久一区二区三区蜜桃 | 久久久久亚洲Av无码专| 77777亚洲午夜久久多喷| 香港aa三级久久三级老师2021国产三级精品三级在| 久久精品国产2020| 久久大香萑太香蕉av| 亚洲国产精品综合久久网络| 久久成人国产精品一区二区| 亚洲午夜久久久精品影院| 国产ww久久久久久久久久| 免费精品99久久国产综合精品| 99久久免费国产特黄| 99久久精品国内| 国产成人久久精品二区三区| 国产国产成人久久精品| 久久综合狠狠综合久久97色| 欧美精品一区二区久久| 国产69精品久久久久久人妻精品| 亚洲精品NV久久久久久久久久|