Как антифрод-детектят прокси по MTU и MSS

Сетевой стек — не просто труба. Это fingerprint, который сдают твои пакеты. Антифрод-системы давно научились вычислять прокси не по IP, а по тому, как пакеты фрагментируются. MTU и MSS — два параметра, которые большинство админов не трогают. И зря.

Почему MTU стал маркером

MTU (Maximum Transmission Unit) — максимальный размер пакета на интерфейсе. Ethernet стандарт — 1500 байт. Но не все так просто. Провайдеры, VPN-серверы, туннели — каждый вносит свои коррективы.

Антифрод сканирует не только IP, но и TCP-стек. Если твой клиент шлет SYN-пакет с MSS, не соответствующим стандарту Ethernet — ты в базе. Не сразу, но через пару запросов.

Механизм простой: при handshake клиент указывает MSS в TCP-опциях. Сервер отвечает. Если MSS меньше 1460 (стандарт для Ethernet 1500 минус 40 байт заголовков) — это туннель или прокси.

MSS — главный предатель

MSS (Maximum Segment Size) — максимальный размер данных в TCP-сегменте. Рассчитывается как MTU минус заголовки. Для Ethernet 1500: MSS = 1500 - 40 = 1460.

Но через прокси или VPN MTU падает. Типичные значения:

| Тип соединения | MTU | MSS |

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

| Ethernet | 1500 | 1460 |

| PPPoE | 1492 | 1452 |

| OpenVPN (TCP) | 1500 | 1450-1400 |

| WireGuard | 1420 | 1380 |

| Shadowsocks | 1500 | 1460 |

| SSH-туннель | 1500 | 1430-1440 |

Видишь разброс? Антифрод собирает статистику. Если у 90% пользователей MSS=1460, а у тебя 1380 — ты в группе риска.

Как это выглядит на практике

Берем обычный curl к серверу. Смотрим MSS через tcpdump:

```bash

tcpdump -i eth0 -n 'tcp[tcpflags] & tcp-syn != 0 and port 443' -X

```

В ответе увидишь опции TCP. MSS будет в первых байтах после заголовка. Для WireGuard — 1380, для OpenVPN — 1400-1450.

Сервер на nginx 1.24 с модулем ngx_http_realip_module может логировать MSS клиента. Пример конфига:

```nginx

log_format mss_log '\ - \ [\] '

'"\" \ \ '

'"\" "\" '

'mss:\';

access_log /var/log/nginx/mss.log mss_log;

```

Да, nginx поддерживает \. Не все знают.

Кейс: как Cloudflare банит по MSS

Проблема: пользователь жалуется, что Cloudflare блокирует запросы. Статус 403, challenge не проходит. Причина — Cloudflare смотрит MSS на своих edge-серверах.

Пример: клиент заходит через Shadowsocks на VPS с MTU 1500. Но Shadowsocks добавляет заголовки шифрования. Реальный MSS клиента — 1420. Cloudflare видит аномалию: IP из США, MSS=1420, хотя стандарт для американских провайдеров — 1460.

Решение: настроить MSS clamping на клиенте. В Linux это iptables:

```bash

iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

```

Но clamp-mss-to-pmtu не всегда спасает. Если Path MTU Discovery сломан — пакеты будут фрагментироваться.

Почему Path MTU Discovery — зона риска

PMTUD (Path MTU Discovery) — механизм, который определяет минимальный MTU на пути. Работает через ICMP-сообщения "Fragmentation Needed". Но многие провайдеры блокируют ICMP.

Когда PMTUD не работает — пакеты с размером больше MTU промежуточного узла просто теряются. TCP начинает ретрансмиссию, снижает размер окна. Антифрод это видит: аномальное количество ретрансмиссий, нестандартный MSS.

Пример: сервер в Германии, клиент через китайский прокси. MTU на прокси — 1400. Клиент шлет пакет 1500. Прокси не может фрагментировать (запрещено в IP-заголовке). Пакет теряется. TCP retransmit. Антифрод фиксирует.

Кейс: банк блокирует VPN по MTU

Проблема: клиент подключается к банку через WireGuard. Банк отклоняет запросы. Логи сервера показывают MSS=1380.

Банк использует систему защиты на базе nginx + lua-скрипты. Скрипт проверяет MSS при handshake. Если MSS < 1440 — блокировка. WireGuard дает 1380. Решение — изменить MTU на клиенте:

```bash

ip link set wg0 mtu 1400

```

Но это не панацея. Банк может проверять не только MSS, но и TTL, окно TCP, таймстемпы.

TTL и MTU — связка для детекта

TTL (Time To Live) — еще один параметр, который выдает прокси. Стандартный TTL для Windows — 128, Linux — 64, macOS — 64. Прокси часто не меняют TTL.

Если клиент с Windows (TTL=128) идет через прокси на Linux (TTL=64), антифрод видит TTL=64. Несоответствие ОС и TTL — красный флаг.

Комбинация TTL + MTU + MSS дает почти 100% детект прокси. Пример: TTL=64, MSS=1380, MTU=1420 — 99% WireGuard.

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

Проблема: сервер e-commerce замечает аномалии в поведении клиентов. Стандартные методы (IP reputation, User-Agent) не работают.

Решение: система собирает статистику по MSS, TTL, окну TCP, таймстемпам. Для каждого IP строится профиль. Если профиль отклоняется от нормы более чем на 2 сигмы — блокировка.

Пример: для IP 185.xxx.xxx.xxx (прокси-провайдер) профиль: MSS=1450, TTL=56, окно=65535. Для реального пользователя из Германии: MSS=1460, TTL=128, окно=29200. Разница очевидна.

Как обходить детект по MTU

Полностью — никак. Но можно снизить вероятность.

1. **MSS clamping на клиенте**. Установи MSS = 1460. Если прокси добавляет заголовки — MTU должен быть больше 1500. В облаке это невозможно.

2. **Изменение MTU на интерфейсе**. Поставь MTU = 1500 на клиенте и прокси. Но если прокси использует туннель (WireGuard, OpenVPN) — MTU туннеля будет меньше.

3. **Использование TCP-опции MSS**. Вручную укажи MSS при соединении. В Linux через iptables:

```bash

iptables -t mangle -A OUTPUT -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1460

```

Но это сработает только если реальный MTU >= 1500. Если туннель дает MTU 1400 — пакеты будут фрагментироваться.

4. **Path MTU Discovery**. Включи на клиенте и сервере. Но если ICMP блокируется — не поможет.

5. **Использование прокси с фиксированным MTU**. Например, Shadowsocks с MTU 1500. Но это редкость.

Кейс: обход через двойной туннель

Проблема: нужно скрыть факт использования прокси. Одиночный туннель детектится по MSS.

Решение: двойной туннель. Первый — WireGuard (MTU 1420, MSS 1380). Второй — SSH поверх WireGuard (MTU 1500, MSS 1460).

Клиент видит MSS=1460, хотя реальный трафик идет через WireGuard. Но это снижает скорость и увеличивает задержку. Не для всех.

Что дает lexic.ml

На lexic.ml используют IPv6-прокси с 2015 года. MTU на их серверах — 1500. MSS — 1460. TTL — 64. Никаких отклонений от стандарта.

Но даже так — если твой клиент использует WireGuard с MTU 1420, а ты заходишь через их прокси — MSS будет 1380. Потому что прокси не меняет MSS клиента.

Решение: настрой MSS clamping на своей стороне. Или используй прокси, которые поддерживают MSS manipulation. Но таких мало.

Итог

MTU и MSS — не просто технические параметры. Это fingerprint, который выдает прокси быстрее, чем IP-репутация. Антифрод-системы собирают статистику по этим значениям и строят профили.

Обойти можно. Но не полностью. Нужно контролировать каждый параметр сетевого стека: MTU, MSS, TTL, окно TCP, таймстемпы. Один промах — и ты в базе.

Если используешь прокси — проверяй MSS. Если не совпадает со стандартом — антифрод уже знает.