Как антифрод-системы маркетплейсов вычисляют IPv6-прокси по паттернам MTU и TTL

MTU и TTL — самые недооценённые сигналы в антифроде. Их редко проверяют вручную, но автоматика на них ловит пачками. Причина простая: прокси-сервер физически не может скрыть, как он фрагментирует пакеты и с каким TTL они приходят на целевой хост. Если вы гоняете трафик через IPv6-прокси, эти два поля утекают раньше, чем TLS-handshake вообще начнётся.

Почему IPv6 делает MTU критичным

В IPv4 маршрутизатор мог фрагментировать пакет на лету. В IPv6 фрагментация по пути запрещена — RFC 8200 оставил её только отправителю. Отсюда PMTUD (Path MTU Discovery) становится обязательным, а не опциональным. Если прокси-сервер не пробрасывает ICMPv6 «Packet Too Big», TCP-сессия зависает или откатывается на минимальный MTU.

Антифрод это знает. Маркетплейс отправляет клиенту ICMPv6 с кодом 2 и смотрит: дойдёт ли ответ, изменится ли размер сегмента в следующих пакетах. Домашний клиент через CGNAT отреагирует одним способом, датацентровый прокси — другим. Разница в поведении и есть отпечаток.

TTL в IPv6: hop limit и его дефолты

В IPv6 поле называется Hop Limit, но суть та же. Дефолты по стеку:

| ОС / стек | Начальный Hop Limit |

|---|---|

| Linux (все современные ядра) | 64 |

| Windows 10/11 | 128 |

| macOS / iOS | 64 |

| FreeBSD | 64 |

| Cisco IOS | 255 |

| OpenWRT | 64 |

Прокси на Linux отдаёт пакеты с hop limit 64 минус число хопов до маркетплейса. Если сервер стоит в датацентре во Франкфурте, а маркетплейс в Москве — 12-14 хопов. Приходит 50-52. Домашний пользователь в Москве через того же оператора даст 60-62. Антифрод складывает это с ASN и получает расхождение.

Комбинация MTU и TTL как отпечаток

По отдельности ни MTU, ни TTL ничего не доказывают. Работает связка. Датацентровые прокси обычно крутятся на виртуалках с MTU 1500 (или 1450 на некоторых облаках), TTL 64. Домашние подключения — MTU 1500 на Ethernet, но 1492 на PPPoE, 1480 на некоторых VPN-туннелях. Мобильные операторы часто дают 1430-1460.

Пример: клиент заявляет себя как абонент МТС с мобильного. Приходит пакет с MTU 1500 и hop limit 52. Мобильный оператор физически не может дать MTU 1500 в LTE — там GTP-туннель добавляет 40+ байт overhead. Расхождение в 40-70 байт — красный флаг.

Как маркетплейс измеряет MTU удалённо

Прямого способа узнать MTU клиента нет. Но есть косвенные. Первый — TCP MSS в SYN-пакете. Клиент объявляет MSS = MTU - 40 (для IPv6) - 20 (TCP header). Если MSS = 1440, значит MTU = 1500. Если MSS = 1420, MTU = 1480.

Второй — размер первого data-сегмента после handshake. Многие стеки отправляют данные пачками ровно под MSS. Смотришь на распределение размеров — видишь MSS.

Третий — PMTUD-зонд. Сервер отправляет пакет заведомо больше MTU и слушает ICMPv6. Ответ приходит либо от клиента, либо от промежуточного роутера — и hop limit в этом ICMP-пакете выдаёт топологию.

Скрипт для сбора отпечатков

Вот рабочий сниффер, который логирует MTU-коррелированные метрики из pcap:

```python

from scapy.all import rdpcap, IPv6, TCP, ICMPv6PacketTooBig

def fingerprint(pcap_path):

flows = {}

for pkt in rdpcap(pcap_path):

if IPv6 not in pkt:

continue

src = pkt[IPv6].src

hlim = pkt[IPv6].hlim

plen = pkt[IPv6].plen

entry = flows.setdefault(src, {"hlims": set(), "max_plen": 0, "mss": None})

entry["hlims"].add(hlim)

if plen > entry["max_plen"]:

entry["max_plen"] = plen

if TCP in pkt and pkt[TCP].flags & 0x02:

opts = dict(pkt[TCP].options)

if "MSS" in opts:

entry["mss"] = opts["MSS"]

for src, e in flows.items():

mtu_est = e["mss"] + 60 if e["mss"] else None

print(f"{src} hlim={sorted(e['hlims'])} max_plen={e['max_plen']} mtu~{mtu_est}")

fingerprint("capture.pcap")

```

Скармливаешь ему трафик с прокси — получаешь таблицу. Дальше сравниваешь с ожидаемым профилем для заявленной геолокации.

Что видит антифрод на реальном трафике

Разберём типичную сессию. Пользователь с московского IP заявляет мобильный МТС. Пакеты приходят с hop limit 55, MSS 1440. Хопов от московского датацентра до маркетплейса обычно 8-10, от мобильного оператора — 12-15. 55 хопов при старте 64 означает 9 хопов пути. Для мобильного маловато. Для VPS в Москве — в самый раз.

Дальше смотрим, как ведёт себя PMTUD. Мобильный оператор честно отвечает ICMPv6 на зонды. Датацентровый прокси часто блокирует ICMP на файрволе — ответа нет. Это тоже сигнал.

Кейс: маркетплейс ловит пул прокси по MSS

Пример: маркетплейс с оборотом 40 млн сессий/сутки, стек на nginx 1.24 + собственный L7-фильтр. Настроен сбор TCP-опций через eBPF-хук. За сутки видит 1200 аккаунтов с заявленной геолокацией «мобильный интернет РФ», но с MSS 1440 и hop limit 50-54. Статистика по легитимным мобильным клиентам того же оператора: MSS 1360-1400, hop limit 58-61. Расхождение по двум параметрам одновременно — 99.7% точность отсева.

Причина: прокси-провайдер поднял пул на Hetzner с MTU 1500 и не стал заморачиваться с подгонкой. Все 1200 аккаунтов сняли за один прогон. Решение для прокси-провайдера — клонировать MSS и hop limit под целевую сеть, но это требует контроля на уровне ядра.

Кейс: ICMPv6-зонд вскрывает прозрачный прокси

Другой пример: антифрод отправляет клиенту ICMPv6 Packet Too Big с MTU=1280 после установки соединения. Легитимный клиент либо игнорирует (если уже отправил данные), либо уменьшает MSS и продолжает. Прокси с прозрачным режимом часто форвардит ICMP обратно на upstream, и на маркетплейс приходит ответ с hop limit, соответствующим пути «маркетплейс → прокси → upstream → обратно». Считаешь хопы — видишь лишнее звено.

В одном разборе прокси-сервис на 200 узлов погорел именно на этом. Классический путь давал 11 хопов, через прокси — 19. Лишние 8 хопов — это внутренняя сеть прокси-провайдера, которая не должна быть видна.

Кейс: MTU-несоответствие на PPPoE

Третий сценарий. Аккаунт заявляет домашний интернет через Ростелеком (PPPoE, MTU 1492). Пакеты приходят с MSS 1460, что соответствует MTU 1500. PPPoE-инкапсуляция добавляет 8 байт overhead, MSS на PPPoE-линке не может быть 1460 — максимум 1452. Антифрод это ловит тривиально: один параметр, одно сравнение с таблицей операторов.

Прокси-провайдер использовал датацентр с чистым Ethernet. Клиент заявил PPPoE. Расхождение — 8 байт. Достаточно для ручной проверки, а после накопления статистики — для автоматического бана.

Как прокси-сервисы пытаются маскироваться

Хорошие сервисы подгоняют MSS через iptables:

```bash

ip6tables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN \

-j TCPMSS --set-mss 1400

```

Это выравнивает MSS для всех исходящих SYN. Но hop limit так не подделаешь — TTL меняется на каждом хопе. Единственный способ — выставлять начальный hop limit под конкретный маршрут. На практике это делают через raw-сокеты или eBPF, настраивая значение индивидуально под целевую AS.

Ещё один приём — держать пул серверов в разных AS, чтобы хоп-каунт совпадал с заявленной геолокацией. Дорого, но работает. Именно поэтому качественные IPv6-прокси стоят в 5-10 раз дороже обычных датацентровых.

Что делать, если вы на стороне клиента

Если нужен прокси, который не палится по MTU/TTL, проверяйте три вещи. Первое: MSS в SYN должен соответствовать заявленному типу подключения. Второе: hop limit должен попадать в диапазон, ожидаемый для этой AS. Третье: ICMPv6 должен вести себя как у настоящего клиента — отвечать на Packet Too Big, не блокироваться наглухо.

Проверить свой прокси можно так:

```bash

curl -6 --max-time 10 -s -o /dev/null -w "%{time_connect} %{time_total}\n" \

https://api64.ipify.org

tcpdump -6 -i eth0 -nn 'tcp[tcpflags] & tcp-syn != 0' -c 5

```

Первый покажет задержку, второй — реальный MSS и hop limit в исходящих SYN. Сравните с эталоном для целевой сети. Если расхождение больше 5% по MSS или 3 хопа по TTL — вас, скорее всего, уже пометили.

Прокси-сервис lexic.ml, например, даёт пул IPv6-адресов с настраиваемым hop limit через API — это редкость, большинство провайдеров такое не умеют. Но даже с правильным hop limit нужно следить за MSS и поведением PMTUD.

Итог по детекту

Антифрод маркетплейсов не смотрит на MTU и TTL в изоляции. Он строит профиль: MSS, hop limit, поведение PMTUD, размеры первых data-сегментов, реакция на ICMPv6-зонды. Совпадение всех параметров с ожидаемым профилем заявленной сети — уже подозрительно. Расхождение хотя бы по двум — почти гарантированный бан.

Прокси-провайдеры, которые это понимают, подгоняют параметры под каждую целевую AS отдельно. Те, кто не понимает, живут до первого крупного прогона. Разница в цене между этими двумя категориями — ровно та цена, которую платят за невидимость на уровне L3.