metalsoft Опубликовано 17 января, 2020 · Жалоба Всем добра, коллеги! Сервер 172.16.0.1 подключен к влану управления коммутаторами vlan_id 3, коммутаторы имеют адреса 172.16.1.x...172.16.35.x, коммутаторов с бОльшими ip адресами нет. Однако tcpdump показывает следующую картину: [root@ipoe1 ~]# tcpdump -enn -i eth1.3 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1.3, link-type EN10MB (Ethernet), capture size 65535 bytes 10:59:28.777981 90:e2:ba:20:58:f2 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 172.22.6.34 tell 172.16.0.2, length 46 10:59:28.997366 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.23 tell 172.16.0.1, length 28 10:59:28.997371 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.31 tell 172.16.0.1, length 28 10:59:28.997373 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.36 tell 172.16.0.1, length 28 10:59:28.997375 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.24 tell 172.16.0.1, length 28 10:59:28.997376 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.48 tell 172.16.0.1, length 28 10:59:28.997378 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.39 tell 172.16.0.1, length 28 10:59:28.997380 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.52 tell 172.16.0.1, length 28 10:59:28.997382 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.25 tell 172.16.0.1, length 28 10:59:28.997384 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.42 tell 172.16.0.1, length 28 10:59:28.997385 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.32 tell 172.16.0.1, length 28 10:59:28.997387 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.51 tell 172.16.0.1, length 28 10:59:28.997389 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.43 tell 172.16.0.1, length 28 10:59:28.997390 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.38 tell 172.16.0.1, length 28 10:59:28.997392 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.62 tell 172.16.0.1, length 28 10:59:28.997394 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.49 tell 172.16.0.1, length 28 10:59:28.997396 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.30 tell 172.16.0.1, length 28 10:59:28.997397 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.41 tell 172.16.0.1, length 28 10:59:28.997399 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.45 tell 172.16.0.1, length 28 10:59:28.997401 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.54 tell 172.16.0.1, length 28 10:59:28.997403 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.57 tell 172.16.0.1, length 28 10:59:28.997405 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.63 tell 172.16.0.1, length 28 10:59:28.997407 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.28 tell 172.16.0.1, length 28 10:59:28.997409 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.46 tell 172.16.0.1, length 28 10:59:28.997410 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.58 tell 172.16.0.1, length 28 10:59:28.997412 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.33 tell 172.16.0.1, length 28 10:59:28.997414 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.29 tell 172.16.0.1, length 28 10:59:28.997415 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.59 tell 172.16.0.1, length 28 Сегменты ip адреса после 172.16. разные. Насколько я понимаю, сервер получает какие-то начальные пакеты с этих адресов, но т.к. этих адресов нет в его arp-таблице, он отправляет к ним arp запросы. Но тогда с каждого из этих адресов должно быть хотя по одному этому начальному пакету, а в выводе tcpdump я их не вижу вобще. Как вычислить источник? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
azhur Опубликовано 17 января, 2020 · Жалоба Для начала, на сетевке у сервера и коммутаторах маска (/12 или таки поуже) и шлюз какие настроены? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
metalsoft Опубликовано 17 января, 2020 · Жалоба Да, маска /12 и на сервере и на коммутаторах. И этот сервер является шлюзом в другие сети. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ShyLion Опубликовано 17 января, 2020 · Жалоба 49 minutes ago, metalsoft said: маска /12 и на сервере и на коммутаторах Это Победа! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
VolanD666 Опубликовано 17 января, 2020 · Жалоба 59 минут назад, metalsoft сказал: Всем добра, коллеги! Сервер 172.16.0.1 подключен к влану управления коммутаторами vlan_id 3, коммутаторы имеют адреса 172.16.1.x...172.16.35.x, коммутаторов с бОльшими ip адресами нет. Однако tcpdump показывает следующую картину: Скрыть содержимое [root@ipoe1 ~]# tcpdump -enn -i eth1.3 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1.3, link-type EN10MB (Ethernet), capture size 65535 bytes 10:59:28.777981 90:e2:ba:20:58:f2 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 172.22.6.34 tell 172.16.0.2, length 46 10:59:28.997366 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.23 tell 172.16.0.1, length 28 10:59:28.997371 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.31 tell 172.16.0.1, length 28 10:59:28.997373 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.36 tell 172.16.0.1, length 28 10:59:28.997375 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.24 tell 172.16.0.1, length 28 10:59:28.997376 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.48 tell 172.16.0.1, length 28 10:59:28.997378 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.39 tell 172.16.0.1, length 28 10:59:28.997380 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.52 tell 172.16.0.1, length 28 10:59:28.997382 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.25 tell 172.16.0.1, length 28 10:59:28.997384 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.42 tell 172.16.0.1, length 28 10:59:28.997385 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.32 tell 172.16.0.1, length 28 10:59:28.997387 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.51 tell 172.16.0.1, length 28 10:59:28.997389 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.43 tell 172.16.0.1, length 28 10:59:28.997390 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.38 tell 172.16.0.1, length 28 10:59:28.997392 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.62 tell 172.16.0.1, length 28 10:59:28.997394 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.49 tell 172.16.0.1, length 28 10:59:28.997396 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.30 tell 172.16.0.1, length 28 10:59:28.997397 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.41 tell 172.16.0.1, length 28 10:59:28.997399 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.45 tell 172.16.0.1, length 28 10:59:28.997401 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.54 tell 172.16.0.1, length 28 10:59:28.997403 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.57 tell 172.16.0.1, length 28 10:59:28.997405 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.63 tell 172.16.0.1, length 28 10:59:28.997407 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.28 tell 172.16.0.1, length 28 10:59:28.997409 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.46 tell 172.16.0.1, length 28 10:59:28.997410 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.58 tell 172.16.0.1, length 28 10:59:28.997412 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.33 tell 172.16.0.1, length 28 10:59:28.997414 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.29 tell 172.16.0.1, length 28 10:59:28.997415 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.59 tell 172.16.0.1, length 28 Сегменты ip адреса после 172.16. разные. Насколько я понимаю, сервер получает какие-то начальные пакеты с этих адресов, но т.к. этих адресов нет в его arp-таблице, он отправляет к ним arp запросы. Но тогда с каждого из этих адресов должно быть хотя по одному этому начальному пакету, а в выводе tcpdump я их не вижу вобще. Как вычислить источник? А почему вы решили что сервер не может просто стучаться на эти адреса? Без начального пакета? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
azhur Опубликовано 17 января, 2020 · Жалоба 59 минут назад, metalsoft сказал: сервер получает какие-то начальные пакеты с этих адресов, но т.к. этих адресов нет в его arp-таблице, он отправляет к ним arp запросы. Если сервер "получил пакет с этих адресов" внутри соответствующего l2 сегмента, то данные из пакета (src ip, src mac) должны, насколько я помню, автоматом попадать в arp-таблицу, и соответственно arp-запросы не нужны. Как вариант, не могут ли пакеты с такими src-адресами поступать через другой сетевой интерфейс сервера? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 17 января, 2020 · Жалоба Ага, или просто что-то или кто-то сеть сканирует на доступность, например тот же заббикс при не верных настройках. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 18 января, 2020 · Жалоба 17 часов назад, metalsoft сказал: Сегменты ip адреса после 172.16. разные. Насколько я понимаю, сервер получает какие-то начальные пакеты с этих адресов, но т.к. этих адресов нет в его arp-таблице, он отправляет к ним arp запросы. Но тогда с каждого из этих адресов должно быть хотя по одному этому начальному пакету, а в выводе tcpdump я их не вижу вобще. Как вычислить источник? 16 часов назад, azhur сказал: Если сервер "получил пакет с этих адресов" внутри соответствующего l2 сегмента, то данные из пакета (src ip, src mac) должны, насколько я помню, автоматом попадать в arp-таблицу, и соответственно arp-запросы не нужны. У вас не точное представление о том как работают современные ОС. 1. Даже если с этих адресов кто то пришёл на хост, и хост собирается ответить - он всё равно запросит через арп. Это делается по банальной причине - экономия цпу: слишком накладно мак адрес каждого входящего пакета чекать на присутствие в арп таблице и добавлять туда, и не факт что он вообще понадобится потом. 2. Нечто подобное может быть если включён прокси арп или не верно настрона таблица маршрузации: хост может думать что все остальные хосты в его сегменте и пытаться отрезолвить их адрес через арп. 16 часов назад, azhur сказал: Как вариант, не могут ли пакеты с такими src-адресами поступать через другой сетевой интерфейс сервера? Могут. Адрес коммутатора который запрашивает идёт после tell, вот на них и смотрите что понастроено. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mcdemon Опубликовано 18 января, 2020 · Жалоба 17 часов назад, metalsoft сказал: Сервер 172.16.0.1 а сервер вообще для чего используется? не является ли он маршрутизатором для кого-то? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
azhur Опубликовано 18 января, 2020 · Жалоба 5 часов назад, Ivan_83 сказал: У вас не точное представление о том как работают современные ОС. 1. Даже если с этих адресов кто то пришёл на хост, и хост собирается ответить - он всё равно запросит через арп. Это делается по банальной причине - экономия цпу: слишком накладно мак адрес каждого входящего пакета чекать на присутствие в арп таблице и добавлять туда, и не факт что он вообще понадобится потом. Вполне возможно, что и так, на истину в последней инстанции не претендую. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
metalsoft Опубликовано 21 января, 2020 · Жалоба Исследавание показало, что пакеты на самом деле приходили через другой интерфейс, и было решено перестроить сегмент сети по-нормальному :) Проблема решена, спасибо всем за участие! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...