macOS 互联网共享不依赖传统防火墙规则，其 NAT/DHCP/DNS 服务由系统深度集成并自动管理；若共享后其他设备无法访问 SMB（445）、VNC（5900）等服务，需单独用 socketfilterfw 放行对应服务路径，而非修改 pf.conf 或关闭防火墙。
macos 的“互联网共享”和“本地存储防火墙”并不是两个独立的、可并列管理的功能模块。系统中没有叫“本地存储防火墙”的内置机制；你实际想配置的，是启用互联网共享时所依赖的网络服务（如 nat、dhcp、dns 代理）及其对应端口的入站/出站访问控制，而这些服务受 macos 底层防火墙（pf + socketfilterfw）影响——但方式很特殊。
先搞清：互联网共享本身不走传统防火墙规则
当你在「系统设置 → 网络 → 互联网共享」中开启共享（例如：将 Wi-Fi 共享给 Ethernet），macOS 实际启动的是：
• bootpd（DHCP/DNS 服务，监听 UDP 67/53）
• natd 或 pf NAT 规则（内核级转发）
• sharingd（协调服务，不监听端口）
这些组件由系统深度集成，不受「阻止所有传入连接」或「防火墙选项」里的应用列表控制。也就是说，你无法用 socketfilterfw --add 去“放行 bootpd”——它压根不在防火墙的应用白名单逻辑里。
终端启用/禁用互联网共享（无需动防火墙）
互联网共享开关由 sharing 命令控制，不是防火墙指令：
- 查看当前共享状态：
sudo sharing -l - 启用共享（示例：从 Wi-Fi 共享到 Ethernet）：
sudo sharing -s com.apple.InternetSharing -e en0 -i en1
（其中en0是源接口，en1是目标接口；用ifconfig | grep "en"查实际名称） - 停用共享：
sudo sharing -s com.apple.InternetSharing -d
执行后系统自动加载 /etc/pf.anchors/com.apple.internet-sharing 中的 NAT 规则，无需手动操作 pfctl。
真正需要终端干预的防火墙场景
如果你开启共享后，其他设备仍无法访问 Mac 上的共享服务（如文件共享 SMB、屏幕共享 VNC），问题通常出在防火墙对这些服务的拦截——但注意：
• 不是互联网共享被拦，而是 SMB（445）、VNC（5900）、SSH（22）等服务被默认阻止
• 这些服务需单独放行，且推荐用 socketfilterfw（非 pfctl），因为系统会周期性重载 pf.conf，手动加的规则容易丢失。
- 确认服务是否在监听：
sudo lsof -iTCP -sTCP:LISTEN -P | grep -E "(445|5900|22)" - 为 SMB 放行（签名服务，通常已自动允许）：
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --add /usr/sbin/smbd - 为屏幕共享放行：
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --add /System/Library/PrivateFrameworks/ScreenSharing.framework/Versions/A/Resources/screensharing.bundle - 验证放行结果：
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --list
不要碰 pf.conf 做共享相关修改
虽然 /etc/pf.conf 是底层防火墙配置文件，但 macOS 的互联网共享功能会动态写入自己的 anchor（锚点），并由 launchd 管理。手动编辑 pf.conf 添加针对 bootpd 或 natd 的规则：
• 容易被系统覆盖（尤其在重启、网络切换或系统更新后）
• 可能与共享服务的 anchor 冲突，导致 NAT 失效或 DHCP 不响应
• 没有必要——只要共享开关打开，系统已确保内部转发通路
