•  Untoreh-light

TCSplitter

Туннель для разделения TCP или UDP-соединения на несколько TCP-соединений.

Цель

Когда вы хотите разделить одно TCP-соединение на несколько? Обычно вы используете туннель достигать полная противоположность . Мой вариант использования заключался в обходе ограничений пропускной способности в мобильной сети, поэтому тесты проводились с сим-картой, по плану которой больше не осталось данных.[1].

Как это работает

В туннель был написан в Голанг поскольку он достаточно быстрый и обычно используется для сетевых инструментов. Cli практически не используется, так как большинство параметров были переработаны, когда я тестировал разные методы.

Изначально были «броски» и «арканы», чтобы разделить количество соединений на исходящие (броски) и входящие (лассо), но это была ненужная абстракция, так как лучше помечать пакеты их адресатом, хотя основным намерением было предлагать различные ограничения скорости для исходящих и входящих соединений, поэтому более высокое разделение между восходящим и нижним уровнями казалось целесообразным.

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

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

Соединения закрываются, а новые открываются по мере достижения настроенного лимита данных для каждого соединения, аналогично тому, как теневые носкипрокси туннелируют данные через разные потоки с целью маскировки поведения потоков данных, за исключением того, что наш туннель делает это как можно чаще.

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

Цель здесь - контролировать, сколько данных должно обрабатывать каждое соединение. Для наших целей это никогда не выходило за рамки обычного MTU размер окна. Вы можете думать о MTU как о верхней границе фрагмента данных, который проходит через сеть, и это было нашей целью, потому что мы хотели обойти ограничения пропускной способности стробируемой сети. Чтобы ограничить объем данных, которые может передать клиент, вам необходимо считать это правда? Если ваша логика работает с чем-то вродеdo-while

Тогда вам нужно по меньшей мере получитьpacket . Я не уверен, что это происходит на самом деле, или мой туннель работает по другой причине. Возможно, вполне возможно проверить даже первый пакет, но с точки зрения дизайна это будет означать, что вам нужно будет проверить каждый единственное соединение, которое сделало бы систему более слабой для атак DOS, и да, мой туннель можно было бы легко использовать в качестве эффективного инструмента DOS / Stress, поскольку вы можете разделить данные на очень маленькие пакеты (что означает, что TCP-соединения будут иметь высокое давление повторного использования ) и иметь пул подключений сколь угодно большого размера.

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

Полученные результаты

Я попробовал кодирование со стиранием в надежде увеличить пропускную способность данных. Используя библиотеку кодирования стирания и кодируя / декодируя сами данные, а также накладывая KCP протокол по моему протоколу разделения. Испытание KCP может показаться обратным подходом, так как он предлагает лучшую задержку для более низкой пропускной способности, но мое первоначальное предположение заключалось в том, что мое узкое место было в соединениях, обрываемых в середине передачи, что могло бы вызвать много поврежденных пакетов, поэтому я мог бы достичь более высокого уровня. пропускная способность с исправлением ошибок.

Оказалось, что это всего лишь ограничение скорости на количество TCP-соединений, которое клиент может отправить по сети, так что это просто защита DOS, с которой я ничего не могу поделать. После X количества подключений любоеSYN попытки перестать получать должноеACK , заполняя отставание и, в конечном итоге, заставляя туннель заглохнуть. Метод проб и ошибок показал, что это возможно между4-8[3] соединения открываются в любой момент времени и с MTU равным500-1000 байтов вы могли бы поддерживать постоянный поток по крайней мере128kbps , если постоянный поток не требовался, вы могли бы достичь более высоких скоростей за более короткий период времени, разрыв много подключений по запросу.

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

Выводы

Я не уверен, что достиг своей цели утилита мудро, поскольку запуск такого туннеля может сильно нагреть телефон и расходовать много заряда батареи, но наличие его в качестве резервного соединения может обнадежить ... если я действительно позаботился о том, чтобы сделать его достаточно стабильным :)

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

Теги сообщений: