为 Squid 上级代理设置独立凭据
为 Squid 6.13 配置专用的上游代理登录信息,不要假定应将客户端的代理密码传给其他运营方。
用户登录你的 Squid 服务所用的凭据,与 Squid 登录上级代理的凭据不同。上级代理可能属于其他运营方,或使用不同的账户数据库。不要认为接受了客户端密码,就应把它传到上游。
Squid 6.13 可以在上级代理定义中附加静态登录信息:
cache_peer 192.0.2.20 parent 3128 0 no-query default name=upstream login=parentuser:ExampleOnly
上面的地址和密码均为文档示例。应把登录信息加到现有上级代理定义上,避免意外创建第二个 peer。同时保留用于决定哪些请求必须使用此上级代理的独立路由策略。
区分账户作用范围
下游的 auth_param 设置验证你的 Squid 实例的客户端。peer 的 login 选项为另一跳提供凭据。修改一方不会自动更新另一方。
遵循上级代理文档中的认证要求。这一行并非所有面向连接认证方案的完整配置。如果上级代理要求 NTLM 或 Negotiate,应核实受支持的 peer 配置方式,而不是反复修改此字段中的密码。
Squid 也提供 PASS、PASSTHRU 等凭据传递选项。它们与独立上游账户的语义不同,可能向 peer 暴露客户端认证信息。如果设计要求使用独立账户,不要把这些选项当作捷径。
保护配置并测试正确的一跳
静态秘密保存在配置中。限制文件和备份的访问权限,分享解析器或调试输出前先脱敏。该选项有自己的转义规则:文档允许 URL 转义,并要求将字面百分号写成两个。
如果客户端认证成功,但转发请求仍在上级代理处失败,应检查上游交互和账户。客户端到 Squid、Squid 到上级代理的传输保护也应分别考虑;加密第一段连接不会自动保护第二段。