afanasev.p пишет:/me не очень понимает в работе Pacemaker+Corosync (wtf?), но для того, чтобы объединить 2 сети в одну "нормальную" (имея при этом 2 маршрутизатора) - нужно правильно настроить маршрутизацию. либо делать нат (но это "на любителя")
Маргрутизацию я могу как автомат Калашникова разбирать и собирать с закрытыми глазами. Проблема не в этом. Даже если маргрутизация настроена криво, но всё равно хост, с которого пытаемся что либо пропинговать, кинет соответствующий icmp echo-request на интерфейс, на котором определен хотя бы маршрут по умолчанию. Но не станет сам определять, что ремутный хост недоступен. У меня же на сетевых интерфейсах - полная тишина. То есть:
1. имеем (адрес узла 192.168.43.102):
Консоль:
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.41.1 0.0.0.0 UG 0 0 0 em1
192.168.0.0 192.168.43.2 255.255.255.0 UG 0 0 0 em2
192.168.43.0 0.0.0.0 255.255.255.0 U 0 0 0 em2
192.168.53.0 192.168.43.2 255.255.255.0 UG 0 0 0 em2
192.168.128.0 192.168.43.2 255.255.255.0 UG 0 0 0 em2
Адрес 192.168.43.2 - это адрес шлюза. Сейчас он на соседнем компьютере, на другом узле кластера.
Сеть 43 - локальная, 53 - ремутная, 128 - openVPN.
2. Пингуем с этого хоста ремутный хост 192.168.53.1:
Консоль:
# ping 192.168.53.1
PING 192.168.53.1 (192.168.53.1) 56(84) bytes of data.
From 192.168.43.102 icmp_seq=1 Destination Host Unreachable
From 192.168.43.102 icmp_seq=2 Destination Host Unreachable
То есть нам трафик режет не кто либо, а сам хост, с которого пингуем. При этом на его сетевых интерфейсах - полная тишина по icmp. О чем с готовностью нам сообщает tcpdump. Но если мы пингуем 8.8.8.8 - проблем нет никаких.
3. Теперь переходим на ремутный хост (192.168.53.1) и пингуем наш узел:
Собственно не получаем никакого ответа...
А вот на нашем хосту:
Консоль:
# tcpdump -n -i em2 proto ICMP
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em2, link-type EN10MB (Ethernet), capture size 65535 bytes
18:58:36.706387 IP 192.168.128.2 > 192.168.43.102: ICMP echo request, id 24002, seq 21, length 64
18:58:37.706553 IP 192.168.128.2 > 192.168.43.102: ICMP echo request, id 24002, seq 22, length 64
18:58:38.706518 IP 192.168.128.2 > 192.168.43.102: ICMP echo request, id 24002, seq 23, length 64
18:58:39.707339 IP 192.168.128.2 > 192.168.43.102: ICMP echo request, id 24002, seq 24, length 64
То есть - пакеты из openVPN на него приходят, но вот взад ответы не идут. Может быть запрещены ICMP?
Нет:
Консоль:
# tcpdump -n -i em2 proto ICMP
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em2, link-type EN10MB (Ethernet), capture size 65535 bytes
19:00:43.901730 IP 192.168.43.6 > 192.168.43.102: ICMP echo request, id 2147, seq 5, length 64
19:00:43.901779 IP 192.168.43.102 > 192.168.43.6: ICMP echo reply, id 2147, seq 5, length 64
19:00:44.699912 IP 192.168.128.2 > 192.168.43.102: ICMP echo request, id 24002, seq 149, length 64
19:00:44.901496 IP 192.168.43.6 > 192.168.43.102: ICMP echo request, id 2147, seq 6, length 64
19:00:44.901523 IP 192.168.43.102 > 192.168.43.6: ICMP echo reply, id 2147, seq 6, length 64
То, что ICMP разрешены - поверьте. Разрешены со всей огромной сети 192.168.0.0/16
4. Продолжаем эксперимент. Теперь переводим openVPN-сервер на нашу ноду. Маршруты несколько изменяются:
Консоль:
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.41.1 0.0.0.0 UG 0 0 0 em1
192.168.43.0 0.0.0.0 255.255.255.0 U 0 0 0 em2
192.168.53.0 192.168.128.2 255.255.255.0 UG 0 0 0 tun0
192.168.128.0 192.168.128.2 255.255.255.0 UG 0 0 0 tun0
То есть - 53-я и 128-я сети уходят на интерфейс tun0, в openVPN. При этом всё начинает работать.
Консоль:
# tcpdump -n -i tun0 proto ICMP
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
19:17:08.768907 IP 192.168.128.2 > 192.168.43.102: ICMP echo request, id 24086, seq 38, length 64
19:17:08.768946 IP 192.168.43.102 > 192.168.128.2: ICMP echo reply, id 24086, seq 38, length 64
19:17:09.770675 IP 192.168.128.2 > 192.168.43.102: ICMP echo request, id 24086, seq 39, length 64
19:17:09.770713 IP 192.168.43.102 > 192.168.128.2: ICMP echo reply, id 24086, seq 39, length 64
19:17:10.772002 IP 192.168.128.2 > 192.168.43.102: ICMP echo request, id 24086, seq 40, length 64
19:17:10.772037 IP 192.168.43.102 > 192.168.128.2: ICMP echo reply, id 24086, seq 40, length 64
Точнее - данный хост становится доступным через openVPM, а колом становится парный ему в кластере хост. Он теряет связь с ремутными по openVPN сетями, но вот с интернетом работает беспроблемно. То есть полностью повторяет поведение первого хоста.
С чем это связано - понять не могу.
=======================
Изменил процедуру создания сетевых алиасов, отказался от готовых шаблонов, написал простенькие скрипты с ifconfig up/down. Абсолютно то же самое поведение. Соседняя нода в кластере ремутно (через openVPN) недоступна.
******************************************************
Решил проблему. Оказалось, что работа сетевых интерфейсов очень чувствительна к тому, как поднимается и останавливается openVPN на алиасных (которые тоже синхронно с ним живут) виртуальных интерфейсах. Надо, чтобы это всё очень синхронно работало. Вначале поднимался интерфейс, затем - openvpn. Остановка в обратном порядке.
Всё решил в одном стартовом скрипте. В нем жестко задан порядок старта и останова служб (алиасного интерфейса, правил маршрутизации и openVPN). В результате перечень ресурсов pacemaker'а сократился, но, при этом, всё заработало как часы. Соседний хост виден постоянно за исключением нескольких секунд, в течение которых служба мигрирует на живую ноду и openvpn переинициализируется.
