Но все является тем, чем звучит.
Обьяснение не соответствует действительности совсем.
И никакого отношения к sysctl не имеет.
Надо побольше читать доку. Просто взять ctrl+f и найти слово.
И еще неплохо бы задуматься зачем стали бы скрипты zapret ковыряться в системных настройках, не имеющих к его работе никакого отношения. Просто чтобы комбайн все в кучу ? Тут бы помойка настала
Раз даже от опытных пользователей до сих пор идут вопросы и непонимание, как и что работает в Запрете, значит, инструкцию мало кто понимает… А уж новичку и подавно сложно разобраться. Из этого делаю вывод, что перед чтением документации Запрета необходимо прочитать книгу по компьютерным сетям и инструкцию как все это на практике работает. Ну и примеры, как будет работать та или иная строчка, опция. Без этого понимания не будет. Всё будет методом “тыка”.
А вы так и не ответили на вопрос. Можно хотя бы приблизительно было ответить и доку я читал, там ничего не объясняется, так в двух словах по типу шпаргалки. Вы ведь создали, значит должны знать и хоть примерно, кроме того как “Обьяснение не соответствует действительности совсем”
Какой не будь случай из жизни, к примеру вот была такая ситуация и роутер лёг и тогда на этом фоне будет нарисовываться картина, что и как работает
Вы абсолютно правы, поэтому чтоб не читать книги по сетям, проще спросить )
А кажись в доке написано, но сокращенно
Нужно исходить от стороны запрета.
Данная функция отвечает за слежением TCP_KeepAlive соединений.
Дурим мы просто по стратегией первые пакеты (в состоянии офф) или применяем её на все пакеты в соединении (в состоянии он).
@bolvan Прошу поправить
@abc555 Вот и картина вырисовывается. И функции sysctl не нужеы
Единственный случай из жизни, это блокировка каждого запроса http внутри одного TCP сеанса.
Такого на современных DPI в России не делается
Следовательно для нубов правило НЕ ТРОГАЙ, НЕ ЛЕЗЬ
Если непонятно обьяснение из доки, обьяснять смысла нет
Первое предложение неверно, второе почти верно.
Нет никакого on/off. Есть порты, которые перехватывается по upload части с connbytes и без connbytes.
Первым управляет один параметр, вторым другой.
download часть всегда перехватывается с connbytes.
Параметр keepalive отключает connbytes на выход, вот и все
Спасибо
И там образно было про on/off )
В описании фильтра udp опечатка (–filter-udp=)?
установка фильтра udp и неустановка фильтра tcp запрещает udp
Должно же быть запрещает tcp? По аналогии с --filter-tcp=
Да, очепятка
Гипотетический пример, когда нужно было бы включить UDP_KEEPALIVE.
stateless DPI. stateless - значит проверяет каждый пакет вне контекста соединений, не помнит контекст и не учитывает. Отдельно взятый пакет. Начинается на d1: Похоже на DHT. Блокировать.
Торенты тупят.
Включаем keepalive, делаем desync=tamper. nfqws уродует каждый исходящий пакет d1. DPI его не замечает, торенты работают
Это чисто теоретический вариант
Навальные блокировки доказали stateful характер , прекрасно работал однократный fake или tamper, значит не надо мучать роутер, включать не нужно keepalive
Ну вот смотрите, заходим на http://fast-torrent.ru/, открывается, клацаю на любой торрент, выскакивает заглушка ( не на всех провайдерах именно этот сайт ), включаю KEEPALIVE=80 и заглушка больше не выскакивает, я и предположил что очень эта функция похожа на своё название, а далее ещё хочу проверить одну тему как влияет эта функция на неё
У меня без keepalive открывается. Connbytes 1:6 стоят. Подбирайте стратегию другую значит
Connbytes 1:6 у меня ломает всю мою стратегию, я не использую подобные параметры
Так же на одном прове перестал почему то открываться этот сайт http://rutor.lib/ и включение KEEPALIVE проблему разрулил, этот сайт не пытайтесь открыть, у вас он не откроется, это я для общественности написал про этот домен, потому что многие не в теме что это
HTTP keepalive проверяется так
Если в ответ на первый запрос идет “Connection: keep-alive”,
curl говорит connection left intact
значит keepalive срабатывает
Если далее включить дурилку без keepalive, и действительно провайдер использует statelss DPI (такие рудиментарники еще остались кое-где), то второй запрос пойдет на заглушку.
В примере заглушки нет, значит keepalive дурилку включать не надо.
На всякий случай включать keepalive - все равно что на всякий случай заглотить горсть непонятных таблеток. Авось поможет какая-то
curl -v http://fast-torrent.ru/a http://fast-torrent.ru/b
* Trying 45.142.212.135:80...
* Connected to fast-torrent.ru (45.142.212.135) port 80
> GET /a HTTP/1.1
> Host: fast-torrent.ru
> User-Agent: curl/8.4.0
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Server: nginx/1.20.1
< Date: Tue, 05 Nov 2024 12:33:11 GMT
< Content-Type: text/html; charset=utf-8
< Content-Length: 0
< Connection: keep-alive
< Location: /a/
< X-Content-Type-Options: nosniff
< Referrer-Policy: same-origin
< Cross-Origin-Opener-Policy: same-origin-allow-popups
<
* Connection #0 to host fast-torrent.ru left intact
* Found bundle for host: 0x1c74b7dcf00 [serially]
* Re-using existing connection with host fast-torrent.ru
> GET /b HTTP/1.1
> Host: fast-torrent.ru
> User-Agent: curl/8.4.0
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Server: nginx/1.20.1
< Date: Tue, 05 Nov 2024 12:33:12 GMT
< Content-Type: text/html; charset=utf-8
< Content-Length: 0
< Connection: keep-alive
< Location: /b/
< X-Content-Type-Options: nosniff
< Referrer-Policy: same-origin
< Cross-Origin-Opener-Policy: same-origin-allow-popups
<
* Connection #0 to host fast-torrent.ru left intact
У меня 2 таких заглушки, прова и выше него, ещё одна такая же и keep-alive проблему решил, а то никак не получалось. Ещё одну старую тему которую до конца так и не решил, хочу проверить как она будет работать с этой функцией
Если это решает проблему http - хорошо. Но будет крайней глупостью добавлять туда еще какие-то порты
Флуда это главное не будет с моей стороны ? Не люблю привлекать внимание
Флуд возникает только от неграмотного применения desync any protocol