晚上十点，值班电话响了：客户反馈FTP服务器上的ACL策略明明配好了，可非办公区的电脑还是能连上去传文件。我到现场一看，ACL已经下发到接口，规则也写在明面上，逻辑看着没问题。问题就出在FTP这个协议不是一条连接那么单纯——很多网工在ACL限制FTP访问权限这件事上栽跟头，通常不是ACL语法不会写，而是没有把FTP的双通道机制和流量路径搞清楚。

这篇文章写给两类人：一类是刚接触华为/华三设备、想通过ACL给内网FTP服务器做访问控制的网工，另一类是已经配了ACL但发现“单向访问不管用”“数据通道防不住”的排错玩家。我会从FTP协议本身的坑讲起，给出一套可落地的配置步骤和完整的排错链路，最后聊聊ACL之外FTP安全还缺什么。

1. 先从FTP的双通道机制说起：ACL限制FTP绕不开的底层逻辑

1.1 为什么FTP的“访问权限”比HTTP难管

HTTP很简单：客户端发请求到服务器的80端口，服务器从同一个端口回数据，一来一回都是一条TCP连接。你限制访问某个网站，ACL只需要盯住源地址和目的端口80就行。

FTP完全不是这个套路。一个FTP会话至少包含两条TCP连接：

• 控制连接：客户端主动连服务器的TCP 21端口，所有登录指令、目录列表指令都走这条通道。
• 数据连接：真正传文件内容的那条连接，端口取决于工作模式。

打个比方，FTP的21端口是“前台接待”，你打电话先约好要什么东西；数据端口是“仓库发货口”，货从另一个地方直接出去。很多ACL策略只封了前台，忘了仓库发货口，结果客户照样能拿到货。

这就是为什么ACL限制FTP访问权限，不能只想着“限制21端口”，核心难点在于：数据连接的目标端口在一个FTP会话里是动态变化的，传统ACL如果不做端口范围固化，根本没法精确匹配。

1.2 主动模式和被动模式下的数据端口差异

FTP有PORT主动模式和PASV被动模式两种工作模式，ACL设计必须区分对待：

主动模式（PORT）流程：客户端向服务器21端口发起控制连接，登录成功后客户端告诉服务器“我在某个端口等你”，然后服务器从自己的20端口主动向客户端的指定端口发起数据连接。

被动模式（PASV）流程：客户端向服务器21端口发起控制连接，登录成功后客户端发PASV命令，服务器返回一个随机的数据端口（比如40123），客户端再去连接服务器的这个端口来传数据。

区别一句话总结：主动模式是“服务器连客户端”，被动模式是“客户端连服务器”。企业内网环境里，FTP服务器绝大多数配置为被动模式，因为如果服务器在NAT或防火墙后面，主动模式的“服务器外连”几乎必被防火墙拦。这就意味着ACL要限制的重点变成了“客户端主动访问服务器的高端口”，这个高端口的范围就是ACL规则里最关键的可变因素。

1.3 “配了ACL不管用”的根因：数据链路根本没走你限制的那条路

很多网工在eNSP或真实设备上配好ACL后，发现非授权网段照样能访问FTP，第一反应是“ACL是不是没生效”，但根因往往不是ACL没生效，而是限制的路径不对。

标准ACL只匹配源IP时，它作用在接口上后，能挡住非授权网段对21端口的连接请求。但被动模式下，客户端登录成功后从控制连接里拿到数据端口号，如果ACL没有针对这个数据端口做限制，客户端直接连数据端口就能传输文件。

在华为设备上表现得尤其典型：你配了rule 10 deny source 192.168.100.0 0.0.0.255，非授权PC访问21端口被拦；但假如在ACL生效之前就建立了控制连接，或者数据连接里的目的端口根本没被ACL检查，文件传输照常发生。碰到这种问题，先别急着怀疑设备，先看数据端口。

2. 配置ACL之前的三件事：模式确认、端口固化、位置选择

2.1 第一件事：确认FTP服务器工作在什么模式

如果你连FTP服务器的工作模式都没确认，ACL配置就是在蒙着眼睛开车。确认方法很简单：在FTP客户端连接服务器时抓包，看服务器返回的响应。

协议交互长这样：

> PASV < 227 Entering Passive Mode (192,168,20,10,156,49)

最后两个数字156,49代表数据端口号，计算方式是156 * 256 + 49 = 39985。看到227响应，说明服务器工作在被动模式，数据端口是39985。

如果看到的是类似PORT 192,168,10,5,171,17的命令，则是主动模式，服务器会从20端口往外连，ACL限制思路完全不同。

Windows IIS自带FTP、FileZilla Server、Linux的vsftpd，绝大多数默认启用被动模式，且被动端口是动态范围。这一步确认做完，你才知道ACL需要放行的端口池是多少。

2.2 第二件事：把被动模式端口范围固化成一个窗口

ACL用端口段匹配时，端口范围越精确越好。很多FTP服务器默认被动端口范围是1024-65535，甚至直接用系统随机端口，这种范围对ACL来说几乎没法封堵——你不能为了放FTP数据流，把上千个高端口全部放给某个网段，那和裸奔没有区别。

所以在配ACL前，一定要去FTP服务器端把被动端口固化到一个小窗口。

FileZilla Server配置被动模式：进入“被动模式设置”，填写端口范围40000-40099。 vsftpd的配置文件加两行：

pasv_min_port=40000 pasv_max_port=40099

Windows IIS FTP如果用的是内置被动端口范围，需要在IIS管理器的“FTP防火墙支持”里设置数据通道端口范围。

这个窗口多大合适？取决于并发文件传输数量。一个数据连接占用一个端口，100个并发就需要至少100个端口窗口。内网办公场景开100个窗口通常足够溢出，如果大规模并发，建议配合服务器端限制会话数一起考虑。

为什么要固化？因为ACL里可以这样写：放行源地址为办公网段、目的地址为FTP服务器、目的端口为40000-40099的TCP流量。窗口不固化，这条规则就是空谈。

2.3 第三件事：选ACL类型和应用位置

华为/华三设备上ACL有两类常用类型：

标准ACL（编号2000-2999）：只能匹配源IP地址，适合粗粒度控制“哪个网段能访问FTP服务器”。优点是简单、CPU压力小；缺点是无法精确到端口，同一网段内所有流量都会被放行或拦截。

扩展ACL（编号3000-3999）：可以同时匹配源IP、目的IP、协议类型、目的端口，适合精确控制FTP的21端口和被动端口池。

我的建议是：企业场景优先扩展ACL，因为你需要同时限制21端口和40000-40099的数据端口，标准ACL完全做不到端口级控制。只有当需求简单到“只允许某个网段访问服务器、网段内其他流量也已经管控”时，标准ACL才够用。

应用位置也很讲究。常见的应用方式是在服务器所在VLAN的三层接口（VLANIF）上做traffic-filter inbound，还能在服务器接入的二层物理口上做接口ACL。如果你打算只限制跨网段访问，把ACL挂到VLANIF的inbound方向即可；如果服务器和客户端在同一VLAN内，注意二层转发流量不会经过VLANIF的traffic-filter，必须把ACL挂到接入端口或网关下的其他位置。

3. 以华为/华三设备为例的ACL配置实战：从网段限制到端口级限制

3.1 最简单的网段级限制：标准ACL配置

假设FTP服务器IP是192.168.20.10，允许办公网段192.168.10.0/24访问，其他网段全部禁止。用华为VRP语法：

acl number 2001 rule 5 permit source 192.168.10.0 0.0.0.255 rule 10 deny source any quit interface Vlanif20 traffic-filter inbound acl 2001 quit

华三Comware体系语法略有差别：

acl basic 2001 rule 0 permit source 192.168.10.0 0.0.0.255 rule 5 deny quit interface Vlan-interface20 packet-filter 2001 inbound quit

必须说清楚这个方案的局限：它只限制“从哪里来”，不管“到哪个端口去”。如果办公网段里某台机器被攻陷，攻击者可以用这台机器作为跳板访问FTP服务器；如果非授权网段内的PC借用办公网段的源IP（比如改地址），也能蒙混过关。标准ACL适合快速止血，不适合精细控制。

3.2 端口级精确控制：扩展ACL同时限制21和被动数据口

在FTP被动模式端口已固化为40000-40099的前提下，配置扩展ACL：

acl number 3001 rule 5 permit tcp source 192.168.10.0 0.0.0.255 destination 192.168.20.10 0 destination-port eq 21 rule 10 permit tcp source 192.168.10.0 0.0.0.255 destination 192.168.20.10 0 destination-port range 40000 40099 rule 100 deny ip quit interface Vlanif20 traffic-filter inbound acl 3001 quit

解释一下三条规则的含义：

• rule 5：允许办公网段访问FTP服务器的21端口，建立控制连接。
• rule 10：允许办公网段访问FTP服务器的40000-40099端口，建立数据连接。
• rule 100：其余流量全部丢弃。不写这条也行，华为ACL末尾隐含deny all，但写出来便于后续排错时看命中次数。

如果FTP服务器上还开了其他服务，比如SSH或RDP，不要让这些端口被ACL放行通道一并放掉。ACL匹配规则只针对这两个目的端口做白名单，其他端口默认丢弃，是更稳妥的安全姿态。

3.3 配置下发与方向核对：别把inbound和outbound搞反

ACL的inbound和outbound方向理解是新手最容易出问题的地方。以服务器所在VLANIF的traffic-filter inbound为例，它过滤的是“从客户端进入这个三层接口的流量”。从PC发往FTP服务器的报文，在进入VLANIF时就被匹配；服务器回给PC的报文，如果没在outbound方向做限制，会被交换机正常转发。

很多人在排“FTP能登录但打不开目录”时发现，数据连接的返回报文被拦了。原因往往是：他们把同一份ACL既挂在inbound又挂在outbound，而ACL里没有放行服务器返回给办公网段的流量。服务器从40001端口回包给PC，源IP是服务器IP，目的IP是PC IP，如果outbound方向的ACL只有“办公网段访问服务器”的规则，返回报文不匹配，就会被deny掉。

正确做法通常是：入方向做源地址和目的端口的白名单，出方向保持默认放行。防火墙有状态检测，有去就有回；交换机的traffic-filter没有状态检测，必须人为保证对称性。如果你确实需要在出方向也做ACL，应该单独写一条放行“源地址为FTP服务器、目的地址为办公网段”的返回流规则。

3.4 设备自身的FTP管理通道：另一个容易忽略的场景

我们前面讨论的是“限制别人访问FTP服务器”。但还有一种场景：限制别人通过FTP协议登录交换机/路由器本身来管理设备。这个场景用的不是接口traffic-filter，而是设备自身的FTP服务ACL。

华为和华三设备都支持类似下面的配置，把FTP管理源限制在管理网段：

acl number 2002 rule 5 permit source 192.168.10.0 0.0.0.255 rule 10 deny quit ftp server acl 2002

命令细节在不同版本里略有差异，但核心逻辑一致：给设备自身的FTP服务绑定一个源地址ACL，只有管理网段能登录设备传配置文件。如果不限制，设备管理IP暴露在内网任何网段都能被FTP登录，配合弱口令就是灾难。

4. 排错实录：配了ACL之后FTP仍然能访问的完整排查链路

4.1 现象一：ACL没命中，流量从二层直接绕过了三层过滤

客户报障“ACL配了、非授权网段还是能访问FTP”。我到现场第一件事，先不看ACL规则，先看拓扑：FTP服务器和客户端是不是在同一个VLAN里。

如果是，问题已经找到一半。交换机上VLANIF的traffic-filter只过滤三层转发的流量，而同一VLAN内的PC和服务器通信，报文在交换机内部直接二层转发，根本不经过VLANIF接口。ACL挂在VLANIF上，自然永远不被命中。

这个问题在真实网络和eNSP模拟器里都很常见。排查方法：

display acl 3001

看规则后面的命中次数。如果所有规则后面都是0，再结合“同一VLAN互访”的拓扑判断，基本可以确认流量走了二层。修复方式：把ACL下推到服务器接入的物理端口，例如：

interface GigabitEthernet0/0/1 traffic-filter inbound acl 3001 quit

这样无论客户端和服务器是否同一VLAN，只要进到服务器这个端口，都要被ACL检查。代价是这个端口上所有发往服务器的流量都要被匹配一遍，注意规则顺序不要误伤正常管理流量。

4.2 现象二：控制连接被放行、数据连接被拦截，表现为“登录成功但列表不出来”

这是FTP被动模式下最经典的ACL问题。客户端能登录，能输入用户名密码，但一执行LIST或下载文件，客户端就卡住，过一会儿超时。

抓包看交互，会看到服务器返回了227响应，里面携带着数据端口，比如(192,168,20,10,156,41)，算出端口是40041。然后客户端发SYN到服务器的40041端口——如果ACL只放行了21端口，没有放行40000-40099，这个SYN包就会被末尾的deny丢弃，数据连接永远建立不起来。

排查方法依然看ACL计数：

display acl 3001

如果发现rule 10 permit tcp ... destination-port range 40000 40099的命中次数始终是0，而rule 100 deny ip在快速增长，基本可以确认数据端口池没有对上。去服务器端看被动模式实际分配的端口，和ACL放行范围做比对。

还有一种更隐蔽的情况：ACL放行的端口范围是对的，但FTP客户端没有使用被动模式，而是用了主动模式。主动模式下数据连接从服务器20端口发起，如果服务器侧ACL只放行办公网段到服务器的流量，服务器往客户端方向回包就可能被回程ACL拦掉。这时候需要检查客户端软件传输设置，把主动模式改成被动模式，或者在服务器侧放行20端口的出方向流量。

4.3 排错工具组合：display acl + display traffic-filter + 抓包验证

遇到ACL相关故障，我的固定排错三板斧：

1. display acl 3001：看规则命中次数，明确哪条规则在实际起作用。
2. display traffic-filter applied-record或display packet-filter：确认ACL真正下发到了哪些接口、哪个方向，防止配置写到接口但没下发成功。
3. 抓包：在FTP服务器侧抓包，重点看SYN包是否到达服务器网卡。如果交换机ACL已经把SYN丢弃，服务器侧抓不到任何连接尝试；如果服务器侧能看到TCP SYN，说明ACL没有拦到这个方向的流量。

抓包时用Wireshark，过滤规则写：

tcp.port == 21 || tcp.port >= 40000 && tcp.port <= 40099

重点关注是否有来自非授权网段的SYN报文。如果有SYN到达但服务器没响应，说明ACL没问题，是服务器本身或中间链路的问题。

4.4 修复与验证的完整流程

不管故障根源在哪，修复后一定要按下面这个清单做回归验证，缺一项都不算闭环：

• 授权网段PC：能登录、能列目录、能上传下载文件。
• 非授权网段PC：不能登录，任何端口都无法访问FTP服务器。
• 授权网段PC主动模式下：同步测试是否恢复正常，如果不支持，客户端切换被动模式。
• 服务器侧查看被动端口使用范围，确认40000-40099内的端口正常分配。
• 查看ACL命中计数，确认permit规则有增长、deny规则拦住了非授权流量。

另外提一个经常被忽略的分支：如果客户端是Windows且报错类似“failed to start login server: 以一种访问权限不允许的方式做了一个访问”，别光盯着交换机ACL。这个错误通常是Windows本地防火墙拦截了FTP客户端进程，或者FTP客户端所需的端口被本地策略禁用。排查时先把本机Windows防火墙临时关闭测试一下，能连上就说明是客户端本机策略问题，和网络ACL无关。

5. 除了ACL，FTP访问控制还需要补齐的几块短板

5.1 弱口令和明文传输怎么处理

ACL解决了“谁能访问FTP”的问题，但没有解决“口令是否安全”和“传输是否加密”的问题。FTP协议本身是明文传输，用户名密码在网络上抓包就能看到。ACL把访问源限制到办公网段后，攻击面小了，但内网中如果有一台主机被控制，照样能通过抓包获取FTP口令。

对付弱口令，建议顺序如下：

• 禁止匿名登录，强制强密码策略。
• 开启登录失败锁定，连续失败5次锁定账号10分钟。
• 对FTP服务器做源地址白名单，和ACL里允许访问的网段保持一致。
• 传输敏感文件时，优先使用FTPS或SFTP。

ACL承担“门禁”职责，但这些服务器侧的加固措施才是真正的“保险柜”。门禁再严，保险柜密码是123456，一样危险。

5.2 FTP监控与登录审计的配合

ACL不会告诉你谁在尝试登录FTP，但它能通过deny规则的命中次数告诉你“有人在被限制的网段尝试访问”。把这些数据接进监控体系，能发现很多异常。

华为设备上定期查看ACL命中计数是一个朴素但有效的监控手段：

display acl 3001

在服务器端配合看日志：Windows IIS的FTP日志、vsftpd的日志，里面记录了每次登录尝试的IP、用户名、成功与否。把这些日志汇聚到日志平台，设置告警规则，比如“10分钟内同一源IP登录失败5次”自动触发告警，配合ACL的deny命中变化，基本能及时发现扫描行为。

5.3 长期演进：用FTPS/SFTP替代FTP的过渡思路

ACL限制FTP只是第一步，如果业务允许，我建议尽早规划向FTPS或SFTP迁移。

FTPS是FTP over SSL，端口通常是990（隐式）或21（显式），改动最小；SFTP是SSH协议族的一部分，走22端口，服务器和客户端支持都很好。迁移期间可以先用ACL把FTP限制在内网，公网访问一律走隧道或跳板，再逐步把内部客户端的连接方式切换过去。

如果你用的是飞牛OS这类NAS设备，设置FTP后同样建议把公网端口映射收掉，只保留内网访问；必须公网访问时，优先用NAS自带的WebDAV/TLS或SFTP，而不是把FTP直接暴露出去。家庭和小型办公场景没有企业级交换机，ACL能做的有限，更多要靠服务端配置和路由器端口策略来完成访问控制。

最后说一点个人体会：ACL限制FTP访问权限这件事，表面上是几条配置命令，实际考验的是对FTP双通道工作原理的理解。我见过太多人在ACL规则里纠结得与失，最后发现数据通道端口没固化、ACL位置挂错、方向搞反——只要先把被动端口池固化、再把源地址白名单和端口白名单组合好，这个需求其实很简单。真正用心做完一次，后面再遇到类似的需求，基本就是按模板五分钟搞定的事。