Como criar um banco de dados de geolocalização de IP do zero

 (ipapi.is)
5 pontos por GN⁺ 2023-09-15 | 1 comentários | Compartilhar no WhatsApp
  • Um banco de dados de geolocalização de IP associa intervalos de IP a país, cidade, CEP, fuso horário e coordenadas; a ipapi.is oferece bancos de dados gratuitos em CSV e comerciais em CSV/MMDB
  • A edição gratuita não cobre todo o espaço IPv4 e IPv6 e também tem menor precisão, mas a edição comercial é o banco de dados completo usado no campo location da API e é atualizada pelo menos duas vezes por semana
  • Para construir um por conta própria, é preciso combinar geoloc e geofeed do WHOIS, inferência de localização a partir de campos de endereço e descrição do WHOIS, além de projetos públicos como RIPE IPmap, geofeed-finder e OpenGeoFeed
  • A precisão oscila quando uma rede está distribuída por várias regiões ou quando IPs são realocados ou alugados; em julho de 2023, a cobertura de geoloc no RIPE NCC era de 2,3% e a cobertura de URLs geofeed era de 0,17%
  • Os dados coletados exigem enriquecimento e normalização, como encontrar coordenadas a partir de cidade e país ou localizar a cidade mais próxima a partir das coordenadas; a ipapi.is usa arquivos de CEP, cidades e países do GeoNames

Estrutura de um banco de dados de geolocalização de IP

  • Um IP to Geolocation Database é um banco de dados que armazena informações de geolocalização por faixa de IP
  • Um endereço IP pode ser geolocalizado com as seguintes informações
    • país, cidade, estado, CEP
    • fuso horário
    • latitude, longitude
  • O banco de dados da ipapi.is é dividido em edição gratuita e edição comercial
    • a edição gratuita pode ser baixada em formato CSV
    • a edição comercial é oferecida nos formatos CSV e MMDB
    • a edição comercial cobre todo o espaço IPv4 e IPv6
    • a edição gratuita inclui apenas parte do espaço IPv4 e IPv6
  • O banco de dados comercial é atualizado pelo menos duas vezes por semana

Diferenças entre a edição gratuita e a comercial

  • O banco de dados gratuito de geolocalização de IP tem menos entradas do que a edição comercial e não cobre todo o espaço de endereços IPv4 e IPv6
  • A edição gratuita tem menor precisão de geolocalização
  • As principais fontes da edição gratuita são dados WHOIS e RFC 8805 Geofeeds
  • O banco de dados comercial é o banco completo usado no campo location da API da ipapi.is
  • A edição comercial calcula a localização combinando várias fontes
    • registros WHOIS
    • medições ativas de latência com base em ping e traceroute
    • RFC 8805 Geofeeds
    • consultas de DNS reverso

Formatos do banco de dados e campo de precisão

  • Os arquivos do banco de dados estão nos formatos CSV ou MMDB
  • Os principais campos incluem faixa de IP, localização, coordenadas e precisão
    • ip_version: 4 para IPv4, 6 para IPv6
    • start_ip, end_ip: IP inicial e final da faixa de rede
    • continent, country_code, country, state, city, zip
    • timezone, latitude, longitude
    • accuracy
  • accuracy indica a precisão estimada da informação de geolocalização em uma escala de 1 a 5
    • 1: precisão muito alta, geralmente confiável no nível de cidade
    • 2: precisão alta, normalmente confiável no nível de cidade
    • 3: precisão média, difícil de considerar confiável no nível de cidade
    • 4: precisão baixa, em geral precisa no nível de país
    • 5: precisão muito baixa, esperada apenas no nível de país

Como verificar uma amostra MMDB

Uso e limitações da geolocalização por IP

  • Geolocalização por IP é o processo de mapear um endereço IP para uma localização geográfica definida por latitude e longitude
  • Empresas online e provedores de serviços usam informações de geolocalização para diversos fins
    • publicidade segmentada
    • detecção e prevenção de fraude
    • localização de conteúdo
    • DRM e conformidade regulatória
    • segurança de rede
    • análise e insights
  • Há razões estruturais para a geolocalização por IP nem sempre ser precisa
    • redes IPv4 e IPv6 alocadas podem estar distribuídas geograficamente
    • há redes projetadas para abranger várias regiões, como redes móveis ou via satélite
    • a localização pode mudar quando um Regional Internet Registry ou uma empresa de aluguel de IP realoca ou reatribui uma rede IP
  • Geolocalizar endereços IP é complexo, mas pode oferecer um nível de precisão difícil de ignorar em uma API de endereços IP

O que é necessário para construir do zero

  • Cada endereço IP na internet é de propriedade ou administrado por uma organização específica
  • Regional Internet Registries (RIRs) como ARIN e APNIC armazenam informações de propriedade em bancos de dados WHOIS
  • Os registros WHOIS nem sempre incluem informações de geolocalização da rede alocada
  • A organização dona da rede pode usar os IPs em qualquer localização geográfica desejada, além de poder atribuí-los a terceiros ou alugar blocos de IP
  • A coleta de informações de geolocalização se divide em três frentes principais
    • extração de dados diretos de geolocalização, como geoloc e geofeed, dos registros WHOIS
    • inferência indireta de localização a partir de endereço postal, descrição e informações de país no WHOIS
    • uso de projetos públicos como RIPE IPmap, geofeed-finder e OpenGeoFeed

Dados diretos de geolocalização por RIR

  • RIPE NCC

    • Os objetos inetnum e inet6num do RIPE NCC alocam redes IP a organizações
    • As informações de geolocalização podem ser fornecidas por meio de dois atributos: geoloc e geofeed
    • geoloc armazena latitude e longitude como string
    • Exemplo: 47.855374 12.132041
    • Em julho de 2023, o banco de dados do RIPE NCC tinha 4.190.644 objetos inetnum e 819.381 objetos inet6num
    • Desses, 114.389 objetos incluíam o atributo geoloc, com cobertura total de 2,3%
    • geofeed contém a URL de um arquivo CSV no formato RFC 8805
    • A URL do geofeed pode ser registrada em um atributo dedicado geofeed ou no formato Geofeed {URL} dentro do atributo remarks
    • Em julho de 2023, o RIPE NCC tinha 6.643 URLs de geofeed em atributos remarks e 2.035 registros WHOIS com atributo geofeed
    • A cobertura de URLs de geofeed é de 0,17%, mas esse número pode ser enganoso, já que um único arquivo geofeed pode incluir várias redes

  • ARIN

    • O ARIN fornece informações de geolocalização colocando a URL do geofeed no atributo Comment do objeto NetRange
    • Houve pedido para adicionar um atributo geofeed dedicado, mas ele foi rejeitado sob a justificativa de que os atributos Comment ou Remark já eram suficientes
    • Ao contrário do RIPE NCC, o banco de dados do ARIN não usa o atributo geoloc

  • LACNIC

    • O LACNIC é mais ativo no suporte a geolocalização do que o ARIN
    • O LACNIC opera um Geofeed Service para que membros possam fornecer informações de geolocalização dos IPs que possuem
    • Os dados públicos estão disponíveis em milacnic.lacnic.net/lacnic/geofeeds
    • O banco de dados WHOIS do LACNIC fornece, por padrão, informações de geolocalização no nível de cidade
    • O banco de dados do LACNIC pode ser baixado do servidor FTP ftp.lacnic.net/lacnic/dbase/

  • AFRINIC e APNIC

    • A AFRINIC afirma não oferecer serviço de geolocalização nem manter relação oficial ou operacional com provedores de geolocalização
    • A AFRINIC, de forma semelhante ao RIPE NCC, permite o uso de URLs de geofeed no atributo remarks
    • O APNIC oferece suporte a geolocalização em nível quase igual ao do RIPE NCC
      • atributo geoloc
      • URL de geofeed no atributo remarks
    • O APNIC parece aberto a melhorar seu suporte a geolocalização

Como inferir localização a partir do WHOIS

  • O objetivo principal do WHOIS é fornecer informações cadastrais da organização proprietária de números da internet, como endereços IP e números AS
  • O WHOIS frequentemente inclui endereço postal e país da sede ou do local administrativo da organização
  • Em alguns casos, o endereço postal da organização coincide com o local de uso do IP, mas isso nem sempre acontece
  • O endereço administrativo de grandes organizações pode não corresponder à localização de todos os seus endereços IP

  • Inferência no RIPE NCC

    • Nos objetos inetnum e inet6num do RIPE NCC, os atributos utilizáveis são os seguintes
      • country: fornece apenas precisão no nível de país
      • descr: descrição da rede, podendo conter informações de localização ou endereço
      • netname: difícil de analisar e de baixa confiabilidade
      • address: tecnicamente é um atributo do objeto role e contém endereço postal
    • O atributo country identifica um código de país ISO 3166-2 em letras, mas não especifica se aquele país corresponde à sede, ao datacenter ou ao local do usuário final
    • O atributo descr é uma descrição em formato livre, mas pode ser útil para inferência de geolocalização quando a organização inclui localização e endereço da rede
    • address pode oferecer alta precisão, mas assumir que o endereço postal do objeto de função corresponde ao local de uso do IP pode causar erros

  • Inferência no ARIN

    • No ARIN, os seguintes atributos WHOIS são relativamente confiáveis para organizações pequenas ou concentradas em um único local
      • Address
      • City
      • StateProv
      • PostalCode
      • Country
    • Organizações como universidades, hospitais e órgãos governamentais podem usar os endereços IP do objeto NetRange no mesmo local do endereço postal administrativo
    • No caso de grandes empresas ou organizações nacionais com muitos NetRange, o endereço postal administrativo pode não coincidir com o local real de uso dos IPs
    • No exemplo do Google Fiber, usar o endereço do WHOIS aponta para Mountain View, California, mas a maioria dos provedores de geolocalização posiciona esse IP em San Antonio, Texas

  • LACNIC, AFRINIC e APNIC

    • O LACNIC fornece geolocalização no banco de dados WHOIS, então não é necessária inferência adicional
    • A AFRINIC usa o mesmo formato de banco de dados WHOIS do RIPE NCC, então os mesmos princípios podem ser aplicados
      • country, descr
      • address do objeto role
    • O APNIC também usa o mesmo formato de banco de dados WHOIS do RIPE NCC, então aplica os mesmos princípios

Projetos públicos de geolocalização

  • RIPE IPmap

    • O RIPE IPmap era uma API que fornecia dados de geolocalização da infraestrutura central da internet
    • Parece não ser mais mantido, e aparenta não receber novas contribuições desde 2019
    • O RIPE IPmap inferia a geolocalização de endereços IP com vários motores
    • Os motores latency e single-radius usavam medições do RIPE Atlas para fornecer um raio de latência de endereços IP
    • As medições de RTT mínimo fornecem um limite superior da distância máxima possível, por causa da velocidade da luz em fibra óptica
    • O motor reverse-dns extraía geolocalização em nível de cidade a partir do hostname do registro PTR
    • O banco de dados do RIPE IPmap pode ser baixado em https://ftp.ripe.net/ripe/ipmap/
    • Segundo o site do antigo mantenedor, a precisão e a cobertura do projeto caíram bastante

  • geofeed-finder

    • O geofeed-finder é uma ferramenta open source que descobre e coleta arquivos geofeed a partir de dados WHOIS
    • A ferramenta também faz verificação de propriedade de prefixo, gerenciamento de cache e validação de códigos ISO
    • Conforme a RFC 9092, é possível extrair geofeeds de dados WHOIS
    • Como a cobertura das informações de geofeed em toda a rede é muito baixa, a utilidade prática é limitada

  • LACNIC Geofeeds Service e OpenGeoFeed

    • O LACNIC Geofeeds Service fornece informações de geolocalização de uma parte considerável dos membros do LACNIC
    • Os dados podem ser baixados publicamente em milacnic.lacnic.net/lacnic/geofeeds
    • É um projeto importante por mostrar que é possível coletar geolocalização em nível de RIR
    • O OpenGeoFeed é um projeto open source que reúne geofeeds públicos próprios conforme a RFC 9092
    • O OpenGeoFeed oferece um arquivo único com geofeeds públicos conhecidos em opengeofeed.org/feed/public.csv
    • O OpenGeoFeed é promissor, mas a cobertura dos geofeeds não parece estar atualizada e é improvável que as fontes de dados sejam atualizadas com frequência

Enriquecimento e normalização dos dados

  • Os dados brutos de geolocalização coletados de várias fontes podem ser incompletos ou inconsistentes
  • Pode haver registros com informações de país e cidade, mas sem coordenadas, assim como registros com coordenadas, mas sem informações de país e cidade
  • Quando um registro bruto contém apenas o país, a precisão dificilmente ultrapassa o nível de país
  • Os dados coletados precisam ser enriquecidos e convertidos para um formato comum
  • O enriquecimento de dados é feito com bancos de dados geográficos open source
  • O trabalho de enriquecimento se divide em dois casos
    • encontrar latitude e longitude a partir do par cidade-país
    • encontrar a cidade e o país mais próximos a partir de latitude e longitude
  • A ipapi.is usa os seguintes bancos de dados para enriquecer informações de geolocalização

Leituras relacionadas

1 comentários

 
GN⁺ 2023-09-15
Opiniões do Hacker News

  • Eu já gostava de ler os artigos antes de entrar na IPinfo, e a IPinfo oferece um serviço de dados de geolocalização de IP
    Usamos uma metodologia mais ampla do que a descrita aqui; também utilizamos alguns conjuntos de dados públicos, mas os dados centrais de localização vêm de medições baseadas em ping
    Enviamos pings para endereços IP a partir de vários servidores pelo mundo e identificamos a localização por multilateração. Um ping a partir de um único servidor só fornece uma informação unidimensional — algo dentro de um certo raio —, mas, repetindo a partir de vários servidores, a localização vai ficando cada vez mais precisa
    Com medições suficientes, dá para chegar a uma precisão próxima ao nível de CEP; hoje temos mais de 600 servidores de detecção no mundo todo e continuamos aumentando esse número
    Dados públicos costumam estar desatualizados ou não ser atualizados com frequência, geralmente não são precisos o bastante para serem úteis e muitas vezes fornecem apenas a localização de grandes faixas de IP ou de organizações
    Além disso, conjuntos de dados públicos não têm processo de verificação. Com o aumento das negociações de IPv4 e dos serviços de VPN, já vimos casos de informações incorretas sendo injetadas; por isso, recebemos com gratidão relatos de correção de localização de IP, mas sempre verificamos
    Pela experiência de operar uma rede de detecção, é muito mais fácil e barato comprar servidores em Nova York do que em qualquer país da África Central. A localização de um endereço IP tem grande impacto no valor que esse IP pode oferecer
    Também fornecemos um banco de dados gratuito de IP-to-Country ASN que pode ser usado em projetos: https://ipinfo.io/developers/ip-to-country-asn-database

    • Fico curioso para saber de quais artigos você é fã. São os artigos de https://incolumitas.com/ ou os de https://ipapi.is/?
      A ideia de triangulação por latência é boa. Já usei informações de latência para várias finalidades, como detecção de VPNs e proxies, mas não imaginava que fosse possível obter uma localização tão precisa assim
      Com 600 servidores fazendo triangulação por latência, parece que dá para obter uma aproximação bem boa, e isso é impressionante
      Mas tenho algumas dúvidas. Como vocês lidam com o fato de alguns ISPs tratarem tráfego ICMP com baixa prioridade ou degradarem seu desempenho? Para geolocalizar todo o IPv4, seria preciso ficar enviando pings continuamente para bilhões de endereços; vocês medem apenas um IP aleatório em cada inetnum/NetRange alocado? Como a maioria dos endereços IP não responde a ICMP, vocês encontram o roteador à frente do destino e determinam a localização desse roteador?
    • Endereços anycast são difíceis de “localizar” pelo tempo de resposta ICMP, e alguns têm uma localização lógica associada separadamente. Um exemplo pode ser visto em https://blog.cloudflare.com/icloud-private-relay/
    • Como fã e cliente da IPinfo, uso a API para colocar em e-mails de alerta de login frases como “Você acabou de fazer login em Berlim, Alemanha. Se não foi você, clique aqui”
      Também usamos para fornecer dados de país em logs de auditoria de clientes, além de prevenção de spam e detecção de fraudes
    • Fico curioso se vocês já consideraram disponibilizar o download do banco de dados em formato Parquet
      Assim seria possível copiar o arquivo para S3, Google Cloud etc. e consultá-lo diretamente com várias ferramentas. Com CSV também dá, mas não é tão fluido
    • Eu tinha curiosidade sobre como descobrir a localização de um endereço IP quando não há fontes de informação existentes, e esta explicação era exatamente o que eu queria saber; é muito interessante

  • Se você não quiser implementar por conta própria, dá para fazer a Cloudflare fazer isso de graça com um Cloudflare Worker simples. Todas as requisições da Cloudflare incluem informações aproximadas de localização do IP
    Você também pode enviar uma requisição para esta URL operada por um Cloudflare Worker. A latência deve ser baixa globalmente: https://www.edenmaps.net/iplocation
    Para apps pequenos, tudo bem usar, só peço para não mandar 10 milhões de requisições por dia

    • É melhor baixar e usar um banco de dados de IPs do que compartilhar com terceiros quais endereços IP podem ter acessado o serviço
    • Diz que estou a 100 km da costa da Somália, mas na verdade estou em Bruxelas, Bélgica. Obrigado pela privacidade :D
    • Fico curioso se alguém sabe quão precisa é a geolocalização da Cloudflare nas requisições do Worker
    • Excelente. Se possível, fico curioso se você poderia disponibilizar esse código como open source
    • Estou em Munique, mas a Cloudflare aponta para uma floresta aleatória 730 km ao norte

  • Moro em um país cuja língua local não é minha língua materna, então odeio sites que inferem o idioma pela localização do IP e o impõem à força
    Mesmo quando o navegador envia o cabeçalho de idioma de forma muito clara, eles o ignoram e escolhem o idioma com base em uma suposição preguiçosa

    • Trabalho em um serviço de geolocalização de IP, mas também odeio isso
      No setor, chamam isso de “personalização da experiência web”, mas é uma forma irritante de fazer as coisas. Nunca recomendei que ninguém fizesse isso
      Se for personalizar um site por geolocalização de IP, o melhor uso é algo como impostos, frete ou colocar o país do usuário no topo de um menu suspenso de seleção de país
      Fora isso, quase nada me vem à cabeça. Tradução geralmente não funciona bem e só atrapalha. Mesmo que o site tenha boas intenções, criar uma versão no idioma local com Google Translate não é uma boa ideia
    • Moro nos EUA e, em todos os meus dispositivos, a geolocalização por IP aponta para regiões erradas
      Poucas tecnologias estragam tanto a experiência cotidiana na internet quanto esses bancos de dados
      Eu queria que simplesmente desaparecessem
      Em vez de o site chutar errado toda vez e esconder o fluxo de correção atrás de vários links e carregamentos de página, ele poderia perguntar o CEP no primeiro carregamento
      Além disso, não há como corrigir o banco de dados para criar a “resposta certa” ou uma “resposta melhor”, porque quase nunca quero que o site use minha localização atual
      Normalmente estou verificando o estoque de uma loja em um lugar para onde vou depois. Essa área inteira está tentando resolver um problema mal definido
    • Fiquei tão frustrado com a mesma coisa que até escrevi um texto sobre isso: https://www.fer.xyz/2021/04/i18n

  • Depende do uso e da precisão necessária
    A melhor forma de criar um serviço de geolocalização é ter 1 bilhão de dispositivos informando ao mesmo tempo a própria localização e o IP. Na prática, Apple e Google estão nessa posição
    Como eles recebem atualizações contínuas de IP e localização, têm os melhores bancos de dados de geolocalização do mundo
    O ponto central é criar um app em que as pessoas forneçam a localização voluntariamente e fazer muita gente usar esse app. É por isso que hoje em dia todo app pede permissão de localização
    O Foursquare estava na direção certa, mas chegou cedo demais

    • Mesmo há 10 anos, as políticas internas de privacidade da Apple impediam a empresa de coletar latitude/longitude precisas
      Era preciso usar telemetria de sessões HTTP para determinar qual endpoint era ideal para um IP ou sub-rede específicos, e isso resultou em um banco de dados próprio, semelhante ao GeoIP, baseado em condições reais
      Ainda assim, por questões de privacidade, isso precisava ser mantido apenas de forma tão temporária quanto possível. Os resultados de geocodificação reversa do Apple Maps não podiam ser usados nem registrados fora do contexto de solicitações de usuários em tempo real, como encontrar restaurantes por perto

  • Em uma história um pouco relacionada, o Google Maps pode aprender a localização de um IP com base nos lugares que você explora no mapa
    Se você olha uma determinada localização vezes suficientes, mesmo apagando todos os cookies, ao abrir o Google Maps ele usa esse lugar como localização padrão
    Percebi isso usando o Google Maps e, considerando que várias pessoas podem compartilhar o mesmo endereço IP, isso é um pouco preocupante do ponto de vista de privacidade

    • Parece mais provável que seja o contrário. O Google tem um banco de dados de geolocalização por IP muito bom e, quando não há outras informações, parece usar isso como localização de navegação
    • Por isso, às vezes ele diz que estou no rio onde costumo remar, e às vezes no lugar onde fica a casa de verão
    • Eles também usam isso no Google Workspace, em localização de dados e para determinar a jurisdição de órgãos de aplicação da lei

  • É interessante, mas não acho que a geolocalização real seja calculada assim
    Dados da ARIN/RIPE não são precisos o suficiente além do país, então não são úteis
    Geolocalização comercial correlaciona o IP do cliente com uma localização física conhecida. Por exemplo, informações de APs Wi-Fi ou encomendas enviadas ao usuário. Pelo menos é isso que ouço há décadas

    • Trabalho na área de ad tech, e é assim que tratamos geolocalização
      Também há geolocalização do dispositivo, mas, se o usuário não consentir em compartilhar dados de GPS, usamos apenas o endereço IP para segmentação. Um provedor comum é a MaxMind, que distribui um banco de dados para hospedar localmente e consultar

  • Os comentários estão em um tom bastante cínico, mas pessoalmente achei isso muito interessante
    Me lembrou de quando, no meu primeiro emprego, adicionei PostGIS e busca baseada em localização a um banco de dados. Na época, era baseado em endereços e CEPs

    • Também dá para fazer isso de forma relativamente simples no MySQL. Um truque é usar quadrados em vez de círculos, o que evita muitos cálculos matemáticos

  • Há bastante tempo criei http://www.hostip.info. Era um serviço que coletava localizações de endereços IP de forma comunitária, algo como “esta estimativa está errada? Corrija aqui”
    A última vez que verifiquei foi provavelmente há uns 10 anos: o país era quase perfeito, a região era incompleta, e a cidade era melhor do que cara ou coroa. Todos os dados são gratuitos
    Não sei se ainda está no site, mas havia também um cubo 3D giratório para mostrar endereços conhecidos ou consultas recentes. x, y, z eram os três primeiros octetos do endereço, e as cores variavam por grupos como país e continente
    Era tão antigo que foi escrito como um applet Java. Se eu refizesse hoje, provavelmente usaria WebGL
    Vendi há muito tempo, mas coloquei como condição que os dados deveriam permanecer sempre gratuitos. No começo, não acreditei na proposta por e-mail porque parecia golpe, mas tudo correu bem via escrow.com e acho que terminou de forma satisfatória para os dois lados. Isso já faz quase 20 anos

  • Parece uma versão moderna do GeoIP baseado em ping mencionado antes: https://github.com/Ne00n/yammdb

    • Como ele apenas se conecta a um arquivo mmdb já compilado, se a implementação não for pública, não há nada ali que dê para considerar uma implementação “moderna”

  • Tenho curiosidade sobre propostas de métodos para geolocalizar IPs de datacenters, mesmo que de forma bem aproximada
    Estou analisando dados de traceroute e conheço os locais de início e fim, mas o que me interessa são os trechos intermediários
    Por exemplo, é possível inferir algumas informações a partir de códigos de aeroportos presentes no hostname de um nó
    Partindo do pressuposto de que um determinado nó não está em mau estado, também parece possível inferir a localização pelo tempo médio de RTT
    Alguns exemplos de IPs problemáticos são 193.142.125.129, 129.250.6.113 e 129.250.3.250. Eles aparecem em traceroutes no Reino Unido e eu os considero em Londres, mas os resultados de geolocalização ficam espalhados pelo mundo todo

    • Esses IPs pertencem ao Google e à NTT, e ambos operam grandes redes internacionais, então, se quiserem, podem realocar IPs pelo mundo todo. Por isso, a geolocalização baseada em consultas é instável, como você já viu
      Os traceroutes para esses IPs parecem indicar que a rede vai para Londres
      O IP do Google não responde a ping, mas o lado da NTT/Verio responde. Se você pingar a partir de uma hospedagem baseada em Londres, há grande chance de obter resposta em poucos milissegundos, e isso permitiria definir um limite superior para a distância a partir de Londres
      Também dá para pingar a partir de outras hospedagens dentro do Reino Unido e do outro lado do Canal da Mancha para verificar se o menor ping vem de uma hospedagem em Londres. Ainda assim, pode ser que a conectividade apenas passe por Londres e a localização real seja outra, então não dá para saber com total certeza
      É preciso verificar também a partir de outros pontos de observação para ver se não é anycast. Ao pingar 8.8.8.8 a partir da maioria das redes no mundo, você chega a um local próximo, mas esses IPs também têm traceroute indo para Londres a partir da região de Seattle, então, pelo menos atualmente, é bem provável que não sejam anycast
      Se você não tiver hospedagem pelo mundo todo, pode procurar looking glasses públicos de redes bem conectadas que permitam fazer esse tipo de ping ocasionalmente
    • O TULIP parecia promissor
      Ele diz que “o objetivo do TULIP é localizar um host de destino, identificado por nome ou endereço IP, usando medições de atraso RTT de ping de hosts de referência, ou landmarks, cujas localizações são bem conhecidas até o destino”
      https://tulip.slac.stanford.edu/
      Mas o endpoint publicado parece estar morto
    • Há algumas ideias em https://ensa.fi/papers/geolocation_imc17.pdf
      Obter o RTT até esse IP a partir de probes do RIPE Atlas em locais conhecidos é próximo da ideia mencionada e, de todo modo, provavelmente é o melhor método
    • Se você opera um app ou serviço web popular, teria seu próprio número AS e compraria alguns blocos de IP sob esse AS, anunciando esses endereços a partir de vários datacenters próprios ou alugados pelo mundo
      Esses anúncios BGP sairiam por provedores upstream diferentes em vários locais
      Se o upstream de um anúncio vindo de um local específico for um ISP regional, dá para estimar, em certa medida, que esse datacenter está naquela região. Mas, se for um ISP Tier 1 que oferece conectividade direta global, até essa estimativa fica difícil
      As relações BGP podem ser vistas em ferramentas de looking glass como bgp.tools: https://bgp.tools/prefix/193.142.125.0/24#connectivity
      Se for possível executar traceroutes a partir de vários probes de localização conhecida espalhados pelo mundo, dá para triangular observando os IPs fixos das interfaces dos roteadores intermediários
      Porém, se você usar uma CDN como a Cloudflare para anunciar seu bloco de IP em mais de 200 PoPs e encaminhar o tráfego pela rede privada deles até datacenters no mundo todo, esse método também deixa de funcionar