TURN服務器在防火牆之後 - 如何處理XOR-RELAYED-ADDRESS

Question

我在防火牆後面的服務器上運行TURN服務器（http://tools.ietf.org/html/rfc5766）。該機器具有公用IP地址，用於將傳入和傳出網絡數據包發送到服務器的專用IP地址或從中傳送出去。基本上，服務器不能將套接字綁定到公共IP地址，只能是私有IP地址。運行ifconfig顯示了具有私有IP地址的網絡設備。

當我運行TURN服務器時，必須綁定到私有IP地址（因爲服務器不認爲它連接到公共Internet）。所有對分配創建的響應都將使用私有IP地址發回XOR-RELAYED-ADDRESS。客戶端收到XOR-RELAYED-ADDRESS並將數據發送到服務器的私有IP地址，這明顯失敗。

有我正在考慮解決這個兩個選項：

• 有我的客戶端代碼忽略異或中繼-地址的IP地址，並只使用異或中繼-地址的端口。客戶端將所有中繼消息發送到TURN服務器的公共IP（因爲客戶端已經知道這個值）和XOR-RELAYED-ADDRESS端口。
• 修改我的服務器以瞭解其公有IP（即使它不能將套接字綁定到它），並始終在XOR-RELAYED-ADDRESS響應中發回公共IP。

我覺得第一種方法打破了TURN RFC ......儘管我無法想象TURN服務器將發送XOR-RELAYED-ADDRESS的IP作爲TURN服務器公共IP，RFC表示XOR-RELAYED-ADDRESS是客戶端應該發送數據的地址。

我覺得第二種方法打破了RFC 減去 ......如果這是有道理的。此外，這種方法不會強迫客戶做任何特殊的事情，而第一種方法需要所有客戶遵守上述規定。

您對此有何看法？有沒有人遇到過這種情況，並且/或者對哪種方法中斷的RFC更少有任何意見，或者RFC甚至被任何一種方法侵犯？

Answer 1

我在亞馬遜EC2上運行my STUN server code幾乎有同樣的確切問題。由stun服務器返回給客戶端的起始地址和備用地址是NAT的IP地址。

我曾經想過一些解決方案：

1. 只是假設客戶是預先配置要知道備用IP地址，如果他們真的想要做額外的NAT類型檢測試驗。這對STUN來說不是一個錯誤的假設。畢竟，他們需要知道stun服務的主要IP地址。

2. 修改服務器代碼以通過它從命令行或配置文件映射的IP地址。這相當於上面介紹的第二種方法。我可以讓服務器在啓動時自動發現它自己的外部IP地址，通過網絡請求（或測試另一個stun服務器）來自動執行此操作。

你的第一個建議 - 客戶知道IP映射 - 完全沒問題，假設你沒有嘗試與除你自己以外的其他客戶端互操作。但是如果你認爲你需要使用別人的客戶端堆棧，那麼這個選項變得不太理想。你可以做一個混合的方法 - 爲你的客戶理解的「TURN Allocate響應」創建一個新的自定義屬性，「忽略中繼IP，只是假設端口是正確的」。這是好的，但不是很好。

你的第二個建議是比較符合我上面的＃2。還有一件事要考慮。如果您的客戶端也與TURN服務器位於同一防火牆後，會發生什麼情況？你想要內部地址還是外部地址？再次，如果你的客戶都在同一個防火牆後面，他們可能不需要TURN進行通信。另一個問題是將正確的IP地址傳遞給服務器的管理開銷。

我喜歡你的第二個建議。

你可以考慮發佈提問到BEHAVE IETF email discussion group。他們是起草STUN和TURN規格的開放式委員會。我認爲他們應該知道，在NAT後面運行的雲中的服務器正變得越來越普遍。他們可能會有一些建議。我會非常感興趣的是與你共同創作這封電子郵件。或者至少讀他們的迴應。