スクラッチでIPジオロケーションデータベースを構築する

 (ipapi.is)
5 ポイント 投稿者 GN⁺ 2023-09-15 | 1件のコメント | WhatsAppで共有
  • IPジオロケーションデータベースは、IP範囲を国・都市・郵便番号・タイムゾーン・座標に対応付けるもので、ipapi.is は無料CSVと商用CSV/MMDBデータベースを提供している
  • 無料版はIPv4・IPv6の全空間をカバーしておらず精度も低いが、商用版はAPIのlocationフィールドで使われる完全なデータベースで、少なくとも週2回更新される
  • 自前で構築するには、WHOISのgeoloc・geofeed、WHOISの住所・説明フィールドからの位置推定、RIPE IPmap・geofeed-finder・OpenGeoFeedのような公開プロジェクトを併用する必要がある
  • ネットワークが複数地域に分散していたり、IPが再割り当て・リースされると精度は揺らぎ、RIPE NCCの2023年7月時点でのgeolocカバレッジは2.3%、geofeed URLカバレッジは**0.17%**程度である
  • 収集データには、都市・国から座標を見つけたり、座標から近い都市を見つけたりする補強・正規化が必要で、ipapi.is はGeoNamesの郵便番号・都市・国情報ファイルを活用している

IPジオロケーションデータベースの構成

  • IP to Geolocation Database は、IP範囲ごとのジオロケーション情報を保存するデータベースである
  • IPアドレスは次の情報でジオロケーション化できる
    • 国、都市、州、郵便番号
    • タイムゾーン
    • 緯度、経度
  • ipapi.is のデータベースは無料版と商用版に分かれる
    • 無料版はCSV形式でダウンロード可能
    • 商用版はCSVとMMDB形式で提供される
    • 商用版はIPv4・IPv6の全空間を扱う
    • 無料版はIPv4・IPv6空間の一部のみを含む
  • 商用データベースは少なくとも週2回更新される

無料版と商用版の違い

  • 無料のIPジオロケーションデータベースは商用版よりエントリー数が少なく、IPv4・IPv6アドレス空間全体をカバーしていない
  • 無料版はジオロケーション精度が低い
  • 無料版の主なソースはWHOISデータとRFC 8805 Geofeedsである
  • 商用データベースは ipapi.is API のlocationフィールドで使われる完全なデータベースである
  • 商用版は複数のソースを組み合わせて位置を算出する
    • WHOISレコード
    • ping、tracerouteベースのアクティブ遅延測定
    • RFC 8805 Geofeeds
    • 逆引きDNSルックアップ

データベース形式と精度フィールド

  • データベースファイルはCSVまたはMMDB形式である
  • 主なフィールドはIP範囲、位置、座標、精度を含む
    • ip_version: IPv4は4、IPv6は6
    • start_ip, end_ip: ネットワーク範囲の開始・終了IP
    • continent, country_code, country, state, city, zip
    • timezone, latitude, longitude
    • accuracy
  • accuracyはジオロケーション情報の推定精度を1～5で表す
    • 1: 非常に高い精度で、通常は都市レベルで信頼できる
    • 2: 高い精度で、一般に都市レベルで信頼できる
    • 3: 中程度の精度で、都市レベルでは信頼しにくい
    • 4: 低い精度で、通常は国レベルで正確
    • 5: 非常に低い精度で、国レベルで正確と期待される

MMDBサンプルの確認方法

IPジオロケーションの活用と限界

  • IPジオロケーションは、IPアドレスを緯度・経度で定義された地理的位置にマッピングするプロセスである
  • オンラインビジネスやサービス提供者は、ジオロケーション情報をさまざまな用途に活用する
    • ターゲティング広告
    • 不正検知と防止
    • コンテンツのローカライズ
    • DRMとコンプライアンス
    • ネットワークセキュリティ
    • 分析とインサイト
  • IPジオロケーションが常に正確とは限らないのには構造的な理由がある
    • 割り当てられたIPv4・IPv6ネットワークが地理的に分散している可能性がある
    • モバイルネットワークや衛星ネットワークのように、複数地域にまたがるよう設計されたネットワークがある
    • Regional Internet Registry またはIPリース会社がIPネットワークを再割り当て・再配分すると位置が変わる可能性がある
  • IPアドレスのジオロケーション化は複雑だが、IPアドレスAPIで無視しにくい精度を提供できる

スクラッチで構築する際に必要な作業

  • インターネット上の各IPアドレスは特定の組織が所有または管理している
  • ARIN、APNICのようなRegional Internet Registry(RIR) はWHOISデータベースに所有情報を保存している
  • WHOISレコードが割り当てネットワークのジオロケーション情報を常に含むわけではない
  • ネットワーク所有組織は、任意の地理的位置でIPを使用でき、第三者に割り当てたりIPブロックをリースしたりすることもできる
  • ジオロケーション情報の収集は大きく3つに分かれる
    • WHOISレコードからgeoloc、geofeedのような直接的なジオロケーションデータを抽出する
    • WHOISの郵便住所、説明、国情報から間接的に位置を推定する
    • RIPE IPmap、geofeed-finder、OpenGeoFeedのような公開プロジェクトを活用する

RIRごとの直接的なジオロケーションデータ

  • RIPE NCC

    • RIPE NCCのinetnum、inet6numオブジェクトはIPネットワークを組織に割り当てる
    • ジオロケーション情報はgeolocとgeofeedの2つの属性で提供される場合がある
    • geolocは緯度と経度を文字列で保持する
    • 例: 47.855374 12.132041
    • 2023年7月時点でRIPE NCCデータベースにはinetnumが4,190,644件、inet6numが819,381件あった
    • このうちgeoloc属性を含むオブジェクトは114,389件で、全体カバレッジは**2.3%**である
    • geofeedはRFC 8805形式のCSVファイルURLを保持する
    • geofeed URLは専用のgeofeed属性、またはremarks属性のGeofeed {URL}形式で記録されることがある
    • 2023年7月時点でRIPE NCCにはremarks属性のgeofeed URLが6,643件、geofeed属性を持つWHOISレコードが2,035件あった
    • geofeed URLカバレッジは**0.17%**だが、1つのgeofeedファイルが複数のネットワークを含む可能性があるため、この数値は誤解を招くことがある

  • ARIN

    • ARINはNetRangeオブジェクトのComment属性にgeofeed URLを入れる方式でジオロケーション情報を提供している
    • 専用のgeofeed属性追加の要望はあったが、CommentやRemark属性で十分という理由で却下された
    • ARINデータベースはRIPE NCCと異なりgeoloc属性を使わない

  • LACNIC

    • LACNICはARINよりジオロケーション対応に積極的である
    • LACNICは、会員が保有IPアドレスのジオロケーション情報を提供できるGeofeed Serviceを運営している
    • 公開データはmilacnic.lacnic.net/lacnic/geofeedsで提供される
    • LACNIC WHOISデータベースは基本的に都市レベルのジオロケーション情報を提供する
    • LACNICデータベースはFTPサーバーftp.lacnic.net/lacnic/dbase/からダウンロードできる

  • AFRINICとAPNIC

    • AFRINICはジオロケーションサービスを提供しておらず、ジオロケーション提供者との公式・運用上の関係もないと表明している
    • AFRINICはRIPE NCCと同様にremarks属性のgeofeed URL利用をサポートしている
    • APNICはRIPE NCCとほぼ同じレベルでジオロケーションをサポートしている
      • geoloc属性
      • remarks属性のgeofeed URL
    • APNICはジオロケーション支援の改善に前向きな姿勢を見せている

WHOISから位置を推定する方法

  • WHOISの主目的は、IPアドレスやAS番号のようなインターネット番号を所有する組織の登録者情報を提供することである
  • WHOISには組織の本社や管理拠点の郵便住所と国が含まれることが多い
  • 組織の郵便住所がIPアドレスの利用場所と一致することもあるが、常にそうとは限らない
  • 大規模組織の管理住所は、その組織のすべてのIPアドレスの場所と一致しない可能性がある

  • RIPE NCCでの推定

    • RIPE NCCのinetnum、inet6numオブジェクトで利用可能な属性は次のとおり
      • country: 国レベルの精度のみを提供
      • descr: ネットワーク説明であり、位置・住所情報が入る場合がある
      • netname: 解析が難しく信頼性が低い
      • address: 厳密にはroleオブジェクトの属性で、郵便住所を保持する
    • country属性はISO 3166-2の文字国コードを識別するが、その国が本社所在地なのかデータセンター所在地なのか最終利用者所在地なのかは指定しない
    • descr属性は自由形式の説明だが、組織がネットワークの場所や住所情報を入れる場合があり、ジオロケーション推定に有用である
    • addressは高い精度を与えることがあるが、roleオブジェクトの郵便住所がIPアドレスの利用場所と同じだと仮定すると誤りが生じうる

  • ARINでの推定

    • ARINでは次のWHOIS属性が、小規模組織や単一拠点に集中した組織では比較的信頼できる
      • Address
      • City
      • StateProv
      • PostalCode
      • Country
    • 大学、病院、政府機関のような組織は、NetRangeオブジェクトのIPアドレスを管理郵便住所と同じ場所で使っていることがある
    • 大企業や全国規模の組織が多数のNetRangeを保有している場合、管理郵便住所が実際のIP利用場所と一致しないことがある
    • Google Fiberの例では、WHOIS住所を使うとMountain View, Californiaになるが、多くのジオロケーション提供者はそのIPをTexasのSan Antonioに位置付けている

  • LACNIC、AFRINIC、APNIC

    • LACNICはWHOISデータベースでジオロケーションを提供しているため、別途推定は不要である
    • AFRINICはRIPE NCCと同じWHOISデータベース形式を使っているため、同じ原則を適用できる
      • country, descr
      • roleオブジェクトのaddress
    • APNICもRIPE NCCと同じWHOISデータベース形式を使っているため、同じ原則を適用する

公開ジオロケーションプロジェクト

  • RIPE IPmap

    • RIPE IPmapは、インターネットのコアインフラ向けジオロケーションデータを提供するAPIだった
    • もはや保守されていないようで、2019年以降は新たな貢献がないように見える
    • RIPE IPmapは複数のエンジンでIPアドレスのジオロケーションを推定する
    • latencyとsingle-radiusエンジンはRIPE Atlasの測定値を用いてIPアドレスの遅延半径を提供する
    • 最小RTT測定値は、光ファイバー媒質における光速の制約から可能な最大距離の上限を与える
    • reverse-dnsエンジンはPTRレコードのホスト名から都市レベルのジオロケーションを抽出する
    • RIPE IPmapデータベースはhttps://ftp.ripe.net/ripe/ipmap/からダウンロードできる
    • プロジェクトの精度とカバレッジは、以前の保守担当者のWebサイトによれば大幅に低下している

  • geofeed-finder

    • geofeed-finderは、WHOISデータからgeofeedファイルを発見して取得するオープンソースツールである
    • このツールはプレフィックス所有権の検証、キャッシュ管理、ISOコード検証も行う
    • RFC 9092に従ってWHOISデータからgeofeedを抽出できる
    • ネットワーク全体におけるgeofeed情報のカバレッジが非常に低いため、実用性は限定的である

  • LACNIC Geofeeds ServiceとOpenGeoFeed

    • LACNIC Geofeeds Serviceは、LACNIC会員のかなりの割合のジオロケーション情報を提供する
    • データはmilacnic.lacnic.net/lacnic/geofeedsで公開ダウンロード可能である
    • RIRレベルでジオロケーション情報を収集できる点で重要なプロジェクトである
    • OpenGeoFeedは、RFC 9092に従った独自公開geofeedを集めるオープンソースプロジェクトである
    • OpenGeoFeedは、既知の公開geofeedファイルをまとめた単一ファイルopengeofeed.org/feed/public.csvを提供している
    • OpenGeoFeedは有望だが、geofeedカバレッジが最新ではないように見え、データソースが頻繁に更新される可能性も低い

データ補強と正規化

  • 複数ソースから集めた生のジオロケーションデータは不完全だったり一貫性がなかったりする
  • 国・都市情報はあるが座標がないレコードと、座標はあるが国・都市情報がないレコードの両方がありうる
  • 生レコードが国情報しか含まない場合、精度は国レベルを超えにくい
  • 収集データは共通フォーマットへ補強・変換する必要がある
  • データ補強はオープンソースの地理データベースを使って行う
  • 補強作業は2つのケースに分かれる
    • 都市・国の組み合わせから緯度と経度を見つける
    • 緯度・経度から最も近い都市と国を見つける
  • ipapi.is はジオロケーション情報の補強に次のデータベースを使っている

関連記事

1件のコメント

 
GN⁺ 2023-09-15
Hacker News のコメント

  • IPinfo に加わる前から記事を楽しく読んでいて、IPinfo では IP ジオロケーションデータサービスを提供している
    ここで説明されている方法より拡張された手法を使っており、公開データセットも一部活用しているが、中心となる位置データは ping ベースの測定から得ている
    世界中の複数のサーバーから IP アドレスに ping を送り、多辺測量（multilateration）で位置を特定する。1台のサーバーからの ping は「特定の半径内のどこか」という一次元の情報しか与えないが、複数のサーバーで繰り返すと位置が徐々に精密になる
    十分に測定すれば郵便番号レベルに近い精度まで到達でき、現在は世界中に600台以上の検知サーバーがあり、引き続き増やしている
    公開データは古かったり頻繁に更新されなかったりし、一般に有用と言えるほど精密ではなく、大きな IP レンジや組織単位の位置しか提供しないことが多い
    また公開データセットには検証プロセスがない。IPv4 取引や VPN サービスが増える中で、不正確な情報が注入される事例も見てきたため、IP 位置修正の報告はありがたく受け取るが、必ず検証している
    検知ネットワークを運用してきた経験上、中央アフリカのどこかの国よりもニューヨークでサーバーを買うほうがはるかに簡単で安い。IP アドレスの位置は、その IP が提供できる価値に大きく影響する
    プロジェクトで使える無料の IP-to-Country ASN データベースも提供している: https://ipinfo.io/developers/ip-to-country-asn-database

    • どの記事のファンなのか気になる。https://incolumitas.com/ の記事なのか、https://ipapi.is/ の記事なのか？
      遅延時間による三角測量というアイデアは良い。VPN やプロキシ検知などさまざまな用途で遅延時間情報を使ってきたが、そこまで正確な位置が得られるとは考えていなかった
      600台のサーバーで遅延時間による三角測量を行えば、かなり良い近似が得られそうで印象的だ
      ただ、いくつか気になる点がある。一部の ISP は ICMP トラフィックを低い優先度で処理したり性能を落としたりするが、それにどう対応しているのか、すべての IPv4 をジオロケーションするには数十億のアドレスに継続的に ping を送る必要があるが、各割り当て inetnum/NetRange からランダムな IP を1つだけ測定しているのか、ほとんどの IP アドレスは ICMP に応答しないが、対象の手前のルーターを見つけてそのルーターの位置を取っているのかが気になる
    • エニーキャストアドレスは ICMP 応答時間で「位置」を捉えるのが難しく、一部は論理的な位置が別に結び付いている。例は https://blog.cloudflare.com/icloud-private-relay/ で見られる
    • IPinfo のファンかつ顧客として、ログイン通知メールに「たった今、ドイツのベルリンからログインしました。本人でない場合はこちらをクリックしてください」といった文言を入れるために API を使っている
      顧客監査ログの国データ提供、スパム防止や不正検知にも使っている
    • データベースを Parquet 形式でダウンロードできるようにすることを検討したことがあるか気になる
      そうすればファイルを S3 や Google Cloud などにコピーして、複数のツールから直接クエリできる。CSV でも可能ではあるが、スムーズではない
    • 既存の情報源がないときに IP アドレスの位置をどう把握するのか気になっていたが、この説明はまさに知りたかった内容で、とても興味深い

  • 自分で実装したくないなら、簡単な Cloudflare Worker で Cloudflare に無料でやってもらうことができる。すべての Cloudflare リクエストには、おおよその IP 位置情報が含まれている
    Cloudflare Worker で動いているこの URL にリクエストを送ってもよい。世界的に低いレイテンシになるはずだ: https://www.edenmaps.net/iplocation
    小さなアプリでは使っても構わないが、1日1,000万リクエストずつ送らないでほしい、という程度だ

    • 第三者に、どの IP アドレスがサービスに接続した可能性があるかを共有するより、IP データベースをダウンロードして使うほうがよい
    • ソマリア沖から100km離れた場所だと表示されるが、実際にはベルギーのブリュッセルにいる。プライバシー保護ありがとう :D
    • Worker リクエストでの Cloudflare ジオロケーションがどれくらい正確なのか知っている人がいるか気になる
    • 素晴らしい。可能ならそのコードを オープンソースとして公開してもらえるか気になる
    • ミュンヘンにいるのに、Cloudflare は北に730km離れた適当な森を指している

  • 公用語が母語ではない国に住んでいるので、IP 位置から言語を推測して強制適用するウェブサイトが本当に嫌いだ
    ブラウザが言語ヘッダーを非常に明確に送っているのに、それを無視して怠惰な仮定に基づいて言語を決めてしまう

    • IP ジオロケーションサービスで働いているが、自分もこれが嫌いだ
      業界では「ウェブ体験のパーソナライズ」と呼ぶが、腹立たしいやり方だ。誰にもそうするよう勧めたことはない
      IP ジオロケーションでウェブサイトをパーソナライズするなら、税金のようなもの、送料、国選択ドロップダウンでユーザーの国を一番上に置く程度がせいぜいだ
      それ以外はほとんど思いつかない。翻訳はたいていうまく機能せず、邪魔になるだけだ。ウェブサイトに善意があったとしても、Google Translate で現地語版を作るのは良い考えではない
    • 米国に住んでいるが、すべてのデバイスで IP ジオロケーションが間違った地域を指す
      こうしたデータベースほど日常的なインターネット体験を台無しにする技術も珍しい
      ただ消えてほしい
      ウェブサイトが毎回間違って推測し、修正フローを複数のリンクやページ読み込みの先に隠すのではなく、初回読み込み時に郵便番号を尋ねればよい
      さらに、データベースを直して「正解」や「より良い答え」を作る方法もない。ウェブサイトに現在地を使ってほしい場合がほとんどないからだ
      たいていは、これから行く場所の店舗在庫を確認している。この分野全体が 定義の誤った問題を解こうとしているようなものだ
    • 同じ苛立ちが大きかったので、関連する記事まで書いた: https://www.fer.xyz/2021/04/i18n

  • 用途と必要な精度によって異なる
    地理位置情報サービスを作る最良の方法は、自分の位置とIPを同時に報告する10億台のデバイスを確保すること。実質的にAppleとGoogleがこの立場にいる
    彼らはIPと位置情報の継続的な更新を受け取っているため、世界で最も優れた地理位置情報データベースを持っている
    要点は、人々が自発的に位置情報を提供するアプリを作り、そのアプリを多くの人に使わせること。だから最近はどのアプリも位置情報の権限を求める
    Foursquareは方向性としては正しかったが、早すぎた

    • 10年前でも、Apple内部のプライバシーポリシーは、Appleが精密な緯度/経度を収集することを禁じていた
      特定のIPやサブネットにどのエンドポイントが最適かを判断するためにHTTPセッションのテレメトリを使う必要があり、その結果として実際の条件に基づく独自のGeoIP類似データベースを作った
      それでもプライバシー保護のため、可能な限り一時的にしか保持できなかった。Apple Mapsの逆ジオコーディング結果は、近くのレストランを探すといったリアルタイムのユーザーリクエストの文脈外では、使用したり記録したりできなかった

  • 多少関連する話として、Google Mapsは地図上でどの位置を探索しているかに基づいてIPの位置を学習できる
    特定の位置を十分な回数見ると、Cookieをすべて削除してもGoogle Mapsを開いたときにその位置をデフォルト位置として使う
    Google Mapsを使っていて気づいたが、複数の人が同じIPアドレスを共有し得ることを考えると、プライバシー面で少し気がかりだ

    • 逆である可能性のほうが高そうだ。Googleは非常に優れたIP地理位置情報データベースを持っていて、ほかの情報がないときの探索位置にそれを使っているのだと思う
    • だから、ときどき自分がよくボートを漕ぐ川にいることになったり、またときどきは夏の別荘がある場所になったりするのだと思う
    • Google Workspaceとデータのローカライゼーション、法執行機関の管轄地域の判断にもこれを使っている

  • 興味深いが、実際の地理位置推定がこのように行われているわけではないと思う
    ARIN/RIPEデータは国レベルを超えると十分に正確ではなく、有用ではない
    商用の地理位置情報は、クライアントIPと既知の物理的位置を相関させる。たとえばWiFi AP情報や、ユーザーに送った宅配便のようなものだ。少なくとも何十年もそう聞いてきた

    • 広告技術分野で働いているが、地理位置情報はそのように扱っている
      デバイスの地理位置情報もあるが、ユーザーがGPSデータの共有に同意しない場合、ターゲティングにはIPアドレスだけを使う。一般的なプロバイダーはMaxMindで、ローカルにホストしてクエリするデータベースを配布している

  • コメント欄はかなり冷笑的な雰囲気だが、個人的には本当に興味深かった
    最初の職場でデータベースにPostGISと位置情報ベースの検索を追加していたことを思い出す。当時は住所と郵便番号に基づいていた

    • MySQLでも比較的簡単にできる。コツの一つは円ではなく正方形を使うことで、そうすると多くの数学的計算を避けられる

  • かなり昔にhttp://www.hostip.infoを作った。IPアドレスの位置をコミュニティ方式で集めるサービスで、「この推定は間違っていますか？修正してください」といった方式だった
    最後に確認したのはおそらく10年ほど前だが、国はほぼ完璧で、地域は不完全、都市はコイン投げよりはましという程度だった。すべてのデータは無料だ
    まだサイトにあるかは分からないが、既知のアドレスや最近の検索などを表示するための、回転する3Dキューブもあった。x、y、zはアドレスの先頭3オクテットで、国・大陸などのグループごとに色を変えていた
    あまりに古いのでJavaアプレットで書かれていた。作り直すならWebGLでやることになりそうだ
    かなり昔に売却したが、データは常に無料のままでなければならないという条件を付けた。最初はメールで来た提案が詐欺のように見えて信じなかったが、escrow.comを通じてうまく進み、双方とも満足いく形で終わったと思う。もうほぼ20年前のことだ

  • 先に出ていたpingベースのGeoIPの現代版に見える: https://github.com/Ne00n/yammdb

    • すでにコンパイル済みのmmdbファイルにリンクされているだけなので、実装が公開されていないなら、何であれ「現代的」な実装と見なせる関連内容はない

  • データセンターの IP を、かなり大まかにでも地理位置化する方法についての提案が知りたい
    traceroute データを分析していて、始点と終点の位置は分かっているが、関心があるのは中間区間
    例えば、ノードのホスト名に含まれる空港コードから一部の情報を推測できる
    特定ノードの状態が悪くないという前提なら、平均 RTT 時間から位置を推測することも可能そう
    厄介な例の IP は 193.142.125.129、129.250.6.113、129.250.3.250。英国の traceroute に現れ、ロンドンにあると見ているが、地理位置情報の結果は世界中に散らばる

    • これらの IP は Google と NTT の所有で、どちらも大規模な国際ネットワークを運用しているため、望めば IP を世界中に再配置できる。そのため、検索ベースの地理位置情報はすでに見たとおり不安定
      それらの IP への traceroute は、ネットワークがロンドンへ向かっているように見える
      Google の IP は ping に応答しないが、NTT/Verio 側は応答する。ロンドン拠点のホスティングから ping すれば 1 桁ミリ秒の応答になる可能性が高く、そうなればロンドンからの距離の上限を決められる
      英国内の別のホスティングや海峡の向こう側からも ping してみると、最小 ping がロンドンのホスティングから出るか確認できる。ただし、接続性がロンドン経由であるだけで、実際の位置は別の場所という可能性もあるため、完全には分からない
      ほかの観測地点でも確認し、エニーキャストでないかを見る必要がある。世界中のほとんどのネットワークから 8.8.8.8 に ping すると近い場所が返るが、これらの IP はシアトル地域からでも traceroute がロンドンへ向かうため、少なくとも現時点ではエニーキャストではない可能性が高い
      世界中にホスティングがないなら、ときどきこのような ping を試せる、接続性の良いネットワークの公開 looking glass を探すとよい
    • TULIP は有望に見えた
      「TULIP の目的は、位置がよく知られた基準ランドマークホストから対象までの ping RTT 遅延測定を用いて、IP 名またはアドレスで識別される対象ホストの位置を見つけること」とされている
      https://tulip.slac.stanford.edu/
      ただし、公開対象のエンドポイントは停止しているようだ
    • https://ensa.fi/papers/geolocation_imc17.pdf にいくつかアイデアがある
      既知の位置にある RIPE Atlas プローブから当該 IP までの RTT を取得する方法は、述べたアイデアに近く、いずれにせよ最善の方法である可能性が高い
    • 人気アプリや Web サービスを運営しているなら、自前の AS 番号を持ち、その AS 配下でいくつかの IP ブロックを購入して、世界各地の複数の所有・賃貸データセンターからそれらのアドレスを広告するだろう
      このような BGP 広告は、複数の場所にある異なる上位 ISP へ出ていく
      特定の場所から出た広告の上位が地域 ISP なら、そのデータセンターがその地域にあるとある程度推測できる。しかし、世界規模の直接接続を提供する Tier 1 ISP であれば、その推測すら難しい
      BGP 関係は bgp.tools のような looking glass ツールで確認できる: https://bgp.tools/prefix/193.142.125.0/24#connectivity
      世界中に散らばった既知位置の複数のプローブから traceroute を実行できれば、中間ルーターインターフェースの固定 IP を見て三角測量できる
      ただし Cloudflare のような CDN を使って自分の IP ブロックを 200 以上の PoP から広告し、そのプライベートネットワーク経由で世界中のデータセンターへ行かせると、この方法も破綻する