Portless 本地命名路由
Portless 安全运维：回环范围、转发头与 hosts 同步授权
理解本地和公网暴露边界，解释转发头为何不能直接作为可信身份，并检查固定版本的内部 hosts 同步认证。
你将学会
- 本地、局域网和公网分享是不同范围
- 内部接口不只检查回环地址
- 使用实验结果，但不把它写成安全认证
开始前需要
- 了解 HTTP 访问源、端口和命令行基础
- 能够区分回环、局域网与公网暴露
追踪命名请求，明确安装权限边界，并区分已观察行为和未测试集成。
先看结论
- 回环、LAN、tailnet 和公网隧道需要分别决定暴露范围。
- 保留的转发头不等于清洗后的安全身份。
- 有界授权测试不等于完整安全审计。
本地、局域网和公网分享是不同范围
文档中的代理默认绑定回环。LAN 模式改变监听并广播 .local 名称；可选 Tailscale、Funnel 与 ngrok 的可达范围和外部依赖不同。尤其公网隧道不等于私有本地路由。暴露含调试接口或示例凭据的开发应用前，应检查持久化 LAN 配置及分享环境变量。
检查的代理会保留已传入的 X-Forwarded-Proto、Host 和 Port，并把实际对端地址追加到 X-Forwarded-For，实验确认了这一点。因此这些头并不是可信公网入口清洗后给出的身份声明。应用在把它们用于授权、安全跳转或客户端识别前，需要明确自己的可信代理政策。
内部接口不只检查回环地址
POST /.portless/hosts-sync 仅在字面回环访问主机下被拦截。处理器检查真实对端，拒绝 Origin 与 Sec-Fetch-Site，要求恰好一个格式正确的令牌头，再用 timingSafeEqual 与配置令牌比较。实验中缺少凭据得到 401，有效测试凭据只到达无害的回调计数器，不会触发操作系统写入。
回调区分实际同步与已禁用，分别返回 204 和 409；相同路径若使用应用主机名，仍会转发给应用。HEAD / 只有在严格条件满足时才返回 HMAC 挑战证明，且证明可能伴随 404。因此不能仅凭 HTTP 200 判断代理身份，也不能把普通路由状态与认证证明混为一谈。
使用实验结果，但不把它写成安全认证
实验验证了即使测试令牌本身有效，重复令牌头和浏览器来源元数据仍会被拒绝，也检查了缺失或无效挑战的证明行为。这只能支持检查的分支，不是对 DNS 重绑定、全部网络对端、证书存储、系统服务或隧道集成的渗透测试。排障报告绝不能发布真实机器令牌。
HTTP 处理器以外仍有重要操作权限：强制替换路由可能终止登记的进程，信任证书会改变机器信任边界，安装服务可能创建特权持久执行。每项动作都应单独审查。跳数计数器可发现意外循环，但客户端能控制的请求头不是认证系统，也不是完整拒绝服务防护。
实施步骤
- 1
启动前检查实际绑定和分享设置。
- 2
明确应用信任哪些代理。
- 3
用假令牌和不写入的回调验证内部授权。
- 4
强制替换、证书信任和服务安装保持明确批准。
可复制示例
{
"回环测试结果": {
"缺少令牌": 401,
"有效令牌附带Origin": 401,
"重复令牌头": 401,
"有效令牌计数回调": 204,
"禁用回调": 409,
"有效HEAD证明状态": 404
},
"修改hosts文件": false,
"使用真实令牌": false
}常见问题
为什么有效挑战证明可能伴随 404？
证明头会先被加入，随后继续普通路由。字面回环主机不一定登记了应用，所以普通响应仍可能是 404。
令牌测试通过能证明适合公网部署吗？
不能。测试只覆盖选定的回环 HTTP 分支，公网暴露、应用认证与其他集成威胁仍需单独处理。
资料来源
- packages/portless/src/proxy.ts来源核查 2026-09-08
- packages/portless/src/hosts-sync-auth.ts来源核查 2026-09-08
- packages/portless/src/routes.ts来源核查 2026-09-08
- README.md来源核查 2026-09-08