Proxy (http(s)/SOCKS4/5) -> VPN client -> Internet

Начнем с простого вопроса. А с сервера у вас как трафик ходит через vpn или напрямую?

К серверу нет особой привязки, мне нужно чтобы у меня был прокси сервер, на выходе которого ip любой vpn сети к которой подключен сервер.

Проще говоря мне нужно proxy2vpn

Еще раз, сервер на котором установлен прокси, при поднятии впн как в инет идет, через этот впн или напрямую?

По сути это таже конфигурация, что и при обычном прокси сервере, например 3proxy, только в качестве external интерфейса, не ip сервера, а интерфейс tun0 vpn тунеля. Кажется, что просто нужно указать в external для 3proxy ip тунеля, или tun0 для dante proxy. Но это не работает, прокси сервера стартуют, но в сеть клиента который юзает эту проксю - не пускает. Если меняю на ip хоста или на eth0, проксик работает как надо. Но трафик идёт как и ожидается не через vpn соединение (vpn client)

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

А теперь посмотрим на таблицу роутинга. Куда пакетики должны лететь если у вас единственный defroute?

Я не очень хорошо разбираюсь в сетевых протоколах, можете мне дать схему что и как нужно сделать. Можно без комманд, чтобы я понимал алгоритм действий. Из исходных данных у меня следующие:

1) сервер с выходом в интернет и vpn сервером 2) сервер с прокси 3) мне нужно чтобы когда я ввожу данные от прокси сервера, например в браузере, у меня был доступ в интернет с ip первого сервера

На сервере #2 я могу ставить любое по и производить любые настройки.

Даже не знаю что и ответить, когда знаний ноль, читайте документацию. Вас интересует iproute2 и iptables tutorial
И «Сети для самых маленьких» почитайте.
Но быстрое близкое к вам направление это гугленье по подключению двух провайдеров.

Наискосок. Создаем отдельную таблицу $TABLENAME в /etc/iproute2/rt_tables
Шаманство простое. Если у вас прокся запускается от отдельного пользователя, то создаете правило в iptables маркируещее пакетики по его uid $MYVPNMARK
Создаете правило в ip rule в духе ip rule add fwmark $MYVPNMARK table $TABLENAME
При поднятии впн создаете в отдельной таблице default route, что-то типа ip route add default via $IPGW dev $DEVNAME table $TABLENAME.

ЗЫ Как совет. Для тестирования не обязательно сразу пользовать проксю, на локальном пользователе сервера с его UID протестируйте работу роутинга для начала.

Я нашел тут тему с подобным вопросам, вы там давали рекомендации по настройке

Перенаправлять трафик в tun0 при использовании прокси

Перенаправлять трафик в tun0 при использовании прокси

По сути мне нужно именно это.

Может быть вы сможете мне помочь?

Допустим у меня есть сервер. На нем есть интерфейсы eth1 (10.10.10.1) и tun0 (11.11.11.1)

Я поднимаю на этом сервере 3proxy, если в конфиге я указываю external 10.10.10.1 (eth0) и затем подключаюсь к прокси, то все гуд. На клиенте который выходит в сеть через прокси, внешний ip сервера (10.10.10.1).

Теперь я хочу указать параметр external в конфиге 3proxy равным 11.11.11.1 (tun0) - если подключаюсь к прокси - интернет не работает.

Что мне нужно добавить в правила / роутинг чтобы все заработало?

Вам нужно добавить маршрут через VPN, каким-либо способом. Можно добавить маршрут по умолчанию с метрикой выше, чем у текущего маршрута по умолчанию через интернет-провайдера (не гарантирую, что заработает, но по логике должно), либо, как говорит anc, создать несколько таблиц маршрутизации, и пакеты от прокси-сервера помещать в таблицу маршрутизации с маршрутом по умолчанию в VPN, а все остальные пакеты — в обычную таблицу маршрутизации, с маршрутом по умолчанию через интернет-провайдера.

Вам нужно добавить маршрут через VPN, каким-либо способом. Можно добавить маршрут по умолчанию с метрикой выше, чем у текущего маршрута по умолчанию через интернет-провайдера (не гарантирую, что заработает, но по логике должно)

Не вариант, ТС пишет «Мне и не нужно чтобы сервер выходил в сеть через впн»

Я нашел тут тему с подобным вопросам, вы там давали рекомендации по настройке

Там тема была другая. Или я вас не понял. Нарисуйте схему.

Так он и не будет, если у VPN-интерфейса будет метрика выше. Зато при bind к интерфейсу будет использоваться он, а не тот, у которого метрика ниже. Только что проверил на curl — работает, но только от root, от обычного пользователя:

setsockopt(3, SOL_SOCKET, SO_BINDTODEVICE, "wlp3s0\0", 7) = -1 EPERM (Operation not permitted)

Интерфейс мы конечно забиндим. А что с роутингом будет?

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

Хм интересное решение. Никогда не предполагал даже что так может работать. Век живи век учись. Спасибо.
Проверил на том же curl действительно работает. В кач-ве дополнений.
У меня в main defroute нет, отдельные таблицы на каждого прова.
На слаке и из под пользователя тоже работает. Но если где-то и не работает, согласно ману по curl можно установить CAP_NET_RAW

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

Полноценная маршрутизация работать без дополнительных таблиц и ip rule не будет.

Да я не столько про задачу ТС, сколько про ваше описание. Когда бинд на интерфейс использует таблицы роутинга именно этого интерфейса. Вот о чем не знал. Всегда считал что мухи отдельно, котлеты отдельно. Еще раз спасибо!