Запуск tpws в контейнере

[rerime]

Привет, запускаю контейнер. Задача пока получить пропускание трафика через прозрачный прокси. tpws --uid=0:0 --no-resolve --bind-addr=0.0.0.0 --port=8080 --split-pos=1 --debug=2

Посылаю на него весь трафик 443.

/ip firewall nat add action=dst-nat dst-port=443 protocol=tcp src-address=192.168.1.166 to-addresses=192.168.2.2 to-ports=8080 chain=dstnat

Получаю в логах:

both SO_ORIGINAL_DST and IP6T_SO_ORIGINAL_DST failed !
Dropping connection to local address to the same port to avoid loop

При этом если зайти в сам контейнер, сайты снаружи доступны.

[bol-van]

ядро урезанное или ограничения контейнера

[rostov114]

EVENT mask 00000001 fd=3 accept
both SO_ORIGINAL_DST and IP6T_SO_ORIGINAL_DST failed !
Dropping connection to local address to the same port to avoid loop
Failed to add connection
epoll_wait

Чистая установка Debian последний версии. Гипервизор PVE. Параметры запуска /opt/zapret/tpws/tpws --user=tpws --bind-addr=0.0.0.0 --port=988 --hostspell=HOST --split-http-req=method --split-pos=3 --oob --debug=2 --uid=0:0 Параметры перенаправления в NAT такое же.

[bol-van]

возможно связано с разными нетворк неймспейсами редирект сделан из одного в другой, и инфа об оригинальном адресе назначения теряется это работает только в пределах одной системы в одном неймспейс

[vfeshenko]

Это, судя по всему, связано с тем, что tpws принимает трафик только из lo, а крутясь в контейнере, он принимает трафик на VETH контейнера, т.е. на внешний интерфейс с точки зрения tpws. К сожалению, в mikrotik нельзя внутри контейнера настроить правила iptables и выполнить DNAT с VETH контейнера на lo внутри контейнера (выполнив таким образом реализацию прозрачного прокси), так как отсутствуют необходимые права. Решением было бы снять ограничения только для lo, тем самым разрешив прямые подключения к tpws. К сожалению, режим socks неудобен, т.к. требует настройки со стороны браузеров и ломает концепцию прозрачного прокси.

[bol-van]

микрот с запретом однозначно пролетает или берите лом и на войну с производителем ломать до линух шелла

[rerime]

@bol-van а можно объяснить чего не хватает, трафик приходит в контейнер?

[bol-van]

я не изучал микрот. но видно, что там идет все не так, как в обычном случае трафик не рулится через контейнер редирект в другой неймспейс это как редирект на другой хост мета инфа теряется

[rerime]

Может есть альтернативы tpws?

[mikeS7]

для микротика (у меня получилось только под arm, на arm64 не работает) можно запустить связку tun2socks и tpws в socks режиме

[rerime]

@mikeS7 о круто, у меня как раз arm. Поделишься рецептом с комьюнити?

[bol-van]

проблема не в тпвс таким способом вы не запустите никакой прозрачный прокси обходные пути пусть ищут фанаты микроты я к ним не отношусь

[rerime]

@bol-van не был бы так уверен, встречал такую инструкцию для прозрачного прокси https://docs.diladele.com/tutorials/mikrotik_transparent_squid/mangling.html#rule-2-accept-https-traffic-from-proxy-box Если работает для squid почему не может работать для tpws?

Но у меня с tpws не взлетело. Плохо знаю сети.

[bol-van]

есть прокси которые разбираются что им делать исходя из передаваемых данных например хттп хедер host: или sni в тлс тпвс этого не делает ему система должна сообщить куда шло изначальное соединение это и называется мета информацией о ней знает только одна система. система сделала редирект она знает куда шло соед но потом это никуда не передается

тпвс это тцп прокси с функцией дурения некоторых известных протоколов или неизвестных протоколов. в общем случае вычленить кула лезли нельзя да и то в хттп только хост а не ип а сни может подменяться потому это ненадежно

[rerime]

@bol-van какую мета информацию ждет tpws? dst address, dst port каждого пакета на уровне L4? Может есть дока по архитектуре tpws, с интересом бы почитал.

[bol-van]

tpws не работает на пакетном уровне на уровне соединения получается информация через те самые ioctl из ошибки если редирект или днат иначе используется getsockname.это работает в режиме tproxy а если нет инфы то возвращается адрес локалхоста и срабатывает защита от цикла

[romkazor]

Связка с tun2socks выдает curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to youtube.com:443 хотч такой же конфиг с xray работает отлично

[bol-van]

эта проблема хоть как-то относится к запуску tpws в контейнере ? если нет, создавайте отдельную тему

[Kolobok12309]

@mikeS7 о круто, у меня как раз arm. Поделишься рецептом с комьюнити?

По данному посту поднимается tun2socks, в env PROXY нужно указать socks5://172.17.0.2:1080 (ip контейнера с tpws в режиме --socks)

https://forum.ixbt.com/topic.cgi?id=14:66554-129#post14020

Но мб дело в железе, мб сам tun2socks тормозит, но обход ютуба получаю на ~20% запроса курлом (указывая socks для него 100%)

[mikeS7]

@mikeS7 о круто, у меня как раз arm. Поделишься рецептом с комьюнити?

По данному посту поднимается tun2socks, в env PROXY нужно указать socks5://172.17.0.2:1080 (ip контейнера с tpws в режиме --socks)

https://forum.ixbt.com/topic.cgi?id=14:66554-129#post14020

Мой вариант здесь https://habr.com/ru/articles/838452/comments/#comment_27214474 Но мб дело в железе, мб сам tun2socks тормозит, но обход ютуба получаю на ~20% запроса курлом (указывая socks для него 100%)

Думаю, что проблема в настройке маршрутизации, а в микротике вариантов накосячить просто бесконечность )

[pselfin]

Статью на хабре удалили, пока вот нашел у автора в другом месте https://www.pvsm.ru/vpn/394656 И на всякий в ПДФ сохранил Решаем проблему блокировок (и YouTube) за 5 минут на роутере Mikrotik через контейнеры и без VPN.pdf