为 Dante 添加用户名认证

在 Dante 1.4.4 中，client 规则在 SOCKS 协商之前接纳连接，SOCKS 规则则决定哪些通过认证的请求可以继续。即使连接来自白名单中的地址，第二阶段仍然可以要求提供用户名。

使用操作系统用户名认证时，除了认证方式，还要检查服务使用的身份。读取账户数据库可能需要特权身份：

clientmethod: none
socksmethod: username
user.privileged: root
user.unprivileged: danteproxy

使用实际为 Dante 安装的低权限服务账户。创建或选择与用户名认证后端兼容、获准使用的客户端账户；服务运行身份和客户端登录账户承担不同的角色。

保留请求的访问边界

在现有的严格 client 规则之后，为允许的 SOCKS 路由增加账户要求：

socks pass {
    from: 198.51.100.27/32 to: 203.0.113.20/32 port = 443
    command: connect
    socksmethod: username
    user: proxyuser
    log: connect error
}

地址和账户名都是示例值。这里仅允许一个来源、一个目标、一种命令，以及指定的已认证用户。不要因为加了密码，就将这道边界替换为不限来源的访问。

全局和规则内的认证方式必须一致。检查是否还留有过去仅按来源放行时使用的、只接受 none 的旧规则。也要保留原本需要的监听器和防火墙限制。

分别测试认证协商和访问权限

启动之前，用已安装服务器的配置检查模式验证文件。然后使用确实支持 SOCKS5 用户名和密码协商的授权客户端，检查未提供凭据、凭据错误，以及获准账户请求禁止目标的情况。

RFC 1929 定义的用户名和密码子协商不会加密密码。随后与目标建立的 HTTPS 会话，也保护不了此前与代理交换的认证信息。客户端到服务器之间应使用受到适当保护的路径。

配置检查成功只能确认语法和身份，不能证明账户数据库或网络路径可用。实际测试被拒绝时，应从服务器日志中查明拒绝发生在哪个阶段。