关于 GFW 封锁 SMTP 的研究
226 views
Skip to first unread message
wanghx
May 2, 2010, 3:35:12 PM5/2/10
to lihlii-g, Salon Friends
lihlii RT @gfwrev:
维基百科中所说GFW的邮件过滤系统返回“…551 User not
local;…<forward-path>”是可以证实的。用SMTP发送一封典型垃圾邮件就可观测到。随后GFW会RST。此重置与
HTTP的区别在于GFW有伪造内容、无继发封锁。about
3 hours ago from web
http://bbs.chinaunix.net/viewthread.php?tid=954853
作者: leconte 时间: 2007-06-28 00:44 标题: [原创]截图分析传说中gfw造成的551 User not local错误
作者:leconte (http://blog.oolec.com)
今天在调试一个客户邮件服务器postfix的时候遇到了传说中的551错误（"551 User not local; please try [forward-path]"）
错误现象是这样的，用户采用smtp认证的方式自己给自己的邮箱发信，outlook或者foxmail会报551错误或者直接报未知错误。
而如果给别的信箱发信就不会有问题，在本机采用webmail发信也很正常。
很快就可以排除是postfix邮件系统的问题，因为我登录到服务器上采用telnet手工smtp认证发信没有任何问题。
那么问题一定出现在通往邮件服务器的路由中，只能通过抓包分析了。
我在我的本机采用wireshark抓包
同时邮件服务器采用tcpdump -w packet tcp port 25将数据包保存为文件packet
然后我在本机通过smtp发信，重复错误现象，然后将两边抓到的包用wireshark分析，结果果然不出所料。
先看截图（ip地址和邮箱域名等已经被处理掉）
1。邮件服务器端的截图
图中红色圈中可以看到，mail from指令和rcpt to指令服务器都正确的返回了250 OK
但是在随后蓝色圈中突然不断收到rst中断连接。
2。本地客户端的截图
图中红色圈中可以看到，服务器返回的信息由250 OK被替换成了"551 User not local; please try [forward-path]"。
随后又是一堆的Rst中断连接。
注意，蓝色圈中是服务器的真正返回，但是这时候连接已经中断，没有意义了。
3。很明显，双方的连接在通讯途中被干预了。更能证明这一点的一个例子是ttl值的变化。
正常情况下服务器返回信息Ip包头中的ttl值是48，大约经过了16跳。
而"551 User not local; please try [forward-path]"这条消息的ttl值是50，发生什么事情已经很明显了。。
在google上可以搜索到很多关于551错误的例子，从大家的评论来看，这件事情多半是gfw干的了。
只是我不太明白的是，gfw管这个做什么，出于什么目的？:em12:
补充:根据iceblood的提醒，我检查了一下邮件服务器，果然是放在国外的。
看来邮件服务器放在国外，使用smtp自己给自己发信就会报错。
作者:leconte (http://www.oolec.com)
[ 本帖最后由 leconte 于 2008-4-23 15:31 编辑 ]
作者: ronaldogreat910 时间: 2007-06-28 09:15
顶,辛苦LZ了
作者: abel 时间: 2007-06-28 09:19
這文章非常好,
不過圖看得較辛苦些,
建議樓主可以讓圖更美觀些,文字再大一些
以造福後進的閱讀
此外,也建議版本可以加精
作者: chifeng 时间: 2007-06-28 13:03
赞。。。分析的不错。
作者: ffxskffxsk 时间: 2007-06-28 13:13
俺公司一个同事的发国外的邮件就这样。郁闷死了，什么时候能好呢，或者怎么做，才能不发过去呀？？
作者: leconte 时间: 2007-06-28 13:31
to abel:
晚上回家我改进一下截图效果
作者: 思一克 时间: 2007-06-28 13:32
iceblood原来也分析过几乎同样的结果
作者: abel 时间: 2007-06-28 14:33
是的 !
不過 GFW 的個案太多
我認為每個個案都需要證明,這些證明如果都在 CU mail 版
效果及幫助我想對於不了解的朋友用處非常大的
作者: ffxskffxsk 时间: 2007-06-28 14:40
Connection reset by ntvirus.url.com.tw 那这个是不是也是又gfw造成的？
作者: iceblood 时间: 2007-06-28 17:13
这个早在去年的时候我就已经肯定了跨国际出口的邮件，如果服务器在境外，使用 SMTP自己给自己发邮件100%出错。
我当时只能对国内某些部门愕然~
因为实在是太无耻，太下流到极点了。
国内刚出问题的时候，是在2004年11月左右。当时我公司出现拦截问题，我在整个Internet都查不到任何资料。
由于当时找不到原因，被领导对我的能力怀疑了很长时间，当然那个时候到这个公司时间也不长。有些东西还没适应。
[ 本帖最后由 iceblood 于 2007-6-28 17:15 编辑 ]
作者: abel 时间: 2007-06-28 18:33
我從沒有碰過,但是想也知道 reverse "DCG" 搞什麼東西
作者: ctuyoung 时间: 2007-06-28 20:55
兄弟们，我有个好办法穿透GFW，大家有没有兴趣知道啊？不过需要改MTA的投递程序的
作者: Linux@初学者 时间: 2007-06-29 10:22
每年一到重大节日时就出现这样的问题呀,肯定是ZF在干预
为什么用hotmail.yahoo.gmail出现错误的概率小啊?
作者: ffxskffxsk 时间: 2007-06-29 10:50
今天 我也进行了抓包分析，发现同样的现象，另外是不是 自己家的防火墙 电信的路由器，对方国家的防火墙也可能出问题呢？
作者: ffxskffxsk 时间: 2007-06-29 10:52
to ctuyoung：什么办法？公布下吧，我们公司现在生死存亡的关头啊，再不弄好，intel客户要发彪了！！！！
作者: ctuyoung 时间: 2007-06-29 11:11
ffxskffxsk， 把邮件地址给我，我email给你，不想明盘，怕东厂的阉人们看到，这样的话这个办法就无效了
作者: ctuyoung 时间: 2007-06-29 11:20
ffxskffxsk， 我PM你了，查看你的站内短信信箱就可以了
作者: 思一克 时间: 2007-06-29 11:26
yahoo, gmail估计是在国内有邮件SERVER，你发直接到这SERVER上了，然后走专线。
作者: ffxskffxsk 时间: 2007-06-29 15:43
to ctuyoung:谢谢已经收到，正在研究
to 思一克：对于你提供的方法，不太了解,你的意思是说，让yahoo或者gmail的服务器做我们的中转服务器吗？
这样的话他们允许relay我们的邮件吗？
作者: hongfengyue 时间: 2007-06-29 22:38
能不能给我一份呀，我也遇到这样的问题了。包括最近的aaazzz的文件也是一大堆呀。
谢谢！
hongfengwbw # yahoo.com.cn
作者: feiwupiaoxue 时间: 2007-07-01 21:57
我也碰到了这样的问题,也包括aaazzz的问题,请ctuyoung大哥也发送一封邮件给我,谢谢!unixsir at 163.c.com
作者: ffxskffxsk 时间: 2007-07-02 13:58
另外还有个问题:国外发给我们的邮件也会被弹回,怎么样设置我们的inbound服务器才不会弹回国外的邮件呢?
难道也用那个方法发邮件?
作者: ctuyoung 时间: 2007-07-02 15:57
To: ffxskffxsk
其实彻底解决这个问题的办法是在海外搭建镜像服务器，对outbound的邮件辨别IP网段，如果属于海外的邮件则通过镜像服务器进行转发。对于 inbound服务器，设置不同的DNS view，是海外的投递方将邮件投递至镜像服务器然后再转发至原服务器。我提供的方法只是没有镜像服务器的情况下做的一种trick而已
作者: yj11 时间: 2007-07-02 16:26
给补充一下,别忘记加密.
作者: ffxskffxsk 时间: 2007-07-03 11:13
ai.不管了，看人家怎么处理吧，反正咱又不是做主的！
作者: 263 时间: 2007-07-04 11:05
GFW是专门用来对付国外网站的，但并不是全部国外的网站都会被封锁。
GFW主要的工作方式有以下三种：
域名劫持
全球一共有13组根（Root）级别的DNS服务器，目前中国大陆已有多台DNS镜像。但没有一组受中国大陆直接控制，所以中国大陆方面未能从根本上 控制网站域名。于是，中国大陆采取域名劫持手段来进行封锁中国大陆以外的“不合规格”的站点。域名劫持就是在劫持的网络范围内拦截域名解析的请求，分析请 求的域名，把审查范围以外的请求放行，否则直接返回假的IP地址或者什么也不做使得请求失去响应，其效果就是对特定的网址不能访问或访问的是假网址。
简单的说，域名劫持是阻止人们直接访问某个域名所绑定的网站。GFW采用这种手段来阻止中国大陆网民访问部分中国大陆以外的网站。
国家入口网关的IP封锁
这个技术和上面的域名劫持有点相似，只不过域名劫持封锁的是域名，但IP封锁是直接封锁网站所在服务器的IP地址。很多对电脑比较了解的网民开始采取 代理服务器的方式访问被封锁的站点，所以GFW也封锁了网民常用的一部份代理服务器的IP地址。
主干路由器关键字过滤阻断
这个技术有点复杂，那么我们来举个例子吧：
当你做飞机的时候，要进行安全检查，若你的行李里有违禁物品的话，将无法通过安检。
GFW相当于安全检查机器。当你访问一个国外网站的时候，必须经过GFW。GFW会检查目标网站的内容，若目标网站内含有敏感的词语的话，GFW将会 切断你和目标网站的链接。当你使用海外的搜索引擎的时候，GFW会对你输入进搜索引擎的关键词进行审查，若你输入了敏感的关键词的话，GFW将会切断你和 搜索引擎的链接。
[ 本帖最后由 263 于 2007-7-4 11:06 编辑 ]
作者: 思一克 时间: 2007-07-04 12:04
关键是GFW水平也差了点，工作不正常呀
作者: soway 时间: 2007-07-06 11:04
前几天一个朋友遇到的问题,各位看看是否跟GFW有关
他的email服务器在中国,国外的同事通过这台服务器发其他域的email正常.
但是国外的同事发给自己本域的其他同事,就不行.
同样的帐号在国内不存在问题.
以上困扰了他很久,我当时就猜测是GFW的问题.但是因为没有办法找到国外的人能一起测试,所以也不好确定.
作者: Linux@初学者 时间: 2007-07-10 11:12
最近和日本互发信件老有问题,是不是和7.7事变有关啊?
作者: fluke888 时间: 2007-07-11 09:04
我也遇到同样问题。
现在每天收到大量的投诉，都是关于发往日本的邮件的。
作者: vyouzhi 时间: 2007-07-16 15:21
:em11:
如何向国家投诉
我受不了啦
作者: wangqh_2008 时间: 2007-07-16 15:25
我也遇到同样的问题。ab...@gmail.com:
> 209.85.199.114 does not like recipient.
> Remote host said: 551 User not local; please try <forward-path>
> Giving up on 209.85.199.114
作者: 思一克 时间: 2007-07-16 16:52
现在好象多数国外的都坏了-----
6 16:04 remote 13231 connect to smtp server 212.242.40.53. try 5 of 8 hosts
16 16:04 remote 13231 HELO mail.xxxx.com
16 16:04 remote 13231 MAIL FROM:<Cl...@yyyy.com.cn> 250
16 16:04 remote 13231 RCPT TO:<n...@linco.dk> 250
16 16:04 remote 13231 DATA
16 16:04 remote 13231 sending... 354
16 16:04 remote 13231 --> "r{00}ZConnected to 212.242.40.53 but connection died. Possible duplicate! (#4.4.2){0a}
作者: vyouzhi 时间: 2007-07-16 17:33
国外的(包括香港)都出不去过不来
气死人了.
作者: 枫影谁用了 时间: 2007-07-16 17:56
是的,几乎都出不去!
海外的几乎都出不去!好在公司有多条HK专线.
作者: hwin 时间: 2007-07-16 18:15
看到 263的一个介绍，好像没法解决这个问题， 除非你在国外架设服务器
http://www.263mail.com.cn/news/abroad.htm
作者: yj11 时间: 2007-07-16 18:22
551这个报错,现在这个解决方案可以是现阶段最理想的.
补充一句:不加密你的会话是明文就会被GFW给断开的.只要加密过后的才是安全的.
[ 本帖最后由 yj11 于 2007-7-16 18:27 编辑 ]
作者: 思一克 时间: 2007-07-16 19:49
现在还没有好. 瘫痪状态.
作者: 枫影谁用了 时间: 2007-07-16 21:26
是啊!深圳..我这边的都是全部经HK出
作者: wigeboy 时间: 2007-07-17 05:14
别想了，GFW根本就是人类历史进程的倒退！这个封锁如果在电信出 国路由上面则是永久性的，网通，铁通等还好一些，很多都是临时的截断。
我从各大城市的朋友了解到，国外旅客比较集中的酒店，都是拉专线，否则影响不好的说，还影响不好，现在我国外朋友在网上见到我就说GFW，在国外都通街的 事情了，信息发达如今，还能瞒哪位？
我原来还只对于GFW只是截断WEB的连接，没想到如此不堪，连mail也弄了，目前还知道的是，只要是国外的免费网页空间，免费代理，免费DNS，一律 有杀错无放过！
一看便知道是某某部门省事，宁愿全部杀错，也不愿意放过一个！真是给人叫的好， 功夫网 ，共fei（第三声）网。
和我目前掌握的web截断来看，如果网页，BLOG，论坛在国外，只要带有任何的“法XX，熟女，美女，色情，政治”等相关文字，电信就会极其无耻的封杀IP路由，这 个是永久性的，根本无门投诉。
GFW你有客服嘛？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？
我公司已经被无故封杀了两次IP，站点为外贸的，信息产业部你说国内网络出口那么小，外贸不把站点建在国外，国外客户浏览的到网站嘛？
GFW你有客服嘛？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？
和电信的鸟人反映，那些鸟人像鹌鹑一样说他们根本不知道有这玩意，狗X！那玩意就在你们的路由上。抱歉说了不雅字体，像某伟人说的一样，我已经出离愤怒 了？
GFW你有客服嘛？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？
GFW你有客服嘛？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？
GFW你有客服嘛？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？
万一国外也像我们对国外网站一样将全部国内的IP封杀，中国的网络还能叫互联网嘛?
还真是叫China Net吧
你说你们部门把整个网络监控这样无所谓，你别设个破烂关键字就直接封IP，还没客服！！！！！！！！！！！！！！！我打电话给谁？谁赔偿我的损失？
还不给人提，一提就炸！CIA都没那么可恶
PS：我这里还有份表，如果你的网站不幸必须建在国外，那么看表的内容，赶快去掉这项吧，没道理说的
图片：
图片带明显的挑逗性质的； 《＝＝＝＝＝＝我靠，怎么才算是，我竖起中指算不算？
泳装女性臀部面对镜头、做性暗示动作及表情的； 《＝＝＝＝＝＝我靠，怎么叫暗示的表情？我舔舌头算不算？
非人体类图片但全裸身体的；
露点及用很小遮盖物防露点的；
用朦胧的方式表达色情的； 《－＝＝＝＝＝＝＝＝＝＝＝＝＝我靠，怎么才算是朦胧？
穿着SM或成人性质的衣物或成人用品的； 《＝＝＝＝＝＝全国人民一齐结扎好了
故意走光的；
特写女性或男性下体的……
文字：
文字含有明显挑逗性质的字眼的； 《＝＝＝＝＝＝＝＝＝你给我个列表好吗？最多，最多偶把列表上面的全删了，5555
含“淫荡”、“骚妇”、“熟女”等意淫词汇的； 《＝＝＝＝＝＝＝这个还好点，但是我网上骂街也不可以嘛？犯得着您动用那么多资源来封我IP还浪费电
带有侵犯个人隐私性质的“偷拍”等词汇的； 《＝＝＝＝＝＝＝＝＝“XXX被偷拍了，这些人真是贱” 某X秒后，国际长途电话，靠！！！XX数据中心，我服务器DOWN了，你TMD不是说SLA100％的嘛？我每月交几千元的钱，喂狗都好过喂你！
文字不含禁用词汇，但整体有色情感觉的； 《＝＝＝＝＝＝这个真TMD绝倒
视频：
国外禁播MTV；
带性暗示的广告片段；
三级及AV片中的诱惑性片段；
版主如果怕网监叔叔找的话，就把我的回复删除吧，抱歉，只是想发泄发泄。
[ 本帖最后由 wigeboy 于 2007-7-17 06:14 编辑 ]
作者: 思一克 时间: 2007-07-17 08:37
我也只能走专线。
做GFW的工程师水平有极大提高的必要。
作者: rubil 时间: 2007-07-17 10:17
TTL值是不是经过一个路由器就加1啊？
作者: 天下布武 时间: 2007-07-17 10:21
在国外做邮件服务器，然后用VPN加密，这样就可以解决了，DNS上面做个dns-view，国外来的邮件，先到国外邮件服务器，然后在转发到国内的邮件 服务器就可以了。
作者: vyouzhi 时间: 2007-07-17 11:03
走VPN或者说是专线之类
但服务器要懂得判断
那些应该起国内
那些应该走专线
如果解决不了这步
那还是白说了.
作者: 思一克 时间: 2007-07-17 11:07
没有你说的这样复杂。
规则：走普通的1个小时还没有发走的，或4次TRY还没有发走的一律走专线。
----基本没有错。
作者: vyouzhi 时间: 2007-07-17 11:12
但问题是只要邮件一发到国外去
马上就收到
复制代码
这种错误了
立即就退了回来
作者: aaa999 时间: 2007-07-17 11:26
550 5.1.1 User unknown (in reply to end of DATA command
哎,最近跟客户之间及其不畅啊
我在客户端做ssl发送有用吗
作者: 天下布武 时间: 2007-07-17 11:30
利用Bind 9 的view功能呀，做智能DNS，国内的ip来的，就回给国内的ip，国外的全部回给国外的服务器ip就可以了。利用bind9很容易做到的。
作者: 天下布武 时间: 2007-07-17 11:45
除非你的邮件服务器是在国外，否则没有任何用处的。
作者: ctuyoung 时间: 2007-07-17 11:57
通过GFW事件，兄弟们一定要擦亮眼睛，千万不要被某D欺骗了哦，某D从诞生到现在从来都是靠欺骗生存的！！！
作者: vyouzhi 时间: 2007-07-17 11:59
天下布武 兄
说得有点道理，但现在我还没想到如何把这个结合qmail呢，我只知道qmail有一个smtproutes，当然现在这个也在用，现在只是手工加 的，发现一个加一个，效率是差的了。
还在想如何做才行.
作者: proxima888 时间: 2007-07-17 12:00
我同事用126可以发到国外去啊！我想应该是126在发送的时候采用的加密传输。
作者: 天下布武 时间: 2007-07-17 12:12
发送的话，只能一个个手工加smtproutes了，我现在是手工在exchange里面加的，也是一个个手工加的，智能dns是可以解决客户发给我们邮 件被退的问题的。http://www.263mail.com.cn/news/abroad.htm，看看这个，263他 们解决的方案。
作者: tidezcy 时间: 2007-07-17 14:17
难怪几年了,境外的邮件用户通过公网的SMTP要发邮件给自己,从来就没成功过.
作者: uuhs_hiei 时间: 2007-07-17 15:28
试了一把，126、163、263都能发过去，难道他们都有国外镜像服务器？
作者: qsee 时间: 2007-07-17 15:39
应该是，从邮件系统到海外中转服务器之间的链路走VPN，那就没问题了
作者: qsee 时间: 2007-07-17 15:41
免费邮影响不大的~因为流量很小，GFW对这些没什么兴趣。
作者: wind521 时间: 2007-07-17 15:46
这是为什么呢？
大家有找到解决办法吗？
作者: abel 时间: 2007-07-17 16:00
這是什麼論點, 第一次見到,有什麼依據嗎 ?
我個人認為最佳解法就是不要住在cty 兄所講的某D 的地盤上,就不會被騙了
作者: uuhs_hiei 时间: 2007-07-17 16:14
免费邮流量不大？什么逻辑。我想全球这三家的邮件收发数量也能进前30
作者: henrilee 时间: 2007-07-17 16:41
主要是要做到几点：
1）在国外有服务器。
2）国内到国外的这台服务器之间是加密传输的
3）MX优先指向国外，并且采用智能dns才可以。
作者: wigeboy 时间: 2007-07-17 21:38
这个厉害，PS，最佳封IP封的猖狂到恶劣极点，昨天我国外服务器的IP又遭毒手
作者: yong_chen 时间: 2007-07-18 08:37
那有没有什么解决办法,我公司现在所有发往国外的邮件,以及国外发给我们的邮件都不行.如果这样下去会崩溃的.
作者: sannyluo 时间: 2007-07-18 09:18
ctuyoung,能否MAIL一份给我,谢谢!
作者: luo118 时间: 2007-07-18 09:35
本人测试过,
(1)用VPN发送,是可以成功的,因为VPN有加密协议,GFW检测不了.
(2) 开放SMTP SSL安全连接也可以,SSL安全连接也有加密的.
以上两点,测试过可行, 现在我公司已经通过VPN方式,得到了解决.
以上证明了,GFW 一加密了,就检测不到了,只能过个加密就可以..........
作者: 枫影谁用了 时间: 2007-07-18 09:41
你只是发送吧!
那别人给你送信呢?
当然也可以用DNS view可能可以解决一大部份.
作者: wuyiwu 时间: 2007-07-18 10:39
啊~~对不起啊`~兄弟,我刚才鼠标乱点,无意按了一个臭蛋[0] @_b
作者: uuhs_hiei 时间: 2007-07-18 11:21
能否详细些？
作者: dearhhh 时间: 2007-07-18 12:02 标题: 回复 #12 ctuyoung 的帖子
to ctuyoung:我也遇到这个情况,能不能也发一个给我?谢谢!
dea...@126.com
作者: uuhs_hiei 时间: 2007-07-18 14:13
作者: uuhs_hiei 时间: 2007-07-18 15:25
找出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.xxx.xxx.xxx does not like recipient.
Remote host said: 551 User not local; please try
Giving up on xxx.xxx.xxx.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 root wheel 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: 0x2E68FF24 Ack: 0x0 Win: 0xFFFF TcpLen: 44
TCP Options ( => 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: 0x1527A9A1 Ack: 0x2E68FF25 Win: 0x16A0 TcpLen: 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
1 210.83.214.161 0.722 ms 0.699 ms 0.612 ms
2 210.83.193.49 0.595 ms 0.486 ms 0.615 ms
3 210.52.131.6 16.979 ms 16.978 ms 16.975 ms
4 210.52.130.10 46.711 ms 45.836 ms 45.838 ms
5 210.52.132.230 50.208 ms 49.957 ms 50.085 ms
6 210.53.126.2 50.083 ms 49.955 ms 50.334 ms
7 202.147.16.125 50.583 ms 50.207 ms 50.587 ms
8 202.147.16.205 51.204 ms 50.081 ms 50.209 ms
9 202.147.16.214 103.055 ms 103.050 ms 103.179 ms
10 202.147.0.206 99.803 ms 99.677 ms 99.806 ms
11 203.192.131.250 103.802 ms 103.549 ms 103.430 ms
12 203.174.64.13 99.804 ms 100.053 ms 100.681 ms
13 203.174.64.146 100.056 ms 100.799 ms 102.075 ms
14 203.174.64.214 101.012 ms 99.676 ms 100.179 ms
15 203.131.198.80 100.805 ms 99.926 ms 99.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: 0x2E68FF25 Ack: 0x1527A9A2 Win: 0x8218 TcpLen: 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: 0x1527A9A2 Ack: 0x2E68FF25 Win: 0x16A0 TcpLen: 32
TCP Options (3) => NOP NOP TS: 9713767 121485450
32 32 30 20 35 61 2D 70 30 37 2D 62 33 2E 64 61 220 5a-p07-b3.da
74 61 2D 68 6F 74 65 6C 2E 6E 65 74 20 46 2D 53 ta-hotel.net F-S
65 63 75 72 65 2F 76 69 72 75 73 67 77 5F 73 6D ecure/virusgw_sm
74 70 2F 32 32 30 2F 35 61 2D 70 30 37 2D 62 33 tp/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: 0x2E68FF25 Ack: 0x1527A9F3 Win: 0x8218 TcpLen: 32
TCP Options (3) => NOP NOP TS: 121485551 9713767
48 45 4C 4F 20 6C 69 76 65 64 6F 6F 72 2E 63 6E HELO 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: 0x2E68FF56 Ack: 0x1527AA19 Win: 0x8218 TcpLen: 32
TCP Options (3) => NOP NOP TS: 121485755 9713787
52 43 50 54 20 54 4F 3A 3C 6A 69 6D 67 72 65 65 RCPT TO:6E 40 6E 65 70 74 75 6E 65 2E 6C 69 76 65 64 6F x_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: 0x1527AA19 Ack: 0x2E68FF7F Win: 0x0 TcpLen: 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: 0x1527AA19 Ack: 0x2E68FF7F Win: 0x16A0 TcpLen: 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: 0x2E68FF7F Ack: 0x1527AA24 Win: 0x8218 TcpLen: 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
1 210.83.214.161 0.722 ms 0.699 ms 0.612 ms
2 210.83.193.49 0.595 ms 0.486 ms 0.615 ms
3 210.52.131.6 16.979 ms 16.978 ms 16.975 ms
4 210.52.130.10 46.711 ms 45.836 ms 45.838 ms
5 210.52.132.230 50.208 ms 49.957 ms 50.085 ms
6 210.53.126.2 50.083 ms 49.955 ms 50.334 ms
7 202.147.16.125 50.583 ms 50.207 ms 50.587 ms <——可能发送错误信息的IP
8 202.147.16.205 51.204 ms 50.081 ms 50.209 ms
9 202.147.16.214 103.055 ms 103.050 ms 103.179 ms
10 202.147.0.206 99.803 ms 99.677 ms 99.806 ms
11 203.192.131.250 103.802 ms 103.549 ms 103.430 ms
12 203.174.64.13 99.804 ms 100.053 ms 100.681 ms
13 203.174.64.146 100.056 ms 100.799 ms 102.075 ms
14 203.174.64.214 101.012 ms 99.676 ms 100.179 ms
15 203.131.198.80 100.805 ms 99.926 ms 99.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恢复我们的网络.
作者: luo118 时间: 2007-07-18 18:09
那我讲一下,我用VPN,实现吧!
我们目前情况,只是SMTP 发送有问题,SMTP发国内是没有问题的,只是国外有问题,
pop3 收信国外,还是国内,都是正常的,所以针对SMTP处理.
我用的VPN处理,VPN加密后可以发送,并不影响pop3,
因为收信是根据DNS MX记录,只有你的MX记录没有错就可以了.
第一次测试,
搞好后VPN server ,和把EMAIL server 通过拔后进入 VPN server, 本地主机发送电邮时候,
也要拔入VPN server,这样在可以发送国外电邮,所以我测试一下,发送到HK,是收到的,
如果没有拔入连接SMTP服务器时候,发出去的信,即是退回来了, 证明方法可行,
不可能客叫每个客都用VPN连入来方送的对吧!所以想了第二个方法,
第二次测试,
还好我香港也有EMAIL server 不如试一下转发, 试一下转发,方法也可行,
后来看一下,日志和退信,不是每个客都可以,想一想,转发也不是很可靠,因为国内EMAIL server
转到HK EMAIL server,可能中间所有栏截,和SMTP发送的一样错误.
第三次,测试,
使用,第一次和第二次方法, 把HK Email Server和国内Email Server用VPN连接起来,
测试了N次,OK通过,没有问题, 到现在都没有客投诉发国外有问题了,
只是HK Email Server,负载高一点,
第四次,测试中,,,,,
开放smtp SSL 安全连接, 因为我的是使用QMAIL 所以不知道点样开放SMTP 安全连接,
SMTP SSL 安全连接,应也可以解决这问题, 可以开放SMTP ssl安全连接的朋友,不防试一下,
同样,知道qmail 如何开放SMTP SSL安全连接的朋友,请告诉我一下,谢谢!
作者: luo118 时间: 2007-07-18 18:15 标题: 回复 #12 ctuyoung 的帖子
如果真的有,比较好的方法,我也一份,EMAIL给我吧!
luo...@163.com
或者发上这版,不访大家分享一下,
作者: lidingsz 时间: 2007-07-18 20:47
to ctuyoung：是什么好办法？我们公司大老板也发飙了！！！！请把你的好方法发到我的信箱！万分感激！
lidi...@gmail.com
作者: lisoftware 时间: 2007-07-18 22:14
这个问题会死人的，不见血！！！
作者: zznzwh 时间: 2007-07-19 13:59
最近,
[ 本帖最后由 zznzwh 于 2007-7-19 14:51 编辑 ]
作者: zznzwh 时间: 2007-07-19 14:01 标题: 回复 #1 leconte 的帖子
最
[ 本帖最后由 zznzwh 于 2007-7-19 14:49 编辑 ]
作者: HawaiiLeo 时间: 2007-07-20 10:07
最近公司老板去中国出差，正好碰到这个问题，我找到好多资料也没有看到什么好的解决办法。
qmail的ssl连接怎么建立啊？关注中。。。
作者: arone 时间: 2007-07-21 17:11
佩服楼主的精神
作者: junongs 时间: 2007-07-27 10:04 标题: 回复 #65 luo118 的帖子
不会过段子VPN也给封了吧
作者: yong_chen 时间: 2007-07-27 11:41
现在这边好像是好一些,但还是没有完全恢复....真是不知道哪天又突然不行了....
作者: xieweihua 时间: 2007-08-18 22:01
搞什么长城！
http://bbs.chinaunix.net/viewthread.php?tid=954853
作者: leconte 时间: 2007-06-28 00:44 标题: [原创]截图分析传说中gfw造成的551 User not local错误
作者:leconte (http://blog.oolec.com)
今天在调试一个客户邮件服务器postfix的时候遇到了传说中的551错误（"551 User not local; please try [forward-path]"）
错误现象是这样的，用户采用smtp认证的方式自己给自己的邮箱发信，outlook或者foxmail会报551错误或者直接报未知错误。
而如果给别的信箱发信就不会有问题，在本机采用webmail发信也很正常。
很快就可以排除是postfix邮件系统的问题，因为我登录到服务器上采用telnet手工smtp认证发信没有任何问题。
那么问题一定出现在通往邮件服务器的路由中，只能通过抓包分析了。
我在我的本机采用wireshark抓包
同时邮件服务器采用tcpdump -w packet tcp port 25将数据包保存为文件packet
然后我在本机通过smtp发信，重复错误现象，然后将两边抓到的包用wireshark分析，结果果然不出所料。
先看截图（ip地址和邮箱域名等已经被处理掉）
1。邮件服务器端的截图
图中红色圈中可以看到，mail from指令和rcpt to指令服务器都正确的返回了250 OK
但是在随后蓝色圈中突然不断收到rst中断连接。
2。本地客户端的截图
图中红色圈中可以看到，服务器返回的信息由250 OK被替换成了"551 User not local; please try [forward-path]"。
随后又是一堆的Rst中断连接。
注意，蓝色圈中是服务器的真正返回，但是这时候连接已经中断，没有意义了。
3。很明显，双方的连接在通讯途中被干预了。更能证明这一点的一个例子是ttl值的变化。
正常情况下服务器返回信息Ip包头中的ttl值是48，大约经过了16跳。
而"551 User not local; please try [forward-path]"这条消息的ttl值是50，发生什么事情已经很明显了。。
在google上可以搜索到很多关于551错误的例子，从大家的评论来看，这件事情多半是gfw干的了。
只是我不太明白的是，gfw管这个做什么，出于什么目的？:em12:
补充:根据iceblood的提醒，我检查了一下邮件服务器，果然是放在国外的。
看来邮件服务器放在国外，使用smtp自己给自己发信就会报错。
作者:leconte (http://www.oolec.com)
[ 本帖最后由 leconte 于 2008-4-23 15:31 编辑 ]
作者: ronaldogreat910 时间: 2007-06-28 09:15
顶,辛苦LZ了
作者: abel 时间: 2007-06-28 09:19
這文章非常好,
不過圖看得較辛苦些,
建議樓主可以讓圖更美觀些,文字再大一些
以造福後進的閱讀
此外,也建議版本可以加精
作者: chifeng 时间: 2007-06-28 13:03
赞。。。分析的不错。
作者: ffxskffxsk 时间: 2007-06-28 13:13
俺公司一个同事的发国外的邮件就这样。郁闷死了，什么时候能好呢，或者怎么做，才能不发过去呀？？
作者: leconte 时间: 2007-06-28 13:31
to abel:
晚上回家我改进一下截图效果
作者: 思一克 时间: 2007-06-28 13:32
iceblood原来也分析过几乎同样的结果
作者: abel 时间: 2007-06-28 14:33
QUOTE:
原帖由 思
一克 于 2007-6-28 13:32 发表
iceblood原来也分析过几乎同样的结果
iceblood原来也分析过几乎同样的结果
是的 !
不過 GFW 的個案太多
我認為每個個案都需要證明,這些證明如果都在 CU mail 版
效果及幫助我想對於不了解的朋友用處非常大的
作者: ffxskffxsk 时间: 2007-06-28 14:40
Connection reset by ntvirus.url.com.tw 那这个是不是也是又gfw造成的？
作者: iceblood 时间: 2007-06-28 17:13
这个早在去年的时候我就已经肯定了跨国际出口的邮件，如果服务器在境外，使用 SMTP自己给自己发邮件100%出错。
我当时只能对国内某些部门愕然~
因为实在是太无耻，太下流到极点了。
国内刚出问题的时候，是在2004年11月左右。当时我公司出现拦截问题，我在整个Internet都查不到任何资料。
由于当时找不到原因，被领导对我的能力怀疑了很长时间，当然那个时候到这个公司时间也不长。有些东西还没适应。
[ 本帖最后由 iceblood 于 2007-6-28 17:15 编辑 ]
作者: abel 时间: 2007-06-28 18:33
我從沒有碰過,但是想也知道 reverse "DCG" 搞什麼東西
作者: ctuyoung 时间: 2007-06-28 20:55
兄弟们，我有个好办法穿透GFW，大家有没有兴趣知道啊？不过需要改MTA的投递程序的
作者: Linux@初学者 时间: 2007-06-29 10:22
每年一到重大节日时就出现这样的问题呀,肯定是ZF在干预
为什么用hotmail.yahoo.gmail出现错误的概率小啊?
作者: ffxskffxsk 时间: 2007-06-29 10:50
今天 我也进行了抓包分析，发现同样的现象，另外是不是 自己家的防火墙 电信的路由器，对方国家的防火墙也可能出问题呢？
作者: ffxskffxsk 时间: 2007-06-29 10:52
to ctuyoung：什么办法？公布下吧，我们公司现在生死存亡的关头啊，再不弄好，intel客户要发彪了！！！！
作者: ctuyoung 时间: 2007-06-29 11:11
ffxskffxsk， 把邮件地址给我，我email给你，不想明盘，怕东厂的阉人们看到，这样的话这个办法就无效了
作者: ctuyoung 时间: 2007-06-29 11:20
ffxskffxsk， 我PM你了，查看你的站内短信信箱就可以了
作者: 思一克 时间: 2007-06-29 11:26
yahoo, gmail估计是在国内有邮件SERVER，你发直接到这SERVER上了，然后走专线。
作者: ffxskffxsk 时间: 2007-06-29 15:43
to ctuyoung:谢谢已经收到，正在研究
to 思一克：对于你提供的方法，不太了解,你的意思是说，让yahoo或者gmail的服务器做我们的中转服务器吗？
这样的话他们允许relay我们的邮件吗？
作者: hongfengyue 时间: 2007-06-29 22:38
QUOTE:
原帖由 ctuyoung 于 2007-6-28 20:55 发表
兄弟们，我有个好办法穿透GFW，大家有没有兴趣知道啊？不过需要改MTA的投递程序的
兄弟们，我有个好办法穿透GFW，大家有没有兴趣知道啊？不过需要改MTA的投递程序的
能不能给我一份呀，我也遇到这样的问题了。包括最近的aaazzz的文件也是一大堆呀。
谢谢！
hongfengwbw # yahoo.com.cn
作者: feiwupiaoxue 时间: 2007-07-01 21:57
我也碰到了这样的问题,也包括aaazzz的问题,请ctuyoung大哥也发送一封邮件给我,谢谢!unixsir at 163.c.com
作者: ffxskffxsk 时间: 2007-07-02 13:58
另外还有个问题:国外发给我们的邮件也会被弹回,怎么样设置我们的inbound服务器才不会弹回国外的邮件呢?
难道也用那个方法发邮件?
作者: ctuyoung 时间: 2007-07-02 15:57
To: ffxskffxsk
其实彻底解决这个问题的办法是在海外搭建镜像服务器，对outbound的邮件辨别IP网段，如果属于海外的邮件则通过镜像服务器进行转发。对于 inbound服务器，设置不同的DNS view，是海外的投递方将邮件投递至镜像服务器然后再转发至原服务器。我提供的方法只是没有镜像服务器的情况下做的一种trick而已
作者: yj11 时间: 2007-07-02 16:26
QUOTE:
原帖由 ctuyoung 于 2007-7-2 15:57 发表
To: ffxskffxsk
其实彻底解决这个问题的办法是在海外搭建镜像服务器，对outbound的邮件辨别IP网段，如果属于海外的邮件则通过镜像服务器进行转发。对于 inbound服务器，设置不同的DNS view，是海外的投递方将邮件 ...
To: ffxskffxsk
其实彻底解决这个问题的办法是在海外搭建镜像服务器，对outbound的邮件辨别IP网段，如果属于海外的邮件则通过镜像服务器进行转发。对于 inbound服务器，设置不同的DNS view，是海外的投递方将邮件 ...
给补充一下,别忘记加密.
作者: ffxskffxsk 时间: 2007-07-03 11:13
ai.不管了，看人家怎么处理吧，反正咱又不是做主的！
作者: 263 时间: 2007-07-04 11:05
GFW是专门用来对付国外网站的，但并不是全部国外的网站都会被封锁。
GFW主要的工作方式有以下三种：
域名劫持
全球一共有13组根（Root）级别的DNS服务器，目前中国大陆已有多台DNS镜像。但没有一组受中国大陆直接控制，所以中国大陆方面未能从根本上 控制网站域名。于是，中国大陆采取域名劫持手段来进行封锁中国大陆以外的“不合规格”的站点。域名劫持就是在劫持的网络范围内拦截域名解析的请求，分析请 求的域名，把审查范围以外的请求放行，否则直接返回假的IP地址或者什么也不做使得请求失去响应，其效果就是对特定的网址不能访问或访问的是假网址。
简单的说，域名劫持是阻止人们直接访问某个域名所绑定的网站。GFW采用这种手段来阻止中国大陆网民访问部分中国大陆以外的网站。
国家入口网关的IP封锁
这个技术和上面的域名劫持有点相似，只不过域名劫持封锁的是域名，但IP封锁是直接封锁网站所在服务器的IP地址。很多对电脑比较了解的网民开始采取 代理服务器的方式访问被封锁的站点，所以GFW也封锁了网民常用的一部份代理服务器的IP地址。
主干路由器关键字过滤阻断
这个技术有点复杂，那么我们来举个例子吧：
当你做飞机的时候，要进行安全检查，若你的行李里有违禁物品的话，将无法通过安检。
GFW相当于安全检查机器。当你访问一个国外网站的时候，必须经过GFW。GFW会检查目标网站的内容，若目标网站内含有敏感的词语的话，GFW将会 切断你和目标网站的链接。当你使用海外的搜索引擎的时候，GFW会对你输入进搜索引擎的关键词进行审查，若你输入了敏感的关键词的话，GFW将会切断你和 搜索引擎的链接。
[ 本帖最后由 263 于 2007-7-4 11:06 编辑 ]
作者: 思一克 时间: 2007-07-04 12:04
关键是GFW水平也差了点，工作不正常呀
作者: soway 时间: 2007-07-06 11:04
前几天一个朋友遇到的问题,各位看看是否跟GFW有关
他的email服务器在中国,国外的同事通过这台服务器发其他域的email正常.
但是国外的同事发给自己本域的其他同事,就不行.
同样的帐号在国内不存在问题.
以上困扰了他很久,我当时就猜测是GFW的问题.但是因为没有办法找到国外的人能一起测试,所以也不好确定.
作者: Linux@初学者 时间: 2007-07-10 11:12
最近和日本互发信件老有问题,是不是和7.7事变有关啊?
作者: fluke888 时间: 2007-07-11 09:04
QUOTE:
原帖由 Linux@
初学者 于 2007-7-10 11:12 发表
最近和日本互发信件老有问题,是不是和7.7事变有关啊?
最近和日本互发信件老有问题,是不是和7.7事变有关啊?
我也遇到同样问题。
现在每天收到大量的投诉，都是关于发往日本的邮件的。
作者: vyouzhi 时间: 2007-07-16 15:21
:em11:
如何向国家投诉
我受不了啦
作者: wangqh_2008 时间: 2007-07-16 15:25
我也遇到同样的问题。ab...@gmail.com:
> 209.85.199.114 does not like recipient.
> Remote host said: 551 User not local; please try <forward-path>
> Giving up on 209.85.199.114
作者: 思一克 时间: 2007-07-16 16:52
现在好象多数国外的都坏了-----
6 16:04 remote 13231 connect to smtp server 212.242.40.53. try 5 of 8 hosts
16 16:04 remote 13231 HELO mail.xxxx.com
16 16:04 remote 13231 MAIL FROM:<Cl...@yyyy.com.cn> 250
16 16:04 remote 13231 RCPT TO:<n...@linco.dk> 250
16 16:04 remote 13231 DATA
16 16:04 remote 13231 sending... 354
16 16:04 remote 13231 --> "r{00}ZConnected to 212.242.40.53 but connection died. Possible duplicate! (#4.4.2){0a}
作者: vyouzhi 时间: 2007-07-16 17:33
国外的(包括香港)都出不去过不来
气死人了.
作者: 枫影谁用了 时间: 2007-07-16 17:56
是的,几乎都出不去!
海外的几乎都出不去!好在公司有多条HK专线.
作者: hwin 时间: 2007-07-16 18:15
看到 263的一个介绍，好像没法解决这个问题， 除非你在国外架设服务器
http://www.263mail.com.cn/news/abroad.htm
作者: yj11 时间: 2007-07-16 18:22
QUOTE:
原帖由 hwin 于 2007-7-16 18:15 发表
看到 263的一个介绍，好像没法解决这个问题， 除非你在国外架设服务器
http://www.263mail.com.cn/news/abroad.htm
看到 263的一个介绍，好像没法解决这个问题， 除非你在国外架设服务器
http://www.263mail.com.cn/news/abroad.htm
551这个报错,现在这个解决方案可以是现阶段最理想的.
补充一句:不加密你的会话是明文就会被GFW给断开的.只要加密过后的才是安全的.
[ 本帖最后由 yj11 于 2007-7-16 18:27 编辑 ]
作者: 思一克 时间: 2007-07-16 19:49
现在还没有好. 瘫痪状态.
作者: 枫影谁用了 时间: 2007-07-16 21:26
QUOTE:
原帖由 思
一克 于 2007-7-16 19:49 发表
现在还没有好. 瘫痪状态.
现在还没有好. 瘫痪状态.
是啊!深圳..我这边的都是全部经HK出
作者: wigeboy 时间: 2007-07-17 05:14
别想了，GFW根本就是人类历史进程的倒退！这个封锁如果在电信出 国路由上面则是永久性的，网通，铁通等还好一些，很多都是临时的截断。
我从各大城市的朋友了解到，国外旅客比较集中的酒店，都是拉专线，否则影响不好的说，还影响不好，现在我国外朋友在网上见到我就说GFW，在国外都通街的 事情了，信息发达如今，还能瞒哪位？
我原来还只对于GFW只是截断WEB的连接，没想到如此不堪，连mail也弄了，目前还知道的是，只要是国外的免费网页空间，免费代理，免费DNS，一律 有杀错无放过！
一看便知道是某某部门省事，宁愿全部杀错，也不愿意放过一个！真是给人叫的好， 功夫网 ，共fei（第三声）网。
和我目前掌握的web截断来看，如果网页，BLOG，论坛在国外，只要带有任何的“法XX，熟女，美女，色情，政治”等相关文字，电信就会极其无耻的封杀IP路由，这 个是永久性的，根本无门投诉。
GFW你有客服嘛？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？
我公司已经被无故封杀了两次IP，站点为外贸的，信息产业部你说国内网络出口那么小，外贸不把站点建在国外，国外客户浏览的到网站嘛？
GFW你有客服嘛？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？
和电信的鸟人反映，那些鸟人像鹌鹑一样说他们根本不知道有这玩意，狗X！那玩意就在你们的路由上。抱歉说了不雅字体，像某伟人说的一样，我已经出离愤怒 了？
GFW你有客服嘛？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？
GFW你有客服嘛？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？
GFW你有客服嘛？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？
万一国外也像我们对国外网站一样将全部国内的IP封杀，中国的网络还能叫互联网嘛?
还真是叫China Net吧
你说你们部门把整个网络监控这样无所谓，你别设个破烂关键字就直接封IP，还没客服！！！！！！！！！！！！！！！我打电话给谁？谁赔偿我的损失？
还不给人提，一提就炸！CIA都没那么可恶
PS：我这里还有份表，如果你的网站不幸必须建在国外，那么看表的内容，赶快去掉这项吧，没道理说的
QUOTE:
图片：
图片带明显的挑逗性质的； 《＝＝＝＝＝＝我靠，怎么才算是，我竖起中指算不算？
泳装女性臀部面对镜头、做性暗示动作及表情的； 《＝＝＝＝＝＝我靠，怎么叫暗示的表情？我舔舌头算不算？
非人体类图片但全裸身体的；
露点及用很小遮盖物防露点的；
用朦胧的方式表达色情的； 《－＝＝＝＝＝＝＝＝＝＝＝＝＝我靠，怎么才算是朦胧？
穿着SM或成人性质的衣物或成人用品的； 《＝＝＝＝＝＝全国人民一齐结扎好了
故意走光的；
特写女性或男性下体的……
文字：
文字含有明显挑逗性质的字眼的； 《＝＝＝＝＝＝＝＝＝你给我个列表好吗？最多，最多偶把列表上面的全删了，5555
含“淫荡”、“骚妇”、“熟女”等意淫词汇的； 《＝＝＝＝＝＝＝这个还好点，但是我网上骂街也不可以嘛？犯得着您动用那么多资源来封我IP还浪费电
带有侵犯个人隐私性质的“偷拍”等词汇的； 《＝＝＝＝＝＝＝＝＝“XXX被偷拍了，这些人真是贱” 某X秒后，国际长途电话，靠！！！XX数据中心，我服务器DOWN了，你TMD不是说SLA100％的嘛？我每月交几千元的钱，喂狗都好过喂你！
文字不含禁用词汇，但整体有色情感觉的； 《＝＝＝＝＝＝这个真TMD绝倒
视频：
国外禁播MTV；
带性暗示的广告片段；
三级及AV片中的诱惑性片段；
版主如果怕网监叔叔找的话，就把我的回复删除吧，抱歉，只是想发泄发泄。
[ 本帖最后由 wigeboy 于 2007-7-17 06:14 编辑 ]
作者: 思一克 时间: 2007-07-17 08:37
我也只能走专线。
做GFW的工程师水平有极大提高的必要。
作者: rubil 时间: 2007-07-17 10:17
TTL值是不是经过一个路由器就加1啊？
作者: 天下布武 时间: 2007-07-17 10:21
在国外做邮件服务器，然后用VPN加密，这样就可以解决了，DNS上面做个dns-view，国外来的邮件，先到国外邮件服务器，然后在转发到国内的邮件 服务器就可以了。
作者: vyouzhi 时间: 2007-07-17 11:03
走VPN或者说是专线之类
但服务器要懂得判断
那些应该起国内
那些应该走专线
如果解决不了这步
那还是白说了.
作者: 思一克 时间: 2007-07-17 11:07
没有你说的这样复杂。
规则：走普通的1个小时还没有发走的，或4次TRY还没有发走的一律走专线。
----基本没有错。
QUOTE:
原帖由 vyouzhi 于 2007-7-17 11:03 发表
走VPN或者说是专线之类
但服务器要懂得判断
那些应该起国内
那些应该走专线
如果解决不了这步
那还是白说了.
走VPN或者说是专线之类
但服务器要懂得判断
那些应该起国内
那些应该走专线
如果解决不了这步
那还是白说了.
作者: vyouzhi 时间: 2007-07-17 11:12
但问题是只要邮件一发到国外去
马上就收到
- Remote_host_said:_551_User_not_local;_please_try_<forward-path>
这种错误了
立即就退了回来
作者: aaa999 时间: 2007-07-17 11:26
550 5.1.1 User unknown (in reply to end of DATA command
哎,最近跟客户之间及其不畅啊
我在客户端做ssl发送有用吗
作者: 天下布武 时间: 2007-07-17 11:30
QUOTE:
原帖由 vyouzhi 于 2007-7-17 11:03 发表
走VPN或者说是专线之类
但服务器要懂得判断
那些应该起国内
那些应该走专线
如果解决不了这步
那还是白说了.
走VPN或者说是专线之类
但服务器要懂得判断
那些应该起国内
那些应该走专线
如果解决不了这步
那还是白说了.
利用Bind 9 的view功能呀，做智能DNS，国内的ip来的，就回给国内的ip，国外的全部回给国外的服务器ip就可以了。利用bind9很容易做到的。
作者: 天下布武 时间: 2007-07-17 11:45
QUOTE:
原帖由 aaa999 于 2007-7-17 11:26 发表
550 5.1.1 User unknown (in reply to end of DATA command
哎,最近跟客户之间及其不畅啊
我在客户端做ssl发送有用吗
550 5.1.1 User unknown (in reply to end of DATA command
哎,最近跟客户之间及其不畅啊
我在客户端做ssl发送有用吗
除非你的邮件服务器是在国外，否则没有任何用处的。
作者: ctuyoung 时间: 2007-07-17 11:57
通过GFW事件，兄弟们一定要擦亮眼睛，千万不要被某D欺骗了哦，某D从诞生到现在从来都是靠欺骗生存的！！！
作者: vyouzhi 时间: 2007-07-17 11:59
QUOTE:
原帖由 天
下布武 于 2007-7-17 11:30 发表
利用Bind 9 的view功能呀，做智能DNS，国内的ip来的，就回给国内的ip，国外的全部回给国外的服务器ip就可以了。利用bind9很容易做到的。
利用Bind 9 的view功能呀，做智能DNS，国内的ip来的，就回给国内的ip，国外的全部回给国外的服务器ip就可以了。利用bind9很容易做到的。
天下布武 兄
说得有点道理，但现在我还没想到如何把这个结合qmail呢，我只知道qmail有一个smtproutes，当然现在这个也在用，现在只是手工加 的，发现一个加一个，效率是差的了。
还在想如何做才行.
作者: proxima888 时间: 2007-07-17 12:00
我同事用126可以发到国外去啊！我想应该是126在发送的时候采用的加密传输。
作者: 天下布武 时间: 2007-07-17 12:12
QUOTE:
原帖由 vyouzhi 于 2007-7-17 11:59 发表
天下布武 兄
说得有点道理，但现在我还没想到如何把这个结合qmail呢，我只知道qmail有一个smtproutes，当然现在这个也在用，现在只是手工加 的，发现一个加一个，效率是差的了。
还在想如何做才行.
天下布武 兄
说得有点道理，但现在我还没想到如何把这个结合qmail呢，我只知道qmail有一个smtproutes，当然现在这个也在用，现在只是手工加 的，发现一个加一个，效率是差的了。
还在想如何做才行.
发送的话，只能一个个手工加smtproutes了，我现在是手工在exchange里面加的，也是一个个手工加的，智能dns是可以解决客户发给我们邮 件被退的问题的。http://www.263mail.com.cn/news/abroad.htm，看看这个，263他 们解决的方案。
作者: tidezcy 时间: 2007-07-17 14:17
QUOTE:
原帖由 iceblood 于 2007-6-28 17:13 发表
这个早在去年的时候我就已经肯定了跨国际出口的邮件，如果服务器在境外，使用 SMTP自己给自己发邮件100%出错。
这个早在去年的时候我就已经肯定了跨国际出口的邮件，如果服务器在境外，使用 SMTP自己给自己发邮件100%出错。
难怪几年了,境外的邮件用户通过公网的SMTP要发邮件给自己,从来就没成功过.
作者: uuhs_hiei 时间: 2007-07-17 15:28
试了一把，126、163、263都能发过去，难道他们都有国外镜像服务器？
作者: qsee 时间: 2007-07-17 15:39
应该是，从邮件系统到海外中转服务器之间的链路走VPN，那就没问题了
作者: qsee 时间: 2007-07-17 15:41
QUOTE:
原帖由 uuhs_hiei 于 2007-7-17 15:28 发表
试了一把，126、163、263都能发过去，难道他们都有国外镜像服务器？
试了一把，126、163、263都能发过去，难道他们都有国外镜像服务器？
免费邮影响不大的~因为流量很小，GFW对这些没什么兴趣。
作者: wind521 时间: 2007-07-17 15:46
这是为什么呢？
大家有找到解决办法吗？
作者: abel 时间: 2007-07-17 16:00
QUOTE:
原帖由 qsee 于 2007-7-17 15:41 发表
免费邮影响不大的~因为流量很小，GFW对这些没什么兴趣。
免费邮影响不大的~因为流量很小，GFW对这些没什么兴趣。
這是什麼論點, 第一次見到,有什麼依據嗎 ?
我個人認為最佳解法就是不要住在cty 兄所講的某D 的地盤上,就不會被騙了
作者: uuhs_hiei 时间: 2007-07-17 16:14
QUOTE:
原帖由 qsee 于 2007-7-17 15:41 发表
免费邮影响不大的~因为流量很小，GFW对这些没什么兴趣。
免费邮影响不大的~因为流量很小，GFW对这些没什么兴趣。
免费邮流量不大？什么逻辑。我想全球这三家的邮件收发数量也能进前30
作者: henrilee 时间: 2007-07-17 16:41
主要是要做到几点：
1）在国外有服务器。
2）国内到国外的这台服务器之间是加密传输的
3）MX优先指向国外，并且采用智能dns才可以。
作者: wigeboy 时间: 2007-07-17 21:38
QUOTE:
原帖由 abel 于 2007-7-17 16:00 发表
這是什麼論點, 第一次見到,有什麼依據嗎 ?
我個人認為最佳解法就是不要住在cty 兄所講的某D 的地盤上,就不會被騙了
這是什麼論點, 第一次見到,有什麼依據嗎 ?
我個人認為最佳解法就是不要住在cty 兄所講的某D 的地盤上,就不會被騙了
这个厉害，PS，最佳封IP封的猖狂到恶劣极点，昨天我国外服务器的IP又遭毒手
作者: yong_chen 时间: 2007-07-18 08:37
那有没有什么解决办法,我公司现在所有发往国外的邮件,以及国外发给我们的邮件都不行.如果这样下去会崩溃的.
作者: sannyluo 时间: 2007-07-18 09:18
ctuyoung,能否MAIL一份给我,谢谢!
作者: luo118 时间: 2007-07-18 09:35
本人测试过,
(1)用VPN发送,是可以成功的,因为VPN有加密协议,GFW检测不了.
(2) 开放SMTP SSL安全连接也可以,SSL安全连接也有加密的.
以上两点,测试过可行, 现在我公司已经通过VPN方式,得到了解决.
以上证明了,GFW 一加密了,就检测不到了,只能过个加密就可以..........
作者: 枫影谁用了 时间: 2007-07-18 09:41
QUOTE:
原帖由 luo118 于 2007-7-18 09:35 发表
本人测试过,
(1)用VPN发送,是可以成功的,因为VPN有加密协议,GFW检测不了.
(2) 开放SMTP SSL安全连接也可以,SSL安全连接也有加密的.
以上两点,测试过可行, 现在我公司已经通过VPN方式,得到了解决.
以 ...
本人测试过,
(1)用VPN发送,是可以成功的,因为VPN有加密协议,GFW检测不了.
(2) 开放SMTP SSL安全连接也可以,SSL安全连接也有加密的.
以上两点,测试过可行, 现在我公司已经通过VPN方式,得到了解决.
以 ...
你只是发送吧!
那别人给你送信呢?
当然也可以用DNS view可能可以解决一大部份.
作者: wuyiwu 时间: 2007-07-18 10:39
QUOTE:
原帖由 枫
影谁用了 于 2007-7-18 09:41 发表
你只是发送吧!
那别人给你送信呢?
当然也可以用DNS view可能可以解决一大部份.
你只是发送吧!
那别人给你送信呢?
当然也可以用DNS view可能可以解决一大部份.
啊~~对不起啊`~兄弟,我刚才鼠标乱点,无意按了一个臭蛋[0] @_b
作者: uuhs_hiei 时间: 2007-07-18 11:21
QUOTE:
原帖由 luo118 于 2007-7-18 09:35 发表
本人测试过,
(1)用VPN发送,是可以成功的,因为VPN有加密协议,GFW检测不了.
(2) 开放SMTP SSL安全连接也可以,SSL安全连接也有加密的.
以上两点,测试过可行, 现在我公司已经通过VPN方式,得到了解决.
以 ...
本人测试过,
(1)用VPN发送,是可以成功的,因为VPN有加密协议,GFW检测不了.
(2) 开放SMTP SSL安全连接也可以,SSL安全连接也有加密的.
以上两点,测试过可行, 现在我公司已经通过VPN方式,得到了解决.
以 ...
能否详细些？
作者: dearhhh 时间: 2007-07-18 12:02 标题: 回复 #12 ctuyoung 的帖子
to ctuyoung:我也遇到这个情况,能不能也发一个给我?谢谢!
dea...@126.com
作者: uuhs_hiei 时间: 2007-07-18 14:13
作者: uuhs_hiei 时间: 2007-07-18 15:25
找出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.xxx.xxx.xxx does not like recipient.
Remote host said: 551 User not local; please try
Giving up on xxx.xxx.xxx.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 root wheel 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: 0x2E68FF24 Ack: 0x0 Win: 0xFFFF TcpLen: 44
TCP Options ( => 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: 0x1527A9A1 Ack: 0x2E68FF25 Win: 0x16A0 TcpLen: 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
1 210.83.214.161 0.722 ms 0.699 ms 0.612 ms
2 210.83.193.49 0.595 ms 0.486 ms 0.615 ms
3 210.52.131.6 16.979 ms 16.978 ms 16.975 ms
4 210.52.130.10 46.711 ms 45.836 ms 45.838 ms
5 210.52.132.230 50.208 ms 49.957 ms 50.085 ms
6 210.53.126.2 50.083 ms 49.955 ms 50.334 ms
7 202.147.16.125 50.583 ms 50.207 ms 50.587 ms
8 202.147.16.205 51.204 ms 50.081 ms 50.209 ms
9 202.147.16.214 103.055 ms 103.050 ms 103.179 ms
10 202.147.0.206 99.803 ms 99.677 ms 99.806 ms
11 203.192.131.250 103.802 ms 103.549 ms 103.430 ms
12 203.174.64.13 99.804 ms 100.053 ms 100.681 ms
13 203.174.64.146 100.056 ms 100.799 ms 102.075 ms
14 203.174.64.214 101.012 ms 99.676 ms 100.179 ms
15 203.131.198.80 100.805 ms 99.926 ms 99.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: 0x2E68FF25 Ack: 0x1527A9A2 Win: 0x8218 TcpLen: 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: 0x1527A9A2 Ack: 0x2E68FF25 Win: 0x16A0 TcpLen: 32
TCP Options (3) => NOP NOP TS: 9713767 121485450
32 32 30 20 35 61 2D 70 30 37 2D 62 33 2E 64 61 220 5a-p07-b3.da
74 61 2D 68 6F 74 65 6C 2E 6E 65 74 20 46 2D 53 ta-hotel.net F-S
65 63 75 72 65 2F 76 69 72 75 73 67 77 5F 73 6D ecure/virusgw_sm
74 70 2F 32 32 30 2F 35 61 2D 70 30 37 2D 62 33 tp/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: 0x2E68FF25 Ack: 0x1527A9F3 Win: 0x8218 TcpLen: 32
TCP Options (3) => NOP NOP TS: 121485551 9713767
48 45 4C 4F 20 6C 69 76 65 64 6F 6F 72 2E 63 6E HELO 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: 0x2E68FF56 Ack: 0x1527AA19 Win: 0x8218 TcpLen: 32
TCP Options (3) => NOP NOP TS: 121485755 9713787
52 43 50 54 20 54 4F 3A 3C 6A 69 6D 67 72 65 65 RCPT TO:6E 40 6E 65 70 74 75 6E 65 2E 6C 69 76 65 64 6F x_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: 0x1527AA19 Ack: 0x2E68FF7F Win: 0x0 TcpLen: 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: 0x1527AA19 Ack: 0x2E68FF7F Win: 0x16A0 TcpLen: 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: 0x2E68FF7F Ack: 0x1527AA24 Win: 0x8218 TcpLen: 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
1 210.83.214.161 0.722 ms 0.699 ms 0.612 ms
2 210.83.193.49 0.595 ms 0.486 ms 0.615 ms
3 210.52.131.6 16.979 ms 16.978 ms 16.975 ms
4 210.52.130.10 46.711 ms 45.836 ms 45.838 ms
5 210.52.132.230 50.208 ms 49.957 ms 50.085 ms
6 210.53.126.2 50.083 ms 49.955 ms 50.334 ms
7 202.147.16.125 50.583 ms 50.207 ms 50.587 ms <——可能发送错误信息的IP
8 202.147.16.205 51.204 ms 50.081 ms 50.209 ms
9 202.147.16.214 103.055 ms 103.050 ms 103.179 ms
10 202.147.0.206 99.803 ms 99.677 ms 99.806 ms
11 203.192.131.250 103.802 ms 103.549 ms 103.430 ms
12 203.174.64.13 99.804 ms 100.053 ms 100.681 ms
13 203.174.64.146 100.056 ms 100.799 ms 102.075 ms
14 203.174.64.214 101.012 ms 99.676 ms 100.179 ms
15 203.131.198.80 100.805 ms 99.926 ms 99.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恢复我们的网络.
作者: luo118 时间: 2007-07-18 18:09
那我讲一下,我用VPN,实现吧!
我们目前情况,只是SMTP 发送有问题,SMTP发国内是没有问题的,只是国外有问题,
pop3 收信国外,还是国内,都是正常的,所以针对SMTP处理.
我用的VPN处理,VPN加密后可以发送,并不影响pop3,
因为收信是根据DNS MX记录,只有你的MX记录没有错就可以了.
第一次测试,
搞好后VPN server ,和把EMAIL server 通过拔后进入 VPN server, 本地主机发送电邮时候,
也要拔入VPN server,这样在可以发送国外电邮,所以我测试一下,发送到HK,是收到的,
如果没有拔入连接SMTP服务器时候,发出去的信,即是退回来了, 证明方法可行,
不可能客叫每个客都用VPN连入来方送的对吧!所以想了第二个方法,
第二次测试,
还好我香港也有EMAIL server 不如试一下转发, 试一下转发,方法也可行,
后来看一下,日志和退信,不是每个客都可以,想一想,转发也不是很可靠,因为国内EMAIL server
转到HK EMAIL server,可能中间所有栏截,和SMTP发送的一样错误.
第三次,测试,
使用,第一次和第二次方法, 把HK Email Server和国内Email Server用VPN连接起来,
测试了N次,OK通过,没有问题, 到现在都没有客投诉发国外有问题了,
只是HK Email Server,负载高一点,
第四次,测试中,,,,,
开放smtp SSL 安全连接, 因为我的是使用QMAIL 所以不知道点样开放SMTP 安全连接,
SMTP SSL 安全连接,应也可以解决这问题, 可以开放SMTP ssl安全连接的朋友,不防试一下,
同样,知道qmail 如何开放SMTP SSL安全连接的朋友,请告诉我一下,谢谢!
作者: luo118 时间: 2007-07-18 18:15 标题: 回复 #12 ctuyoung 的帖子
如果真的有,比较好的方法,我也一份,EMAIL给我吧!
luo...@163.com
或者发上这版,不访大家分享一下,
作者: lidingsz 时间: 2007-07-18 20:47
to ctuyoung：是什么好办法？我们公司大老板也发飙了！！！！请把你的好方法发到我的信箱！万分感激！
lidi...@gmail.com
作者: lisoftware 时间: 2007-07-18 22:14
这个问题会死人的，不见血！！！
作者: zznzwh 时间: 2007-07-19 13:59
最近,
[ 本帖最后由 zznzwh 于 2007-7-19 14:51 编辑 ]
作者: zznzwh 时间: 2007-07-19 14:01 标题: 回复 #1 leconte 的帖子
最
[ 本帖最后由 zznzwh 于 2007-7-19 14:49 编辑 ]
作者: HawaiiLeo 时间: 2007-07-20 10:07
最近公司老板去中国出差，正好碰到这个问题，我找到好多资料也没有看到什么好的解决办法。
qmail的ssl连接怎么建立啊？关注中。。。
作者: arone 时间: 2007-07-21 17:11
佩服楼主的精神
作者: junongs 时间: 2007-07-27 10:04 标题: 回复 #65 luo118 的帖子
不会过段子VPN也给封了吧
作者: yong_chen 时间: 2007-07-27 11:41
现在这边好像是好一些,但还是没有完全恢复....真是不知道哪天又突然不行了....
作者: xieweihua 时间: 2007-08-18 22:01
搞什么长城！
| 欢迎光临 ChinaUnix.net (http://bbs.chinaunix.net/) |
Reply all
Reply to author
Forward
0 new messages