隧道与穿透：对象、配置与机制

监听、转发、代理与隧道入口

VPN、端口转发和反向隧道都建立额外访问路径，但监听位置、认证方式和路由影响不同。先画清入口、隧道两端与目标服务，再配置暴露范围，不能用控制通道在线替代数据通路验收。

选择承载层

隧道承载层决定范围：SSH端口转发搬运指定TCP连接，SOCKS是应用代理，WireGuard承载IP路由，FRP把被映射服务带到代理端。先列出谁发起连接、谁监听、最终目的地和信任者，再选机制。一个端口通了不代表整个子网可达，应用代理也不自动接管所有DNS。

谁可以连接监听端

监听地址决定入口暴露范围。回环地址仅让本机连接，0.0.0.0监听所有IPv4接口；IPv6通配监听是否覆盖IPv4与系统设置有关。绑定回环并不能限制本机其他用户，防火墙、身份授权和服务端访问控制还需分别设计。对外映射前明确用户群和回退方式。

密钥、令牌和占位值

凭据管理需要区分VPN私钥、SSH用户身份与FRP令牌，不能重复使用。本文离线示例没有可部署秘密，文件中的保留地址仅用于推演；读者若另行部署需通过秘密存储替换并分发。不得将历史INI中的固定弱令牌和内部地址照搬。

练习与参考解答

练习：两个方案都把远端服务映射到本机端口：甲监听127.0.0.1，乙监听0.0.0.0。二者暴露范围是否相同？FRP令牌验证通过是否替代目标服务登录？

参考解答

不同，乙可接受所有IPv4接口上符合其他网络策略的访问，甲限本机但仍不隔离本机其他用户。FRP令牌只管理相应代理接入，不为映射业务补上登录与授权；要分别记录监听地址/端口和业务认证机制，不能只记录“隧道已连接”。

控制通道、数据路径与信任边界

先明确监听端、控制通道、目标服务与回程，再对照配套示例理解FRP 映射、SSH 转发与 WireGuard 路由。

本地与远程转发

LocalForward在客户端开入口，目标连接从SSH服务端发出；RemoteForward在服务端开入口，目标连接从客户端发出。两者的localhost分别属于执行目标连接的那一端。先画连接方向再填地址，否则常把本机服务意外暴露在远端。远程监听还受GatewayPorts与服务端策略限制。

动态转发与解析位置

SOCKS解析位置由应用代理模式决定，有的应用在本机先做DNS，有的把域名交给代理。DynamicForward本身不保证所有应用流量或DNS都走代理。代理成功只说明该应用使用的链路有效，排查时记录应用配置、解析点和最终目标。

加密路由与系统路由

WireGuard的AllowedIPs把公钥与允许的内层IP前缀关联，出站选对端、入站约束源地址。系统路由表决定包是否进入隧道，配置工具可能辅助添加路由；两者不能混为一件事。0.0.0.0/0扩大接管范围，也涉及DNS、回程和管理连接，不能只改一行就声称全流量安全。

控制通道与被映射服务

FRP认证用于控制客户端接入代理，传输加密保护相应链路，但它不自动为被映射服务增加业务身份认证。服务端允许端口范围、代理绑定地址与网络防火墙决定暴露面。v0.61.1的TOML字段与旧0.29.1的INI字段不同，本课只作字段与边界阅读，不运行穿透进程。

回程、NAT与重叠地址

返回路径缺失会使隧道握手正常但业务不通。重叠网段是两端LAN地址冲突的常见来源；两端LAN地址重叠时，更具体路由可能把包交给本地网卡；应先重划地址或设计明确转换，不能靠反复重启。NAT改变源地址，影响审计和授权，需同时记录转换前后身份及回程。

练习与参考解答

练习：A为SSH客户端、B为服务端。LocalForward把A的回环15432转到127.0.0.1:5432，目标localhost属于谁？WireGuard握手成功但目标网段不通还要看哪两类路由？

参考解答

该目标连接由B发出，因此127.0.0.1属于B而不是A。WireGuard还需核对系统是否把目标流量送进隧道，以及AllowedIPs是否选择正确对端并允许内层源地址；再检查回程和重叠网段。端口转发和IP路由不能互相替代。

FRP 旧 INI 映射的角色与撤回范围

FRP local_ip 属于哪一端，HTTP 域名配置能保证映射成功吗？ 两份旧 FRP 记录共用服务端 Linux、客户端 Windows 的场景，应统一为控制入口、业务映射入口和客户端目标三类对象。server_addr/server_port 指向 frps，remote_port 是代理端提供的入口，local_ip/local_port 是 frpc 一侧实际连接的服务；客户端 127.0.0.1 不代表服务器回环。HTTP 虚拟主机映射还需要入口监听、实际请求域名与 DNS 相符，不能只填 custom_domains 就推定链路成功。

原 INI 混有 auth_token、privilege_token、服务端代理段、管理面板和不同端口组，不能视为一份已验证的兼容配置。旧 0.29.1 二进制下载、INI 字段和公网地址全部撤回为现行启动模板，现代固定版本两端 TOML 在应用篇单独表达。命令行 -c 指向哪份配置应在两端分别记录，不能把 Windows frpc.exe 当 Linux 服务端。

管理面板是另一入口，不应因调试方便默认公开；FRP 令牌不替代映射 SSH/HTTP 服务的登录授权。固定弱令牌、口令、扩大 allow_ports 和通配绑定均不迁作安全基线。旧 Nginx 转发 0.0.0.0:9000 也不证明管理面板已可靠受保护，应使用明确可连接上游并单独设计认证。配置审阅不证明穿透可用，DNS、端口与证书需逐项验证。

应用代理配置、规则顺序与配置缺失

Clash MATCH 后的直连规则是否保证生效，v2fly 是否有完整配置？ Clash 与 v2fly-core 草稿描述应用代理，不是 Linux 系统配置或完整 VPN。HTTP、SOCKS、DNS 与管理 API 是不同监听；映射容器端口、应用实际启用代理、解析位置和出站目标需分别证明。暴露 7890/7891 或 10808/10809 不会自动使所有应用流量通过代理，也不证明 UDP 与 DNS 使用了同一路径。

旧 Clash 清单公开代理与管理端口，允许 LAN 并在所有接口监听 controller/DNS，却没有可核验的访问控制；不能作为默认部署。规则清单先 MATCH 再列“内网直连”，不能仅因直连条目存在就声称已经按预期分流；需要按所选实现的匹配顺序检查，终止匹配规则应放在设计的兜底位置。旧 172.12/172.13 地址不是 RFC1918 私网，不能按公司旧地址推广为私网。proxies 中 server/port/uuid/password 是占位值，不构成可用订阅或协议兼容性证据。

v2fly-core 仅挂载 /etc/v2ray 并指定 config.json，没有提供该 JSON 正文；Windows 导出截图不代替可静态检查的配置。旧 latest 风格镜像、Compose version、hosts 挂载、外部 dashboard 和界面链接全部撤回为现行安装方案，未据此断言产品消失或不再可用。可迁移的是配置路径、端口、代理范围、DNS 和管理入口的核对方法；本课不把这些草稿升级成新的代理产品教程。