★ 由来
做服务器间相互备份的时候，到某两台服务器的时候，暂且称为A、B吧，发现他们之间不能互通，查看了ip，内网ip都是一个网段的，查看防火墙，端口也都是打开的，更加离奇的是，通过rsync从B访问A的时候，提示对方拒绝连接，同时在A上面用tcpdump监听相应端口，发现没有任何数据来往，而在A上面同时用tcpdump监听，却发现发出的请求对方都有回应。这个就太离奇了，到底是怎么回事呢？在A上面查看ip设置，注意到A有三个网卡，一个公网，两个内网ip，两个内网ip分别是10.x.x.0/24网段和192.168.0.0/24网段的，而B上面只有两块网卡，一个公网ip，一个内网ip，内网是192.168.0.0/24网段的，此时突然想起来A上面有snmpd监控，查看了一下，发现A的192.168.0.0/24 网段根本从来就没有任何流量，所以就断定肯定是网线插错了。打电话给机房也不太可能，就想着自己修改一下服务器的ip好了，反正是内网ip，即使修改出问题也不会出现连不上的情况，这样至少我远程还可以继续维护。这样，恶梦开始了。。。。
★ 解决问题
修改ip是比较简单的，rh下面/etc/sysconfig/network-scripts下面几个文件修改了就好，虽然是修改内网ip，我还是对旧的配置文件做了备份，修改之后，重启了一下网络。
#service network restart
这里也有个小问题，不知道ssh怎么做到重启网络居然可以不掉线的。
重启网络之后，查看了一下ip，已经修改过来了，然后重新查看监控，发现192.168网段的网卡也有流量了，说明修改好了。再次尝试从B执行rsync从A同步数据，发现仍然连不上，A上的tcpdump仍然没有数据，B上面的仍然有回应，rsync的出错提示依然没变。这个问题太奇怪了，无意中发现在B上面监听的时候发现返回数据的主机名似乎不是A的，查看之后发现确实不是，再看同机房的服务器，发现有一台的内网ip和A的192网段的ip一样，B访问的其实是那台电脑的，那台没有开rsyc服务，所以连不上了。至此B访问A有回应的问题知道原因，那么就尝试修改一下A的192网段的ip看看。修改到另外一个ip之后，连接B，发现仍然连不上，从B也连不到A，都提示no route，可是查看route表，似乎没问题啊。到底怎么回事呢？此时突然想起来一个问题，他们不会不在一个机房吧。。。赶紧查看服务器托管信息，确定他们确实不在一起，所以访问不通是正常的。这样问题算找到原因了。
★ 新的问题
上面问题解决大概也没用多少时间，10多分钟的样子吧。正准备休息一下的时候，其他技术人员过来抱怨，说有客户反映A服务器连不上了。我看了一下我的监控，没发现问题。通过沟通之后才知道，客户访问的时候是通过内网ip来访问的，也就是10网段的ip（我的监控只能监控外网ip）。而我因为不知道情况不是刚刚修改了ip么，这也简单，改回去不就行了，况且我修改之前还做了备份呢，这里还庆幸了一下我自己想的周到。
覆盖回去，重启了一下网络，然后让他去测试一下。测试发现依然连不上，我开始觉得有点奇怪了，不是都改回去了么，想起来之前还修改过防火墙，就去恢复了防火墙设置，发现还是不行。用tcpdump监控发现似乎有10网段的ip过来访问，但是似乎没有反馈回去的数据，检查apache的日志发现没有相关的记录。而apache用公网ip访问没有任何问题。
此时就陷入了一个困境，因为我没有办法测试内网是不是还通了。其实这是我经验不足造成的，tcpdump既然能看到10网段过来的ip，那么就说明外面的内网ip连接我们这里是没问题的，那也就说明是我们服务器的问题，不会是网络的问题。
此后将防火墙清空也没有效果，tcpdump监控也一直是只有进来的，没有出去的。其实多次强调只有进来的没有出去的，我也在怀疑是不是服务器拒绝连接了？但是我手里只有这一台服务器，没有办法测试使用内网ip通过别的服务器是否能正常登陆，通过本地访问外网ip是一切正常的，可以看到apache中的日志。
这个时候老大在火车上了，有人已经打电话统治他出问题了。老大给我打电话建议我重启一下服务器。其实他这个建议没有任何意义，重启服务器也就是将重启一下网络，而我已经做过这个操作了。重启还要担一定的风险，如果起不来，还得去机房，那服务就不是停几个小时的问题了。不过没有办法中的办法，而我之前也重启一个测试服务器，没有遇到问题，所以就给服务器重启了，这样我也是争取一点时间，好想想到底哪里的问题。
此时各个小头都已经过来站在我后面了，我都能感觉手都有一点抖了。因为这台服务器是我们的主要业务之一，停几分钟就会损失不少钱，而到现在已经一个小时左右了。
重启没有遇到问题，连接上去之后就是启动服务器上面的一些服务，启动服务之后再次测试，发现问题依然，这也是意料之中的。
头脑发热中，发现来访问我们服务器的内网10网段的ip是10.0.0.0/8网段的，而我们服务器设置的是10.x.x.0/24，难道是这里的问题？修改了一下ip设置，重启了一下网络，然后用tcpdump查看，发现现在我们的服务器对10网段的ip访问有了回应了。一阵兴奋，让技术人员测试一下，发现他依然连不上。查看apache日志，似乎已经有10网段的访问记录了。那还是哪里的问题呢？
其实修改内网网段的时候就想到了，是不是路由的设置问题？这时老大提示了一下，看看之前管理服务器的技术人员留下的文档，我也突然想起来，我之前刚好对这台服务器的设置做过仔细检查，并做了备份，包括ifconfig信息，route信息，dns信息等，查看了一下，发现确实是路由表出问题了，新旧路由表不同。
★ 解决新的问题
发现问题所在就好了，接下来就是修改路由表。先修改内网ip的网段，改回10.x.x.0/24，然后修改10.0.0.0/8网段的ip的路由。修改的时候出现了对route命令不熟悉的问题，route add default gw添加了默认路由，发现不行，改来改去，手一抖，在只剩一条默认路由的情况下，执行了route del default gw命令，这样把服务器的网络给废掉了。。。
赶紧打电话联系深圳机房，花了十几二十分钟，最终联系到了机房的工作人员，可是新的问题又来了，我这里的信息没有机架位置，服务器编号等，只有ip又不能确定是哪台，还好工作人员比较好，根据我提供的服务器牌子等一些信息，找到了一台服务器。接上显示器之后，他说没有任何显示。然后说给重启了吧。其实这里他也要担一定的风险，如果这台不是我们的，他也得等着被别人投诉（不过他倒是可以有推脱的理由，可以说对方服务器莫名重启）。启动的过程很让人焦心，现在离已经过去快2个小时了，如果还不能尽快解决，恐怕我留在这个公司的时间也不多了，呵呵。
启动还算顺利，我能登陆服务器了。先启动各服务，测试发现依然连不上。然后我就查看路由，添加了255.0.0.0/8的默认路由，然后tcpdump查看，收发包正常，查看apache日志，记录也正常。让技术人员测试，也正常了。
至此，问题总算解决了。时间已经过去2个多小时了，才发现自己口干舌噪。
★ 总结一下
1) 各服务器配置情况比较混乱，一些特殊设置没有写明，这是导致服务器问题的一个原因。
2) 管理员应该及时对各服务器配置情况做备份，这样即使服务器挂了，也可以参考备份立刻恢复之前的情况。
3) 要相信系统。比如从B服务器rsync连接A服务器的时候，提示连接被拒绝。“被拒绝”说明B服务器的rsync和目的服务器进行了交流，对方不允许你连接，和连接没有响应等是有区别的。而从A服务器的tcpdump中也可以看到根本就没有对方过来的数据包，你也不要怀疑是不是被防火墙挡住了，防火墙挡住tcpdump也可以查看的。
4) 管理员应该对一些常用的命令的所有参数都比较熟悉。比如route，tcpdump，ls，tar，find等等，真正出问题的时候，你觉得还有时间让你去看man来查看某个命令是否能实现某个功能呢？你也不想当着一堆人的面现看吧。
5) 做某个操作前最好先确认一下会不会有问题，尤其是网络和防火墙相关的命令。因为要是设置出了问题，远程控制不了了，你哭都没地哭。但是工作总得做，不能因为怕出问题就不作吧，呵呵，我之前写了一篇如何给系统加防火墙的帖子，可以参考下里面的想法。
6) 压力肯定是有的，就看你怎么面对了，呵呵。平时多花些功夫，出问题了就不会手忙脚乱了。
做服务器间相互备份的时候，到某两台服务器的时候，暂且称为A、B吧，发现他们之间不能互通，查看了ip，内网ip都是一个网段的，查看防火墙，端口也都是打开的，更加离奇的是，通过rsync从B访问A的时候，提示对方拒绝连接，同时在A上面用tcpdump监听相应端口，发现没有任何数据来往，而在A上面同时用tcpdump监听，却发现发出的请求对方都有回应。这个就太离奇了，到底是怎么回事呢？在A上面查看ip设置，注意到A有三个网卡，一个公网，两个内网ip，两个内网ip分别是10.x.x.0/24网段和192.168.0.0/24网段的，而B上面只有两块网卡，一个公网ip，一个内网ip，内网是192.168.0.0/24网段的，此时突然想起来A上面有snmpd监控，查看了一下，发现A的192.168.0.0/24 网段根本从来就没有任何流量，所以就断定肯定是网线插错了。打电话给机房也不太可能，就想着自己修改一下服务器的ip好了，反正是内网ip，即使修改出问题也不会出现连不上的情况，这样至少我远程还可以继续维护。这样，恶梦开始了。。。。
★ 解决问题
修改ip是比较简单的，rh下面/etc/sysconfig/network-scripts下面几个文件修改了就好，虽然是修改内网ip，我还是对旧的配置文件做了备份，修改之后，重启了一下网络。
#service network restart
这里也有个小问题，不知道ssh怎么做到重启网络居然可以不掉线的。
重启网络之后，查看了一下ip，已经修改过来了，然后重新查看监控，发现192.168网段的网卡也有流量了，说明修改好了。再次尝试从B执行rsync从A同步数据，发现仍然连不上，A上的tcpdump仍然没有数据，B上面的仍然有回应，rsync的出错提示依然没变。这个问题太奇怪了，无意中发现在B上面监听的时候发现返回数据的主机名似乎不是A的，查看之后发现确实不是，再看同机房的服务器，发现有一台的内网ip和A的192网段的ip一样，B访问的其实是那台电脑的，那台没有开rsyc服务，所以连不上了。至此B访问A有回应的问题知道原因，那么就尝试修改一下A的192网段的ip看看。修改到另外一个ip之后，连接B，发现仍然连不上，从B也连不到A，都提示no route，可是查看route表，似乎没问题啊。到底怎么回事呢？此时突然想起来一个问题，他们不会不在一个机房吧。。。赶紧查看服务器托管信息，确定他们确实不在一起，所以访问不通是正常的。这样问题算找到原因了。
★ 新的问题
上面问题解决大概也没用多少时间，10多分钟的样子吧。正准备休息一下的时候，其他技术人员过来抱怨，说有客户反映A服务器连不上了。我看了一下我的监控，没发现问题。通过沟通之后才知道，客户访问的时候是通过内网ip来访问的，也就是10网段的ip（我的监控只能监控外网ip）。而我因为不知道情况不是刚刚修改了ip么，这也简单，改回去不就行了，况且我修改之前还做了备份呢，这里还庆幸了一下我自己想的周到。
覆盖回去，重启了一下网络，然后让他去测试一下。测试发现依然连不上，我开始觉得有点奇怪了，不是都改回去了么，想起来之前还修改过防火墙，就去恢复了防火墙设置，发现还是不行。用tcpdump监控发现似乎有10网段的ip过来访问，但是似乎没有反馈回去的数据，检查apache的日志发现没有相关的记录。而apache用公网ip访问没有任何问题。
此时就陷入了一个困境，因为我没有办法测试内网是不是还通了。其实这是我经验不足造成的，tcpdump既然能看到10网段过来的ip，那么就说明外面的内网ip连接我们这里是没问题的，那也就说明是我们服务器的问题，不会是网络的问题。
此后将防火墙清空也没有效果，tcpdump监控也一直是只有进来的，没有出去的。其实多次强调只有进来的没有出去的，我也在怀疑是不是服务器拒绝连接了？但是我手里只有这一台服务器，没有办法测试使用内网ip通过别的服务器是否能正常登陆，通过本地访问外网ip是一切正常的，可以看到apache中的日志。
这个时候老大在火车上了，有人已经打电话统治他出问题了。老大给我打电话建议我重启一下服务器。其实他这个建议没有任何意义，重启服务器也就是将重启一下网络，而我已经做过这个操作了。重启还要担一定的风险，如果起不来，还得去机房，那服务就不是停几个小时的问题了。不过没有办法中的办法，而我之前也重启一个测试服务器，没有遇到问题，所以就给服务器重启了，这样我也是争取一点时间，好想想到底哪里的问题。
此时各个小头都已经过来站在我后面了，我都能感觉手都有一点抖了。因为这台服务器是我们的主要业务之一，停几分钟就会损失不少钱，而到现在已经一个小时左右了。
重启没有遇到问题，连接上去之后就是启动服务器上面的一些服务，启动服务之后再次测试，发现问题依然，这也是意料之中的。
头脑发热中，发现来访问我们服务器的内网10网段的ip是10.0.0.0/8网段的，而我们服务器设置的是10.x.x.0/24，难道是这里的问题？修改了一下ip设置，重启了一下网络，然后用tcpdump查看，发现现在我们的服务器对10网段的ip访问有了回应了。一阵兴奋，让技术人员测试一下，发现他依然连不上。查看apache日志，似乎已经有10网段的访问记录了。那还是哪里的问题呢？
其实修改内网网段的时候就想到了，是不是路由的设置问题？这时老大提示了一下，看看之前管理服务器的技术人员留下的文档，我也突然想起来，我之前刚好对这台服务器的设置做过仔细检查，并做了备份，包括ifconfig信息，route信息，dns信息等，查看了一下，发现确实是路由表出问题了，新旧路由表不同。
★ 解决新的问题
发现问题所在就好了，接下来就是修改路由表。先修改内网ip的网段，改回10.x.x.0/24，然后修改10.0.0.0/8网段的ip的路由。修改的时候出现了对route命令不熟悉的问题，route add default gw添加了默认路由，发现不行，改来改去，手一抖，在只剩一条默认路由的情况下，执行了route del default gw命令，这样把服务器的网络给废掉了。。。
赶紧打电话联系深圳机房，花了十几二十分钟，最终联系到了机房的工作人员，可是新的问题又来了，我这里的信息没有机架位置，服务器编号等，只有ip又不能确定是哪台，还好工作人员比较好，根据我提供的服务器牌子等一些信息，找到了一台服务器。接上显示器之后，他说没有任何显示。然后说给重启了吧。其实这里他也要担一定的风险，如果这台不是我们的，他也得等着被别人投诉（不过他倒是可以有推脱的理由，可以说对方服务器莫名重启）。启动的过程很让人焦心，现在离已经过去快2个小时了，如果还不能尽快解决，恐怕我留在这个公司的时间也不多了，呵呵。
启动还算顺利，我能登陆服务器了。先启动各服务，测试发现依然连不上。然后我就查看路由，添加了255.0.0.0/8的默认路由，然后tcpdump查看，收发包正常，查看apache日志，记录也正常。让技术人员测试，也正常了。
至此，问题总算解决了。时间已经过去2个多小时了，才发现自己口干舌噪。
★ 总结一下
1) 各服务器配置情况比较混乱，一些特殊设置没有写明，这是导致服务器问题的一个原因。
2) 管理员应该及时对各服务器配置情况做备份，这样即使服务器挂了，也可以参考备份立刻恢复之前的情况。
3) 要相信系统。比如从B服务器rsync连接A服务器的时候，提示连接被拒绝。“被拒绝”说明B服务器的rsync和目的服务器进行了交流，对方不允许你连接，和连接没有响应等是有区别的。而从A服务器的tcpdump中也可以看到根本就没有对方过来的数据包，你也不要怀疑是不是被防火墙挡住了，防火墙挡住tcpdump也可以查看的。
4) 管理员应该对一些常用的命令的所有参数都比较熟悉。比如route，tcpdump，ls，tar，find等等，真正出问题的时候，你觉得还有时间让你去看man来查看某个命令是否能实现某个功能呢？你也不想当着一堆人的面现看吧。
5) 做某个操作前最好先确认一下会不会有问题，尤其是网络和防火墙相关的命令。因为要是设置出了问题，远程控制不了了，你哭都没地哭。但是工作总得做，不能因为怕出问题就不作吧，呵呵，我之前写了一篇如何给系统加防火墙的帖子，可以参考下里面的想法。
6) 压力肯定是有的，就看你怎么面对了，呵呵。平时多花些功夫，出问题了就不会手忙脚乱了。