Как антибот-системы палят IPv6 /64 при мультиаккаунтинге

Почему /64 — это не «много адресов», а один отпечаток

Провайдер выдаёт клиенту /64 на роутер. Внутри — 2^64 адресов. Кажется, что можно наделать миллион «разных» клиентов и никто не заметит. Антибот видит другое: все они приходят из одного префикса.

С точки зрения маршрутизации /64 — минимальная единица для SLAAC. С точки зрения антифрода — это как один дом, только квартир много. Cloudflare, Akamai, Datadome, Imperva давно научились агрегировать IPv6 по префиксу и сравнивать не отдельные адреса, а подсети.

Проверить, что у вас именно так, просто:

```bash

curl -s https://api64.ipify.org

curl -6 -s https://ipv6.ident.me

ip -6 addr show scope global | grep inet6

```

Если два адреса отличаются только в младших 64 битах — антибот уже видит их как одну сущность.

Что конкретно смотрит антибот

Первое — префикс в заголовках. X-Forwarded-For, CF-Connecting-IP, True-Client-IP содержат полный адрес, но бэкенд режет его до /64 и складывает в корзину. Второе — TLS-отпечаток (JA3/JA4). Третье — набор заголовков Accept-Language, User-Agent, порядок HTTP/2-фреймов.

Дальше идёт корреляция. Если с одного /64 за 10 минут пришло 200 регистраций с разными адресами, но одинаковым JA4 — это красный флаг. Даже если каждый адрес уникален.

```python

import ipaddress

def prefix64(addr):

ip = ipaddress.ip_address(addr)

if isinstance(ip, ipaddress.IPv6Address):

net = ipaddress.ip_network(f"{addr}/64", strict=False)

return str(net.network_address)

return addr

print(prefix64("2a00:1450:4001:82b::1"))

print(prefix64("2a00:1450:4001:82b::dead:beef"))

```

Оба вывода — `2a00:1450:4001:82b::`. С точки зрения антибота это один клиент.

Кейс: регистрация на маркетплейсе через /64

Сервер на nginx 1.24 проксирует запросы к бэкенду и передаёт `X-Real-IP` как полный IPv6. Бэкенд на Python (FastAPI 0.110) пишет в лог полный адрес. Антифрод-модуль считает `ipaddress.ip_network(ip + "/64")` и группирует.

Проблема: за сутки с одного /64 зарегистрировалось 340 аккаунтов. Все с разными адресами внутри префикса. Все прошли капчу. Все использовали разные User-Agent. Но антифрод выдал бан по всему /64 через 6 часов.

Причина — не в адресах. В том, что TLS-сессия шла через один и тот же прокси-сервер с одинаковым набором шифров, а HTTP/2-приоритеты совпадали до байта. Плюс все запросы приходили в одну и ту же секунду каждой минуты — бот не рандомизировал тайминг.

Решение: разнести трафик по разным /64 от разных провайдеров, рандомизировать задержки в диапазоне 800–4000 мс, использовать разные TLS-стеки (curl, requests с urllib3, Go net/http). Это уже не «маскировка адреса», а маскировка поведения.

Почему NAT и прокси не спасают

Классический IPv4-прокси решает проблему одним адресом — один клиент. С IPv6 сложнее: если прокси выдаёт клиенту /64, то все его соединения всё равно приходят с одного префикса. Антибот видит префикс, а не отдельный адрес.

Многие «IPv6-прокси» на рынке дают именно /64 на аккаунт. Это лучше, чем один адрес, но всё равно одна подсеть. Если антибот агрегирует по /64 — вы попались. Если агрегирует по /56 или /48 — попались дважды.

Вот тут и появляется смысл в сервисах, которые выдают именно отдельные префиксы с гарантией, что соседние /64 не принадлежат другим клиентам. Один из таких — lexic.ml, где /64 выдаётся как изолированная единица маршрутизации, а не как «один адрес из пула». Проверить изоляцию можно так:

```bash

for i in 1 2 3; do

curl -6 --interface "eth0" -s https://api64.ipify.org

sleep 1

done

```

Если три запроса вернули три разных /64 — изоляция работает. Если один /64 — это тот же пул.

Агрегация по /56 и /48 — что это меняет

Провайдеры выдают клиентам /56 (256 подсетей /64) или /48 (65536 подсетей /64). Антиботы это знают. Cloudflare, например, в своих правилах WAF позволяет указать `ip.src in {2a00:1450::/32}` — и это отсечёт весь диапазон.

Если антибот агрегирует по /56, то десять разных /64 внутри одного /56 — это один клиент. Маскировка на уровне /64 бесполезна. Нужно проверять, какой префикс у вас в руках:

```bash

whois -h whois.ripe.net 2a00:1450:4001:82b::1 | grep -E "inet6num|route6"

```

Вывод покажет, что за диапазон закреплён за вами. Если это /48 — у вас 65536 подсетей /64, можно раскидать тысячи аккаунтов без пересечения.

Как строится отпечаток префикса

Антиботы собирают не только сам адрес. Они смотрят на ASN, на обратную зону DNS (PTR), на MTU и на поведение ICMPv6. Если у вас 500 адресов из одного /64, но у всех одинаковый PTR-шаблон — это палево.

Ещё один маркер — TCP timestamps и window size. У реальных пользователей они разные. У ботов, запущенных с одного сервера — одинаковые. Если вы гоняете трафик через один прокси, антибот увидит одинаковый TCP-стек у всех «клиентов».

```python

import socket

def tcp_fingerprint(host, port=443):

s = socket.socket(socket.AF_INET6, socket.SOCK_STREAM)

s.settimeout(3)

s.connect((host, port))

opts = s.getsockopt(socket.IPPROTO_TCP, socket.TCP_INFO, 104)

s.close()

return opts.hex()[:32]

print(tcp_fingerprint("example.com"))

```

Сравните отпечатки с двух разных машин — увидите разницу. С одного прокси — совпадение.

Маскировка префикса: что реально работает

Первое — разные /64 из разных /48. Если у вас один /48, раскидывайте аккаунты по разным /64 внутри него, но не более 3–5 на одну /64. Второе — разные ASN. Если все адреса из одной AS, антибот это видит мгновенно.

Третье — рандомизация поведения. Разные TLS-библиотеки, разные задержки, разные наборы заголовков. Это дороже, чем купить новый префикс, но без этого даже идеальный /64 не спасёт.

```bash

curl -6 --interface 2a00:1450:4001:82b::1 -s https://httpbin.org/ip

curl -6 --interface 2a00:1450:4001:82b::2 -s https://httpbin.org/ip

```

Оба запроса придут с одного /64. Антибот это увидит. Если нужны разные /64 — нужны разные интерфейсы или разные прокси.

Кейс: парсер маркетплейса на 2000 запросов/час

Парсер на Python (requests 2.31, urllib3 2.2) ходил через один /64. Скорость — 2000 запросов в час, задержка 300 мс. Через 40 минут — 403 на всё. Проверка показала: Cloudflare заблокировал /64 целиком по правилу «rate limit > 500 req/min» с агрегацией по /64.

Причина — не в количестве адресов. Парсер использовал один и тот же набор заголовков и одну TLS-сессию. Cloudflare сгруппировал по префиксу и посчитал суммарный RPS.

Решение: раскидать по 20 разным /64, ограничить 100 запросов в минуту на /64, добавить jitter 200–1500 мс, менять User-Agent и Accept-Language на каждом /64. После этого — 18 часов без бана.

Кейс: мультиаккаунтинг в соцсети

Соцсеть (условно, VK) на 50 аккаунтов. Все — с одного /64, разные адреса, разные браузерные отпечатки через антидетект. Через 3 дня — блокировка 12 аккаунтов. Причина — соцсеть агрегирует по /64 и смотрит на поведенческие паттерны: одинаковое время активности, одинаковые лайки.

Технические детали: соцсеть хранит `ip_prefix` в своей БД как `inet` с маской /64, индексирует по нему и при превышении порога (например, 10 аккаунтов на /64) запускает ручную проверку.

Решение: 5 аккаунтов на /64, разные /48, рандомизация активности. Плюс — разные часовые пояса в профилях, чтобы время активности не совпадало.

Кейс: игровой бот на 500 сессий

Игровой сервер с античитом (EAC, BattlEye) на 500 сессий. Все — с одного /64. Через 2 часа — бан 400 сессий. Причина — античит смотрит на префикс и на TCP-отпечаток. У всех сессий — одинаковый window size 65535 и одинаковые TCP timestamps.

Решение: разные /64 (минимум 100 префиксов), разные ОС-образы в контейнерах (разные TCP-стеки), рандомизация MSS и window size через `iptables`:

```bash

iptables -t mangle -A POSTROUTING -p tcp --syn -j TCPMSS --set-mss 1400

sysctl -w net.ipv4.tcp_window_scaling=1

```

Это не панацея, но снижает вероятность корреляции.

Чек-лист проверки своего префикса

Перед тем как запускать мультиаккаунтинг, проверьте:

| Проверка | Команда | Что смотреть |

|---|---|---|

| Сколько /64 у вас | `whois -h whois.ripe.net ` | inet6num |

| ASN | `curl -s https://ipinfo.io//json` | org |

| PTR | `dig -x +short` | шаблон |

| TCP-отпечаток | `nmap -6 -O ` | window, MSS |

Если у вас один /64 — это один клиент для антибота. Если один /48 — 65536 клиентов, но только если антибот не агрегирует по /48.

Итог: маскировать надо не адрес, а префикс

IPv6 даёт много адресов, но антиботы это знают. Они агрегируют по /64, /56, /48 и коррелируют с TLS, TCP и поведением. Один /64 — это один отпечаток, сколько бы адресов внутри него вы ни использовали.

Работающая схема: разные /64 из разных /48, разные ASN, рандомизация таймингов и TLS-стеков. Без этого даже тысяча адресов внутри одного /64 — это один клиент с точки зрения антифрода.