У меня проблема с активным / активным кластером брандмауэра, где состояние отслеживания соединения в брандмауэре, похоже, не реплицируется.
Он активен / активен, потому что у меня есть два маршрутизатора, подключенных через разных интернет-провайдеров, и диапазон сети, который предоставляется через BGP. Способ обратной маршрутизации данных определяется BGP. Следовательно, маршрутизация асимметрична. Эти два брандмауэра объединены в сеть во внутренней сети, и у меня есть виртуальный IP-адрес, действующий как маршрут по умолчанию для серверов Windows.
Когда оба брандмауэра работают и внутренний сервер пытается подключиться, ответ возвращается через вторичный брандмауэр (тот, который не имеет записи о состоянии соединения). Следовательно, ответ отбрасывается и не направляется на сервер, инициировавший запрос.
Я думал, что conntrackd исправит это, но я не могу заставить его работать. Возможно, я неправильно понимаю, как это работает. Могу ли я вообще получить conntrackd для репликации состояния iptables? Он реально работает в активном / активном режиме? Реплицируется ли состояние в реальном времени?
Вот что содержится в моем файле conntrackd.conf.
Sync {
Mode ALARM {
RefreshTime 15
CacheTimeout 180
}
Multicast {
IPv4_Address 225.0.0.50
Group 3780
IPv4_Interface 10.0.0.100
Interface eth2
SndSocketBuffer 1249280
RcvSocketBuffer 1249280
Checksum on
}
}
General {
Nice -20
HashSize 32768
HashLimit 131072
LogFile on
Syslog on
LockFile /var/lock/conntrack.lock
UNIX {
Path /var/run/conntrackd.ctl
Backlog 20
}
NetlinkBufferSize 2097152
NetlinkBufferSizeMaxGrowth 8388608
Filter From Userspace {
Protocol Accept {
TCP
}
Address Ignore {
IPv4_address 127.0.0.1 # loopback
IPv4_address 10.0.0.100 # dedicated link0
IPv4_address 10.0.0.101 # dedicated link1
IPv4_address x.x.x.130 # Internal ip
}
}
}
Другой conntrackd такой же, за исключением IPv4_interface в разделе многоадресной рассылки, который имеет 10.0.0.101. И внутренний IP в секции фильтра заканчивается на 131
Я установил правила брандмауэра для приема ввода на 225.0.0.50/32 и вывода на 225.0.0.50/32.
Я установил здесь режим ALARM, но сначала попробовал FTFW. Ни то, ни другое не работает.
Моя версия ядра: 3.11.0.
К сожалению, мое вырезание и вставка не работает в окне виртуального окна. Однако позвольте мне просто сказать, что когда я запускаю: sudo conntrackd -i, он выводит на выходе УСТАНОВЛЕННОЕ tcp-соединение, которое я создал с входом ssh.
Однако на другом маршрутизаторе та же команда не выводит никаких данных. Я думаю, это должно означать, что состояние не было передано на другой маршрутизатор.
Любые идеи?
Обновление: я запустил tcpdump -i eth2 на каждой машине, и я вижу UDP-пакеты, поступающие локально с другого маршрутизатора, которые были предназначены для многоадресного адреса 225.0.0.50 порта 3780 длиной 68 байтов.
Если я инициирую ssh-соединение, я сразу вижу активность на tcpdump, и отключение делает то же самое. В противном случае будут передаваться регулярные биения этого сообщения. Итак, ясно, что маршрутизаторы отправляют пакеты, но игнорирует ли conntrackd их? Есть ли какая-нибудь скрытая отладка, которую я могу включить?
Update2: Хорошо, после нескольких дней поиска в Google и просмотра исходного кода я обнаружил, что conntrackd реплицирует состояние, но в итоге оказывается во внешнем кеше. Чтобы зафиксировать правила, вам нужно запустить conntrackd -c. Очевидно, conntrackd разработан для использования в активном / резервном режиме.
Кажется, в какой-то момент была представлена новая опция под названием CacheWriteThrough. Но потом был удален. Может conntrack делать активным / активным или нет? Кажется, я не могу найти на это ответа.
Хорошо, после нескольких дней разочарований и небольшой документации и даже чтения исходного кода. Я понял это.
Mode FTFW {
[...]
DisableExternalCache On
}
Отключение внешнего кеша - это то, что вам нужно для сценария асимметричной маршрутизации. В противном случае для активного / резервного копирования вы хотите использовать значение по умолчанию выключено и установить параметры notify_master, notify_backup, notify_fault в keepalived.
Параметр CacheWriteThrough был удален и заменен на DisableExternalCache.
Эти сценарии используются для фиксации внешнего кеша состояния подключения к маршрутизатору, содержащему IP. С DisableExternalCache On они не нужны, потому что состояние уже зафиксировано.
Я обнаружил, что активная / резервная конфигурация (без nopreempt) не удалась в паре межсетевой экран / маршрутизатор, если активный сервер был перезагружен. Когда мастер вышел из строя, резервное копирование взяло на себя обязательство, и сценарий primary-backup.sh зафиксировал внешний кеш в таблице ядра, как и ожидалось. Все связи остались активными. Однако, когда (исходный) мастер перезапустился и снова взял на себя управление, поскольку его внешний кеш был пуст, сценарий primary-backup.sh зафиксировал пустой внешний кеш в таблице ядра, и все соединения были разорваны iptables. Я исправил это, добавив несколько строк в начале скрипта:
case "$1" in
primary)
#
# request resynchronization with master firewall replica
#
# Note: this is an attempt to fix problem after reboot of original master,
# which had no entries in external cache and so resulted in empty
# conntrack table
#
$CONNTRACKD_BIN -C $CONNTRACKD_CONFIG -n
if [[ $? -eq 1 ]]
then
logger "ERROR: failed to invoke conntrackd -n"
fi
#
# commit the external cache into the kernel table
#
# etc