No route to host 之 SSH

最近DMZ的新系统上线，期间遇到了一个小问题，两天都没有解决，影响到了项目的进度。

简单来说就是Office的机器通过ssh连接不到DMZ的机器。

其中，操作系统由国内的同事安装与配置，硬件防火墙规则由泰国的同事设置。

这个问题都可能与防火墙的规则设置有关，因此出了问题，我们首先怀疑的就是防火墙的规则设置的有问题。

 

Office Server测试如下:

1.通过ssh连接DMZ 主机

#ssh   10.*.*.* -p22145  
Error1: ssh: connect to host  10.*.*.* port 22145: No route to host

 

2.ping Dmz主机

#date && ping 10.*.*.*
Fri Jul 24 14:26:22 CST 2014
PING 10.*.*.* (10.*.*.*) 56(84) bytes of data.
^C
--- 10.*.*.* ping statistics ---
42 packets transmitted, 0 received, 100% packet loss, time 41929ms

 

3. telnet DMZ主机的IP 和端口

# date && telnet 10.*.*.* 22145
Fri Jul 24 14:28:41 CST 2014
Trying 10.*.*.*...

国内的同事通过虚机的控制台登录DMZ的server

DMZ Local Server测试：
1.检查ssh服务状态是否正常

# service sshd status
openssh-daemon (pid  8014) is running...

2.检查ssh的对应的端口

#netstat -lntp|grep sshd
tcp        0      0 0.0.0.0:22145               0.0.0.0:*                   LISTEN      8014/sshd           
tcp        0      0 :::22145                    :::*                        LISTEN      8014/sshd       

   

3.检查系统的iptables策略

# iptables -L -n --line-numbers
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination         
1    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:22145

4.看本地的ip地址

#ifconfig |grep "inet addr"
inet addr:10.*.*.*  Bcast:10.*.*.*   Mask:255.255.255.192
inet addr:127.0.0.1  Mask:255.0.0.0

5.eth0的配置情况

#more /etc/sysconfig/network-scripts/ifcfg-eth0 
DEVICE=eth0
BOOTPROTO=none
HWADDR=00:30:16:80:23:32
NM_CONTROLLED=yes
ONBOOT=yes
TYPE=Ethernet
UUID="e6361119-cd22-41de-9e84-f35b50c23d52"
IPADDR=10.*.*.*
NETMASK=255.255.255.192 
GATEWAY=10.*.*.*
IPV6INIT=no
USERCTL=no

泰国的同事也将防火墙的设置规则，截图发给国内的同事看，的确是按照同事提交的申请进行设置的防火墙规则。

国内装系统的同事和泰国管理防火墙的同事开始讨论这件事，都说自己的配置没问题。由于用英语交流，况且都不是自己的母语，有些问题表达起来可能不是特别的清楚。

时间过去两天了。。。。。。

他们两个还在互相证明自己是对的，但最着急的是我。因为部门大BOSS在催这件事。

解决这件事情，只要证明其中的任何一个人说的是正确或错误就可以了，但机器都连不上，怎么证明呢？

想来想去，想到了一个移花接木的办法。

局域网中还有能ssh上的测试机，临时关闭测试机。通过虚拟机的console把新建机器的IP替换成测试机的IP.

如果可以访问测试机的IP,就证明国内的同事没问题，问题出在泰国同事的身上。如果不能访问测试机的IP,就证明问题出在系统的设置上，与泰国同事设置的防火墙关系不大。

换上测试机器的ip，这样还是不访问。这样证明了不是硬件防火墙的问题，剩下的问题就交给本地的同事去查了。果然一会他就找到了原因。

问题很简单，但愿下次不要犯类似的错误。

 

解决这个问题的关键是证明其中一个人是错误的。