Al_Ko, мне всё равно трудно всё это понять. У задачи есть более простое решение, причём максимально наивное и топорное. Можно просто одному делать запросы в нулевую секунду минуты, а второму - в 30 секунду минуты.
Al_Ko, это вообще не так делается. Если имеется источник, из которого можно взять данные, то можно, например, сделать промежуточный прокси-сервис, который будет брать данные и никогда не отдавать одно и то же разным своим клиентам.
Герман Шестак, судя по длине кода, это похоже на SHA256. Но браться он может от чего угодно, что так легко не угадать. Например, от посоленного секретным словом полного URL. На этой стадии видимо придётся попробовать декомпилировать игру и попытаться найти в ней соответствующее место.
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).
