华为交换机FTP配置：客户端/服务端、传输排错与安全实践-平芜编程栈

1. 先搞清楚一件事：交换机在FTP里到底扮演什么角色

1.1 为什么同一个"FTP配置"，能问出两种完全不同的答案

很多人搜"华为交换机FTP配置"，搜到的答案往往对不上自己的场景，根源就在于没先分清设备的角色。FTP是一套客户端与服务端的模型，交换机在这套模型里既能当客户端去连别人的FTP服务器，也能自己开一个FTP服务让外面的电脑连进来。这两种配置路径几乎没有交集：前者只需要一条ftp命令加一个可达的IP，后者要动AAA、本地用户、服务使能、目录权限、ACL一整串东西。我见过不少新手照着"ftp server enable"敲了半天，结果他只是想把配置文件传到一台已经架好的文件服务器上，根本用不上服务端配置。

从运维实际频率看，设备作为FTP客户端占绝大多数。日常的配置备份、版本升级、日志导出，都是交换机主动伸手去拿文件或送文件。设备作为FTP服务端则是另一类需求：现场没有独立文件服务器，只有一台笔记本，想让笔记本直接读走交换机flash里的配置文件，这时候才需要交换机自己当服务器。还有一种情况是自动化脚本批量巡检，脚本在服务器侧跑，让交换机被动提供文件，也能省掉在每台设备上写客户端命令的麻烦。

所以我在动手之前会先问自己三个问题：文件在谁那边、谁发起连接、网络里有没有现成的文件服务。答案清楚了，配置路径自然就定了。下面所有内容都按这个分岔来展开，你对照自己的场景挑一段看就行，不用全盘照抄。

1.2 FTP、TFTP、SFTP三者怎么选，别一上来就FTP

选型这件事值得单独说，因为选错了后面全是返工。TFTP最轻，UDP 69端口，交换机命令行里一条tftp 192.168.1.100 get xxx.cc就完事，不用登录、不用密码，也不需要服务端做用户管理。它的短板是传输不可靠，大文件（尤其是几十兆的系统软件包）容易传一半失败，而且没有任何认证，谁都能拿。配置备份这种几KB到几百KB的小文件，TFTP其实非常好用，我个人的习惯是日常备份走TFTP，版本升级这种大文件才上FTP。

FTP基于TCP，有认证、能续传、支持目录浏览和多个文件批量操作，适合传系统软件包和多份配置。代价是明文——用户名、密码、文件内容在链路上全是裸的。内网隔离环境里问题不大，跨区域或者带外管理网暴露面较大的场景就要掂量。SFTP走SSH的22端口，加密传输，安全性最好，华为设备同样支持sftp客户端命令，但服务端配置比FTP麻烦一点，而且部分老版本VRP对SFTP客户端支持有限。我的取舍原则很直白：临时小文件用TFTP，大文件内网用FTP，跨网段或者合规要求高的用SFTP。不是为了省事就一律FTP，也不是为了安全就把自己绕死在SFTP的密钥配置里。

方式	端口/协议	认证	大文件可靠性	典型用途
TFTP	69/UDP	无	一般	配置备份、小镜像
FTP	21/TCP + 数据端口	用户名密码（明文）	好	系统软件、批量配置
SFTP	22/TCP（SSH）	用户名密码或密钥	好	跨网段、合规场景

2. 设备作为FTP客户端：备份与升级最常走的路

2.1 动手前的连通性与前置条件确认

这一步最容易被跳过，也最容易出问题。交换机能ping通FTP服务器，不代表FTP就能登上去，但ping不通就一定登不上去——所以先ping。命令很简单，ping 192.168.1.100，重点看丢包率和时延。如果服务器和交换机不在同一网段，还要确认交换机上有到该网段的路由，display ip routing-table看一眼有没有默认路由或者明细路由。带外管理口（MEth）和业务口是两套转发平面，从管理口发起的流量需要单独确认管理口IP和网关配置，别拿业务口的连通性去推断管理口。

第二个要确认的是源地址。交换机可能有多个三层接口，去往FTP服务器的报文从哪个接口出去，服务器侧看到的源IP就是哪个。如果服务器上有访问控制或者你在做地址绑定，源IP不对就会直接被拒。稳妥做法是显式指定源接口，命令是ftp client source-interface Vlanif10，这样不管路由怎么选，源地址都是确定的。我吃过这个亏：一台设备上配了管理VLAN和业务VLAN两个地址，FTP服务器只放行了管理段，结果报文从业务接口出去，登录一直超时，排查了半小时才发现是源地址问题。

第三个是服务器侧的准备。FTP服务是否启动、监听端口是不是默认21、账号是否有目标目录的读写权限、被动模式的数据端口范围有没有在防火墙上放行。这几点里最隐蔽的是被动模式：FTP协议的控制连接和数据连接是分开的，被动模式下服务器会临时开一个高位端口给客户端连，如果中间有防火墙只放行了21端口，表现就是"能登录、能列目录、一传文件就卡死"。这个现象后面排查章节还会细说。

2.2 客户端登录与文件传输的完整命令实录

连通性没问题就可以登了。华为VRP下的客户端命令很直观，登录、取文件、送文件、退出四步走：

<HUAWEI> ftp 192.168.1.100 Trying 192.168.1.100 ... Press CTRL+K to abort Connected to 192.168.1.100. 220 FTP service ready. User(192.168.1.100:(none)):netadmin 331 Password required for netadmin. Enter password: 230 Logged on. [ftp]

登录成功后提示符会从<HUAWEI>变成[ftp]，这个细节很关键——很多人敲dir发现列出来的不是本地flash而是服务器目录，就是因为还在ftp视图里。想确认当前视角，pwd看服务器当前目录，!dir（感叹号前缀）才是执行本地命令。华为这套设计里，ftp视图下不带前缀的命令都作用于远端服务器，带!的才落到本地，这一点和Linux的lftp有点像，习惯之后很顺手。

取文件和送文件分别是get和put：

[ftp] get vrpcfg.zip [ftp] put vrpcfg.zip [ftp] bye

get是把服务器上的文件拉到本地flash当前目录，put是把本地文件推上去。文件默认落在flash根目录，如果本地已有同名文件，行为取决于版本，有的会直接覆盖，有的会提示确认，所以传之前先用!dir看一眼本地有没有同名文件，避免把刚改好的配置盖掉。传输完成一定要bye退出，别直接关会话——某些版本下不退出会导致会话残留，下次登录提示用户数超限。

批量操作可以用mget和mput，配合通配符，比如mget *.zip。但我不太推荐在生产设备上用通配符批量拉取，一是不确定远端目录里有什么，二是文件名匹配到意外文件会占用宝贵的flash空间，盒式交换机的flash通常只有几百兆，塞满了连save都会失败。

2.3 配置文件与系统软件传输的关键差异

这两类文件的处理逻辑完全不同，混着讲容易出事。配置文件（vrpcfg.zip）通常几十到几百KB，传输快，风险主要在"覆盖"——把设备当前的配置备份出去，或者把备份的配置拉回来覆盖当前配置，后者属于变更操作，必须提前save一份现网配置兜底，并且确认拉回来的配置和当前软件版本匹配。跨大版本导入配置是很常见的翻车点，老版本的配置里有新版本已废弃的命令，导入后设备可能直接进入异常状态。

系统软件（.cc结尾的镜像文件）通常几十兆，传输时间长，风险在"空间"和"校验"。传之前用dir确认flash剩余空间至少是文件大小的两倍——设备升级时往往需要新旧两个镜像共存，空间不够会传一半报错。传完必须做校验，比对文件大小是最基本的，严谨一点用display system-software information或者看文件属性里的CRC。我见过镜像传输中途丢包导致文件大小对了但内容损坏，设备重启后起不来，只能现场救砖，代价极大。

传完之后指定下次启动文件：

<HUAWEI> startup system-software flash:/newversion.cc <HUAWEI> display startup

display startup会列出当前启动文件和下次启动文件，确认下次启动那一栏已经改成新文件，再reboot。重启前务必再save一次并且确认配置已保存，否则升级完发现配置丢了，白干。

注意：升级操作请在业务窗口期进行，并且提前准备好回退方案——旧镜像不要急着删，留在flash里，新版本有问题可以改回启动文件快速回退。

3. 设备作为FTP服务端：让外部来取文件

3.1 服务使能与本地用户配置的完整链路

这条路径的核心是AAA。华为设备的登录认证统一走AAA模块，FTP用户本质上就是一个绑定了ftp服务类型的本地用户。配置顺序建议是：先建用户、再授权限和目录、最后开服务。反过来先开服务再建用户，中间那段时间设备处于"服务开着但没人能登"的状态，虽然危害不大，但没必要。

<HUAWEI> system-view [~HUAWEI] aaa [~HUAWEI-aaa] local-user ftpoper password irreversible-cipher FtP@2024#ops [~HUAWEI-aaa] local-user ftpoper service-type ftp [~HUAWEI-aaa] local-user ftpoper privilege level 15 [~HUAWEI-aaa] local-user ftpoper ftp-directory flash: [~HUAWEI-aaa] quit [~HUAWEI] ftp server enable

service-type ftp这一行决定了这个账号能不能用于FTP，漏了它，密码再对也是530。privilege level是权限级别，0到15，配置文件下载、目录切换这类操作需要足够高的级别，实际配下来level 15最省事，只读场景可以给低一些但要看具体版本对命令级别的划分。ftp-directory是登录后的根目录，写flash:表示用户看到的就是设备flash，也可以指向子目录。这行的意义在于限制用户的视野，配合权限可以做出"只能看某个目录"的效果。

密码这里用irreversible-cipher是较新版本的推荐写法，存的是不可逆密文。老版本可能只支持cipher，命令敲下去报错就换一种写法，别死磕。密码强度要够，华为对本地用户密码有复杂度校验，纯数字或者太短会直接被拒，报错信息里会提示策略要求，照着改就行。

3.2 目录权限与用户级别的对应关系

很多人配完发现能登录、能dir，但get配置文件失败，报权限错误。问题基本都出在级别和目录这两处。目录权限上，ftp-directory必须指向真实存在的路径，写flash:/backup但设备上没这个目录，登录后pwd会失败或者跳到一个不可写的位置，上传就失败。传文件前先在设备上mkdir flash:/backup建好目录，这是最稳的做法。

用户级别的影响更微妙。低级别用户可以登录、可以浏览，但涉及文件写入、删除、目录切换的命令会被拒。有些版本里put需要level 3以上，delete需要更高。与其去背版本差异，不如按用途分账号：只读备份账号给较低级别，只允许get；运维账号给level 15，允许上传下载。这样即使密码泄露，损失范围也可控。我一般会建两个账号，一个ftpbackup只读，一个ftpadmin读写，日常自动化脚本用只读的。

还有一点常被忽略：本地用户默认可能是ftp-directory指向flash根目录，用户能看到所有文件，包括系统镜像。这本身不算漏洞，但如果账号权限给到15，对方就能删镜像。所以"高权限 + 根目录"这个组合只在完全可信的内网里用，稍有外部暴露风险就必须收窄目录。

3.3 用ACL把访问范围收到最小

FTP服务开起来就是21端口对着整个可达网络敞开，等于把登录界面暴露给所有能路由到设备管理地址的人。即便密码够强，日志里也会被扫描器刷满，而且明文协议本身经不起抓包。最有效的收紧手段是用ACL限定源地址：

[~HUAWEI] acl 2000 [~HUAWEI-acl4-basic-2000] rule 5 permit source 192.168.10.50 0 [~HUAWEI-acl4-basic-2000] rule 10 permit source 192.168.10.0 0.0.0.255 [~HUAWEI-acl4-basic-2000] quit [~HUAWEI] ftp server acl 2000

ftp server acl把ACL绑定到FTP服务上，只有匹配permit规则的源地址能建立连接，其余一律丢弃。注意ACL末尾默认隐含deny，所以只写permit就够了，不需要额外写拒绝规则。规则顺序按精确到宽泛排列，单主机规则放前面，网段放后面，虽然基础ACL匹配是按序的，但养成这个习惯在复杂策略里能少踩坑。

ACL生效后要做验证，从允许的地址登一次，从不允许的地址试一次，两边都符合预期才算配完。只验证允许侧是不够的，很可能ACL压根没绑上，你以为收紧了其实全放开。

提示：如果设备同时开启了Telnet或HTTP管理，FTP的ACL不会覆盖它们，各服务的访问控制要分别配置。别以为绑了一个ACL就万事大吉。

4. 传输过程中的参数细节与文件系统认知

4.1 存储介质、文件系统与空间管理

华为交换机的存储介质按形态分几类：盒式设备多是flash，插卡式或者框式可能有cfcard、sd卡、usb。命令里的路径前缀就是flash:、cfcard:、sd:。不同介质的容量差别很大，盒式机flash常见几百兆，框式主控的cfcard能到几个G。传文件前用dir看清楚目标介质的剩余空间，别想当然认为空间够。

空间管理有个坑：设备上删除文件用delete，但默认行为可能只是打个删除标记，空间不一定立刻释放。有些版本需要用delete /unreserved才真正删除。我遇到过flash显示空间不足、dir看文件也不多，最后发现是一堆已标记删除但未释放的历史镜像。这种情况用reset recycle-bin清空回收站能立刻回收空间。这个命令有风险，执行前确认回收站里没有还需要的东西。

还有文件名长度和字符限制。设备对文件名长度有上限，太长的名字传上去会被截断或者直接失败；文件名里带空格、中文、特殊符号也可能出问题。我的习惯是全部用短横线加数字，比如cfg-20240612.zip，纯英文数字加短横线，从来没出过问题。

4.2 传输模式binary与ascii的取舍

FTP客户端一般有二进制和ASCII两种传输模式，华为设备的FTP客户端默认行为在多数版本下是二进制，但如果你用PC上的FTP客户端连设备，或者用某些脚本库，就要显式设置。区别在于ASCII模式会做换行符转换，把Unix的LF转成Windows的CRLF。对文本文件（比如导出的配置）来说，转换后文件大小会变，某些场景下会导致校验失败；对压缩包、镜像这类二进制文件，ASCII模式传输会直接破坏文件内容。

结论很明确：传zip、cc、bin一律用二进制模式。传纯文本日志时也不建议用ASCII，因为设备侧的文件通常以LF结尾，转换成CRLF后再传回设备可能引发格式问题。宁可全程二进制，一致性最好。用命令行FTP客户端时，登录后先敲binary再传，这个动作只需要一秒，能省掉后面一堆"文件大小对不上"的疑问。

4.3 会话超时与并发连接的处理

设备侧对FTP会话有空闲超时机制，长时间不操作会自动断开。传大文件时如果链路慢，一次传输耗时可能超过超时时间，但正在传输的会话通常不会被踢，被踢的是"登着不动"的会话。真正麻烦的是并发连接数限制：设备作为服务端时能同时接入的FTP会话数是有限的，如果前面的会话没有正常bye，残留会话会占用名额，后来的人就登不上，报"too many users"之类的错误。

处理办法有两个。一是养成bye的习惯，别直接关窗口。二是定期查看和清理会话，华为设备上有查看用户连接的命令（不同版本命令名有差异，一般在display users或display ftp-server这类命令下），发现残留会话可以强制断开。我倾向于把FTP服务端的超时时间调短一点，比如空闲几分钟就断，虽然操作时要注意别停太久，但能有效防止会话堆积。

5. 常见问题与排查技巧实录

5.1 登录阶段失败的三类原因速查

登录失败是最常见的，现象通常是卡在"Trying..."或者提示530。按我的排查顺序，先分三层：网络层、服务层、认证层。

网络层看ping和路由，ping不通就是地址、掩码、VLAN、路由的问题，跟FTP配置一点关系没有，别在这上面改AAA。ping通但21端口连不上，用telnet 192.168.1.100 21测端口，通不了说明服务没起或者中间被拦。服务层看设备侧display ftp-server（或对应版本命令）确认服务已使能，PC侧确认FTP服务在跑、防火墙放行了21端口。认证层就是530，逐项核对：service-type里有没有ftp、密码对不对、账号有没有被锁、级别够不够、ftp-directory路径存不存在。

现象	大概率原因	处理方向
Trying 后超时	路由不通/端口被拦/服务未起	先ping，再测21端口
530 Login incorrect	账号无ftp服务类型/密码错	查service-type，重设密码
530 Not logged in, access denied	ACL未放行源地址	查ftp server acl与规则
登录成功但dir失败	ftp-directory路径不存在	设备上先建目录
能登录不能上传	用户级别不足/目录只读	提升privilege level

这里补一个容易误判的点：账号密码里带特殊字符时，某些FTP客户端会做转义处理，导致实际发出的密码被改变。密码里如果必须有@、#、$这类字符，换一个客户端或者改用命令行测试，能快速定位是不是客户端的问题。

5.2 传输中断、卡死与文件损坏的排查路径

现象一：能登录、能列目录，一传文件就卡在"150 Opening data connection"然后超时。这是典型的被动模式数据端口不通。FTP的控制连接走21，数据连接另开端口，主动模式下是服务器连客户端，被动模式下是客户端连服务器的高位端口。中间有防火墙或NAT时，被动模式最容易出问题。解决办法是在客户端侧切换主被动模式，或者让防火墙放行服务器的被动端口范围。设备作为客户端时，如果服务器在NAT后面，同样会遇到这个问题，这时候换TFTP往往比死磕FTP更快。

现象二：传到一半断了，重连后文件不完整。先看链路质量，长距离或者跨广域网的传输本来就容易中断，能续传的客户端用续传，不能续传的分卷传。再看flash空间，空间不足时传输会在写入阶段失败，报错信息不一定直白。最后看文件大小是否超过单文件限制，老设备的文件系统对大文件支持有限。

现象三：传完文件大小对得上，但设备不认。镜像文件要校验，配置文件的格式要对。配置文件本质是个压缩包，别用文本编辑器打开再保存，那样会破坏格式。曾经有人为了改一行配置，把vrpcfg.zip解压改了再压回去，压缩算法和目录结构一变，设备直接拒绝加载。改配置就在设备上改，或者用文本配置导入，别动二进制文件。

5.3 我自己的排查顺序清单

踩过的坑多了，慢慢形成一套固定顺序，遇到问题按这个走，基本不会绕远路。第一步永远是最小化验证：换一台PC、换一根线、换一个网段，先把"是不是环境问题"排除掉。第二步看设备侧的服务状态和日志，很多失败在日志里都有记录，比猜快得多。第三步对比配置，找一台能正常工作的设备，把两份配置导出来diff，差异点往往就是问题点。第四步才是查文档和版本说明，因为版本差异导致的命令行为变化，只有文档能说清。

还有一个经验：把每次故障的现象、原因、处理动作记下来，形成一个自己的问题库。FTP这类基础功能的问题高度重复，第二次遇到同类现象时，翻记录比翻文档快十倍。

6. 安全边界与长期运维习惯

6.1 FTP本身的短板必须用外围手段补

FTP是明文协议，这一点不因为设备是华为还是别的品牌而改变。用户名、密码、文件内容在链路上都是可读的，抓包工具一开就全看见。所以我的原则是：FTP只在管理网内用，管理网本身用VLAN隔离，不承载业务流量；账号密码定期更换，且不与设备登录密码复用；服务端配置ACL白名单，只允许固定的运维终端访问；用完就关服务，undo ftp server enable这条命令应该成为操作习惯的一部分，而不是一直开着图方便。

另外要明确一点，FTP用户和设备的命令行登录用户是两套权限体系，但可以共用账号。如果图省事让FTP账号同时具备Telnet或SSH登录能力，等于把命令行入口也暴露了。正确做法是FTP账号只绑service-type ftp，需要命令行登录的另外建账号绑service-type ssh，各走各的通道。

6.2 把备份做成例行动作而不是临时救火

配置备份这件事，最怕的是"想起来才做"。我见过太多场景是设备出问题要恢复了，才发现上一次备份是半年前。比较务实的做法是固定节奏：变更前必备份、变更后必备份、每月定期备份一次。备份文件按"设备名-日期-版本"命名，统一存放在一个目录里，保留最近若干份，太老的清理掉。

如果设备数量可观，手工一台台传不现实，可以考虑在网管侧跑脚本批量拉取。思路是脚本通过SSH登录设备执行save，再用FTP或TFTP把配置文件取回本地归档。这里要注意，脚本的账号权限、并发数、失败重试都要设计好，不然一次批量操作可能把设备的管理会话占满。规模再大一些的场景，用专门的配置管理平台去做，比自研脚本更省心。