/me не очень понимает в работе Pacemaker+Corosync (wtf?), но для того, чтобы объединить 2 сети в одну "нормальную" (имея при этом 2 маршрутизатора) - нужно правильно настроить маршрутизацию. либо делать нат (но это "на любителя")
Маргрутизацию я могу как автомат Калашникова разбирать и собирать с закрытыми глазами. Проблема не в этом. Даже если маргрутизация настроена криво, но всё равно хост, с которого пытаемся что либо пропинговать, кинет соответствующий icmp echo-request на интерфейс, на котором определен хотя бы маршрут по умолчанию. Но не станет сам определять, что ремутный хост недоступен. У меня же на сетевых интерфейсах - полная тишина. То есть:
1. имеем (адрес узла 192.168.43.102):
С чем это связано - понять не могу.
=======================
Изменил процедуру создания сетевых алиасов, отказался от готовых шаблонов, написал простенькие скрипты с ifconfig up/down. Абсолютно то же самое поведение. Соседняя нода в кластере ремутно (через openVPN) недоступна.
******************************************************
Решил проблему. Оказалось, что работа сетевых интерфейсов очень чувствительна к тому, как поднимается и останавливается openVPN на алиасных (которые тоже синхронно с ним живут) виртуальных интерфейсах. Надо, чтобы это всё очень синхронно работало. Вначале поднимался интерфейс, затем - openvpn. Остановка в обратном порядке.
Всё решил в одном стартовом скрипте. В нем жестко задан порядок старта и останова служб (алиасного интерфейса, правил маршрутизации и openVPN). В результате перечень ресурсов pacemaker'а сократился, но, при этом, всё заработало как часы. Соседний хост виден постоянно за исключением нескольких секунд, в течение которых служба мигрирует на живую ноду и openvpn переинициализируется.
Получил полную загадку. А именно:
1. Операционная система RFR-17.1 со всеми последними патчами на двух серверах. Которые планируются к работе в кластере Pacemaker+Corosync. Локальная сеть - 192.168.43.0
2. Есть ремутные компьютеры, с которых должен быть доступ к этому кластеру по openVPN.
3. Поднимаем (кластерно) openVPN, на одной из нод. Соответственно там поднимается сетевой интерфейс tun0 c сетью 192.168.128.0.
4. На межсетевом экране на узлах кластера разрешено всё для сети 192.168.0.0/16
5. Пытаемся поработать с ремутных компьютеров и видим засаду.
5.1 Ремутный компьютер (через openVPN) прекрасно видит узел кластера на котором развернут openVPN. Узел получает из интерфейса tun0 пакеты от VPN-адреса 192.168.128.2 и откликается на них. Это хорошо.
5.2. Ремутный компьютер прекрасно видит остальные компьютеры в локальной сети 192.168.43.0. Они тоже его чуют и откликаются.
5.3 ЗАСАДА: второй узел кластера понимает только входящие пакеты из локальной сети. То есть посланные с адресов 192.168.43.0. Пакеты приходящие от сети 192.168.128.0, из VPN, этим узлом игнорируются полностью. Он не только на них никак не откликается, но даже нет и исходящего на них от узла трафика. Всё умирает в нём.
6. Переводим openVPM на второй узел кластера. И видим ту же самую картину. Узел на котором живет openVPN открывается для доступа, а второй узел кластера становится доступным только из _локальной_ сети. На запросы из VPN не откликается и сам туда ничего слать не хочет.
7. Если с такой "закрывшейся" ноды попытаться попинговать ремутный (в openVPN) компьютер, то сама эта нода ответит: Destination Host Unreachable. Ответит сама, на сетевых интерфейсах узла, при этом нет никаких исходящих запросов. Однако такая закрывшаяся нода неплохо очень видит весь остальной интернет.
Знатоки, подскажите, где собака зарылась?
]]>