| Руководство по pfSense 2.0. Глава 9 Бриджинг (Мосты) |
 |
 |
 |
| 02.04.12 14:54 |
|
Руководство по pfSense 2.0. Часть 9 Глава 9 Бриджинг (Мосты)
Обычно, каждый интерфейс pfSense представляет собой свой широковещательный домен с уникальной IP подсетью, и действует так же как отдельный коммутатор. В некоторых случаях бывает желательно или необходимо объединить несколько интерфейсов в один широковещательный домен, где два порта брандмауэра будут действовать так, как будто они находятся на одном коммутаторе, за исключением трафика между интерфейсами, которым можно управлять с помощью правил брандмауэра. Обычно такой режим упоминается как прозрачный брандмауэр (transparent firewall).
9.1. Мосты и петли уровня 2
Используя мост, вы должны быть осторожны и избегать возникновения петель второго уровня, либо конфигурировать коммутатор для их обработки в соответствии с вашими требованиями. Петля второго уровня, создаёт тот же эффект, как если бы вы соединили кабелем два порта коммутатора. Если у вас присутствует развёртывание pfSense с двумя интерфейсами, эти интерфейсы объединены в мост, и оба интерфейса подключены к одному коммутатору, вы создали петлю уровня 2. Соединение двух коммутаторов двумя патч-кордами приведёт к тому же эффекту. Управляемые коммутаторы используют протокол Spanning Tree Protocol (STP) для обработки подобной ситуации, поскольку часто бывает необходимо иметь несколько связей между коммутаторами, а вы явно не желаете, чтобы ваша сеть упала если кто-то подключит один порт в другой. STP не включается по умолчанию на всех управляемых коммутаторах, и почти никогда не доступен на неуправляемых коммутаторах. При отсутствии STP, кадры в петле уровня 2 попадают в замкнутый цикл, а сеть перестаёт функционировать до тех пор, пока цикл не будет удалён. В двух словах - мост имеет потенциал полностью вывести из строя сеть если вы не понимаете что делаете.
9.2. Мосты и брандмауэры Фильтрация с функциями объединения интерфейсов не отличается от маршрутизируемых интерфейсов. правила брандмауэра применяются на каждом участвующем интерфейсе моста на входящей основе. Те, кто некоторое время использует pfSense, могут вспомнить о включении флага Enable filtering bridge, на странице System -> Advanced. Ссылки на данный флаг являются устаревшей информацией. Она была унаследована из m0n0wall, который реализовал мост иным способом.
В pfSense используются различные способы преодоления необходимости данного флага, а пути построения моста в новых версиях FreeBSD не позволяют работать с не фильтрующим мостом пока вы полностью не отключите pf.
9.3. Мост двух внутренних сетей Вы можете объединить две внутренние сети для создания одного широковещательного домена и включить фильтрацию трафика между двумя интерфейсами. Обычно, это делается с беспроводным интерфейсом, сконфигурированным как точка доступа, для соединения проводных и беспроводных сегментов в одном широковещательном домене.
Иногда, брандмауэр с интерфейсами LAN и OPT может использоваться в качестве коммутатора, в сетях, где необходимы только две внутренних системы. Вы можете столкнуться и со сценариями, в которых два интерфейса брандмауэра должны находится в одном широковещательном домене для каких-то других специфических целей. Замечание
Существуют дополнительные требования и ограничения, когда объединяются беспроводные интерфейсы, что связано со способом функционирования 802.11. Смотрите раздел 18.3, "Мосты и беспроводные сети" для получения дополнительной информации.
9.3.1. DHCP и внутренние мосты Если вы объединяете одну внутреннюю сеть с другой, необходимо сделать две вещи. Прежде всего убедитесь, что DHCP работает только на основном интерфейсе (с IP адресом), а не на одном из подключаемых в мост. Во-вторых, вам понадобится дополнительное правило брандмауэра вверху набора правил для данного OPT интерфейса, разрешающее DHCP-трафик. Как правило, при создании правила разрешающего трафик на интерфейсе, источник (source) указывается аналогично "OPT1 Subnet", так, что только трафику от подсети разрешается покидать данный сегмент. При использовании DHCP этого не достаточно. Поскольку клиент ещё не имеет IP адреса, DHCP запрос выступает как широковещательный. Для удовлетворения этих запросов, вам необходимо создать правило на интерфейсе моста с Protocol установленным в UDP, Source установленным в 0.0.0.0 и портом источника 68, Destination установленным в 255.255.255.255, и портом назначения 67. Добавьте описание, похожее на "Allow DHCP", а затем нажмите кнопку Save и Apply Changes. В итоге, вы получите правило которое выглядит так как показано на рисунке 9.1, "Правило брандмауэра для разрешения DHCP".
 Рисунок 9.1, "Правило брандмауэра для разрешения DHCP"
После добавления этого правила, клиенты в объединяемом сегменте должны иметь возможность успешно совершать запросы к демону DHCP слушающему на интерфейсе входящем в мост.
9.4. Мост OPT c WAN Мост интерфейсов OPT и WAN позволяет использовать публичные IP адреса во внутренней сети, имеющей IP шлюз размещаемый в сети WAN. Одна из ситуаций когда это бывает необходимо - динамическое назначение публичных IP адресов. Вы можете использовать pfSense для защиты систем которые получают публичные IP адреса непосредственно с DHCP сервера вашего провайдера с помощью интерфейса моста. Это так же полезно в ситуации, когда в наличии имеется блок публичных IP адресов, и необходимо напрямую назначать публичные IP адреса хостам, как описано в разделе 6.7.1.2.1, "Простая IP подсеть".
9.5. Взаимодействие с мостом Интерфейс моста ведёт себя, в некоторых отношениях, несколько иначе, чем обычные интерфейсы, и есть несколько вещей, которые не совместимы с мостом, и некоторые другие, где необходимо воспользоваться дополнительными соображениями для размещения моста. В этом разделе описываются функции, работа которых на интерфейсе моста отличается от работы на простых интерфейсах.
9.5.1. Каптивный портал Каптивный портал (Глава 19, "Каптивный портал") не совместим с мостом, поскольку он требует IP на интерфейсе моста, используемый для обслуживания контента портала. Интерфейсы моста не имеют назначенного IP адреса.
9.5.2. CARP CARP (Глава 20, Избыточность брандмауэра/Высокая доступность) не совместим с мостом в данное время - однако имеется возможность ручного хакинга. Использование CARP с сетями, которые связаны мостом, как правило не рекомендуется, но у некоторых такая установка работает. Особое внимание должно уделяться обработке петли уровня 2, которая неизбежна в сценарии CARP + мост. Когда соединяются два сегмента сети, в действительности, они объединяются в одну большую сеть, как уже говорилось в данной главе. Когда CARP добавляется в эту смесь, это означает, что для каждого интерфейса будет в наличии два пути между коммутаторами и создаётся петля.
Управляемые коммутаторы могут справиться с этой проблемой используя Spanning Tree Protocol (STP), но неуправляемые коммутаторы не имеют защиты от циклов. Оставленная без внимания, петля может вывести сеть из строя и сделать невозможной передачу любого трафика. Если STP отсутствует, можно использовать два других подхода, которые не столь элегантны как STP. Оба этих метода требуют изменения системных файлов pfSense, и особого внимания к системе резервного копирования/восстановления pfSense. Эти методы используют скрипт в cron, или хук devd для управления мостом. Оба метода описаны в постах на форуме CARP/VIP [http://forum.pfsense.org/index.php/topic,4984.0.html].
9.5.2.1. Конфигурирование основного и резервного брандмауэра Конфигурирование основного и резервного брандмауэра производится так же, как и при любом прочем развёртывании CARP, которое мы будем рассматривать в главе 20, "Избыточность брандмауэра/высокая доступность". Сконфигурируйте интерфейс моста на основном и резервном брандмауэре, используя то же описание интерфейса. Если на основном брандмауэре интерфейс моста OPT1, сделайте OPT1 и на резервном. Не подключайте оба моста одновременно, пока не закончите настройку. Вы должны иметь возможность получать доступ к web-интерфейсу. Все действия необходимо будет выполнить для основного и резервного брандмауэра.
9.5.2.2. Конфигурирование STP Даже при активном STP, потребуется некоторое конфигурирование коммутатора, предназначенное для указания правильного действия STP при выборе того, каие порты должны быть открытыми, а какие заблокированными. В противном случае, всё может закончится ситуацией когда весь трафик движется через резервный маршрутизатор моста вместо основного, что приводит к непредсказуемому поведению. Блокировка порта, в данной ситуации, контролируется путём установки приоритетов порта и оценки путей. На коммутаторе Cisco, конфигурация может выглядеть примерно следующим образом:
interface FastEthernet0/1
description Firewall - Primary - DMZ Port
switchport access vlan 20
spanning-tree vlan 20 port-priority 64
no cdp enable
interface FastEthernet0/2
description Firewall - Backup - DMZ Port
switchport access vlan 20
spanning-tree vlan 20 cost 500
no cdp enable
Устанавливая значение приоритета порта ниже чем нормальное значение (64 вместо стандартного 128), мы предполагаем большую вероятность его использования, особенно с учётом более высокой оценки пути (500 вместо стандартного 19), чем прочие порты. Эти значения могут быть проконтролированы следующим образом (на коммутаторе):
# show spanning-tree interface FastEthernet0/1 Interface FastEthernet0/1 (port 13) in Spanning tree 20 is FORWARDING
Port path cost 19, Port priority 64
Designated root has priority 32768, address 0002.4b6e.xxxx
Designated bridge has priority 32768, address 0002.b324.xxxx
Designated port is 3, path cost 131
Timers: message age 6, forward delay 0, hold 0
BPDU: sent 18411032, received 16199798
# show spanning-tree interface FastEthernet0/2 Interface FastEthernet0/2 (port 14) in Spanning tree 20 is BLOCKING
Port path cost 500, Port priority 128
Designated root has priority 32768, address 0002.4b6e.xxxx
Designated bridge has priority 32768, address 0002.b324.xxxx
Designated port is 4, path cost 131
Timers: message age 6, forward delay 0, hold 0
BPDU: sent 434174, received 15750118
Как можно видеть, порт коммутатора основной системы осуществляет пересылку, а порт резервного блокируется. Если трафик через основной порт прекращается, в работу включается резервный. Коммутаторы других производителей поддерживают аналогичную функциональность. Обратитесь к документации вашего коммутатора для получения информации о конфигурировании STP. В pfSense 2.0, STP может конфигурироваться и управляться на интерфейсе моста.
9.5.2.3. Скрипт CARP для cron В данном методе, каждую минут cron запускает выполнения скрипта, который проверяет, является ли система MASTER или BACKUP в кластере CARP. Если система является MASTER, мост поднят, если система является BACKUP, мост не работает. Это позволяет предотвратить возникновение петли, когда в данный момент времени активен только один мост, однако как вы можете заметить, как часто крон запускает скрипт, столько же времени система простаивает до тех пор пока скрипт обнаруживает коммутатор и активирует резервный мост.
9.5.2.3.1. Добавление скрипта Прежде всего, необходимо добавить скрипт, проверяющий статус CARP и соответственно изменить статус моста. Ниже приведён пример, который вы можете использовать. Он доступен для скачивания по адресу [http://files.pfsense.org/misc/bridgecheck.sh].
#!/bin/sh # # CARP check script for bridging #
# from eblevins on the forum #
if ifconfig carp0 | grep BACKUP > /dev/null 2>&1 ; then /sbin/ifconfig bridge0 down else
/sbin/ifconfig bridge0 up fi
Скопируйте этот скрипт куда-нибудь, например в /usr/bin/bridgecheck.sh. Следующая команда позволит скачать этот файл с files.pfsense.org и сохранить его в /usr/bin/bridgecheck.sh. # fetch -o /usr/bin/bridgecheck.sh \ http://files.pfsense.org/misc/bridgecheck.sh
Теперь сделайте этот скрипт запускаемым, используя следующую команду:
# chmod +x /usr/bin/bridgecheck.sh
9.5.2.3.2. Расписание выполнения сценария Теперь, вам потребуется запланировать запуск скрипта. Сохраните резервную копию конфигурации на экране Diagnostics -> Backup/Restore. Откройте конфигурацию в текстовом редакторе и найдите тег <cron>. Вы должны обнаружить раздел конфигурации, содержащий все запланированные задачи, которые обрабатывает cron.
<cron>
<item>
<minute>0</minute>
<hour>*</hour>
<mday>*</mday>
<month>*</month>
<wday>*</wday>
<who>root</who>
<command>/usr/bin/nice -n20 newsyslog</command>
</item>
<item>
<minute>1,31</minute>
<hour>0-5</hour>
<mday>*</mday>
<month>*</month>
<wday>*</wday>
<who>root</who>
<command>/usr/bin/nice -n20 adjkerntz -a</command>
</item>
Добавьте bridgecheck.sh в записи cron. Добавление следующего элемента позволит запускать скрипт каждую минуту.
<item> <minute>*/1</minute> Сделайте изменения для основного и резервного брандмауэра.
9.5.2.3.3. Отключение моста при начальной загрузке Вам потребуется добавить в конфигурацию команду которая позволит отключать мост при первоначальной загрузке. Это предотвратит появление петли уровня 2, а мост будет поднят на мастере CARP с помощью скрипта bridgecheck.sh через минуту после загрузки. Над строкой </system>, необходимо добавить следующую строку:
<shellcmd>/sbin/ifconfig bridge0 down</shellcmd>
Сохраните изменения конфигурационных файлов. Теперь восстановите изменённую конфигурацию на первичном и резервном брандмауэре. Брандмауэры должены перезагрузиться после восстановления конфигурации и нормально работать.
9.5.2.4. devd хук Это решение возможно только в pfSense 1.2.3. или более поздней версии и включает в себя использование devd для отлова актуального состояния перехода CARP, когда это происходит. Отредактируйте /etc/devd.conf на резервном и основном брандмауэрах и добавьте следующие строки:
notify 100 {
match "system" "IFNET";
match "type" "LINK_UP";
match "subsystem" "carp"; action "/usr/local/bin/carpup";
};
notify 100 {
match "system" "IFNET";
match "type" "LINK_DOWN";
match "subsystem" "carp"; action "/usr/local/bin/carpdown";
};
Теперь создайте новые файлы: /usr/local/bin/carpup
#!/bin/sh /sbin/ifconfig bridge0
и: /usr/local/bin/carpdown #!/bin/sh /sbin/ifconfig bridge0 down
Теперь сделаем эти скрипты исполняемыми: # chmod a+x /usr/local/bin/carpup
# chmod a+x /usr/local/bin/carpdown
Это позволит автоматически поднять и положить мост в любое время при обнаружении изменений состояния CARP. 9.5.2.5. Устранение неполадок отказоустойчивого моста Если что-то не работает, как было задумано, проверьте страницу Status -> Interfaces на обеих системах для обзора интерфейса bridge0, и страницу статуса CARP для контроля статуса master и backup CARP. Вы можете выполнить bridgecheck.sh из командной строки, и проверить состояние интерфейсов используя ifconfig. Понимание основ ОС FreeBSD может быть необходимо для успешного выявления и устранения проблем данного типа.
Многие проблемы CARP и мостов могут быть связаны с петлями коммутатора и вопросами STP. Обратитесь к разделу 9.5.2, "CARP", а так же проверьте конфигурацию вашего коммутатора для просмотра статуса интерфейсов моста. Если ваши порты блокированы в то время когда они должны осуществлять пересылку, вам, скорее всего, необходимо настроить параметры STP или использовать один из альтернативных методов закрытия резервного моста.
9.5.3. Multi-WAN Мосты, по своей природе, несовместимы с multi-WAN в большинстве использований. Когда используется мост, обычно нечто иное чем pfSense будет являться шлюзом по умолчанию для хостов на интерфейсе моста, и только этот маршрутизатор может направлять трафик от этих хостов. Это не освобождает вас от использования нескольких WAN интерфейсов с прочими интерфейсами на том же брандмауэре, который не является мостом, а только влияет на хосты интерфейса моста, где они используются иначе чем шлюз по умолчанию pfSense. Если мост объединяет несколько внутренних интерфейсов и pfSense - шлюз по умолчанию для ваших хостов на интерфейсе моста, вы можете использовать multi-WAN так же, как с не мостового интерфейса.
pfSense: The Definitive Guide The Definitive Guide to the pfSense Open
Source Firewall and Router Distribution
Обычно, каждый интерфейс pfSense представляет собой свой широковещательный домен с уникальной IP подсетью, и действует так же как отдельный коммутатор. В некоторых случаях бывает желательно или необходимо объединить несколько интерфейсов в один широковещательный домен, где два порта брандмауэра будут действовать так, как будто они находятся на одном коммутаторе, за исключением трафика между интерфейсами, которым можно управлять с помощью правил брандмауэра. Обычно такой режим упоминается как прозрачный брандмауэр (transparent firewall).
9.1. Мосты и петли уровня 2 Используя мост, вы должны быть осторожны и избегать возникновения петель второго уровня, либо конфигурировать коммутатор для их обработки в соответствии с вашими требованиями. Петля второго уровня, создаёт тот же эффект, как если бы вы соединили кабелем два порта коммутатора. Если у вас присутствует развёртывание pfSense с двумя интерфейсами, эти интерфейсы объединены в мост, и оба интерфейса подключены к одному коммутатору, вы создали петлю уровня 2. Соединение двух коммутаторов двумя патч-кордами приведёт к тому же эффекту. Управляемые коммутаторы используют протокол Spanning Tree Protocol (STP) для обработки подобной ситуации, поскольку часто бывает необходимо иметь несколько связей между коммутаторами, а вы явно не желаете, чтобы ваша сеть упала если кто-то подключит один порт в другой. STP не включается по умолчанию на всех управляемых коммутаторах, и почти никогда не доступен на неуправляемых коммутаторах. При отсутствии STP, кадры в петле уровня 2 попадают в замкнутый цикл, а сеть перестаёт функционировать до тех пор, пока цикл не будет удалён. В двух словах - мост имеет потенциал полностью вывести из строя сеть если вы не понимаете что делаете.
9.2. Мосты и брандмауэры Фильтрация с функциями объединения интерфейсов не отличается от маршрутизируемых интерфейсов. правила брандмауэра применяются на каждом участвующем интерфейсе моста на входящей основе. Те, кто некоторое время использует pfSense, могут вспомнить о включении флага Enable filtering bridge, на странице System -> Advanced. Ссылки на данный флаг являются устаревшей информацией. Она была унаследована из m0n0wall, который реализовал мост иным способом.
В pfSense используются различные способы преодоления необходимости данного флага, а пути построения моста в новых версиях FreeBSD не позволяют работать с не фильтрующим мостом пока вы полностью не отключите pf.
9.3. Мост двух внутренних сетей Вы можете объединить две внутренние сети для создания одного широковещательного домена и включить фильтрацию трафика между двумя интерфейсами. Обычно, это делается с беспроводным интерфейсом, сконфигурированным как точка доступа, для соединения проводных и беспроводных сегментов в одном широковещательном домене.
Иногда, брандмауэр с интерфейсами LAN и OPT может использоваться в качестве коммутатора, в сетях, где необходимы только две внутренних системы. Вы можете столкнуться и со сценариями, в которых два интерфейса брандмауэра должны находится в одном широковещательном домене для каких-то других специфических целей. Замечание
Существуют дополнительные требования и ограничения, когда объединяются беспроводные интерфейсы, что связано со способом функционирования 802.11. Смотрите раздел 18.3, "Мосты и беспроводные сети" для получения дополнительной информации.
9.3.1. DHCP и внутренние мосты Если вы объединяете одну внутреннюю сеть с другой, необходимо сделать две вещи. Прежде всего убедитесь, что DHCP работает только на основном интерфейсе (с IP адресом), а не на одном из подключаемых в мост. Во-вторых, вам понадобится дополнительное правило брандмауэра вверху набора правил для данного OPT интерфейса, разрешающее DHCP-трафик. Как правило, при создании правила разрешающего трафик на интерфейсе, источник (source) указывается аналогично "OPT1 Subnet", так, что только трафику от подсети разрешается покидать данный сегмент. При использовании DHCP этого не достаточно. Поскольку клиент ещё не имеет IP адреса, DHCP запрос выступает как широковещательный. Для удовлетворения этих запросов, вам необходимо создать правило на интерфейсе моста с Protocol установленным в UDP, Source установленным в 0.0.0.0 и портом источника 68, Destination установленным в 255.255.255.255, и портом назначения 67. Добавьте описание, похожее на "Allow DHCP", а затем нажмите кнопку Save и Apply Changes. В итоге, вы получите правило которое выглядит так как показано на рисунке 9.1, "Правило брандмауэра для разрешения DHCP".
Рисунок 9.1, "Правило брандмауэра для разрешения DHCP"
После добавления этого правила, клиенты в объединяемом сегменте должны иметь возможность успешно совершать запросы к демону DHCP слушающему на интерфейсе входящем в мост.
9.4. Мост OPT c WAN Мост интерфейсов OPT и WAN позволяет использовать публичные IP адреса во внутренней сети, имеющей IP шлюз размещаемый в сети WAN. Одна из ситуаций когда это бывает необходимо - динамическое назначение публичных IP адресов. Вы можете использовать pfSense для защиты систем которые получают публичные IP адреса непосредственно с DHCP сервера вашего провайдера с помощью интерфейса моста. Это так же полезно в ситуации, когда в наличии имеется блок публичных IP адресов, и необходимо напрямую назначать публичные IP адреса хостам, как описано в разделе 6.7.1.2.1, "Простая IP подсеть".
9.5. Взаимодействие с мостом Интерфейс моста ведёт себя, в некоторых отношениях, несколько иначе, чем обычные интерфейсы, и есть несколько вещей, которые не совместимы с мостом, и некоторые другие, где необходимо воспользоваться дополнительными соображениями для размещения моста. В этом разделе описываются функции, работа которых на интерфейсе моста отличается от работы на простых интерфейсах.
9.5.1. Каптивный портал Каптивный портал (Глава 19, "Каптивный портал") не совместим с мостом, поскольку он требует IP на интерфейсе моста, используемый для обслуживания контента портала. Интерфейсы моста не имеют назначенного IP адреса.
9.5.2. CARP CARP (Глава 20, Избыточность брандмауэра/Высокая доступность) не совместим с мостом в данное время - однако имеется возможность ручного хакинга. Использование CARP с сетями, которые связаны мостом, как правило не рекомендуется, но у некоторых такая установка работает. Особое внимание должно уделяться обработке петли уровня 2, которая неизбежна в сценарии CARP + мост. Когда соединяются два сегмента сети, в действительности, они объединяются в одну большую сеть, как уже говорилось в данной главе. Когда CARP добавляется в эту смесь, это означает, что для каждого интерфейса будет в наличии два пути между коммутаторами и создаётся петля.
Управляемые коммутаторы могут справиться с этой проблемой используя Spanning Tree Protocol (STP), но неуправляемые коммутаторы не имеют защиты от циклов. Оставленная без внимания, петля может вывести сеть из строя и сделать невозможной передачу любого трафика. Если STP отсутствует, можно использовать два других подхода, которые не столь элегантны как STP. Оба этих метода требуют изменения системных файлов pfSense, и особого внимания к системе резервного копирования/восстановления pfSense. Эти методы используют скрипт в cron, или хук devd для управления мостом. Оба метода описаны в постах на форуме CARP/VIP [http://forum.pfsense.org/index.php/topic,4984.0.html].
9.5.2.1. Конфигурирование основного и резервного брандмауэра Конфигурирование основного и резервного брандмауэра производится так же, как и при любом прочем развёртывании CARP, которое мы будем рассматривать в главе 20, "Избыточность брандмауэра/высокая доступность". Сконфигурируйте интерфейс моста на основном и резервном брандмауэре, используя то же описание интерфейса. Если на основном брандмауэре интерфейс моста OPT1, сделайте OPT1 и на резервном. Не подключайте оба моста одновременно, пока не закончите настройку. Вы должны иметь возможность получать доступ к web-интерфейсу. Все действия необходимо будет выполнить для основного и резервного брандмауэра.
9.5.2.2. Конфигурирование STP Даже при активном STP, потребуется некоторое конфигурирование коммутатора, предназначенное для указания правильного действия STP при выборе того, каие порты должны быть открытыми, а какие заблокированными. В противном случае, всё может закончится ситуацией когда весь трафик движется через резервный маршрутизатор моста вместо основного, что приводит к непредсказуемому поведению. Блокировка порта, в данной ситуации, контролируется путём установки приоритетов порта и оценки путей. На коммутаторе Cisco, конфигурация может выглядеть примерно следующим образом:
interface FastEthernet0/1
description Firewall - Primary - DMZ Port
switchport access vlan 20
spanning-tree vlan 20 port-priority 64
no cdp enable
interface FastEthernet0/2
description Firewall - Backup - DMZ Port
switchport access vlan 20
spanning-tree vlan 20 cost 500
no cdp enable
Устанавливая значение приоритета порта ниже чем нормальное значение (64 вместо стандартного 128), мы предполагаем большую вероятность его использования, особенно с учётом более высокой оценки пути (500 вместо стандартного 19), чем прочие порты. Эти значения могут быть проконтролированы следующим образом (на коммутаторе):
# show spanning-tree interface FastEthernet0/1
Interface FastEthernet0/1 (port 13) in Spanning tree 20 is FORWARDING
Port path cost 19, Port priority 64
Designated root has priority 32768, address 0002.4b6e.xxxx
Designated bridge has priority 32768, address 0002.b324.xxxx
Designated port is 3, path cost 131
Timers: message age 6, forward delay 0, hold 0
BPDU: sent 18411032, received 16199798
# show spanning-tree interface FastEthernet0/2
Interface FastEthernet0/2 (port 14) in Spanning tree 20 is BLOCKING
Port path cost 500, Port priority 128
Designated root has priority 32768, address 0002.4b6e.xxxx
Designated bridge has priority 32768, address 0002.b324.xxxx
Designated port is 4, path cost 131
Timers: message age 6, forward delay 0, hold 0
BPDU: sent 434174, received 15750118
Как можно видеть, порт коммутатора основной системы осуществляет пересылку, а порт резервного блокируется. Если трафик через основной порт прекращается, в работу включается резервный.
Коммутаторы других производителей поддерживают аналогичную функциональность. Обратитесь к документации вашего коммутатора для получения информации о конфигурировании STP. В pfSense 2.0, STP может конфигурироваться и управляться на интерфейсе моста.
9.5.2.3. Скрипт CARP для cron В данном методе, каждую минут cron запускает выполнения скрипта, который проверяет, является ли система MASTER или BACKUP в кластере CARP. Если система является MASTER, мост поднят, если система является BACKUP, мост не работает. Это позволяет предотвратить возникновение петли, когда в данный момент времени активен только один мост, однако как вы можете заметить, как часто крон запускает скрипт, столько же времени система простаивает до тех пор пока скрипт обнаруживает коммутатор и активирует резервный мост.
9.5.2.3.1. Добавление скрипта Прежде всего, необходимо добавить скрипт, проверяющий статус CARP и соответственно изменить статус моста. Ниже приведён пример, который вы можете использовать. Он доступен для скачивания по адресу [http://files.pfsense.org/misc/bridgecheck.sh].
#!/bin/sh #
# CARP check script for bridging #
# from eblevins on the forum #
if ifconfig carp0 | grep BACKUP > /dev/null 2>&1 ; then /sbin/ifconfig bridge0 down else
/sbin/ifconfig bridge0 up fi
Скопируйте этот скрипт куда-нибудь, например в /usr/bin/bridgecheck.sh. Следующая команда позволит скачать этот файл с files.pfsense.org и сохранить его в /usr/bin/bridgecheck.sh. # fetch -o /usr/bin/bridgecheck.sh \ http://files.pfsense.org/misc/bridgecheck.sh
Теперь сделайте этот скрипт запускаемым, используя следующую команду:
# chmod +x /usr/bin/bridgecheck.sh
9.5.2.3.2. Расписание выполнения сценария Теперь, вам потребуется запланировать запуск скрипта. Сохраните резервную копию конфигурации на экране Diagnostics -> Backup/Restore. Откройте конфигурацию в текстовом редакторе и найдите тег <cron>. Вы должны обнаружить раздел конфигурации, содержащий все запланированные задачи, которые обрабатывает cron.
<cron>
<item>
<minute>0</minute>
<hour>*</hour>
<mday>*</mday>
<month>*</month>
<wday>*</wday>
<who>root</who>
<command>/usr/bin/nice -n20 newsyslog</command>
</item>
<item>
<minute>1,31</minute>
<hour>0-5</hour>
<mday>*</mday>
<month>*</month>
<wday>*</wday>
<who>root</who>
<command>/usr/bin/nice -n20 adjkerntz -a</command>
</item>
Добавьте bridgecheck.sh в записи cron. Добавление следующего элемента позволит запускать скрипт каждую минуту.
<item> <minute>*/1</minute> <hour>*</hour>
<mday>*</mday>
<month>*</month>
<wday>*</wday>
<who>root</who>
<command>/usr/bin/bridgecheck.sh</command>
</item>
Сделайте изменения для основного и резервного брандмауэра.
9.5.2.3.3. Отключение моста при начальной загрузке Вам потребуется добавить в конфигурацию команду которая позволит отключать мост при первоначальной загрузке. Это предотвратит появление петли уровня 2, а мост будет поднят на мастере CARP с помощью скрипта bridgecheck.sh через минуту после загрузки. Над строкой </system>, необходимо добавить следующую строку:
<shellcmd>/sbin/ifconfig bridge0 down</shellcmd>
Сохраните изменения конфигурационных файлов. Теперь восстановите изменённую конфигурацию на первичном и резервном брандмауэре. Брандмауэры должены перезагрузиться после восстановления конфигурации и нормально работать.
9.5.2.4. devd хук Это решение возможно только в pfSense 1.2.3. или более поздней версии и включает в себя использование devd для отлова актуального состояния перехода CARP, когда это происходит. Отредактируйте /etc/devd.conf на резервном и основном брандмауэрах и добавьте следующие строки:
notify 100 {
match "system" "IFNET";
match "type" "LINK_UP";
match "subsystem" "carp"; action "/usr/local/bin/carpup";
};
notify 100 {
match "system" "IFNET"; match "type" "LINK_DOWN";
match "subsystem" "carp"; action "/usr/local/bin/carpdown";
}; Теперь создайте новые файлы: /usr/local/bin/carpup
#!/bin/sh /sbin/ifconfig bridge0
и: /usr/local/bin/carpdown
#!/bin/sh /sbin/ifconfig bridge0 down Теперь сделаем эти скрипты исполняемыми:
# chmod a+x /usr/local/bin/carpup # chmod a+x /usr/local/bin/carpdown
Это позволит автоматически поднять и положить мост в любое время при обнаружении изменений состояния CARP. 9.5.2.5. Устранение неполадок отказоустойчивого моста Если что-то не работает, как было задумано, проверьте страницу Status -> Interfaces на обеих системах для обзора интерфейса bridge0, и страницу статуса CARP для контроля статуса master и backup CARP. Вы можете выполнить bridgecheck.sh из командной строки, и проверить состояние интерфейсов используя ifconfig. Понимание основ ОС FreeBSD может быть необходимо для успешного выявления и устранения проблем данного типа.
Многие проблемы CARP и мостов могут быть связаны с петлями коммутатора и вопросами STP. Обратитесь к разделу 9.5.2, "CARP", а так же проверьте конфигурацию вашего коммутатора для просмотра статуса интерфейсов моста. Если ваши порты блокированы в то время когда они должны осуществлять пересылку, вам, скорее всего, необходимо настроить параметры STP или использовать один из альтернативных методов закрытия резервного моста.
9.5.3. Multi-WAN Мосты, по своей природе, несовместимы с multi-WAN в большинстве использований. Когда используется мост, обычно нечто иное чем pfSense будет являться шлюзом по умолчанию для хостов на интерфейсе моста, и только этот маршрутизатор может направлять трафик от этих хостов. Это не освобождает вас от использования нескольких WAN интерфейсов с прочими интерфейсами на том же брандмауэре, который не является мостом, а только влияет на хосты интерфейса моста, где они используются иначе чем шлюз по умолчанию pfSense. Если мост объединяет несколько внутренних интерфейсов и pfSense - шлюз по умолчанию для ваших хостов на интерфейсе моста, вы можете использовать multi-WAN так же, как с не мостового интерфейса.
{jcomments on} |
| Последнее обновление 02.04.12 15:24 |
