LINUX.ORG.RU
решено ФорумAdmin

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

 ,


0

1

Возможно вопрос элементарный и ответ очевидный. Но видимо я заработался, что не могу найти ответ.

Есть шлюз. Клиенты. НАТ. Все как обычно. Есть железка, которая одним портом смотрит в интернет (у нее свой интернет), а другим в мою сеть. И стоит она для того, чтоб отправлять некий трафик через него. То есть есть к примеру сеть ХХХ.ХХХ.ХХХ.ХХХ/24, есть мой шлюз 10.0.0.1 и эта железка с адресом 10.0.0.2. Чтоб клиентам всем не добавлять маршрут (неважно, ручками или через dhcp), на моем шлюзе просто сделал правило вида

route add -net XXX.XXX.XXX.XXX netmask 255.255.255.0 gw 10.0.0.2


FORWARD разрешен. Да и вообще все работает. Все замечательно. Но вот мне хотелось кое что проверить и как обычно запустил

tcpdump -i eth0 dst XXX.XXX.XXX.XXX


И.... И ничего. При этом если сбрасывать conntrack, то в какой-то момент tcpdump начинает видеть первые пару пакетов, а потом вновь тишина. Клиенты за nat повторюсь не испытывают проблем. То есть трафик, который должен идти через эту железку(10.0.0.2) идет. Но tcpdump не видит. Как же мне в случае проблем заниматься отладкой? Если я удаляю правило из таблицы маршрутизации, то tcpdump так же начинает видеть входящие пакеты, правда, естественно, они никуда не уходят, потому что без этой железки в эту сеть не попасть.

Возможно это тривиальный вопрос. Но то ли я переработал и не вижу очевидного. ТО ли что-то еще. В интернете тоже не нашел информации, что от правил маршрутизации tcpdump может перестать видеть пакеты.

★★

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

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

anonymous ()

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

что покажет?

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

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

anto215 ★★ ()

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

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

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

as_lan ★★ ()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

as_lan ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.