Идентификация прокси по MTU и TCP window scaling

TCP-стек — болтливый свидетель. Он рассказывает о тебе больше, чем User-Agent, cookies и отпечатки браузера вместе взятые. Прокси и VPN меняют IP, но забывают про сетевой уровень. А зря.

Как MTU выдаёт прокси

MTU (Maximum Transmission Unit) — размер пакета, который интерфейс готов отправить без фрагментации. Для Ethernet — 1500 байт. Для PPPoE — 1492. Для туннелей — 1400 и меньше.

Когда ты сидишь дома за роутером с PPPoE — твой MTU 1492. Подключаешься через прокси — сервер видит пакеты с MTU 1500, потому что прокси пересобирает их заново. Несоответствие — красный флаг.

Разные ОС имеют разные дефолтные MTU:

- Windows: 1500 (Ethernet), 1400 (VPN-адаптеры)

- Linux: 1500, но туннели часто ставят 1450-1400

- macOS: 1500, но для PPPoE — 1492

Сервис сопоставляет TCP-сегменты с заявленным клиентом MTU. Если браузер говорит "я Windows", а пакеты летят с MTU 1500 и без признаков PPPoE — аномалия.

TCP window scaling: тихий идентификатор

Параметр Window Scale в TCP-хендшейке — множитель размера окна приёма. Он фиксируется при установке соединения и не меняется.

Значения по умолчанию:

- Linux: 7 (умножитель 128)

- Windows 10/11: 8 (256)

- macOS: 5 (32)

- Android: 4-7, зависит от версии

Прокси-сервис перехватывает SYN от клиента и устанавливает своё соединение с целевым сервером. Его TCP-стек имеет собственные параметры. Если сервер видит window scale 7 (Linux), а TLS-отпечаток браузера говорит о Windows 11 — прокси палится.

Почему это работает

TCP-параметры устанавливаются на уровне ядра ОС. Прокси-приложение не может их изменить без прав root и пересборки сетевого стека.

Пример: клиент подключается к прокси через OpenVPN. MTU туннеля — 1400. Прокси-сервер на Linux имеет MTU 1500. Когда прокси пересылает запрос к целевому сайту, он отправляет пакеты с MTU 1500. Сервер проверяет: "Этот клиент пришёл через туннель с MTU 1400, но шлёт пакеты 1500. Значит, между ним и мной кто-то ещё."

Идентификация по MSS

MSS (Maximum Segment Size) — параметр TCP-опций, указывающий максимальный размер сегмента. Он вычисляется из MTU минус заголовки.

| Интерфейс | MTU | MSS |

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

| Ethernet | 1500 | 1460 |

| PPPoE | 1492 | 1452 |

| OpenVPN | 1400 | 1360 |

| WireGuard | 1420 | 1380 |

MSS фиксируется в SYN-пакете. Прокси не меняет MSS при пересылке, если не настроен на clamping. Сервер видит: MSS 1360 (OpenVPN), а IP принадлежит хостинг-провайдеру. Вывод: клиент за VPN.

Практический тест

Проверь свой текущий сетевой стек:

```bash

Linux

cat /proc/sys/net/ipv4/tcp_window_scaling

cat /proc/sys/net/ipv4/tcp_rmem

ip link show | grep mtu

macOS

sysctl net.inet.tcp.window_scale

sysctl net.inet.tcp.mssdflt

```

Как сервисы используют эти данные

Крупные сервисы создают отпечаток TCP-стека каждого запроса. Они хранят базу: window scale, MSS, порядок TCP-опций, значения таймеров.

Алгоритм работы:

1. Перехват SYN-пакета

2. Извлечение параметров: window scale, MSS, SACK permitted, timestamps

3. Сравнение с базой известных комбинаций

4. Если комбинация не соответствует заявленной ОС или типу подключения — повышенный риск

Пример из практики: сервис потокового видео замечает, что все запросы от одного IP имеют window scale 7 и MSS 1412. Это типично для Linux-сервера с MTU 1452. Браузер клиента отправляет заголовки Windows 11. Сервис блокирует доступ.

TCP timestamps: скрытая зацепка

Опция TCP timestamps содержит два значения: tsval (отправитель) и tsecr (получатель). Частота обновления tsval зависит от частоты системного таймера ядра.

- Linux: 1 мс (CONFIG_HZ=1000) или 10 мс (CONFIG_HZ=100)

- Windows: 100 мс

- macOS: 10 мс

Прокси пересылает пакеты, но не может подделать частоту тиков ядра. Если tsval увеличивается на 100 мс (Windows), а window scale — 7 (Linux) — несоответствие.

Защита от идентификации

Полностью скрыть прокси невозможно. Но можно подобрать параметры так, чтобы не выделяться из толпы.

Настройка Linux-сервера под Windows:

```bash

Приводим window scale к Windows-значению

sysctl -w net.ipv4.tcp_window_scaling=1

Устанавливаем размеры буферов как у Windows

sysctl -w net.ipv4.tcp_rmem='65536 131072 6291456'

sysctl -w net.ipv4.tcp_wmem='65536 131072 6291456'

MSS clamping для соответствия типу подключения

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

-j TCPMSS --clamp-mss-to-pmtu

```

Но это не спасёт от анализа частоты timestamps. Для полного соответствия нужен патч ядра или использование тунельного интерфейса с подменой параметров.

Реальный кейс: блокировка дата-центров

Один из наших клиентов, использующий IPv6 прокси от lexic.ml, столкнулся с блокировкой на сайте банка. IP менялся, но сервис стабильно определял прокси.

Разбор проблемы показал: все запросы шли с window scale 7 и MSS 1412. Это типично для Linux VPS. Браузеры реальных пользователей с Windows давали window scale 8 и MSS 1460.

Решение: мы пересобрали сетевой стек прокси с параметрами, имитирующими домашний Windows-роутер. Добавили clamping MSS до 1452 (PPPoE). После этого сервис перестал отличать прокси-трафик от обычного домашнего.

Что проверять при покупке прокси

- Параметры TCP-стека сервера

- MTU интерфейса

- Возможность настройки MSS clamping

- Поддержку изменения window scale

Большинство дешёвых прокси работают на стоковых Linux-серверах без каких-либо настроек. Их TCP-отпечаток — как отпечаток пальца: уникальный и легко узнаваемый.

Выводы

MTU и window scaling — только вершина айсберга. Сетевой уровень хранит десятки параметров, по которым можно отличить прокси от реального пользователя. Пока одни сервисы собирают эти данные, другие — учатся их подделывать.

Идентификация прокси — гонка вооружений. И в этой гонке побеждает тот, кто понимает сетевой стек глубже, чем просто "сменить IP".