SOCKS5 では、クライアントが宛先要求を送る前に認証が折衝されます。そのため、早い段階での資格情報の失敗は、プロキシの先での FTP、HTTPS、その他のアプリケーションの失敗とは別の出来事になります。

クライアントの挨拶には、対応している認証方式が列挙されます。サーバーはその一覧から 1 つの方式を選び、選択結果を返します。0xff という値は、提示されたどの方式も受け入れられず、接続を閉じなければならないことを意味します。パスワードが失敗した後で、クライアントがサーバー側のあらゆる方式を順に試すわけではありません。

Dante の順序が制御するもの

Dante 1.4.x はプロトコルレベルの設定を socksmethod と呼びます。そのドキュメントには、方式は優先順に列挙されると書かれています。両方の方式を許可するポリシーでは、この宣言はクライアントが提示したときにユーザー名/パスワードを優先します。

socksmethod: username none

一覧を逆にすると、両方の方式が提示されたときに認証なしのアクセスを優先します。

socksmethod: none username

これらは代替の方式宣言であり、完全なサーバー構成ではありません。待ち受けインターフェース、許可されたクライアント、宛先ルール、およびルール固有の認証制約は依然として重要です。

none を許可することには具体的な帰結があります。認証なしだけを提示するクライアントは、該当するルールの下で受け入れられる可能性があります。username を先頭に置いても、none を含む一覧が全員にパスワードを要求する条件になるわけではありません。

まず要件を選ぶ

許可されたすべてのクライアントがユーザー名/パスワードで認証しなければならない場合は、none を一般的な互換性の修正として追加するのではなく、その要件をグローバルルールと該当ルールで一貫して構成してください。限られたクライアント群に対して匿名アクセスが意図的である場合は、その群と許可される宛先を明示してください。

Dante には clientmethod もあり、これは TCP クライアントが接続したとき、SOCKS の折衝より前に実行される検査に関するものです。SOCKS5 の挨拶で交換される方式とは別の層です。古い method キーワードを使う構成の断片は、インストールされている Dante のバージョンのマニュアルに照らして読むべきです。

2 つのクライアントが異なる動作をする場合は、それぞれが何を提示するか、Dante が何を選択するか、選択された方式のサブ折衝が成功するかを比較します。次に SOCKS の宛先応答を調べます。この順序により、あらゆる失敗を FTP のせいにしたり、サーバーの認証ポリシーを盲目的に変えたりすることなく、欠落した資格情報コールバックを特定できます。

最後に、SOCKS5 のユーザー名/パスワード認証は パスワードの交換を暗号化しません。それらの資格情報に機密性が必要な場合は、適切に保護されたトランスポートまたはネットワークを使用してください。

関連記事