Danteにユーザー名認証を追加する

Dante 1.4.4では、クライアントルールがSOCKSネゴシエーションの前に接続を受け入れ、SOCKSルールが認証済みリクエストのうち何を先へ通すか決めます。許可済みの送信元からの接続でも、第2段階でユーザー名を要求できます。

OSのユーザー名で認証する場合は、方式だけでなくサービスの実行主体も確認します。アカウントデータベースの読み取りには、特権を持つ実行主体が必要になる場合があります。

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

Dante用に実際に用意された低権限のサービスアカウントを使用してください。ユーザー名認証のバックエンドに対応する、利用を許可されたクライアントアカウントを作成または選択します。サービスの実行主体とクライアントのログインは別の役割です。

リクエストの許可範囲を維持する

既存の範囲を絞ったクライアントルールの後で、許可する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
}

アドレスとアカウント名は例です。この設定は1つの送信元、1つの宛先、1つのコマンド、および指定した認証済みユーザーを許可します。パスワードを追加したからといって、この境界を取り払い、送信元を無制限にしないでください。

全体の認証方式とルールごとの方式を一致させます。送信元だけで許可していた設定の、noneのみを認める古いルールが残っていないか確認してください。意図したリスナーとファイアウォールの制限も維持します。

ネゴシエーションとアクセスを別々に確認する

起動する前に、インストール済みサーバーの設定チェックモードでファイルを検証します。その後、SOCKS5のユーザー名・パスワードネゴシエーションに実際に対応する許可済みクライアントを使用します。認証情報なし、誤った認証情報、許可されたアカウントから禁止された宛先への要求を確認してください。

RFC 1929で定義されたユーザー名・パスワードのサブネゴシエーションは、パスワードを暗号化しません。後から宛先と確立するHTTPSセッションは、それより前のプロキシとのやり取りを保護しません。クライアントからサーバーまでを適切に保護した経路を使用します。

設定チェックの成功で確認できるのは構文と実行主体であり、アカウントデータベースやネットワーク経路ではありません。実際のテストがどの段階で拒否されたか、サーバーログを確認してください。