Перевод пакетов из туннеля в прокси-коннект (tun to socks,http,...)

преобразовывать пакеты из tun0 в прокси-коннект и обратно

Как ты себе представляешь преобразование dns udp или icmp пакета в соединение?

точно так же как и для системного vpn подключения?

curl вполне себе справляется с таковым.

Запусти squid и направь его policy-based роутингом в тот интерфейс (а слушает пусть 127.0.0.1 куда браузер и будет подключаться).

сплит-туннелирование

Какие-то плохие словечки.

как осуществить этот policy-based роутинг наиболее простым способом? вот и ищу конкретную прогу, которая сразу бы всё превращала.
Мне хочется что бы было типа OpenVPN-socks5-proxy как будто.

Какие-то плохие словечки.

а в чём плоховость? возможно я не вник в мем какойто...

кажется нашлось решение — throne

получается что direct-подключение на tun0 делает то что я и хотел — а сам он высылает на прокси-подключение, по параметрам в настройках.

Не знаю.

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

ipfw fwd адрес_гейта ip from any to any jail название_контейнера_с_прогой

(вместо jail можно другие признаки для распознавания трафика проги использовать на твой выбор)

ip netns, засовываешь туда свой tun0 и браузер.

freebsd хорошая система. но сча вот на арче...

ухх... спасибо за похоже очень дельную наводку — давно я не рыскал в туллинге для сетей.

только вопрос — а как за счёт netns связать tun0 и сам неймспейс? или ты подразумевал, что каким-то иным способом это сделать?

а как за счёт netns связать tun0 и сам неймспейс?

RTFM

ip netns set dev <device> netns <namespace>

ip netns set dev <device> netns <namespace>

что-то это думается невалидное...

Любой http или socks прокси, лучше http, потому что они все умеют по доменам посылать в разные места. У меня на роутере пара tinyproxy и три socks. socks забиндены на разные интерфейсы (использую ciadpi - он и как легковесный просто socks хорош), tinyproxy по большой таблице масок доменов раскидывает на один из трёх ciadpi. Второй tinyproxy - для разрешённых для ребёнка сайтов (белый список).

ip netns, засовываешь туда свой tun0 и браузер.

Вот из-за таких как ты потом у людей ядро банальный route add игнорирует.

Сложно, очень сложно…

Ну вот у него dante почему-то не работает..
Похожую проблему я вижу тут (stackexchange.com), но там не совсем понятно почему curl --interface отрабатывал.

Так я tinyproxy использую - он умеет socks пиром делать.

я понимаю, но у ТС проблема с биндингом socks прокси (dante) на tun интерфейс.

да — у меня тоже curl в tun0 интерфейс нормально отправляет.

а, я вроде понял, что с dante - там, похоже, вообще не используется опция SO_BINDTODEVICE. Даже если указать имя сетевого интерфейса, то он просто возьмет его IP, что недостаточно (не будет работать корректно без source-based routing).
Из умеющих SO_BINDTODEVICE socks-прокси - https://github.com/dariost/soks (по наводке отсюда)

засмотрел код — выглядит на первый взгляд очень прилично — подобно как мне думалось про таковую реализацию.
Возможно стоит её взять как референс на пути возделывания С++ кода (жаль лицензия MPL2, а не GPL).

думается можно ставить [РЕШЕНО].

Для этого не надо править заголовок в ерунду, надо просто нажать «Отметить как решённую»

route add устарел уже лет на 20

Да я понял, когда обнаружил, что теперь тоннель за NAT через тоннель за NAT сроутить сильно сложнее, чем 20 лет назад.

https://github.com/slingamn/namespaced-openvpn

Для вг тоже есть готовое, если самому лень.

ну хз хз... дата последнего коммита напрягает слегка:
https://github.com/slingamn/namespaced-openvpn/commit/a3fa42b2d8645272cbeb685...
(slingamn committed on Sep 3, 2020)

Так а что там коммитить? Он простой и работает.

вопрос в актуальности самой программы — вполне возможно она уже кривовасто работает поскольку что-то могло поменяться из того что она юзает, в том числе как я понял, что она на py2, хотя уже давным давно юзается py3

#!/usr/bin/python3 ну что ты выдумываешь? Использую этот скрипт каждый день уже много лет.

не. я про другое. что в пингвине уже лет 20 точно стандарт - ip ro a

ну, там много всего добавили. На фоне всё ещё живого ipfw в FreeBSD это прям либо простые случаи, либо разбираться, что от чего зависит - т.е. обычные правила уже не работают, а default route может ставиться в разных местах (ну ещё это и собственные погремушки OpenWRT в uCI)

а, так у тя не пингвин, а фря?

тогда поздравляю с выпиливанеим последних GPLей из CURRENT и приобщением фри к дырам, найденных ИИ!

Я не очень понял о чем речь, но обычно трафик пускают в socks, а далее в tun. Напрямую только через iptables. Есть готовые утилиты для последнего. В Линуксах нет программ с кнопкой вкл/выкл впн, или я плохо искал

Не, я страдаю с OpenWRT, а там - linux + uCI. Я неделю приводил в понятное состояние «включил и работай» тревел-роутер, чтобы он поднимал до моей квартиры тоннель из любой сети, прозрачно для своих клиентов. Главное веселье было - состыковать интерфейсы, NAT роутинг и роутинг. То у NAT гонка подъёма роутинга, то uCI в неочевидном порядке поднимает.

Руками поднимаешь-прописываешь - всё работает. перезагружаешь - вроде роутинг такой же, а ничего не работает.

Вроде бы, дело оказалось в (L)uCI - она творчески перезапускает скрипты своего фаервола при перезапуске некоторых интерфейсов, и иногда не совсем корректная настройка начинает работать. И вот в этом состоянии я два дня искал, почему после этого при ребуте не работает.

В этом плане FreeBSD - это образец UI/UX.

Новость на опёнке: Альтернативная расширенная сборка PuTTY, поддерживающая файловые сессии. Лучший комментарий там: Отдельно хочется поздравить всех пользователей ФриБСД с обновлением UI для их любимой ОС.