Почему IPv6-адреса из дата-центров хуже проходят проверку, чем residential: анализ ASN и whois

Что видит антифрод, когда приходит пакет

Антифрод-система не смотрит на IP как на строку. Она разбирает его на слои: ASN, тип сети, геолокацию, историю, репутацию. Residential-адрес и адрес из дата-центра отличаются по всем этим параметрам сразу. И если IPv4-пул ещё можно как-то замаскировать, то с IPv6 всё сложнее — там префиксы выдают происхождение с первого взгляда.

Разберём, почему так происходит, и что с этим можно сделать.

Как устроена выдача IPv6 в дата-центрах

Провайдер получает от RIR (ARIN, RIPE, APNIC) блок. Минимальная аллокация для IPv6 — /32, а часто /29 или /28. Внутри этого блока хостер нарезает /48 или /64 клиентам. Один /32 — это 65 536 подсетей /48. Это создаёт проблему для репутационных баз: они не могут отследить каждый /64, поэтому помечают весь /32 как «хостинг».

Residential-провайдеры делают иначе. Comcast, Deutsche Telekom, Ростелеком выдают /56 или /64 конечным абонентам из динамических пулов. Эти префиксы меняются при переподключении, у них нет стабильной истории, и антифрод не может присвоить им устойчивый «плохой» скор.

Вот как выглядит типичный whois для дата-центра:

```

inet6num: 2a01:4f8::/32

netname: HETZNER-RZ-NBG-NET

descr: Hetzner Online GmbH

country: DE

org: ORG-HOA1-RIPE

admin-c: HOAC1-RIPE

tech-c: HOAC1-RIPE

status: ALLOCATED PA

mnt-by: RIPE-NCC-HM-MNT

created: 2005-06-06T00:00:00Z

```

`status: ALLOCATED PA` — это уже маркер. У residential-провайдеров чаще `ASSIGNED PA` с привязкой к конкретному региону и пулу абонентов.

ASN-классификация: как работает

Каждый IP принадлежит автономной системе. У ASN есть тип: ISP, Hosting, Business, Education, Government. Антифрод берёт этот тип из баз IP2Location, MaxMind, Spur, IPQualityScore. Дата-центровые ASN — Hetzner (AS24940), DigitalOcean (AS14061), OVH (AS16276), AWS (AS16509) — помечены как Hosting.

Вот простой скрипт, который показывает тип ASN для адреса:

```python

import requests

def check_ip(ip):

r = requests.get(f"https://ipinfo.io/{ip}/json")

data = r.json()

org = data.get("org", "")

asn = org.split()[0] if org else "unknown"

return {

"ip": ip,

"asn": asn,

"org": org,

"country": data.get("country"),

"city": data.get("city")

}

for ip in ["2a01:4f8:c17:b8f::1", "2607:f8b0:4004:c07::71"]:

print(check_ip(ip))

```

Для Hetzner получите `AS24940 Hetzner Online GmbH`. Для residential-провайдера — что-то вроде `AS8402 PJSC VimpelCom`. Разница видна сразу.

Проблема в том, что даже если вы купили residential-прокси, но он маршрутизируется через дата-центр (например, через туннель), ASN в заголовке пакета всё равно останется дата-центровым. Антифрод видит ASN из BGP-анонса, а не из вашей легенды.

Проверка через whois и RIPE Stat

Кроме ASN, антифрод смотрит на whois-записи. У residential-провайдеров в whois есть поле `descr` с упоминанием региона, часто — «Broadband», «DSL», «FTTH». У дата-центров — «Hosting», «Cloud», «Datacenter», «Colocation».

RIPE Stat даёт API для проверки:

```bash

curl -s "https://stat.ripe.net/data/as-overview/data.json?resource=AS24940" | jq '.data | {holder, announced}'

```

Ответ:

```json

{

"holder": "Hetzner Online GmbH",

"announced": true

}

```

`announced: true` означает, что ASN анонсирует префиксы в BGP. Это нормально для любого провайдера. Но если вы проверите `asn-neighbours`, увидите, что у дата-центров аплинки — это Tier-1 (Cogent, HE, Telia), а у residential — региональные ISP с меньшим количеством связей.

Геолокация IPv6: почему она врёт

IPv6-геолокация работает хуже IPv4. Причина — в архитектуре. IPv4-адреса распределены блоками /24, и каждый блок имеет историю. IPv6-префиксы /64 могут быть в разных городах одной страны, а базы геолокации обновляются медленно.

Пример: адрес `2a01:4f8:c17:b8f::1` (Hetzner, Nuremberg) в базе MaxMind определяется как Nuremberg, Germany. Но если вы арендуете VPS в Hetzner Falkenstein, геолокация может показать Nuremberg — разница 300 км. Для антифрода это красный флаг: пользователь заявляет один город, а IP показывает другой.

Residential-адреса привязаны к конкретному DSLAM или CMTS, и геолокация там точнее. Comcast в Чикаго даёт адреса с точностью до района.

Репутационные базы и их логика

Spur, IPQualityScore, Scamalytics используют комбинацию факторов. Для IPv6 они смотрят:

- Тип ASN (hosting vs ISP)

- Наличие в блоклистах (Spamhaus, SORBS)

- Историю абузов

- Количество активных портов (открытые 80, 443, 22)

- Наличие PTR-записи

Дата-центровые IPv6 часто не имеют PTR. Residential-провайдеры выдают PTR вида `c-24-1-1-1.hsd1.il.comcast.net`. Это ещё один маркер.

Вот как проверить PTR для IPv6:

```bash

dig -x 2a01:4f8:c17:b8f::1 +short

```

Если ответ пустой — антифрод добавит балл к риску.

Почему residential-прокси на IPv6 — редкость

Residential-провайдеры почти не выдают статические IPv6. Абонент получает /64 из динамического пула, и при переподключении префикс меняется. Это значит, что построить пул residential IPv6-прокси сложно: адреса нестабильны, их нельзя зарезервировать.

Большинство residential-прокси-сервисов работают на IPv4. IPv6 там — либо туннели через дата-центры (и тогда ASN выдаёт), либо мобильные операторы (где IPv6 есть, но пул ограничен).

Мобильные IPv6 — отдельная история. T-Mobile US, Verizon Wireless выдают IPv6 из больших блоков, и эти адреса часто проходят проверки лучше, чем дата-центровые. Но их мало, и они дорогие.

Кейс: проверка на Cloudflare

Сервер на Hetzner с IPv6 `2a01:4f8:xxx::1` пытается пройти проверку Cloudflare Turnstile. Turnstile смотрит на ASN, геолокацию и поведение. Если ASN — Hetzner, а браузер заявляет US-локаль, Turnstile выдаёт капчу.

Решение: использовать residential IPv4 или мобильный IPv6. Если IPv6 обязателен — брать адреса у провайдеров с ASN типа ISP, а не Hosting. Например, у немецкого Deutsche Telekom (AS3320) есть IPv6-блоки, которые проходят проверки лучше.

Но даже это не гарантия. Cloudflare обновляет базы каждые несколько часов, и если ASN попал в список подозрительных, все адреса из него получат повышенный скор.

Кейс: банк и геолокация

Банковское приложение проверяет IP при логине. Пользователь заходит с IPv6 `2600:1f18:xxx::1` (AWS us-east-1). Банк видит: ASN — Amazon, тип — Hosting, геолокация — Ashburn, Virginia. Пользователь заявляет Москву. Результат — блокировка и запрос на верификацию.

Причина: банк использует базу MaxMind с флагом `is_hosting: true`. Даже если пользователь реально в Москве, но сидит через AWS VPN, система не может это подтвердить.

Решение: использовать residential-прокси с ASN российского провайдера (Ростелеком, МТС). Тогда ASN будет ISP, геолокация совпадёт, и проверка пройдёт.

Кейс: антифрод интернет-магазина

Магазин на Shopify использует приложение для фрод-детекции. Покупатель оформляет заказ с IPv6 `2001:41d0:xxx::1` (OVH). Приложение проверяет:

- ASN: OVH (Hosting)

- Геолокация: Roubaix, France

- Billing address: New York, US

- PTR: отсутствует

Результат — заказ помечен как высокий риск. Магазин отменяет заказ, покупатель уходит.

Решение: если покупатель реально в США, но использует OVH VPN, ему нужно переключиться на residential-прокси. Или магазин должен настроить правила: игнорировать ASN-тип, если геолокация совпадает с billing address. Но это снижает защиту.

Как проверить свой IPv6 перед использованием

Перед тем как использовать IPv6 для важных задач, проверьте его по нескольким базам:

```bash

!/bin/bash

IP="2a01:4f8:c17:b8f::1"

echo "=== ASN ==="

curl -s "https://stat.ripe.net/data/prefix-overview/data.json?resource=\$IP" | jq '.data.asns'

echo "=== PTR ==="

dig -x \$IP +short

echo "=== IPInfo ==="

curl -s "https://ipinfo.io/\$IP/json" | jq '{org, country, city}'

echo "=== Spur ==="

curl -s "https://api.spur.us/v2/context/\$IP" -H "Token: YOUR_TOKEN" | jq '.'

```

Если ASN — Hosting, PTR пустой, а геолокация не совпадает с ожидаемой — адрес будет проблемным.

Что делать, если нужен IPv6, но residential недоступен

Вариантов немного. Первый — использовать IPv4 residential и не мучиться. IPv6 всё ещё не везде обязателен, и большинство антифрод-систем работают с IPv4 лучше.

Второй — искать провайдеров с ASN типа ISP, которые сдают IPv6 в аренду. Такие есть, но их мало. Например, некоторые европейские ISP предлагают IPv6-блоки для бизнеса с ASN, который не помечен как Hosting.

Третий — использовать мобильные IPv6. Они дороже, но проходят проверки лучше. Мобильные операторы часто имеют ASN типа ISP, и их адреса не так засвечены в блоклистах.

Если вам нужен IPv6-прокси с чистым ASN, lexic.ml даёт доступ к пулам, где ASN не помечен как Hosting. Это не residential в классическом смысле, но проходит проверки лучше, чем стандартные дата-центровые адреса.

Итог

IPv6 из дата-центров хуже проходит проверки по трём причинам: ASN помечен как Hosting, геолокация часто врёт, PTR отсутствует. Residential IPv6 — редкость из-за динамической выдачи префиксов. Если нужен чистый IPv6, ищите провайдеров с ASN типа ISP или используйте мобильные адреса. В остальных случаях IPv4 residential остаётся надёжнее.