Transparent firewall failover

Если выключение одного гостя ломает выход в инет, значит пакеты туда и обратно ходят разными путями. IMHO в stp это можно отрегулировать через стоимость портов.

Посмотри на списки МАС-ов на vSwitchX до выключения одного из гостей и после. Возможно проблема в реализации vSwitch.

Если файрвол будет fullstate, то нужно настраивать conntrackd

1. А чего бы ему не работать то, если «На мостах включен STP»? STP рвет петлю и траффик ходит по одному из путей. Если этот путь сдохнет, то активируется второй, но долго (минуту где-то).

2. Сессии висят на клиенте и сервере, бридж между ними о них ничего не знает. Так что если траффик не пропадёт на долгое время (пока сходится STP), то сессии никуда не денутся.

3. Вряд-ли, странная схема. Ты опиши чего хочешь добиться? Прозрачного файрволла? Не проще ли на роутере файрволлить? Поставь две виртуалки, подними на них VRRP для отказоустойчивости и вторая подхватит адрес первой при ее падении. Ну или добавь к этому менеджер кластера аля Pacemaker для динамического создания правил файрволла на второй ноде.

Либо, если это ESXi, то может отказоустойчивость делать на его уровне? VMWare Fault Tolerance там или просто HA.

При выключении любого из гостей пинг с ПК в «мир» этого даже не замечает, все пакеты проходят.

Вот это сомнительно, значит пинг идёт каким-то другим путем. То что SSH залипает на минуту это норм, схождение STP идёт.

Если выключение одного гостя ломает выход в инет, значит пакеты туда и обратно ходят разными путями. IMHO в stp это можно отрегулировать через стоимость портов.

Выход и инет оно как раз-то не ломает, при серфинге его вообще не чувствуется. Как ходят пактеты - понять трудно. Такое впечатление, что по обоим путям одновременно. STP крутил, никакой реакции.

Если файрвол будет fullstate, то нужно настраивать conntrackd

stateful. Обязательно. А вот как настроить conntrack-sync на безадресных мостах я пока не понял.

1. А чего бы ему не работать то, если «На мостах включен STP»? STP рвет петлю и траффик ходит по одному из путей. Если этот путь сдохнет, то активируется второй, но долго (минуту где-то).

tcpdump -nibr0, запущенный одновременно на обоих гостях, показывает, что трафик идёт через оба моста.

Сессии висят на клиенте и сервере, бридж между ними о них ничего не знает.

Эт-то понятно, уровень другой. Но сессии реагируют на потерю пакета/серии пакетов.

Так что если траффик не пропадёт на долгое время (пока сходится STP), то сессии никуда не денутся.

Ну вот пропадает, значить.

странная схема.

Возможно.

Ты опиши чего хочешь добиться?

Описал же в топе)

Прозрачного файрволла?

Угу. Отказоустойчивого.

Не проще ли на роутере файрволлить?

Нет. В ЦОД роутер не мой будет, а хостера. Ставить свой аппаратный фаер - создавать единую точку отказа. Ставить два фаера - ... Дорого. 2U + сами железки. Народ не поймёт)

Поставь две виртуалки, подними на них VRRP для отказоустойчивости и вторая подхватит адрес первой при ее падении.

Какой такой адрес, мосты прозрачные же.

Либо, если это ESXi, то может отказоустойчивость делать на его уровне? VMWare Fault Tolerance там или просто HA.

FT - ограничение на один вирт. процессор. Эти два тазика ещё роутить кое-что будут по мелочи (вот тут уже VRRP нужон будет), DHCP + dns fwd. Хотелось бы, чтобы у каждого было по два потока.

HA - грузиться машинка будет минуту-полторы, в это время сети, очевидно, не будет. Это нежелательно.

Вот это сомнительно, значит пинг идёт каким-то другим путем. То что SSH залипает на минуту это норм, схождение STP идёт.

Вот! Вот в том-то и дело, что другого пути нет ни физически, ни логически, пинги эти tсpdump'ом на мостах видны (на обоих сразу), но на выключение одной «половинки» пингу по фигу.

пинги эти tсpdump'ом на мостах видны (на обоих сразу)

Это особенность vmware вроде - запуск tcpdump переводит вирт.интерфейсы в режим promisc и вирт.свич начинает работать как хаб для этого интерфейса - пихает в него весь траффик, проходящий через себя, как-то делал такое. Это настраивается в св-вах вирт.свича насколько помню.

По поводу пингов нужно смотреть в дампе что происходит после отключения активного пути, как отрабатывает STP и т.п.

При прочих равных конечно разницы между пингами и SSH быть не должно - или всё работает или ничего.

Это особенность vmware вроде - запуск tcpdump переводит вирт.интерфейсы в режим promisc и вирт.свич начинает работать как хаб для этого интерфейса - пихает в него весь траффик, проходящий через себя, как-то делал такое. Это настраивается в св-вах вирт.свича насколько помню.

Так-так, погоди, tcpdump запущен в дебьяне и слушает мост внутри дебьяна. Про то, что снаружи матрица, он вообще не знает :) vSwitch'и и так пришлось перевести в promisc режим (как раз в свойствах), иначе он не посылал ответные пакеты (идущие на хост «за виртуалкой») на интерфейс виртуалки. Весь трафик он в него, кажется, всё же не пихает - пинги (говорю о них, потому что их отследить легче, чем прочий траф) «размазываются» по мостам. Вроде бы, случайным образом.

По поводу пингов нужно смотреть в дампе что происходит после отключения активного пути, как отрабатывает STP и т.п.

Вот да, этим завтра и займусь. Надо же понять как оно всё работает, в конце концов.

При прочих равных конечно разницы между пингами и SSH быть не должно - или всё работает или ничего.

Да, возможно, я что-то упустил. Но при нескольких пробных запусках/отключениях картина была именно такая.

Так-так, погоди, tcpdump запущен в дебьяне и слушает мост внутри дебьяна. Про то, что снаружи матрица, он вообще не знает

Да, не знает. Но включение tcpdump переводит интерфейс в promisc и говорит свичу миррорить туда траффик:

Promiscuous mode is a security policy which can be defined at the virtual switch or portgroup level in vSphere ESX/ESXi. A virtual machine, Service Console or VMkernel network interface in a portgroup which allows use of promiscuous mode can see all network traffic traversing the virtual switch.

(c) http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=...

Причем насколько я помню добавление интерфейса в бридж автоматом влючает promisc режим.

vSwitch'и и так пришлось перевести в promisc режим

Это не promisc режим, это секьюрити-опция, позволяющая виртуалкам на этом свиче слушать траффик (или не позволяющая :)

Забей на мосты, и извраты с STP (для такой топологии лучше бы нечто вроде smart-link иметь), го на L3

Если я тебя правильно понял, то ты советуешь отказаться от прозрачного fw, сделать роутер с реальным IP и фильтровать трафик уже на нём? Но тогда он будет иметь адрес в публичной сети. То есть, с учётом VRRP у нас получается перерасход пяти белых IP + потенциальная возможность атаки на сам router/fw.