求:UDP 通过socks5代理的代码

shanhe 2002-08-10 08:07:19
我初步了解socks5的原理,但是无法详细了解udp数据报怎么传输的,能够给出一些参考代码吗?
...全文
214 10 打赏 收藏 举报
写回复
10 条回复
切换为时间正序
当前发帖距今超过3年,不再开放新的回复
发表回复
seabank 2002-09-15
给我也发一份
xiaolaohu_001@sina.com
谢谢!!!
  • 打赏
  • 举报
回复
aben456 2002-09-15
wangbj@snm.szptt.net.cn
急需!
  • 打赏
  • 举报
回复
qsfsea 2002-09-11
gz
  • 打赏
  • 举报
回复
shanhe 2002-09-11
还是没人问津
  • 打赏
  • 举报
回复
liuyup 2002-09-06
也给我发一份。。liuyup@cmmail.com
  • 打赏
  • 举报
回复
sinten 2002-09-06
是啊,顺便发给我一份:P

dbb@psychcn.com
  • 打赏
  • 举报
回复
elingson 2002-09-02
快把你的总结写上来!UP
  • 打赏
  • 举报
回复
shanhe 2002-08-27
已经解决了,很快整理一个总结来
  • 打赏
  • 举报
回复
shanhe 2002-08-22
我现在可以实现发送到proxy外的主机,主机也可以接收,但是从proxy内收不到发回的信息
  • 打赏
  • 举报
回复
shanhe 2002-08-22
我把socks5的中文翻译贴上,请高手提出意见

标题:SOCKS 5协议详解
□作者:李洪洲 2002-06-10 19:12
文章摘要:
  该文档描述了一个应用层的用于穿越IP网络防火墙的协议。这种穿越的安全性是
高度依赖于正规的认证和正规执行方法提供的有效封装,以及在SOCKS客户端和SOCKS
服务端所选择的安全性,还有管理员对认证方法选项所作的小心周密的考虑。


---------------------------------------------------------------------------

正文:

SOCKS 5协议详解   

  笔者在实际学习中,由于在有些软件用到了socks5(如oicq,icq等),对其原理不
甚了解,相信很多朋友对其也不是很了解,于是仔细研读了一下rfc1928,觉得有必要
译出来供大家参考。

1.介绍:

  防火墙的使用,有效的隔离了机构的内部网络和外部网络,这种类型的Internet
架构变得越来越流行。这些防火墙系统大都充当着网络之间的应用层网关的角色,通
常提供经过控制的Telnet,FTP,和SMTP访问。为了推动全球信息的交流,更多的新的应
用层协议的推出。这就有必要提供一个总的架构使这些协议能够更明显和更安全的穿
过防火墙。也就有必要在实际上为它们穿过防火墙提供一个更强的认证机制。这种需
要源于客户机-服务器联系在不同组织网络之间的实现,而这种联系需要被控制和是很
大程度上被认证的。
  该协议被描述为用来提供在TCP和UDP域下为客户机-服务器应用程序便利和安全的
穿过防火墙的一个架构。该协议在概念上被描述为一个介于应用层和传输层之间的"隔
离层",但是这类服务并不提供网络层网关服务,如ICMP报文的传输。

2.现状:

  SOCKS 4为基于TCP的客户机-服务器应用程序提供了一种不安全的穿越防火墙的机
制,包括TELNET,FTP和当前最流行的信息发现协议如HTTP,WAIS和GOPHER.
  新协议为了包括UDP扩展了SOCKS 4,为了包括对总体上更强的认证机制的支持扩
展了协议架构,为了包括域名和IPv6地址的支持扩展了地址集。
  SOCKS协议执行最具代表性的是包括了在SOCKS库中利用适当的封装程序来对基于
TCP的客户程序进行重编译和重链结。

注意:
  除非特别提及,封装在包格式中的十进制数表示的是通讯域的长度(用八位组
octect表示)。一个给定的八位组必须具有指定的值,格式X'hh'被用来表示在该域中
单个八位组的值。当单词"变量Variable"被使用时,它指出了通讯域拥有一个可变长
度,这个可变长度要么由一个联合的(一个或两个八位组)长度域定义,要么由一个数
据类型域所定义。

3.基于TCP客户机的程序

  当一台基于TCP的客户机希望和目标主机建立连接时,而这台目标主机只有经过防
火墙才能到达(这种情况?一直持续到?它被执行时),它就必须在SOCKS服务器端的适
当的SOCKS端口打开一个TCP连结。SOCKS服务按常例来说定位于TCP端口1080。如果连
接请求成功,客户机为即将使用的认证方式进行一种协商,对所选的方式进行认证,
然后发送一个转发请求。SOCKS服务器对该请求进行评估,并且决定是否建立所请求转
发的连接。
  客户机连接到服务器,发送一个版本标识/方法选择报文:

  +----+----------+----------+
  |VER | NMETHODS | METHODS |
  +----+----------+----------+
  | 1 |   1  | 1 to 255 |
  +----+----------+----------+

  VER(版本)在这个协议版本中被设置为X'05'。NMETHODS(方法选择)中包含在
METHODS(方法)中出现的方法标识八位组的数目。
  服务器从METHODS给出的方法中选出一种,发送一个METHOD selection(方法选择
)报文:

  +----+--------+
  |VER | METHOD |
  +----+--------+
  | 1 |  1  |
  +----+--------+

  如果所选择的METHOD的值是X'FF',则客户机所列出的方法是没有可以被接受的,
客户机就必须关闭连接。

当前被定义的METHOD的值有:
  >> X'00' 无验证需求
  >> X'01' 通用安全服务应用程序接口(GSSAPI)
  >> X'02' 用户名/密码(USERNAME/PASSWORD)
  >> X'03' 至 X'7F' IANA 分配(IANA ASSIGNED)
  >> X'80' 至 X'FE' 私人方法保留(RESERVED FOR PRIVATE METHODS)
  >> X'FF' 无可接受方法(NO ACCEPTABLE METHODS)
***IANA是负责全球INTERNET上的IP地址进行编号分配的机构(译者著)***
  于是客户机和服务器进入方法细节的子商议。方法选择子商议另外描述于独立的
文档中。
  欲得到该协议新的METHOD支持的开发者可以和IANA联系以求得到METHOD号。已分
配号码的文档需要参考METHOD号码的当前列表和它们的通讯协议。
  如果想顺利的执行则必须支持GSSAPI和支持用户名/密码(USERNAME/PASSWORD)认
证方法。

4.需求

  一旦方法选择子商议结束,客户机就发送请求细节。如果商议方法包括了完整性
检查的目的和/或机密性封装,则请求必然被封在方法选择的封装中。

SOCKS请求如下表所示:

  +----+-----+-------+------+----------+----------+
  |VER | CMD | RSV | ATYP | DST.ADDR | DST.PORT |
  +----+-----+-------+------+----------+----------+
  | 1 |  1 | X'00' |  1 | Variable |   2  |
  +----+-----+-------+------+----------+----------+

其中:
o VER protocol version:X'05'
o CMD
 o CONNECT X'01'
 o BIND X'02'
 o UDP ASSOCIATE X'03'
o RSV RESERVED
o ATYP address type of following address
 o IP V4 address: X'01'
 o DOMAINNAME: X'03'
 o IP V6 address: X'04'
o DST.ADDR desired destination address
o DST.PORT desired destination port in network octet order

5.地址

  在地址域(DST.ADDR,BND.ADDR)中,ATYP域详细说明了包含在该域内部的地址类型

    o X'01'

  该地址是IPv4地址,长4个八位组。
    o X'03'

  该地址包含一个完全的域名。第一个八位组包含了后面名称的八位组的数目,没
有中止的空八位组。
    o X'04'

  该地址是IPv6地址,长16个八位组。

6.回应

  到SOCKS服务器的连接一经建立,客户机即发送SOCKS请求信息,并且完成认证商
议。服务器评估请求,返回一个回应如下表所示:


  +----+-----+-------+------+----------+----------+
  |VER | REP | RSV | ATYP | BND.ADDR | BND.PORT |
  +----+-----+-------+------+----------+----------+
  | 1 | 1 | X'00' | 1  | Variable |   2  |
  +----+-----+-------+------+----------+----------+

其中:

o VER protocol version: X'05'
o REP Reply field:
  o X'00' succeeded
  o X'01' general SOCKS server failure
  o X'02' connection not allowed by ruleset
  o X'03' Network unreachable
  o X'04' Host unreachable
  o X'05' Connection refused
  o X'06' TTL expired
  o X'07' Command not supported
  o X'08' Address type not supported
  o X'09' to X'FF' unassigned
o RSV RESERVED
o ATYP address type of following address
  o IP V4 address: X'01'
  o DOMAINNAME: X'03'
  o IP V6 address: X'04'
o BND.ADDR server bound address
o BND.PORT server bound port in network octet order
标志RESERVED(RSV)的地方必须设置为X'00'。

  如果被选中的方法包括有认证目的封装,完整性和/或机密性的检查,则回应就被
封装在方法选择的封装套中。

CONNECT

  在CONNECT的回应中,BND.PORT包括了服务器分配的连接到目标主机的端口号,同
时BND.ADDR包含了关联的IP地址。此处所提供的BND.ADDR通常情况不同于客户机连接
到SOCKS服务器所用的IP地址,因为这些服务器提供的经常都是多址的(muti-homed)。
都期望SOCKS主机能使用DST.ADDR和DST.PORT,连接请求评估中的客户端源地址和端口


BIND

  BIND请求被用在那些需要客户机接受到服务器连接的协议中。FTP就是一个众所周
知的例子,它通过使用命令和状态报告建立最基本的客户机-服务器连接,按照需要使
用服务器-客户端连接来传输数据。(例如:ls,get,put)
都期望在使用应用协议的客户端在使用CONNECT建立首次连接之后仅仅使用BIND请求建
立第二次连接。都期望SOCKS主机在评估BIND请求时能够使用DST.ADDR和DST.PORT。
  有两次应答都是在BIND操作期间从SOCKS服务器发送到客户端的。第一次是发送在
服务器创建和绑定一个新的socket之后。BIND.PORT域包含了SOCKS主机分配和侦听一
个接入连接的端口号。BND.ADDR域包含了关联的IP地址。  客户端具有代表性的是
使用这些信息来通报应用程序连接到指定地址的服务器。第二次应答只是发生在预期
的接入连接成功或者失败之后。在第二次应答中,BND.PORT和BND.ADDR域包含了欲连
接主机的地址和端口号。

UDP ASSOCIATE(连接?)(我理解为 协商)

  UDP 连接请求用来建立一个在UDP延迟过程中操作UDP数据报的连接。DST.ADDR和
DST.PORT域包含了客户机期望在这个连接上用来发送UDP数据报的地址和端口。服务器
可以利用该信息来限制至这个连接的访问。如果客户端在UDP连接时不持有信息,则客
户端必须使用一个全零的端口号和地址。

  当一个含有UDP连接请求到达的TCP连接中断时,UDP连接中断。(当TCP连接也就是
UDP ASSOCIATE 请求 到达完成时,UDP ASSOCIATE阶段结束)

  在UDP连接请求的回应中,BND.PORT和BND.ADDR域指明了客户端需要被发送UDP请
求消息的端口号/地址。

回应过程

  当一个回应(REP值非X'00')指明失败时,SOCKS主机必须在发送后马上中断该TCP
连接。该过程时间必须为在侦测到引起失败的原因后不超过10秒。
  如果回应代码(REP值为X'00')时,则标志成功,请求或是BIND或是C
  • 打赏
  • 举报
回复
发帖
VC/MFC

1.6w+

社区成员

VC/MFC相关问题讨论
社区管理员
  • 基础类社区
  • Web++
  • encoderlee
加入社区
帖子事件
创建了帖子
2002-08-10 08:07
社区公告

        VC/MFC社区版块或许是CSDN最“古老”的版块了,记忆之中,与CSDN的年龄几乎差不多。随着时间的推移,MFC技术渐渐的偏离了开发主流,若干年之后的今天,当我们面对着微软的这个经典之笔,内心充满着敬意,那些曾经的记忆,可以说代表着二十年前曾经的辉煌……
        向经典致敬,或许是老一代程序员内心里面难以释怀的感受。互联网大行其道的今天,我们期待着MFC技术能够恢复其曾经的辉煌,或许这个期待会永远成为一种“梦想”,或许一切皆有可能……
        我们希望这个版块可以很好的适配Web时代,期待更好的互联网技术能够使得MFC技术框架得以重现活力,……