在我安装了iptables-servies后,所有的iptables rules都没有了,现在slave机器不能顺利的telnet到master的机器,情况如下
master上只有一条规则
其实在这里很清晰看到,对于来自192.168.1.108的机器,想要访问这里的mysql端口,采用的是tcp的协议,并且对于这样的请求是ACCEPT的,问题很可能就不是出自于防火墙了,可能端口没有被启用,或者不存在
查询了一下,的确如此,不存在3306的MySQL端口
《iptables介绍》=================================
防火墙虽然是一堵墙,但这堵墙是有规则的墙,有的人会被放行,有的人会被隔绝墙外,而这个规则是iptables这个工具来实现的
iptables真的像数据库里面的一张table,里面存放了很多规则,里面的规则有三类,具体属于叫做链chain
1.input chain——有的人来上门,那么这些人就要被INPUT CHAIN的规则所检查,有点像进地铁时的检查
2.forward chain——有的人不上来上门找人的,他们只是把这里当做中介的通道,比如隧道,人行天桥,就接受FORWARD CHAIN的规则检查
3.output chain——不是所有的客人都要进地铁,有些客人到站了下车出去,本机也有ping别人主机的需要,就接受OUTPUT CHAIN的规则检查
并不是所有的客人都可以符合input/forward/output里面的三条规则的,如果没有符合的话,就采取默认的规则,默认是放行还是禁止呢,写在括号里面
这台机器都是ACCEPT的默认规则
我们现在尝试在master机器上加上一条,DROP掉来自slave的连接,看看会怎么样
解释一下,规则是一条一条覆盖上去的,类比个别session 对变量的设置,会覆盖 global 的环境变量,在这个例子里面,最开始是 policy ACCEPT的宽松政策,然后在这条政策上面,加上了允许192.168.1.108的信息包访问本机器,但是后来有加上了一条规则,是把来自192.168.1.108的链接全都扔到垃圾桶里面,我们要很小心的去设置这些规则,因为有可能一条错误的规则,就会把所有的链接都隔绝门外了,现在来自192.168.1.108的“请求链接”结果是这样子的
完全杳无音讯,完全没有反馈,这让我想起了客体关系理论,我们都想要寻求客体的回应,这里还要注意的是,ACCEPT和REJECT,INPUT这些需要大写
现在把这条规则删除掉,可以先查询这条规则的line-number,然后根据规则的policy type和line number去删除掉
删除的结果是,slave的192.168.1.108可以重新链接了
如果客体的应对方式 --jump REJECT的话
iptables --append INPUT --source 192.168.1.108 --jump REJECT
对方感受到的,并不是--jump DROP那种卡主没有回应,而是无法到达,被拒绝的反馈