Bir IP bloğunu yeni bir lokasyonda kullanmaya başladığınızda ya da başka bir ağdan devraldığınızda, kısa süre içinde şu tür bildirimler gelmeye başlayabilir: kullanıcılar bir yayın servisinde yanlış ülke kataloğunu görüyor, arama motoru sonuçları başka bir dilde çıkıyor, bir ödeme sağlayıcısı işlemleri şüpheli olarak işaretliyor. Bunların çoğunun arkasında aynı sorun vardır: IP konum veritabanları bloğunuzu yanlış yere yerleştirmiştir.
Geofeed, bu veritabanlarına “bu adresler aslında burada kullanılıyor” bilgisini standart ve makine tarafından okunabilir bir biçimde vermenin yoludur.
IP konum verisi nereden gelir?
Ticari IP konum sağlayıcıları, verilerini birçok kaynaktan birleştirir: RIR kayıtlarındaki ülke bilgisi, gecikme ölçümleri, kullanıcıların paylaştığı konum sinyalleri, ağ operatörlerinden gelen bildirimler. Bu kaynaklar bazen birbiriyle çelişir. Örneğin bir blok, kaydın bağlı olduğu kuruluşun ülkesinde görünürken fiilen başka bir ülkedeki veri merkezinde kullanılıyor olabilir.
Geofeed, operatörün doğrudan beyanıdır. Sağlayıcılar bu beyanı genellikle diğer sinyallerle karşılaştırarak kullanır; yani geofeed tek başına bir “komut” değil, güçlü bir girdidir.
RFC 8805 formatı
Geofeed, basit bir CSV dosyasıdır. Her satır bir prefix ve onun konumunu tanımlar. Alanlar sırasıyla şunlardır:
- Prefix: IPv4 ya da IPv6, CIDR gösterimiyle.
- Ülke: ISO 3166-1 alpha-2 kodu (
TR,GB,NL). - Bölge: ISO 3166-2 kodu (
TR-34,GB-LND). Boş bırakılabilir. - Şehir: Serbest metin. Boş bırakılabilir.
- Posta kodu: Tanımlı ancak kullanılması önerilmiyor; boş bırakın.
Örnek bir dosya:
# prefix,country,region,city,postal
192.0.2.0/25,TR,TR-34,Istanbul,
192.0.2.128/25,GB,GB-LND,London,
198.51.100.0/24,NL,NL-NH,Amsterdam,
2001:db8:100::/48,TR,TR-34,Istanbul,
2001:db8:200::/48,GB,GB-LND,London,
Dikkat edilmesi gerekenler:
#ile başlayan satırlar yorumdur.- Dosya UTF-8 kodlanmış olmalıdır. Şehir adlarında özel karakter kullanacaksanız kodlamayı kontrol edin; birçok operatör sorun çıkmaması için ASCII yazımı tercih eder.
- Aynı prefix’i iki farklı konumla tanımlamayın. Bir /24’ü ikiye bölüyorsanız, /24’ü değil iki /25’i yazın.
- Gereğinden fazla hassasiyet vermeyin. RFC 8805 de, bireysel kullanıcıların konumunu açığa çıkarabilecek ayrıntıdan kaçınmayı önerir. Sunucu blokları için şehir düzeyi genellikle yeterlidir; son kullanıcı ağlarında ülke ya da bölge düzeyinde kalmak daha doğrudur.
- Dosyayı HTTPS üzerinden, kararlı bir adreste yayınlayın.
Netlojik’in kendi geofeed dosyası, bu formatın gerçek bir örneği olarak https://netlojik.com/geofeed.csv adresinde yayınlanmaktadır.
RIPE kaydında geofeed: alanı
Geofeed dosyasını hazırlamak işin yarısıdır. Sağlayıcıların dosyanızı bulabilmesi ve ona güvenebilmesi için, dosya adresini adres bloğunun resmi kaydına eklemeniz gerekir. RFC 9632 bu bağlantıyı tanımlar; RIPE veritabanında inetnum ve inet6num nesneleri bunun için geofeed: alanını destekler:
inetnum: 192.0.2.0 - 192.0.2.255
netname: ORNEK-NET
country: TR
geofeed: https://example.net/geofeed.csv
mnt-by: ORNEK-MNT
source: RIPE
inet6num: 2001:db8::/32
netname: ORNEK-NET-V6
country: TR
geofeed: https://example.net/geofeed.csv
mnt-by: ORNEK-MNT
source: RIPE
Örnekteki 198.51.100.0/24 bloğu için de aynı geofeed: alanını taşıyan ayrı bir inetnum nesnesi olduğunu varsayıyoruz.
Bu yöntemin önemli bir avantajı var: Dosyanın sahibi, adres bloğunun kaydını yönetme yetkisine sahip olan taraf olarak doğrulanmış olur. Bir tüketici, geofeed dosyasındaki bir prefix’i ancak o prefix’i kapsayan inetnum nesnesi bu dosyayı gösteriyorsa kabul etmelidir. Kaydınızın kapsamı dışındaki satırlar yok sayılır.
Bazı eski kayıtlarda aynı bilgi remarks: Geofeed https://... biçiminde tutulur. Yeni kayıtlar için ayrı geofeed: alanını kullanmak daha temiz bir yöntemdir. Aynı nesnede ikisini birden kullanmayın.
Kaydı kontrol etmek için:
whois -h whois.ripe.net 192.0.2.0 | grep -i geofeed
Yayına almadan önce kontroller
Hatalı bir geofeed, hiç olmamasından daha kötü sonuç verebilir. Yayınlamadan önce birkaç basit kontrol yapın:
# Dosyaya HTTPS ile erişilebiliyor mu?
curl -sSf https://example.net/geofeed.csv | head
# Her satırda beş alan var mı?
grep -v '^#' geofeed.csv | awk -F, 'NF!=5 {print NR": "$0}'
# Ülke kodları iki harf ve büyük mü?
grep -v '^#' geofeed.csv | awk -F, '$2 !~ /^[A-Z][A-Z]$/ {print NR": "$0}'
Ayrıca dosyadaki her prefix’in, geofeed: alanını eklediğiniz inetnum/inet6num nesnelerinin kapsamında olduğundan emin olun.
Sağlayıcılar değişikliği ne zaman yansıtır?
Bu sorunun tek bir cevabı yok. Güncelleme süresi sağlayıcıya göre değişir: bazıları geofeed dosyalarını düzenli aralıklarla tarar, bazıları ise veritabanlarını belirli yayın döngüleriyle günceller. Bunun üzerine, sağlayıcı verisini kullanan servislerin (içerik platformları, reklam ağları, ödeme sistemleri) kendi kopyalarını ne sıklıkla yenilediği de eklenir. Dolayısıyla geofeed’i güncelledikten sonra değişikliğin tüm servislerde görünmesi zaman alabilir.
Süreci hızlandırmak için:
- Önemli IP konum sağlayıcılarının düzeltme formlarını kullanarak geofeed adresinizi ayrıca bildirin.
- Yeni bir blok devreye almadan önce geofeed ve RIPE kaydını güncelleyin; böylece blok kullanıma girdiğinde doğru konumun yayılma süreci zaten başlamış olur.
- Sorun belirli bir serviste sürüyorsa, o servisin destek kanalına geofeed adresinizi ve RIPE kaydını referans olarak iletin.
Bakım
Geofeed bir kez yazılıp unutulacak bir dosya değildir. Bir prefix yeni bir lokasyona taşındığında, bir blok iade edildiğinde ya da yeni bir blok eklendiğinde dosyayı da güncelleyin. Bu adımı IRR ve RPKI güncellemeleriyle birlikte, adres değişikliği kontrol listenizin bir parçası haline getirmek en sağlam yöntemdir.
Doğru bir geofeed, kullanıcılarınızın yanlış ülkeden geliyormuş gibi görünmesini tamamen önleyemez; ama sağlayıcılara en güvenilir kaynaktan, sizden, açık bir beyan sunar ve düzeltme sürecini tahmin yürütmekten çıkarır.
