[Решено]Проблема с сетью в Fedora 17

Привет всем!

Получил полную загадку. А именно:
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. Ответит сама, на сетевых интерфейсах узла, при этом нет никаких исходящих запросов. Однако такая закрывшаяся нода неплохо очень видит весь остальной интернет.

Знатоки, подскажите, где собака зарылась?

/me не очень понимает в работе Pacemaker+Corosync (wtf?), но для того, чтобы объединить 2 сети в одну "нормальную" (имея при этом 2 маршрутизатора) - нужно правильно настроить маршрутизацию. либо делать нат (но это "на любителя")

afanasev.p написал:

/me не очень понимает в работе Pacemaker+Corosync (wtf?), но для того, чтобы объединить 2 сети в одну "нормальную" (имея при этом 2 маршрутизатора) - нужно правильно настроить маршрутизацию. либо делать нат (но это "на любителя")

Маргрутизацию я могу как автомат Калашникова разбирать и собирать с закрытыми глазами. Проблема не в этом. Даже если маргрутизация настроена криво, но всё равно хост, с которого пытаемся что либо пропинговать, кинет соответствующий icmp echo-request на интерфейс, на котором определен хотя бы маршрут по умолчанию. Но не станет сам определять, что ремутный хост недоступен. У меня же на сетевых интерфейсах - полная тишина. То есть:
1. имеем (адрес узла 192.168.43.102):
[console]# 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[/console]
Адрес 192.168.43.2 - это адрес шлюза. Сейчас он на соседнем компьютере, на другом узле кластера.
Сеть 43 - локальная, 53 - ремутная, 128 - openVPN.
2. Пингуем с этого хоста ремутный хост 192.168.53.1:
[console]# 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[/console]
То есть нам трафик режет не кто либо, а сам хост, с которого пингуем. При этом на его сетевых интерфейсах - полная тишина по icmp. О чем с готовностью нам сообщает tcpdump. Но если мы пингуем 8.8.8.8 - проблем нет никаких.
3. Теперь переходим на ремутный хост (192.168.53.1) и пингуем наш узел:
Собственно не получаем никакого ответа...
А вот на нашем хосту:
[console]# 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[/console]
То есть - пакеты из openVPN на него приходят, но вот взад ответы не идут. Может быть запрещены ICMP?
Нет:
[console]# 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
[/console]
То, что ICMP разрешены - поверьте. Разрешены со всей огромной сети 192.168.0.0/16
4. Продолжаем эксперимент. Теперь переводим openVPN-сервер на нашу ноду. Маршруты несколько изменяются:
[console]# 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[/console]
То есть - 53-я и 128-я сети уходят на интерфейс tun0, в openVPN. При этом всё начинает работать.
[console]# 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
[/console]
Точнее - данный хост становится доступным через openVPM, а колом становится парный ему в кластере хост. Он теряет связь с ремутными по openVPN сетями, но вот с интернетом работает беспроблемно. То есть полностью повторяет поведение первого хоста.

С чем это связано - понять не могу.
=======================
Изменил процедуру создания сетевых алиасов, отказался от готовых шаблонов, написал простенькие скрипты с ifconfig up/down. Абсолютно то же самое поведение. Соседняя нода в кластере ремутно (через openVPN) недоступна.
******************************************************
Решил проблему. Оказалось, что работа сетевых интерфейсов очень чувствительна к тому, как поднимается и останавливается openVPN на алиасных (которые тоже синхронно с ним живут) виртуальных интерфейсах. Надо, чтобы это всё очень синхронно работало. Вначале поднимался интерфейс, затем - openvpn. Остановка в обратном порядке.
Всё решил в одном стартовом скрипте. В нем жестко задан порядок старта и останова служб (алиасного интерфейса, правил маршрутизации и openVPN). В результате перечень ресурсов pacemaker'а сократился, но, при этом, всё заработало как часы. Соседний хост виден постоянно за исключением нескольких секунд, в течение которых служба мигрирует на живую ноду и openvpn переинициализируется.