То ли лыжи не едут... br0 && NAT && KVM

address x.y.z.251

адрес .251 ты скорее всего не увидишь, т.к.

iface br0 inet static
        address x.y.z.249
[...]
        bridge_ports eth0

Я прописывал и другие подсети (которые естественно не используются в NAT) - результат один и тот же.

Т.е. будет виден 249-й?

eth0 не видна извне

Ну так заходи по IP бриджа.

Ага, понял. А как быть с NAT`ом? Он то ходить наружу перестает.

Тебе бридж только для виртуалок нужен? Тогда не надо в него eth0 добавлять.

Вот у меня есть «внутренний бридж». Наружу он ходит вот так:

-A POSTROUTING -s 172.16.4.0/24 -j MASQUERADE
net.ipv4.ip_forward = 1

Это всё, больше я ничего не делал.

Считай что бридж это объединялка сегметов локальной сети, эдакий свитч.

Да, только для KVM, и чтобы она не цепляла NAT и алиас eth0:1.

Я не совсем пойму, тогда как его указывать? или параметр «bridge_ports eth0» мы опускаем и создаем подсеть для виртуалок, где br0 - шлюз для них?

параметр «bridge_ports eth0» мы опускаем

Попробуй так, у меня не осталось тачек на дебиане/убунту, поэтому конфигом не подскажу :)

создаем подсеть для виртуалок, где br0 - шлюз для них?

Да, всё верно. Ещё чуть-чуть и будет рабочая сетка!

Кажется понял, как оно работает. Проверю где-то через час, когда народ свалит с рабочих мест:-)

Если хост с KVM реально не маршрутизирует пакеты, то натить бриджеванные пакеты будет не просто.

В таком случае понадобиться конструкция типа

iptables -t nat -A POSTROUTING -m physdev --physdev-in XXX -s n.n.n.n/p -j SNAT --to-source .....

Без «echo 1 >/proc/sys/net/bridge/bridge-nf-call-iptables» оно работать не будет.

Да еще в др. таблицах iptables не забыть разрешающие правила.

В смысле не маршрутизирует? Он и есть шлюз для 15+ подсетей. Про данную опцию я где-то читал.

И еще:

sysctl net.bridge.bridge-nf-call-iptables=1
sysctl: cannot stat /proc/sys/net/bridge/bridge-nf-call-iptables: Нет такого файла или каталога

Я вот что пытаюсь понять - пакеты из виртуалной машины подключенной к мосту маршутизируются kvm-хостом или только коммутируются мостом ?

Если оно машрутизируется, то проблем с натом нет. А вот если оно только коммутитуются, то для перехватывата и ната на уровне IP требуется поддержка в ядре CONFIG_BRIDGE_NETFILTER=y.

PS На протах моста ip-адресов не должно быть, иначе логика становится совсем непонятной.

Походу маршрутизируется. Как я понял, схема такова: 192.168.0.2 (KVM-guest) -> 192.168.0.1 (br0, шлюз) -> x.y.z.251 (eth0). eth0 <-> br0 natится хостом. Значит проблем быть не должно, все ок.

192.168.0.0/24 это одна сетка на br0, а x.y.z.251/24 вторая (через алиас)?

А зачем в этом случае eth0 запихнули в мост ???? Тебе нужно для виртуалки честный адрес из x.y.z.0/24 ? Тогда при чем тут нат ?

Оставь в бридже только виртуалку, eth0 верни как отдельный интерфейс.

eth0 - x.y.z.251. eth0:1 - x.y.z.250, зачем это сделано я писал тут. Собственно eth0 из бриджа выкинул, да, две сети, белая для выхода инет и 192.168.0.0/24 для KVM.

auto br0
iface br0 inet static
        address 192.168.0.1
        network 192.168.0.0
        broadcast 192.168.0.255
        bridge_stp off
        bridge_fd 0
        bridge_maxwait 0

Как-то так. br0 даже не появился в ifconfig -a, хотя раньше появлялся.

Бгы, а командами через brctl создается. Копаю дальше.

bridge_ports none

пропустил. Интерфейс завелся, и даже при пробросе маршрута ручками на хосте с белым ip из той же подсетки пингается. Завтра будем пускать KVM.

Эммм... ты что-то очень странное делаешь: навешиваешь адрес на интерфейс, который участвует в бридже. Оно не может так работать, если интерфйес в бридже, им рулит драйвер бриджа.

Можешь навесить на бридж оба адреса x.y.z.249,251 - так оно работать будет.

Да я уже разобрался, что мне нужно:-)

Как это не осталось, а что юзаем вместо debian на серваках?

Петросянчик

iface eth0 inet static

bridge_ports eth0

да уж.

Родственник?

а что юзаем вместо debian на серваках?

У меня только один боевой сервер (и два для экспериментов). На физических машинах арчик, внутри боевых тазиков ubuntu 12.04 lts.

Я так сделал потому что мне нужно было свежее ядро и свежий qemu. На мастер машине подняты только ssh и qemu, поэтому с апдейтами особой возни нет.

Возможно, при следующем переезде поменяю на ubuntu lts (какой-нить 14.04 когда выйдет) чтобы ещё меньше париться.

Пробовал всякие centos и scientific linux, не моё это.

У debian пугает время поддержки?

Раньше да, пугало :). Щас пофиг уже даже пофиг на дистр, лишь бы можно было один раз настроить и дальше не париться с поддержкой. А ещё убунта строится на debian testing. Т.е. там софт посвежее чем в стабильном дебиане. Вот для меня это ключевой момент.