记录了排查pfsense OPT interface网络连接故障问题的经过。

问题描述

使用esxi搭建网络,并使用pfsense作为路由,网络拓扑大致如下图:

Fig.1 internal network topology
Fig.1 internal network topology

目前划分了3个网段:WAN,LAN和OPT1:

  • WAN
  • LAN: 192.168.153.0/24
  • OPT1: 192.168.113.0/24

pfsense对3个网段都有对应的interface,并作为子网LAN和OPT1的网关,IP地址都设为1。

其中WAN和LAN的主机网络通信都是正常的,但是发现在OPT1的子网中,主机无法和网关通信,具体如图中主机CentOS8(192.168.113.x) ping网关(192.168.113.1)出现连接超时。

这就非常奇怪了,因为在设置LAN和OPT的时候,操作是一样的,为什么会出现LAN可以正常通信,而OPT异常的问题呢?

排查思路

数据链路层

网络ping不通,可能是数据链路层或者网络层的问题。首先考虑数据链路层,LAN和OPT在esxi的设置如下图:

Fig.2 vSwitch for LAN1
Fig.2 vSwitch for LAN1
Fig.3 vSwitch for OPT
Fig.3 vSwitch for OPT

图3中LAN2即为OPT。

esxi中,分别为LAN和OPT新建了独立的vSwitch,并各自创建了port groups。

LAN中,pfsense和Ubuntu等其它主机属于同一个port group。而OPT中,pfsense和CentOS等主机属于同一个port group。既然如此设置,那么OPT1内各主机在数据链路层的通信就应该是正常的。

抓包验证:把Kali的interface连接到OPT网段,ping网关,同时使用Wireshark抓包,发现相应的ARP查询和应答:

Fig.4 ARP in OPT
Fig.4 ARP in OPT

说明了数据链路层通信正常。

网络层

排除了数据链路层,那就只可能是网络层的问题了。

继续缩小排查范围,有如下发现:

  1. OPT网段各主机除了网关pfsense之外,相互ping正常。
  2. 从主机CentOS ping网关连接超时,但是从网关ping主机CentOS正常。
  3. 用nmap scan网关,结果”host is up”,但是1000个port都被filter。

这个时候基本上锁定是pfsense本身的问题,搜索”OPT pfsense”,发现线索: pfsense-interface-no-internet

原来pfsense在配置OPT interface的时候,防火墙默认是拒绝的;而在配置LAN interface的时候,防火墙默认开放。

配置打开OPT interface的防火墙,问题就解决了。

一点总结

无论是开发、部署还是日常维护,问题总是难免的,排查问题也是一种debug。能不能高效定位问题,找到问题的原因,乃至解决问题也是衡量所谓“高手”的一个维度。

从这个意义上来说,能够解决什么难度、多复杂的问题,也划分了能力的层次,恍如武侠小说中的排行榜。

快速缩小排查问题的范围,二分查找是很优秀的例子。而在具体应用上,则从理论和实践两方面着手,具体问题具体分析。譬如本问题如果不了解网络分层,不知道从何着手;而抓包和ping又属于具体的实践了。理论和实践相辅相成,进益是无穷尽的。

本例算是相对简单的,属于本地网络;如果是远程的,则难度又上升一个层次。读到过关于软件工程最精辟的话是“软件开发就是关于控制复杂度”(大意),现代计算机体系层层叠叠,叠床架屋已经非常复杂了,想要快速定位问题其实是很不容易的。