3proxy の HTTP と SOCKS の両サービスでログインを必須にする

HTTP と SOCKS5 クライアント向けに、3proxy のユーザー、強力な認証、サービスへのアクセスルールを構成します。

ユーザーを定義するだけでは 3proxy のログイン設定の全体にはなりません。サービスには認証方式と、それを使うアクセスルールも必要です。設定が処理される過程でサービスの設定が適用されるため、順序が重要です。

2 つのサービスに対するローカル専用の例は次のとおりです。

users alex:CL:replace_with_a_private_password
auth strong
allow alex
proxy -i127.0.0.1 -p3128
flush
allow alex
socks -i127.0.0.1 -p1080

設定リファレンスでは users、auth strong、およびサービスコマンドについて説明されています。CL はこの例のパスワードを平文で保存します。ファイルを保護し、配備に適したサポート対象の資格情報保存形式を選んでください。

クライアントには正しいログイン交換が必要

HTTP サービスは HTTP プロキシ認証を想定しています。SOCKS サービスには SOCKS5 のユーザー名とパスワードによる認証をサポートするクライアントが必要です。SOCKS4 クライアントは、同じリスナーポートに到達するというだけではその交換を提供できません。

strong という語は認証モードの名前であり、暗号化された転送の保証ではありません。必要に応じてクライアントからプロキシまでの区間を保護してください。宛先への HTTPS とプロキシへの暗号化は別々の判断のままです。

ループバック結合はこの例をローカルアクセスに限定します。リモートクライアントには、意図したリスナーとネットワークポリシーを明示的に選んでください。公開ワイルドカードリスナーはログイン動作の確認の代わりにはなりません。

一方のサービスが認証情報を求め、もう一方が求めない場合は、各サービスコマンドより前の設定、flush の後のルール、認証のキャッシュを調べてください。パスワードを変えても、誤ったポリシーで起動したサービスは修復できません。同様に、デーモンのオペレーティングシステムアカウントを変えてもプロキシユーザーは作成されません。

関連記事