一次诡异的网络故障

今天碰到一个诡异的网络故障，在复杂的网络条件下，保证条理的清楚是很重要的，为了警醒自己，特记录如下。 早上碰到一个事情，说IDC之间的VPN挂了，但是看了监控，发现2个IDC之间ping是没有问题的。 先描述一下网络环境。 2个IDC，一个在国内一个在国外，暂时是用pptp连接的，2边都有硬件防火墙。硬件防火墙在上周做了一次策略升级。pptp两边都是之前用linux server搭建的，2边出和进的pptp server都是单独的。基本架构就是下面这个草图了。 现在问题是，2个IDC之间的服务器有些可以ping通，有些不行，刚好加监控的都可以。 端口也可以telnet， 但是无法建立连接，一建立连接就被reset， tcpdump的结果就是如下这样的，下面这个是建立rsync的一次连接。 好了，情况都描述完成了，如何处理吧看。 这台rsync服务器检查了本身，发现没有问题，因为从本地机房进行rsync没有问题。 那问题就应该是在pptp 或者firewall上面了。 由于上周firewall做了一次升级，恢复了配置，发现问题依旧。 于是我思维凌乱了，这个是什么情况呢？ 两边可以ping，但是建立被reset， 让我感觉怎么像是gfw干的事情呢。 抱着最后一丝希望，就一点点排错吧。 首先确定了2边IDC各自内部都没有问题。 于是从pptp client上进行查，这下发现了奇怪的现象。 从pptp client服务器到另外IDC的rsync居然是可以建立连接的，那问题就应该是pptp client上了， 回想了一下之前的操作，发现了问题所在。 因为这个pptp client还拨到了c机房，之前在iptalbes中nat链里的out interface是写死了ppp0和ppp1的，但是由于不定时断线，所以哪条是ppp0，哪条是ppp1是不固定的。 于是这次本来去B IDC应该是走ppp1的，结果走了ppp0，从而导致了异常的故障发生。 从这个可以看出来, iptables的nat链是有点问题的，正常情况out interface指错了的话应该就是不通的。 但是查了man一下，发现如果没有指对的话它就会乱走，有没有规律那就再看源码了。