Огласите весь список усилителей и ограничителе
Откуда народ это все придумывает ?
Ограничители все описаны в доке. Это TTL и fooling.
Усилитель я вообще не знаю что такое. Есть способы воздействия на трафик. Они перечисляются в --dpi-desync. Остальные параметры уточняют характеристики воздействия
Всех приветствую. Подскажите, пожалуйста, кто владеет информацией, пытаюсь настроить обход DPI на pfSense 2.7.2 при помощи dvtws от bol-van (спасибо Вам за инструментарий), но столкнулся с проблемой: при добавлении в скрипт запуска по инструкции на bsd-системы строки
ipfw add 100 divert 989 tcp from any 80,443 to any tcpflags syn,ack in not diverted recv “$NETIF”
у меня напрочь падает загрузка всех интернет-страниц ($NETIF у меня pppoe0). Без этой строки обход DPI работает, но только через QUIC
Стратегию подсмотрел в пакете “zapret-discord-youtube-1.4.0”, а именно
–filter-udp=443 --hostlist=“list-general.txt” --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-fake-quic=“%BIN%quic_initial_www_google_com.bin” --new ^
–filter-udp=50000-65535 --dpi-desync=fake --dpi-desync-any-protocol --dpi-desync-cutoff=d3 --dpi-desync-repeats=6 --dpi-desync-fake-quic=“%BIN%quic_initial_www_google_com.bin” --new ^
–filter-tcp=80 --hostlist=“list-general.txt” --dpi-desync=fake,split2 --dpi-desync-autottl=2 --dpi-desync-fooling=md5sig --new ^
–filter-tcp=443 --hostlist=“list-general.txt” --dpi-desync=fake,split --dpi-desync-autottl=2 --dpi-desync-repeats=6 --dpi-desync-fooling=badseq --dpi-desync-fake-tls=“%BIN%tls_clienthello_www_google_com.bin”
На Win10 с ней Youtube работает идеально, и по TLS, и по QUIC, а при её адаптации под dvtws работает только через QUIC. По этому протоколу не все устройства в сети могут обращаться, затем и борюсь чтобы работало и по TLS.
${SERVICE_CMD}
–debug=1
–port=989
–filter-udp=443 --hostlist=“$YOUTUBE_LIST” --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-fake-quic=“$QUIC_BIN” --new
–filter-udp=50000-65535 --dpi-desync=fake --dpi-desync-any-protocol --dpi-desync-cutoff=d3 --dpi-desync-repeats=6 --dpi-desync-fake-quic=“$QUIC_BIN” --new
–filter-tcp=80 --hostlist=“$YOUTUBE_LIST” --dpi-desync=fake,split2 --dpi-desync-autottl=2 --dpi-desync-fooling=md5sig --new
–filter-tcp=443 --hostlist=“$YOUTUBE_LIST” --dpi-desync=fake,split --dpi-desync-autottl=2 --dpi-desync-repeats=6 --dpi-desync-fooling=badseq --dpi-desync-fake-tls=“$TLS_BIN”
| logger -t “${SERVICE_NAME}” >/dev/null 2>&1 &
Наведите, пожалуйста, на мысль, куда посмотреть…
Может DNAT?
Я тоже подумал, читая документацию Запрета, что сплит-пос лишним не будет. Значение, которое указывается после знака равенства (от 1 до 1500), определяет позицию (смещение в байтах) внутри пакета TCP, где произойдет разделение.
Либо ты не туда смотрел
Либо не тот рид читал
Спойлер
Выдержка из /dosc/bsd пункт pfSense
ipfw delete 100
ipfw add 100 divert 989 tcp from any to any 80,443 out not diverted xmit em0
pkill ^dvtws$
dvtws --daemon --port 989 --dpi-desync=split2
Для bsd систем там отдельный рид и в нем есть отдельный пункт для pf
На pfsense может быть конфликт 2 фаерволов - pf и ipfw.
Можно запустить dvtws с --debug и посмотреть приходят ли на него входящие пакеты.
У меня не особо много опыта с pfsense, но из постов я видел много дичи вплоть до перевертыша src/dst адресов
Если не получится завести входящие, можно от них отказаться, но придется тогда и отказаться от autottl и autohostlist
Это видел, спасибо. Но смотрел скорее в файле bsdfw.txt, им и руководствовался
Спойлер
ipfw delete 100
ipfw add 100 divert 989 tcp from any to any 80,443 out not diverted xmit em0
; required for autottl mode
ipfw add 100 divert 989 tcp from any 80,443 to any tcpflags syn,ack in not diverted recv em0
; udp
ipfw add 100 divert 989 udp from any to any 443 out not diverted xmit em0
Вот кусок лога без строки
ipfw add 100 divert 989 tcp from any 80,443 to any tcpflags syn,ack in not diverted recv “$NETIF”
Я не особо шарю в компьютерных сетях, поэтому обратился за помощью, если не сложно, посмотрите, пожалуйста
Спойлер
packet: id=3034 len=375
IP4: 192.168.1.192 => 173.194.187.8 proto=tcp ttl=127 sport=58700 dport=443 flags=AP seq=1452415997 ack_seq=2081504192
TCP: 2F 3F 00 1D 00 20 CA D3 91 E2 45 BA AD 79 EF 3D E5 AE 32 91 25 D5 D0 78 08 25 43 84 5E 5A C3 41 … : /?.. …E…y.=…2.%…x.%C.^Z.A …
using cached desync profile 0
reassemble : feeding data payload size=335. now we have 1743/1743
packet contains full TLS ClientHello
req retrans : seq interval 1452414589-1452416331
DELAY desync until reasm is complete (#2)
REPLAYING delayed packet #1 offset 0
REPLAY IP4: 192.168.1.192 => 173.194.187.8 proto=tcp ttl=127 sport=58700 dport=443 flags=A seq=1452414589 ack_seq=2081504192
TCP: 16 03 01 06 CA 01 00 06 C6 03 03 8A 74 DE 31 11 2F 07 E5 BA 24 3A B7 42 0F 2A 9F 51 0E 1A DC 42 … : …t.1./…$:.B.*.Q…B …
using cached desync profile 0
packet contains full TLS ClientHello
hostname: rr3---sn-4g5e6ns6.googlevideo.com
discovered l7 protocol
discovered hostname
desync profile search for tcp target=173.194.187.8:443 l7proto=tls hostname=‘rr3---sn-4g5e6ns6.googlevideo.com’
- hostlist check for profile 4
Checking include hostlist
Hostlist check for rr3---sn-4g5e6ns6.googlevideo.com : negative
Hostlist check for googlevideo.com : positive
desync profile 4 matches
desync profile changed by revealed l7 protocol or hostname !
dpi desync src=192.168.1.192:58700 dst=173.194.187.8:443
split pos 2
sending fake request : 16 03 01 02 87 01 00 02 83 03 03 5F 15 63 CB 06 EA 1C DD 40 76 F5 8C 44 50 6E 01 F3 A3 83 AC C2 … : …_.c…@v…DPn… …
sending fake(1) 1st tcp segment 0-1 len=2 : 00 00 : …
sending 1st tcp segment 0-1 len=2 seqovl=0 : 16 03 : …
sending fake(2) 1st tcp segment 0-1 len=2 : 00 00 : …
sending 2nd tcp segment 2-1407 len=1406 : 01 06 CA 01 00 06 C6 03 03 8A 74 DE 31 11 2F 07 E5 BA 24 3A B7 42 0F 2A 9F 51 0E 1A DC 42 E7 98 … : …t.1./…$:.B..Q…B… …
DROPPING delayed packet #1
REPLAYING delayed packet #2 offset 1408
REPLAY IP4: 192.168.1.192 => 173.194.187.8 proto=tcp ttl=127 sport=58700 dport=443 flags=AP seq=1452415997 ack_seq=2081504192
TCP: 2F 3F 00 1D 00 20 CA D3 91 E2 45 BA AD 79 EF 3D E5 AE 32 91 25 D5 D0 78 08 25 43 84 5E 5A C3 41 … : /?.. …E…y.=…2.%…x.%C.^Z.A …
using cached desync profile 4
packet contains full TLS ClientHello
hostname: rr3---sn-4g5e6ns6.googlevideo.com
dpi desync src=192.168.1.192:58700 dst=173.194.187.8:443
split pos 2 is outside of this packet 1408-1743
SENDING delayed packet #2 unmodified
reassemble session finished
packet: id=3034 drop
packet: id=3035 len=1448
IP4: 192.168.1.192 => 173.194.187.8 proto=tcp ttl=127 sport=58700 dport=443 flags=AP seq=1452414924 ack_seq=2081504192
TCP: BA BB EE 05 C6 F2 55 7B FC 7A 0B 1D 6C 18 70 FC 6A F0 0A B3 D6 6C 89 BC 20 84 93 88 76 AB C3 C4 … : …U{.z…l.p.j…l… …v… …
using cached desync profile 4
not applying tampering to unknown protocol
packet: id=3035 reinject unmodified
packet: id=3036 len=1448
IP4: 192.168.1.192 => 173.194.187.8 proto=tcp ttl=127 sport=58700 dport=443 flags=A seq=1452414589 ack_seq=2081504192
TCP: 16 03 01 06 CA 01 00 06 C6 03 03 8A 74 DE 31 11 2F 07 E5 BA 24 3A B7 42 0F 2A 9F 51 0E 1A DC 42 … : …t.1./…$:.B..Q…B …
using cached desync profile 4
packet contains partial TLS ClientHello
not applying tampering to TLS ClientHello without hostname in the SNI
packet: id=3036 reinject unmodified
С стратегиями выше при обращении через TLS видео не грузятся совсем, сами страницы ютуба, комментарии и тд грузятся.
При модификации стратегии tcp=443 методом перебора и из результатов blockcheck - в основном также не работает, иногда грузится секунд 20 и потом начинает показывать видео. При использовании пакета “zapret-discord-youtube-1.4.0” на Win10 всё грузится сразу, из-за этого не могу понять причину где я косячу. Есть предположение, что там в правила используется конструкция
inbound and tcp and (tcp.Ack and tcp.Syn or tcp.Rst or tcp.Fin)…
Она, как мне показалось, похожа на tcpflags syn,ack, но я никак не смог её адаптировать.
Пробовал
ipfw add 100 divert 989 tcp from any 80,443 to any tcpflags syn,ack in not diverted recv “$NETIF”
ipfw add 100 divert 989 tcp from any 80,443 to any tcpflags rst in not diverted recv “$NETIF”
ipfw add 100 divert 989 tcp from any 80,443 to any tcpflags fin in not diverted recv “$NETIF”
но не взлетело, все сайты перестают открываться
Этот лог выкушен из середины. Непонятно приходят ли входящие
ipfw add 100 divert 989 tcp from any 80,443 to any tcpflags rst in not diverted recv “$NETIF”
ipfw add 100 divert 989 tcp from any 80,443 to any tcpflags fin in not diverted recv “$NETIF”
Это может понадобиться только для autohostlist. Но даже при таком варианте не будут срабатывать реакции на http redirect 302/307. На BSD нет способа их выцепить, не перенаправляя все входящие
Спасибо за пояснения. Там лог приличный по размерам, взял сколько смог из консоли, под спойлер не смог разместить, приложил файлом
Входящие не приходят. Это конфликт фаеров.
Может и есть какой-то способ починить, но мне неизвестен он.
Можно спросить на гихабе в дискуссиях про pfsense. Может там подскажут.
А сейчас проще всего отказаться от autottl, autohostlist и входящих.
Использовать только pf тоже не получается из-за так и не пофиксенной проблемы в BSD
Понятно… Спасибо, что уделили мне время
А не подскажете, в opnSense те же грабли будут? В документации есть описание про OpenBSD, но можно ли пытаться применить описанные методы к opnSense?
Если имеется доступ к роутеру по ssh, то для доступа к файловой системе достаточно любого клиента с поддержкой SCP. Какой-нибудь тотал коммандер/фар менеджер или что там еще в ходу у виндузятников с этим легко справится.
Во! Да, оказывается, что даже для Far Manager есть плагин на основе WinSCP, это, конечно, весьма удобно. Так или иначе, виндузятникам придется скачать какой-то инструмент. По простоте всё выше перечисленное на мой взгляд одинаково.
Open в приставке к sense означает лишь открытую версию чего-то, напоминающего pfsense.
Точно не скажу.
Но оба основаны на FreeBSD и к OpenBSD не относятся
Грабли будут те же самые, потому что имеют отношение к FreeBSD
В Win10+ в достаточно новых билдах из коробки идет openssh, который включает в себя scp и sftp
кстати именно datanoack в любом виде (в виде добавки к любой стратегии ) напрочь ломает mail.yahoo.com
как долазит туда мистика… или и “должен” долазить как допустим md5sig ? но лишь тупой яху реагирует на сей признак…
pingploteer считает что на 10м хопе он когда как просто yahoo.com на 20м
а в зависимости от стратегии blockcheck предлагает ttl от 7 до 11 - т.е. уже не вариант
и в целом не понимаю как работает связка ttl и dpi-desync-fooling
в том смысле что дальше N хопа не полезит и dpi-desync-fooling (имхо)
но почему с ttl=8 + --dpi-desync-fooling открывает кабинет прова который на 7м хопе
а допустим ttl=7+ --dpi-desync-fooling уже не отрывает
равно как и ttl=8 без --dpi-desync-fooling тоже (но тут то ещё понятно)
НО ttl=11 + dpi-desync-fooling уже не открывает половину инета - сайты начиная 10го хопа зачастую. а как же тогда кабинет прова открывает? при ttl=8 + dpi-desync-fooling??? кабинет на 7м
Понял, благодарю за ответ
Оттуда же, откуда zapret 1.4 и 1.5.1 видимо ))
Data No ACK