iddqda

не CentOS (с ним не знаком)
но у меня был интересный опыт обновления Убунты с 14.04 на 16.04
в процессе обновления сетевые интерфейсы получили новые имена вида enoX или ensY
А настройки в /etc/interfaces прописаны для старых ethX, так что сеть при настройке не настроилась и не поднялась

диагностика простая

iddqd@iddq:~$ dmesg | grep eth[01]
[    1.874054] e1000 0000:02:00.0 eth0: (PCI:66MHz:32-bit) 00:50:56:11:11:11
[    1.874672] e1000 0000:02:00.0 eth0: Intel(R) PRO/1000 Network Connection
[    2.237540] e1000 0000:02:02.0 eth1: (PCI:66MHz:32-bit) 00:50:56:11:11:12
[    2.238185] e1000 0000:02:02.0 eth1: Intel(R) PRO/1000 Network Connection
[    2.240464] e1000 0000:02:02.0 ens34: renamed from eth1
[    2.243988] e1000 0000:02:00.0 ens32: renamed from eth0

Ставьте линукс сервер на балконе (или VPS) и цепляйтесь к нему ssh+tmux
а для поиграть сервисы geforce now или google stadia (обещали в ноябре запустить)

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

ну т.е.

sudo add-apt-repository -r 'deb [arch=amd64,arm64,ppc64el] http://mirror.realcompute.io/mariadb/repo/10.4/ubuntu bionic main'
apt update
apt install mariadb-server

затем то же самое без ключа -r в первой команде

Я делаю вот так
1. в snmptrapd прописываю OID трапа, который хочу ловить и обрабатывать и путь к обработчику
примерно вот так:

traphandle .1.3.6.1.4.1.9.9.315.0.0.1 /etc/zabbix/externalscripts/traphandlers/cisco-psec-traphandler.py
traphandle .1.3.6.1.4.1.9.9.548.0.1.1 /etc/zabbix/externalscripts/traphandlers/cisco-psec-traphandler.py

2. обработчики пишу на питоне. на перле уже даже моя бабушка не пишет.
3. в Заббиксе создаю item типа zabbix_trapper на хосте, который мониторю, точнее в шаблоне, который потом вешаю на хост.
4. из самого обработчика вызываю zabbix_sender который шлет нужное значение на нужный хост по ключу item-а созданного в 3-м пункте

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

Реализован сплит днс, внутри сети идешь по локальному ip, снаружи по публичному

и продолжаем с этого места...
изнутри еще какой то отдельной сети идешь по третьему ip
из другой отдельной сети по четвертому итп
1-й 2-й 3-й 4-й ip поизвольные. могут сопадать. или даже быть не ip (а запись), а srv txt итп
короче, сплит днс - не ограничивается 2-мя зонами.

з.ы.

tls + ipsec будет больно

не будет если tls будет внутри ipsec, а не наоборот.

Вы похоже не очень хорошо разбираетесь в сетях
В результате неверно интерпретируете выводы Wireshark и идете ложным путем

поясните три момента
1.

приложения не видят устройства других сетей, хотя ping и TCP/ip соединения идут

что вы имеете ввиду под глаголом "видят"?
2.

Как сделать, чтоб при получении пакета о составе сети роутер сообщил о сетях за VPN?

Ваши приложения используют протоколы динамической маршрутизации?
3.

Как сделать чтоб роутер перенапрявлял L2 броадкаст по L2 туннелю к сетям?

Здесь конечно полная каша, но может имеется ввиду прокси-арп?

А что куда роутить? может Л3 коммутатор надо?
просто если edge то это куда?
интернет с ip телефонией и видео отпадает наверное
значит не в интернет. В филиалы? А там тоже 700+ юзеров?
а может в ДЦ? толщина каналов какая?

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

1. поначалу наверное хватит.
2. после установки не увидишь. но взаимная поддержка файловых систем есть и там и там. просто настроить нужно будет.
3 и 4. можно если убунту сразу ставить сразу на LVM

перед тем как настраивать Заббикс, надо в систему поставить и настроить unixODBC и ODBC драйверы для нужной СУБД

Сначала добиваешься чтоб отработала команда isql -v TEST
Затем настраиваешь переменные окружения для демона заббикс
И только потом ковыряешь заббикс-фронтенд

держи ссылки полезные:
https://www.zabbix.com/documentation/3.4/manual/co...
https://habr.com/en/post/226365/

на линуксе разворачиваете nextcloud (можно готовый applience в виде VM, docker или snap)
Затем на iPad, iPhone, Android, Mac или Windows ставите клиента nextcloud
и затем кидаете что угодно с любых устройства на сервер и обратно

возможно это поможет Мега-Учебник Flask, Часть XXII: Фоновые задачи

А вы только в сети провайдера ходите?
а на тостер как попали?
ответьте себе на простой вопрос: что означает самая первая строчка в вашей таблице маршрутизации?

уверен что не работает?
тут нужна поддержка VRF-Aware NAT т.е. несколько таблиц трансляций
циска знает что если пакет прилетел в интерфейс в VRF1 то и маршрутизировать и натить будет по соответствующим таблицам. Ничего в конфиг для этого отдельно прописывать не нужно.

И это старая фича. уже минимум лет 8 в IOS-ах такое реализовано

что за железяка?

используй драйвер macvlan https://docs.docker.com/network/macvlan/

вот так примерно делается:

docker network create -d macvlan --subnet=10.2.4.96/16 --gateway=10.1.1.1 -o parent=eno1 mac_net
docker run --net=mac_net --ip=10.2.5.5 -it --rm busybox
/ # ping 10.1.2.10 -c 1
PING 10.1.2.10 (10.1.2.10): 56 data bytes
64 bytes from 10.1.2.10: seq=0 ttl=63 time=0.423 ms

docker run --net=mac_net --ip=10.2.5.6 -it --rm busybox
/ # ping 10.1.2.10 -c 1
PING 10.1.2.10 (10.1.2.10): 56 data bytes
64 bytes from 10.1.2.10: seq=0 ttl=63 time=0.423 ms

при этом tcpdump запущенный на хосте показывает такое:

10:29:07.257561 IP 10.2.5.5 > 10.1.2.10: ICMP echo request, id 1536, seq 2, length 64
10:29:07.257924 IP 10.1.2.10 > 10.2.5.5: ICMP echo reply, id 1536, seq 2, length 64
10:29:26.101902 IP 10.2.5.6 > 10.1.2.10: ICMP echo request, id 1536, seq 0, length 64
10:29:26.102431 IP 10.1.2.10 > 10.2.5.6: ICMP echo reply, id 1536, seq 0, length 64

При обращению на внешний интерфейс port forwarding работает.

ОК

При обращении на белый ip не работает

обращении откуда?
если изнутри, то правильно не работает

смотри
S - внешний адрес сервера
s - внутренний адрес сервера
c - внутренний адрес клиента
(src->dst) - IP пакет с адресами источника и назначения

1. вы посылаете пакет от клиента на внешний адрес сервера (с -> S)
2. пакет проходит файрвол, который делает порт-форвардинг т.е. натит внешний адрес в внутренний
пакет пр(c -> s)
3. сервер получает этот пакет и отвечает пакетом (s->c) т.е. в качестве исходящего адреса используется внутренний адрес сервера.
4. клиент получает пакет от сервера, но он ждет пакет от адреса S а получает от адреса s
поэтому он его отбрасывает и ждет дальше

чтоб побороть такое поведение используют два подхода:
1. hairpinning - это когда используют левую сеть для трансляциии пакетов от внутренних клиентов к внутренним сервисам
2. dnz view когда для внутренних клиентов DNS держит отдельную зону с внутренними адресами.