кто-нибудь поднимал dns-сервер, который бы автоматически отправлял все *.i2p на localhost:4444, а прочие адреса резоливил бы также как и 8.8.8.8? поделитесь конфигом, позязя
DNS-сервер занимается разрешением имен, а не перенаправлением запросов к серверам на определенные порты. Потому "автоматически отправлял все *.i2p" он в принципе решить не может, максимум, на любой запрос из зоны "i2p." отдавать 127.0.0.1или [::1] (без порта, разумеется), а дальше сам ебись фаерволом или чем еще, если i2p поддерживает прозрачное проксирование.
Задача "прочие адреса резоливил бы также как и 8.8.8.8?" уже в дефольных конфигах любого DNS-сервера решена (root-сервера в качестве хинтов для зоны ".").
@etw Фейл, у меня i2p только на 127.0.0.1 слушает, но дела это не меняет
$ dig +tcp hiddenchan.i2p @127.0.0.1 -p 4444
;; communications error: connection reset
@anonim У меня это решено проще - для i2p отдельный инстанс привокси. Благо, systemd позволяет довольно просто сделать один конфиг для запуска неограниченного количества разных инстансов одного демона.
@l29ah Во-первых, не умеет (у него внутре своя система разрешения имен). А, во-вторых, на 4444 висит HTTP прокся, за каким хуем ты подумал, будто она станет сервить DNS запросы, ума не приложу.
@l29ah Создавать TCP-туннели в уеб-гуйне и2п на нужных портах до нужных сервисов. Собственно, на 4444 висти особый уличный TCP-туннель, редиректящий все на false.i2p.
@l29ah Ну ты сам подумай, вот будет у тебя торчать из i2p демона TCP-порт, с которым ты будешь пытаться разговаривать по хуй-знает-какому протоколу. Как i2p-демон должен догадаться, что твой, например, msgpack-encoded-custom-ftp-over-ssl надо всенепременно послать на определенный хост в сети i2p?
@l29ah Это туннели уровня приложений, который прозрачно в TCP/IP не переводится. Если в Tor можно накостылять поддержку исходящих TCP-соединений, потому что в конечном итоге он предоставляет соединение с конкретным IP-адресом, то внутри I2P даже IP-адресов нет.
@l29ah Это будет работать только для протоколов, внутри которых не содержится зависимых от адресации данных, т. е. установили соединение — дальше само течёт. Однако такие соединения через I2P и так спокойно создаются через менеджер туннелей с подключением приложения к локальном порту. Можно рассмотреть хотя бы прикручивание ничего не подозревающего TCP/IP bittorrent-клиента к I2P.
@l29ah Там DNS-прокся не для onion-сайтов, а для обычных. Т.к. луковичным сайтам нечего ответить на A-запрос, т.к. IP-адресов у них нет. Разрешение имен работает по-другому: ты, когда делаешь запрос, обращаясь через SOCKS к tor-демону, сообщаешь, что хотел бы подключиться, например, к xmh57jrzrnw6insl.onion, а он внутри у себя определяет уже, что это такой-то луковичный сайт и надо обратиться к такому-то hidden-сервису. Нигде здесь протокол DNS участия не принимает.
@etw В общем, у тора роль такого универсального протокола, через который можно сообщить демону, куда ты хочешь обратиться, исполняет SOCKS. i2p же работает через туннели до конкретных eepsite-s, т.к. там, похоже, считают SOCKS неуниверсальным. При этом есть костыли для парсинга HTTP, IRC и SOCKS, и в конфиге по-дефолту включены только HTTP и IRC.
@ceyt Заебись мастурбировать на каждый чих через вебню небось.
Да, в таких случаях без адаптации никак. Но это не релевантно проксицирку для остальных случаев.
@ceyt И ещё тебе понадобится протокол для оповещения участников сети о том, какие виртуальные IP-адреса приложения, висящие на неких туннелях, думают, что используют. И ещё автоконфигурация, чтобы они не повторялись.
@l29ah Прозрачное проксирование подразумевает, что прокся умеет самостоятельно извлекать из трафика адрес назначения, куда надо подключиться и так пока что делают только HTTP-прокси для соответствующего трафика.
@l29ah Мы про L7 протоколы речь ведем. Если ты хочешь подключиться к onion/i2p сайтам, у которых нет IP-адреса, то выдирать тебе из заголовков IP-пакетов нечего. В проксированием нормального IP ради простого проксирования IP без обработки вышележащих протоколов никто ИРЛ, кроме фаерволов/роуторв/L3-свитчей не занимается по причине бессмысленности.
@l29ah Ниче, пустой ответ. Нет таких записей. Могу еще так сделать для полной уверенности
$ dig +short -t any @localhost -p 9053 kpvz7ki2v5agwt35.onion
$
@l29ah В контексте любых программ и протоколов, которым нужно что-то сложнее, чем однократные исходящие TCP-соединения. Хотя бы общеизвестный FTP возьми, в коором сервер должен прислать свой адрес и порт для соединения с данными.
в общем, специалисты, я поднял виртуальный сетевой интерфейс, редирекчу на него все .i2p, на этом интерфейсе слушает nginx, но тут у меня пробел в познаниях. как в nginx превратить запрос GET /index.html HTTP/1.1\r Host: echelon.i2p в GET http://echelon.i2p/index.html HTTP/1.1 и сделать ему proxy_pass http://127.0.0.1:4444?
@hirthwork i2p прозрачное проксирование не умеет? Если умеет, можешь просто редиректить все прям на него iptables-ом, он сам из Host-а все, что надо достанет.
@l29ah Хорошо, берём тупейшую поебень. netcat открывает порт 12345 и слушает его. Как твоя система догадается, что нужно создать серверный туннель? Значит, ручками, ручками. Значит, только клиентские прогаммы и протоколы.
@l29ah Ты какой-то L2 VPN внутри готового туннеля I2P представляешь, а я говорю о том, что при исходящих соединениях на фальшивые IP-адреса прозрачный прокси может заставить I2P создать туннель (или воспользоваться пулом уже существующих) на указанный в виде домена/B32 адресат, а вот регистрировать адресат и создавать серверный туннель для открытого локально соединения получится только руками.
@ceyt Программа, по своим интимным причинам, решает слушать какой-то порт. Извне ты никак до неё не достучишься, пока не создашь в I2P серверный туннель, передающий данные в этот порт, и не сообщищь неким образом адресат этого туннеля клиентской стороне.
@ceyt Можно, конечно, замапить все порты на один адрес, но это потребует автоматического создания виртуальных интерфейсов и скрытых сервисов для каждой программы.
@stiletto поздняк. я уже поднял dnsmasq все запросы в *.i2p уже отправляются на отдельный виртуальный айпишник, если ничего не придумаю к вечеру, то просто на этой айпишнике подниму наколеночную проксю на джаве
@l29ah пасяб
Любишь экстрим и адреналин? Пей Red Bull!
Их всех надо сажать в темницу и кормить через трубочку только тем, что нужно.
несекурно, иди нахуй
@etw пук
@l29ah Это туннели уровня приложений, который прозрачно в TCP/IP не переводится. Если в Tor можно накостылять поддержку исходящих TCP-соединений, потому что в конечном итоге он предоставляет соединение с конкретным IP-адресом, то внутри I2P даже IP-адресов нет.
@l29ah Это будет работать только для протоколов, внутри которых не содержится зависимых от адресации данных, т. е. установили соединение — дальше само течёт. Однако такие соединения через I2P и так спокойно создаются через менеджер туннелей с подключением приложения к локальном порту.
Можно рассмотреть хотя бы прикручивание ничего не подозревающего TCP/IP bittorrent-клиента к I2P.
@ceyt И ещё тебе понадобится протокол для оповещения участников сети о том, какие виртуальные IP-адреса приложения, висящие на неких туннелях, думают, что используют. И ещё автоконфигурация, чтобы они не повторялись.
@ceyt А вручную для нескольких адресатов ты и сейчас можешь сделать, никто не запрещает.
@l29ah В контексте любых программ и протоколов, которым нужно что-то сложнее, чем однократные исходящие TCP-соединения. Хотя бы общеизвестный FTP возьми, в коором сервер должен прислать свой адрес и порт для соединения с данными.
в общем, специалисты, я поднял виртуальный сетевой интерфейс, редирекчу на него все .i2p, на этом интерфейсе слушает nginx, но тут у меня пробел в познаниях. как в nginx превратить запрос
GET /index.html HTTP/1.1\rвHost: echelon.i2p
GET http://echelon.i2p/index.html HTTP/1.1и сделать емуproxy_pass http://127.0.0.1:4444?@hirthwork я могу такую проксю на джаве запилить за полчаса, но кажется, что ещё одного велосипеда мой сервер просто не выдержит
@etw кто там «сам достаёт»? iptables?
@etw нет, если послать запрос на /index.html и передать Host, то она ругается
@l29ah Хорошо, берём тупейшую поебень. netcat открывает порт 12345 и слушает его. Как твоя система догадается, что нужно создать серверный туннель? Значит, ручками, ручками. Значит, только клиентские прогаммы и протоколы.
@hirthwork Первая ссылка в гугле: https://ef.gy/using-nginx-as-a-proxy-server
@l29ah У тебя туннеля нет, откуда ты пакет возьмёшь?
@l29ah Ты какой-то L2 VPN внутри готового туннеля I2P представляешь, а я говорю о том, что при исходящих соединениях на фальшивые IP-адреса прозрачный прокси может заставить I2P создать туннель (или воспользоваться пулом уже существующих) на указанный в виде домена/B32 адресат, а вот регистрировать адресат и создавать серверный туннель для открытого локально соединения получится только руками.
@ceyt сам то понял чего сморозил?
@hirthwork Всё по описанию.
@l29ah Как DNS отреагирует на открытый netcat'ом порт?
@ceyt Программа, по своим интимным причинам, решает слушать какой-то порт. Извне ты никак до неё не достучишься, пока не создашь в I2P серверный туннель, передающий данные в этот порт, и не сообщищь неким образом адресат этого туннеля клиентской стороне.
@l29ah Они там виртуальные, и всё равно сопоставляются 1:1.
@l29ah Ну, destination, ёба.
@l29ah RTFM.
@ceyt Можно, конечно, замапить все порты на один адрес, но это потребует автоматического создания виртуальных интерфейсов и скрытых сервисов для каждой программы.
@stiletto поздняк. я уже поднял dnsmasq все запросы в *.i2p уже отправляются на отдельный виртуальный айпишник, если ничего не придумаю к вечеру, то просто на этой айпишнике подниму наколеночную проксю на джаве
@krkm ага. щас на айфон фоксипроски заебошу