2013/7/10 Eugene Berdnikov <[email protected]> > Дамп в студию! >
http://pastebin.com/dixe708x -- "хороший" трафик на внутреннем интерфейсе http://pastebin.com/c86v742F -- "хороший" трафик на внешнем интерфейсе http://pastebin.com/AnDLmLG8 -- "плохой" трафик на внутреннем интерфейсе http://pastebin.com/ZE0ZUG2w -- "плохой" трафик на внешнем интерфейсе > > > потом в адрес repo.maven.apache.org от виртуалки > > уходит пачка ACK, на которые он отвечает RST. > > > > Что интересно, первый RST уходит именно от шлюза, т.к. после iptables -A > > OUTPUT -o eth2 --dst 68.232.34.223 -p tcp --dport 80 --tcp-flags RST > RST -j > > DROP всё работает нормально (eth2 -- это сетевуха, которая "смотрит" в > > инет). > > Это не доказывает, что RST сгенерил именно шлюз. Нужно сравнить с дампом, > снятым на том интерфейсе шлюза, к которому подключена виртуалка. > Если это не сам шлюз, то вышеприведённое правило не будет действовать на него. > > > Смотрю на 2 окна wireshark'а, в одном "проблемный" дамп, в другом -- > > нормальный (снятый при подключении с другой машины). Разница -- размер > окна > > tcp, номер исходящего порта да разные версии wget, и всё. > > > > Что делать? > > Локализовать до пакета, вызывающего RST, и рассмотреть его внимательно. > Не вижу никаких отличий кроме контрольной суммы и номера последовательности. > > Заодно убедиться, что трафик не уходит куда-нибудь "налево" (например, > через брижд для виртуалок), так что в сети появляется лишний читатель > трафика, который может вдруг поперхнуться чужим пакетом. > > И он всегда слушает именно на тех портах, что и проблемный хост?
