P2P简介 网络模式 C/S 模式 B/S 模式 P2P(peer to peer) FTP,POP3,SMTP HTTP QQ,SkyPe,BitXXX.

一切从沟通开始 背景 结论: 畅通无阻 人物: B(oy) 和 G(irl) 事件: 聊天 环境: 同一网段,宿舍,或者实验室 工具:IpMsg(飞鸽传输) B : 192.168.0.10 : 2425(Tcp/Udp) G : 192.168.0.20 : 2425(Tcp/Udp) 结论: 畅通无阻

What’s up? 背景 人物 : B 和 G 事件 : 聊天, 传文件 工具: IpMsg 环境一: B : 10.10.5.100 : 2425 (T/U) G : 10.10.5.200 : 2425 (T/U) 可以聊天,传文件

What’s up? 环境二: 结论 QQ? 地点 : B(北楼) G(南楼) B : 10.10.5.100/192.169.0.2 : 2425 (T/U) G : 10.10.5.200/192.168.0.2 : 2425 (T/U) 工具 : IpMsg 结论 聊天? 传文件? QQ?

Network Address Translator (NAT) 网络地址转换器 解决IPv4的32位地址的快速损耗的方法 网络地址和端口转换 （NAPT） 一个例子 各个击破 UDP TCP

还是沟通! 情况一: 背景: 目的 : 调试程序 方案一: B : 10.10.5.100 G : 10.10.5.200 / 192.168.0.2 工具 : ChatServer.java (Udp) 目的 : 调试程序 方案一: B : Server(10.10.5.100 : 8000) G : Client (192.168.0.2 : 4567)

还是沟通! 方案二 方法: B启动服务器,G启动客户端. B得到的连接:10.10.5.200 : 27000 结论: Nat转换了G的IP地址 B 和 G 可以对等通信(Udp) 方案二 B : Client (10.10.5.100 : 4567) G : Server(192.168.0.2 : 8000)

还是沟通! 情况二: 背景 方法: 结论: B : 10.10.5.100 : 4000 G : 192.168.0.2 : 4000 无法连接! 通信不对等 情况二: 背景 B : 10.10.5.100 : 4000 G : 192.168.0.2 : 4000 工具: QQ(显ip)

还是沟通! 方案 方法 B 启动qq G 启动qq 结论 可以对等聊天 Udp 穿透 Nat. 情况三 背景 B : 10.10.5.100/192.168.0.2 : 4000 G : 10.10.5.200/192.168.0.2 : 4000

还是沟通! 方案 方法 B 启动qq G 启动qq 结论 可以对等通信 Udp 的 Nat 打洞 NAT 分类

细说NAT和UDP打洞 锥形NAT 对称NAT 当建立了一个 [私有IP:端口]-[公网IP:端口] 端口绑定之后，对于来自同一个[私有IP:端口]会话，锥形NAT服务器允许发起会话的应用程序在接下来的会话中重复使用这个端口绑定，一直到所有的会话结束才解除这个绑定。 对称NAT 与Cone NAT是大不相同的，并不对会话进行端口绑定，而是分配一个全新的 公网端口 给每一个新的会话。 受限制的锥形NAT 会对传入的数据包进行筛选，当内部主机发出“外出”的会话时，NAT会记录这个外部主机的IP地址信息，所以，也只有这些有记录的外部IP地址，能够将信息传入到NAT内部，受限制的锥形NAT 有效的给防火墙提炼了筛选包的原则——即限定只给那些已知的外部地址“传入”信息到NAT内部。

案例分析 情况二的分析 背景 : B 有可路由的IP地址,G在Nat G后 目标 : 实现对等通信 备注 : 为了简化问题,我们假设qq服务器S运行在10.10.5.1,就是默认网关上. 方法: B 启动qq: 10.10.5.100 : 4000和S建立UDP会话 G 启动qq: 192.168.0.2 : 4000和S建立UDP会话,在S那里,记录了B和G的socket信息: B: 10.10.5.100 : 4000 G: 10.10.5.200 : 7890 (Nat 转换后的)

案例分析 B 和 G都是隐身的, B想给G发消息 B发消息给S,获取G的socket信息,并通知S想和G建立UDP会话 假如B直接发消息到10.10.5.200:7890,会被Nat G屏蔽掉,因为B和G的会话没有建立,这个数据报被认为是不安全的. S发消息给G,告诉她B想和她建立会话,并把B的socket信息告知G,G给B发送一个UDP包,Nat G记录了B和G的会话 现在,B和G可以相互通信了. S起了引见的作用.

案例分析 情况三的分析 背景 : B 在Nat B后,G在Nat G后 目标 : 实现对等通信 备注 : 为了简化问题,我们假设qq服务器S运行在10.10.5.1,就是默认网关上. 方法: B 启动qq: 192.160.0.2 : 4000和S建立UDP会话 G 启动qq: 192.168.0.2 : 4000和S建立UDP会话,在S那里,记录了B和G的socket信息: B: 10.10.5.100 : 9870 (Nat B转换后的) G: 10.10.5.200 : 7890 (Nat G转换后的)

案例分析 B 和 G都是隐身的, B想给G发消息 B发消息给S,获取G的socket信息,并通知S想和G建立UDP会话 假如B直接发消息到10.10.5.200:7890,会被Nat G屏蔽掉,因为B和G的会话没有建立,这个数据报被认为是不安全的. S发消息给G,告诉她B想和她建立会话,并把B的socket信息告知G,G给B发送一个UDP包,Nat G记录了G到B的会话 可是B到G的会话并没有建立,所以Nat B屏蔽了G的数据报,还是不能通信 该怎么办呢??

案例分析 B通知S,想和G建立会话,获得G的socket信息 B向G:10.10.5.200:7890发送Udp数据报,因为G到B的会话没有建立,所以,Nat G屏蔽了这个数据报.然而,B到G的会话已经被Nat B记录了. S通知G,B想和她建立会话. G向B:10.10.5.100:9870发送Udp数据报,因为B到G的会话已经被Nat B记录,所以,B收到了G的数据报,同时,在Nat G,G到B的的会话也被记录.B和G的会话到此完全建立起来. B和G可以对等通信了. 上述的技术: 称为UDP打洞

TCP的P2P 背景 文件的传输,用UDP是不可靠的 用TCP进行P2P通信,会复杂的多 难点:TCP如何穿透NAT 常见软件:qq,Bitxxx 有些技术难点,仍然在研究中

TCP如何建立连接 要建立一个TCP连接，需要如下步骤： 请求端（通常成为客户）发送一个SYN段指明客户端打算连接的服务器的端口号，以及初始序号（ISN）。我们称此SYN段为报文段1。 服务器发回包含服务器的初始序号的SYN报文段（报文段2）作为应答。同时将确认序号设为客户的ISN加1以对客户的SYN报文段进行确认。一个SYN将占用一个序号。 客户必须将确认序号设置为服务器的ISN加1以对服务器的SYN报文段进行确认（报文段3）。 这三个报文段完成连接的建立。我们称这个过程为三次握手。发送第一个SYN的一端将执行主动打开（active open）。接收这个SYN并发回下一个SYN的一端执行被动打开（passive open）。 当一端为建立连接而发送它的SYN时，它为连接选择一个初始序号。ISN随时间而变化，因此每个连接都具有不同的ISN。RFC 793中指出ISN可看作是一个32比特的计数器，没4ms加1。

GG和MM的故事 背景 GG给MM发了一个小游戏,上面捆绑了最新木马XX,MM用的杀毒软件太…MM中招了. GG偷笑,从此,就可以看到MM在干什么了,呵呵(在坐MM以后要小心了) 问题:GG真的能达到目的吗?? 怀疑中……

想看,不是那么容易的 情况一: 背景: 结论: 很不幸,最典型的C/S模式.MM听天由命吧(阿门…) GG : 10.10.5.100 : 7890 Client (TCP) MM : 10.10.5.200 : 8000 Server(TCP) 结论: 很不幸,最典型的C/S模式.MM听天由命吧(阿门…) Tips:开着防火墙,应该就没有问题了,呵呵. 没事多用netstat,看看有没有什么奇怪的端口开着.

想看,不是那么容易的 情况二: 背景: 结论: GG真的能看到吗? GG : 10.10.5.100 : 7890 Client (TCP) MM : 10.10.5.200 /192.168.0.2 : 8000 Server(TCP) 结论: GG真的能看到吗? 可能的情况: GG的Client连接MM,可是,他不知道服务器的端口,因为在Nat M后,即使知道,会话是不被认证的,连接不能建立.GG不能看到,呵呵(MM偷笑)

想看,不是那么容易的 如何看到? 有时候,出现连接成功的情况,开防火墙也没有用的,因为连接从内向外发起,有的防火墙不阻拦的. GG的ip:10.10.5.100 : 7890 MM的Server知道GG的IP,主动连接GG的Client! 传说中的反射式木马…… 还可以这样?(MM哭,GG笑)…… Server真的知道GG的IP吗?(GG哭,MM笑)…… 有时候,出现连接成功的情况,开防火墙也没有用的,因为连接从内向外发起,有的防火墙不阻拦的. Tips: 用用netstat,看看有没有建立莫名的TCP连接,Server不一定知道GG的IP的!

想看,不是那么容易的 情况三: 背景: 结论: GG能看到  Tips: MM们还是开着防火墙吧. MM : 10.10.5.200 : 8000 Server (TCP) GG : 10.10.5.100 /192.168.0.2 : 7890 Client(TCP) 结论: GG能看到  Tips: MM们还是开着防火墙吧.

想看,不是那么容易的 情况三: 背景: 结论: GG你想怎么看呢? GG : 10.10.5.100 / 192.168.0.2 : 7890 Client MM : 10.10.5.200 / 192.168.0.2 : 8000 Server(TCP) 结论: GG你想怎么看呢? 可能的情况: GG的Client连接MM,可是,他不知道服务器的端口,因为在Nat M后,即使知道,会话是不被认证的,连接不能建立.GG不能看到,呵呵(MM偷笑)

想看,不是那么容易的 对于这种情况,没有第三方的帮助,GG无法看到MM MM的服务器主动连接GG,假设她知道GG的公网IP,因为连接是不被认证的,所以,Nat G拒绝连接. 所以,GG无法看到MM(GG哭,MM笑)…… 对于这种情况,没有第三方的帮助,GG无法看到MM 结论:因为我们处于很多层Nat后(教育网,西工大校园网,软院,每个楼层的网关,每个宿舍的网关)所以,被外面人控制的几率,很小.

TCP的点对点通信 情况二的分析 背景:Server不知道GG的IP,如何连接? 方案一: S的IP是已知的,木马的Server和Client都连接到S,通过S的中转,进行通信. 相当于代理:QQ很多情况,用这种方式传送文件.

TCP的点对点通信 方案二: 目标:实现TCP的点对点通信 方法: GG和MM都先和S建立会话,S保存他们的socket信息 GG告诉S,希望连接MM的Server,S把请求发送给MM,还有GG的公网IP MM的Server向GG发起连接 连接可以建立,实现通信 一般,如果有一方有可以路由的IP,另一方在Nat后,Bitxxx用的就是这种方法.

TCP的点对点通信 情况三: 背景:双方都处于Nat后,要想不通过中转,实现点对点的通信. TCP穿透技术. 目前没有成熟的技术,只有一些理论出来. 非常复杂.