Как использовать дополнительные адреса на интерфейсе?

policy based routing

погугли и почитай

писать долго и лень

https://www.opennet.ru/docs/RUS/LARTC/

«Команда ipinfo.io/ip» (имеется ввиду наверное curl http://ipinfo.io/ip) делает исходящее соединение, а не входящее.

Входящие соединения должны слать исходящие пакеты с того адреса, на который это соединение пришло. В одном терминале запусти tcpdump -i any tcp port 22, а во втором терминале сделай ssh сессию на второй адрес своего VPS. В первом терминале увидишь входящие пакеты со второго адреса VPS.

Это разжевано чуть больше чем много раз только на этом форуме. Ищите «два провайдера». Кратко так: defroute из таблицы main идет лесом, отправляем в отдельные таблицы. И рулим с помощью ip rule + по необходимости маркировкой пакетов.

Хм. Попробую.

Curl, по идее и должен слать исходящие пакеты. Это ж проверка видимого у VPS IP? Просто не совсем понятно, почему при подключении к доп. адресу, он не идет как маршрут по-умолчанию.

Для моей головы это странно. Если есть, условно, два адреса 10.20.30.40 и 100.200.300.400, то при иницировании соединения со вторым, ответ должен приходить от него же, а не от первого.

Возможно, там какие-то приоритеты, по крайней мере добавление новых таблиц и правил, не работает, вероятно, потому, что основной маршрут в какой-то из таблиц давит все остальные условия, так что придется с нуля создавать…

Ясень пень, что в лк первый помечен как основной, но хотелось бы чтобы IP, к которому подключаешься, подхватывался автоматом)

Поищем)

Я не понял твою проблему. Что значит «При подключении к серверу по второму IP, исходящие пакеты шуруют через первый»? Что ты понимаешь под «подключением к серверу по второму IP»? Что ты понимаешь под «исходящими пакетами»? С чего ты взял, что у тебя что-то перенаправляется?

Например, при подключении по SSH. У сервака 2 IP.

1. Подключение по 1 адресу (основному):

ssh user@10.20.30.40 -p 22 > curl ipinfo.io/ip > 10.20.30.40

2. Подключение по 2 (дополнительному, он же ens3:0):

ssh user@100.200.300.400 -p 22 > curl ipinfo.io/ip > 10.20.30.40.

(Подключился ко второму, а сервер все равно использует первый для выхода в сеть.)

3. Подключение по 2 (используем явное указание о том, с какого адреса слать пакеты):

ssh user@100.200.300.400 -p 22 > curl –interface 100.200.300.400 ipinfo.io/ip > 100.200.300.400.

На практике это означат, что несмотря на подключение к серверу по адресу 100.200.300.400, я захожу на ютуб с адреса 10.20.30.40, если явно не указал иное непосредственно на сервере.

Как-то так)

На практике это означат, что несмотря на подключение к серверу по адресу 100.200.300.400, я захожу на ютуб с адреса 10.20.30.40, если явно не указал иное непосредственно на сервере.

Для локальных процессов, в зависимости от того на какой адрес вы зашли по ssh, это более другое шаманство будет. Точнее сначала локальное шаманство в котором «в зависимости от», а уж потом сверху прикручиваем обертку по определению на какой ip залогинились через ssh. Это две несвязные части, сначала научитесь просто локальные процессы выпускать через разные ip.

Буду пробовать.

Я немного поковырял маршрутизацию: добавление таблиц или правил не дает никакого эффекта.

Сервер как будто автоматом хватается за таблицу main, в которой по дефолту прописан маршрут к «ens3». Вне зависимости от приоритетов, метрик, правил и таблиц используется тупо основной адрес для выхода в сеть, если явно не указать иное.

Помогают только дедовские способы:

1. Снести маршрут по умолчанию из таблицы main и создать новый, уже с указанием 2 IP.
2. Снести 1 адрес на интерфейсе. Тогда идет автоматическое переключение на второй адрес.

Может, это какие-то настройки вне сервера. VMmanager от провайдера может буянить?) Скорее всего, можно будет попробовать отключить автоприсвоение адресов и накатить адрес вручную с двумя отдельными интерфейсами.

К сожалению, PBR не прокатил, ну или я рукожоп))

Сервак вцепился в табличку main и клал на остальные болт. По крайней мере выглядит именно так, ибо доп. таблицы ничего не изменяют или, может, что-то есть, но не в видимой части - сервер упирается в основной ап, пока его не снесешь. Какая-то неведомая мне автоматика)

Попробую покурить)

Сервер как будто автоматом хватается за таблицу main, в которой по дефолту прописан маршрут к «ens3». Вне зависимости от приоритетов, метрик, правил и таблиц используется тупо основной адрес для выхода в сеть, если явно не указать иное.

Не сервер, а используемый им dhcp клиент. В зависимости от самого клиента разные решения up/down скрипты и разные опции запрещения автоматизации прописывания того, что получили от dhcp сервера. В целом задача сводится к двум пунктам:
1. Нам не надо что бы dhcp клиент делал «что-то» автоматом (это «что-то» может быть настроено избирательно).
2. В up-down скриптах прописываем то, что нужно нам сделать из того, что не умеет dhcp клиент из каробки.

Так должно быть и это не поменять. Для сервера запуск curl всегда одинаковый, вне зависимости от того, куда ты заходил. Можешь попробовать на уровне виртуалок или контейнеров это реализовать, должно получиться.

Какая связь между ssh и curl-ом? Куда ты подключлся по ssh - дело исключительно ssh, никаким боком это никаких других прог не касается.

За ip-адрес, используемый для исходящих соединений (не пиши «пакетов» - а то получается чушь) отвечают сами программы - они могут его выбрать, например у телнета для этого есть ключ -b. У курла сам читай ман есть ли аналог (я им не пользуюсь и не знаю).

В хорошей ОС (FreeBSD) проге можно навязать правильный исходящий адрес с помощью простой команды jail (jail / x 1.2.3.4 твоя-команда вместо 1.2.3.4 ставишь желаемый исходящий адрес), линукс так не умеет но у него наверно есть что-то похожее, но требующее предварительно потратить день на изучение и чтение всяких простыней.

https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/configuring_and_managing_networking/configuring-policy-based-routing-to-define-alternative-routes_configuring-and-managing-networking#routing-traffic-from-a-specific-subnet-to-a-different-default-gateway-by-using-nmcli_configuring-policy-based-routing-to-define-alternative-routes

Те, кто предложил policy routing (PR) - не прочитали внимательно ТЗ.

Раз у тебя 1 интерфейс и один шлюз, то тут нет надобности в PR.

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

для ping/curl/wget можно явно указать каким адресом пользоваться.

для транзитного трафика просто делаешь SNAT на любой из этих адрсов.

А если нужно сменить дефолтный адрес с которого будет ходить сервер, то

ip ro change default via 10.0.0.1 dev ens3 scope link src xxx.xxx.xxx.xxx

Какая связь между ssh и curl-ом? Куда ты подключлся по ssh - дело исключительно ssh, никаким боком это никаких других прог не касается.

Curl нужен просто чтоб проверять с какого IP-адреса идет исходящие соединение. Суть не в SSH, можно подключится любым протоколом, который позволят через сервер выходить в интернет.

За ip-адрес, используемый для исходящих соединений (не пиши «пакетов» - а то получается чушь) отвечают сами программы - они могут его выбрать, например у телнета для этого есть ключ -b. У курла сам читай ман есть ли аналог (я им не пользуюсь и не знаю).

Не особо важна какая программа на сервере ломится в интернет, нужно, чтобы было автоматическое переключение адресов (маршрутов).

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

Попробую.

Так должно быть и это не поменять.

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

Хм. Попробую покопать автоматику.

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

А если оно не умеет?

через LD_PRELOAD.

PR можно использовать если нужно сделать привязку к адресу по UID или порту/протоколу

нужно, чтобы было автоматическое переключение адресов

По какому критерию?

Не особо важна какая программа на сервере ломится в интернет, нужно, чтобы было автоматическое переключение адресов (маршрутов).

Это НЕ маршруты, это привязка исходящего адреса.

Это значит, если я подключился к серверу по 2 IP (по любому протоколу),

Ещё раз, твоё «подключение к серверу» это работа программы, принимающей это подключение, и никому, кроме этой программы, это не интересно, никаких глобальных эффектов от этого нет.

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

через LD_PRELOAD.

Если я правильно понял вашу мысль, то это уже не совсем «просто должно уметь указывать локальный адрес».

Он хочет, чтобы при заходе с помощью ssh на сервер через eth0 все программы, запущенные из этой сессии уходили через eth0. И если зашел через eth1, то, соответственно, все шло через eth1.

Это чушь. curl-у по барабану откуда залез тот кто его запустил (через физического терминала, или какого-то специального серверного IP).

Все просто. Коннектясь по ssh (скажем, по «2 порту») создается двухнаправленная! :)) сессия (tcp connection) - ssh отсылает текст к серверу, сервер присылает обратно текст в ответ - по той же одной и той же самой коннекции. И все это происходит по «2 порту» (т.е. сервер отвечает исходящим текстом через тот же самый IP адрес, на котором ему и пришел входящий текст из ssh).

Какой адрес будут пользовать ДРУГИЕ проги для соединений с интернетом (незавасимо запущенные с ssh-логина, с физического терминала, по таймеру кроном, или еще как-нибудь) - совершенно отдельный «вопрос». Они будут пользовать по умолчанию тот IP кто «дефолтный на выход» (пока специально не указано другое). И по-другому и быть не может.

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

Вариант с LD_PRELOAD хорош тем, что не требует никаких привилегий. После connect он сам делает bind на указанный адрес. Теоретически, можно проанализировать кто запустил, что запустил, куда коннектился и на основании этого выбрать адрес.

Есть вариант с загоном всех в проксю которая решает с какого адреса пойти.

Либо варианты с PR на основе TOS/uid/port.

По входящему подключению.

Если есть подключение по любому протоколу (ssh, https, socks и прочее) из вне к 2 IP, то этот второй IP и используется для выхода в интернет самим сервером. По-умолчанию на сервере гвоздями прибит основной адрес, а второй никак не используется для исходящих запросов, если это явно не указать.

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

Это НЕ маршруты, это привязка исходящего адреса.

Она самая. Чат гопота мне говорила, что сие мона провернуть мухлюя с маршрутами.

Ещё раз, твоё «подключение к серверу» это работа программы, принимающей это подключение, и никому, кроме этой программы, это не интересно, никаких глобальных эффектов от этого нет.

Ну вот, нужно, чтобы «интерес» появился) Автоматика для ленивых жоп: «Так, я сервер и я вижу, что ты подрубился к N2, значит используем N2 для исходящих подключений. Погнали!».

Это чушь. curl-у по барабану откуда залез тот кто его запустил (через физического терминала, или какого-то специального серверного IP).

Почему «чушь»? Суть ведь не меняется)) Замени eth на IP или на A\B\C.

Это простое, как палка, условие: Если мы выбрали 2, то и используем всем сервером 2. Если 3, то 3, если 4, то 4.

Какой адрес будут пользовать ДРУГИЕ проги для соединений с интернетом (незавасимо запущенные с ssh-логина, с физического терминала, по таймеру кроном, или еще как-нибудь) - совершенно отдельный «вопрос». Они будут пользовать по умолчанию тот IP кто «дефолтный на выход» (пока специально не указано другое). И по-другому и быть не может.

Плохо, что не может, не удобная шляпа тогда получается. Даешь автоопределение!)

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

Хм… если я куплял мороженное, то, вероятно, основная популяцию человеков должна увидеть у меня в руках мороженное, а не дробовик))

Чат гопота мне говорила

Вот и общался бы дальше с этим бредогенератором, зачем на форум пошёл?

Странная предъява. Чую обидки по поводу того, что я, по вашему, не понял, что вы хотели сказать выше) А если серьезно, чтоб попросить помощи, что, я считаю, очевидно. Зачем ещё ходить на технический форум?

Предъява в том что ты не только попытался получить ответ у бредогенератора, но ещё и принёс этот бред сюда и пытаешься заявлять будто это авторитетная истина.

Они будут пользовать по умолчанию тот IP кто «дефолтный на выход» (пока специально не указано другое). И по-другому и быть не может.

Плохо, что не может, не удобная шляпа тогда получается. Даешь автоопределение!)

Автоопределение чего? /dev/urandom ?

Почему «чушь»? Суть ведь не меняется)) Замени eth на IP или на A\B\C. Это простое, как палка, условие: Если мы выбрали 2, то и используем всем сервером 2. Если 3, то 3, если 4, то 4.

Потому что чушь.

Насчет «сути»:

Скажем, ты запустил curl не заходя через remote ssh-сессию (через какого-то IP), а тупо через физическую консоль/клаву на COM/PS2 порту (можно и через pts/tty, не суть).

Теперь что, curl -X «GET» «www.mail.ru» должен выслать GET request не через дефолтном IP на гейтуей - а вместо того, срать его тебе обратно в консоль что ли, потому что ты «зашел через консоль» и curl должен «использует то же на выход» из чего «зашел тот, кто ее и запустил»?

А если это крон запустил curl по таймеру, через что curl будет посылать свой «GET» запрос, как будет работать «автоопределение»? В крон ведь гет реквест (и вообще любых данных) засунуть обратно нельзя.

Чушь это несусветная.