Почему IPv6-адреса из "чистых" дата-центров всё равно палятся антифродом Google: анализ ASN и whois

Купил свежий IPv6-блок у хостера, который клянётся: "чистые адреса, никто не трогал". Проверяешь на ipqualityscore — fraud score 0. Заходишь в Google через прокси — капча. Welcome to reality. Антифрод Google давно не смотрит на репутацию отдельного IP. Он смотрит на ASN, whois-записи, BGP-анонсы и то, как ведёт себя весь префикс целиком.

Что реально проверяет антифрод Google

Google не выставляет оценку "хороший IP / плохой IP". Он строит граф связей. Узел — адрес. Рёбра — ASN, whois-контакты, регистрационные данные, поведенческие паттерны соседей по префиксу. Если твой /64 анонсируется из ASN, где сидят ещё 200 хостеров с историей сканирования портов, ты унаследуешь их репутацию. Даже если конкретно твой адрес никогда в жизни не выходил в интернет.

Это ключевой момент, который упускают. Репутация IPv6-адреса — не свойство адреса. Это свойство префикса, ASN и RIR-записи. Google склеивает их в один профиль риска. Свежий /48 из ASN, где 70% адресов — VPS-фермы, автоматически получает метку "low trust" ещё до первого запроса.

ASN как главный сигнал

Автономная система — это паспорт. Google смотрит на номер ASN, тип организации (hosting, ISP, business, education), размер анонсируемого префикса и возраст регистрации ASN в RIR. ASN, зарегистрированный три месяца назад через какого-нибудь reseller'а в Панаме, — красный флаг сам по себе. Не потому что там что-то плохое, а потому что статистически за такими ASN стоит 90% фрода.

Вот как выглядит базовая проверка через Team Cymru и whois:

```bash

whois -h whois.cymru.com " -v 2a01:4f8:1c1c:1234::1"

```

Ответ даст ASN, страну регистрации и префикс. Дальше — `whois` по ASN у RIPE или ARIN:

```bash

whois -h whois.ripe.net AS12345 | grep -E "org-name|country|created|descr"

```

Поле `created` — критичное. Если ASN зарегистрирован меньше года назад, а `org-name` — что-то вроде "CloudHost Solutions LLC", Google почти гарантированно отнесёт тебя к категории "datacenter / hosting". Для residential-трафика это приговор. Капча прилетит на первом же запросе к `accounts.google.com`.

WhoIs и обратная зона: где палится даже "чистый" блок

Хостер говорит "чистый блок". Открываешь whois — видишь abuse-c с email вида `abuse@cheapvps-panama.com`. Всё, приехали. Google матчит abuse-контакты с уже известными фрод-кластерами. Один и тот же abuse-c на 40 ASN — это не совпадение, это сеть перепродажи адресов.

Ещё хуже — обратная зона (PTR). У IPv6 PTR-записи живут в `ip6.arpa`. Если хостер не настроил PTR вообще, Google видит голый адрес без hostname. Для residential-адресов отсутствие PTR — норма. Для дата-центра — тоже норма, но это значит, что ты не можешь прикинуться домашним пользователем. Антифрод это знает.

Проверить PTR можно так:

```bash

dig -x 2a01:4f8:1c1c:1234::1 +short

```

Пустой ответ — сигнал "datacenter, no hostname". Настроенный PTR вида `vps-12345.hosting-provider.net` — сигнал "hosting". И только PTR вида `dynamic-pool-123.isp-name.ru` даёт шанс пройти как residential.

RIR-записи и возраст префикса

RIPE, ARIN, APNIC, LACNIC, AFRINIC — пять реестров. У каждого своя политика выдачи. Google парсит их базы. Ключевые поля: дата аллокации префикса, тип (ALLOCATED PA vs ASSIGNED PA), размер. Свежий /32, выданный в 2024 году, — это почти всегда hosting-провайдер или CDN. Residential-провайдеры получили свои блоки 10-15 лет назад.

Тут работает эвристика: чем моложе префикс и чем он крупнее, тем выше вероятность, что это инфраструктура для аренды. Residential-провайдеры не запрашивают /32. Они запрашивают /29 или /30 и раздают /56 клиентам. Дата-центры берут крупные блоки и дробят на /64 для VPS.

Поведенческие паттерны префикса

Даже если ASN чистый, whois идеальный, PTR настроен — Google смотрит на поведение всего /64. Если из соседних адресов идёт сканирование портов, спам-регистрации, автоматизированные запросы к API — весь префикс получает метку. Это не паранойя, это как работает rate limiting на уровне подсети.

Пример: хостер выдал тебе /64. В том же /48 сидят ещё 500 клиентов. Двое из них крутят парсеры Google Search, трое — регают аккаунты пачками. Через сутки весь /48 уходит в "elevated risk". Твои запросы начинают триггерить капчу, хотя ты ничего не делал. Это называется "collateral damage" в антифроде.

Кейс: свежий /64 из немецкого хостера

Пример: клиент арендовал /64 в Hetzner (AS24940), Франкфурт. Блок выдан в марте, до этого не использовался. Первый запрос к Google — капча. Проверяем ASN: AS24940, org-name "Hetzner Online GmbH", зарегистрирован в 2002. Вроде чисто. Но тип организации — hosting. Google видит "datacenter" и сразу повышает риск.

Причина — не репутация адреса, а категория ASN. Hetzner — хостинг-провайдер. Residential-трафик оттуда не идёт. Значит, любой запрос из AS24940 с высокой вероятностью — бот, парсер или прокси. Капча вылезает не потому что ты плохой, а потому что ты статистически подозрительный.

Решение: не пытаться пройти как residential из хостинга. Использовать ASN с типом "business" или "education", где доля реального трафика выше. Либо идти через residential-прокси, где ASN принадлежит ISP с домашними клиентами.

Кейс: IPv6 из "чистого" дата-центра в Нидерландах

Другой пример: /48 в AS49981 (WorldStream), Нидерланды. Хостер утверждает: блок новый, никто не использовал. Проверяем whois:

```

inet6num: 2a02:2b88:1:1::/48

org-name: WorldStream B.V.

country: NL

created: 2019-06-12

```

Дата создания — 2019, не свежак. Но `org-name` — hosting. И вот что интересно: abuse-c ведёт на тот же email, что и ещё 12 ASN. Это сеть перепродажи. Google это видит. Результат: капча на Google, блокировка на Cloudflare, повышенный риск на Facebook.

Причина — не сам адрес, а граф связей. Один abuse-c на 12 ASN = кластер. Кластер = фрод. Решение: искать ASN, где abuse-c уникален и не пересекается с другими хостингами. Таких мало, но они есть.

Кейс: residential IPv6, который всё равно палится

Пример: клиент взял residential IPv6 у ISP в Восточной Европе. ASN типа ISP, whois чистый, PTR настроен как `dynamic-pool-123.isp.net`. Первые два дня — всё ок. На третий день — капча. Проверяем: из соседнего /64 в том же /48 кто-то начал спамить. Весь /48 ушёл в бан.

Причина — shared reputation на уровне префикса. Residential-провайдеры часто выдают /56 клиентам, а /48 — это 256 клиентов. Если один из них фродит, страдают все. Google не разбирается, кто именно. Он банит префикс целиком.

Решение: использовать /64, изолированный от соседей. Либо менять префикс при первых признаках бана. Либо идти через прокси-пул, где префиксы ротируются.

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

Минимальный чек-лист. ASN: тип организации (hosting / ISP / business). WhoIs: возраст ASN, abuse-c, пересечения с другими ASN. PTR: наличие и формат. RIR: дата аллокации префикса. Поведение соседей: сканирование, спам, автоматизация.

Скрипт для базовой проверки:

```python

import subprocess

import re

def check_ipv6(ip):

result = subprocess.run(

["whois", "-h", "whois.cymru.com", f" -v {ip}"],

capture_output=True, text=True

)

lines = result.stdout.strip().split("\n")

if len(lines) < 2:

return None

parts = lines[1].split("|")

asn = parts[0].strip()

prefix = parts[2].strip()

country = parts[3].strip()

ripe = subprocess.run(

["whois", "-h", "whois.ripe.net", f"AS{asn}"],

capture_output=True, text=True

)

org = re.search(r"org-name:\s*(.+)", ripe.stdout)

created = re.search(r"created:\s*(.+)", ripe.stdout)

return {

"asn": asn,

"prefix": prefix,

"country": country,

"org": org.group(1).strip() if org else None,

"created": created.group(1).strip() if created else None

}

print(check_ipv6("2a01:4f8:1c1c:1234::1"))

```

Это даст базовый профиль. Дальше — ручной анализ: пересечения abuse-c, тип ASN, история префикса.

Почему "чистота" адреса ничего не значит

Чистота адреса — это маркетинг. Реальность: антифрод работает на уровне ASN, префикса и графа связей. Свежий /64 из hosting-ASN с общим abuse-c — это красный флаг, даже если адрес никогда не использовался. Google не проверяет каждый адрес отдельно. Он проверяет контекст.

Отсюда практический вывод: если нужен трафик, который не палится, — смотри не на "чистоту" IP, а на ASN, whois и поведение соседей. Дата-центры почти всегда палятся, потому что их ASN помечены как hosting. Residential-прокси работают лучше, но и там есть грабли: shared reputation на уровне /48.

Инфраструктура вроде lexic.ml даёт IPv6-прокси с ротацией префиксов, что частично решает проблему shared reputation. Но даже с ротацией — если ASN hosting, капча будет. Это не баг, это архитектура антифрода.

Что делать практически

Не покупать "чистые" IP у хостингов. Смотреть на ASN: тип организации, возраст, abuse-c. Проверять PTR и RIR-записи. Тестировать поведение соседей по префиксу. Если капча — менять не адрес, а ASN.

Residential-прокси с уникальными /64 работают лучше всего. Но их мало, они дорогие, и их тоже банят. Идеального решения нет. Есть компромисс: ротация префиксов + ASN с типом ISP + контроль поведения соседей. Всё остальное — лотерея.

Итог

Антифрод Google — это не проверка IP, а анализ графа. ASN, whois, PTR, RIR-записи, поведение префикса. "Чистый" адрес из hosting-ASN всё равно палится, потому что палится не адрес, а контекст. Хостеры продают "чистоту" как свойство IP. Реальность: это свойство инфраструктуры целиком.