sudo rm -rf /, вообще говоря, нужно наоборот напрячься, чтобы dhcp не прописал шлюз. Разве только в этой системе уже есть интерфейс с аналогичной подсеткой, тогда такое я могу представить.
Можно попробовать с debug позапускать dhcp-клиент (какой он там? dhclient скорее всего).
В дебианобразиях пакет libpython3-dev. В шляпных - python3-devel. В других искать тоже что-то подобное. Ну и надо будет их подключить к реальной сборке.
Sand, вряд ли, в debian/ubuntu штатного selinux нет, так что взгромоздить его ещё надо умудриться: достать refpolicy из unstable-ветки, собрать, поставить, разглючить...
RoffDaniel, чтобы не плодились правила в ip rule при каждом вызове скрипта, можно явно указывать preference правил - то число, которое написано в начале правила:
ip ru add from 10.0.20.20 p 20 lookup lan1
ip ru add from 10.0.30.30 p 30 lookup lan2
Тогда на существующие правила будет выдаваться ошибка и они не будут добавляться ещё раз.
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 (для которого и цикл лишний), есть попытки выдать желаемое за действительное.
