以前プロキシを使ったことがあれば、IPホワイトリストはおそらくお馴染みのものでしょう。サーバーのアドレスをプロバイダーに登録しておけば、そのアドレスからの接続は認証情報なしで許可されます。これは一般的なモデルであり、他の製品から移ってきた人はこの設定を探しに来ることがよくあります。
レジデンシャルゲートウェイに関する直接的な答えは、IPホワイトリストは存在しないということです。認証はすべてのリクエストでユーザー名とパスワードによって行われ、認証情報が唯一の認証手段です。これは機能の欠落ではなく意図的な設計上の選択であり、アクセスの保護方法を変えるものなので、その理由を理解しておく価値があります。ホワイトリストは製品ラインの他の部分、ISPプロキシとレガシーなポートベースのプランには存在しており、そこでの設定方法についてもここで扱います。
レジデンシャルゲートウェイが認証情報を使う理由
レジデンシャル製品は単一のエンドポイント p.shifter.io:443 であり、すべてのターゲティング情報はユーザー名の中に収められています。ステッキーセッション付きの米国出口へのリクエストも、ローテーティングするドイツ出口へのリクエストも、ホストとポートは同じで、変わるのはユーザー名の文字列だけです。この設計は認証に対してある帰結をもたらします。認証情報はすでにリクエストごとの情報を運んでいるため、どのみち毎回のリクエストに含める必要があるのです。
認証情報による認証は移植性もかなり高く、これは見た目以上に重要です。ホワイトリストはアクセスを固定の出口アドレスに結びつけますが、現代のインフラの多くにはそのような固定アドレスがありません。コンテナは再スケジュールされるたびに新しいアドレスを取得し、オートスケーリンググループはノードを追加・削除し、サーバーレス関数は予告なく変化する共有アドレス空間を経由して出て行き、CIランナーは一時的であり、ノートPCや自宅回線を使う開発者は一晩で変わりうる動的アドレスを持っています。ホワイトリストの下では、これらすべてがサポートチケットになります。シークレットストアに認証情報を入れておけば、同じ設定がノートPC、コンテナ、CIジョブ、本番クラスタのどこからでも、誰も何も登録することなく動作します。
したがって、レジデンシャルプロキシでホワイトリストの設定を探してこの記事にたどり着いたのであれば、代わりに設定すべきものは認証情報の取り扱いであり、これは以下で扱います。
ホワイトリストが適用される場所
2つの製品はソースIPによる認証を使用しており、もしホワイトリストがあなたにとって必須要件であれば、これらを検討すべきです。
ISPプロキシは2つの認証モードをサポートしており、パネルでプランごとにどちらかを選びます。authorized source IPモードでは、サーバーのアドレスを登録し、その後ポート 1337 で固定IPに接続します。認証情報は一切不要です。username and passwordモードでは、どこからでも認証情報を使って接続でき、IPごとに1行の設定になります。トレードオフはまさに上で説明した通りです。ホワイトリストは認証情報をコードから完全に排除できますが、その代償として登録済みアドレスからしか動作しません。ISPプロキシはローテーティングレジデンシャルとは異なる製品で、ローテーションするプールではなく固定の静的アドレスを持ちます。両者のどちらを選ぶか比較する場合は、ISP versus residential proxiesとwhat static residential proxies areを参照してください。
レガシーなポートリストプランはソースIPのみで認証します。割り当てられた各ポートには専用のサブドメインがあり、パネルでサーバーのアドレスをホワイトリストに登録するか、レガシーな管理APIを通じてリストを管理し、その後リスト内の任意のポートに接続します。このプランを利用している場合、ホワイトリストはオプションではなく、唯一の認証手段です。業界がこのモデルから離れていった背景については、why the per-port era is overを参照してください。
ISPプロキシでホワイトリストを設定する
仕組み自体は単純ですが、ほとんどの失敗は2つの詳細に起因します。
まず、ローカルのアドレスではなく、**出口(egress)**アドレスを登録してください。重要なのはトラフィックが実際に出てくる公開アドレスであり、これはLANアドレスでも、コンテナの内部アドレスでも、そのマシンで ifconfig が表示するものでもありません。実際にリクエストを送信するマシンから確認してください。
# run this ON the server that will connect to the proxies
curl -s https://ipinfo.io/ipインフラがNATゲートウェイやロードバランサーを経由して出て行く場合は、その共有アドレスを登録すべきものであり、それが動的に割り当てられるものではなく安定していることを確認する価値があります。
次に、パネルのISP Proxies内で認証モードを意図的に選んでください。2つのモードは重ね合わせられるものではなく、互いに排他的な選択肢だからです。authorized source IPモードに入れば、認証情報なしで接続できます。
# authorized source IP mode: no username or password
curl -x 185.199.108.153:1337 https://ipinfo.io/jsonこれがエラーを返し、アドレスが登録済みであることが確実な場合、よくある原因は、出口アドレスが変わった、IPv4アドレスを登録したがトラフィックはIPv6経由で出て行っている(あるいはその逆)、あるいはテストしたノードとは別のノードからリクエストが送られている、といったものです。
トレードオフを率直に述べると
ホワイトリストはコードや設定からシークレットを取り除くという点で確かに価値があります。リポジトリに漏洩するものがなく、ローテーションする必要もなく、ログに残ることもありません。その弱点は、出口アドレスが変わった瞬間に機能しなくなることであり、安定したアドレスを持たない場所からのアクセスをサポートできないことです。
認証情報による認証は移植性が高く、どの環境からでも動作しますが、認証情報はあなたが所有することになるシークレットであり、ソースコードではなくシークレットマネージャーに置くべきものであり、ローテーション計画が必要です。
どちらが本質的に安全というわけではありません。両者は異なる形で失敗し、正しい選択はあなたのインフラが安定した出口を持つかどうかによります。
レジデンシャルの認証情報を保護する:ホワイトリストが存在しないため
レジデンシャルゲートウェイを利用している場合、このセクションがあなたにとってホワイトリストの代わりになります。
認証情報をソースコード管理やコンテナイメージから排除し、シークレットマネージャーに裏付けられた環境変数から読み込んでください。可能であれば環境ごとに別々の認証情報を使い、開発環境の値が漏洩しても本番環境が露出しないようにします。ローテーションはパネルでのワンクリックではなくデプロイとして扱ってください。まずシークレットストアを更新し、クライアントをロールし、それから古い値をローテーションします。というのも、以前のパスワードをまだ保持しているクライアントは、変更された瞬間から407を返し始めるからです。これはfixing 407 and credential errorsで扱われている、最もよくある自己招来型の問題です。
そして、もう一方の側も制御してください。プロバイダー側にホワイトリストがなくても、通常の出口ルール、ネットワークポリシー、またはセキュリティグループを使って、自分のシステムのうちどれがゲートウェイに到達できるかを制限できます。これにより、漏洩した認証情報がインフラの外部からは使いにくくなります。また、帯域使用量を監視してください。説明のつかない消費は認証情報が漏れたことの兆候であり、自分のpipeline monitoringからベースラインを把握しておけば発見しやすくなります。
よくある間違い
10.x や 192.168.x のようなプライベートアドレスを登録すること。これは公開の出口アドレスのみがプロバイダーから見えるため、決して一致しません。ノートPCや自宅回線をホワイトリストに登録し、ルーターの再起動でアドレスが再割り当てされて動かなくなったときに驚くこと。オートスケーリングが別のアドレスの背後にノードを追加することを忘れること。トラフィックが実際にはIPv6経由で出て行っているのにIPv4を登録すること。そして、ある製品でのホワイトリストエントリが別の製品もカバーすると思い込むこと。ISPプロキシのホワイトリストはレジデンシャルゲートウェイには何の効果もなく、依然として認証情報が要求されます。
結論
レジデンシャルゲートウェイにはIPホワイトリストは存在せず、これは設計によるものです。ターゲティング情報はユーザー名の中にあるため、認証情報はどのみち毎回のリクエストに存在する必要があり、認証情報による認証はコンテナ、オートスケーリング、CI、動的な接続にわたって、ホワイトリストでは破綻してしまう場面でも機能し続けます。ソースIP認証が特に必要な場合、ISPプロキシは2つの選択可能なモードの1つとしてそれを提供しており、レガシーなポートリストプランはそれを唯一の手段として使用します。どちらの場合も、登録すべきものはローカルのものではなく公開の出口アドレスです。レジデンシャルでは、ホワイトリストの代わりに規律ある認証情報の取り扱いを行ってください。シークレットマネージャー、環境ごとの値、古いパスワードを無効化する前にクライアントを更新する手順、そして自分の側での出口制御と使用量の監視です。
すべての製品に対応する完全な認証リファレンスはauthentication documentationにあり、ゲートウェイの詳細はgateway and authenticationにあります。製品自体はresidential proxiesで、すべての国とセッションモードにわたって単一のエンドポイントと単一の認証情報ペアを使用し、per-GB pricingとなっています。