穿透Socks5 代理的UDP編程

2019-11-18 13:26:29

字體：大中小

來源：轉載

供稿：網友

　　要害詞：Socks5 TCP/ip UDP 代理服務器 RFC1928 java 網絡編程
　　
　　
　　
　　
　　
　　網絡編程中，對于數據傳輸實時性要求較高的場合，大家都會選擇UDP來作為數據傳輸協議，在TCP/IP協議族中UDP協議較TCP協議需要的網絡系統資源更少。然而在企業應用中，由于網絡安全原因等會導致除了特定端口以外的IP數據無法通過專用的路由或網關。為了支持這類應用，制定了專門的支持Socks連接的socks4/socsk5協議。Socks協議答應實現此類功能的代理軟件可以答應防火墻(本文以下內容中防火墻與代理的稱謂可以等同視之)以內的客戶通過防火墻實現對外部的訪問，甚至可以答應等待外部的連接。對于防火墻內部的軟件客戶端，僅同防火墻協商，同防火墻的特定端口取得聯系，然后交換數據，而防火墻外部的程序也直同防火墻進行數據交換，外部看不到防火墻的內部網情況，這樣起到了防火墻的監護功能，也滿足了大多數通過非常用（如http FTP等）端口交換數據的應用程序需求。防火墻內部的應用程序如何通過防火墻將UDP數據傳輸到防火墻外部，并且接受外部的UDP數據報文，這就是所謂穿透Socks代理的UDP編程。
　　
　　
　　
　　RFC1928描述了Socks協議的細節，告訴我們客戶程序如何同Socks代理協商，取得透過該協議對外傳輸的途徑。英文的URL為：http://www.ietf.org/rfc/rfc1928.txt，中文的翻譯參考不是很貼切（但譯者還是值得尊敬的），但對于E文不大好的可以將就一下：http://www.china-pub.com/computers/emook/0541/info.htm。建議先了解以上鏈接內容后在閱讀下文。
　　
　　
　　
　　一般的代理軟件都實現了兩個版本的Socks協議—Socks4以及Socks5,其中Socks5協議支持UDP報文的傳輸以及多種驗證方法，該協議還考慮IP發展需要，支持Ipv6。
　　
　　TCP透過代理支持兩種方法：Bind以及Connection。Connection是指作為客戶端，主動連接代理外部的服務程序，在這種方式中代理將替代客戶程序發起真正的對外部服務程序的連接，并往返傳輸在此連接中需要交流的數據；Bind方式則用在那些需要客戶機接受到服務器連接的協議中，例如FTP協議之類的除了需要建立一個客戶--服務器的連接報告狀態外，還需要建立一個服務器—客戶的連接來傳輸實際的數據（當然要注重這里的FTP協議通過Socks協議連接遠程主機，并非通過FTP代理協議）。UDP報文傳輸則意味著代理充當UDP數據傳輸的中間人，將防火墻內的主機對外的數據傳遞出去，將需要引入到防火墻內的UDP數據報文轉給防火墻特定的主機。關于TCP穿透的討論和例子很多（給出一個實現的例子：http://www.codePRoject.com/internet/casyncproxysocket.asp ），就不多講了，在此著重討論如何實現UDP數據的穿透Socks5代理。
　　
　　
　　
　　為了測試方便我簡單寫了一個服務進程在代理外IP為192。168。0。250上監聽UDP8100端口，接收到一個UDP的數據報后，返回服務器上的當前時間給發送UDP報文的客戶端。代理采用Wingate,他在192。168。0。1上運行，Socks的標準端口1080來運行服務監聽程序。我的機器為192。168。0。10，你可以看到，我不能夠直接聯系運行時間服務的機器，我會向代理提出我的要求，由代理進程負責UDP數據報文的轉發。代理軟件選擇Wingate，并且為了簡單起見，采用不需要驗證客戶的驗證方法。好了，交代了背景后，下面我們就開始穿越代理的旅程吧。
　　
　　無論是TCP還是UDP通過代理，首先要同代理取得聯系。為了能夠確保在第一階段順利確保數據傳輸，協議規定客戶端采用TCP方式連接聯系代理服務器。
　　
　　一旦客戶同代理的1080端口連接上，客戶首先要發送一個版本標識/方法選擇的TCP報文給代理服務器，具體格式為：
　　
　　
　　
　　　　版本號（1字節）可供選擇的認證方法(1字節) 方法序列（1-255個字節長度）
　　
　　假如是socks4協議，版本號就是0x04，但是這里是支持UDP的Socks5，所以是字節0x05。此說明對于后面的報文格式解釋的版本部分也都適用。
　　
　　Socks協議定義了0-255種通過代理的認證方法：
　　
　　0x00 無驗證需求
　　
　　0x01 通用安全服務應用程序接口(GSSAPI)
　　
　　　　0x02 用戶名/密碼(USERNAME/PASSWord)
　　
　　　　0x03 至 X'7F' IANA 分配(IANA ASSIGNED)
　　
　　　　0x80 至 X'FE' 私人方法保留(RESERVED FOR PRIVATE METHODS)
　　
　　0xFF 無可接受方法(NO ACCEPTABLE METHODS)
　　
　　顯然，無論是發起Socks請求的客戶端還是負責轉發Socks數據的代理都不可能完全實現所有的（起碼目前還沒有）方法，所以客戶端需要把自己能夠支持的方法列出來供代理服務器選擇。假如支持無驗證，那么此報文的字節序列就為：0x05 0x01 0x00，其中的0x01表示客戶端只支持一種驗證，0x00表示能夠支持的方法是編號為0x00的（無驗證）的方法。假如客戶端還支持用戶名/密碼的驗證方式，那么報文就應當是：0x05 0x02 0x00 0x02。
　　
　　代理接收到客戶的請求，會根據自身系統的實現返回告訴客戶驗證采用哪一種方法，返回的保文格式為：
　　
　　版本號服務器選定的方法
　　
　　假如服務器僅支持無驗證的驗證方法，它返回字節序列：0x05 0x00?？蛻舳送淼臄祿笪牡耐祽鹁褪荢ocks協議的驗證方法選擇階段。
　　
　　接下來就是根據選擇的方法來，驗證客戶身份了。雖然我們這里不需要驗證，但是還是簡單講一下0x02的用戶名/口令的驗證客戶端發送報文格式：
　　
　　0x01 用戶名長度（1字節）用戶名（長度根據用戶名長度域指定）口令長度（1字節）口令（長度由口令長度域指定）
　　
　　不清楚為什么報文的首字節是0x01(按照慣例應當是0x05)。整個報文長度根據用戶名和口令的實際長度決定。用戶名和口令都不需要以’/0’結束。服務器會根據提供的信息進行驗證，返回如下的報文字節序列映像為：
　　
　　0x01 驗證結果標志
　　
　　驗證結果標志可以為：0x00 驗證通過，其余均表示有故障，不可以繼續下一步的協議步驟。
　　
　　在通過了驗證步驟之后，接下來就是確定UDP傳輸的端口了。這里面需要確定兩個重要的端口：1、客戶端發送UDP數據的本機端口，一方面可以為發送數據指定端口，另一方面告訴代理，假如有數據返回，就傳遞給該端口，構成一個UDP傳輸回路。2、代理想在哪個端口接收客戶發送的UDP數據報，作為對外UDP Socket的申請方，雙方協商確定一個端口后，可以持續通過此端口向外部主機發送數據，也可以通過此端口由代理接收外部主機發回的UDP數據，再通過此端口發給UDP發送請求客戶端?？蛻舳藭凑找韵赂袷桨l送TCP數據字節序列：
　　
　　協議版本 Socks命令　保留字節　地址類型特定地址特定端口
　　
　　Socks命令有3種：CONNECT （編號0x01） BIND (0x02) UDP(編號0x03)
　　
　　保留字節長度1，為0x00
　　
　　地址類型有3種：
　　
　　0X01　　該地址是IPv4地址，長4個8bit字節。
　　
　　0X03　　該地址包含一個完全的域名。第一個8bit字節包含了后面名稱的8bit的數目，沒有中止的’/0’。
　　
　　0X04 該地址是IPv6地址，長16個8bit字節。
　　
　　特定地址一般對于多IP的主機有意義，假如不是或者不關心哪一個IP發起UDP數據傳輸，就可以填0。0。0。0，地址類型選擇0x01。比較重要的就是UDP傳輸將要從哪一個UDP端口發起。一般為了避免因為硬性指定一個端口導致引起沖突，會首先生成一個UDP套接字，用生成的套接字既定端口來作為自己傳輸UDP的端口，并通過此步驟告知代理服務器。譬如臨時生成一個UDP套接字，UDP選擇端口2233作為傳輸UDP數據的本地端口，那么此報文就為：0x05 0x03 0x00 0x00 0x00 0x00 0x00 0x08 0xb9 其中0x08 0xb9換算成10進制就是2233。
　　
　　代理服務器會根據自己的端口占用情況，給出一個有關代理服務器的端口的回復字節序列，告訴客戶可以將UDP數據發送到此地址和端口中去，以實現UDP穿透代理。返回的字節序列為：
　　
　　版本代理的應答　保留1字節　地址類型代理服務器地址綁定的代理端口
　　
　　代理的應答可以為值：
　　
　　0X00 成功協商
　　
　　0X01 常見的Socks故障
　　
　　0x02 不答應連接
　　
　　0X03 網絡不可到達
　　
　　0X04 主機不可到達
　　
　　0X05 連接被重置
　　
　　0X06 TTL 失效
　　
　　0X07 命令不支持
　　
　　0X08 地址類型不支持
　　
　　0X09 一直到0xff都保留
　　
　　代理的地址指客戶端需要發給那一個IP，綁定的端口指代理將在哪一個端口上為客戶接收數據并轉發出去。地址類型、地址參照上面的解釋。
　　
　　通過以上的TCP協商幾個步驟后，現在客戶端明確了自己將需要發送的UDP數據發給代理服務器的某個IP的某個端口了。代理服務器也知道是哪一個IP發送數據報給自己，假如接收到由于轉發此UDP數據報而從遠端目標主機傳回的數據報，他需要根據協議將收到的數據報返回給客戶的特定端口。此特定端口就是此步驟中字節序列中綁定的代理端口
　　
　　在傳輸UDP數據時，由于通過代理，所以需要按照一定的格式進行包裝，在需要傳送的數據之前添加一個報頭，具體為：
　　
　　保留2字節的0 是否數據報分段重組標志地址類型將要發到代理外的目標地址遠端目標主機的端口　需要通過代理傳送出去的數據
　　
　　是否數據報分段重組標志為0表示該數據報文是獨立的不需要重新組合，其他的表示特定的序列號，以利于UDP報文整合。
　　
　　這里的地址是最終接收此UDP數據的代理外的服務器地址，我們這個例子中就是192。168。0。250。端口就是8100。根據地址類型

上一篇：文件上傳的完全攻略

下一篇：對等計算實踐：基于 IP 多播的發現