LINUX.ORG.RU

torxy — прозрачный HTTP/HTTPS-прокси, позволяющий перенаправлять трафик на выбранные домены через TOR-сервер

 ,


3

4

Представляю вниманию первую публичную версию своей разработки - прозрачный HTTP/HTTPS-прокси, позволяющий перенаправлять трафик на выбранные домены через TOR-сервер.

Проект создавался для повышения комфорта доступа из домашней локальной сети к сайтам, который может быть ограничен по разным причинам. Например, магазин homedepot.com недоступен по географическому признаку.

Возможности:

  • Работа исключительно в прозрачном режиме, настройка требуется только на роутере;
  • Для HTTPS название домена извлекается из SNI, если таковой имеется;
  • Неопознанный (не HTTP и не HTTPS) входящий TCP-трафик обрабатывается «как есть»;
  • В правилах редиректа в TOR поддерживаются поддомены;
  • Список правил формируется пользователем самостоятельно;

>>> Страница проекта



Проверено: anonymous_incognito ()
Последнее исправление: unfo (всего исправлений: 4)
Ответ на: комментарий от vimusov

Чем это лучше privoxy?

Поддержкой SNI. Без этого в современных интернетах, где HTTPS уже стал нормой жизни, прокси бесполезен чуть более, чем полностью.

SNI скоро закроют и перейдут на ESNI, потом на еще что-то..

Лучше делать класический MitM всего ssl и принимать решение на основе разшифрованного трафика.

anonymous
()
Ответ на: комментарий от necrus

Privacy Pass

будет тебе счастье

но для этого я так понимаю придется лисицу впендюрить? спасибо мне такого счастья не надо…

anonymous
()
Ответ на: комментарий от qwe

man syslog

man journalctl

И смотрим там ключ --output=json. syslog ничего подобного не предоставляет даже близко.

vimusov
() автор топика
Ответ на: комментарий от mord0d

у какого-нибудь rsyslogd какие-то проблемы с логгированием по уровням?

Оно там крайне примитивное. journald сохраняет куда больше информации, чем просто текстовое сообщение, timestamp и уровень логирования.

vimusov
() автор топика
Ответ на: комментарий от anonymous

Лучше делать класический MitM всего ssl

Разумеется, SNI это лишь временная мера. C HTTP/2 и HTTP/3 это уже не прокатит. И MITM тоже не прокатит, даже уже сейчас - потому что HSTS и Certificate pinning говорят ему «ахахадавайдосвидания».

vimusov
() автор топика
Ответ на: комментарий от vimusov

А почему нельзя сделать вывод в stderr/stdout, а логгирование оставить на откуп иниту/запускатору? Do one thing and do it well.

mord0d ★★★★★
()
Ответ на: комментарий от vimusov

Оно там крайне примитивное. journald сохраняет куда больше информации...

В данном случае это не информация, а мусор не несущий полезной информации.

qwe ★★★
()
Ответ на: комментарий от mord0d

По современным стандартам сам текстовый формат с одной лог записью на строчку уже не «do it well». Структурированый лог может быть многострочным, может содержать произвольные пары ключ-значение, может ссылаться на родительский контекст какой-то вроде «все логи в результате обработки вот этого HTTP запроса». И тут даже thread ID логировать не помогает если это сервер с зелеными потоками.

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

Другое дело что ТС этим не пользуется

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от anonymous

Дык HSTS сразу взорвется на половине Интернета. Вырезать его из страниц? Вычищать из браузера?

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 2)
Ответ на: комментарий от vertexua

Другое дело что ТС этим не пользуется

Как раз таки пользуюсь. Именно потому и затащил в зависимости биндинг к systemd, чтобы взять из него JournalHandler.

vimusov
() автор топика
Ответ на: комментарий от zimmin

Как у тебя выглядит файл /etc/torxy.rules? Запости в репо.

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

vimusov
() автор топика
Ответ на: комментарий от anonymous

но для этого я так понимаю придется лисицу впендюрить? спасибо мне такого счастья не надо

Privacy Pass 2.0 available in Chrome and Firefox, а разве сегодня бывают ещё какие-то браузеры? ) Кстати на Лису не гони, я на ней со времён Мозилы и пока замены не вижу. Вот, почитай хотя бы статейку https://restoreprivacy.com/browser/secure/

necrus ★★★
()
Ответ на: комментарий от vimusov

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

А зачем тогда код самого прокси выложил? Твой код кому-то может не понравиться, или кому-то не подойти - у всех ведь разные потребности, разный стиль написания, разные вкусы.

zimmin
()
Последнее исправление: zimmin (всего исправлений: 1)
Ответ на: комментарий от vertexua

Да в этом конкретном случае всё это не нужно. А где нужно — делай логи у себя как нужно.

mord0d ★★★★★
()
Ответ на: комментарий от vimusov

Выкладывать конкретные конфиги нет никакого смысла.

Есть смысл ходя бы показать примеры, как это МоЖеТ выглядеть. Больше примеров - это хорошо. Чтоб был объяснен синтаксис конфига с примерами.

anonymous
()
Ответ на: комментарий от anonymous

Есть смысл ходя бы показать примеры, как это МоЖеТ выглядеть

Пример конфига есть в примере пакетирования. Также есть подробное описание самих правил. Что ещё добавить - не знаю. Чего точно не будет - так это конкретных списков правил, ибо они у каждого свои.

vimusov
() автор топика

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

anonymous
()
Ответ на: комментарий от qwe

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

Демонизация силами приложения плоха тем, что её надо писать в каждом приложении отдельно, и её потом трудно дружить с супервизорами. Если не дружить, тогда супервизор не может, собственно, следить за живостью процесса, что является одной из его главных задач.

Проверка раз в секунду, что приложение успешно запустилось или процесс умер — тоже так себе, выглядит как костыль, да и в systemd units и upstart jobs запихивать куски шелла неудобно и странно.

configtest и последующий запуск покрывают не все случаи (например, невозможность занять порт), и этот способ подвержен TOCTOU-гонкам.

Вот с логами проблема более-менее решена — приложение пишет логи в stdout, а супервизор перенаправляет в логгер. А универсального (не завязанного, например, на systemd) и общепринятого способа уведомления об успешном запуске, насколько мне известно, пока не появилось.

Как сейчас лучше поступить разработчику нового приложения? Пойти первым путём, и пусть дальше голова болит у package maintainer’ов? Или сделать всё под systemd (а не sysvinit, upstart, runit, так как мейнстрим), но так, чтобы при отсутствии systemd всё не слишком сильно ломалось (не оборачивать sd_notify в assert)? Или просто забить на уведомления, и пусть страдает эксплуатация? А может быть есть какой-то ещё способ, про который я не знаю?

kmeaw ★★★
()
Ответ на: комментарий от anonymous

Не могу найти скриншотов

Скриншоты чего именно вы хотели бы увидеть? Программы без интерфейса, работающей на роутере, у которого ни Х-ов, ни даже монитора нет? Такое бывает только в художественных фильмах про какеров.

vimusov
() автор топика
Последнее исправление: vimusov (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.