On Wed, Jul 10, 2013 at 05:34:37PM +0300, Hleb Valoshka wrote:
> 2013/7/10 Eugene Berdnikov <b...@protva.ru>
>
> > Дамп в студию!
> >
>
> http://pastebin.com/dixe708x -- "хороший" трафик на внутреннем интерфейсе
> http://pastebin.com/c86v742F -- "хороший" трафик на внешнем интерфейсе
>
> http://pastebin.com/AnDLmLG8 -- "плохой" трафик на внутреннем интерфейсе
> http://pastebin.com/ZE0ZUG2w -- "плохой" трафик на внешнем интерфейсе
Насколько я вижу, пакет
13:39:29.950920 IP (tos 0x0, ttl 56, id 58211, offset 0, flags [DF], proto TCP
(6), length 1492)
68.232.34.223.80 > gateway.49336: Flags [.], cksum 0xd33d (correct), seq
7261:8713, ack 215, win 15872, length 1452
не был передан на внутренний интерфейс. Поэтому возникает подозрение,
что причиной генерации RST является содержимое именно этого пакета.
Нет ли в настройках iptables шлюза правил, которые могут приводить
к генерации RST?
Если правил больше одного, то интересно, где именно теряется тот
недоставленный клиенту пакет. Предлагаю включить трассировку для пакетов,
которые интересны (через iptables -t raw ... -j TRACE) и попытаться
понять, где ломается нормальная последовательность прохождения пакетов
по цепочкам iptables.
> > > Что интересно, первый RST уходит именно от шлюза, т.к. после iptables -A
> > > OUTPUT -o eth2 --dst 68.232.34.223 -p tcp --dport 80 --tcp-flags RST
> > RST -j
> > > DROP всё работает нормально (eth2 -- это сетевуха, которая "смотрит" в
> > > инет).
> >
> > Это не доказывает, что RST сгенерил именно шлюз. Нужно сравнить с дампом,
> > снятым на том интерфейсе шлюза, к которому подключена виртуалка.
>
> Если это не сам шлюз, то вышеприведённое правило не будет действовать на
> него.
Да, согласен, OUTPUT применяется только к локально сгенерённым пакетам.
> > Заодно убедиться, что трафик не уходит куда-нибудь "налево" (например,
> > через брижд для виртуалок), так что в сети появляется лишний читатель
> > трафика, который может вдруг поперхнуться чужим пакетом.
> >
> И он всегда слушает именно на тех портах, что и проблемный хост?
Был у меня случай, когда трафик перехватывался трояном на заражённом
виндовом компьютере, этот троян иногда (видимо, по причине ошибок
в своём коде) отвечал на те пакеты, которые ловил.
Вычислили заражённую машинку по mac'у, вылечили -- эффект исчез.
В данном случае это кажется невозможным из-за срабатывания правила
в OUTPUT, но если на шлюзе где-то есть бридж, то вероятность наступить
на какой-то баг ядра мне кажется немаленькой.
--
Eugene Berdnikov
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130710163412.gg3...@sie.protva.ru
