TCP OS Fingerprint і проксі — як насправді працює детект

Клієнти часто запитують про «TCP відбиток» і звинувачують провайдерів: «у вас поганий відбиток проксі». Розберемося, що це насправді таке, чому більшість проксі-сервісів роблять це неправильно — і як це вирішено в ProxyGrow на рівні ядра.

Що таке TCP OS fingerprint?

Коли пристрій підключається до будь-якого сайту, він встановлює TCP-з'єднання. Під час хендшейку передається не лише IP, а й набір низькорівневих параметрів із заголовків TCP-пакетів:

• Window Size — розмір буфера прийому, заявлений ОС
• TTL — початковий час життя, різний у різних ОС
• MSS — максимальний розмір сегмента, узгоджений при handshake
• Порядок і набір TCP-опцій — SACK, Timestamps, NOP, ECN, Window Scale
• Поведінка TCP-стеку — патерни ретрансмісій, обробка втрат, таймаути

Сукупність цих значень унікальна для кожної операційної системи. Windows 10, Android, iOS та Linux виглядають по-різному на мережевому рівні — це закладено в дизайн. Це і є TCP OS fingerprint — пасивно зчитуваний мережевий відбиток пристрою. Його не треба «запитувати» — він передається автоматично з кожним SYN-пакетом.

Що відбувається, коли ти використовуєш проксі?

Без проксі: пристрій будує TCP-з'єднання напряму з сайтом. Сайт бачить твій IP і твій fingerprint.

З проксі: пристрій будує TCP-з'єднання з проксі-сервером, а проксі відкриває окреме TCP-з'єднання з цільовим сайтом. Це два різних з'єднання. Сайт бачить параметри проксі-сервера, а не твого пристрою.

Якщо проксі-сервер працює на Linux (а більшість так і працює) — сайт бачить Linux fingerprint. Якщо при цьому браузер передає User-Agent: Windows 10, виникає невідповідність між L4 (транспортний рівень) і L7 (прикладний рівень) — і це розузгодження детектується автоматично.

Як сайти це виявляють?

Стандартний інструмент пасивної детекції — p0f. Він аналізує вхідні TCP SYN-пакети і визначає ОС віддаленого хоста без жодного активного запиту. Жодних probe-пакетів, жодних алертів від IDS.

Сайт зіставляє три сигнали:

1. L4 TCP fingerprint vs L7 User-Agent

Якщо TCP-стек каже «Linux», а браузер — «Windows 10»: червоний прапор. Це пряма вказівка на проксі або VPN.

2. RTT на L4 vs RTT на L7

Сайт бачить затримку TCP-з'єднання від проксі до себе (наприклад, 40 мс). Браузер клієнта передає загальний RTT 70 мс (клієнт → проксі → сайт). Різниця в цих значеннях — явний індикатор проміжного сервера.

3. Внутрішня неузгодженість TCP-параметрів

Якщо хтось спробував «підробити» fingerprint — наприклад, підмінив Window Size під Windows, але залишив Linux-специфічний порядок TCP-опцій — це гірше, ніж чесний Linux fingerprint. Неузгоджені поля детектуються надійніше, ніж відсутність спуфінгу.

Що змінюється в TCP при використанні проксі

Про мобільних операторів

Важливий момент: CGNAT операторів стільникового зв'язку сам по собі може змінювати TCP fingerprint. Обладнання оператора здатне видавати Linux або FreeBSD fingerprint — навіть при прямому підключенні модема без жодного проксі. Тому «Linux у fingerprint» автоматично не означає детект чи бан. Це один із багатьох сигналів, а не вирок.

Саме тому у мобільних проксі від початку є структурна перевага перед датацентровими — ще до будь-яких хитрощів із fingerprint.

Де насправді небезпека?

Три джерела проблем, які дійсно впливають на детект:

1. Неякісний частковий спуфінг

Проксі-сервіс змінює тільки Window Size або TTL, залишаючи інші параметри несумісними із заявленою ОС. Такий «гібрид» детектується краще, ніж чесний Linux fingerprint без спуфінгу взагалі.

2. Різниця RTT L4 / L7

Що більша різниця між затримкою на мережевому рівні та затримкою браузера — то очевидніша наявність проміжного сервера.

3. DNS-витоки

Один спільний DNS-резолвер на всі модеми ферми — класична помилка. Сайт бачить DNS-запити з одного джерела при різних IP. Кожен модем має використовувати DNS свого оператора.

Що важливіше: L4 чи L7?

L7 аналізується глибше. Canvas fingerprint, WebGL, TLS fingerprint (JA3/JA4), налаштування HTTP/2, порядок заголовків браузера — все це передає більше інформації, ніж TCP-стек. Але критична саме узгодженість між L4 і L7: якщо вони суперечать одне одному — жоден із рівнів не врятує.

Як це вирішено в ProxyGrow

Більшість проксі-сервісів або взагалі не працюють із TCP fingerprint, або роблять частковий спуфінг — і отримують результат гірший, ніж без нього.

У ProxyGrow реалізований власний мережевий стек на базі Linux kernel 6.12 — TCP Fingerprint Reality:

Повна імітація TCP-стеку обраної ОС Не заміна окремих полів, а відтворення всієї логіки поведінки TCP: Window Size, TTL, MSS, порядок і набір опцій, SACK/ECN-поведінка, timestamp-патерни — все відповідає обраній ОС цілком і внутрішньо узгоджено.

Прозоре клонування fingerprint клієнта на льоту Система зчитує TCP-параметри з вхідного SYN-пакета клієнта і проксує їх далі до цільового сайту. Сайт бачить fingerprint реального пристрою клієнта, а не проксі-сервера.

Застосування fingerprint на різних доступах Зчитаний fingerprint клієнта застосовується консистентно на всі його з'єднання, незалежно від типу протоколу.

Компенсація RTT: L4 RTT = L7 RTT Ключова відмінність. Система компенсує затримку в TCP-стеку так, що різниця між RTT на мережевому рівні (L4) і RTT браузера (L7) зводиться до мінімуму. Детект за дельтою RTT усунено.

Працює на всіх типах підключень SOCKS5, HTTP-проксі, OpenVPN, IKEv2, VLESS — fingerprint reality застосовується на транспортному рівні, прозоро для протоколу верхнього рівня.

Мінімальний вплив на продуктивність Уся обробка відбувається на рівні ядра. Швидкість і стабільність, характерні для ProxyGrow, зберігаються.

Підсумкова таблиця

Жоден із описаних методів детекції — p0f, RTT-аналіз, User-Agent vs TCP mismatch — не дає сигналу, якщо fingerprint клієнта передається коректно, а затримки скомпенсовано.

Це і є різниця між «продавати мобільні проксі» і продавати проксі, які на мережевому рівні дійсно поводяться як справжні мобільні пристрої.