Товарищи, я себе уже весь мозг сломал, прошу помочь советом.
ByeDPI не дает устанавливать соединения через себя, в браузере
Secure Connection Failed An error occurred during a connection to . PR_CONNECT_RESET_ERROR
в консоль же при этом пишет connect to self, ignore.
Но с чего бы он подключается к себе - ума не приложу…
Локально на Win byedpi работает нормально. Но конечная цель сделать ресурсы общедоступными на всей сети, для этого задействована малина с OpenWRT 23.05.
В качестве прокси выступает Byedpi в режиме transparent proxy (на него трафик заводится через ruantiblock, но тестировал и напрямую).
Запущен сейчас с параметрами ./ciadpi-armv7l -E -i 192.168.11.5 --debug 2 --tlsrec -5+se --fake -5 --ttl 5 --tls-sni www.google.com, где 192.168.11.5 - IP малины. Порт 1080 открыт и доступен.
На просторах гитхаба нашел собранный под OpenWRT ipk, но история с ним аналогичная.
С чем может быть связана ошибка, в каком направлении смотреть?
Где установлен ruantiblock и как он настроен? Как настроен iptables/nftables? И при чём здесь порт 1080, если (цитирую) в режиме прозрачного прокси, SOCKS работать не будет?
Скорее всего не настроена правильно схема предотвращения зацикливания.
byedpi сам генерит трафик, и если его опять перехватить и опять направить на byedpi, получится loop.
Обычно это предотвращается через запуск под специальным юзером и исключением юзера из редиректа. Либо отказ от редиректа трафика, исходящего с самой системы
Может быть еще и ошибка в выборе socks/transparent режима.
Транспарент прокси некоторые привыкли толковать в понятиях squid.
Когда на него можно DNATнуть откуда угодно, и он срабатывает.
Здесь это не так. squid анализирует трафик для выяснения адреса назначения.
tproxy работает через метаданные ОС. Если их нет, то будет connect to self
Короче, надо технически разбирать как устроена вся схема, а если используется стороннее решение, то еще и выяснить что оно делает и как реализует заявленную функцию
Насчет транспарента - возможно в этом дело, протестирую. Со стороны ruantiblock у меня было настроено перенаправление через redirect, а не tproxy.
Если не поможет, то надо будет смотреть на отключение редиректа
ruantiblock установлен на этом же узле, на малине. Насчет порта - нет никакой разницы какой порт использовать, если нет конфликта. SOCKS я у себя не использую. Можно поменять на 1101, к примеру, и, вероятно, я это позже сделаю, но что это изменит сейчас?
iptables не задействован, в nft никакого криминала. Попробую сейчас переключить в режим tproxy перенаправление трафика, как предложил bolvan, если не поможет, то направлю настройки nft.
Вот что интересно… В режиме перенаправления tproxy на ruantiblock не заработало, вернул обратно на redirect. По предложению BBS поменял порт на 1101, думаю с чем черт не шутит. И все, похоже заработало! По крайней мере несколько девайсов сейчас перенастроил на использование малины в качествe шлюза и у них доступ к ресурсам появился.
Выходит, что
- Надо использовать кастомный порт
- в режиме transparent proxy byedpi работает через redirect
Проведу сегодня дополнительные тесты
Между tproxy и redirect/dnat технически разница небольшая.
В первом случае адрес получается через getsockname, во втором через ioctl SO_ORIGINAL_DST и IP6T_SO_ORIGINAL_DST.
В обоих случаях используются метаданные ОС, что делает невозможным перенаправление с другой системы или другого нетворк неймспейса (контейнера).
Похоже, ruantiblock создаёт разный набор правил nft для разных режимов t_proxy_type. Интересно, какие именно правила он создаёт. Жаль что эта штука не умеет одновременно использовать больше одного проксика (как xray), мне бы такой маршрутизатор пригодился.
То, что при смене порта всё заработало - это намёк на то, что порт 1080 уже кем-то занят. netstat -tulpn
И последнее, почему вы не используете zapret вместо связки ByeDPI+ruantiblock?
Netstat смотрел конечно, как без него . И у меня на 1080 ничего не висит 
Ну как бы то ни было, заработало и хорошо)
Умеет, но в ограниченном виде. Один прокси будет основным с возможностью подключения обновляемого списка доменов, еще до 5 проксей можно задействовать по статично заданным спискам (либо для конкретных IP клиентских, например).
Почему не zapret… До этого я предполагал его подключить. Стратегии подобрал, запустил с nfqws - и оно не заработало. Повозился сколько смог, так и не смог добиться работы. Изучение доступной документации не помогло, дебаг оказался весьма проблематичным, решил рассмотреть альтернативу.
Но также чем интересно было настроить byedpi с ruantiblock - возможность 3 режимов работы:
- обычный трафик идет без каких-либо изменений
- трафик к заблокированным ресурсам идет через byedpi
- дополнительно можно явно указать что заворачивать на byedpi или VPN
Ну и это все управляется через luci, что плюс.
Спасибо, появился повод потестить эту штуку. Жаль что оно не умеет работать с zapret, но я чего-нибудь придумаю.