(1)反馈初步排查结果。
老架构设备,开启邮件安全,邮件客户端与服务器握手后2s内服务器回复响应包。
新架构设备,不开启邮件安全,邮件客户端与服务器握手后20s服务器才回复响应包。
新架构设备,开启邮件安全,邮件客户端与服务器握手后20s服务器才回复响应包。
(2)查抓取并分析新墙失败的报文(如下),发现服务器在TCP三次握手后超过5s没有回应smtp报文,导致连接超时断开。
(3)通过以上信息,制定初步策略。
关闭安全策略,封锁、过滤等服务,判断是不是基础网络问题。
基于前一步缩小范围,查看日志,确定tcp报文路径异常点。
(4)协调测试环境出现问题,检查防火墙本身配置,未发现异常。
(5)以上未发现异常,分析网络拓扑是否存在问题,网络拓扑不复杂,理应不存在环路等问题。
(6)远程环境有问题,通过多次协商,查看邮件异常时的日志,没有错误信息,处理正常,查看邮件SMTP协议,是否存在什么机制导致延迟回包?未发现此机制。
(7)开启安全策略存在问题,尝试跳过安全策略查看问题是否还存在,通过配置白名单bypass安全策略,问题仍存在,服务器仍延迟10秒以上回应,报文如下:
(8)对比老墙和新墙的报文,如下:
老墙客户端及经过AF后的报文
新墙客户端及经过AF后的报文:
对比发现TCP MSS存在差异,修改新墙MSS值验证,仍存在问题。
对比去除option,与老墙保持一致,验证仍存在问题。
(8)通过以上信息做阶段性总结:
新架构开启邮件代理,抓包查看,tcp三次握手后,服务器回包慢,导致连接超时销毁,发送邮件失败。
老架构会将tcp握手包 option(Window Scale、SACK、NOP..)去除,代理后只保留tcp头部转发,新架构按照规范保留option字段处理,修改新架构同样去除option,服务器仍回包慢,无法抓取服务器处理,不知服务器对那个字段敏感,而导致回包慢。
新架构把邮件服务器加入白名单,只走基本转发流程,原始报文原封不动转发,不做修改,服务器仍回包慢,推测是流量本身有问题或服务器处理问题。
(9)由于缺少服务器端关键信息,分析不出原因,询问客户服务器端操作系统、邮件服务器软件版本,准备本地复现,信息如下:
邮件客户端:foxmail 7.0,7.2
服务端操作系统:windows Server 2008 R2 Enterprise
邮件服务器:Mdemon V10.1.2
(10)本地搭建好环境,尝试复现未发现问题,应该是配置和网络有差异,协商客户实际服务器查看问题。
协商到服务器远程,由于此时已换为老墙,邮件服务器未找到历史日志,并且按照抓包工具wireshark无法使用,内部对齐下一步排查方法。
(11)下一步排查方案:
老墙开启bypass,看不是有异常?证明报文原始就有问题,经过老墙代理之后正常了,还是新墙处理有问题
准备好环境和工具,技术去现场换上新墙,通过服务器日志,发现服务器响应慢是因为请求DNS超时。
通过定位发现,服务器回应客户端邮件信息,会有两次根据客户端IP反查域名的过程,客户端IP不会绑定域名,这个过程一定是失败的,默认10s超时失败,2次请求邮件就延迟了至少20s。
已经确认是服务器域名配置的问题,和客户协商修改服务器DNS服务器配置,如下可解决问题。
修改配置过程中,保存发现问题,由于开始设置的邮件域名不符合通用格式,无法保存,告知客户需要将域名添加.com,即fujichinon.com,保存成功。
修改域名后,验证发送邮件无问题,但是客户反映邮箱无法使用了,因为域名发生变更,尝试修改回来,发现邮件服务器限制更改,无法更改回来,由于客户在域名后加上.com影响范围太大,不能统一修改,需要想办法回复业务。
查看邮件服务器帮助信息,通过修改映射,包头转译均无用,恢复修改,查看其他办法,查找Mdemon官网信息,看到有域名别名配置选项,遂尝试将域名fujichinon通过别名映射到fujichinon.com上,测试发现问题解决。
【问题原因分析】
新墙:服务器回应客户端邮件信息,会有两次根据客户端IP反查域名的过程,客户端IP不会绑定域名,这个过程一定是失败的,每次反查域名10秒超时失败,服务器继续往下进行,2次请求就导致邮件发送延迟了至少20秒。
老墙:老墙也有3秒的延迟,由于后续无法把老墙替换到客户环境中,无法进一步分析老墙行为。
【解决方案】
通过修改邮件服务器Mdemon的DNS配置,使其向本地请求快速得到回应,避免服务器延迟回应。
如果其他服务器有同样问题,可以开启DNS透明代理,让AF代理DNS报文,可减小响应时间,加快邮件收发。
注:建议邮件域名符合通用规范,目前服务器可使用fujichinon和fujichinon.com,此后新用户可配置fujichinon.com。