Ротация IP через IPv6: как использовать /64 подсеть для обхода блокировок и не получить бан

/64 подсеть — не игрушка, а инструмент

Сразу к сути. У тебя есть /64 подсеть IPv6. Это 18 квинтиллионов адресов. Буквально. 2^64, если по-честному. С таким пулом можно менять IP каждую секунду, и на твоём веку адреса не кончатся.

Но есть нюанс. Провайдеры и сайты тоже не дураки. Они видят, что запросы идут из одной подсети. И если ты тупо долбишь их с каждого нового адреса — бан прилетит быстрее, чем ты успеешь сказать "ротация".

Я занимаюсь IPv6 прокси с 2015 года. На lexic.ml мы перелопатили кучу схем. Расскажу, что работает, а что ведёт в песочницу.

Как работает IPv6 ротация глазами железа

У тебя есть интерфейс с адресом вида 2001:db8::1/64. Всё, что после /64 — твоя территория. Ты можешь назначить любой адрес, и трафик пойдёт.

Ключевой момент — ядро Linux (или другого *nix) не требует, чтобы каждый IP был привязан к интерфейсу. Можно генерировать адреса на лету.

```bash

Пример быстрой смены адреса через ip

ip -6 addr add 2001:db8::100/64 dev eth0

Работаем

curl --interface eth0 http://example.com

Сносим

ip -6 addr del 2001:db8::100/64 dev eth0

```

Только так ты быстро упрёшься в лимит таблицы маршрутизации. 10 тысяч адресов — ядро начнёт тормозить. 100 тысяч — готовься к перезагрузке.

Реальная схема: не плоди адреса, меняй хвост

Рабочий метод — держать один базовый адрес на интерфейсе, а для запросов использовать разные source-адреса.

```python

import socket

import struct

def create_ipv6_socket():

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

Генерируем случайный хвост

suffix = struct.unpack('>Q', os.urandom(8))[0]

full_addr = f"2001:db8::{suffix:x}"

sock.bind((full_addr, 0))

return sock

```

Никаких лишних адресов в системе. Только на уровне сокета. Быстро, чисто, без нагрузки на ядро.

Главные грабли: почему тебя забанят за 5 минут

Грабли номер раз — одинаковый User-Agent. Сменил IP, а заголовки браузера те же. Любая система защиты это видит. Решение — менять fingerprint полностью.

Грабли номер два — тайминги. Если запросы идут каждые 200 мс, а IP меняется каждые 5 секунд — паттерн очевиден. Нужна случайная задержка от 1 до 10 секунд.

Грабли номер три — DNS. Ты сменил IP, но DNS-запросы всё ещё идут с твоего реального адреса. Провайдер видит: "Ага, вот кто скрывается". Используй свой DNS-резолвер на каждом новом IP.

Таблица: что делают крупные сайты

| Сайт | Политика | Лимит запросов | Время жизни бана |

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

| Google | 100 запросов/мин на /64 | Жёстко | 1 час |

| Cloudflare | 50 запросов/мин на /56 | Средне | 30 мин |

| Amazon | 200 запросов/мин на /48 | Мягко | 15 мин |

| Twitter/X | 30 запросов/мин на /64 | Очень жёстко | 2 часа |

Видишь закономерность? Чем меньше маска, тем больше лимит. Amazon смотрит на /48 — это 65536 подсетей /64. Google режет по /64.

Как обходить лимиты: распределённая ротация

Не меняй IP на каждый запрос. Разбей /64 на диапазоны. Используй один адрес 10-20 секунд. Потом переходи на следующий.

```python

Простая ротация с задержкой

import time

import random

ip_pool = [f"2001:db8::{i:x}" for i in range(10000, 10100)]

for ip in ip_pool:

Меняем адрес

change_ip(ip)

Делаем 5-15 запросов

for _ in range(random.randint(5, 15)):

make_request()

time.sleep(random.uniform(0.5, 2.0))

```

10 адресов на 100 запросов. Каждый адрес живёт 30-60 секунд. Никакой подозрительной активности.

Реальный кейс: парсинг с lexic.ml

Был у нас клиент. Парсил агрегатор цен. Сайт рубил на 50-м запросе. Стандартная история.

Дали ему /64 подсеть. Настроили ротацию через 50 адресов. Первые 2 дня — полёт нормальный. На третий — бан.

Почему? Он использовал один и тот же TCP-стек. SYN-пакеты были идентичны. Сайт просто сравнивал сигнатуры.

Решение — эмулировать разные ОС. На одном IP — Windows 10, на другом — Linux, на третьем — macOS. Fingerprint меняется, бан отложен.

```bash

Меняем MSS для разных IP

iptables -A OUTPUT -s 2001:db8::100 -p tcp --tcp-flags SYN SYN -j TCPMSS --set-mss 1460

iptables -A OUTPUT -s 2001:db8::200 -p tcp --tcp-flags SYN SYN -j TCPMSS --set-mss 1440

```

Когда /64 не панацея

Есть сайты, которые смотрят на /56 или даже /48. Cloudflare, например. Если ты в одной /56 — ты под колпаком.

Решение — брать несколько /64 подсетей. Или использовать /48, если провайдер даёт. На lexic.ml мы выдаём клиентам /48, чтобы гарантировать обход блокировок.

Ещё одна хреновая новость — некоторые сайты банят по MAC-адресу. Да, IPv6 позволяет трекать устройство через последние 64 бита (EUI-64). Решение — генерировать случайный хвост, не привязанный к MAC.

Инструментарий: что реально работает

Из практики — лучшее решение на Python с aiohttp. Асинхронно, быстро, без костылей.

```python

import aiohttp

import asyncio

import random

class IPv6Rotator:

def __init__(self, subnet, count=1000):

self.subnet = subnet

self.ips = [f"{subnet}:{i:x}" for i in range(count)]

self.current = 0

async def get_session(self):

ip = self.ips[self.current]

self.current = (self.current + 1) % len(self.ips)

connector = aiohttp.TCPConnector(

local_addr=(ip, 0),

family=socket.AF_INET6

)

return aiohttp.ClientSession(connector=connector)

```

Никаких лишних зависимостей. Работает из коробки.

Безопасность: не свети реальный IPv4

Если у тебя есть IPv4 и IPv6, трафик может утекать на IPv4. Проверь, что всё идёт только через IPv6.

```bash

Отключаем IPv4 на интерфейсе

sysctl -w net.ipv4.conf.eth0.disable_ipv4=1

Или через iptables

iptables -A OUTPUT -o eth0 -p ip -j DROP

```

Иначе ты будешь менять IPv6, а запросы всё равно летят с твоего реального IPv4. Смешно и грустно.

Итог: как не получить бан

1. Не меняй IP на каждый запрос. 5-15 запросов на один адрес.

2. Меняй fingerprint: User-Agent, заголовки, TCP-параметры.

3. Используй случайные задержки. Без паттернов.

4. Разные DNS для разных IP.

5. Если сайт жёсткий — бери /48, а не /64.

6. Отключай IPv4 на интерфейсе ротации.

Никакой магии. Только техника и здравый смысл. /64 даёт тебе 18 квинтиллионов адресов. Используй их с умом, а не как кувалду.