LINUX.ORG.RU
Форум — Admin  

Redirect HostFrom при пинге через бридж

 , , ,


0

1

Итак, есть машина: 

nas:~$ ip -4 addr show  dev br0
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    inet 192.168.0.5/24 brd 192.168.0.255 scope global br0
       valid_lft forever preferred_lft forever

на этом бридже висит lxc-контейнер: 

ss:~$ ip -4 addr show eth0
6: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    inet 192.168.0.8/24 brd 192.168.0.255 scope global eth0
       valid_lft forever preferred_lft forever

при попытке попинговать с хоста заведомо выключенную машину из той же сети: 

nas:~$ ping 192.168.0.10
PING 192.168.0.10 (192.168.0.10) 56(84) bytes of data.
From 192.168.0.8 icmp_seq=2 Redirect HostFrom 192.168.0.8: icmp_seq=2 Redirect Host(New nexthop: 192.168.0.10)
From 192.168.0.8 icmp_seq=3 Redirect HostFrom 192.168.0.8: icmp_seq=3 Redirect Host(New nexthop: 192.168.0.10)
From 192.168.0.8 icmp_seq=1 Destination Host Unreachable
From 192.168.0.8 icmp_seq=5 Redirect HostFrom 192.168.0.8: icmp_seq=5 Redirect Host(New nexthop: 192.168.0.10)
From 192.168.0.8 icmp_seq=6 Redirect HostFrom 192.168.0.8: icmp_seq=6 Redirect Host(New nexthop: 192.168.0.10)
From 192.168.0.8 icmp_seq=4 Destination Host Unreachable
From 192.168.0.8 icmp_seq=8 Redirect HostFrom 192.168.0.8: icmp_seq=8 Redirect Host(New nexthop: 192.168.0.10)
^C
--- 192.168.0.10 ping statistics ---
8 packets transmitted, 0 received, +7 errors, 100% packet loss, time 7006ms
pipe 3

Прерываем пинг и запускаем заново:

nas:~$ ping 192.168.0.10
PING 192.168.0.10 (192.168.0.10) 56(84) bytes of data.
From 192.168.0.5 icmp_seq=1 Destination Host Unreachable
From 192.168.0.5 icmp_seq=2 Destination Host Unreachable
From 192.168.0.5 icmp_seq=3 Destination Host Unreachable
From 192.168.0.5 icmp_seq=4 Destination Host Unreachable
From 192.168.0.5 icmp_seq=5 Destination Host Unreachable
From 192.168.0.5 icmp_seq=6 Destination Host Unreachable
^C
--- 192.168.0.10 ping statistics ---
9 packets transmitted, 0 received, +6 errors, 100% packet loss, time 8030ms
pipe 3

Вопрос - что это было?

★★★★★
← как узнать мы работаем на железе или в виртуалке по XEN?
Переезд MySql сервера →

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

Вопрос: почему 0.5 при пинге 0.10 шлет пакеты на 0.8?

Ответы можно поискать в таблице маршрутизации, ARP-таблице, может и tcpdump что-то полезное расскажет.

tekuchev
()
Ответ на: комментарий от mky 
nas:~$ ip route 
default via 192.168.0.1 dev br0 
10.0.3.0/24 dev lxcbr0  proto kernel  scope link  src 10.0.3.1 
192.168.0.0/24 dev br0  proto kernel  scope link  src 192.168.0.5
Turbid ★★★★★
() автор топика
Ответ на: комментарий от tekuchev

Вопрос: почему 0.5 при пинге 0.10 шлет пакеты на 0.8?

именно

Ответы можно поискать в таблице маршрутизации

смотри выше

ARP-таблице

а вот это самое интересное

таблица на 0.5:

nas:~$ ip neigh 
192.168.0.199 dev br0  FAILED
192.168.0.35 dev br0  FAILED
192.168.0.8 dev br0 lladdr 00:16:3e:48:5a:25 STALE
192.168.0.2 dev br0  FAILED
192.168.0.28 dev br0  FAILED
192.168.0.52 dev br0  FAILED
192.168.0.78 dev br0  FAILED
192.168.0.53 dev br0  FAILED
192.168.0.79 dev br0  FAILED
192.168.0.102 dev br0  FAILED
192.168.0.1 dev br0 lladdr d4:ca:6d:38:e2:eb REACHABLE
192.168.0.21 dev br0  FAILED
192.168.0.188 dev br0  FAILED
192.168.0.77 dev br0  FAILED
192.168.0.251 dev br0 lladdr 34:08:04:c2:9b:33 REACHABLE
192.168.0.100 dev br0  FAILED
192.168.0.44 dev br0  FAILED
192.168.0.15 dev br0 lladdr e8:5b:5b:18:18:61 REACHABLE
192.168.0.189 dev br0  FAILED
192.168.0.107 dev br0  FAILED
192.168.0.101 dev br0  FAILED
192.168.0.12 dev br0  FAILED
192.168.0.75 dev br0  FAILED
192.168.0.42 dev br0  FAILED
192.168.0.13 dev br0  FAILED
192.168.0.10 dev br0 lladdr 2e:fa:d1:f3:9f:f7 REACHABLE

те что с маками - действительно есть такие хосты. про остальные могу сказать только одно - кто все эти люди?

тогда как на 0.10:

pc:~$ ip neigh 
192.168.0.1 dev eth0 lladdr d4:ca:6d:38:e2:eb REACHABLE
192.168.0.252 dev eth0 lladdr 00:25:d3:16:55:79 STALE
192.168.0.5 dev eth0 lladdr d0:27:88:0f:a5:f2 REACHABLE

или на 0.8:

ss:~$ ip neig
192.168.0.1 dev eth0 lladdr d4:ca:6d:38:e2:eb REACHABLE
192.168.0.31 dev eth0 lladdr 00:0e:08:24:af:e7 STALE
192.168.0.10 dev eth0 lladdr 2e:fa:d1:f3:9f:f7 REACHABLE
192.168.0.5 dev eth0 lladdr d0:27:88:0f:a5:f2 STALE

на 0.5 крутитятся следующие сервисы: transmission (может он ищет пиров на этих левых ip?), plex media server с dlna, ftp.

может и tcpdump что-то полезное расскажет

пока не понимаю с чего начать в нем смотреть

Turbid ★★★★★
() автор топика
Ответ на: комментарий от Turbid

пока не понимаю с чего начать в нем смотреть

Смотреть на обмен пакетов при команде 

 nas:~$ ping 192.168.0.10
Причем интересует канальный уровень, (ключ -e), а в особенности - ARP-запросы и ответы, то есть tcpdump должен запускаться до того, как в ARP-таблице появится запись про .10.

таблица на 0.5:

В этой таблице .10 жив и здравствует. Могу предположить, если пингать его, пока он жив, никаких редиректов от .8 не будет. Какая запись будет в ARP таблице, если хост выключить, подождать, пока очистится ARP-кэш, и запустить его ping?

Это проблема возникла только с .10? Что будет, если пингать любой другой неиспользуемый адрес? Появится ли ICMP-редирект и запись в arp-таблице?

tekuchev
()
Ответ на: комментарий от tekuchev

итак, хост 0.10 со вчерашнего вечера выключен, но arp с 0.5:

nas:~$ ip neigh show 192.168.0.10
192.168.0.10 dev br0 lladdr 2e:fa:d1:f3:9f:f7 STALE

далее пингуем: 

nas:~$ ping 192.168.0.10
PING 192.168.0.10 (192.168.0.10) 56(84) bytes of data.
From 192.168.0.8 icmp_seq=2 Redirect HostFrom 192.168.0.8: icmp_seq=2 Redirect Host(New nexthop: 192.168.0.10)
From 192.168.0.8 icmp_seq=3 Redirect HostFrom 192.168.0.8: icmp_seq=3 Redirect Host(New nexthop: 192.168.0.10)
From 192.168.0.8 icmp_seq=4 Redirect HostFrom 192.168.0.8: icmp_seq=4 Redirect Host(New nexthop: 192.168.0.10)
From 192.168.0.8 icmp_seq=5 Redirect HostFrom 192.168.0.8: icmp_seq=5 Redirect Host(New nexthop: 192.168.0.10)               
From 192.168.0.8 icmp_seq=6 Redirect HostFrom 192.168.0.8: icmp_seq=6 Redirect Host(New nexthop: 192.168.0.10)
From 192.168.0.8 icmp_seq=8 Redirect HostFrom 192.168.0.8: icmp_seq=8 Redirect Host(New nexthop: 192.168.0.10)
From 192.168.0.5 icmp_seq=9 Destination Host Unreachable
From 192.168.0.5 icmp_seq=10 Destination Host Unreachable
From 192.168.0.5 icmp_seq=11 Destination Host Unreachable
From 192.168.0.5 icmp_seq=12 Destination Host Unreachable
From 192.168.0.5 icmp_seq=13 Destination Host Unreachable
From 192.168.0.5 icmp_seq=14 Destination Host Unreachable
From 192.168.0.5 icmp_seq=15 Destination Host Unreachable
From 192.168.0.5 icmp_seq=16 Destination Host Unreachable
From 192.168.0.5 icmp_seq=17 Destination Host Unreachable
From 192.168.0.5 icmp_seq=18 Destination Host Unreachable
From 192.168.0.5 icmp_seq=19 Destination Host Unreachable
From 192.168.0.5 icmp_seq=20 Destination Host Unreachable
From 192.168.0.5 icmp_seq=21 Destination Host Unreachable
From 192.168.0.5 icmp_seq=22 Destination Host Unreachable
From 192.168.0.5 icmp_seq=23 Destination Host Unreachable
^C
--- 192.168.0.10 ping statistics ---
24 packets transmitted, 0 received, +21 errors, 100% packet loss, time 23005ms
pipe 4

и смотрим снова arp-таблицу: 

nas:~$ ip neigh show 192.168.0.10
192.168.0.10 dev br0  FAILED

Есть мнение, что пока снова не включу-выключу 0.10 - эксперимент не повторю.

Сегодня попробую поиграться с tcpdump, спасибо за наводки.

p.s. Есть идеи откуда левые ip в arp-таблице?

Turbid ★★★★★
() автор топика
Последнее исправление: Turbid (всего исправлений: 1)
Ответ на: комментарий от Turbid

p.s. Есть идеи откуда левые ip в arp-таблице?

Я пока еще верю, что чудес не бывает, а значит кто-то из приложений на .5 пытается связаться с этими хостами. Опять же - tcpdump на все/часть этих хостов, лучше в background и надолго, чтобы наверняка что-то поймать. Тогда по src_port и dst_port быть может удастся понять кто, куда и зачем ломится.
Остальные варианты что-то выглядят весьма трудоемкими:
через iptables: есть опция --cmd-owner, но это нужна поддержка в ядре. Можно попробовать через --uid-owner, если «подозреваемые» приложения под разными пользователями. И придется писать кучу правил под все программы.
Есть еще разные программы типа nettop, nethogs ( http://sourceforge.net/projects/nethogs/ ), может они что расскажут, но ими я не пользовался.

tekuchev
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← как узнать мы работаем на железе или в виртуалке по XEN?
Admin
Переезд MySql сервера →