Всем привет!
Есть интересность, ни как победить не могу
Есть CentOS 7
Linux 3.10.0-327.22.2.el7.x86_64 #1 SMP Thu Jun 23 17:05:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linuxдва интерфейса, серый 192.168.5.3 и белый X.X.X.X .
На белом шлюз по умолчанию X.X.X.1, на сером стопка сетей 172/192.
Вот на сером отваливается шлюз, если в этот момент идёт обращение к удалённом хосту на пример 192.168.10.2 через этот шлюз 192.168.5.2, роутинг перестаёт идти и валиться через белый шлюз X.X.X.1, да ещё не с белого IP, а серого 192.168.5.3.
Помогает ребут или новый роут, скажем 192.168.10.2/32 via 192.168.5.2
Как линукс должен восстановить маршрут по статик роуту?
> Помогает ребут или новый роут, скажем 192.168.10.2/32 via 192.168.5.2
> Как линукс должен восстановить маршрут по статик роуту?статичные никак, так как он у вас static прописан в системе. самому проверять доступность к примеру шлюза и поддерживать таблицу маршрутов на уровне скриптов.
так же на досуге покурите iproute2, dynamic routes
> статичные никак, так как он у вас static прописан в системе. самому
> проверять доступность к примеру шлюза и поддерживать таблицу маршрутов на уровне
> скриптов.
> так же на досуге покурите iproute2, dynamic routesВопрос, а как понять, что маршрут перестроился, если разницы в
netstat -nar
ip route show
Ни какой разницы не видно ?
Все смешалось в кучу - кони, люди...Что значит "роутинг перестаёт идти" и чем отличается маршрут от "роута"?
> Что значит "роутинг перестаёт идти" и чем отличается маршрут от "роута"?Маршрут от роута, ни чем в данном случае, только что буквами в словах.
Смотрю
ip route show
Видишь что есть маршрут до 192.168.10.2 через 192.168.5.2, а система выбирает маршрут через шлюз с белого ip X.X.X.1, да ещё и шлёт не с белого X.X.X.X, а с серого 192.168.5.3.
>> Что значит "роутинг перестаёт идти" и чем отличается маршрут от "роута"?
> Маршрут от роута, ни чем в данном случае, только что буквами в
> словах.
> Смотрю
> ip route show
> Видишь что есть маршрут до 192.168.10.2 через 192.168.5.2, а система выбирает маршрут
> через шлюз с белого ip X.X.X.1, да ещё и шлёт не
> с белого X.X.X.X, а с серого 192.168.5.3.а в ip ru sh что? PBR вообще настроен?
> а в ip ru sh что? PBR вообще настроен?ip ru sh
0: from all lookup local
32766: from all lookup main
32767: from all lookup defaultPBR ни чего дополнительного нет, роутинг настроен в nmtui (сохраняет файлах /etc/sysconfig/network-scripts/route-ens160 для локального интерфейса) и default route для белого
Вот локальной сети
ADDRESS0=172.27.29.0
NETMASK0=255.255.255.0
GATEWAY0=192.168.5.2
METRIC0=0
********стопка подобного************
ADDRESS14=172.24.254.0
NETMASK14=255.255.255.0
GATEWAY14=192.168.5.2
METRIC14=0
первый раз о таком слышу.
статика всегда статика, на она так и названа, прописал и зыбИл.
а посмотрите логи, сеть не передергивается часом перед тем как такое происходит.
> а посмотрите логи, сеть не передергивается часом перед тем как такое происходит.Нет не передёргивается, падает шлюз только, но он там где-то в сети, а линукс на виртуалке и в логах падения сети не видно. Как только падает шлюз этот, всё Linux начинает слать в шлюз по умолчанию, да ещё и с серой сетки источник получается.
Что можно поискать в системе, когда это происходит, скажем так какая диагностика существует?
Ядро обновлял, глюк такой и остался.
Может какой мега развёрнутый дебаг можно включить?
может показать ip route sh, а то гадать мы будем долго.
Игрался метрикой в конфигах интерфейсов выставляя в настройках интерфейса METRIC=100, удаляя эту настройку или добавляя METRIC=0, всё равно светиться 100. Не помогает не рестарт сети, ни перезагрузка. Но и до добавления метрики, работала так же, и игры с ней мне тогда не помогли.default via X.X.X.1 dev eno33554952 proto static metric 100
10.10.5.0/24 via 192.168.5.21 dev eno16777984 proto static
10.16.0.0/16 via 192.168.5.2 dev eno16777984 proto static
172.16.0.0/16 via 192.168.5.2 dev eno16777984 proto static
172.16.1.0/24 via 192.168.5.2 dev eno16777984 proto static
172.24.251.0/24 via 192.168.5.2 dev eno16777984 proto static
172.24.252.0/24 via 192.168.5.2 dev eno16777984 proto static
172.24.253.0/24 via 192.168.5.2 dev eno16777984 proto static
172.24.254.0/24 via 192.168.5.2 dev eno16777984 proto static
172.25.0.0/16 via 192.168.5.2 dev eno16777984 proto static
172.27.29.0/24 via 192.168.5.2 dev eno16777984 proto static
X.X.X.0/28 dev eno33554952 proto kernel scope link src X.X.X.6 metric 100
192.168.0.0/16 via 192.168.5.203 dev eno16777984 proto static
192.168.5.0/24 dev eno16777984 proto kernel scope link src 192.168.5.3 metric 100
192.168.17.0/24 via 192.168.5.203 dev eno16777984 proto static
192.168.42.0/24 via 192.168.5.203 dev eno16777984 proto static
192.168.91.0/24 via 192.168.5.203 dev eno16777984 proto static
192.168.143.0/24 via 192.168.5.203 dev eno16777984 proto static
и ещё iptables -t nat -L -nv
Ни чего нет.iptables -t nat -L -nv
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destinationChain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destinationChain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destinationChain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
данная ситуация наблюдается только на одном протоколе/службе (например tcp/http) или проверяли разные (icmp tcp udp ... )?
И чем, как проверяли?
> данная ситуация наблюдается только на одном протоколе/службе (например tcp/http) или проверяли
> разные (icmp tcp udp ... )?
> И чем, как проверяли?ICMP, UDP, TCP
1) Не пингуются шлюзы
2) Не бегает SIP
3) Нельзя вебом зайти на шлюз с сервера.Смотрел, что уходит не c того IP на не тот шлюз, снимал дамп tcpdump и смотрел в Wireshark
а что в это время происходит с arp таблицей?
и на какой mac уходят пакеты?
В arp таблице всё присутствует, и два шлюза и соседи. А нам мак уходит соответственно шлюза по умолчанию.
А другие хосты доступны, через серую, если не обращались к ним через шлюз серой сетки в момент падения, доступны. Не доступны, только к кому было обращение в момент падения шлюза серого.
Ну так всё замечательно! при чём тут статика? здесь arp.
> Ну так всё замечательно! при чём тут статика? здесь arp.Поясните, не понял вас.
Шлюз после падения выбирается то другой. И Почему-то шлётся не с белого IP, а с серого, от старого, не рабочего маршрута, который работал до падения шлюза для серой сетки.
если в arp таблице ВСЁ присутствует то и отправляются пакеты соответственно arp таблице.
http://xgu.ru/wiki/ARP-spoofing
http://xgu.ru/wiki/Proxy_ARP
src ip выбирается согласно таблицы маршрутизации (интерфейс ведь не в down).
> если в arp таблице ВСЁ присутствует то и отправляются пакеты соответственно arpОно и до поломки отсылает всё согласно arp таблице. ARP таблица в обоих случаях отображает реальную реальность, и не меняется вообще. А вот линукс принимает решение НАВСЕГДА до перезагрузки системы оставить маршрут по умолчанию на эту сеть, а не отдельно прописанный, через серую сетку.
Тв3 - там есть экстрасенсы.
> Тв3 - там есть экстрасенсы.Расскажите, что ещё смотреть можно? Проблема в том, что кроме перечисленных команд в этой ветке, я не знаю более, есть же ещё что-то?
>> Тв3 - там есть экстрасенсы.
> Расскажите, что ещё смотреть можно? Проблема в том, что кроме перечисленных команд
> в этой ветке, я не знаю более, есть же ещё что-то?Попробуйте выполнить conntrack -F и посмотреть, начнут ли бегать пакеты с нужных интерфейсов