Назад | Перейти на главную страницу

IPv6 против IPv4 для геолокации

сначала отказ от ответственности: этот вопрос от новичка по теме IPv6.

На нашем веб-сервере изначально был активен IPv6, а Nginx неправильно настроен, поэтому пользователи с IPv6 получили сообщение об ошибке и веб-сайт не загрузился.

После настройки Nginx для прослушивания IPv6 веб-сайт загружается правильно, но для пользователей с IPv6 геолокация не выполняется (мы используем бесплатную базу данных Maxmind), тогда все они геолокации находятся в США.

Затем я отключил поддержку IPv6, и теперь, похоже, он работает хорошо, даже с клиентом, который использует IPv6, мой веб-сайт видит IPv4, а затем геолокализует его в нужной стране.

Тогда возникает вопрос:

После настройки Nginx для прослушивания IPv6 веб-сайт загружается правильно, но для пользователей с IPv6 геолокация не выполняется (мы используем бесплатную базу данных Maxmind), тогда все они геолокации находятся в США.

Убедитесь, что вы используете правильную базу данных. Некоторые предложения geoip имеют отдельные базы данных для IPv4 и IPv6 (AIUI с maxmind унаследованные продукты разделены на отдельные версии v4 и v6, а продукты geoip2 охватывают оба в одной базе данных).

Что на самом деле происходит, когда клиент IPv6 запрашивает мой сайт? Если у него тоже есть IPv4, то это лишает смысла иметь IPv6.

Следует учитывать разные типы клиентов.

  1. Только клиенты IPv4, которые могут использовать только IPv4 и не смогут получить доступ к вашему сайту, если он только v6.
  2. Правда IPv6 только клиенты. Они не смогут получить доступ к вашему сайту, если это только IPv4. Такие клиенты сейчас крайне редки.
  3. Традиционные клиенты с двойным стеком и IPv4, и IPv6. IPv4, вероятно, будет привязан к предварительным условиям и, скорее всего, также будет привязан к Интернет-провайдеру.
  4. Клиенты только IPv6, использующие шлюз DS-Lite на базе интернет-провайдера для доступа в Интернет IPv4.
  5. Клиенты только IPv6, использующие шлюз NAT64 / DNS64 на базе интернет-провайдера для доступа в Интернет IPv4.

Случаи 1 и 2 довольно очевидны.

В случаях 3 и 4 клиент, скорее всего, попробует и IPv4, и IPv6. Обычно, если он находит оба, он сначала пробует IPv6.

В случае 5 клиент будет использовать ваш IPv6-адрес, если запись существует. Если вы не предложите адрес IPv6, он будет использовать адрес IPv6, синтезированный шлюзом NAT64 / DNS64. Затем NAT64 преобразует трафик IPv6 от клиента в трафик IPv4 для отправки вам.

(что было из-за того, что у нас закончился IPv4)?

Первоначальная идея заключалась в том, чтобы перейти от версии 4 только к двойному стеку. Затем, когда все перешли на двойной стек, мы могли начать отключать IPv4. Была надежда, что это произойдет до того, как закончатся адреса IPv4.

Этого не произошло по многим причинам, включая стандарты «башни из слоновой кости», которые игнорировали реальность Интернета, и тот простой факт, что было трудно создать бизнес-обоснование для IPv6, когда никто другой этого не делал.

Итак, сейчас мы находимся в печальном положении: адреса IPv4 практически исчерпаны, но большая часть Интернета по-прежнему остается только IPv4.

Таким образом, интернет-провайдеры вынуждены что-то делать, чтобы обеспечить непрерывный рост в пост-истощенном мире со многими услугами, основанными только на IPv4. В основном у них есть три варианта.

  1. Традиционный NAT на уровне ISP (часто именуемый «NAT операторского класса»). Это может сопровождаться или не сопровождаться развертыванием двойного стека IPv6.
  2. DS-Lite. В этой системе пакеты IPv4 инкапсулируются (обычно CPE) и туннелируются к специальному NAT у провайдера. Этот NAT имеет расширенные таблицы сопоставления, которые определяют не только внутренний IP-адрес и порт, но также и IPv6-адрес, с которого пришел туннелированный трафик.
  3. NAT64 / DNS64. В этой системе сервер DNS64 интернет-провайдера синтезирует записи AAAA для имен хостов, которые не указывают на эти записи в поле NAT64. Затем сервер NAT64 преобразует клиентский трафик IPv6 в трафик IPv4.

Все эти варианты в конечном итоге сводятся к реализации механизмов, позволяющих совместно использовать адреса IPv4 между несколькими клиентами.

Насколько надежна геолокация на основе этого IPv4?

Геолокация всегда зависит от точности данных геолокации. По мере того, как адреса IPv4 становятся все более редкими, они, вероятно, будут перемещаться в большей степени, что снижает точность геолокации.

Кроме того, с помощью механизмов совместного использования IP пользователи в разных местах могут находиться за одним и тем же IP. База данных геолокации ничего не может с этим поделать.

Есть ли недостаток в том, что он не поддерживает IPv6?

Помимо вопросов о геолокации, здесь есть три основных момента.

  1. Производительность и надежность. Все механизмы, доступные интернет-провайдерам для обмена IPv4-адресами между несколькими пользователями, вероятно, снизят производительность и надежность. Насколько они сокращают их, зависит от того, насколько конкурентным является их развертывание у провайдера.
  2. Контроль над злоупотреблениями. Если все, что у вас есть, - это общие IPv4-адреса, становится намного сложнее отслеживать злоумышленников, чтобы либо запретить их, либо сообщить о них их интернет-провайдерам.
  3. Долгосрочное будущее. Прямо сейчас все еще существует достаточное количество контента только для версии 4, и интернет-провайдеры вынуждены предлагать своим пользователям механизмы доступа к контенту только для версии 4. Однако может наступить момент, когда количество контента только для версии 4 упадет настолько низко, что интернет-провайдеры больше не сочтут целесообразным поддерживать эти механизмы.

Если вам достаточно детализации на уровне страны, то вы можете просто положиться на whois. Не запрашивайте whois по каждому IP-адресу клиента, который вы видите. Когда вы видите новый IP-адрес и запрашиваете whois, затем кешируйте диапазон, чтобы будущие запросы IP-адресов в этом диапазоне не касались whois. Если вы не получаете ответа от whois, не пытайтесь использовать whois для того же / 32 в течение следующих 24 часов.

Если вам нужна более детальная детализация или если кэширование данных из whois сложнее, чем то, что вы хотите реализовать, вам нужно найти поставщика, который может предоставить вам доступ к таким данным для IPv6. Вам не обязательно использовать одного и того же провайдера для IPv4 и IPv6.

Для клиентов с IPv4 и IPv6 вы можете создавать свои собственные данные о соответствии между адресами. Как это можно сделать, было ответил раньше.

Если и клиент, и сервер поддерживают двойной стек, то клиент решает, использовать IPv4 или IPv6. С 2010 года считается лучшей практикой, когда клиенты стараются использовать самый быстрый или самый надежный из двух.

Есть клиенты с более надежным подключением IPv6, чем подключение IPv4. Если ваш сайт поддерживает только IPv4, эти клиенты сочтут ваш сайт ненадежным. Доля пользователей, для которых это так, будет продолжать расти.