Как работают сервисы IP-геолокации и почему ваш сервер «переезжает» в другую страну

Вы арендуете сервер во Франкфурте, заходите в панель, а какой-нибудь ipinfo.io уверенно пишет, что машина находится в Бухаресте. Или ещё веселее: MaxMind показывает Германию, IP2Location — Нидерланды, а Microsoft считает, что это Сингапур. Знакомая картина для всех, кто работает с хостингом. Ниже — подробный разбор того, как устроена IP-геолокация, откуда берутся ошибки и что с ними можно (и нельзя) сделать.

Почему IP-адрес сам по себе ничего не знает о географии

Важный момент, который часто упускают: в IP-адресе нет никакой информации о физическом местоположении. Это просто 32-битное (или 128-битное в случае IPv6) число — идентификатор узла в маршрутизируемой сети. Никакого поля «страна», никаких координат — ничего. Географическая привязка — это всегда внешняя, дополнительная информация, которую кто-то когда-то собрал и добавил в базу данных.

Отсюда следует простое, но важное: не существует одного «правильного» ответа на вопрос «где находится IP». Есть только набор баз данных, каждая из которых даёт свой ответ, и эти ответы могут расходиться — иногда на тысячи километров. Когда MaxMind пишет в документации, что координаты — это не точка, а область с радиусом, который может варьироваться от нескольких километров до 1000 километров, это не кокетство, а честное отражение природы данных.

Источники данных: откуда геолокационные сервисы берут информацию

Чтобы понимать, почему база ошибается, нужно знать, из чего она состоит. Типичный провайдер, например MaxMind, IP2Location, IPinfo, DB-IP или IPregistry, агрегирует несколько независимых источников и на их основе формирует свой ответ.

1. WHOIS/RDAP региональных интернет-регистратур (RIR)

Первый и самый старый источник — данные регистратур: RIPE NCC (Европа, Ближний Восток, Центральная Азия), ARIN (Северная Америка), APNIC (Азия и Океания), LACNIC (Латинская Америка), AFRINIC (Африка). Когда LIR (Local Internet Registry — как правило, ISP или хостер) получает блок адресов, он регистрирует его через объект inetnum (для IPv4) или inet6num (для IPv6) с полями country, org, иногда geoloc с координатами.

Проблема в том, что эти поля носят административный характер, а не технический. Поле country отражает страну регистрации организации — держателя блока, а не страну, где реально находятся серверы. Если немецкий LIR арендует /24 румынскому хостеру, который разместит IP на своих машинах в Бухаресте, в WHOIS ещё долго может оставаться country: DE. И многие геобазы это честно копируют.

Объект inetnum в RIPE может выглядеть примерно так:

inetnum: 203.0.113.0 - 203.0.113.255
netname: EXAMPLE-HOSTING-FRA
descr: Example Hosting GmbH - Frankfurt DC1
country: DE
geoloc: 50.110924 8.682127
geofeed: https://example-hosting.de/geofeed.csv
admin-c: EH123-RIPE
tech-c: EH123-RIPE
status: ASSIGNED PA
mnt-by: EXAMPLE-MNT
source: RIPE

2. BGP-маршрутизация и AS-данные

Второй сигнал — откуда префикс анонсируется в BGP. Если /24 появляется в глобальной таблице через AS какого-нибудь франкфуртского провайдера и апстримы видят его из европейских IXP, это сильный аргумент в пользу того, что блок используется в Европе. Геопровайдеры собирают BGP-дампы (RouteViews, RIPE RIS), смотрят на origin AS, путь префикса и точки пиринга — и делают выводы. Как справедливо отмечают в APNIC, тот, кто анонсирует префикс через BGP, фактически определяет, где он «виден»: если блок анонсируется из инфраструктуры в другой стране, сервисы геолокации и сетевые инструменты зафиксируют новое происхождение.

3. Активные измерения: задержка и триангуляция

Серьёзные провайдеры (особенно IPinfo со своей Probe Network, MaxMind, Google) запускают пинги и TCP-handshake к целевым адресам из множества точек по всему миру и триангулируют. Если из Амстердама RTT до IP — 3 мс, а из Нью-Йорка — 90 мс, адрес почти наверняка находится в Европе. Это даёт точность на уровне города для тех адресов, которые реально отвечают, но бессильно против CGNAT, anycast и машин с закрытым ICMP/TCP.

4. Reverse DNS / PTR-записи

Многие хостеры и ISP закладывают в PTR осмысленные имена: srv42.fra1.example-hosting.de, node-10.ams2.provider.net. Парсинг токенов вроде fra, ams, lax, sin — это дешёвый и на удивление надёжный сигнал на уровне города, когда оператор следит за именованием. Но если PTR не настроен или содержит нерелевантные данные (а на IPv6 это скорее правило, чем исключение), сигнал пропадает.

5. Пользовательские данные и телеметрия

Один из самых точных и при этом наименее очевидных источников — обратная связь от пользователей. Браузерные и мобильные SDK, имеющие доступ к GPS (с разрешения пользователя), отправляют координаты вместе с исходным IP. Операторы вроде Google используют это в масштабах миллиардов устройств — отсюда сверхточные данные Google Maps по геолокации IP. Партнёрские программы MaxMind и аналогов работают похоже: e-commerce передаёт адреса покупателей (billing/shipping), провайдер сверяет их с IP. Как отмечает сам MaxMind, данные геолокации основаны на расположении конечных пользователей IP-адресов или сетей там, где это возможно.

6. Geofeeds (RFC 8805) — самозаявление оператора

Относительно новый и технически самый чистый источник. О нём — отдельно ниже, потому что для хостера это главный инструмент исправления данных.

Почему конкретный хостинг-сервер может «стоять не там»

Теперь к главному. Причины, по которым ваш сервер в Цюрихе показывается в Варшаве, складываются из перечисленных выше сигналов: какие-то из них устарели, какие-то противоречат друг другу, а какие-то отсутствуют.

Свежевыделенный блок. Хостер только что получил /24 у RIR или купил его на вторичном рынке. WHOIS обновлён, но геопровайдеры обращаются к RIR не в реальном времени: кто-то — раз в неделю, кто-то — раз в месяц, а кто-то — нерегулярно. Пока сканирование не произошло, блок либо наследует старое значение (если это transfer), либо попадает в значение по умолчанию от RIR — центр соответствующего региона.

IP-трансфер между странами. Самый частый кейс в эпоху исчерпания IPv4. Литовский хостер продал свой /22 британскому, британский поднял на нём серверы в Лондоне — но MaxMind, IP2Location и другие ещё месяцами видят «LT». Это хорошо иллюстрирует типичный кейс: если литовская компания владела блоком и продала или переназначила его британскому провайдеру, WHOIS-запись может по-прежнему указывать "LT", пока кто-то не обновит её — и даже тогда многие сервисы геолокации не сразу распознают изменение. Типичный срок ожидания — от двух до восьми недель после того, как вы начнёте анонсировать блок и отправите correction requests. И даже это не даёт гарантии: Microsoft/Bing, например, живут на своём отдельном пайплайне обновлений, и жалобы на неправильную локацию их сервисов — постоянная тема на Microsoft Q&A.

Рассинхронизация между WHOIS и фактическим использованием. Классическая история: LIR зарегистрирован в Германии, но обслуживает дата-центр в Швейцарии. В inetnum указано country: DE, потому что это страна регистрации организации, а сервер стоит в Цюрихе. Без geofeed геопровайдер не узнает про Швейцарию и будет показывать DE — это, строго говоря, не ошибка WHOIS, а ошибка интерпретации.

Anycast. Один и тот же префикс физически присутствует в десятках точек по всему миру (DNS-корневые серверы, CDN, крупные публичные DNS вроде 1.1.1.1). MaxMind прямо говорит: для anycast-сетей геолокация не предоставляется — они не имеют фиксированного местоположения и могут обслуживать контент из любой точки мира. Если ваш хостер использует anycast для части услуг, такие IP технически «везде и нигде».

Устаревшие или расходящиеся базы у потребителя. Даже если мы всё исправили у провайдеров геолокации, конкретный сервис может использовать локальную копию базы, обновлённую год назад. Это частая ситуация, например, с GeoLite2.

Что это значит для вас как клиента

Геолокация IP — это оценка, а не точный факт.
Даже если сервер физически находится в одной стране, разные сервисы могут показывать разные локации. Это нормально и связано с тем, как устроены базы данных.

Исправление занимает время.
Даже если мы со своей стороны всё настроили корректно (WHOIS, geofид, маршрутизация), обновление данных в сторонних сервисах может занять от 2 до 8 недель.

Мы не можем напрямую управлять сторонними базами.
Сервисы вроде MaxMind, Google или Microsoft используют собственные алгоритмы и циклы обновлений. Мы можем отправлять запросы и публиковать корректные данные, но не можем мгновенно изменить их отображение.

Разные сервисы — разные результаты.
Если один сайт показывает «не ту» страну, это не значит, что с сервером что-то не так — скорее всего, у этого конкретного сервиса устаревшая или неточная база.

IP-геолокация не подходит для строгих ограничений.
Если речь идёт о доступе к контенту или региональных ограничениях, стоит учитывать, что IP-геолокация сама по себе не является надёжным механизмом.