web-dev-qa-db-ja.com

conntrackdが状態を複製しないのはなぜですか?

ファイアウォールの接続追跡状態が複製されていないように見えるアクティブ/アクティブファイアウォールクラスターに問題があります。

異なる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はアクティブ/アクティブを実行できますか?その答えが見つからないようです。

5
Matt

何日も欲求不満でドキュメントがほとんどなく、ソースコードを読んだ後でもわかりました。私はそれを理解しました。

Mode FTFW {
     [...]
     DisableExternalCache On
}

外部キャッシュを無効にすることは、非対称ルーティングシナリオに必要なことです。それ以外の場合、アクティブ/バックアップの場合、デフォルトをオフにして、keepalivedでnotify_master、notify_backup、notify_fault設定を設定します。

CacheWriteThroughの設定が削除され、DisableExternalCacheに置き換えられました。

これらのスクリプトは、IPを保持しているルーターに外部接続状態キャッシュをコミットするために使用されます。 DisableExternalCacheがオンの場合、状態はすでにコミットされているため、これらは必要ありません。

5
Matt

アクティブサーバーが再起動された場合、ファイアウォール/ルーターのペアでアクティブ/バックアップ構成(プリエンプトなし)が失敗することがわかりました。マスターがダウンすると、バックアップが引き継がれ、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
0
Chris Tucker