プロキシのIP認証:許可するアドレスと適した用途

プロキシのIP認証:許可するアドレスと適した用途

IP認証では、許可された接続元アドレスからプロキシを利用できます。そのアドレスを事業者のアクセスリストに追加すると、アプリケーションはプロキシ用のユーザー名とパスワードを別途送信せずに接続できます。事業者は通常、これをホワイトリスト、許可リスト、または認可済みIPアドレスのリストと呼びます。

固定パブリックIPを持つサーバーなど、安定したネットワークでアプリケーションを動かす場合に便利な方式です。ただし、許可するのはアプリケーションの接続元アドレスであり、購入したプロキシのアドレスではありません。設定時には、この2つを混同しやすいため注意が必要です。

アクセス方式の比較は、プロキシ認証をご覧ください。このガイドでは、どの送信元IPを許可するか、複数の端末でどのようにアクセスを共有するか、ネットワーク変更後に何を確認するかを説明します。

プロキシは保存したリスト内の送信元IP 198.51.100.24を許可し、別の送信元IPを拒否します。追加するのはクライアントのパブリックIPであり、プロキシのアドレスではありません。

プロキシによる許可IPの確認方法

接続を受けると、プロキシは送信元IPを確認して、許可されたアドレスと照合します。一致し、サービスのほかの条件も満たしていれば、リクエストを受け付けます。IP認証だけを使う場合、プロキシのパスワードを送る必要はありません。サービスによっては、アドレス確認とほかのアクセス要件を組み合わせます。

ルーターを通じてインターネットに接続する自宅のパソコンを例に考えます。

アドレスの種類例役割
パソコンのローカルIP192.168.1.20自宅のネットワーク内で使います。この例では、外部のプロキシには見えません。
自宅回線のパブリックIP198.51.100.24このアドレスからプロキシへ接続します。許可するのはこのアドレスです。
プロキシへの接続アドレス203.0.113.80アプリケーションのプロキシ設定に、ポートと一緒に入力します。
プロキシの出口IP203.0.113.90ウェブサイトからは、プロキシが接続する際の送信元として見えます。

プロキシの接続アドレスと出口IPは、同じ場合も異なる場合もあります。どちらもアクセスリスト内のクライアントIPの代わりにはなりません。また、出口IPが固定のプロキシを購入しても、自宅のアドレスが恒久的に固定されるわけではありません。

ローカルネットワーク内のプロキシにも、同じ原則が当てはまります。プロキシが確認するのは、自分に見える接続元です。その送信元がプライベートアドレスの場合もあります。インターネット上の商用プロキシでは、通常、利用するネットワークのパブリックな外向きアドレスが必要です。

IP認証が便利な場合

外向きアドレスが固定のサーバーなら、そのアドレスを1度許可すれば、複数のプロセスからプロキシを使えます。設定ごとにプロキシのパスワードを保存したり、アプリケーション間で配布したり、変更時にすべてのコピーを更新したりする必要がありません。

管理されたオフィスでは、複数のパソコンが1つのパブリックIPを共有することがあります。サービスがこの使い方を認めていれば、1件の登録でそのネットワークの外向きアドレスを許可できます。オフィス内のアクセス制御は、引き続きネットワーク管理者の責任です。

必要なプロキシプロトコルには対応していても、提供された方式でユーザー名とパスワードを送信できないアプリケーションにも役立つ場合があります。IP認証は、その問題を解決する可能性があります。ただし、HTTP、SOCKS5など、アプリケーションにない機能が追加されるわけではありません。

追加するIPの調べ方

アプリケーションを実行する環境からアドレスを調べます。自宅のパソコンのブラウザーなら、設定中のプロキシを使わずにIPアドレス確認ページを開きます。そのプロキシ経由で開くと、プロキシの出口アドレスが表示され、間違ったIPをリストに追加するおそれがあります。

VPS上でスクリプトを動かす場合は、管理に使う自宅のパソコンではなく、VPSの外向きアドレスが必要です。クラウド環境では、サーバーやコンテナーが共有NATゲートウェイから通信する場合があります。その場合はゲートウェイのパブリックアドレスが該当し、サーバーへのログインに使うアドレスとは異なることがあります。

VPNを使う場合は、経路に注意します。プロキシへの接続がVPNを通れば、プロキシに見えるのはVPNの出口アドレスです。経路を分けている場合、ブラウザーとスクリプトが別の出口を使うこともあります。したがって、ブラウザーでの確認で分かるのは、そのテストで通った経路だけです。事業者が接続ログを提供していれば、送信元を直接確認する助けになります。

IPv4とIPv6は別のアドレスです。IPv4アドレスを許可しても、IPv6接続が自動で許可されるわけではありません。アクセスリストが受け付けるバージョンと、アプリケーションがプロキシへ接続する際のアドレスを確認します。これは、ウェブサイトに見えるプロキシ出口IPのバージョンとは別の問題です。

IP確認ページと顧客管理画面をベクターで描き直した図です。IPv4 198.51.100.24を選び、IP Whitelist → Manageを開いてアドレスを追加し、保存後に約3分待ちます。最後の画面には、2つの許可済みIPと、それぞれ750の接続数が表示されています。
実際のProxyCompassインターフェースを模式的に描き直した図です。英語のボタン名は、提供された画面と一致しています。

ProxyCompassでは、確認結果にIPv6も表示されていても、パブリックIPv4アドレスを使います。サービスカードでIP Whitelist → Manageを開き、追加欄にIPv4アドレスを貼り付け、Add IPをクリックします。リストを設定したらSaveをクリックし、アクセス規則の反映を約3分待ちます。その後、プロキシ経由で新しい接続をテストします。

複数の端末には、許可IPがいくつ必要?

プロキシへ到達する際の異なる送信元アドレスを数えます。パソコンの台数や購入するプロキシ数とは、大きく異なる場合があります。

例えば、1つのパブリックな外向きアドレスを共有するオフィスの8台のパソコンなら、1件の登録で利用できる場合があります。外向きアドレスが異なる自宅のパソコンとVPSを同時に使うには、2つのアドレスを許可する必要があります。登録枠が1件しかない場合、自宅のIPをVPSのIPに置き換えても、両方の送信元が同時に許可されるわけではありません。

逆に、登録が注文全体に適用されるなら、1台のサーバーから20個のプロキシに接続しても、クライアントIPを20個用意する必要はありません。許可する送信元アドレス、注文内のプロキシ数、同時接続上限は、別々のサービス設定です。

購入前に、利用できる登録枠と、追加・変更の条件を確認します。複数のネットワークを使うには、追加枠、共通の管理された出口、またはサービスが認める別の認証方式が必要になる場合があります。共有出口には保守が必要で、タスクの可用性に影響する構成要素が1つ増えます。

パッケージ全体の例:同時接続数は1500です。2つのクライアントIPに750ずつ、または一方に1000、もう一方に500を割り当てられます。クライアントIPを追加しても、合計は増えません。

図のProxyCompassの例では、パッケージで1500の同時接続を利用できます。IPの横の750は、そのクライアントアドレスからの接続上限であり、現在開いている接続数ではありません。2つのアドレスに750ずつ割り当てられています。スライダーで配分を変更でき、例えば最初のIPに1000、次のIPに500を割り当てられます。1つのパブリックIPの背後にある端末は、そのIPの割り当てを共有します。

ホワイトリストにIPを追加しても、パッケージ全体の接続上限は増えません。並列タスクや接続の再利用への影響は、同時接続上限の記事で説明しています。

アクセスを設定して結果を確認する方法

  1. 作業環境の外向きIPを特定し、該当するサービスのリストに追加します。アプリケーションで使う注文やプロキシグループを選んでいることを確認します。
  2. IP認証用の接続アドレス、ポート、プロトコル、アクセスモードを事業者から取得し、アプリケーションに入力します。ユーザー名とパスワードの欄を空にするのは、実際にそれらが不要なモードに限ります。
  3. サービスの案内に従って、規則が反映されるのを待ちます。管理画面やAPIが登録の保存を確認しても、すべてのノードに規則がすでに適用されているとは限りません。すべてのサービスに共通する待ち時間はありません。
  4. 実際に作業するアプリケーションで新しい接続を開き、プロキシ経由で小さなリクエストを送ります。出口IPを期待する結果と比較し、アプリケーションが通知せず直通接続へ切り替わっていないことを確認します。その後、主なタスクを開始します。

別のパソコンやリモートサービスからのテストは、別の送信元IPから到達します。そのテストが拒否されるのは、アクセス制限が正しく動作しているためかもしれません。それだけでプロキシの故障とは判断できません。

IPやネットワークが変わるとどうなる?

ISPが新しいアドレスを割り当てたり、ノートパソコンをモバイル回線に切り替えたり、VPNの出口が変わったりすると、新しい接続がリストにないIPから到達する場合があります。プロキシ自体は動作していても、クライアントのアクセス条件が変わったということです。

短い回線切断で、必ずIPが変わるわけではありません。まず現在のアドレスを確認し、許可済みの登録と比較します。変わっていなければ、ネットワークの可用性、アプリケーション設定、サービス状態を調べます。IPが同じでも、ネットワークの中断後には既存の接続を復旧する必要がある場合があります。

アドレスが頻繁に変わる場合は、アクセスを維持するための管理作業を考慮します。利用できる場合、固定パブリックIP、安定したサーバー出口、APIによる許可リストの自動更新が役立ちます。自動化では、規則の反映時間を考慮し、再試行を制限する必要があります。設定変更用のAPIキーは、プロキシ接続にパスワードがなくても、別途保護すべき機密情報です。

管理できなくなった古いアドレスを「念のため」に残さないでください。後で他人に割り当てられる可能性があります。サービスの操作機能で、その許可を取り消します。取り消しで既存接続も終了するかは、実装によって異なります。

IPリストが保護する範囲と管理方法

プロキシのアドレスとポートだけが知られても、送信元の確認により、未許可のネットワークからの接続を防げます。これは、漏れたプロキシリストの不正利用対策になります。ただし、サービスの規則の範囲で機能するものであり、許可したパソコンやゲートウェイの保護に代わるものではありません。

パブリックIPは、個人の身元を証明しません。異なる従業員が同じオフィス出口を使うことも、ISP側でアドレスを共有するCGNATにより、複数の契約者が1つのパブリックIPを使うこともあります。アクセスがそのIPだけに依存する場合、プロキシはその規則で利用者を区別できません。誰が使えるアドレスかを理解したうえで許可します。

共有IPを削除すると、その送信元を使う全員が接続できなくなります。1人の従業員だけの権限を取り消し、ほかの人を接続したままにすることはできません。個別のアクセス制御には追加の対策が必要です。サブネット全体を許可する前に、そこから誰が接続できるか、サービスが認証情報も求めるかを確認します。

IP認証自体は、通信を暗号化せず、出口IPがプロキシだと識別されることも防ぎません。データ保護は使用する接続に依存し、ネットワークの挙動やほかの信号からプロキシの情報が分かる場合もあります。設定にパスワードがないことは、アクセスが無管理であることも、通信が暗号化されていることも意味しません。

IPによるアクセスが失敗する理由

現象最初に確認すること
自宅では動くがVPSでは動かないVPSの外向きIPと、そのIPがリストにあるかを確認します。自宅のアドレスに対する許可は、別の送信元には適用されません。
ネットワークやVPNの変更後に使えなくなったプロキシへ到達する送信元アドレスが変わっていないか確認します。
IPを追加したが、すぐには接続できなかった選択したサービス、正確なアドレス、規則の反映状況、新しい接続の設定を確認します。
HTTPプロキシが407を返す、またはアプリケーションがパスワードを求めるアクセスモード、ポート、事業者の要件を確認します。このコードはプロキシ認証を求めるもので、想定したIPアクセスが失敗した理由を説明するものではありません。
接続がタイムアウトするアドレスとポートへの到達性、ネットワークの制限、接続ログを確認します。タイムアウトだけでは、IPリストの問題とは判断できません。
ほかのサイトは開けるが、1つのサイトだけアクセスを拒否する誰が拒否を返したか、リクエストがプロキシを通ったかを確認します。例えば、ウェブサイトの403応答だけでは、プロキシ認証の問題だと証明できません。

407はHTTPのコードです。SOCKS5には独自の応答やエラーメッセージがあるため、その中にHTTPコードを探す必要はありません。問い合わせには、試行時刻、外向きIP、プロキシのアドレスとポート、選択したプロトコル、正確なエラーメッセージが役立ちます。

IP認証を選ぶ場面

作業環境全体にアクセスが必要で、プロセスごとのパスワード配布を避けたい場合、安定して管理できる外向き接続を持つアプリケーションに適しています。選ぶ前に、すべての拠点に十分な登録枠があり、ネットワーク変更時にリストを更新できることを確認します。

アドレスが頻繁に変わる場合、担当者が異なるネットワークで作業する場合、個人ごとにアクセスを取り消す必要がある場合は、ほかの認証方式やサービスの追加制限も検討します。購入したプロキシリスト内のアドレス数ではなく、誰がどこから接続するかで判断します。

ナレッジベースに戻る