29.05.2013 14:27, Eugene Berdnikov пишет: > On Wed, May 29, 2013 at 01:41:11PM +0400, Mikhail A Antonov wrote: >> 29.05.2013 10:50, Eugene Berdnikov пишет: >>> Проверьте tcpdump'ом с обеих сторон и трассировкой правил iptables, >>> может быть, там всё-таки есть ошибка конфигурации. >> iptables приводил в первом письме. > Я сказал "трассировку": iptables -t raw <selector> -j TRACE. Я не верно понял. Спасибо, посмотрю на это подробнее. Ни разу не пользовался.
>> tcpdump тоже смотрел: >> root@klon-gw:~# tcpdump -pni any -vvv host 213.79.76.3 > Здесь непонятно, через какие интерфейсы ходят пакеты. Вы думаете, что > знаете их точно, но постороннему человеку нужны доказательства. > К тому же с бриджами всё непросто, там можно отдельно слушать brX, > а можно те интерфейсы, которые к бриджу подключены, и получать > разные результаты. У меня слушается именно бридж. Про это прослушивание eth я в курсе. Когда буду писать в netdev разнесу tcpdump по интерфейсам >> на GW - пакет пришёл, пакет ушёл >> на HN - пакет пришёл на физику, ушёл в бридж, вернулся в vnet, прошёл >> через hn на выход на другую физику >> Всё работает, кроме ната. > Да, похоже на баг. Но таки проверьте, что что все интерфейсы и цепочки > проходятся в нужной последовательности. Я проверил. Но попробую трассировку применить. >>>> Если я нарвался на ядерный баг - куда мне писать? >>> В net...@vger.kernel.org. Но если нет готовности собирать у себя ядро >>> из свежего git'а и делать бисекты, а также пробовать патчи от тамошних >>> хакеров, то лучше туда не соваться, а искать обходной путь... IMHO. >> Эта конфигурация легко собирается на любой машине, на которой сможет >> работать kvm. Не думаю что тамошним хакерам будет удобно играть в >> испорченный телефон. Быстрее, проще и удобнее у себя такое же сделать. > Наивный человек, :) никто не будет городить такое страшилище с kvm, > а собирать ядро придётся Вам, если вообще кого-то эта тема заинтересует. > Причём заинтересовать может лишь если ситуация воспроизводится на самом > свежем ядре из git'а, которое сейчас под рукой у девелоперов. > > Нужен простой и понятный тесткейс: два интерфейса, одно правило, ничего > лишнего. Не пишите "! -d 172.16.2.44/32" в правиле SNAT, оно там излишне > потому что пакет с локальным dst_ip в POSTROUTING не попадёт. Но эта > мелочь режет глаз, а с чайниками в netdev никто разговаривать не хочет. Замечено следующее - если на сервере запущен какой-то сервис (пусть будет почтовый сервер) и пользователь из локальной сети захочет подключиться к этому серверу используя внешний адрес - у него ничего не выйдет. Если в правиле указать что если dst свой - не натить - то всё работает. Пример: пользователь с ноутом, на котором настроен почтовый клиент, который подключается к серверу по имени mail.company.com. Он всегда будет получать внешний адрес mail.company.com и пытаться к нему подключиться. Из внешней сети он нормально будет работать. Из внутренней - нет. Можно нагородить костылей в виде заворачивания всех dns-запросов к себе и отдавать локальные адреса локальным пользователям, используя view в bind, но чем оно лучше? -- Best regards, Mikhail - WWW: http://www.antmix.ru/ XMPP: ant...@stopicq.ru
signature.asc
Description: OpenPGP digital signature