•  unsoreh-light

TCSplitter

Тунель для поділу з'єднання TCP або UDP на кілька з'єднань TCP

Гол

Коли ви хотіли б розділити одне TCP -з'єднання на кілька? Зазвичай ви використовуєте a тунель досягати прямо протилежне . Моя ситуація з використанням обходила обмеження пропускної спроможності в мобільній мережі, тому тести проводилися за допомогою сім -карти, на якій більше не залишилося даних на її плані[1].

Як це працює

Файл тунель було написано в golang оскільки він досить швидкий і зазвичай використовується для мережевого інструментування. Клієнт практично не придатний для використання, оскільки більшість опцій були перероблені, коли я випробовував різні методи.

Спочатку існували "flings" та "lassos", щоб розділити кількість з'єднань для вихідних (flinged) та вхідних (lassoed), але це була непотрібна абстракція, оскільки краще позначати пакети їх призначенням, хоча основним наміром було запропонувати різні обмеження швидкості для вихідних та вхідних з'єднань, тому більш високий рівень поділу між вгору/вниз здався практичним.

Клієнт повинен створити екземпляр усіх з'єднань, оскільки ми припускаємо, що сервер не може відкривати вихідні з'єднання. Коли клієнти отримують з'єднання з програми користувача, він встановлює необхідний пул з'єднань із сервером, і незалежно від того, які дані вони отримують, він розбиває його між виділеними з'єднаннями відповідно до обмеження, визначеного користувачем.

Потім пакети надсилаються на сервер, який має відновити їх у правильному порядку, тому що різні з'єднання TCP можуть завершити потік даних у будь -який час (надісланий порядок не дотримується, тому що маршрутизація ), а потім перенаправлено до програми -одержувача.

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

Чому це працює

Намір тут полягає в тому, щоб контролювати, скільки даних має обробляти кожне з'єднання. Для наших цілей це ніколи не було, як зазвичай MTU розмір вікна. Ви можете вважати MTU верхньою межею частини даних, яка передається по всій мережі, і це було нашою ціллю, тому що ми хотіли обійти обмеження швидкості пропускної здатності мережі з обмеженим доступом. Щоб обмежити кількість даних, які клієнт може передати, вам потрібно рахувати це, правда? Якщо ваша логіка працює з чимось на зразок ado-while

Тоді вам потрібно принаймні отримати apacket . Я не впевнений, що це відбувається насправді, або причина мого тунелю працює інша. Можливо, цілком можливо перевірити навіть перший пакет, але з точки зору дизайну це означало б, що вам доведеться перевірити кожен єдине з'єднання, що зробить систему слабшою для атак DOS, і так, мій тунель можна легко використовувати як ефективний інструмент DOS/стресу, оскільки ви можете розділити дані на дуже маленькі пакети (що означає, що з'єднання TCP матимуть високий тиск переробки ) і мати пул підключень настільки великий, наскільки вам подобається.

Тестування через різні порти також показало, що це можливо тільки через дещо портів, і що межа була постійно різною між портами, с443 даючи одне з найвищих вікон, навколо20kb , здогадуючись, тому щоTLS рукостискання вимагають більше даних, і що ці обмеження швидкості змінюються залежно від часу доби[2].

Результати

Я спробував кодування стирання в надії збільшити пропускну здатність даних. За допомогою бібліотеки кодування стирання та кодування/декодування самих даних, а також шляхом накладання КПК протокол над моїм протоколом розщеплення. Випробування KCP може здатися зворотним підходом, оскільки він торгує кращою затримкою для меншої пропускної здатності, але моє початкове припущення було, що моє вузьке місце було в з'єднаннях, що перервались у середині передачі, що спричинило б багато пошкоджених пакетів, тому я міг би досягти більш високого рівня пропускна здатність з виправленням помилок.

Виявилося, що це лише обмеження щодо кількості TCP-з'єднань, які клієнт може надіслати через мережу, тому це просто захист DOS, з яким я нічого не можу вдіяти. Після X кількість з'єднань будь -якаSYN спроби припинити отримувати належнеACK , заповнюючи відставання і зрештою роблячи тунель зупинкою. Проби і помилки показали, що це можливо між4-8[3] з'єднання відкриваються в будь -який момент часу і з MTU500-1000 байт, ви могли б принаймні тримати постійний потік128kbps , якщо постійний потік не був вимогою, ви могли б досягти більших швидкостей за коротший період часу на розривається безліч з'єднань за запитом.

На відміну від цього, (правда)DNS тунель ледве проштовхується56kbps і його можна швидко придушити, тому що я думаю, що велика кількість запитів DNS виглядає більш підозріло, ніж запити TCP. Ми маємо уточнити, що аtrue Тунель DNS кодує (вихідні) дані через підроблені субдомени та розшифровує (вхідні) дані, отримані шляхом запиту записів DNS, тоді як іноді тунель DNS можна вважати сирим UDP -з'єднанням через порт DNS, що, ймовірно, колись у минулому, DNS -сервери дозволено та правильно передано.

Висновки

Я не впевнений, що досяг своєї мети утиліта розумно, оскільки запуск такого типу тунелю може зробити ваш телефон досить гарячим і витратити багато акумулятора, але його наявність як резервного з'єднання може бути обнадійливим ... якщо я насправді потрудився зробити його досить стабільним :)

[1]зазвичай, коли на сім -картці немає більше даних для перегляду веб -сторінок, веб -запити переспрямовують на шлюз захоплення (щоб повідомити вам купити більше даних)
[2]тарифні плани мобільного зв'язку можуть забезпечити кращу зв'язок у нічний час
[3]Це число, дещо узгоджене з загальними підрахунками ядра, може викликати у вас підозру, що ядро ​​якось обмежує з'єднання, сценарій відкритих з'єднань нашого тунелю, безумовно, незвичайний, але налаштування ручок Linux ніколи не дало кращих результатів.

Теги дописів: