Un IP non va “indovinato” dal whois di un vecchio database o da una dashboard che mostra una mappa colorata. Se devi capire a chi appartiene un indirizzo, in quale ASN ricade e in quale area geografica è plausibile collocarlo, il percorso serio è sempre lo stesso: parti dal registry, incroci con l’ASN, poi verifichi con un Looking Glass o con un traceroute controllato. Il punto non è trovare un’etichetta perfetta, ma costruire un’informazione abbastanza solida da reggere troubleshooting, anti-abuse, capacity planning e analisi di routing.
Registry, ASN e GeoIP non rispondono alla stessa domanda
La confusione nasce perché questi tre livelli sembrano dire tutti “da dove viene quell’IP”, ma in realtà descrivono cose diverse. Il registry ti dice chi ha ricevuto il blocco di indirizzi e con quali vincoli amministrativi. L’ASN ti dice chi annuncia quella rete in BGP e quindi chi la porta in Internet in quel momento. Il GeoIP è una stima probabilistica della posizione, utile per policy e reporting, ma non è una prova di domicilio fisico.
Questa distinzione evita errori classici: un IP assegnato a un operatore europeo può essere annunciato da un POP in un altro paese, oppure un blocco può risultare in un registry di una nazione ma terminare su una CDN con edge distribuiti. Se usi il GeoIP come fonte primaria per decisioni sensibili, finisci per bloccare utenti legittimi o per attribuire male il traffico. Se usi solo l’ASN, perdi la dimensione geografica. Se usi solo il registry, confondi assegnazione e routing reale.
Partire dal registry: il dato più noioso è spesso il più utile
Per un IP pubblico, il primo controllo deve essere sul database del registry regionale o sul database del RIR competente: RIPE NCC, ARIN, APNIC, LACNIC o AFRINIC. Il registro ti dà la prima fotografia amministrativa: range, organizzazione, stato del blocco, eventuale contatto tecnico e, talvolta, il riferimento all’ASN originario o al maintainer. È il miglior punto di partenza quando devi capire se un indirizzo appartiene davvero all’operatore che pensi tu.
Esempio pratico: un IP risolve verso un servizio in Italia, ma il registry indica un blocco assegnato a un operatore paneuropeo. Questo non è un errore: potrebbe essere un POP locale o una rete anycast. La domanda corretta non è “è in Italia?” ma “chi lo gestisce, con quale blocco, e chi lo annuncia oggi?”.
Per fare un controllo rapido da terminale puoi usare il whois del RIR o strumenti più moderni come RDAP, che espone dati strutturati e meno ambigui del vecchio output testuale. In molti casi conviene usare RDAP per automatizzare, e whois solo come fallback operativo.
Esempio RDAP:
curl -s https://rdap.arin.net/registry/ip/8.8.8.8 | jq '.name, .startAddress, .endAddress, .entities[].roles?'
Se non hai jq, puoi comunque ispezionare il JSON grezzo. L’obiettivo è verificare almeno: range, entità amministrativa e eventuali riferimenti a network handle o abuse contact. Se quei campi mancano, non inventare il resto: il gap va chiuso con il portale del registry o con un whois diretto sul RIR corretto.
Dall’ASN al routing reale: il BGP conta più della mappa
Una volta identificato il blocco, devi capire quale ASN lo annuncia. Qui il dato utile non è il nome commerciale del provider, ma l’origin ASN visto in BGP. È quello che ti dice chi sta realmente propagando il prefisso in quel momento. Se il prefisso è annunciato da più ASN per motivi di multihoming, traffic engineering o servizi anycast, devi leggere anche il contesto delle vie e non fermarti al primo match.
Per questo il Looking Glass è più affidabile di una ricerca casuale in un database GeoIP: mostra la vista di rete da un punto preciso dell’operatore. Ti consente di confrontare prefissi, next-hop, AS-path, community e, in certi casi, la presenza di route policy particolari. Se l’IP appartiene a una CDN o a un servizio distribuito, il Looking Glass spesso rivela subito il motivo per cui la geolocalizzazione sembra “sbagliata”.
Un controllo minimo da fare è tracciare il prefisso e verificare che il percorso BGP sia coerente con il provider o con il nodo atteso. Se hai un Looking Glass pubblico, cerca il prefisso e guarda la tabella di routing IPv4/IPv6. Se hai solo accesso a una macchina Linux, un traceroute o meglio un mtr ti danno almeno il profilo della latenza e i salti principali.
Esempio operativo:
mtr -rwzbc 20 8.8.8.8
traceroute 8.8.8.8
Qui non cerchi la “verità geografica”, ma una coerenza tecnica: il prefisso deve essere raggiungibile dal percorso che ti aspetti, con una latenza compatibile con il punto di presenza dichiarato. Se il percorso passa da un continente diverso, il GeoIP potrebbe essere corretto solo in parte o del tutto fuorviante per il tuo caso d’uso.
GeoIP: utile per policy, pericoloso come prova
Il GeoIP serve soprattutto per decisioni operative: localizzare contenuti, filtrare frodi, applicare regole di compliance, selezionare lingua o regione, scegliere un datacenter di fallback. Ma va letto come stima probabilistica. I database commerciali e open source non hanno la stessa qualità, e la qualità varia molto tra paesi, carrier, mobile network, CDN e cloud provider. Le reti mobili sono tra i casi peggiori: gli IP possono risultare in una città, mentre l’utente è altrove, o viceversa.
Se devi fare un controllo serio, confronta almeno due fonti GeoIP diverse e il riscontro di rete. Se due database discordano e il percorso BGP suggerisce un POP specifico, la rete vince sul dato geografico “cartografico”. Per il troubleshooting, il GeoIP va usato come indizio, non come fondamento.
Un modo pratico per ridurre gli errori è fissare una policy interna: il GeoIP decide solo quando la confidenza è alta e quando il rischio di falso positivo è basso. Altrimenti si passa a un controllo manuale con registry, ASN e Looking Glass. Questo è particolarmente importante nei sistemi di sicurezza, dove un geoblock sbagliato può impattare business e supporto clienti più di quanto risolva un abuso reale.
Flusso operativo consigliato per mappare un IP
Se devi farlo in modo ripetibile, usa sempre la stessa sequenza. È più lenta di una query singola, ma riduce gli errori di attribuzione.
Verifica il formato dell’indirizzo: IPv4 o IPv6, pubblico o privato, assegnato o non routabile. Un IP privato non ha senso in registry o GeoIP pubblico.
Interroga il registry corretto: RIR o RDAP. Conferma range, organizzazione, eventuale descrizione del blocco e contatti tecnici.
Estrai l’ASN origin: usa una vista BGP affidabile o un Looking Glass. Controlla se il prefisso è annunciato da un solo ASN o da più origini.
Confronta con GeoIP: verifica paese, regione e città su almeno una seconda fonte. Se la discrepanza è ampia, non forzare la conclusione.
Valida con un test di raggiungibilità:
mtr,traceroute, o query da un punto di osservazione vicino al target. Il percorso deve essere coerente con il tipo di rete.
Questa sequenza funziona bene anche quando devi classificare traffico sospetto. Un IP che arriva da un ASN di hosting noto, ma con GeoIP in un paese inatteso, può essere un proxy, una CDN o un nodo di uscita VPN. Non basta una sola etichetta per decidere se bloccarlo.
Looking Glass: cosa guardare davvero
Il Looking Glass è spesso usato in modo superficiale: si lancia un ping e basta. È poco. La parte utile è la vista del routing. Devi guardare prefisso, AS-path, next-hop, eventuali community e, se disponibili, informazioni su local-pref o policy di esportazione. Se il servizio è anycast, il prefisso può essere identico ma il percorso cambiare molto da un punto di osservazione all’altro.
Per un troubleshooting reale, il questionario è semplice: il prefisso è visibile? È visibile ovunque o solo in alcune regioni? Il path è stabile? Ci sono prepending, route leak o asimmetrie evidenti? Questi dettagli spiegano spesso perché un IP “sembra” in un paese ma risponde come se fosse altrove.
Quando il Looking Glass non è disponibile, puoi costruire un controllo parziale da una VPS in una regione diversa, ma va dichiarato come tale. Non è la stessa cosa di una vista dell’operatore. Se usi una VPS, annota il provider, la regione e il timestamp del test: senza questi dati il confronto perde valore.
Due casi tipici che fanno perdere tempo
Primo caso: CDN. Il registry mostra il blocco a un grande fornitore globale, l’ASN è quello della CDN e il GeoIP punta a una città diversa da quella attesa. Non è necessariamente un errore: il nodo più vicino all’utente può essere in un’altra regione, e l’edge decide in base al routing, non alla sede legale del cliente.
Secondo caso: cloud e IP elastici. Un IP può essere stato riciclato, riusato o spostato tra zone di disponibilità. Il database GeoIP può restare indietro per giorni o settimane. In questi casi il registry e l’ASN sono più affidabili della geolocalizzazione, ma devi comunque confermare con il percorso e con la proprietà del servizio.
Automatizzare senza perdere il controllo
Se devi fare questa attività su più IP, automatizza la raccolta ma non la conclusione. Un piccolo script può interrogare RDAP, estrarre il prefisso, fare una query a un servizio ASN e incrociare un database GeoIP locale. Però la decisione finale va basata su regole esplicite: dove la confidenza è alta, dove serve conferma umana, e dove il dato è troppo ambiguo per essere usato.
Un esempio minimale di pipeline è questo: RDAP per l’ownership, un database BGP per l’origin ASN, un database GeoIP locale per la stima geografica, e un Looking Glass per la verifica del path. Se uno dei quattro elementi manca, il report deve dirlo. Il silenzio su un campo mancante è peggio di un valore incerto.
# esempio concettuale: sostituisci l'endpoint con quello del tuo provider o del tuo tool interno
curl -s https://rdap.example.net/ip/203.0.113.10
whois -h whois.radb.net '!g203.0.113.0/24'
Se usi script interni, conserva i campi minimi in output: IP, prefisso, ASN, paese GeoIP, fonte, timestamp, esito del path check. Senza timestamp, un dato di rete vecchio vale poco. Senza fonte, non sai quanto fidarti. Senza prefisso, non puoi ricostruire la relazione con il routing.
Regola pratica per non sbagliare attribuzione
La regola è semplice: registry per la proprietà, ASN per il routing, GeoIP per la probabilità geografica, Looking Glass per la verifica sul campo. Se i quattro livelli concordano, hai una buona base. Se non concordano, non forzare una conclusione unica: documenta la discrepanza e indica quale layer è più affidabile per il caso d’uso specifico.
In pratica, questo approccio riduce errori in ticketing, abuse handling e analisi di incidenti. Ti evita anche di trasformare una semplice anomalia di geolocalizzazione in un falso incidente di routing. E quando il problema è davvero di rete, il percorso che hai raccolto ti aiuta ad arrivare prima al punto giusto: origin, edge, carrier o servizio a valle.
Se vuoi una sintesi operativa da tenere sul monitor: non fidarti mai di un solo database, non trattare il GeoIP come prova, e usa il Looking Glass per confermare quello che il registry e l’ASN suggeriscono. È meno “narrativo” di una mappa, ma molto più utile quando qualcosa va davvero verificato.
Commenti (0)
Nessun commento ancora.
Segnala contenuto
Elimina commento
Eliminare definitivamente questo commento?
L'azione non si può annullare.