Благодарю, про маркеры тоже нашел пост. Будем крутить )
ну не в течении же 1 секунды 2х запросов
я же не предлагаю “зашить” ip в скрипт
1й этап как щас при старте делаем вывод о перехвате 53 или подмене ответов системного
2й при вводе domain.org ещё раз сравниваем ответ ip от системного и публичного dns для domain.org. чисто чтоб исключить случай как описано в изначальном посте.
любая разница в ответе повод вывести ахтунг. даже если это “просто” последствия “кэша” или чего другого не связанного с подменой dns от прова
p.s.
хотя я таки понял что ты имел ввиду. действительно простой nslookup на 1.1.1.1 подряд 10 раз за 5 сек. рандомно выдаёт 2 разных ip на инсту. и один из них даже открывает. а второй давно блочен по ip. но чебурнилы видать непрочухали.
ок. спс. ждём.
Разные DNS выдают разные ответы в одно и то же время.
У них кэш. Сравнивать эти ответы невозможно.
От одного сервера нечего сравнивать
да. поправил уже. но ты успел быстрей ответить
Мультисплит можно будет использовать с fake после запятой, как split2?
--dpi-desync=fake,multisplit --dpi-desync-fooling=(дурилка) --dpi-desync-split-pos=1,midsld
Такая стратегия будет корректной, рабочей?
В смысле, ломать не будет? Открывает, собрать три сегмента в обратном порядке должен уметь каждый сервер. Или вопрос про какие-то специфически заблокированные сайты? У меня ютуб проверяют жёстче всего, для сайтов типа фейсбука и этого достаточно дизордера с pos=1. Насколько я понимаю DPI теряется и не понимает, что перед ней client hello когда не видит 0x16 в начале. Только в случае ютуба DPI ещё парсит дополнительно пару следующих пакетов на наличие googlevideo.com, чему призван мешать второй разрез который сечет googlevideo пополам.
По идее да, multisplit это стратегия второй фазы и будет работать с фейком. Только если можно обойтись без фейка, то зачем он нужен?
multisplit - это вариант split. сочетаемость с другими не меняется, кроме seqovl, который здесь не поддерживается
Ситуация может быть любая. Сегодня можно, завтра нет.
Инструмент есть инструмент, это не шаблонная нажималка, и он должен быть гибок.
Да, мне тоже показалось, что алгоритм такой. Надо попробовать именно multisplit, а не multidisorder. Без переиначивания порядка
Классно! Тогда конфигурацию переписывать не буду. У меня все открывается, видео Ютуба быстро грузится. Поменяю сплит2 на мультисплит - и всё! В моей конфигурации все равно больше ничего улучшить нельзя.
Нене, в смысле вообще с этой стратегией сайты из блока открывает или нет. Если да,то имеет смысл убрать репиты и фейк гугла и уйти на multidisorder/multisplit
Сколько сидел, так и не смог пробить ютуб на multisplit. Видимо, нужен какой-то особенный параметр, но изменение split_pos=* и sld, endsld, midsld, ничего не дали.
Пробовал бахнуть даже fake и repeats дополнительно к multisplit, но тоже ничего не вышло. Вообще 0% пробития.
На multidisorder работает отлично. Даже не знаю, почему вообще не хочет работать multisplit.
А вот со сплитом не работает. Такое чувство, что каким-то конечным автоматом парсят сегменты, проходящие через DPI.
DPI умеет собирать фрагменты по порядку, но не умеет вне порядка
nfqws, кстати, тоже умеет собирать TLS лишь по порядку. Но он и не расчитан на распознавание обманов, потому что работает с исходным трафиком, который не обманывает. Сборка нужна в основном для кибера.
на моем прове на http DPI пинает на заглушку при любом количестве фрагментов, а при disorder соединение зависает. на https тоже самое, только не зависает при disorder
Они на каком-то прове добавили проверку еще на тупое вхождение подстроки “googlevideo.com”, и поэтому не работает обычный disorder
Открывает все что мне нужно +дискорд и ютуб. Только не факт, что у вас такие же алгоритмы DPI.
Ещё работает гуглофейк с disorder2 и --dpi-desync-split-tls=snisld. Без репитов.
На с чёт того что исчез нолик я так подумал сегодня, что наверно это мой косяк, просто автоматом бывает что то делаю, что даже не замечаю, точнее не запоминаю что делал, возможно бадун сыграл свою роль, не знаю
Вряд ли это получится. TLS 1.2 перестают работать без фейка
Это вообще не работает, прога сразу вылетает.
seqovl в MS/MD все-таки будет
для MS на каждый сегмент. в linux еще сечется превышение MTU и повторяется отправка без seqovl при ошибке. в других системах нет возможности продетектить превышение MTU. при превышении соединение сломается. тут сами думайте и оценивайте ваши сплиты и размер seqovl.
расчет идет на то, что пакеты не будут в сети перепутаны порядком, иначе будет срыв техники. пакеты идут залпом. как только первый приходит, оригинальная часть тут же выдается сервером в сокет, а tcp window смещается в плюс. если будет дисордер по естественным причинам, сервер сглотнет seqovl fake вместо real
для MD на все, кроме первого сегмента. если на какой-то части seqovl>=начального смещения, то seqovl автоматом отменяется для этой части. иначе будет срыв техники, но здесь он легко виден сразу, и можно отменить гарантированный фейл. превышения MTU в этом варианте быть не может в принципе, тк отсылаемые пакеты не увеличиваются относительно оригинала.
если вдруг TLS ClientHello размазано по разным пакетам, то позиции сплита нормализуются под текущий пакет. выбираются только те, что в него вписываются. правила работают с нормализованными позициями и смещениями внутри этого пакета. то есть nfqws не обьединяет мультипакетный запрос. он работает только внутри каждого пакета.
Так автор еще в прод изменения не катил