FAQ

为何防火墙已经打开某端口, 但还是连不上?

请确认以下2点: (1) 防火墙规则已经应用到该台主机 (2) 主机内部iptables已经关闭. 端口是否打开可以通过nc命令查看,例如 nc -nv 10.3.1.2 22, 若端口已打开而服务不可用,请检查服务是否正常运行。

还有一种造成无法访问的情况是,ISP运营商由于高危端口等原因而主动封禁了某些端口,例如445端口。 目前从运营商处反馈的端口封锁列表有:

TCP:42,135,137,138,139,445,593,1025,1068,1434,3127,3130,3332,4444,5554,6669,9996,

12345,31337,54321

UDP:135,445,593,1026,1027,1068,1434,4444,5554,9996

为什么主机无法ping通?

请确认一下2点: (1) 防火墙规则已经允许icmp,并应用到主机 (2) 主机内部iptables已经关闭

如何将某端口对所有IP开放?

源IP写: 0.0.0.0/0

如何限制某些恶意用户对我主机的访问?

如果能获得恶意用户的访问IP,可以在主机防火墙中添加一条包含该源IP的阻止(Drop)规则

内网是否有防火墙?

内网访问控制可使用网络ACL

我的内网主机如何与其他人的主机隔离?

UCloud的内网使用了软件定义网络(SDN)技术,以此来实现不同用户主机间的内网隔离

修改防火墙以后,新规则会即时生效吗?

用户在使用防火墙的时候,有时会遇到修改后规则不生效的问题。这个原因是因为tcp长连接导致的。

通常情况下,防火墙规则是立即生效的。但某些场景下,防火墙场景并不会立即生效。

以Nginx为例,Nginx会在触发keepalive_timeout(默认为65秒)之后,发送FIN包,使得Conntrack失效。

在这种场景,防火墙生效最多需要两分钟。

而对于类似于MySQL的长连接场景,由于nfconntracktcptimeoutestablished这个系统内核及参数设置其默认的失效时间为5天,这种场景一旦连接建立,通过修改防火墙的方式很难立即阻断连接。

防火墙未立即生效的补救措施:

如上面所提到的MySQL场景,其端口为3306。假设为了能够阻断来自于1.2.3.4的连接,可以在云主机中使用iptables的"RAW"表进行处理。

iptables -t raw -I PREROUTING -s 1.2.3.4 -p tcp -m tcp --dport 3306 -j DROP

该方法之所以能够生效,是因为Linux系统的Netfilter中,在PREROUTING以及OUTPUT这两个HOOK的conntrack之前,安插了一个优先级更高的RAW表。通过RAW表,就可以分离出不需要被conntrack的流量了。

修改防火墙以后,原先已建立的连接会受到什么影响?

防火墙不会阻断已建立的连接,所以就连接不受防火墙规则变化的影响。