Tcpdump не видит пакеты

В интернете тоже не нашел информации, что от правил маршрутизации tcpdump может перестать видеть пакеты.

Он перестает видеть от ната

tcpdump -nnNNi eth0 net XXX.XXX.XXX.0/24

что покажет?

А, понял. Твои хосты видят, что подсетка находится за другим шлюзом и начинают ходить напрямую через 10.0.0.2, мимо 10.0.0.1. Так сейчас сети работают, умные очень стали.

Если ты на своем свитче настроишь режим хаба или как то еще среплицируешь трафик порта, который смотрит на 10.0.0.2, то увидишь по МАС-ам что как ходит.

tcpdump -i any dst XXX.XXX.XXX.XXX помогает, если трафик ходит через разные интерфейсы.

Не работает. Да и уходят через тот же интерфейс ведь.

Нарисуйте внятную схему:

1. вот локальная сеть (ее адрес/24), она подключена куда (коммутатор)

2. есть шлюз (ifconfig), в его интерфейсы подключены что (каммутатор, инет)?

3. есть железка (адреса и куда подключены порты/интерфейсы).

У меня тоже эта мысль сразу же возникла. Но не сталкивался с этим еще. А как это они сами могут ходить мимо основного ? На клиентах ведь нет маршрута. А если есть - то где смотреть? И где можно почитать про эту умную штуку, которая позволяет идти напрямую через другой маршрутизатор?

1. Сеть 10.0.0.0/24. Естественно коммутатор. Туда же и Сервер(шлюз/маршрутизатор)
2. У шлюза адрес 10.0.0.1
3. В сети есть еще одна железка, с адресом 10.0.0.2. Он Lan воткнут в мою сетку. Wan в провайдера
4. На шлюзе прописал маршрут. Для клиентов шлюз по умолчанию мой маршрутизатор. А на нем уже трафик в нужную подсеть отправляется через 10.0.0.2

Дальше думаю все итак понятно

Не раскрыта тема NAT-а. iptables-save на шлюзе.

Предположу либо зеркалить порт коммутатора куда воткнута железка, и там искать пакеты, либо воткнуть железку в шлюз, и в шлюзе цедить пакеты. И нафиг железке шлюз, если железка в той же подсети.

iptables и nat тут вообще не причем. anto215 был прав. Почему-то только сейчас вспомнил про трасировку с клиентов. Клиенты напрямую идут на 10.0.0.2. Осталось понять почему и где про это почитать.

У железки не прописан мой шлюз. У нее свой шлюз, провайдера.

Гуглите про icmp redirect

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

Вооот! Спасибо. Почитал. Теперь понятно. Маршрут попадает в кеш, но не записывается в таблицу маршрутизации. Ну теперь в принципе понятно. Дальше уже видно будет, что с этим делать и делать ли.

Если бы NAT был не причем, то у Вас бы ничего не работало. Именно NAT заворачивает SYN пакет от клиента на железку.

Поддержу предыдущего оратора, по человечески будет работать только если железку подключить в шлюз и шлюзом маршрутизировать.

Будет работать если выключить как отправку редиректов (net.ipv4.conf.all.send_redirects) так и приемов (net.ipv4.conf.all.accept_redirects). Что я сейчас в принципе и сделал. Вот только не могу однозначно понять. Оставлять ли редирект или убирать. С одной стороны маршрутизатору надо оставлять. Клиенты пусть напрямую бегают к железке. Исключается один узел для пакетов в ту сеть. С другой нет возможности отлавливать проблемы да и возможности для MITM появляются

Да и в интернете не нашел однозначного ответа. Кто-то в целях безопасности отключает. Кто-то наоборот на шлюзах включает.

С другой нет возможности отлавливать проблемы

Если коммутатор не совсем тупой (и умеет хотя бы в vlan'ы) - можно эту железку убрать в отдельный vlan и на шлюзе приземлить на субинтерфейс

Тогда логическая топология получится нормальная и редиректов не будет.

Ну или конкретно для отлавливания проблем - зеркалировать трафик (опять же коммутатор должен быть не совсем тупым)

Ну да. Это все можно сделать. Только сейчас не вижу большой необходимости. Я не нашел явных причин включать редиректы. Если кто нибудь приведет реальные факты необходимости редиректор - буду только рад выслушать. А пока с выключенными редиректами нет проблем.