запускаю
“C:*\goodbyedpi-0.2.2\x86_64\goodbyedpi.exe” -f 4 -e 4 --reverse-frag --set-ttl 7 --port 22222 --port 22224 --port 25656 --port 25735 --port 25500

так всё что по ip не блочено открывает (порты для holavpn в хроме)

с целью сделать более-лучше убираю -f 4 -e 4 --reverse-frag и продолжает открываться большинство, но не все блоченые сайты. те которые не открываются без заглушки, просто net err. увеличение ttl до предпоследнего хопа неработающего сайта никак не помогает.

а если -f 4 -e 4 --reverse-frag оставить, но убрать --set-ttl 7 то, по крайней мере в хроме, перестают открываться (бесконечно белый экран) вообще любые сайты (не понимаю почему)

т.е. знаем что dpi прова на седьмом хопе (если меньше 7 лезет заглушка)
но видимо и после 7го ещё есть другие dpi и их обманывает фрагментация, но тогда почему такая фрагментация не мешает сайтам открываться? а без ttl7 мешает…

отсюда и непонятно в моём случае -f 4 -e 4 --reverse-frag --set-ttl 7 сколько и каких фэйковых пакетов шлётся? если только 1 и с ttl7 то как тогда фрагментация помoгает “пробить” dpi который дальше 7го хопа?

Вероятно, соединение разрывает ваш провайдер.

1 пакет, TLS ClientHello на домен w3.org

Вероятно, фейковый пакет отключает дальнейшую обработку сессии, а фрагментированный пакет без фейкового, наоборот, ведёт к разрыву сессии.

всё равно не до конца понимаю принцип обмана

ну допустим (в моём случае) на 7м хопе dpi видит w3.org и пропускает его(который никуда дальше не доходит из-за ttl7) а следом идёт пакет с настоящим адресом

так и где тут спрятана фрагментация? в первом или в следующем?

даже Microsoft Network Monitor не помогает понять
если первый ясен

  Frame: Number = 513, Captured Frame Length = 571, MediaType = ETHERNET

- TLS: TLS Rec Layer-1 HandShake: Client Hello.
  - TlsRecordLayer: TLS Rec Layer-1 HandShake:
     ContentType: HandShake:
   + Version: TLS 1.0
     Length: 512 (0x200)
   - SSLHandshake: SSL HandShake ClientHello(0x01)
      HandShakeType: ClientHello(0x01)
      Length: 508 (0x1FC)
    - ClientHello: TLS 1.2

     - ClientHelloExtension: Server Name(0x0000)
        ExtensionType: Server Name(0x0000)
        ExtensionLength: 15 (0xF)
        NameListLength: 13 (0xD)
        NameType: Host Name (0)
        NameLength: 10 (0xA)
        ServerName: www.w3.org
     

то в следующем я вижу истинный адрес 68 64 72 65 7A 6B 61 2E 69 6E hdrezka.in
но вот чтоб в заголовках пакета его не найти…

• сам адрес без “разрывов” или \n каких нибудь
  поэтому как -e 4 позволяет пробить путь к ней неясно
  именно она без фрагментации а только с ttl не открывается

но то что именно ещё 1 dpi дальше седьмого не возьмусь утверждать и уже не уверен

Фейковый пакет не фрагментируется, а отправляется целиком, либо с низким TTL, либо с неправильной чексуммой, в зависимости от настроек.

Оригинальный пакет отправляется фрагментированным, либо задом наперед, либо последовательно (также зависит от настроек).

ок. это соответствует моим представлениям

осталось придти к пониманию понятий

ориг пакет это тот что сразу за w3.org ? (на 99% уверен что да но всё же вдруг и ещё шлётся а я не нахожу)
и видимо я плохо понимаю что есть “фрагментация” как её увидеть в сниффере? ибо думал что это адрес хоста делится частями но как уже говорил

сам адрес без “разрывов” или \n каких нибудь

и

в заголовках пакета его не найти

Да.

Отправка TLS ClientHello двумя TCP-сегментами (пакетами) вместо одного.

Такой функции нет.