29 мая 2013 г., 0:39 пользователь Mikhail A Antonov <[email protected]> написал: > 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 и после создания/активации, может там есть что подкрутить.
