← Назад в базу знаний

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

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

MTU и MSS: тихая война антифрода против прокси

Антифрод-системы не дремлют. Они копают глубже, чем ты думаешь. Один из их любимых методов — анализ MTU и MSS пакетов. И это работает. Даже если твой прокси чист со всех сторон, эти два параметра могут его выдать с потрохами.

MTU (Maximum Transmission Unit) — максимальный размер пакета на сетевом уровне. MSS (Maximum Segment Size) — максимальный размер сегмента на транспортном уровне. Разница между ними — 40 байт (20 байт IP-заголовок + 20 байт TCP-заголовок). Но дьявол, как обычно, в деталях.

Как прокси ломают MTU

Прокси-серверы работают как посредники. Они принимают пакет от клиента, обрабатывают его, отправляют дальше. В этой цепочке MTU может меняться. Почему? Потому что прокси добавляет свои заголовки, инкапсулирует трафик, использует туннели.

Типичный сценарий: клиент сидит за NAT с MTU 1500. Запрос идет на прокси. Прокси добавляет свои метаданные — MTU пакета увеличивается. Если итоговый размер превышает MTU следующего узла, пакет фрагментируется. Антифрод это видит.

Есть и обратная сторона. Некоторые прокси насильно режут MTU, чтобы избежать фрагментации. Клиент шлет пакет с MTU 1500, а прокси отдает уже 1400. Для бэкенда это красный флаг. Пользователи с реальных IP так не делают.

MSS — еще один ключ к разоблачению

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

Стандартный MSS для Ethernet — 1460 байт (1500 MTU минус 40 байт заголовков). Но если трафик идет через VPN или туннель, MSS может быть меньше. Например, при использовании PPPoE — 1452 байта. GRE-туннель — 1436 байт.

Антифрод смотрит на несоответствие. Если клиент из региона, где стандартный MSS 1460, а приходит пакет с MSS 1400 — подозрение. Если MSS меняется от сессии к сессии — еще хуже.

Реальные цифры и кейсы

Прокси-провайдеры знают об этой проблеме. Но не все решают её правильно. Давай посмотрим на типичные значения MTU/MSS для разных типов соединений:

| Тип соединения | MTU | MSS | Примечание |

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

| Ethernet | 1500 | 1460 | Стандарт |

| PPPoE | 1492 | 1452 | ADSL, некоторые LTE |

| VPN (OpenVPN) | 1500 | 1400-1450 | Зависит от настроек |

| GRE-туннель | 1476 | 1436 | Прокси-агрегаторы |

| IPv6-over-IPv4 | 1480 | 1440 | 6to4 туннели |

Обрати внимание на разброс. Если ты используешь прокси с фиксированным MTU 1400, а твой пользователь сидит на Ethernet с MTU 1500 — антифрод это заметит.

Как антифрод собирает данные

Системы фрод-мониторинга не ждут, пока ты ошибешься. Они проактивно анализируют каждый пакет. Вот типичный процесс:

1. Анализ TCP-рукопожатия. Собираются опции MSS, масштабирование окна, временные метки.

2. Сравнение с базой знаний. Для каждого региона, провайдера, типа устройства есть эталонные значения.

3. Выявление аномалий. Если MSS клиента не совпадает с эталоном для его геолокации — триггер.

4. Дополнительная проверка. Отправка ICMP-запросов с разным размером пакета для определения реального MTU.

Пример кода: как проверить MTU/MSS

curl тебе тут не поможет. Нужен низкоуровневый доступ к сокетам. Вот пример на Python:

```python

import socket

import struct

def get_mss(host, port):

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

sock.settimeout(5)

Включаем сбор информации о TCP

sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_INFO, 1)

try:

sock.connect((host, port))

Получаем TCP-информацию

info = sock.getsockopt(socket.IPPROTO_TCP, socket.TCP_INFO, 100)

Парсим структуру (упрощенно)

mss = struct.unpack('i', info[4:8])[0]

return mss

except:

return None

finally:

sock.close()

Проверка для разных хостов

hosts = ['example.com', 'google.com', 'yandex.ru']

for host in hosts:

mss = get_mss(host, 80)

print(f'{host}: MSS={mss}')

```

Этот код показывает, как получить MSS для конкретного соединения. Антифрод-системы делают то же самое, но в масштабе.

Почему это важно для прокси

Если ты используешь прокси для обхода блокировок или защиты анонимности, MTU/MSS — твоя ахиллесова пята. Даже если IP чистый, а User-Agent правильный, параметры пакетов могут выдать.

Особенно это критично для IPv6. Там MTU не может быть меньше 1280 байт. Если твой прокси режет MTU ниже этого порога — пакеты просто не пройдут. Антифрод это знает и использует.

На lexic.ml, например, давно решили эту проблему. Поддержка IPv6 там настроена так, что MTU/MSS не выбиваются из стандартных значений. Но это редкость. Большинство прокси-сервисов даже не знают о такой проверке.

Как защититься

Есть несколько способов обмануть антифрод по MTU/MSS:

1. **Фиксация MSS на уровне ядра**. Настройка iptables для принудительного задания MSS:

```bash

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

```

2. **Туннели с правильным MTU**. Используй WireGuard или OpenVPN с корректной настройкой MTU. Не ставь значение наобум.

3. **Динамическая подстройка**. Анализируй MTU клиента и подгоняй свой под него. Это сложно, но эффективно.

4. **Минимизация инкапсуляции**. Чем меньше дополнительных заголовков, тем ближе MTU/MSS к стандарту.

Грабли, на которые наступают все

Первая ошибка — использовать дефолтные настройки прокси. Большинство софта (3proxy, Squid) ставят MTU 1500 по умолчанию. Но это работает только если твой канал поддерживает такой MTU.

Вторая — игнорировать IPv6. Многие думают, что раз IPv6 не так распространен, можно забить. Но антифрод-системы активно анализируют и IPv6-трафик. И там MTU/MSS еще критичнее.

Третья — не проверять свой прокси. Запустил, работает, и ладно. А потом удивляешься, почему аккаунты банят. Проверять MTU/MSS надо регулярно. Хотя бы раз в неделю.

Итог

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

Решение есть. Настройка сетевых параметров, правильный выбор протоколов, регулярный мониторинг. И да, выбор прокси-провайдера, который понимает эти проблемы. Потому что большинство — нет.

✔️Купить прокси