Сервер на двух адресах

[Novgor]

Всем привет, нужна помощь.
У меня сейчас сервер работает на адерсе x.x.x.57.
Хочу, чтобы он ещё работал с адреса x.x.x.8.
Добавил в конфиг сервера адреса в ListenIP=, но всё равно агенты не хотят подключаться, если указать в конфиге агента Server/ServerActive x.x.x.8. Ошибка:

1044591:20231208:094238.681 failed to accept an incoming connection: connection from "109.206.171.57" rejected, allowed hosts: "62.122.169.8"

Что упускаю ?
Нужно, чтобы сервер работал с агентами и с x.x.x.57 и с x.x.x.8.

[csr]

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

у вас что-то не сходится. с одной стороны вы пишите, что сервер уже работает с x.x.x.57, а ошибка говорит, что он не разрешен, а разрешен с x.x.x.8.

пришлите то, что вы указали в Server/ServerActive

проверьте маршрутизацию, т.к. при подключении к агенту (если используются пассивные проверки) сервер выбирает интерфейс (и ip адрес) согласно таблицам маршрутизации. и вообще у вас может быть ситуация, что пакеты приходят на первый интерфейс, а сервер пытается ответить со второго (это уже про активные проверки).

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

[Novgor]

Да, сейчас у меня всё работает на x.x.x.57. Я хочу, чтобы сервер работал ещё и на x.x.x.8, чтобы потом его мигририровать.

Я делал такие настройки:
В сервер я добавил ListenIP и указал ещё один адрес:

 
 root@zabbix:~# zabbix_server -V zabbix_server (Zabbix) 5.0.14​  root@zabbix:~# cat /etc/zabbix/zabbix_server.conf|grep Listen ListenIP=X.X.X.57, X.X.X.8

Агент я меняю адрес с .57 на .8 :

[ 0 1.9ms ] 05:37:17 root:~# zabbix_agentd -V zabbix_agentd (daemon) (Zabbix) 4.0.17  ​[ 0 4.8ms ] 05:37:24 s5161:~# cat /etc/zabbix/zabbix_agentd.conf|grep Server Server=X.X.X.8 ServerActive=X.X.X.8

И в итоге получаю ошибки:

 1845989:20231211:053846.923 failed to accept an incoming connection: connection from "X.X.X.57" rejected, allowed hosts: "X.X.X.8" 1845990:20231211:053901.308 failed to accept an incoming connection: connection from "X.X.X.57" rejected, allowed hosts: "X.X.X.8" 1845987:20231211:053916.285 failed to accept an incoming connection: connection from "X.X.X.57" rejected, allowed hosts: "X.X.X.8"

С сервера где расположен агент, я проверял доступность через телнет, порт доступен.

[csr]

На агенте вы заменили x.x.x.57 на x.x.x.8. Т.е. разрешены соединения только с x.x.x.8.
Хрустальный шар говорит, что у вас пассивные проверки, т.е. сервер инициирует исходящее соединение с агентом. А судя по логам, сервер делает это через x.x.x.57. Из-за этого у вас и ругань на неавторизованное соединение с x.x.x.57

То, что вы разрешили серверу получать входящие соединения это не означает, что он будет делать исходящие соединения с этих адресов. Откуда это будет происходить - настройка операционной системы (маршрутизации)

То, что вы проверяли соединение через телнет это ничего не говорит. При активном телнете посмотрите через netstat с какого ip адреса у вас происходит соединение и вы увидите, что это происходит с x.x.x.57.

По-простому - проблема не в заббиксе, а в сетевых настройках

[Novgor]

Если смотреть с сетевой стороны, то да, x.x.x.8 "зароучен" на x.x.x.57. Т.е. в данном случае, сетевые настройки не позволяют использовать сервер как я задумал.
И есть их "поменять", то всё должно заработать ?
Т.е. дополнительных настроек не требуется для активации сервера на втором адресе?

[Kos]

Просто, на всякий случай (см. документацию):
ListenIP - параметр, который указывает серверу Zabbix, на каких IP разрешено слушать, т.е. принимать входящие соединения.
SourceIP - параметр, указывающий серверу Zabbix, с каких IP инициировать исходящие соединения.
Разумеется, если там указываются какие-то IP явно, то эти адреса должны быть предварительно настроены на уровне операционной системы (и должна быть обеспечена корректная маршрутизация).

И ещё замечание в сторону: версия 5.0, хоть и LTS, но её поддержка уже прекращена с 31 мая этого года (кстати, последний релиз из линейки 5.0 - это 5.0.40, в то время как у вас 5.0.14). Ну и агенты 4.0.17 - они, конечно, совместимы с 5.0.х, но последний релиз линейки 4.0.х был 4.0.50 (ну, или хотя бы 4.0.35)...

[Novgor]

Просто, на всякий случай (см. документацию):
ListenIP - параметр, который указывает серверу Zabbix, на каких IP разрешено слушать, т.е. принимать входящие соединения.
SourceIP - параметр, указывающий серверу Zabbix, с каких IP инициировать исходящие соединения.
Разумеется, если там указываются какие-то IP явно, то эти адреса должны быть предварительно настроены на уровне операционной системы (и должна быть обеспечена корректная маршрутизация).

И ещё замечание в сторону: версия 5.0, хоть и LTS, но её поддержка уже прекращена с 31 мая этого года (кстати, последний релиз из линейки 5.0 - это 5.0.40, в то время как у вас 5.0.14). Ну и агенты 4.0.17 - они, конечно, совместимы с 5.0.х, но последний релиз линейки 4.0.х был 4.0.50 (ну, или хотя бы 4.0.35)...

Насчёт версий серверной части я как раз и планирую всё обновить до актуальных версий. Но для начала мне нужно мигрировать сервер в другой место, и адрес x.x.x.57 я не смогу сохранить. Поэтому и хочу, чтобы до миграции сервер мог работать с двумя адресами.
С документаций я ознакамливался, но проблема в том, что SourceIP не работает с 2 ипами. Поэтому и решил попросить консультации тут.

zabbix_server [40380]: ERROR: invalid "SourceIP" configuration parameter: 'x.x.x.57, x.x.x.8'

В то время как адрес х.х.х.8 работает полноценно:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 10000
    link/ether 00:25:90:4f:ce:c0 brd ff:ff:ff:ff:ff:ff
    inet x.x.x.57/24 brd 109.206.171.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet x.x.x.x.8/32 brd 62.122.169.8 scope global eth0:1
       valid_lft forever preferred_lft forever

​

Просто даже если дело в самом адресе x.x.x.8, я могу его заменить, повесить тэгированый Влан и выделить оттуда x.x.x.x/24. Но насколько я понимаю, всё равно по SourceIP будет инициировать исходящие соединения с адреса x.x.x.57. И у меня не получится задумка, что я заранее все агенты переключать на новый адрес, и всё продолжает рабоать на старом физическом сервере, но с нового адреса, который я в последствии смогу перенести на новый физический сервер.

[Kos]

Я не знаю, как серверу объяснять, с какого IP-адреса инициировать исходящие соединения для разных агентов (в зависимости от... чего, собственно?).

Если бы мне нужно было поменять IP сервера, я бы выбрал один из подходов:

• "резать к чёртовой матери, не дожидаясь перитонитов!", т.е. просто в какой-то вечер или выходные поменять IP на сервере и синхронно - в настройках всех агентов (агенты после этого нужно перезапустить). Понятно, что тут будет некоторый даун-тайм (т.е. время простоя), но он будет запланированный. Свести его к минимуму можно, предварительно подкорректировав конфиги на агентах; тогда после смены IP-адреса на сервере останется только их перезапустить. Если есть какой-то механизм, как это сделать централизованно, то это облегчит задачу. Как вариант - можно, наоборот, организовать перезапуск агентов с помощью метрики system.run[...], а адрес на сервере поменять сразу после этого.
• поднять второй IP-адрес на сервере, и переводить на него агентов по одному, а затем убрать с сервера первый адрес.

Как я понимаю, вы пытаетесь идти как раз вторым путём. В этом случае нужно учитывать, что сервер, наверное, сможет отвечать на запросы к нему, отправленные по любому из адресов, а вот сам будет инициировать соединения только с одного из них. Поэтому данный путь, возможно, окажется более трудоёмким, т.к. настройки агентов придётся корректировать несколько раз:

• поднимаем второй IP-адрес на сервере (т.е. кроме адреса x.x.x.57, добавляем ещё x.x.x.8).
• на агентах меняем параметр "Server=", указывая там оба адреса. Таким образом, пассивные проверки будут выполняться независимо от того, с какого адреса они пришли.
• (можно делать одновременно с предыдущим пунктом) - меняем на агентах параметр "ServerActive=", указывая там "новый" адрес x.x.x.8 (и перезапускаем агентов для перечитывания конфига). Поскольку на сервере этот адрес уже поднят (и, надеюсь, маршрутизация есть), то агенты продолжат работать, как и раньше: за активными проверками будут ходить по новому адресу, а на пассивные проверки отвечать, несмотря на то, что они приходят со старого адреса.
• когда прошлись по всем агентам, то либо убираем с сервера старый IP-адрес вообще, либо прописываем в его конфиге параметр "SourceIP=" с новым адресом (в любом случае, сервер Zabbix придётся перезапустить). С этого момента все коммуникации будут идти с использованием нового адреса, но старый останется в конфигах агентов в параметре "Server=" в качестве мусора, который потом не спеша можно будет зачистить.

Как-то так...
Возможные подводные камни - ситуация, если сервер на запросы, направленные по новому адресу, будет слать ответы со своего старого адреса. Тогда такие ответы будут игнорироваться (но тогда должна быть ругань в логах агентов, следует это проверить на каком-нибудь одном, чтобы убедиться, что такой подход работает).

[Novgor]

Я не знаю, как серверу объяснять, с какого IP-адреса инициировать исходящие соединения для разных агентов (в зависимости от... чего, собственно?).

Если бы мне нужно было поменять IP сервера, я бы выбрал один из подходов:

• "резать к чёртовой матери, не дожидаясь перитонита!", т.е. просто в какой-то вечер или выходные поменять IP на сервере и синхронно - в настройках всех агентов (агенты после этого нужно перезапустить). Понятно, что тут будет некоторый даун-тайм (простой), но он будет запланированный. Свести его к минимуму можно, предварительно подкорректировав конфиги на агентах; тогда после смены IP-адреса на сервере останется только их перезапустить. Если есть какой-то механизм, как это сделать централизованно, то это облегчит задачу. Как вариант - можно, наоборот, организовать перезапуск агентов с помощью метрики system.run[...], а адрес на сервере поменять сразу после этого.
• поднять второй IP-адрес на сервере, и переводить на него агентов по одному, а затем убрать с сервера первый адрес.

Как я понимаю, вы пытаетесь идти как раз вторым путём. В этом случае нужно учитывать, что сервер, наверное, сможет отвечать на запросы к нему, отправленные по любому из адресов, а вот сам будет инициировать соединения только с одного из них. Поэтому данный путь, возможно, окажется более трудоёмким, т.к. настройки агентов придётся корректировать несколько раз:

• поднимаем второй IP-адрес на сервере (т.е. кроме адреса x.x.x.57, добавляем ещё x.x.x.8).
• на агентах меняем параметр "Server=", указывая там оба адреса. Таким образом, пассивные проверки будут выполняться независимо от того, с какого адреса они пришли.
• (можно делать одновременно с предыдущим пунктом) - меняем на агентах параметр "ServerActive=", указывая там "новый" адрес x.x.x.8 (и перезапускаем агентов для перечитывания конфига). Поскольку на сервере этот адрес уже поднят (и, надеюсь, маршрутизация есть), то агенты продолжать работать, как и раньше: за активными проверками будут ходить по новому адресу, а на пассивные проверки отвечать, несмотря на то, что они приходят со старого адреса.
• когда прошлись по всем агентам, то либо убираем с сервера старый IP-адрес вообще, либо прописываем в его конфиге параметр "SourceIP=" с новым адресом (в любом случае, сервер Zabbix придётся перезапустить). С этого момента все коммуникации будут идти с использованием нового адреса, но старый останется в конфигах агентов в параметре "Server=" в качестве мусора, который потом не спеша можно будет зачистить.

Как-то так...

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

[csr]

описывать для потомков, если честно нечего.

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

но переезд можно сделать так:

1.а если у вас на сервере два адреса и эти адреса находятся в разных подсетях (по вашей записи это не понятно), то у вас на сервере два шлюза. в таком случае указывайте в таблице маршрутизации сервера явно: хост1 ходить через шлюз1, хост2, ходить через шлюз2. таким образом все пакеты на хост1 будут ходить через первый шлюз, хост2 через второй. SourceIP в конфигурации сервера не трогайте. он сам будет подставлять нужный адрес в зависимости от таблицы маршрутизации

1.б если у вас на сервере два адреса и эти адреса находятся в одной подсети, то делайте подобную маршутизацию непосредственно на маршрутизаторе

2. если можете использовать/перейти на активные проверки (т.е. клиент сам высылает информацию о себе), то в агенте используйте dns имя сервера. как переедете, измените в dns и больше нигде ничего менять не надо. для минимизации простоя, предварительно уменьшите ttl на dns сервере.

[Alex_UUU]

Вопрос интересный, но, имхо, сложного ничего нет.
ss -ltup покажет какие адреса и порты слушает какой процесс. Если zabbix-server слушает оба - значит Ок.
Если в агенте указать оба адреса в параметре server и activeserver то агент будет слать данные по обоим адресам, и они, соответственно, будут задваиваться.
В любом случае для обоих адресов c сервера
nmap -S сервер агент -p10050
и агента
nmap сервер -p10051
должны быть в open
Сомневаюсь, что в SourceIP можно указать 2 адреса (и логика говорит, что 2 нельзя)
А вот в ListenIP надо указать 0.0.0.0, тогда будет слушать все по указанному порту (10051)

[Kos]

Если в агенте указать оба адреса в параметре server и activeserver то агент будет слать данные по обоим адресам, и они, соответственно, будут задваиваться.

Это не совсем так.
Замечание верное для параметра ServerActive (кстати, важно правильное написание имени параметра, вплоть до регистра букв) - в этом случае, действительно, агент будет пытаться слать данные активных проверок по обоим адресам, и данные будут дублироваться.
В случае параметра Server ничего страшного происходить не будет - этот параметр влияет только на то, с каких адресов разрешено принимать запросы на пассивные проверки.