Нормально он пропускает и badsum, и datanoack. По крайней мере 153 ревизия - та, что без secure boot.
Там старинное ядро 3.2 с проприетарным неотключаемым оффлоадом в нетфильтре.
Но если с самого него дурить, там проблемы будут из-за оффлоада.
Лучше все же в роутер на openwrt втыкать , отключать NAT на openwrt и прописывать ip route на подсеть lan openwrt в автозапуск на huawei. Если, конечно, это не версия с secureboot неломаемая
ясно
видимо прошивки разные у твоего и моего
хотя у меня тоже 153й. небрендированый но прошка с 4pda чтоб и imei и т.п. рулить.
запрет в кинетике крутится
но результат с разными момедами разный - и железо во вних тоже разное - нельзя удачную от 33 на 83 прошить…
root@p711:/ # atc "ATI"
Manufacturer: huawei
Model: E8372
Revision: 21.328.03.00.00
root@p711:/ # cat /proc/version
Linux version 3.4.5 (jenkins@localhost) (gcc version 4.6.x-google 20120106 (prerelease) (GCC) ) #1 PREEMPT Tue Oct 24 17:58:00 CST 2017
badsum проверял с роутера , в который воткнут huawei.
без fake - виснет, тк заблокировано
fake - виснет, тк доходит до сервера
fake:badsum - не виснет, отбрасывается сервером
Не раз разбиралось
На разных ОС разная работа с сетевыми стеком из-за чего копирование в лоб с винды на линукс не проходила без проблем
Есть инфа о блокировках finland-*.discord.media? Оч странная картина, вроде бы tls handshake нормально проходит, но потом сервер виснет секунд на 30-40 и клиент кидает fin на то, что сервер после этого присылает. На 16 кб блок вроде бы не похоже
Ни у кого не получалось обходить замедление fastly? Например, с i.imgur.com то быстро качает, то только 1.5 мегабита идёт.
Нужна ссылка
Вот например:
https://i.imgur.com/qFkK7Wt.gif
Как будто это сам imgur или fastly. У меня в 1 раз было 50кб/сек, а в последующие уже быстро. Но можешь попробовать так
curl -k -o /dev/null --connect-to ::i.imgur.com -H "Host: i.imgur.com" https://apple.com/qFkK7Wt.gif
Или adobe.com
добрый день у меня такой вопрос почему когда я применяю syndata или dup=1 у меня отваливается весь интернет даже лампочка перестаёт гореть это что роутер виноват или это особенность моего провайдера
А у вас PPPoE или IPoE? Мб провайдер разрывает PPPoE сессию при получении чего-то “плохого”?
у меня PPPoE
Спасибо, но не помогло. Там ещё от выдаваемого IP зависит, поэтому закостылил сменой DNS. Если попадает на определённый IP-адрес из подсети 146.75.0.0/16, то где-то в половине или трети случаев режется скорость соединения. Пробовал обходить на другом линке без NAT через SYNACK, но тоже не помогло. Вероятно режут безусловно, просто из-за load balancer не всегда попадает на DPI с шейпингом.
месяцев 7-8 взад подминал вопрос что делает запрет с http если видит host: 123.45.67.89
т.е. просто цифры
тогда пришли к мнению что всё равно идёт дурение не смотря ни на что
а как сейчас поведение по дефолту?
https://ntc.party/t/zapret-whats-new/61/194
не особо прояснило.
мне всё также приходится применять --ipset-exclude-ip= с перечислением поайпишно чтобы не глючило то что иначе глючит.
или я чтото упускаю и есть более элегантный вариант?
Содержимое host: как IP адрес в ipset не проверяется.
Идет проверка по хостлистам как строка. При этом распознается, что хост является литеральным представлением IP и логика с поддоменами, разделенными точками, отменяется
ipset - только IP адреса из L3, хосты - только из L6/L7, даже если они выглядят как литеральное представление IP адреса
Для локальных GGC у меня нет уверенно работающих стратегий (любые удачные то пробивают, то нет, но это не суть). Юзал их блокировку через hosts на 127.0.0.1, но это несколько тормознуто. Добавил ipset с их айпишниками, добавил правило:
-A OUTPUT -p tcp --dport 443 -m set --match-set beeline_ggc dst -j REJECT --reject-with tcp-reset
При запущенном zapret при просмотре видео в консоль спамит:
rawsend: sendto (227): Operation not permitted
rawsend: sendto (1452): Operation not permitted
rawsend: sendto (490): Operation not permitted
Убирал правило для googlevideo, чтобы zapret пакеты к GGC вообще не трогал, но сообщения продолжаются. Видимо, ему не нравятся реджекты вообще.
Помогите ))
UPD:
Не шарю в работе цепочек, поэтому вот так, видимо, правильно:
-A FORWARD -p tcp --dport 443 -m set --match-set beeline_ggc dst -j REJECT --reject-with tcp-reset
ок
про хостлисты понял - как раз этого то и не было раньше.
но с другой стороны. конструкция
--ipset-exclude-ip=31.135.14.238,95.213.212.50,185.162.93.96,87.228.71.67 --new
самая левая\первая в строке именно так работает или нет?
логика(моя) - у пакета по любасу есть адрес - он “совпадает” ни смотря ни начто другое => дропаем из дальнейшей обработки
или надо всёже вкупе с --filter-tcp=80 бла-бла-бла этот экслюд вкарячивать?
REJECT или DROP output вызывают ошибки аксес денайд при попытке отправить что-то, подпадающее под правило
Если используются скрипты запуска, содержимое ipset надо продублировать в nozapret
Если свои правила - продублировать ipset с отрицанием в правило nfqueue
ipset работает по L3, --filter-{tcp,udp} по L4
они разные заголовки смотрят
все фильтры складываются по AND
–filter-tcp=80 не синоним “здесь http”
нет, не http, а просто порт 80. по нему я хоть балалайку могу передать