📚 课程目录第4章 ACL基础与IoT适配

4. ACL基础与IoT适配

在IoT网络中，ACL（Access Control List，访问控制列表）是设备侧最直接、最经济的流量过滤手段。它通常部署在路由器、三层交换机、工业网关或具备ACL能力的IoT边缘设备上，通过匹配报文的特定字段并执行permit或deny动作，决定哪些流量可以进入或离开某个接口。与防火墙相比，ACL更轻量、更贴近转发路径，适合在资源受限的IoT设备上做第一道粗粒度或中等粒度的访问控制。

理解ACL，首先要区分它的几种类型。标准ACL只能匹配源IP地址，编号范围通常为1～99和1300～1999；扩展ACL可以匹配源IP、目的IP、协议类型、源端口、目的端口、TCP标志位等，编号范围通常为100～199和2000～2699；命名ACL用名称代替编号，便于管理和修改；时间ACL在扩展ACL基础上增加时间段参数，使规则只在指定时间窗口内生效；基于对象的ACL则把一组IP地址或端口封装成对象组，用对象名引用，减少重复配置。这五类ACL在IoT场景中的适用位置和部署要点差异明显。

标准ACL的匹配能力最弱，只能看源IP。在IoT场景中，它适合部署在靠近目的端的接口上，用来限制哪些管理网段可以访问设备本身。例如，一台工业网关只允许运维网段10.10.20.0/24通过SSH管理，其他源地址一律拒绝。由于标准ACL不关心目的地址，如果把它放在靠近源端的位置，会误伤该源地址访问其他所有目标的流量，因此部署位置必须谨慎。

扩展ACL是IoT边缘最常用的类型。它可以精确到“谁、用什么协议、访问谁的什么端口”。例如，某工厂的摄像头网段是192.168.30.0/24，MQTT Broker地址是10.10.50.10，要求摄像头只能向Broker的8883端口发送MQTT over TLS流量，其他流量全部阻断。对应的扩展ACL规则可以写成：

ip access-list extended IOT_CAMERA_OUT
 permit tcp 192.168.30.0 0.0.0.255 host 10.10.50.10 eq 8883
 deny   ip any any log
!
interface GigabitEthernet0/1
 ip access-group IOT_CAMERA_OUT in

这条规则中，源地址是摄像头网段，目的地址是Broker主机，协议为TCP，目的端口为8883。deny语句带log参数，便于在设备日志中观察被拒绝的异常流量。部署时要注意ACL的隐含拒绝：每条ACL末尾都有一条不可见的deny any any，因此必须显式放行必要的管理流量，否则设备可能连远程登录都被阻断。

命名ACL的价值在于可维护性。IoT项目往往有几十台甚至上百台同型号网关，如果使用编号ACL，后期插入一条规则需要重新编号，容易出错。命名ACL允许在已有条目之间插入新规则，并且名称本身可以表达用途，例如“IOT_EDGE_IN”“MGMT_ACCESS”“MQTT_ONLY”。在批量部署时，可以把命名ACL作为配置模板的一部分，通过自动化工具下发到各设备，减少人工差异。

时间ACL在IoT场景中主要用于“按需放行”。例如，某园区的门禁控制器只在工作日07:00～19:00允许向管理服务器上传刷卡记录，非工作时段即使设备被劫持也无法外联。配置时需要先定义time-range，再在扩展ACL中引用：

time-range WORK_HOURS
 periodic weekdays 07:00 to 19:00
!
ip access-list extended IOT_ACCESS_CTRL
 permit tcp 192.168.40.0 0.0.0.255 host 10.10.50.20 eq 443 time-range WORK_HOURS
 deny   ip any any log

时间ACL生效的前提是设备时钟准确。IoT设备通常通过NTP同步时间，如果时钟漂移，时间段判断就会出错。部署前应确认NTP服务器可达，并检查设备当前时间与标准时间的偏差。此外，时间ACL只对引用它的规则生效，不影响其他规则，因此可以和其他ACL类型组合使用。

基于对象的ACL解决的是“地址和端口重复”的问题。假设一个IoT项目中，有20台传感器需要访问3台服务器，如果逐条写ACL，会产生大量重复条目。使用对象组后，可以把传感器地址放入一个IP对象组，把服务器地址和端口放入另一个对象组，ACL中直接引用对象组名称：

object-group network SENSOR_GROUP
 host 192.168.50.11
 host 192.168.50.12
 range 192.168.50.20 192.168.50.30
!
object-group service MQTT_SVC tcp
 port-object eq 8883
!
ip access-list extended IOT_SENSOR_TO_SERVER
 permit tcp object-group SENSOR_GROUP object-group SERVER_GROUP object-group MQTT_SVC
 deny   ip any any log

这样，当新增传感器或更换服务器时，只需修改对象组，不需要改动ACL主体。对象ACL特别适合设备数量多、变更频繁的IoT环境，但要注意不同厂商对对象组的支持程度不同，部分低端IoT设备可能只支持标准ACL或扩展ACL，部署前需要确认设备能力。

在IoT设备上部署ACL时，建议遵循“先放行管理流量、再放行业务流量、最后显式拒绝其余流量”的顺序。每次修改ACL后，先用show access-lists查看命中计数，确认规则是否按预期匹配，再观察设备日志中的deny记录，判断是否存在误拦截。

ACL规则是有顺序的，设备从上到下逐条匹配，一旦命中就执行动作并停止后续匹配。因此，具体的permit规则必须放在宽泛的deny规则之前。如果顺序写反，可能导致合法业务流量被提前阻断，而排障时又难以从配置表面看出问题。

综合来看，五类ACL在IoT设备上的选择可以这样判断：只需要限制源地址时用标准ACL；需要精确控制协议和端口时用扩展ACL；需要频繁修改和批量管理时用命名ACL；需要按时间段控制时用时间ACL；需要减少重复条目、管理大量地址和端口时用对象ACL。实际部署中，它们经常组合使用，例如用命名扩展ACL承载主体规则，用时间ACL控制生效窗口，用对象组简化地址维护。关键是把ACL放在正确的接口和方向上，并用日志和命中计数验证效果，而不是配置完就认为策略已经生效。