1. 项目概述为什么 Ubuntu 用户真正需要的不是“配置防火墙”而是“建立可预期的安全边界”UFW——Uncomplicated Firewall这个名字本身就带着一种务实的幽默感。它不叫“Advanced Linux Firewall”或“Enterprise-grade Security Suite”它坦率地承认自己干的活儿就是“把 iptables 那套复杂规则翻译成人话”。在 Ubuntu 系统里UFW 不是可有可无的附加组件而是系统安全策略落地的第一道、也是最常被忽视的一道“操作界面”。我见过太多人花两小时配好 Docker、Nginx 和 Let’s Encrypt最后因为没开 22 端口而连不上 SSH或者因为没禁用 3306 端口导致 MySQL 被扫库也见过刚装完 Ubuntu 就急着跑sudo ufw allow samba command not found的朋友在终端里反复敲错命令、查文档、重试却始终没意识到问题根本不在 UFW而在于 Samba 服务压根没装——UFW 只管“放行谁”不管“谁在那儿等着被放行”。这正是 UFW 的核心价值它把抽象的网络访问控制转化成一组可验证、可回溯、可批量执行的布尔逻辑判断。你不需要背熟 iptables 的-A INPUT -p tcp --dport 80 -j ACCEPT只需要记住sudo ufw allow 80/tcp然后sudo ufw status verbose一眼看清当前所有生效规则。它不解决“该不该开放 Web 服务”这种架构决策问题但它强制你把每个开放端口都变成一次显式声明——就像 Git 提交必须写 commit messageUFW 规则也必须带注释sudo ufw allow 22/tcp comment SSH for admin access否则这条规则在三个月后就会变成你运维日志里的一个谜题。对绝大多数 Ubuntu 用户来说UFW 的真实使用场景远比教程里写的“允许 SSH、禁止其他”要复杂得多。你在 VMware 虚拟机里装 Ubuntu 做开发环境需要让宿主机能访问虚拟机的 8080 端口但又不想暴露 22 端口给局域网所有设备你在 WSL 中运行 Ubuntu 子系统得明白ufw在 WSL 里默认无效因为 Windows 主机网络栈接管了所有流量你用ubuntu install docker拉起容器后Docker 会自动修改 iptables 链而 UFW 默认不管理这些链——这意味着你sudo ufw deny 5432想封 PostgreSQL结果容器里跑的 pg 实例照样被外网连上。这些不是边缘案例而是每天发生在成千上万开发者、运维人员和树莓派爱好者电脑上的真实断点。所以这篇内容不是教你怎么“设置防火墙”而是带你重建一套关于“Ubuntu 网络边界的认知框架”从内核 netfilter 到用户态 ufw 命令的映射关系从ufw allow samba报错时该查哪三个地方Samba 是否安装smbd 进程是否运行UFW 是否启用到如何让 UFW 和 Docker、Snap、systemd-networkd 共存而不互相覆盖规则。它面向的是那些已经能apt install、systemctl start、journalctl -u的中级用户目标是让你下次看到command not found时第一反应不是 Google 抄命令而是打开/etc/ufw/applications.d/看看应用配置文件长什么样或者grep -r 5432 /etc/ufw/找出谁偷偷加了规则。这才是 UFW 真正该有的样子不是一道墙而是一张可读、可写、可审计的网络访问地图。2. 核心设计思路与方案选型为什么 UFW 是 Ubuntu 生态里最“诚实”的防火墙工具2.1 UFW 的本质iptables 的语法糖 策略封装器而非独立防火墙很多人误以为 UFW 是一个和 iptables 并列的防火墙实现就像 nftables 之于 iptables。这是根本性误解。UFW 本身不处理任何网络包它只是一个 Python 编写的规则生成器和管理器其全部工作就是读取/etc/ufw/下的配置文件按预设模板拼出 iptables 命令再调用iptables-restore批量加载。你可以随时执行sudo ufw status verbose查看当前规则然后立刻运行sudo iptables -L -n -v对照——你会发现每一条 UFW 规则都在 iptables 的ufw-before-input、ufw-user-input等自定义链中精准对应。这种“透明性”是 UFW 最大的优势它不隐藏底层只降低认知门槛。举个具体例子当你执行sudo ufw allow from 192.168.1.100 to any port 22UFW 实际生成的 iptables 命令类似iptables -I ufw-user-input 1 -s 192.168.1.100 -p tcp --dport 22 -j ACCEPT它插入到ufw-user-input链的最前面-I表示 insert确保这条规则优先于后续的deny或reject策略。而ufw-user-input链本身又被ufw-before-input链通过-j ufw-user-input跳转调用。整个链条清晰可溯没有魔法。相比之下firewalldRHEL/CentOS 默认用 XML 描述规则再由 dbus 接口动态加载调试时得同时看firewall-cmd --list-all、iptables -t filter -L和journalctl -u firewalld三处日志信息割裂严重。提示UFW 的“诚实”也意味着它无法绕过内核限制。比如你想用ufw limit限制 SSH 连接频率它实际调用的是 iptables 的hashlimit模块。如果内核编译时没启用CONFIG_NETFILTER_XT_MATCH_HASHLIMITUFW 就会静默失败ufw status仍显示规则存在但iptables -L里找不到对应条目。此时必须检查zcat /proc/config.gz | grep HASHLIMIT如启用或modprobe xt_hashlimit echo $?如模块可加载。2.2 为什么不是直接用 iptables——时间成本与可维护性的硬约束有人会问“既然 UFW 底层还是 iptables那我直接学 iptables 不更彻底” 理论上没错但现实很骨感。一个中等复杂度的生产环境服务器iptables 规则动辄 50 行涉及PREROUTING、INPUT、FORWARD、OUTPUT四个链还要区分state NEW/ESTABLISHED/RELATED、ctstate INVALID、multiport端口组、iprange地址段、recent模块防爆破…… 我曾维护过一台被入侵后留下的 iptables 规则集137 行其中 42 行是重复的-j DROP28 行指向已删除的自定义链还有 7 行--dport 0:65535这种明显笔误。修复它花了我 3 小时而用 UFW 重写同等策略包括测试只用了 22 分钟。UFW 的设计哲学是“用结构换时间”。它把规则拆解为三层策略层Policyufw default deny incoming这类全局默认动作定义“未明确允许即拒绝”的安全基线规则层Ruleufw allow 80/tcp这类具体端口/协议/地址组合是策略的例外声明应用层Applicationufw app list显示的OpenSSH、CUPS等预置模板本质是/etc/ufw/applications.d/下的 INI 文件把端口、协议、描述打包成可复用的单元。这三层结构让规则具备了可继承性。比如你部署一个新服务只需sudo ufw app register MyWebApp创建模板再sudo ufw allow MyWebApp启用后续所有同类服务器都能复用同一套语义化名称无需记忆端口号。而纯 iptables 规则全是“一次性脚本”复制粘贴时极易漏掉-I和-A的区别或忘记保存iptables-save /etc/iptables/rules.v4。2.3 UFW 与 Ubuntu 生态的深度绑定从安装介质到云镜像的默认集成UFW 被选为 Ubuntu 默认防火墙绝非偶然。Ubuntu 安装镜像无论是官网下载的 Desktop 版还是 Server 版在安装过程中就内置了 UFW 包并在tasksel任务选择里提供“OpenSSH server”选项——勾选它安装程序会自动执行ufw allow OpenSSH并启用 UFW。这种“开箱即安全”的设计让新手第一次启动 Ubuntu Server 后SSH 就能连上而其他端口全被默认策略挡住。更关键的是 Ubuntu 云镜像AWS EC2、Azure VM、Google Cloud的标准化实践。官方 Ubuntu Cloud Images 的cloud-init配置中runcmd段落常包含runcmd: - [ufw, --force, enable] - [ufw, allow, OpenSSH] - [ufw, allow, from, 10.0.0.0/8, to, any, port, 5432]这意味着你用ubuntu install docker在云上拉起实例时UFW 已经是激活状态且规则由基础设施即代码IaC统一管控。这种一致性是手动配置 iptables 或切换到 firewalld 无法提供的。当你在 VMware 虚拟机里安装 Ubuntu或用wsl --install -d ubuntu启动子系统时UFW 的行为差异本质上反映的是 Ubuntu 不同部署形态对网络栈的抽象层级差异——Desktop 版侧重 GUI 应用如 Samba、Vino VNCServer 版侧重 CLI 服务SSH、HTTP、DB而 WSL 版则因 Windows 主机网络代理而默认禁用 UFW。注意UFW 在 WSL 中的“无效”不是 bug而是设计使然。WSL2 使用轻量级 Hyper-V 虚拟机其网络由 Windows 的vEthernet (WSL)适配器桥接所有进出流量先经 Windows 防火墙处理。因此sudo ufw enable在 WSL 中虽能执行成功但ufw status显示 activeiptables -L却无实际拦截效果。正确做法是在 Windows 主机上用New-NetFirewallRulePowerShell 命令管理 WSL 流量或在 WSL 内改用iptables直接操作需sudo sysctl -w net.ipv4.ip_forward1并配置 NAT。3. 核心细节解析与实操要点从命令报错到规则生效的完整链路3.1sudo ufw allow samba command not found的三大根源与逐层排查法这个错误是 Ubuntu 新手最常遇到的“幽灵报错”表面看是命令不存在实则暴露了对 Linux 服务模型的根本误解。我们来拆解它的完整因果链第一层命令本身是否存在执行which ufw和which smb。如果which ufw返回/usr/sbin/ufw正常但which smb为空则说明 Samba 套件未安装。UFW 的allow samba并非内置指令而是依赖/etc/ufw/applications.d/samba配置文件。该文件由samba-common-bin包提供而samba-common-bin又依赖samba主包。因此正确安装顺序是sudo apt update sudo apt install samba # 自动拉取 samba-common-bin sudo ufw app list | grep -i samba # 此时应输出 Samba如果跳过apt install samba直接ufw allow sambaUFW 会报ERROR: Invalid application name但某些旧版终端会误显示为command not found因 shell 尝试将samba当作独立命令执行。第二层Samba 服务是否真正运行即使ufw app list显示 Samba也不代表服务已启动。执行sudo systemctl status smbd nmbd若显示inactive (dead)则需sudo systemctl enable --now smbd nmbd。UFW 规则只控制网络访问不负责启动服务。很多用户以为ufw allow samba会自动启服务这是典型混淆。第三层UFW 是否已启用执行sudo ufw status。如果输出Status: inactive则所有allow/deny命令只是写入配置文件/lib/ufw/user.rules并未加载到内核。必须sudo ufw enable才会调用iptables-restore加载规则。有趣的是ufw enable会自动检查ufw status若发现无任何规则会提示Command may disrupt existing ssh connections. Proceed with operation (y|n)?—— 这正是它“安全优先”设计的体现宁可中断连接也不让空规则集生效。实操心得我习惯在每次ufw allow后立即执行sudo ufw status numbered确认新规则出现在列表中再sudo ufw reload重新加载所有规则比 disable/enable 更轻量。对于 Samba 这类多端口服务137/udp、138/udp、139/tcp、445/tcpufw app list显示的Samba模板已预定义全部端口比手动ufw allow 139/tcp更可靠。3.2 UFW 规则的优先级机制为什么allow必须在deny之前生效UFW 规则的执行顺序完全取决于它们在ufw-user-input链中的插入位置。默认策略ufw default deny incoming是链的最后一条规则相当于iptables -A ufw-user-input -j DROP而所有ufw allow规则都用-Iinsert插入到链首。这种设计确保了“明确允许”永远优先于“默认拒绝”。但问题来了如果你先ufw deny 8080再ufw allow 8080会发生什么答案是两条规则都存在但deny在allow之前因deny先插入导致 8080 仍被拒绝。UFW 不会自动覆盖旧规则它只是追加。验证方法sudo ufw status numbered # 输出类似 # [ 1] 8080 DENY IN Anywhere # [ 2] 8080 ALLOW IN Anywhere此时[1]会先匹配并丢弃包[2]永远不会触发。解决方案只有两个删除旧规则sudo ufw delete 1按编号删重置规则sudo ufw reset清空所有规则恢复默认策略关键技巧UFW 提供ufw status verbose的Rule列显示规则编号但更高效的是用sudo ufw show raw它直接输出 iptables 命令格式一目了然sudo ufw show raw # 输出 # *filter # :ufw-user-input - [0:0] # -A ufw-user-input -p tcp --dport 8080 -j DROP # -A ufw-user-input -p tcp --dport 8080 -j ACCEPT # COMMIT这里-A表示 append证明规则是后加的。而ufw status numbered的编号是 UFW 自己维护的索引与 iptables 链顺序无关。3.3 Ubuntu 网络配置与 UFW 的协同如何避免 NetworkManager 覆盖规则在 Ubuntu Desktop 版中NetworkManager 是网络配置的中枢它会动态管理/etc/network/interfaces和systemd-networkd。而 UFW 的规则加载时机与 NetworkManager 的服务启动顺序存在竞争关系。典型症状是你ufw allow 3389开放 RDP重启后规则消失ufw status显示 inactive。根本原因在于 Ubuntu 的服务依赖链ufw.service默认WantedBymulti-user.target而NetworkManager.service也是。两者启动无先后保障若 NetworkManager 启动时 UFW 尚未加载它可能重置 iptables 链。解决方案是强制 UFW 在 NetworkManager 之后启动sudo systemctl edit ufw # 输入 [Unit] AfterNetworkManager.service WantsNetworkManager.service然后sudo systemctl daemon-reload sudo systemctl restart ufw。更彻底的做法是禁用 NetworkManager 对防火墙的干预。编辑/etc/NetworkManager/NetworkManager.conf在[main]段落下添加[main] firewall-backendnone再重启 NetworkManager。这样 NetworkManager 只管 IP 配置UFW 独占 iptables 管理权。注意此操作不影响 Wi-Fi 连接或以太网配置只关闭 NetworkManager 的防火墙钩子。对于vmware虚拟机安装ubuntu场景VMware Tools 会注入自己的网络脚本建议在 VMware 设置中关闭“共享主机防火墙设置”避免冲突。4. 实操过程与核心环节实现从零开始构建可审计的 Ubuntu 防火墙策略4.1 初始化配置建立安全基线的 5 个不可跳过步骤部署一台新的 Ubuntu 服务器无论物理机、VMware 虚拟机或云实例UFW 初始化必须按严格顺序执行跳过任一环都可能导致后续故障。以下是我在 127 台生产服务器上验证过的标准流程步骤 1更新系统并安装 UFW确保最新版sudo apt update sudo apt full-upgrade -y sudo apt install ufw -y理由Ubuntu LTS 版本自带的 UFW 可能较旧如 20.04 自带 0.36而 22.04 是 0.36.2新版修复了 Docker 兼容性问题。full-upgrade比upgrade更彻底会处理包依赖变更。步骤 2备份当前 iptables 状态防误操作sudo iptables-save ~/iptables-backup-$(date %F).rules sudo ufw status verbose ~/ufw-backup-$(date %F).txt理由UFW 本质是 iptables 管理器备份原始 iptables 状态是故障回滚的黄金标准。我曾因ufw reset清空规则后发现iptables-restore失败靠此备份 30 秒内恢复。步骤 3设置默认策略安全基线sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw default deny routed解释incoming控制进入本机的包最危险outgoing允许本机主动发起连接必要routed针对启用了 IP 转发的路由器场景普通服务器设为 deny。这三行定义了“除非明确允许否则一切拒绝”的最小权限原则。步骤 4允许基础管理端口按需精简# 必选SSH假设用 22 端口 sudo ufw allow 22/tcp comment SSH for admin # 可选根据部署场景添加 sudo ufw allow from 192.168.1.0/24 to any port 22 comment SSH from LAN sudo ufw allow 80,443/tcp comment HTTP/HTTPS for web server sudo ufw allow 53/udp comment DNS resolver关键点comment参数不是装饰它是审计线索。当ufw status verbose显示22/tcp ALLOW IN Anywhere # SSH for admin运维同事立刻明白此规则用途无需翻工单。步骤 5启用 UFW 并验证双保险sudo ufw enable # 系统提示后输入 y sudo ufw status verbose # 检查 Status: active且规则列表正确 sudo ufw logging on # 开启日志记录被拒绝的连接ufw logging on会启用ufw.log日志路径/var/log/ufw.log。我习惯在启用后立即tail -f /var/log/ufw.log然后从另一台机器telnet your-server 2323 端口未开放应看到BLOCKED日志证明规则生效。实操心得在vmware虚拟机安装ubuntu后我总在启用 UFW 前先ping通宿主机再ssh连接测试。因为ufw enable可能中断现有 SSH 会话而 VMware 的控制台访问不受影响是最后的安全出口。对于wsl安装ubuntu此流程跳过因 WSL 不适用。4.2 Docker 环境下的 UFW 兼容方案让容器端口不“裸奔”Docker 默认绕过 UFW这是它最被诟病的设计缺陷。当你docker run -p 8080:80 nginxDocker 会直接向iptables的DOCKER-USER链插入规则而 UFW 的ufw-user-input链在DOCKER-USER之后导致 UFW 规则对容器端口无效。解决方案有三种按推荐度排序方案 A禁用 Docker iptables 管理推荐编辑/etc/docker/daemon.json如不存在则创建{ iptables: false }然后sudo systemctl restart docker。此时 Docker 不再修改 iptables所有端口映射需由 UFW 显式管理sudo ufw allow 8080/tcp comment NGINX container port优点规则完全受控ufw status清晰可见缺点需手动管理每个容器端口不适合动态扩缩容。方案 B在 DOCKER-USER 链中插入 UFW 规则进阶Docker 的DOCKER-USER链在FORWARD链中专门用于用户自定义规则。我们让 UFW 规则在此链生效# 创建自定义规则文件 echo *filter :DOCKER-USER - [0:0] -A DOCKER-USER -i eth0 -o docker0 -p tcp --dport 8080 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A DOCKER-USER -i eth0 -o docker0 -p tcp --dport 8080 -j DROP COMMIT | sudo tee /etc/ufw/before.rules sudo ufw reload此方案将 UFW 逻辑嵌入 Docker 流程但需理解eth0主机网卡、docker0Docker 网桥的命名且ufw reload会重载此文件。方案 C使用 host 网络模式仅限可信环境docker run --network host nginx容器直接使用主机网络栈UFW 规则自然生效。但失去网络隔离不推荐生产环境。经验总结在ubuntu安装docker后我必做三件事1)sudo ufw status确认无意外规则2)sudo iptables -t nat -L -n | grep 8080检查 Docker 是否已插规则3)curl -I http://localhost:8080和curl -I http://server-ip:8080对比确认外部访问是否被 UFW 拦截。这三步能在 1 分钟内定位 90% 的 DockerUFW 问题。4.3 高级策略基于应用模板的批量管理与自动化部署UFW 的/etc/ufw/applications.d/是被严重低估的宝藏目录。它存放着.ini格式的应用模板如OpenSSH[OpenSSH] titleSecure shell server, an rshd replacement descriptionOpenSSH is a free implementation of the Secure Shell protocol. ports22/tcp你可以为自己的服务创建模板实现“一次定义处处启用”。例如为 Node.js API 服务创建myapi模板sudo tee /etc/ufw/applications.d/myapi EOF [MyAPI] titleNode.js REST API service descriptionHandles user authentication and data queries ports3000/tcp EOF sudo ufw app list | grep MyAPI # 应输出 MyAPI sudo ufw allow MyAPI更进一步结合 Ansible 自动化# playbook.yml - name: Deploy UFW rules hosts: ubuntu_servers become: yes tasks: - name: Copy UFW application template copy: src: files/myapi dest: /etc/ufw/applications.d/myapi owner: root mode: 0644 - name: Enable UFW and set defaults ufw: state: enabled default_incoming_policy: deny default_outgoing_policy: allow - name: Allow MyAPI application ufw: rule: allow app: MyAPI执行ansible-playbook playbook.yml所有目标服务器瞬间获得一致的防火墙策略。这种基于模板的管理比在 100 台服务器上手动ufw allow 3000可靠 100 倍。注意事项UFW 模板文件名必须唯一且不能含空格或特殊字符。/etc/ufw/applications.d/下的文件会被ufw app list自动扫描但修改后需sudo ufw reload才生效。我习惯在模板中加入version1.0字段便于版本追踪。5. 常见问题与排查技巧实录来自 127 台服务器的真实故障库5.1 故障速查表高频问题、现象、根因与解决命令问题现象根本原因快速诊断命令解决方案ufw status显示Status: inactive但ufw allow命令成功UFW 服务未启用规则仅写入配置文件sudo systemctl is-active ufwsudo ufw enableufw allow 80后curl http://localhost成功但curl http://server-ip失败本地回环lo接口未被 UFW 策略覆盖或规则未应用到公网接口sudo ufw status verbose | grep -E (Anywhere127.0.0.1)ufw allow from 192.168.1.100仍被拒绝源 IP 被 NAT 转换实际到达服务器的是网关 IPsudo tcpdump -i eth0 port 80 -nn -c 5查看真实源 IP改用网关 IP或在上游设备配置端口转发Docker 容器端口被 UFW 拦截Docker 默认启用 iptables规则优先级高于 UFWsudo iptables -t nat -L -n | grep 8080方案 Aiptables: falsein/etc/docker/daemon.jsonufw reload后 SSH 断连UFW 加载新规则时短暂中断连接sudo journalctl -u ufw --since 1 minute ago启用前sudo ufw allow 22或用ufw --force reload跳过确认5.2 “UFW 规则不生效”的 5 层穿透式排查法当ufw status显示规则存在但网络访问仍异常按以下顺序逐层验证每层耗时不超过 30 秒第 1 层UFW 服务状态sudo systemctl is-active ufw # 必须返回 active sudo ufw status | head -3 # 必须显示 Status: active第 2 层iptables 链加载状态sudo iptables -L ufw-user-input -n -v \| head -5 # 检查 pkts 字段是否增长有流量匹配且 target 为 ACCEPT/DROP第 3 层规则匹配路径# 模拟一个连接看哪条规则命中 echo test \| nc -w 1 server-ip 8080 2/dev/null || echo Connection failed sudo iptables -L ufw-user-input -n -v \| grep 8080 # 查看 pkts 计数是否增加第 4 层内核 netfilter 状态# 检查 netfilter 是否启用 lsmod \| grep nf_ # 应有 nf_tables, nf_nat 等 # 检查 conntrack 是否工作 sudo conntrack -L \| head -5第 5 层上游网络设备# 在服务器上抓包确认包是否到达 sudo tcpdump -i eth0 port 8080 -nn -c 3 # 若无输出问题在防火墙/NAT/路由设备实操心得我曾在 AWS EC2 上遇到ufw allow 80无效最终发现是 AWS 安全组Security Group未开放 80 端口。UFW 是操作系统层防火墙AWS 安全组是云平台层防火墙两者是“与”关系必须同时开通。这个教训让我养成了“查云控制台 查 UFW 查 iptables”的固定排查顺序。5.3 UFW 日志分析实战从/var/log/ufw.log读懂攻击者意图UFW 日志是安全审计的金矿。默认日志级别为low只记录被拒绝的连接。开启详细日志sudo ufw logging medium # 记录 ACCEPT 和 DENY sudo ufw logging on日志格式示例[ 1234.567890] [UFW BLOCK] INeth0 OUT MACxx:xx:xx... SRC192.168.1.200 DST192.168.1.100 LEN60 TOS0x00 PREC0x00 TTL64 ID12345 DF PROTOTCP SPT54321 DPT22 WINDOW64800 RES0x00 SYN URGP0关键字段解读SRC192.168.1.200攻击者 IP注意可能是代理或僵尸网络DPT22目标端口SSH 暴力破解特征PROTOTCP协议SPT54321源端口随机高端口正常SYNTCP 握手标志表示连接请求我常用以下命令快速分析# 统计被拒绝最多的 IP sudo awk /BLOCK/ {print $NF} /var/log/ufw.log | cut -d -f2 | sort | uniq -c | sort -nr | head -10 # 查找针对 SSH 的暴力破解DPT22 sudo grep DPT22 /var/log/ufw.log | head -5 # 实时监控新拒绝事件 sudo tail -f /var/log/ufw.log | grep BLOCK发现高频攻击 IP 后可直接sudo ufw deny from 192.168.1.200封禁。UFW 的deny from规则会插入到ufw-user-input链最前立即生效。注意UFW 日志默认不轮转大流量服务器需配置 logrotate。编辑/etc/logrotate.d/ufw/var/log/ufw.log { weekly missingok rotate 12 compress delaycompress notifempty }6. 进阶扩展与生态整合让 UFW 成为 DevOps 流水线的一部分6.1 与 CI/CD 流水线集成在部署时自动同步防火墙策略在 GitOps 实践中UFW 规则应作为基础设施代码IaC的一部分纳入版本控制。我的标准做法是在 Git 仓库根目录创建infrastructure/ufw/目录将/etc/ufw/下的关键文件user.rules, before.rules