RoffDaniel, полезная теория описана в документе Linux Advanced Routing and Traffic Control HOWTO. Лучше всего все возможности современной маршрутизации iproute2 описаны там.
Вот что нужно сделать:
1. Описать новые таблицы маршрутизации в файле /etc/iproute2/rt_tables. В принципе, это необязательный шаг, так как можно использовать числа вместо имён, но с именами будет удобнее. Имена можно выдать по смыслу. Например, добавим туда:
20 lan1
30 lan2
2. После этого можно смотреть таблицы маршрутизации по имени командой ip ro[ute] l[ist] t[able] имя_таблицы (имена параметров можно сокращать), например:
ip route list table lan1
ip ro l t lan2
Кстати, обычная (дефолтная) таблица маршрутизации называется main, если не указывать table, то подразумевается именно она.
Нам нужно добавить в эту таблицу маршруты для нужного интерфейса. Их должно быть два: один - маршрут до местной сети этого интерфейса, другой - default через шлюз.
Смотрим какие уже есть в main:
ip ro l|grep ens18
Видим что-то типа (я взял у себя по своему Wi-Fi-интерфейсу wlp4s0, а не стал сочинять возможный вывод под задачу):
default via 10.7.8.1 dev wlp4s0 proto dhcp src 10.7.8.174 metric 303
default via 10.7.8.1 dev wlp4s0 proto dhcp metric 600
10.7.0.0/24 via 10.7.8.2 dev wlp4s0 proto zebra metric 20
10.7.8.0/24 dev wlp4s0 proto dhcp scope link src 10.7.8.174 metric 303
10.7.8.0/24 dev wlp4s0 proto kernel scope link src 10.7.8.176 metric 600
Первый маршрут - это который scope link, второй - default. В нашем случае надо будет добавить что-то типа такого:
ip ro add 10.0.20.0/24 dev ens18 scope link src 10.0.20.251 table lan1
ip ro add default via 10.0.20.254 table lan1
ip ro add 10.0.30.0/24 dev ens19 scope link src 10.0.30.251 table lan2
ip ro add default via 10.0.30.254 table lan2
3. Теперь у нас есть две таблицы, в которых есть нужные маршруты, но система всё равно выбирает маршруты main. Для управления этим процессом есть другая команда - ip ru[le]. По умолчанию она показывает:
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
Тут видны ещё 2 таблицы, которые существуют всегда - local и default. Можно на досуге посмотреть, что в них есть. Сейчас наша задача - вставить перед lookup main выбор наших таблиц при некоторых условиях.
ip ru add from 10.0.20.251 lookup lan1
ip ru add from 10.0.30.251 lookup lan2
Теперь правила выглядят так:
0: from all lookup local
32764: from 10.0.30.251 lookup lan2
32765: from 10.0.20.251 lookup lan1
32766: from all lookup main
32767: from all lookup default
Теперь система при маршрутизации для трафика с исходящим адресом 10.0.30.251 будет сначала заглядывать в таблицу lan2, а если там не будет подходящего маршрута (с чего бы ему не быть, если там есть default?) - пойдёт дальше по правилам в main.
Если трафик инициируется на самом сервере (исходящие соединения), то он пойдёт по маршрутам таблицы main, где по-хорошему должен быть только один default route (или больше, но с разными метриками, чтобы при падении одного default route был запасной).
Остаётся вопрос, как это всё поднять вместе с настройкой интерфейса, ведь все наши действия относятся только к рантайму, они исчезнут при перезагрузке, а в случае интерфейсов с настройкой по DHCP - и при временном пропадании связи либо при смене IP.
В centos7 можно было создавать статические роуты (в том числе с указанием таблиц) в файлах route-ИНТЕРФЕЙС, а правила - в rule-ИНТЕРФЕЙС - в каталоге /etc/sysconfig/network-scripts. Насколько мне известно, в centos8 network-scripts выпилили, но я пока с ним не имел дела и не изучал, чем их можно заменить.
В случае с DHCP я в своё время просто сделал скрипт, который вызывался из DHCP hook, определял IP и создавал все недостающие правила. У меня там ещё и маршрутизация по fwmark использовалась (чтобы правильно роутить транзитный трафик, серверу недостаточно маршрутизации по source address, нужно также "красить" коннекты с помощью connmark).
AVKor, вопрос был конкретным: "КАК ПЕРЕНАПРАВИТЬ ВВОД ИЗ КОНВЕЕРА". Рассуждения о том, что автор якобы хотел сделать тупой cat (для которого и цикл лишний), есть попытки выдать желаемое за действительное.
AVKor, ничего я не разбил. Вопрошающий не понимал, как вывод "цепочки" комманд передать в цикл. Как в "цепочке", так и в самом цикле могли быть более сложные действия.
Это, к слову, не единственный вариант, можно было сделать и так:
while read line
do
...
done < <(cat sorted | cut -f 1 -d ' ' | uniq)
Более того, в некоторых задачах так даже лучше, потому что в первом варианте цикл запускается в subshell, а во втором в subshell запускается "цепочка" (хотя это можно переопределить опцией lastpipe).
Omolix, чтобы пользователем root присоединиться к базе testbase, надо сделать mysql -uroot testbase. Или выполнить в клиенте mysql команду use testbase;
Соответственно, что удаётся присоединиться к базе root пользователем root не имеет никакого отношения к невозможности присоединиться к базе testbase.
