VPN背後のCloudFrontジオブロック:出口を診断する
エッジは自分が見るアドレスで判断し、共有された出口は国と評判の両方を変える。出口ノードを切り替える前に、各制御を個別に検証すること。
地理制限はIPアドレスに関する判断であり、VPNはサービスが見るアドレスを変える。この一文だけで、サポート窓口に届く不可解な報告の大半が説明できる。「自宅ではサイトが開くがトンネル経由では失敗する」と「トンネル経由では開くが社内の他の誰も読み込めない」は同じ仕組みが逆の結果を生んでいるだけだ。本手順書は、原因を一つずつ除外する順序で診断を進め、まずエッジが実際に何を返したかから始める。同じ出口アドレスでも、ある検査は通り次の検査で落ちることがある。各検査はそのアドレスの異なる性質を評価しているからだ。
何かを変える前に403を読む
地理ブロックもWAFブロックも403で返り、直す場所は異なる。レスポンスヘッダーとボディの先頭行を取得する。CloudFrontはキャッシュヘッダーと理由文字列を含み、どの層が応答したかを示す。
curl -sS -o /tmp/body.txt -D /tmp/headers.txt https://d111111abcdef8.cloudfront.net/
grep -i "x-cache\|via" /tmp/headers.txt
head -c 300 /tmp/body.txt
配信自体が地理的条件でリクエストを遮断した場合、ボディには国制限を示すメッセージが入る。WAFルールが遮断した場合は、通常は汎用的な禁止ページで、ヘッダー内の配信リクエストIDをWAFログに持ち込むことになる。ここを取り違えると、レートベースルールの問題を国の許可リストで直そうとすることになり、一日を無駄にして成功しない。
ステップ1:配信がどのアドレスを見ているか確認する
失敗しているブラウザと同じマシン、同じ経路から、外部世界に何が見えているかをネットワークに尋ねる。curl -s https://checkip.amazonaws.com は呼び出し元の公開アドレスを返す。VPNクライアントではこれが加入者の自宅回線ではなく出口になる。
curl -s https://checkip.amazonaws.com
nslookup d111111abcdef8.cloudfront.net
そのアドレスが別の国の事業者の出口であれば、地理的判断はすでに下されており、クライアント側では変えられない。設定に触れる前にアドレスをチケットに書く。報告の中で、あなたとサービスが一致している唯一の事実だからだ。
ステップ2:国と評判を切り分ける
CloudFrontはリクエストの送信元アドレスをキーにした第三者のGeoIPデータベースから閲覧者の位置を解決する。対応付けは正確な特定ではなく、おおよそ地域単位だ。位置を判定できない場合、文書化された既定動作はコンテンツを配信することである。したがって状態は三つある。出口が遮断国に割り当てられる、許可国に割り当てられる、データベースが判断を持たずリクエストが通る、だ。
遮断国の利用者でも、事業者がその国に出口を持っていれば許可国にいるように見える。許可国の利用者でも、出口が別の場所に登録されていれば遮断される。どちらの結果も制限が壊れていることを証明しない。どちらも、与えられたアドレスに対して制限が働いているだけであり、CloudFrontの地理制限のドキュメントが説明するとおりだ。
評判は第二の軸であり、トンネルを越えて残る。AWS WAFの匿名IP向けマネージドルールグループは、VPN、プロキシ、Torノード、ホスティング事業者からのリクエストを遮断するために作られている。国検査を通ったリクエストでも、アドレスがどこにあるかではなく何であるかによって拒否されうる。トンネルをクラウドホストへ移したときに遮断が始まったなら、この層が有力だ。
ステップ3:クォータの挙動を確認する
共有出口は第三の形で失敗する。IPごとのレート制限とセッション数は一つのアドレスを一人のクライアントとして扱い、消費者向け出口は同時に多数の加入者を載せている。そのため自宅回線では目立たないリクエストパターンが、出口からは自動化に見える。症状は自然に解消する速度制限や一時遮断であり、地理的なエラーメッセージではない。
配信はアドレスごとのセッション数を意図的に数えることもある。たとえばDynamoDBに書き込むLambda@Edge関数を使う場合だ。それは出口の背後にいる個人を特定しないが、一つのアドレスを一人のクライアントのように振る舞わせる。これが実際の意図であることも多い。しきい値を調整する前に、苦情の背後にある異なるアドレスを記録する。二百席を前にした社内NATは、外から見るとまさに混雑した出口と区別がつかない。社内NAT、大学ネットワーク、単一アドレスを提示する大家族からの誤検知を想定する。
地理を疑う前に、WAFのサンプルリクエストとレートベースルールのメトリクスを見る。出口のリクエスト量で発火するルールは明確な痕跡を残し、修正が上限調整か別の出力経路かを教えてくれる。
何を、どの順で変えるか
まず制御の目的を決める。地域カタログの維持、悪用の制限、契約の履行は三つの異なる目的であり、国リストで扱えるのは最初の一つだけだ。目的が悪用対策なら、出口は身元の単位として誤っている。どれだけ許可リストを整えても、共有アドレスは信頼できるようにならない。
許可リストのために安定したアドレスが本当に必要な場合は、専用または固定の出口が役立つ。アドレスを登録でき、変動しないからだ。ただし居住用アドレスになるわけではなく、GeoIPデータベースが割り当てる国も変わらない。一つ動くまで出口を替えるのは一時的な評判の変更であり、ポリシーの修正ではない。
最後に、依頼者が使った言葉で結果を書く。このアドレスは国、評判、またはレートによって遮断されており、変えるべき制御はこれだ、と。曖昧なままだと、来週また別の出口で同じチケットが来る。