ファイアウォールの接続追跡状態が複製されていないように見えるアクティブ/アクティブファイアウォールクラスターに問題があります。
異なるISPを介して接続された2つのルーターと、BGPを介して提供されるネットワーク範囲があるため、アクティブ/アクティブです。データがどのようにルーティングされるかは、BGPによって決定されます。したがって、ルーティングは非対称です。これらの2つのファイアウォールは内部ネットワーク上でネットワーク化されており、Windowsサーバーのデフォルトルートとして機能する仮想IPがあります。
両方のファイアウォールが実行されていて、内部サーバーが接続を試みると、応答はセカンダリファイアウォール(接続状態の記録がないファイアウォール)を介して返されます。したがって、応答はドロップされ、要求を開始したサーバーにルーティングされません。
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は、10.0.0.101を持つマルチキャストセクションのIPv4_interfaceを除いて同じです。そして、フィルターセクションの内部IPは131で終わります
入力を225.0.0.50/ 32に、出力を225.0.0.50/32に受け入れるようにファイアウォールルールを設定しました。
ここではモードをALARMに設定しましたが、最初にFTFWを試しました。どちらも機能していないようです。
私のカーネルバージョンは3.11.0です。
申し訳ありませんが、仮想ボックスウィンドウからカットアンドペーストが機能していません。ただし、Sudo conntrackd -iを実行すると、sshを使用して作成したESTABLISHEDtcp接続が出力として表示されます。
ただし、他のルーターでは、同じコマンドで出力が生成されません。これは、状態が他のルーターに転送されなかったことを意味すると思います。
何か案は?
更新:各マシンでtcpdump -i eth2を実行すると、68バイトの長さのマルチキャストアドレス225.0.0.50ポート3780宛ての他のルーターからローカルに到着するUDPパケットを確認できます。
Ssh接続を開始すると、tcpdumpですぐにアクティビティが表示され、切断しても同じことが行われます。それ以外の場合は、そのメッセージの定期的なハートビートが届きます。したがって、ルーターがパケットを送信していることは明らかですが、それらを無視してconntrackedされていますか?オンにできる隠しデバッグはありますか?
Update2:わかりました。何日もグーグルしてソースコードを調べた後、conntrackdが状態を複製していることを発見しましたが、最終的には外部キャッシュに保存されます。ルールをコミットするには、conntrackd-cを実行する必要があります。明らかにconntrackdは、アクティブ/バックアップモードで使用するように設計されています。
CacheWriteThroughと呼ばれる新しいオプションがいつか導入されたようです。しかし、その後削除されました。 conntrackはアクティブ/アクティブを実行できますか?その答えが見つからないようです。
何日も欲求不満でドキュメントがほとんどなく、ソースコードを読んだ後でもわかりました。私はそれを理解しました。
Mode FTFW {
[...]
DisableExternalCache On
}
外部キャッシュを無効にすることは、非対称ルーティングシナリオに必要なことです。それ以外の場合、アクティブ/バックアップの場合、デフォルトをオフにして、keepalivedでnotify_master、notify_backup、notify_fault設定を設定します。
CacheWriteThroughの設定が削除され、DisableExternalCacheに置き換えられました。
これらのスクリプトは、IPを保持しているルーターに外部接続状態キャッシュをコミットするために使用されます。 DisableExternalCacheがオンの場合、状態はすでにコミットされているため、これらは必要ありません。
アクティブサーバーが再起動された場合、ファイアウォール/ルーターのペアでアクティブ/バックアップ構成(プリエンプトなし)が失敗することがわかりました。マスターがダウンすると、バックアップが引き継がれ、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