找出GFW在Internet的位置，全面分析国内到国外邮件受阻的原因
找出GFW在Internet的位置作者：刘宏光
邮件：iceblood_at_163.com
网址：http://www.nettf.net
日期：2006-9-26
看到这篇文章的标题，可能有人要问GFW到底是什么？虽然GFW在一部分人的眼睛里并不陌生了，但相对与大部分人来说还是非常陌生的，引用我在google里找到的一段话：
The Great Fire Wall of China的简写，意指“中国网络防火墙”(字面意为“中国防火长城”)，这是对“国家公共网络监控系统”的俗称，国内简称“防火长城”。
GFW是“金盾工程”的一个子功能。“金盾工程”是以公安信息网络为先导，以各项公安工作信息化为主要内容，建立统一指挥、快速反应、协同作战机制，在全国范围内开展公安信息化的工程，主要包括建设公安综合业务通信网、公安综合信息系统、全国公安指挥调度系统以及全国公共网络监控中心等。该项目2003年开始生效。一般所说的GFW，主要指公共网络监控系统，尤其是指对境外涉及敏感内容的网站、IP地址、关键词、网址等的过滤。
GFW的效果通常为，国内网络用户无法访问某些国外网站或者网页；或者国外网络用户无法访问国内的某些网站或者网页。这里的无法访问，有永久性的无法访问（比如色情网站），也有因为URL中含有敏感关键词或者网页上有敏感内容而暂时性的无法访问。
国家防火墙并非中国的专利。实际上，美国也有国家网络监控系统，对进出美国的每一封电子邮件进行内容扫描。不同的是，中国的国家防火墙会直接切断敏感连接，而美国的国家防火墙（考虑更名）则只是做数据监控记录。伊朗、巴基斯坦、乌兹别克斯坦、北非共和国、叙利亚、缅甸、马尔代夫、古巴、北韩、南韩、沙特阿拉伯、阿拉伯联合酋长国、也门使用与金盾类似的国家防火墙。
看了以上这段话相信大家都比较清楚GFW到底是什么了，但是一直有人说有GFW，但具体的位置在哪里呢？我们如何查出GFW到底在哪里呢？好象并没多少文章有介绍，所以我这里针对这点特别写了这篇文章。
GFW这个东西很早我就已经知道，并且为防止GFW的“骚扰”我已经想过了很多办法来避免了，但由于收到外界机制的影响，仍然不可能完全避过GFW，而最近我所在的公司发到国外的邮件总是受阻，严重影响了公司的正常业务，所以我必须给他们一个非常圆满的答复，才有了找到GFW的位置的想法。
最近我们公司总是有人反应发到日本的邮件会被退回来，我查看了一下退信内容，发现主要有如下内容：
<xxx@xxxxx.xxx>:
xxx.xxx.xxx.xxx does not like recipient.
Remote host said: 551 User not local; please try <forward-path>
Giving up on xxx.xxx.xxx.xxx.
或者：
<xxxx@xxxxxxx.xxx>:
xxx.xxx.xxx.xxx does not like recipient.
Remote host said: 500 error
Giving up on xxx.xxx.xxx.xxx.
而在邮件服务器的日志上发现如下内容：
Sep 26 14:46:23 livedoor qmail: 1159253183.972578 delivery 118310: failure: xxx.xxx.xxx.xxx_does_not_like_recipient./Remote_host_said:_500_error/Giving_up_on_xxx.xxx.xxx.xxx./
由于总报这样的问题，所以我在公司的网关服务器上安装上snort这个入侵检测软件，当然我并没发挥入侵检测的功能，因为我只想要里面的sniff功能探测数据包，然后等待这种现象的再次来到。当邮件日志里再次出现上面的日志内容的时候，我进入网关服务器查找所有相关这个IP的记录，并且根据时间找到了：
-rw-------1 rootwheel 6941 Sep 26 14:44 TCP:60661-25
现在就请大家跟着我来分析这个文件：
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/26-14:44:52.643691 0:E0:FC:34:C0:86 -> 0:14:22:1F:4A:49 type:0x800 len:0x4E
10.4.1.4:60661 -> 203.131.198.80:25 TCP TTL:127 TOS:0x0 ID:32988 IpLen:20 DgmLen:64 DF
******S* Seq: 0x2E68FF24Ack: 0x0Win: 0xFFFFTcpLen: 44
TCP Options (8) => MSS: 1460 NOP WS: 1 NOP NOP TS: 121485349 0
TCP Options => SackOK EOL
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
这是我们公司的邮件服务器10.4.1.4向对方发送SYN的请求包，TTL为127，虽然我们的邮件服务器是FreeBSD，但我还是把TTL修改为128了，而邮件服务器和网关服务器之间有一个路由，所以TTL会减1，就成为了127。
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/26-14:44:52.744474 0:14:22:1F:4A:49 -> 0:11:43:58:71:FF type:0x800 len:0x4A
203.131.198.80:25 -> 10.4.1.4:60661 TCP TTL:49 TOS:0x0 ID:0 IpLen:20 DgmLen:60 DF
***A**S* Seq: 0x1527A9A1Ack: 0x2E68FF25Win: 0x16A0TcpLen: 40
TCP Options (5) => MSS: 1460 SackOK TS: 9713757 121485349 NOP
TCP Options => WS: 0
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
这里为对方服务器向我们公司的服务器回复SYN+ACK包。可以看到TTL为49，由于对方也是FreeBSD系统，而FreeBSD的默认TTL值为64，这样我们可以计算出我们的服务器到对方的服务器经过的路由数，64减49等于15，所以网关服务器到对方服务器经过了15个路由，使用traceroute命令追踪了一下结果，如下：
gw2# traceroute -n 203.131.198.80
traceroute to 203.131.198.80 (203.131.198.80), 64 hops max, 40 byte packets
1210.83.214.1610.722 ms0.699 ms0.612 ms
2210.83.193.490.595 ms0.486 ms0.615 ms
3210.52.131.616.979 ms16.978 ms16.975 ms
4210.52.130.1046.711 ms45.836 ms45.838 ms
5210.52.132.23050.208 ms49.957 ms50.085 ms
6210.53.126.250.083 ms49.955 ms50.334 ms
7202.147.16.12550.583 ms50.207 ms50.587 ms
8202.147.16.20551.204 ms50.081 ms50.209 ms
9202.147.16.214103.055 ms103.050 ms103.179 ms
10202.147.0.20699.803 ms99.677 ms99.806 ms
11203.192.131.250103.802 ms103.549 ms103.430 ms
12203.174.64.1399.804 ms100.053 ms100.681 ms
13203.174.64.146100.056 ms100.799 ms102.075 ms
14203.174.64.214101.012 ms99.676 ms100.179 ms
15203.131.198.80100.805 ms99.926 ms99.929 ms
gw2#
这里可以很清楚的看到为15跳，充分证明了TTL没有任何问题，而对方的服务器也没有使用防火墙以及NAT来映射25号端口。
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/26-14:44:52.744633 0:E0:FC:34:C0:86 -> 0:14:22:1F:4A:49 type:0x800 len:0x42
10.4.1.4:60661 -> 203.131.198.80:25 TCP TTL:127 TOS:0x0 ID:33011 IpLen:20 DgmLen:52 DF
***A**** Seq: 0x2E68FF25Ack: 0x1527A9A2Win: 0x8218TcpLen: 32
TCP Options (3) => NOP NOP TS: 121485450 9713757
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
这里是我们公司返回一个ACK包，这样整个TCP连接的握手成功，接下来就要开始传输数据了。
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/26-14:44:52.845542 0:14:22:1F:4A:49 -> 0:11:43:58:71:FF type:0x800 len:0x93
203.131.198.80:25 -> 10.4.1.4:60661 TCP TTL:49 TOS:0x0 ID:37317 IpLen:20 DgmLen:133 DF
***AP*** Seq: 0x1527A9A2Ack: 0x2E68FF25Win: 0x16A0TcpLen: 32
TCP Options (3) => NOP NOP TS: 9713767 121485450
32 32 30 20 35 61 2D 70 30 37 2D 62 33 2E 64 61220 5a-p07-b3.da
74 61 2D 68 6F 74 65 6C 2E 6E 65 74 20 46 2D 53ta-hotel.net F-S
65 63 75 72 65 2F 76 69 72 75 73 67 77 5F 73 6Decure/virusgw_sm
74 70 2F 32 32 30 2F 35 61 2D 70 30 37 2D 62 33tp/220/5a-p07-b3
2E 64 61 74 61 2D 68 6F 74 65 6C 2E 6E 65 74 0D.data-hotel.net.
0A .
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
首先是对方服务器给了我们一个220的服务器信息。
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/26-14:44:52.845826 0:E0:FC:34:C0:86 -> 0:14:22:1F:4A:49 type:0x800 len:0x54
10.4.1.4:60661 -> 203.131.198.80:25 TCP TTL:127 TOS:0x0 ID:33066 IpLen:20 DgmLen:70 DF
***AP*** Seq: 0x2E68FF25Ack: 0x1527A9F3Win: 0x8218TcpLen: 32
TCP Options (3) => NOP NOP TS: 121485551 9713767
48 45 4C 4F 20 6C 69 76 65 64 6F 6F 72 2E 63 6EHELO livedoor.cn
0D 0A ..
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
我们的服务器给对方发送了一个SMTP协议所需要的HELO信息。由于内容太多中间SMTP协议的握手我就不再详细介绍了，所以我这里直接跳到出问题的地方。
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/26-14:44:53.049710 0:E0:FC:34:C0:86 -> 0:14:22:1F:4A:49 type:0x800 len:0x6B
10.4.1.4:60661 -> 203.131.198.80:25 TCP TTL:127 TOS:0x0 ID:33110 IpLen:20 DgmLen:93 DF
***AP*** Seq: 0x2E68FF56Ack: 0x1527AA19Win: 0x8218TcpLen: 32
TCP Options (3) => NOP NOP TS: 121485755 9713787
52 43 50 54 20 54 4F 3A 3C 6A 69 6D 67 72 65 65RCPT TO:<xxxxx
6E 40 6E 65 70 74 75 6E 65 2E 6C 69 76 65 64 6Fx_at_neptune.livedo
6F 72 2E 63 6F 6D 3E 0D 0A or.com>..
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
在这里，当我们的服务器发送RCPT To的信息到对方服务器以后，按照SMTP协议的原理，对方在有这个用户的情况下应该返回250 ok这个信息，但是这个时候问题出现了，我们的服务器马上收到一个如下的信息：
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/26-14:44:53.103763 0:14:22:1F:4A:49 -> 0:11:43:58:71:FF type:0x800 len:0x41
203.131.198.80:25 -> 10.4.1.4:60661 TCP TTL:57 TOS:0x0 ID:64 IpLen:20 DgmLen:51
***AP*** Seq: 0x1527AA19Ack: 0x2E68FF7FWin: 0x0TcpLen: 20
35 30 30 20 65 72 72 6F 72 0D 0A 500 error..
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
500 error的信息，再看看TTL的值，57？对端服务器的TTL由49突然变成了57？理论上来说说不过去，再接着看后面的信息：
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/26-14:44:53.154738 0:14:22:1F:4A:49 -> 0:11:43:58:71:FF type:0x800 len:0x4A
203.131.198.80:25 -> 10.4.1.4:60661 TCP TTL:49 TOS:0x0 ID:37321 IpLen:20 DgmLen:60 DF
***AP*** Seq: 0x1527AA19Ack: 0x2E68FF7FWin: 0x16A0TcpLen: 32
TCP Options (3) => NOP NOP TS: 9713798 121485755
32 35 30 20 4F 6B 0D 0A 250 Ok..
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
这才是真是服务器发送过来的信息，而由于500 error的错误信息比250 Ok的正确信息先到达我们的服务器，所以我们的服务器这个时候就已经认为对方服务器错误，所以按照SMTP协议必须终止邮件的发送，所以这个时候我们的服务器发送：
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
09/26-14:44:53.155026 0:E0:FC:34:C0:86 -> 0:14:22:1F:4A:49 type:0x800 len:0x48
10.4.1.4:60661 -> 203.131.198.80:25 TCP TTL:127 TOS:0x0 ID:33131 IpLen:20 DgmLen:58 DF
***AP**F Seq: 0x2E68FF7FAck: 0x1527AA24Win: 0x8218TcpLen: 32
TCP Options (3) => NOP NOP TS: 121485860 9713787
51 55 49 54 0D 0A QUIT..
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
QUIT退出……，就这样一封正常的邮件被活生生的截断了。
现在我们来开始看那个TTL为57的信息，根据我的经验对方的TTL默认值应该是64，所以64减57等于7，也就是说这个阻断我们信息的信号来自和第7个路由同网断或者就是第7个路由。现在再看看我最上面的traceroute的结果：
gw2# traceroute -n 203.131.198.80
traceroute to 203.131.198.80 (203.131.198.80), 64 hops max, 40 byte packets
1210.83.214.1610.722 ms0.699 ms0.612 ms
2210.83.193.490.595 ms0.486 ms0.615 ms
3210.52.131.616.979 ms16.978 ms16.975 ms
4210.52.130.1046.711 ms45.836 ms45.838 ms
5210.52.132.23050.208 ms49.957 ms50.085 ms
6210.53.126.250.083 ms49.955 ms50.334 ms
7202.147.16.12550.583 ms50.207 ms50.587 ms<——可能发送错误信息的IP
8202.147.16.20551.204 ms50.081 ms50.209 ms
9202.147.16.214103.055 ms103.050 ms103.179 ms
10202.147.0.20699.803 ms99.677 ms99.806 ms
11203.192.131.250103.802 ms103.549 ms103.430 ms
12203.174.64.1399.804 ms100.053 ms100.681 ms
13203.174.64.146100.056 ms100.799 ms102.075 ms
14203.174.64.214101.012 ms99.676 ms100.179 ms
15203.131.198.80100.805 ms99.926 ms99.929 ms<——真实服务器的IP
gw2#
使用 http://www.linkwan.com/gb/broadmeter/VisitorInfo/QureyIP.asp 的IP地址查询查到 202.147.16.125 属于澳大利亚，难道澳大利亚在监视我们的网络，想想虽然有这个可能性，但应该不会明显到这个程度。所以我想应该不是这个IP地址，然后我查了查第6跳的IP地址 210.53.126.2 ，通过查询显示为“中国网通”很明显6和7之间就是中国网通的出口路由，那么GFW就顺理成章安装在 210.53.126.2 这个IP之后。
从上面的分析我们就可以完全的肯定阻断公司邮件正常来往的就是 210.53.126.2 之后的GFW发送的假信息。还好公司的邮件全都是正常的，GFW并不会完全封死，所以过段时间以后会自动恢复。由于发送的邮件非常多，也不一定是同一个服务器，所以不能用VPN来解决，不太现实。当碰到这样的问题的时候我们目前只怕唯一能做的就是等待，直到 GFW恢复我们的网络。
找出GFW在Internet的位置.zip
--------------------------------------------------------------------------------
xmbbx 回复于：2006-10-09 17:29:55
沙发。。。。。
--------------------------------------------------------------------------------
醉卧水云间 回复于：2006-10-09 22:44:08
板凳！前不久版主还和别人争半天呢。
重要的是给出一个合理的绕行方案来，否则太被动了。
[ 本帖最后由 醉卧水云间 于 2006-10-9 22:45 编辑 ]
--------------------------------------------------------------------------------
思一克 回复于：2006-10-10 09:05:15
To 水云间，
内容的过滤装置我很早就知道，也受过其骚扰。
上次那个帖子时主要是垃圾aaazzz是否是FW造成的问题。我原来一直以为不是。
好的方法，
CLIENT端用SSL收发。
如果有专线，可以从专线饶，在专线另端建立mirror服务器。
--------------------------------------------------------------------------------
ardi 回复于：2006-10-10 11:19:37
如果把GFW 的500 error 回应跳过，是否就可正常发信了
--------------------------------------------------------------------------------
anthonyfeng 回复于：2006-10-10 13:52:56
相比楼主，我的方法太简陋了，只是根据traceroute 结果内，最后一台国内的router就当作GFW，受教了。
--------------------------------------------------------------------------------
刘五十三 回复于：2006-10-10 16:55:52
好强，我一直以为500错误是对方垃圾邮件处理拒绝了中国的ip，还有这一招。不过不让国内的发邮件到国外有什么用，应该是不让国外的发过来才对吧。或者pop的时候看到了关键字就切掉连接。
--------------------------------------------------------------------------------
iceblood 回复于：2006-10-10 17:10:51
国外到国内也会发这样的信息的，GFW是双向的。
--------------------------------------------------------------------------------
boyhyc 回复于：2006-10-10 17:31:33
又学习拉……
--------------------------------------------------------------------------------
abel 回复于：2006-10-11 09:00:02
樓主的分析真是捧極了 ! 雖就事而論 GFW 就是出口,但如水雲兄過去所講的 ISP 也是有這類的東西的
至於解決方法,最簡單的就是 PGP 之流,和 Server 支不技援加密較無關係,
但對 user 的習慣可能就會有影響了
--------------------------------------------------------------------------------
孤独的鹰 回复于：2006-10-11 11:19:44
老的GFW是不能模拟服务器的TTL但是新的版本已经可以了
而且被动模式已经被主动模式取代了
所以SSL都会没用了
--------------------------------------------------------------------------------
ecloud 回复于：2006-10-11 11:34:09
SSL怎么会没用？
GFW的反应完全基于内容过滤，SSL以后的邮件标题和内容都是密文，GFW怎么知道这个连接是需要切断的？如果他不做出反应的话也根本不会出现TTL问题
当然，如果你同一个IP还干过其他明文的、GFW认为“不好”的事情，那就跟mail无关了，但是会殃及鱼池
--------------------------------------------------------------------------------
vyouzhi 回复于：2006-10-11 11:50:51
做邮件管理员的
要顾及千丝万缕的关系
正常发送了
就来了一个垃圾邮件
这会才知道有一个叫DCC
一会又来一个叫SPF
好不容易把这些搞定
又出来了一个国安的
真累
有时候太难对客户解释更多的了
--------------------------------------------------------------------------------
vyouzhi 回复于：2006-10-11 11:51:50
SSL是有用
但客户有时候真的很笨的
你也不可能一个一个的对他们说吧
--------------------------------------------------------------------------------
iceblood 回复于：2006-10-11 12:01:12
等能模拟TTL我再用新的方法追踪。呵呵~
--------------------------------------------------------------------------------
孤独的鹰 回复于：2006-10-11 12:14:19
楼上的
已经有了
你就上吧
哈哈
--------------------------------------------------------------------------------
iceblood 回复于：2006-10-11 12:19:20
目前还没影响我，等影响我再说。
[ 本帖最后由 iceblood 于 2006-10-11 12:26 编辑 ]
--------------------------------------------------------------------------------
nisshinzgz 回复于：2006-10-11 15:14:13
我公司已经中招了！都是到日本的mail！
Remote host said: 551 User not local; please try <forward-path>
有时候能过去，发多了就退回来了！真郁闷！
--------------------------------------------------------------------------------
刘五十三 回复于：2006-10-12 16:52:10
不对啊，rcpt的时候切断你的连接的话，他还没有看到你data后的内容，怎么知道你这邮件有问题？这还是邮件头的数据交换呢，没有到data的邮件正文啊？
--------------------------------------------------------------------------------
abel 回复于：2006-10-12 22:13:05
引用：原帖由 刘五十三 于 2006-10-12 16:52 发表
不对啊，rcpt的时候切断你的连接的话，他还没有看到你data后的内容，怎么知道你这邮件有问题？这还是邮件头的数据交换呢，没有到data的邮件正文啊？
他是會根據歷史資料/行為, 或人為設定所產生的,所以有可能在 rcpt 時回應,
--------------------------------------------------------------------------------
penny_kan 回复于：2006-10-13 00:31:41
去年还有留意这个问题，今年找原因的时候都把这茬给忘了
德国一个用户通过他们的SAP（通不通过其实应该一样吧，反正也是要通过一台能发送邮件的服务器RELAY）发送邮件功能发到我们这边，一直会返回下面这些错误
(reason: 354 go ahead)
<silas.zhong@domain.com>
(reason: 500 error)
----- Transcript of session follows ----- ... while talking to mail.domain.com.:
>>> DATA
<<< 500 error
554 5.0.0 Service unavailable
554 5.5.0 Remote protocol error
451 4.4.1 reply: read error from mail.domain.com
<sender@domain.COM>... Deferred: Connection reset by mail.domain.com.
从我们的邮件服务器上查日志又没有错误的
--------------------------------------------------------------------------------
yj11 回复于：2006-10-13 10:45:38
引用：原帖由 iceblood 于 2006-10-9 11:49 发表
找出GFW在Internet的位置
作者：刘宏光
邮件：iceblood_at_163.com
网址：http://www.nettf.net
日期：2006-9-26
看到这篇文章的标题，可能有人要问GFW到底是什么？虽然GFW在一部分人的眼睛 ...
高手,佩服
--------------------------------------------------------------------------------
ronaldogreat910 回复于：2006-10-13 16:14:10
请教iceblood ,如果服务器在大陆只外,也就是GFW只外,但是使用的客户端在大陆啦,那还会是一样的吗?
--------------------------------------------------------------------------------
iceblood 回复于：2006-10-13 16:18:38
是的，只要连接通过了GFW，都会手到影响。
CLIENT-SERVER的还好解决，可以在server装SSL来解决。
但是SERVER-SERVER就不行了，大部分服务器之间的传输都是明文的。
--------------------------------------------------------------------------------
ronaldogreat910 回复于：2006-10-13 16:50:10
还有有点想不通,你做的路由测试都是在服务器上做的,对吧.
我举一个详细的例子,我在四川访问台湾的邮件服务器,然后给日本的服务器发送邮件.
当我把邮件写完后点击发送邮件后的过程是怎么样的呢?应该和LZ最前面讲到的不一样吧,因为这个时候GFW不是在两个服务器之间了.
在下愚昧,望iceblood 能讲解一下.
--------------------------------------------------------------------------------
iceblood 回复于：2006-10-13 16:56:04
的确是不同了，但会出现新的问题，就是你连接台湾的服务器会有问题。
连接上会被自动中断。
[ 本帖最后由 iceblood 于 2006-10-13 18:33 编辑 ]
--------------------------------------------------------------------------------
nisshinzgz 回复于：2006-10-13 18:46:10
难到我们只能等待GWF给我们回复网络吗？
--------------------------------------------------------------------------------
hongfengyue 回复于：2006-10-14 10:09:16
受教了。看来目前最好俄解决方式就是使用SSL或者VPN了。
--------------------------------------------------------------------------------
孤独的鹰 回复于：2006-10-16 14:29:41
引用：原帖由 hongfengyue 于 2006-10-14 10:09 发表
受教了。看来目前最好俄解决方式就是使用SSL或者VPN了。
GFW工作原理是抢在你的服务器之前发送rst包
因为gfw不能伪造TTL,所以你分析的时候可以根据ttl的不同去找到GFW的位置
[ 本帖最后由 孤独的鹰 于 2006-10-16 14:31 编辑 ]
--------------------------------------------------------------------------------
o00o 回复于：2006-10-20 23:17:59
引用：原帖由 孤独的鹰 于 2006-10-16 14:29 发表
GFW工作原理是抢在你的服务器之前发送rst包
因为gfw不能伪造TTL,所以你分析的时候可以根据ttl的不同去找到GFW的位置
如果gfw只向对方的服务器发送rst，如何探知？
--------------------------------------------------------------------------------
iceblood 回复于：2006-10-21 00:42:20
引用：原帖由 o00o 于 2006-10-20 23:17 发表
如果gfw只向对方的服务器发送rst，如何探知？
发送的RST同样有TTL
--------------------------------------------------------------------------------
penny_kan 回复于：2006-10-23 10:56:19
如果是基于内容的过滤，需要什么样的设备才能够承受呢
--------------------------------------------------------------------------------
刘五十三 回复于：2006-10-25 12:30:17
党好强，其实可以用我的假地址的方式让那些发论子的邮件只能发出几百封就被干掉。国内的邮件服务器都不用修改任何东西，gfw已经帮你探测了smtp连接中的地址了。gfw对cpu处理能力也要小很多了。
http://bbs.chinaunix.net/viewthread.php?tid=790812&highlight=
--------------------------------------------------------------------------------
Zer4tul 回复于：2006-12-14 00:07:18
iceblood同学……服了你了……葱白一个……
--------------------------------------------------------------------------------
ipaddr 回复于：2006-12-15 17:53:04
楼主的精神值得ＰＦ，
其实，tracert一下，就知道在哪个位置了。
--------------------------------------------------------------------------------
poper 回复于：2006-12-19 00:54:39
7202.147.16.12550.583 ms50.207 ms50.587 ms<——可能发送错误信息的IP
楼主,这个地址在香港尖沙嘴,网通的地址.
--------------------------------------------------------------------------------
ccf 回复于：2006-12-23 11:35:34
大家好，我就是出现在楼主顶楼说的一样的问题才搜到这个贴的，马上用SSL就可以用，不过好景不长，没到一周25端口就在SSL之前被封了，所以我想在国外建一个邮件代理服务器（就是客户端只把smtp,pop3,地址改到国外的地址，不用装代理客户端，然后服务器走VPN过来），但没有找到合适的软件，大家可以推荐一下吗，linux和windows都无所谓，谢谢大家了。
原文链接：http://bbs.chinaunix.net/viewthread.php?tid=838622
转载请注明作者名及原文出处
页:
[1]