Нашел систему на ростелекоме, где до финки только 1 ТСПУ на самом провайдере.
Все же пробив работает в обе стороны.
Если я с финки пошлю себе на ростелек DHT, он доходит, и если потом перекинуть пару src/dst port и отослать DHT обратно, то до финки доходит.
Значит DPI процессит полностью stateful в обе стороны.
Однако, на другом провайдере это портит ТСПУ на глобалнет
На еще одном провайдере у одного клиента такая схема как с ростелеком срабатывает, у другого в том же городе - не срабатывает.
Значит проблема, видимо, в нескольких ТСПУ, каждый из которых смотрит в свою сторону и считает направление по своему, или они настроены по-разному
Можете попробовать. Сегодня nfqws обновил до поддержики произвольных паттернов дописывания udplen. И сделал hexstring. Можно из файла, можно из hexstring
Я пробовал “de”. Что с “eeeeee”, что с “dedede” одно и то же
Можно попробовать добавлять вперед dictinonary левый элемент с индекс строкой более 1 символа
1:q9:get_peers
это значит
q : get_peers
2:qq1:x
значит
qq : x
после первого d вставить 2:qq1:x
получается
d1:ad2:id20:
d2:qq1:x1:ad2:id20:
если парсер разбирает dictionary и не реагирует не левые индексы, то должно работать
но опять же, без пробива с обеих сторон будет кое-как, как показывает практика
Больше отвечают при повторе содержимого (через патч клиента). Добавление {}, ping, get_peers узлам не нравится. Это без учета цензуры, изучался вопрос реакции софта.
Сделал в nfqws режим tamper и распознавание DHT.
При tamper корректно редактируется пейлоад, добавляя вначале дополнительный индекс:значение как описано выше
Вроде работает. Узлы появляются
Вообще режим tamper будет универсальным на будущее. Он предназначен для модификации известных пейлоадов корректным образом, чтобы их не распознавал DPI, но распознавал получатель.
Да, уже понял, что там в оригинале тоже есть a, и он идет до aa
Сделал 00
С точки зрения синтаксиса n:xxxxxx это строка с n символами. Там может быть все что угодно
Провайдер Уфанет. Нижний Новгород.
На один отправленный пакет, приходит 3 пакета с ответами, если использовать порт 1024.
Прежний порт 12345 больше не получает ответы при использовании программы nping.
В общем, ситуация плохая, вся надежда на умельцев, которые смогут что-то придумать.
Спасибо за совет с портом 1024
А причем тут выборы? Куча даже бесплатных впнов продолжала работать нормально. А “заблоченные” работали вместо udp по tcp, пусть и с порезанной скоростью. Тут что-то другое.
