ага, windows ведет себя также
спасибо, поправлю.
Кстати, на удивление macos ведет себя аналогично Linux, хотя вроде это и BSD
Не может быть гонок в этом коде с sendfile ?
Расчет идет на то, что вызов ядра sendfile до возврата отошлет данные или хотя бы скопирует куда-то.
nanosleep(0) - это просто передача управления следующему потоку в очереди планировщика.
время, после которого вернется nanosleep не гарантировано.
В этот момент копируется в буфер sendfile оригинальный блок данных.
Предполагается, что ядро еще раз обратится к буферу sendfile, чтобы его отослать.
Но когда это будет никто не может гарантировать.
Конечно, наиболее вероятно, что nanosleep вернется гораздо быстрее, чем возникнет необходимость повторной передачи.
Но еще непонятно что будет, когда второй send завершился, данные отправились в сокет, и после этого мы делаем munmap() и закрываем memfd.
Должно быть ядро делает dup() или что-то подобное, чтобы удержать буфер, пока он ему нужен, так что close() в проге не убивает реально буфер мгновенно.
Как вообще с надежностью данной схемы ?
TTL восстанавливается после того, как оригинал будет записан в файл, и если ядро каким-то образом захочет снова отправить данные до завершения nanosleep, то этот пакет тоже не дойдет до сервера из-за низкого TTL, что спровоцирует третью попытку. Однако вероятность этого очень мала, т.к. должно пройти время до ретрансмисии (0.2с) или должен быть полечен SACK, что не произойдет т.к. вторая часть отправляется в самом конце. Еще есть вероятность, что фейк не будет отправлен между вызовом sendfile и записи оригинальных данных с восстановлением TTL, чтобы это минимизировать и используется nanosleep, однако и это дает полную гарантию, что ядро успеет отправить фейк.
Наверно, имелось в виду НЕ дает полную гарантию.
Вот и я смотрю на этот код, и видится мне хак. Не предназначено это для таких попрыгушек
менять данные на лету без синхронизации с ядром на авось. Но возможно это на практике работает довольно стабильно.
Есть разные варианты. Быстрые/медленные/незагруженные/высоконагруженные/одно/многопоточные системы.
На них бы потестить
И еще на разной нагрузке на сам proxy. Я tpws тестировал в очень жестких режимах. До 10000 соединений, торенты через socks, броузер с кучей вкладок, курлы, качающие данные.
Вообщем ему не сладко приходилось, и надо было обеспечить отсутствие потерь кусков данных вследствие закрытий сокетов (буферизированная отправка)
Ну или сразу оговаривать, что режим потенциально ненадежен
да, так и есть
Спасибо большое за утилиту! А то у DPITunnel кривой HTTP-прокси, отчего не все сайты открываются с ним, а тут же привычный прокси SOCKS5/SOCKS4.
Мне хватает такой конфигурации:
/opt/ciadpi --method disorder --split-pos 3
Рад быть полезным
UDP associate over socks ?
Броузеры это поддерживают ?
насколько знаю - нет
Вышла новая версия - теперь сайты с IPv6 тоже открываются!
В windows имеет смысл все, что можно сделать в рамках stream (не packet) фильтра.
В т.ч. сплит и весь набор http дурилок. tlsrec, разумеется, тоже.
Packet filter уже реализован в goodbyeDPI, и без kernel драйвера его судя по всему не сделать
Кстати, tpws в режиме socks может работать под WSL
Конечно, однако до этого byedpi был неэффективен для tls, т.к. на многих провайдерах split не дает эффекта, disorder работает некорректно, а fake не поддерживается.
As discussed in Section 2, the TCP urgent mechanism simply permits a
point in the data stream to be designated as the end of urgent
information but does NOT provide a mechanism for sending “out-of-
band” data.
Unfortunately, virtually all TCP implementations process TCP urgent
indications differently. By default, the last byte of “urgent data”
is delivered “out of band” to the application. That is, it is not
delivered as part of the normal data stream [UNPv1]
( Stevens, W., “UNIX Network Programming, Volume 1.
Networking APIs: Sockets and XTI”, Prentice Hall PTR, 1997.).
For example,
the “out-of-band” byte is read by an application when a recv(2)
system call with the MSG_OOB flag set is issued.
Most implementations provide a socket option (SO_OOBINLINE) that
allows an application to override the (broken) default processing of
urgent indications, so that “urgent data” is delivered “in line” to
the application, thus providing the semantics intended by the IETF
specifications.
Поэтому DPI и может обработать пакет как обычные данные.
И поэтому один байт не будет обработан сервером, за некоторыми исключениями
Конечно, если сервер устанавливает опцию SO_OOBINLINE или флаг MSG_PEEK, принимая обычные данные, то все сломается.
Один байт отбросит, если делать это вручную и следить за отправкой, но семантически oob-данные являются данными. Попробуйте отправить несколько пакетов с urgent-флагом подряд — они объединятся в один сегмент и придут в приложение обычным потоком.
Хак, безусловно, прикольный, но не настолько универсальный, как может показаться на первый взгляд.
Да, поэтому можно отправлять настоящие данные с флагом oob, и все они придут в обычный поток, за исключением последнего байта:
1-я часть с флагом oob:
…“\nHost: rutx” (сервер отбросит x)
2-я часть:
“racker.org”…
К таким исключениям можно отнести некоторые средства защиты от ддос, в частности заметил поломку на QRATOR
Залей скомпилированную версию под винду с obb
byedpi-6b484d5.zip (31,7 КБ)