• <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 閱讀(3579) 評論(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
            確實應該是“如果相同”  回復  更多評論
              
            久久人人爽人人爽人人片AV不| 2020国产成人久久精品| 久久久久免费精品国产| 一本久久综合亚洲鲁鲁五月天| 伊人久久一区二区三区无码| 免费一级做a爰片久久毛片潮| 久久这里的只有是精品23| 亚洲va中文字幕无码久久 | 亚洲精品无码专区久久久 | 久久成人18免费网站| 久久精品无码av| 久久久www免费人成精品| 精品久久久久久中文字幕| 欧美精品一区二区久久| 一本色道久久HEZYO无码| 91久久福利国产成人精品| 99久久99久久精品国产片果冻 | 久久人人爽人爽人人爽av| 久久久无码精品亚洲日韩蜜臀浪潮| 久久无码av三级| 香蕉久久夜色精品升级完成| 久久精品18| 伊人久久综合成人网| 国产欧美久久一区二区| 久久精品国产72国产精福利| 国产精品无码久久综合| 无夜精品久久久久久| 久久精品国产亚洲av麻豆色欲| 久久久久国产精品三级网| 午夜精品久久久久久中宇| 日本精品久久久久影院日本| 99久久免费国产精精品| 精品久久久久久无码专区| 成人久久免费网站| 久久毛片一区二区| 狠狠色丁香久久婷婷综合蜜芽五月| 国产成人精品久久一区二区三区av | 国产成人精品久久| 日韩人妻无码一区二区三区久久99| 久久se这里只有精品| 久久久久久久综合日本|