У меня возникла несколько странная проблема с conntrackd
. Я создал среду со сценарием активный / резервный, в которой сеансы будут реплицированы в резервную копию после аварийного переключения и наоборот. Я следовал официальному руководству инструмента и другим руководствам, которые в значительной степени используют ту же конфигурацию.
Я создаю несколько сеансов tcp
, используя wget
или ssh
, и я могу видеть создаваемые сеансы в conntrack -L
и conntrack -E -p tcp
root@master:/home/master# conntrack -L
udp 17 22 src=x.x.x.190 dst=x.x.x. sport=138 dport=138 [UNREPLIED] src=x.x.x. dst=x.x.x.190 sport=138 dport=138 mark=0 use=1
udp 17 4 src=x.x.x.9 dst=255.255.255.255 sport=11235 dport=11232 [UNREPLIED] src=255.255.255.255 dst=x.x.x.9 sport=11232 dport=11235 mark=0 use=1
udp 17 21 src=x.x.x.26 dst=255.255.255.255 sport=17500 dport=17500 [UNREPLIED] src=255.255.255.255 dst=x.x.x.26 sport=17500 dport=17500 mark=0 use=1
udp 17 14 src=x.x.x.212 dst=x.x.x. sport=137 dport=137 [UNREPLIED] src=x.x.x. dst=x.x.x.212 sport=137 dport=137 mark=0 use=1
udp 17 18 src=x.x.x.50 dst=x.x.x. sport=62401 dport=3052 [UNREPLIED] src=x.x.x. dst=x.x.x.50 sport=3052 dport=62401 mark=0 use=1
tcp 6 299 ESTABLISHED src=192.168.0.7 dst=x.x.x.58 sport=46026 dport=80 src=x.x.x.58 dst=192.168.0.7 sport=80 dport=46026 [ASSURED] mark=0 use=1
root@master:/home/master# conntrack -E -p tcp
[NEW] tcp 6 120 SYN_SENT src=192.168.0.7 dst=x.x.x.58 sport=46030 dport=80 [UNREPLIED] src=x.x.x.58 dst=192.168.0.7 sport=80 dport=46030
[UPDATE] tcp 6 60 SYN_RECV src=192.168.0.7 dst=x.x.x.58 sport=46030 dport=80 src=x.x.x.58 dst=192.168.0.7 sport=80 dport=46030
[UPDATE] tcp 6 432000 ESTABLISHED src=192.168.0.7 dst=x.x.x.58 sport=46030 dport=80 src=x.x.x.58 dst=192.168.0.7 sport=80 dport=46030 [ASSURED]
Но я не вижу их во внутреннем кэше главного компьютера или во внешнем кэше резервного копирования, я могу видеть только сеансы udp
. (Я не могу опубликовать внутренний и внешний кеш, они слишком велики. Представьте, что это как первый блок кода, но только сеансы udp
). Это означает, что сеансы tcp
уничтожаются при аварийном переключении и не реплицируются. Мой gwet
приостанавливается, и мое соединение ssh
зависает. Даже если мастер снова берет на себя управление, сеансы уже потеряны.
Конфигурация conntrackd такова:
Sync {
Mode FTFW {
DisableExternalCache Off
CommitTimeout 1800
PurgeTimeout 5
}
UDP{
IPv4_address 192.168.0.4
IPv4_Destination_Address 192.168.0.5
Port 3780
Interface eth1
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
UDP
ICMP # This requires a Linux kernel >= 2.6.31
}
Address Ignore {
IPv4_address 127.0.0.1 # loopback
IPv4_address x.x.x.58
IPv4_address x.x.x.56
IPv4_address x.x.x.59
IPv4_address x.x.x.7
IPv4_address 192.168.0.4
IPv4_address 192.168.0.5
IPv4_address 192.168.0.6
IPv4_address 192.168.0.7
IPv4_address 192.168.100.100
}
}
}
Если я использую DisableExternalCache On
как , этот вопрос предполагает, что мои внутренние и внешние кеши пусты (даже сеансы udp
потеряны). То же самое применимо, если я использую Address Accept
вместо Address Ignore
. DisableExternalCache On
также рекомендуется использовать в активном / активном сценарии вместо активного / резервного, который я ищу.
Правила брандмауэра настроены на принятие, и эти дополнительные правила добавлены (взяты из netfilter testcase )
[1] iptables -P FORWARD DROP
[2] iptables -A FORWARD -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
[3] iptables -A FORWARD -i eth1 -p tcp --syn -m state --state NEW -j ACCEPT
[4] iptables -A FORWARD -i eth1 -p tcp -m state --state ESTABLISHED -j ACCEPT
[5] iptables -A FORWARD -m state --state INVALID -j LOG
[6] iptables -I POSTROUTING -t nat -s 192.168.0.3 -j SNAT --to 192.168.1.100
Я пробовал другие конфигурации, другие режимы синхронизации, сценарии, которые фиксируют изменения и очищают кеши, когда это необходимо. Но я не могу понять, почему сеансы tcp
не отображаются в кеше. Какие-нибудь мысли? Я что-то упустил?
После долгого чтения, перенастройки и внешней помощи проблема была решена (наконец кошмар закончился).
Проблема заключалась в игнорировании адреса
] часть конфигурации, а не набор правил, о котором я думал сначала.
В обучающих материалах, за которыми я следил, говорится:
В блоке «Игнорирование адреса» должны быть перечислены ВСЕ IP-адреса брандмауэра
Но они не сказали, что игнорирование адреса
должны перечислять ВСЕ IP-адреса, которые брандмауэр имеет на локальных интерфейсах .
Размещение дополнительных адресов, например, тестового хоста, будет игнорировать весь трафик, генерируемый этим хостом. Вот почему в таблице ожидания я смог увидеть сеанс, но не в кеше. Это означает, что блок Address Ignore
должен указывать только свои собственные (и, возможно, резервные) IP-адреса (loopback, ext, int, VIP).
PS: Еще одна вещь, которую следует упомянуть, это то, что брандмауэр должен быть настроен на маскировку IP-адресов брандмауэра. В противном случае при аварийном переключении VIP меняет владельца, но сеанс по-прежнему будет искать IP-адрес созданной машины.
Чтобы преодолеть это, необходимо установить правило snat
.