IPFreedom http://computer.mblogger.cn/mygk/ IPFreedom穿透的分析 有人提到IPFreedom（http://www.ridgewaysystems.com/），能穿透Firewall和NAT。 於是，我找資料來看，以便分析其工作原理。 通過對IPFreeDom軟體的截包、分析，我的結論是：IPFreedom Server本質上是一個Gatekeeper，而IPFreedom Client則是一個能具備RAS信令解析和處理功能的普通Socket程式。其部分工作原理和這篇文章是類同的。 下面是對他工作原理的分析。 看這裏（安裝文擋）： >Configuring your Microsoft NetMeeting endpoint >You can configure NetMeeting to use Personal Client as follows (make sure >that Personal Client is configured and signed-in first): >1. Select Tools... Options from the NetMeeting menus >2. Select the Advanced Calling button >3. Ensure that the Use a gatekeeper to place calls option is enabled. >4. Specify the Gatekeeper address to be 127.0.0.1, as instructed by the Personal Client Configuration window when you check the box to indicate that you will be using NetMeeting for calls. >5. Specify an account name and/or phone number as preferred. >6. Select OK to close each of the options dialogs. ... 1. Netmeeting中如果設置了Gatekeeper，那麼NetMeeting就會發出RAS註冊包，如果註冊不上，那麼是無法撥號的（會提示“撥打電話前請先與網守註冊”）。 2. 既然使用Freedom可以撥打電話，以此推斷IPFreedom Client有處理RAS消息的部分（而這正是Gatekeeper標準的內容之一。） 3. 我推斷是本地的IPFreedom Client在處理這些RAS消息（我是用Iris分析資料包的）。 4. IPFreedom Client在處理RAS後，將該終端的資訊以自定義協定發送到IPFreedom Server（通過先前建立好的TCP:2776）上。 只有這樣才符合他文擋的： >Viewing the IPFreedom endpoint directory and making calls >You may view the list of all IPFreedom subscribers who have chosen to publish their endpoints on the View Directory page…… .. 5. 現在，NetMeeting去撥叫一個電話。發出送Q931的Setup包。 6. 根據IPFreedom的技術文擋，Q931的消息肯定不會直接送到對方，而是走先前建立的TCP:2776通道（通過本地的的IPFreedom Client走出去，因為NetMeeting和IPFreedom Client這2個程式在一台機器上，而H323開TCP都是INADDR_ANY，所以其實不是通道，而是直接發出的）。這就是Gatekeeper在routed的模式（見這篇文章） 7. 根據上面說的，所以IPFreedom Client得到Q931包， 直接從前面已經建立好的TCP:2776發到IPFreedom Server。 8. IPFreedom Server一定會解析這些包，得到被叫端的資訊。 因為所有的IPFreedom Client都會與IPFreedom Server連接，並將註冊到其上的NetMeeting資訊送給Server。這些資訊肯定包括：註冊的IP，號碼。（這些Client得到IP和號碼是很簡單的事。） 9. IPFreedom Server將這些Q931的包送到相應的被叫端的TCP:2776上。（被叫也已經用IPFreedom Client連上來過了）。這個被叫的IPFreedom Client將這些Q931包送到他與本地NetMeeting已經打開的TCP通道上。 10. 被叫的NetMeeting接到Q931包。按正常流程處理。 11. 同樣的，H245的包也這樣做。 12. 現在OLC（打開邏輯通道）消息到達，IPFreedom Client會馬上開2個UDP，與NetMeeting的OLC中UDP的位址關聯起來（就是2個UDP的通道）。 13. 而IPFreedom Server在收到OLC的時，就會為相應的IPFreedom Client開2個UDP埠，並連接上。 14. 所以NetMeeting的RTP/RTCP送到IPFreedom Client的UDP:2776與UDP:2777上。IPFreedom Client的這2個UDP與IPFreedom Server連接著，IPFreedom Server就收到了資料包。並根據被叫資訊，發給被叫的IPFreedom Client的2個UDP通道上。 這就是Gatekeeper在Proxy的模式（見這篇文章） 找了些網上有關IPFreedom的討論，更加證實了的確就是這樣做的。 而且也只能這樣做。 但是，我還有話說： 1. 直接在Client處理RAS，然後又自己生成TCP:2776，再把終端資訊送到Server上。這完全是多此一舉。完全可以把這個RAS送到Server去處理。 2. 把NetMeeting的Gatekeeper設置成127.0.0.1這些的回路位址，實在是不明智，難道所有的H.323終端都只有一張網卡，都用INADDR_ANY來獲取位址嗎？ 3. 使勁的想去掉Gatekeeper的標誌資訊，十分讓人懷疑。其實Server本身處理的就是Gatekeeper的工作，但是卻不承認。 但是，在安裝配置文擋、特別是管理的程式（它介紹上是個B/S結構），處處暴露出Gatekeeper的痕跡，而且我很擔心他極有可能採用了某個MPL/GPL發佈的軟體的核心代碼，所以要這麼用力的抹去自己Gatekeeper的資訊。 最後，得說： 1、 至於IPFreedom Client與IPFreedom Server之間要不要加自定義的包頭，完全不是重點。那更多的是用來做“Oh，這是我們公司軟體發出的包...”這樣的事。 2、 同樣的做法，使用GNU Gatekeeper將更穩定，功能更強大。 http://computer.mblogger.cn/mygk/posts/6345.aspx 最佳辦法，解決公網撥打私網問題 在外網架設Gatekeeper，並修改H.323終端，NATs後的終端現在能接聽來自外網的電話了。一切都很不錯，的確運行的不錯。 但並不真的是一切OK， 如果位於NATs後的是NetMeeting終端或是其他商業的H323終端，你無法修改這些H.323終端代碼來支援前面的方法。因此需要更通用的解決辦法。 如上圖所見，架設2台Gatekeeper（每個網段各有自己的，在這裏是公網網段和私網網段），就能完美的解決所有的問題。 位於192.168.0.11的Gatekeeper需要註冊到位於221.12.0.5的公網Gatekeeper（稱之為“子Gatekeeper”）。 其H323呼叫流程如下： 1. Gatekeeper（192.168.0.11）將自己作為“子Gatekeeper”發送註冊包RRQ到Gatekeeper（221.12.0.5）上。 2. Gatekeeper（221.12.0.5） 比較RRQ來源和RRQ中callSignalAddress域的位址，知道它在NAT後。 於是在回送的RCF包中，增加nonStandardData域。 3. Gatekeeper（192.168.0.11）收到RCF後，得知自己在NAT後，就創建一個TCP,並連接到RCF包中指示的callSignalAddress位址上（一般是221.12.0.5:1721）。這條 TCP通道① 建立。 4. 192.168.0.4終端註冊到Gatekeeper（192.168.0.11）。 5. A撥打電話給B。A建立與221.12.0.5:1721的 TCP通道② ，並發送Setup包。 6. Gatekeeper（221.12.0.5）收到Setup包，發現被叫由Gatekeeper（192.168.0.11）負責處理（後面介紹如何判斷誰對呼叫負責）。於是將該Setup包送給前面已經建立的 TCP通道① 上。 7. Gatekeeper（192.168.0.11）收到Setup包，通過包中Called-Party-Number域知道這是對192.168.0.4的呼叫。因此創建TCP，去連接知名埠--192.168.0.4:1720。於是這條私網GK到私網終端的Q931/H225 TCP通道③ 建立。 8. B通過 TCP通道③ 發出CallProceeding/Alerting/Connect消息到Gatekeeper（192.168.0.11）； Gatekeeper（192.168.0.11）再通過 TCP通道① 送到Gatekeeper（221.12.0.5）； Gatekeeper（221.12.0.5）通過TCP通道② 送到A上。 9. B發送Connect消息包前，創建一個新的TCP㈠，並將其位址填充Connect包的h245Address域，送到Gatekeeper（192.168.0.11）。 10. Gatekeeper（192.168.0.11）收到該Connect包，創建一個新的TCP㈡，並用這個TCP位址改寫Connect包的h245Address域，送到Gatekeeper（221.12.0.5）。 11. Gatekeeper（221.12.0.5）收到該Connect包，也馬上創建一個新的TCP㈢，同樣的替換Connect包中h245Address域，並送給A。 12. A收到Connect後，創建一個新的TCP㈣，並連接 TCP㈢ 建立H245 TCP通道Ⅰ 。 13. Gatekeeper（221.12.0.5）發出Q.931 Facility startH245消息給Gatekeeper（192.168.0.11）,這個包中包含了“第11步”生成的TCP㈢。 14. Gatekeeper（192.168.0.11）收到該包後，建立起 TCP㈡ 到 TCP㈢ 的H245 TCP通道Ⅱ。 15. Gatekeeper（192.168.0.11）建立起 TCP㈡ 到 TCP㈠ 的H245 TCP通道Ⅲ 。 這樣，所有的Q931/H225、H245的連接通道都建立成功。H.245控制信令交互完成後，Media Data將正確的收發

附加檔案：56539_IPFreedom.doc