Re: nat не натит сеть, которая недоступна напрямую

2013-05-29 Пенетрантность Eugene Berdnikov 
On Wed, May 29, 2013 at 03:19:46PM +0400, Mikhail A Antonov wrote:
> 29.05.2013 14:27, Eugene Berdnikov пишет:
...
> >  лишнего. Не пишите "! -d 172.16.2.44/32" в правиле SNAT, оно там излишне
> >  потому что пакет с локальным dst_ip в POSTROUTING не попадёт. Но эта
> >  мелочь режет глаз, а с чайниками в netdev никто разговаривать не хочет.
> Замечено следующее - если на сервере запущен какой-то сервис (пусть
> будет почтовый сервер) и пользователь из локальной сети захочет
> подключиться к этому серверу используя внешний адрес - у него ничего не
> выйдет. Если в правиле указать что если dst свой - не натить - то всё
> работает.

 Это странно, потому что, повторю, пакет с локальным dst_ip не должен
 попадать в POSTROUTING. И если указание локального адреса в правиле
 что-то меняет, это уже повод задуматься... Я подозреваю, что в Вашей
 конфигурации где-то дважды отрабатывает conntrack, потому что пакет
 проходит "транзитом" через сетевую подсистему HN два раза, заныривая
 по пути в виртуалку GW. И это обстоятельство может привести к каким-то
 ошибкам (багам) в районе nat'a, потому что для nat'a существеннен факт
 принадлежности пакета уже установленной коннекции.

 Для диагностики этого дела можно дополнить tcpdump и трассировку цепочек
 мониторингом коннекций. Запускайте conntrack -E (-n, -g, -j), кроме того,
 можно нашинковать цепочки iptables логгированием (-j LOG) состояний
 контрака, чтобы выяснить, в какой момент коннекция регистрируется ядром,
 где она переходит из NEW в ESTABLISHED и т.д. Возможно, тогда станет
 ясно, почему в POSTROUTING она неправильно обрабатывается.

> пользователь с ноутом, на котором настроен почтовый клиент, который
> подключается к серверу по имени mail.company.com.
> Он всегда будет получать внешний адрес mail.company.com и пытаться к
> нему подключиться.
> Из внешней сети он нормально будет работать. Из внутренней - нет.

 Вообще говоря, в случае стандартной конфигурации шлюза подключение
 через внутренний интерфейс по внешнему адресу должно работать.

> Можно нагородить костылей в виде заворачивания всех dns-запросов к себе
> и отдавать локальные адреса локальным пользователям, используя view в
> bind, но чем оно лучше?

 Для вьюшек не нужно заворачивать запросы на шлюзе, достаточно просто
 иметь собственный dns. :) Вьюшки это настолько полезный и удобный
 функционал, что я просто не представляю, как без них жить... Но это
 отдельный вопрос, никак не связанный с багами nat'а, a чем вьюшки
 лучше nat'а -- ну, наверное тем же, чем тёплое лучше мягкого. :)
-- 
 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/20130529144024.gh3...@sie.protva.ru

Re: nat не натит сеть, которая недоступна напрямую

2013-05-29 Пенетрантность Mikhail A Antonov 
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  -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

Re: nat не натит сеть, которая недоступна напрямую

2013-05-29 Пенетрантность 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  -j TRACE.

> tcpdump тоже смотрел:
> root@klon-gw:~# tcpdump -pni any -vvv host 213.79.76.3

 Здесь непонятно, через какие интерфейсы ходят пакеты. Вы думаете, что
 знаете их точно, но постороннему человеку нужны доказательства.
 К тому же с бриджами всё непросто, там можно отдельно слушать brX,
 а можно те интерфейсы, которые к бриджу подключены, и получать
 разные результаты.

> на GW - пакет пришёл, пакет ушёл
> на HN - пакет пришёл на физику, ушёл в бридж, вернулся в vnet, прошёл
> через hn на выход на другую физику
> Всё работает, кроме ната.

 Да, похоже на баг. Но таки проверьте, что что все интерфейсы и цепочки
 проходятся в нужной последовательности.

> >> Если я нарвался на ядерный баг - куда мне писать?
> >  В net...@vger.kernel.org. Но если нет готовности собирать у себя ядро
> >  из свежего git'а и делать бисекты, а также пробовать патчи от тамошних
> >  хакеров, то лучше туда не соваться, а искать обходной путь... IMHO.
> Эта конфигурация легко собирается на любой машине, на которой сможет
> работать kvm. Не думаю что тамошним хакерам будет удобно играть в
> испорченный телефон. Быстрее, проще и удобнее у себя такое же сделать.

 Наивный человек, :) никто не будет городить такое страшилище с kvm,
 а собирать ядро придётся Вам, если вообще кого-то эта тема заинтересует.
 Причём заинтересовать может лишь если ситуация воспроизводится на самом
 свежем ядре из git'а, которое сейчас под рукой у девелоперов.

 Нужен простой и понятный тесткейс: два интерфейса, одно правило, ничего
 лишнего. Не пишите "! -d 172.16.2.44/32" в правиле SNAT, оно там излишне
 потому что пакет с локальным dst_ip в POSTROUTING не попадёт. Но эта
 мелочь режет глаз, а с чайниками в netdev никто разговаривать не хочет.
-- 
 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/20130529102701.gb4...@protva.ru

Re: nat не натит сеть, которая недоступна напрямую

2013-05-29 Пенетрантность Mikhail A Antonov 
29.05.2013 10:50, Eugene Berdnikov пишет:
>
>  Проверьте tcpdump'ом с обеих сторон и трассировкой правил iptables,
>  может быть, там всё-таки есть ошибка конфигурации.

iptables приводил в первом письме.

tcpdump тоже смотрел:
root@klon-gw:~# tcpdump -pni any -vvv host 213.79.76.3
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture
size 65535 bytes
23:58:36.450112 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
ICMP (1), length 84)
172.17.1.2 > 213.79.76.3: ICMP echo request, id 14733, seq 1, length 64
23:58:36.450161 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto
ICMP (1), length 84)
172.17.1.2 > 213.79.76.3: ICMP echo request, id 14733, seq 1, length 64

root@klon-hn0:~# tcpdump -pni any -vvv host 213.79.76.3
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture
size 65535 bytes
23:58:38.907749 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
ICMP (1), length 84)
172.17.1.2 > 213.79.76.3: ICMP echo request, id 14733, seq 1, length 64
23:58:38.907772 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
ICMP (1), length 84)
172.17.1.2 > 213.79.76.3: ICMP echo request, id 14733, seq 1, length 64
23:58:38.907958 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto
ICMP (1), length 84)
172.17.1.2 > 213.79.76.3: ICMP echo request, id 14733, seq 1, length 64
23:58:38.907958 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto
ICMP (1), length 84)
172.17.1.2 > 213.79.76.3: ICMP echo request, id 14733, seq 1, length 64
23:58:38.907967 IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF], proto
ICMP (1), length 84)
172.17.1.2 > 213.79.76.3: ICMP echo request, id 14733, seq 1, length 64
на GW - пакет пришёл, пакет ушёл
на HN - пакет пришёл на физику, ушёл в бридж, вернулся в vnet, прошёл
через hn на выход на другую физику
Всё работает, кроме ната.

На br1 на HN повесил 172.17.1.1, потушив GW:
root@klon-hn0:~# tcpdump -pni any -vvv host 213.79.76.3
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture
size 65535 bytes
00:23:06.865122 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
ICMP (1), length 84)
172.17.1.2 > 213.79.76.3: ICMP echo request, id 16360, seq 1, length 64
00:23:06.865147 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto
ICMP (1), length 84)
172.16.2.44 > 213.79.76.3: ICMP echo request, id 16360, seq 1, length 64
00:23:06.870937 IP (tos 0x0, ttl 56, id 24230, offset 0, flags [none],
proto ICMP (1), length 84)
213.79.76.3 > 172.16.2.44: ICMP echo reply, id 16360, seq 1, length 64
00:23:06.870953 IP (tos 0x0, ttl 55, id 24230, offset 0, flags [none],
proto ICMP (1), length 84)
213.79.76.3 > 172.17.1.2: ICMP echo reply, id 16360, seq 1, length 64
00:23:06.870956 IP (tos 0x0, ttl 55, id 24230, offset 0, flags [none],
proto ICMP (1), length 84)
213.79.76.3 > 172.17.1.2: ICMP echo reply, id 16360, seq 1, length 64
Пакет проходит как надо.


А вот что будет если включить нат на GW:
root@klon-gw:~# tcpdump -pni any -vvv host 213.79.76.3
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture
size 65535 bytes
00:41:28.400688 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
ICMP (1), length 84)
172.17.1.2 > 213.79.76.3: ICMP echo request, id 17548, seq 1, length 64
00:41:28.400717 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto
ICMP (1), length 84)
172.17.0.2 > 213.79.76.3: ICMP echo request, id 17548, seq 1, length 64
00:41:28.407494 IP (tos 0x0, ttl 55, id 24226, offset 0, flags [none],
proto ICMP (1), length 84)
213.79.76.3 > 172.17.0.2: ICMP echo reply, id 17548, seq 1, length 64
00:41:28.407504 IP (tos 0x0, ttl 54, id 24226, offset 0, flags [none],
proto ICMP (1), length 84)
213.79.76.3 > 172.17.1.2: ICMP echo reply, id 17548, seq 1, length 64

tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture
size 65535 bytes
00:41:30.272168 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
ICMP (1), length 84)
172.17.1.2 > 213.79.76.3: ICMP echo request, id 17548, seq 1, length 64
00:41:30.272189 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
ICMP (1), length 84)
172.17.1.2 > 213.79.76.3: ICMP echo request, id 17548, seq 1, length 64
00:41:30.272635 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto
ICMP (1), length 84)
172.17.0.2 > 213.79.76.3: ICMP echo request, id 17548, seq 1, length 64
00:41:30.272635 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto
ICMP (1), length 84)
172.17.0.2 > 213.79.76.3: ICMP echo request, id 17548, seq 1, length 64
00:41:30.272648 IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF], proto
ICMP (1), length 84)
172.16.2.44 > 213.79.76.3: ICMP echo request, id 17548, seq 1, length 64
00:41:30.278967 IP (tos 0x0, ttl 56, id 24226, offset 0, flags [none],
proto ICMP (1), length 84)
213.79.76.3 > 172.16.2.44: ICMP echo reply, id 17548, seq 1, length 64
00:41:30.278988 IP (tos 0x0, ttl 55, id 24226, offset 0, flags [none],
proto ICMP (1), length 84)
213

Re: nat не натит сеть, которая недоступна напрямую

2013-05-29 Пенетрантность Mikhail A Antonov 
29.05.2013 09:56, Dmitry A. Zhiglov пишет:
> Мне эта тема тоже интересна. На squeeze в подобной конфигурации пакеты
> вылетали не через виртуализованный гейт, а через ip, который был
> присвоен "виртуальному коммутатору", то есть если создана
> vnet0:192.168.0.1/24 и в ней находятся виртуалки, то пакет летит не с
> виртуализованного шлюза виртуальной сети (например адрес гейта
> 192.168.0.254) а с 192.168.0.1, который является "шлюзом" для vnet0
> "гипервизора".
Какой IP ближе к пользователю - с того и летит. Это логично и нормально.
Именно поэтому на бридже у HN нет адреса из сети с пользователями.

> Еще, когда kvm создает виртуальные сети (они же "виртуальные
> коммутаторы"), то на гипервизоре он настраивает как-то iptables.
> Попробуйте посмотреть как изменяется iptables и возможно ebtables на
> гипервизоре до создания (и/или активации погашенной) vnet0 и после
> создания/активации, может там есть что подкрутить.
У меня он "сам" iptables не трогает. При запуске виртуальной машины kvm
создаёт vnet виртуальной машины и подключает его к созданному мной
"вручную" бриджу. Больше kvm ничего не делает в плане сети.


-- 
Best regards,
Mikhail
-
WWW: http://www.antmix.ru/
XMPP: ant...@stopicq.ru



signature.asc
Description: OpenPGP digital signature

Re: nat не натит сеть, которая недоступна напрямую

2013-05-28 Пенетрантность Eugene Berdnikov 
On Wed, May 29, 2013 at 12:39:25AM +0400, Mikhail A Antonov wrote:
> Если трафик проходит через GW и имеет адрес не GW - пакет проходит через
> HN, но nat не выполняется.

 Проверьте tcpdump'ом с обеих сторон и трассировкой правил iptables,
 может быть, там всё-таки есть ошибка конфигурации.
 
> Если я нарвался на ядерный баг - куда мне писать?

 В net...@vger.kernel.org. Но если нет готовности собирать у себя ядро
 из свежего git'а и делать бисекты, а также пробовать патчи от тамошних
 хакеров, то лучше туда не соваться, а искать обходной путь... IMHO.
-- 
 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/20130529065052.gw4...@protva.ru

Re: nat не натит сеть, которая недоступна напрямую

2013-05-28 Пенетрантность Dmitry A. Zhiglov 
29 мая 2013 г., 0:39 пользователь Mikhail A Antonov  написал:
> 28.05.2013 23:58, Eugene Berdnikov пишет:
>> On Tue, May 28, 2013 at 10:40:39PM +0400, Mikhail A Antonov wrote:
>> [skip]
>>> Есть идеи что это и почему оно работает не так, как предполагается?
>>  Стык бриджа с ip-nat довольно редко применяется, он плохо отлажен,
>>  здесь есть хорошие шансы найти несколько новых ядерных багов...
> Я пробовал повесить на br1, который сбриджован с eth0, который смотрит в
> сеть с пользователями IP 172.17.1.1/24 (потушив виртуалку GW и убрав
> маршрут из таблицы маршрутизации) - нат заработал.
> Если нат включить на GW - то процесс ната выполняется дважды, но
> пользователи получают интернет.
> Если трафик проходит через GW и имеет адрес не GW - пакет проходит через
> HN, но nat не выполняется.
>
> Если я нарвался на ядерный баг - куда мне писать?
>
> Интересно, а на xen этот баг повторяется? Есть счастливчики с такой
> конфигурацией с xen?

Мне эта тема тоже интересна. На squeeze в подобной конфигурации пакеты
вылетали не через виртуализованный гейт, а через ip, который был
присвоен "виртуальному коммутатору", то есть если создана
vnet0:192.168.0.1/24 и в ней находятся виртуалки, то пакет летит не с
виртуализованного шлюза виртуальной сети (например адрес гейта
192.168.0.254) а с 192.168.0.1, который является "шлюзом" для vnet0
"гипервизора".
Еще, когда kvm создает виртуальные сети (они же "виртуальные
коммутаторы"), то на гипервизоре он настраивает как-то iptables.
Попробуйте посмотреть как изменяется iptables и возможно ebtables на
гипервизоре до создания (и/или активации погашенной) vnet0 и после
создания/активации, может там есть что подкрутить.

Re: nat не натит сеть, которая недоступна напрямую

2013-05-28 Пенетрантность Mikhail A Antonov 
28.05.2013 23:58, Eugene Berdnikov пишет:
> On Tue, May 28, 2013 at 10:40:39PM +0400, Mikhail A Antonov wrote:
> [skip]
>> Есть идеи что это и почему оно работает не так, как предполагается?
>  Стык бриджа с ip-nat довольно редко применяется, он плохо отлажен,
>  здесь есть хорошие шансы найти несколько новых ядерных багов...
Я пробовал повесить на br1, который сбриджован с eth0, который смотрит в
сеть с пользователями IP 172.17.1.1/24 (потушив виртуалку GW и убрав
маршрут из таблицы маршрутизации) - нат заработал.
Если нат включить на GW - то процесс ната выполняется дважды, но
пользователи получают интернет.
Если трафик проходит через GW и имеет адрес не GW - пакет проходит через
HN, но nat не выполняется.

Если я нарвался на ядерный баг - куда мне писать?

Интересно, а на xen этот баг повторяется? Есть счастливчики с такой
конфигурацией с xen?

-- 
Best regards,
Mikhail
-
WWW: http://www.antmix.ru/
XMPP: ant...@stopicq.ru



signature.asc
Description: OpenPGP digital signature

Re: nat не натит сеть, которая недоступна напрямую

2013-05-28 Пенетрантность Eugene Berdnikov 
On Tue, May 28, 2013 at 10:40:39PM +0400, Mikhail A Antonov wrote:
[skip]
> Есть идеи что это и почему оно работает не так, как предполагается?

 Стык бриджа с ip-nat довольно редко применяется, он плохо отлажен,
 здесь есть хорошие шансы найти несколько новых ядерных багов...

 Я под 2.6.30 сталкивался с тем, что в направлении ethX->brX пакеты
 не натятся, хотя в обратном направлении brX->ethX всё нормально.
 При этом трассировка показывала, что пакеты идут по PREROUTING и
 пролетают мимо правила DNAT, как это им удаётся -- непонятно. :-)
 Нужно было копаться в сорцах ядра, но я не стал париться, быстро
 решил свою проблему через -J REDIRECT и юзерспейсовый форвардер.
-- 
 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/20130528195848.gg3...@sie.protva.ru

nat не натит сеть, которая недоступна напрямую

2013-05-28 Пенетрантность Mikhail A Antonov 
Здравствуйте.
Имею проблему с nat - правило есть, преобразования не происходит.
Свежеустановленный debian wheezy.
~# uname -a
Linux klon-hn0 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2+deb7u2 x86_64 GNU/Linux
~# iptables --version
iptables v1.4.14


Есть железная машина [HN], на которой запускаются виртуалки.
~# ip a
1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc mq master br1
state UP qlen 1000
link/ether 88:51:fb:28:fa:2c brd ff:ff:ff:ff:ff:ff
3: eth1:  mtu 1500 qdisc mq state UP
qlen 1000
link/ether 88:51:fb:28:fa:2d brd ff:ff:ff:ff:ff:ff
inet 172.16.2.44/24 brd 172.16.2.255 scope global eth1
inet6 2001:67c:2158:a039:8a51:fbff:fe28:fa2d/64 scope global dynamic
   valid_lft 86248sec preferred_lft 14248sec
inet6 fe80::8a51:fbff:fe28:fa2d/64 scope link
   valid_lft forever preferred_lft forever
4: br0:  mtu 1500 qdisc noqueue state UP
link/ether fe:54:00:00:d2:81 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/28 brd 172.17.0.15 scope global br0
inet6 fe80::6c53:b6ff:fef6:a74c/64 scope link
   valid_lft forever preferred_lft forever
5: br1:  mtu 1500 qdisc noqueue state UP
link/ether 88:51:fb:28:fa:2c brd ff:ff:ff:ff:ff:ff
inet 172.17.0.17/28 brd 172.17.0.31 scope global br1
inet6 fe80::8a51:fbff:fe28:fa2c/64 scope link
   valid_lft forever preferred_lft forever
6: vnet0:  mtu 1500 qdisc pfifo_fast
master br0 state UNKNOWN qlen 500
link/ether fe:54:00:00:d2:81 brd ff:ff:ff:ff:ff:ff
inet6 fe80::fc54:ff:fe00:d281/64 scope link
   valid_lft forever preferred_lft forever
7: vnet1:  mtu 1500 qdisc pfifo_fast
master br1 state UNKNOWN qlen 500
link/ether fe:54:00:12:84:dc brd ff:ff:ff:ff:ff:ff
inet6 fe80::fc54:ff:fe12:84dc/64 scope link
   valid_lft forever preferred_lft forever

Вот так выглядят бриджи:
~# brctl show
bridge namebridge idSTP enabledinterfaces
br08000.fe54d281novnet0
br18000.8851fb28fa2cnoeth0
vnet1
Таблица маршрутизации:
~# ip r
default via 172.16.2.1 dev eth1
172.16.2.0/24 dev eth1  proto kernel  scope link  src 172.16.2.44
172.17.0.0/28 dev br0  proto kernel  scope link  src 172.17.0.1
172.17.0.16/28 dev br1  proto kernel  scope link  src 172.17.0.17
172.17.1.0/24 via 172.17.0.2 dev br0

Собсно правило NAT:

~# iptables-save -t nat
# Generated by iptables-save v1.4.14 on Tue May 28 20:42:38 2013
*nat
:PREROUTING ACCEPT [1066:99540]
:INPUT ACCEPT [5:339]
:OUTPUT ACCEPT [1:80]
:POSTROUTING ACCEPT [864:77910]
-A POSTROUTING ! -d 172.16.2.44/32 -o eth1 -j SNAT --to-source 172.16.2.44
COMMIT
# Completed on Tue May 28 20:42:38 2013

Т.е. схематично сеть выглядит так:
[(eth1:172.16.2.44)-HN-(br0:172.17.0.1)]~~~[(eth0:172.17.0.2)-GW-(eth1:172.17.1.1)]===[(eth0:172.17.1.2)-USER]

Трафик с GW, проходящий через HN - натится
а вот трафик от USER (обычная машина, включённая в eth0 на HN) - не натится
т.е. tcpdump -pni eth1 на HN показывает трафик с IP-адресом от USER,
хотя должен был понатить

GW является kvm-вируалкой, которая физически живёт на машине HN
её eth0 сбриждован с br0, который в реальные eth не смотрит
eth1 от GW сбриджован с br1, который физически уходит на eth0 HN
Пересечений по интерфейсам (физическим и логическим) я не наблюдаю

Вот адреса на GW:
~# ip a
1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc pfifo_fast
state UP qlen 1000
link/ether 52:54:00:00:d2:81 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.2/28 brd 172.17.0.15 scope global eth0
inet6 fe80::5054:ff:fe00:d281/64 scope link
   valid_lft forever preferred_lft forever
3: eth1:  mtu 1500 qdisc pfifo_fast
state UP qlen 1000
link/ether 52:54:00:12:84:dc brd ff:ff:ff:ff:ff:ff
inet 172.17.1.1/24 brd 172.17.1.255 scope global eth1
inet 192.168.15.205/24 scope global eth1
inet6 fe80::5054:ff:fe12:84dc/64 scope link
   valid_lft forever preferred_lft forever

Трафик самой GW уходящий в интернет через HN нормально натится.
Трафик из сети 172.17.1.0/24 (которая напрямую HN не видит) до
172.17.0.1 (адрес HN) ходит, но дальше - не натится.
Имею довольно большое количество установок где натить надо и сети,
доступные напрямую, и сети, которые так же зароучены через другие машины
- и там всё работает.

Физически на машине HN на eth0 висит локалка и iLO от самой машины.
Если на eth0 (т.е. на br1) повесить IP из 172.17.1.0/24 и iLO поставить
адрес из той же сети, то трафик не пойдёт через машину GW.
На GW планируется поставить прозрачную проксю для офиса и возможно
трафикосчиталку. На железную машину, которая занимается запуском
виртуалок, проксю ставить не хочу. Ставить непонятную трафикосчи