2012年4月12日断网的技术记录

原文:http://shell909090.com/blog/2012/04/2012%e5%b9%b44%e6%9c%8812%e6%97%a5%e6%96%ad%e7%bd%91%e7%9a%84%e6%8a%80%e6%9c%af%e8%ae%b0%e5%bd%95/

  4月12日上午, 大约北京时间10点(UTC02:00前后), 中国大部分地区发生了一次断网. 这次断网我有幸正好在使用网络, 因此跟踪调试了整个过程.
1. 网络开始中断
   当时我在公司里面用ssh调整一台国外的机器, 同时用另一台机器作为ssh跳板访问google. 问题发生的时候, 很多国外网站都无法打开, ssh指令不能工作. 我的第一反应就是, GFW针对ssh做了拦截.
   鉴于其他可能, 我登录回了家中, 从家里的机器直接ssh到国外的跳板, 一切正常. 莫非只是我这里的ssh发生了断路? 我正在这么猜测的时候, 家里的ssh也随即断开. 我kill了当前进程, 重新连接后, 恢复了对家里服务器的控制, 但是境外的ssh跳板已经不能连接.
   至此, 可以确定中国出国网络逐步发生中断, 针对什么协议, 机制如何尚不清楚.
   但是, 我同时用同一台机器打开了openvpn, openvpn会提供一个内网接口. 我偶然的用这个内网iface访问了一下, 一切正常. 再尝试了一下, openvpn上网正常. 这说明问题可能局限在ssh上.
2. 这不是一个个例, 这是大规模断网
   既然我对境外服务器还有控制能力, 我就更换了一个ssh端口, 但是问题并没有解决. 这似乎说明封锁不是针对端口(port), 而是针对协议(protocol)的. 为了确证这点, 我对通讯过程做了抓包, 但是结果出乎我的意料. 问题并不出现在ssh握手的时候, 而是tcp第二步的syn-ack回包彻底消失. 这表明封锁并不针对ssh协议, 而是tcp协议栈!
   这非常疯狂, 如果是这样的话, 大部分基于tcp的网络协议将无法工作, 包括境外大部分网站的http协议. 我从twitter上看到, 很多人的各种工具都相继失效, 并且境外很多的http(而非https)确实无法访问, 这和我的判断相一致. 这是针对tcp协议栈的大规模拦截.
3. 为什么特殊
   通常而言, GFW有三个常见工作模式.
* dns污染
* ip封锁
* 深度包过滤(关键字拦截)
  其中dns封锁只对域名有效, ip封锁只对ip有效, 只有深度包过滤才是最麻烦的. 但是通常深度包过滤是使用旁路过滤的方式, 在连接出现问题时发出rst包干扰tcp工作. 而本次的模式是将境外向境内的tcp包直接丢弃, 而非rst. 这是ip封锁的模式. 根据上文的经验和我在twitter上收集的有限几个数据, 封锁范围似乎随着不同的网络连接方式而发生变化. 我这里可以连接的设备在其他人那里就无法继续连接, 反之亦然. 似乎是在多个不同的核心路由器上逐步部署不同的路由器规则, 对境外的特定回包给与丢弃. 这表示GFW的工作模式有可能从包检测向白名单过渡.
4. 为什么麻烦
   白名单是很难对付的一种模式. 对于深度包检测, 可以通过修改包的封装性质予以绕过. ssh/vpn都是这类的典型方式. 然而白名单使得你很难在境外部署一台处于你自己控制之下的服务器. 即使你可以在境外弄到一台服务器(这到不困难), 也没有希望将服务器ip加入白名单内. 由于白名单内的都是国家认可的服务器, 因此上面运作的服务基本都是无可能进行绕行的.
发表评论