ユーザー名とパスワードによるプロキシ認証：接続方法とエラー対策

ユーザー名とパスワードによる認証では、アプリケーションが事業者から発行された認証情報をプロキシへ送ります。プロキシはその情報を確認し、サービスの利用を許可します。異なる端末やネットワークで作業する際に便利な方式です。サービスがIPによる認可も要求していなければ、別のサーバーへスクリプトを移しても、許可IPを変更する必要はありません。

接続を動かすには、ユーザー名とパスワード以外にも、正しいプロキシアドレス、ポート、プロトコルが必要です。アプリケーションも、必要な認証方式に対応している必要があります。したがって、認証エラーが必ずしもパスワードの間違いを意味するわけではありません。

アクセス方式の比較と選び方は、プロキシ認証をご覧ください。この記事では、設定の入力から、稼働中のスクリプトの問題の切り分けまで、ユーザー名とパスワードを使う接続を説明します。

ユーザー名・パスワード認証とは

ユーザー名はアカウントや特定サービスへのアクセスを識別し、パスワードは利用する権利を確認します。確認に成功すると、プロキシは与えられた権限の範囲、つまり利用可能なアドレス一覧、購入した利用枠、適用される上限に従って接続を処理します。

プロキシ認証情報と管理画面のパスワードを混同しないでください。アプリケーションが使う情報は、事業者のウェブサイトへのログイン情報と異なる場合があります。APIキーはサービスAPIへのリクエストに使い、接続先サイトのパスワードはそのサイトへのログインに使います。事業者がその接続方式を明示している場合に限り、それらをプロキシのパスワードとして使ってください。

プロキシ認証に成功しても、接続先ウェブサイトへログインしたことにはなりません。サイトが独自のアカウント、Cookie、トークンを求める場合、アプリケーションはそれらを別途用意する必要があります。

この方式が便利な場合

ユーザー名とパスワードによるアクセスは、固定された複数の場所でも、移動する環境でも使えます。IP制限がなければ、各アプリケーションに認証情報とプロキシ接続設定を用意するだけで、ネットワークごとに許可リストへ登録する必要はありません。

例えば、チームが2つのオフィスと自宅で作業し、それぞれ異なるパブリックIPを使う場合です。サービスがIPをひも付けない認証情報の共有を認めていれば、各アプリケーションで同じプロキシ認証情報を使えます。アプリケーションごとに接続設定を持ち、プロキシはそれぞれから送られる認証情報を確認します。

この方式は、複数の常設サーバーでも使えます。ただし、端末数、同時接続数、利用できるリソースはプランによります。1つのパスワードで無制限に利用できるわけではありません。

アプリケーションによるプロキシ認証情報の送信方法

全体の流れは簡単です。アプリケーションがプロキシへ接続し、アクセス確認を通過してから、目的のリソースへアクセスします。詳しい手順はプロトコルによって異なります。

HTTPプロキシは、まず407 Proxy Authentication Requiredを返し、受け付ける認証方式を示す場合があります。アプリケーションは、Proxy-Authorizationリクエストヘッダーに認証情報を入れて送信します。最初から送るクライアントもあるため、最初の認証要求がログに現れない場合もあります。

通常のHTTPプロキシ経由でHTTPSサイトを開く場合、トンネルを確立するCONNECTリクエストの際に認証を行えます。その後、アプリケーションがサイトとの安全な接続を確立します。確立済みのトンネルを通る後続のサイトリクエストでは、トンネルを開く際のプロキシログインを繰り返しません。

SOCKS5では、接続の開始時、接続先への接続要求より前にユーザー名とパスワードを確認します。失敗すると、アプリケーションはプロキシ経由の要求した接続を得られません。SOCKS5自体の認証失敗は、HTTP 407応答ではありません。

サービスが対応するプロトコルと認証方式を選びます。SOCKS4にはユーザーID欄がありますが、SOCKS5のユーザー名・パスワード交換方式は定義されていません。その欄を埋めても、SOCKS4クライアントがSOCKS5のパスワード認証を行えるようにはなりません。

アプリケーションに入力する設定

利用するサービスの接続情報を確認します。アプリケーションに項目別の欄がある場合は、それぞれ対応する値を入力します。

アプリケーションによっては、protocol://username:password@host:port形式の1本の文字列を入力できます。例えば、http://client01:River%[email protected]:8080では、ユーザー名はclient01、パスワードはRiver@2026、ホストはproxy.example、ポートは8080です。パスワード内の@を%40と表すことで、ホストの前にある区切り文字と区別します。

例えばcurlは、このようにプロキシURLを解釈します。独立したパスワード欄では通常、URLエンコードせず、パスワードそのものを入力します。書式を確認せずに、URL内のエンコード済みの値を別の欄へコピーしないでください。別のパスワードと解釈される可能性があります。%、コロンなどの特殊文字を含む場合は、そのクライアントの書式に従います。

認証情報内の必要な文字だけを1度エンコードします。文字列全体をエンコードすると、区切り文字が壊れます。コマンド引数を引用符で囲んでも、URLエンコードの代わりにはなりません。認証方式にも制限がある場合があります。例えばHTTP Basicでは、パスワードにコロンを使えますが、ユーザー名には使えません。

インポート形式も異なります。host:port:username:passwordとusername:password@host:portは交換して使えません。値が正しくても、読み込み側が別の並びを想定していれば、順序が違うと動作しません。

プロキシURLのhttp://は、クライアントがプロキシ自体に接続する方式を示します。HTTPSサイトへのアクセスを妨げるものではなく、クライアントはそのためのトンネルを確立できます。単にhttps://へ書き換えても、サーバーに安全なプロキシ接続への対応が追加されるわけではありません。

サービスによっては、ユーザー名に国、出口グループ、セッションのパラメーターを含めます。文字列全体をコピーしてください。これらは事業者の規則で経路を制御するものです。書式を自作したり、別のサービスの書式を流用したりしないでください。

アプリケーションの認証対応を確認する理由

プロキシへの対応と、プロキシ認証への対応は別の機能です。ホスト欄とポート欄があっても、ユーザー名とパスワードを送信できるとは限りません。

プロキシプロトコル、認証方式、アプリケーションの具体的な組み合わせを確認します。例えば、Chrome内蔵のSOCKS5実装は、SOCKS5プロキシ認証に対応していません。正しい認証情報だけでは、この制限を解消できません。プロキシ選択用の拡張機能でも、足りない認証方式を追加できるとは限りません。

スクリプトでは、使用するライブラリー、その追加コンポーネント、設定の渡し方によって対応状況が変わる場合があります。アプリケーションが、システムのプロキシ設定や、すでに接続できているブラウザーの設定を使うとは限りません。

大きなタスクを開始する前に、実際に使うアプリケーションで1つのリクエストをテストします。指定したプロキシを使い、失敗後に直通接続へ切り替わっていないことを確認します。ページが開いただけでは、設定が正しいと確認したことにはなりません。

自分のIPが変わるとどうなるか

動的IPのADSL接続では、ルーターの再起動や再接続時にISPが新しいアドレスを割り当てることがあります。プロキシがユーザー名とパスワードだけを確認するなら、同じ認証情報で接続でき、管理画面に新しいIPを追加する必要はありません。オフィスから自宅のネットワークへ移る場合も同様です。

ただし、ネットワークの切り替えで既存の接続が切れる場合があります。クライアントは再接続する必要があり、未完了のリクエストは再試行が必要になることもあります。Wi-Fiからモバイル回線に切り替えた直後のエラーを、すぐにパスワードの問題と判断しないでください。

認証情報と送信元アドレスの両方を確認するサービスもあります。正しいパスワードでもネットワーク制限は回避できず、新しいIPが許可されたアドレスか範囲に一致する必要があります。スクリプトを移す前に、任意のネットワークから接続できるのか、併用確認を行うのかを確かめます。

転送中のパスワードは保護される？

認証は誰にアクセスを許可するかを決めます。暗号化は、経路上の第三者が転送データを読めるかを左右します。パスワードがあるだけで、接続が暗号化されるわけではありません。

HTTP Basicは、ユーザー名とパスワードをBase64でエンコードします。これは元に戻せる表現であり、暗号化ではありません。プロキシへの接続が保護されていなければ、そのネットワーク経路を監視する人が認証情報を得られる可能性があります。標準のSOCKS5ユーザー名・パスワード認証も、送信内容を暗号化しません。

接続先サイトのHTTPSが保護するのは、アプリケーションとそのサイトの間です。HTTPプロキシでは、トンネル確立時の認証が先に行われるため、サイトのTLSはすでに送ったプロキシ認証情報を保護しません。同様に、SOCKS5経由のHTTPSリクエストも、その前に行うプロキシのパスワード確認を暗号化するものではありません。

この経路部分を守るには、サービスとクライアントの両方が対応する場合にTLSを使うHTTPSプロキシを利用するなど、アプリケーションとプロキシの間を保護する必要があります。アプリケーションはプロキシの証明書を検証しなければなりません。販売リストによっては「HTTPSプロキシ」がHTTPSサイトへ接続できるという意味だけの場合もあるため、TLSが実際にどこに適用されるかを確認します。

有効なパスワードを含む完全な接続文字列が漏れると、第三者がサービスの規則の範囲で利用し、利用枠を消費したり、接続を占有したりする可能性があります。認証情報が別なら、これは管理画面のパスワードが漏れたこととは異なります。また、認証方式はアドレスがプロキシと識別されないことを保証しません。外部から到達できる認証要求で、サービスが分かる場合があります。

複数のアプリケーションで認証情報を共有できる？

技術上は、複数のクライアントが同じユーザー名とパスワードを送れます。それを認めるか、共有条件、有効な接続数の上限、購入した利用枠、追加制限をどう定めるかは事業者が決めます。

例えば、2つのスクリプトが1つのアカウントを使いながら、それぞれ異なる数の接続を開くことがあります。1つのパスワードは1つの接続を意味しません。同様に、10個のプロセスを起動しても、サービス全体の接続枠が10倍になるわけではありません。

認証情報の組数と出口IP数も異なります。1組のユーザー名とパスワードで、固定IPのプロキシ一覧や、アドレスプールを使うゲートウェイへアクセスできる場合があります。サイトに見えるIPは、選んだプロキシとサービスの経路選択規則によって決まります。

サービスがアプリケーション別やチームメンバー別の認証情報を提供すれば、ほかを変えずに1組だけを無効にできます。パスワードを共有している場合、変更時には使っているすべてのアプリケーションを更新する必要があります。ただし、認証情報が別でも接続枠や通信量枠が別とは限りません。どの上限を共有するか確認します。

プロキシがユーザー名とパスワードを拒否する理由

まず、誰がエラーを返したかを特定します。HTTPの407はプロキシ認証に関するものです。接続先サイトからの401は、そのサイトへのアクセスに関するものです。ほかの証拠がなければ、403メッセージやタイムアウトだけでプロキシパスワードの正否は分かりません。

サービス状態と残りの利用枠を確認し、実際のアプリケーションで指定の設定を使って1つのリクエストをテストします。失敗したら、表を使ってクライアントの対応、認証情報の書式、送信元IPの制限を確認し、1度に1つの設定だけを変えます。リクエストが安定して成功してから負荷を増やし、負荷時だけ現れる上限を確認します。

稼働するスクリプトで認証情報を保存・変更する方法

認証情報はコードと分け、アクセス制御のある設定や、環境のシークレット保管機能で管理します。環境変数から渡すこともできますが、環境変数自体は暗号化ではありません。有効なパスワードをリポジトリーや他人と共有するテンプレートに入れないでください。

ログには通常、プロキシのホストとポート、接続結果、エラーコードがあれば足ります。完全な接続文字列にはパスワードが含まれるため、ログへ書く前に伏せます。コマンドラインツールでは、アプリケーションやシステムによって、機密情報がコマンド履歴に残ったり、プロセス引数に表示されたりする可能性も考慮します。

パスワードを変更する前に、ローカルアプリケーション、サーバープロセス、定期実行タスク、ビルドシステムなど、すべての利用元を調べます。変更後に設定を更新し、新しい接続でテストします。長時間稼働するプロセスにも新しい値が反映されたか確認してください。再起動が必要なものもあります。

古いパスワードを無効にする目的なら、それを使う新しい接続が拒否されるかテストします。既存接続の扱いはサービスの規則に従い、変更後すぐには閉じない場合があります。緊急にアクセスを取り消す場合は、事業者が対応するアクセス無効化の方法を使います。

併用認証：IPとパスワード

併用認証では、プロキシが認証情報とアプリケーションの接続元アドレスの2条件を確認します。両方を満たす必要があり、正しいパスワードだけではIP制限を回避できません。

ProxyCompassの固定IPパッケージの併用モードは、/24サブネットを使います。同じサブネットのパブリックIPv4を複数持つ場合、許可リストに1つ追加すれば十分です。同じサブネットのほかのアドレスは、個別の登録なしに、正しいユーザー名とパスワードで接続できます。

図では、アプリケーションのパブリックIPの先頭3つの数値が、許可リストのアドレスと一致しています。有効な認証情報なら接続できます。サブネット外のアドレスはネットワーク確認を通過できず、サブネット内でもパスワードが違えば失敗します。同じサブネットのほかのクライアントIPでも、この登録を使えます。ユーザー名とパスワード欄が必須のアプリケーションに便利です。この規則が対象とするのはアプリケーションのパブリックIPであり、購入したプロキシの出口IPではありません。