LINUX.ORG.RU
ФорумAdmin

Transparent firewall failover

 ,


0

1

Здравствуй, ЛОР!

Есть вот такой стенд: http://itmages.ru/image/view/1520329/d3009d24

На картинке изображены:

  • ПК с браузером, командой ping и ssh-клиентом (PC)
  • Некий маршрутизатор с NAT (LAN router)
  • Хост с ESXi, на котором живут
    • Vyatta 6.6, которая на самом деле Debian squeeze (vFirewall0)
    • клон предыдущей ВМ, vFirewall1

Внути каждого гостя есть мост br0, не имеющий ip-адреса (на них фильтруется трафик). На мостах включен STP. Оба гостя включены.

Цель - получить отказоустойчивый прозрачный файрвол (чтобы любой из двух компонентов можно было останавливать на обслуживание без потери доступа к сервисам). Повторюсь - это стенд, «в реале» вместо ПК будут несколько ВМ с «белыми» IP, и никакого NAT не будет.

Всё работает (на ПК «есть интернет»). Всё пингуется, странички открываются (то есть, tcp-сессии нормально устанавливаются). tcpdump, запущенный на обоих мостах, показывает, что через них дружно-весело бегают пакетики. При выключении любого из гостей пинг с ПК в «мир» этого даже не замечает, все пакеты проходят. SSH-сессия, установленная в «мир», при этом, всё же, подвисает на минуту-полторы.

Вопрос 1. Почему оно работает? О_о Никогда бы не подумал, что такая конфигурация (с параллельно включенными бриджами (читай - свитчами)) будет работоспособна. Собрал просто для эксперимента, и вот - завелось.

Вопрос 2. Раз уж оно так всё работает - нельзя ли каким-либо образом синхронизировать чего-нибудь там (даже не знаю, что), чтобы при «пропадании» одного файрвола сессии уровня приложения (как та же SSH) не подвисали, а сохраняли «целостность»?

Вопрос 3. Применял ли кто из пристутствующих подобные схемы? Буду благодарен, если поделитесь опытом.

★★★

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

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

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

vel ★★★★★ ()

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

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

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

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

blind_oracle ★★★★★ ()

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

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

blind_oracle ★★★★★ ()
Ответ на: комментарий от vel

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

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

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

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

nbw ★★★ ()
Ответ на: комментарий от blind_oracle

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

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

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

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

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

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

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

Возможно.

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

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

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

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

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

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

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

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

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

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

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

nbw ★★★ ()
Последнее исправление: nbw (всего исправлений: 1)
Ответ на: комментарий от blind_oracle

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

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

nbw ★★★ ()
Ответ на: комментарий от nbw

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

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

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

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

blind_oracle ★★★★★ ()
Ответ на: комментарий от blind_oracle

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

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

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

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

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

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

nbw ★★★ ()
Ответ на: комментарий от nbw

Так-так, погоди, 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 режим, это секьюрити-опция, позволяющая виртуалкам на этом свиче слушать траффик (или не позволяющая :)

blind_oracle ★★★★★ ()

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

zolden ★★★★★ ()
Ответ на: комментарий от zolden

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

nbw ★★★ ()
Последнее исправление: nbw (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.