Так TCP PING поидее просто проверяет, что хост отвечает SYN-ACK пакетом. А блокировки РКН срабатывают уже после отправки какого-нибудь пакета данных.
В блокчеке есть проверка на блок ip, в лог пишется, что требуется ручная интерпретация или типо того. И есть проверка на подмену днс провайдером, в этом случае ip берутся от doh. Но емнип, нет отдельного поиска именно рабочих ip
Можно поискать IP-Checker.zip (1,5 МБ) (аналогично B-Checker, только добавлена еще проверка на хостинг CF и перенаправление на рабочий ip)
по icmp и нету потерь по tcp гляди . х.з. где в пятом это переключать. для 3го ещё pcap нужен чтоб tcp пинг шёл
https://ntc.party/t/cli-инструмент-для-тестирования-dpi-блокировок-домены-tls-tcp-16-20kb-dns/22237
Утилита для теста обхода блока сайтов и TCP16-20 блоков.
Полезно при тестировании стратегий на работоспособность
Похоже, что так и есть. Посмотрел в шарке, что происходит. Да, идет SYN-ACK от сервера и сразу RST пакет от меня. Но я только учусь, может еще чего-то не понимаю. 
Думал, что если банят по ip то наглухо, вплоть до отброса первого же пакета SYN.
Да, я почитал, сделал все, как у них написано. Работает вроде (даже порт менял на 443 и проверял в том же шарке) но профита мало получается. Показывает, что ip живее всех живых.
@TesterTi спасибо, как всегда, за полезную информацию. Вы меня ей просто завалили, разгребать не успеваю ))
Очень просто тормозит.
Искусственный дроп пакетов с определенной вероятностью.
Это вызывает ретрансмиссии
Либо считается переданная инфа за единицу времени и при превышении включается дроп на некоторое время. Троттлинг. Грубо, но эффективно
так я и не утверждаю что “сложно” - показываю что детектится это на раз (спрашивали меня - как)
Если добавить в список doppiocdn.live - не работает.
Если добавить b-hls-11.doppiocdn.live - сразу начинает работать.
Это баг или фича? Таких b-hls-** там 69+ штук.
Лог кто будет смотреть ?
Работает потому что не работает - обычная ситуация
что-то, что работает, может ломать, и оно работает, когда не работает, но для другого работает
Все домены, к которым идет обращение, инвентаризировать через F12.
Продергать курлом в разных вариантах.
Если что-то одно надо исключить, можно использовать ^domain.com в exclude
В версии для windows где этот лог найти?
А, во, точно, нашёл! Обращение идёт к домену doppiocdn.live. Но если не добавлять домены третьего уровня (например, b-hls-11) - тогда не работает. Если добавить - работает. Это баг или фича?
Вариантах чего?
Но мне не надо исключить домены. Мне наоборот надо включить все возможные домены третьего уровня, чтобы вручную все 69+ штук не добавлять. Я же написал.
В доке все написано где найти. Берем и читаем и смотрим реальные действия, а не по косвенным признакам - открывается в броузере или нет
не сталкивался с траблом:
с винды в winws норм работает конкретная стратегия
а с роутера нифига. и дело не в ttl
а именно в фуллингах
т.е. на винде --dpi-desync-fooling=md5sig,badsum --dup=1 --dup-cutoff=n2 --dup-fooling=badsum нормально переваривает - а на роутере нет. только ts спасает(а дуплет тогда и не нужен)
в чём дело может быть? какой кривой линух рутера может такое ломать? раз с винды проходит то видать не в железе (рутер тотже)
p.s. блокчек на рутере пустить - невсегда возможно. приходится на винде искать…
Таких вопросов уже миллиард было.
Но мало кто удосужился снять дампы для сравнения. Если и пытались, то приходилось наводить , исправлять глупые ошибки типа не с того интерфейса сняли
Причем полную строку и тип/версию прошивку тоже наводить приходится.
Оказывается какой-то там кинетик…
учись дальше
Учусь, куда ж деваться 
Знаний правда не хватает. Вот когда пойму хотя бы половину readme от bolvan, тогда можно будет сказать, что чему-то научился и что-то освоил, но до этого еще далеко.
по моему очевидно что чего значит
Может и очевидно, но уровень разный у всех, не забывайте. Кому-то очевидно, кому-то не очевидно. В целом картина по ip (по этому ip - 149.154.167.51) у меня совпадает с вашей, но здесь видны потери на последнем хопе, а на 104.20.2.154 у меня потерь нет:
Hop Sent PL% Min Max Avg Host Name / [IP]
6 94 1 57,49 76,55 60,93 sto-b2-link.ip.twelve99.net [80.239.128.74]
7 49 6 53,18 64,87 56,36 sto-bb1-link.ip.twelve99.net [62.115.140.214]
8 39 15 51,78 63,22 55,94 sto-b9-link.ip.twelve99.net [62.115.139.181]
9 94 2 55,28 85,48 60,12 cloudflare-ic-391654.ip.twelve99-cust.net [62.115.199.207]
10 21 0 53,83 73,39 59,38 172.68.180.25 [172.68.180.25]
11 94 0 53,55 73,20 59,59 104.20.2.154 [104.20.2.154]
Есть только промежуточные потери, и возможно, они о чем-то говорят, хотя как пишут на сайте, важен только конечный хоп.
The important thing to remember is that the final destination is what REALLY matters. If the final hop is showing zero packet loss and acceptable latency, there isn’t a problem. All issues in hops before that become null and void.
One poorly responding router
The only hop that matters is the final destination. If you’re happy with the latency and packet loss being seen at the final destination, then none of the other hops matter.
Packet loss or latency at intermediate hops.
Я не говорю, что PingPlotter бесполезен, но, как я понимаю, не во всех случаях он может показать блокировку по ip. Вы же сами писали, что animejoy у вас не получилось определить блокировку таким образом.
(спрашивали меня - как)
Это я спрашивал, и спасибо вам большое, что ответили Как видите, я последовал вашему совету до конца, несмотря на то, что тема блокировки ip для меня не является жизненноважной, скорее просто давний интерес. И кстати, я продолжаю изучать PingPlotter - у них очень интересный pdf файл с реальными и разнообразными примерами использования. Хорошая тулза.
А зачем определять блокировку? Сейчас везде проверяется хост, и если там абракадабра то не пустит ) Animejoy у меня открывается просто с подменой хоста )
так типа и “не обязано” чтоли раз кинетик?
видел твои мессаги что под кинетиках не тестишь, но с другой то стороны чем тамошнее ядро и\или версия линуха “хуже” опенврт?
прям тупорогих ошибок точно нет(в том числе с модулями и т.п.), ибо с “старыми” стратегиями всё работает. захотел внедрить “новую” на основе overlapа стуна но роутер не смог…
причём напрягся и прикрутил блокчек прям на рутер но он действительно “не может” 
Старое ядро. Очень много функций или отрезаны и/или отданы под управление NDM, которая сама рулит фаерволом, маршрутизацией и т.д.
Вмешиваться в ее работу можно, но до определенного предела позволенного разработчиком.
Полная поддержка ipv6 в разработке уже лет 10
Ну и для запрета как минимум выбор стартегий ограничен использование iptables, nftables в кинетикевской прошивке пока даже не пахнет
Если вопрос ко мне, то в принципе я уже отвечал. Просто мне всегда было интересно, как можно определить, что ресурс блочится именно по ip, а не по доменному имени. При блокировке ip дурение с пакетами не поможет. Можете сами проверить на windscribe.
У меня тоже стандартным мылом прошивается. Но выше писалось, есть подозрение, что может блочиться по ip, причем периодически.
В каком-то ограниченном варианте он работает.
Но уже не раз обнаруживалось, что начинает ломаться на включении продвинутых фич.
Софт вендора начинает использовать все биты mark, что ломает DESYNC_MARK от nfqws.
Вот это хотя бы. Если перестает работать anti-loop на уровне iptables, ломается порядок отправки пакетов и может вообще быть deadlock. Сломаный порядок - неработающая стратегия.
Переписанный неправильно в 1 бит desync_mark - полное отсутствие реакции на пакет nfqws
Еще сносит правила iptables.
Мне не нравится сток вообще. Сток это война с производителем разной степени ожесточенности, подстройка под него.
Хочется отнести сей девайс на помойку и купить нормальный с openwrt
Кинетик - это не linux. Это модифицированное ядро и софт, который не думает, что есть кто-то, кроме него. Или недостаточно думает. И ты пляшешь с ним в бубны