Re: nat не натит сеть, которая недоступна напрямую
29 мая 2013 г., 0:39 пользователь Mikhail A Antonov <bart@solarnet.ru> написал:
> 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 и после
создания/активации, может там есть что подкрутить.
Reply to: