ラベル conntrackd の投稿を表示しています。 すべての投稿を表示
ラベル conntrackd の投稿を表示しています。 すべての投稿を表示

2007年7月10日火曜日

conntrackd の internal と external キャッシュ

ソースをつらつらと眺めていたところ、少し理解できた。
internal
カーネルから (netlink 経由で) 受け取った内容を展開。なので master 側の話

external
マスタから (マルチキャストで) 受け取った内容を展開。なので slave 側の話。VRRP でマスタが落ちたと判断した場合、この内容を (netlink 経由で) カーネルに通知。通知を受けたカーネルは netlink で通知。で巡り巡って旧 slave 現 master となった internal に展開される。
じゃ internal って意味ないじゃん。と思ったのだが、これは master と slave のやりとり --- プロトコル --- の問題らしい。

sync モードと nack モードなるものがあり、現在 nack モードを推奨。internal を参照しているのは sync モードのみらしく、しかも ENOBUFS の時のみ。nack モードの場合どんなやりとりか調べること。でも、まだ実際に稼働させたことなし.... virtualize 何にしようか。

2007年6月26日火曜日

conntrackd に至る前置き

古い記事ですが、Slashdot 本家に Firewall Failover With pfsync And CARPという記事があった。良いなぁ。と linux 周りを眺めていたら ct_sync? という conntrackd 実装している方が、以前全てカーネルスペースで実装しようとしていた形跡を発見。ML にも入らず日々ダラダラ過ごしていたところ、conntrackd なるものを発見。ct_sync より勢いがありそうな感じで今後に期待....というのが今更ながらの前置き。そうそう CARP と conntrackd 使ってみたらしき ML への投稿があった気がする。

元気が無いのでまたまた貢献できないと思ふぅ。商用ファイアウォール製品と比較して、辛いな。と思う部分ですので、頑張って下さい。

conntrackd のオプション

目に余る逸脱ぶりなので、ちょっと戻る。-c の ``external cache'' という言葉に戸惑う。相変わらず内部、外部キャッシュの意味を理解していない.... conntrack-tools/src/main.c から

static const char usage_client_commands[] =
"Client mode commands:\n"
" -c, commit external cache to conntrack table\n"
(プライマリ) 外部のキャッシュをコミット

" -f, flush internal and external cache\n"
(プライマリ、バックアップ) キャッシュのクリア

" -F, flush kernel conntrack table\n"
(バックアップ) カーネルの conntrack テーブルのクリア

" -i, display content of the internal cache\n"
内部キャッシュの表示

" -e, display the content of the external cache\n"
外部キャッシュの表示

" -k, kill conntrack daemon\n"
停止

" -s, dump statistics\n"
統計情報表示

" -R, resync with kernel conntrack table\n"
(プライマリ) カーネルの conntrack テーブルとの再同期

" -n, request resync with other node (only NACK mode)\n"
(ん? script_.*.sh にない) NACK モードにて他ノードとの再同期

" -x, dump cache in XML format (requires -i or -e)";
どーゆ経過か知らないけどキャッシュ内容の XML 出力

2007年5月9日水曜日

conntrackd のコンパイル

以前 libnetfilter_conntrack のコンパイルができたり、できなかったりは pkg-config というパッケージがホストによって入っていたり、入っていなかったりが原因。ごめんなさい。なのでコンパイラ周りと automake libtool pkg-config 等々が必要。途中省略しまくりのログ。

$ svn co https://svn.netfilter.org/netfilter/trunk/libnfnetlink/. libnfnetlink
....
$ svn co https://svn.netfilter.org/netfilter/trunk/libnetfilter_conntrack/. libnetfilter_conntrack
....
$ svn co https://svn.netfilter.org/netfilter/trunk/conntrack-tools conntrack-tools
....
$ cd libnfnetlink
$ ./autogen.sh
....
$ ./configure --prefix=/usr/local
....
$ sudo make install
....
$ cd ../libnetfilter_conntrack/
$ ./autogen.sh
....
$ PKG_CONFIG_DIR=/usr/local/lib/pkgconfig ./configure --prefix=/usr/local
....
$ make
....
$ sudo make install
....
$ cd ../conntrack-tools
$ ./autogen.sh
....
$ PKG_CONFIG_DIR=/usr/local/lib/pkgconfig ./configure --prefix=/usr/local
....
$ sudo make install
....
$
$ cd /usr/local/lib
$ find /usr/local -ctime -20
....


svn も必要か。最近まで sudo 使わずに root になってたけど何となく使うようにしよう。sudores は
chamaken  ALL=(root) NOPASSWD: /usr/bin/make install
みたく

2007年5月8日火曜日

conntrackd のインストールについて

途中からすっげっ嫌になったので、すっげっ意訳となってしまつたぁ...

How to install the conntrack-tools

このドキュメントにて conntrack-tools のセットアップ方法を詳しく述べます。

0. Introduction

conntrack-tools パッケージには二つのプログラムを含みます:
  • conntrack: connection tracking システムとやり取りをするコマンドラインインターフェース。
  • conntrackd: ハイアベイラビリティな GNU/Linux のファイアウォールを配備するために使用し、ファイアウォールの使用統計を収集することができる connection tracking ユーザスペースデーモン。

1. Requirements

conntrack-tools を動作させるために以下のソフトウェアをインストールしなければなりません。先に進む前にこれらが正しくインストールされているか確認して下さい。
  • linux kernel バージョン >= 2.6.18 (http://www.kernel.org)とサポートできるようにするのは:
    • connection tracking system (quite obvious ;)
    • nfnetlink
    • ctnetlink (ip_conntrack_netlink)
    • connection tracking event notification API
  • libnfnetlink: オフィシャルリリース netfilter.org から取得可能な netfilter netlink ライブラリ。
  • libnetfilter_conntrack:
    オフィシャルリリース netfilter.org から入手できるnetfilter conntrack ライブラリ。
2. Basic Installacion

conntrack-tools をコンパイル、インストールためには、ただ一般的な以下のステップに従うだけです。
./configure
$ make
# make install
この時点でコマンドラインインターフェース `conntrack' を使うことが できます。しかし `conntrackd' と呼ばれるユーザスペースデーモンを動 作させるためにはいくつかの魔法の言葉が必要です。

3. Setting up conntrackd

現在 conntrackd は二つの動作モードを持ちます: 統計モードと同期モード双方の詳細について以下述べます。

3.1. Synchronization mode

conntrackd は Linux 上のステートフルファイアウォールの接続の状態を複製することができます。この章ではデーモンを同期モードで設定する方法を述べます。

3.1.1. Requirements

Keepalived バージョン 1.x (http://www.keepalived.org): 使用しているディストリビューションが最近のバージョンのものかチェックして下さい。

3.1.2. Configuration

  1. keepalived のインストールと設定:
    keepalived 1.x の最新のバージョンをダウンロード、インストールします。使用しているディストリビューションに含まれているかチェックして下さい。シンプルなプライマリ/バックアップのシナリオを設定するのであれば conntrackd の tarball 内のサンプルファイルを使用することができます。
    • node 1 に対しては: conntrackd-x.x.x/examples/sync/node1/keepalived.conf
    • node 2 に対しては: conntrackd-x.x.x/examples/sync/node2/keepalived.conf

  2. これらのファイルは仮想 IP 192.168.0.100 を eth0 で、また 192.168.1.100 を eth1 で持つ二つの端末から構成されるシンプルな VRRPクラスタを設定するのに用いることができます。keepalived に詳しくないのであれば http://www.keepalived.org の公式ドキュメントを読んで下さい。step2 に進む前に keepalived が正しく稼働しているか確認して下さい。

  3. Setting up conntrackd:
    'conntrackd' を同期モードで設定するためには設定ファイルを /etc/conntrackd に置かなければなりません。
    node1 上では
    # cp examples/sync/_type_/node1/conntrackd.conf /etc/conntrackd.conf

    node2 では
    # cp examples/sync/_type_/node1/conntrackd.conf /etc/conntrackd.conf

    _type_ は現在二つある同期タイプ、パーシステントモードか NACK モード、を選びます。パーシステントモードは NACK モードよりリソースを消費しますが、NACK モードは、まだ実験的です。

    配備した設定に合うよう、これらファイルを編集するのを忘れないで下さい。

    設定ファイルを /etc/conntrackd 配下に置きたくないのであればconntrackd にオプション -C でどこを探すか教えてやって下さい。

  4. Running conntrackd

    conntrackd はコンソールモードで稼働することができます。この場合、ただ 'conntrackd' とタイプして下さい。あるいはデーモンモードで稼働させていのであれば 'conntrackd -d' とタイプして下さい。

  5. Checking that conntrackd is working fine
    conntrackd には、ステータスをチェックするための、いくつかの方法があります:
    • (別名内部キャッシュと呼ばれる) 現在このノードによって処理されている接続のキャッシュをダンプ:
      # conntrackd -i

    • (別名外部キャッシュと呼ばれる) ネットワーク内の別ノードから送信された接続についてのキャッシュをダンプ:
      # conntrackd -e

    • 複製デーモンによって収集された統計情報のダンプ:
      # conntrackd -s

  6. Setting up interaction with keepalived

    keepalived はアクティブノードが落ちたと検知すると、落ちたアクティブを置き換えるノード候補を指定します。このイベントにて外部キャッシュ、例えば? 別のノードによって処理された接続を含むキャッシュが (カーネルに?) 引渡されなければなりません。外部キャッシュを引渡すためには

    # conntrackd-c
    とタイプします。

    keepalived は別プログラムとやり取りするためのインターフェースとしてシェルスクリプトを提供しているので以下に紹介する行を keepalived の設定ファイルに記述することにより、外部キャッシュを引渡す処理を自動化できます。

    'script_master.sh' 内には以下の記述があります:
    #!/bin/sh
    /usr/sbin/conntrackd -c # commit external cache
    /usr/sbin/conntrackd -R # resync with kernel conntrack table
    よって、(アクティブノードが) 落ちたイベントにて次候補となるノードが仮想 IP と落ちるノードが処理していた接続を引き継ぎます。NACK モードでは、このファイルは異なることを見て下さい。

  7. Disable TCP window tracking
    適切なパッチがカーネルのメインラインに入るまで TCP window tracking を不能としなければなりません。以下をとりあえずの解決策とすることを検討して下さい:
    # echo 1 >  /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal

3.2. Statistic mode

conntrackd は統計デーモンとして稼働することも可能です。興味が無いようであれば飛ばして下さい。同期モードを稼働させる必要はありません。この章ではデーモンを統計モードで設定するための方法を述べます。
  1. Configuration

    conntrackd を統計モードで設定するのは、幾分簡単です。設定ファイルをコピーするだけです。

    # cp examples/stats/conntrackd.conf /etc/conntrackd.conf

  2. Running conntrackd in statistics mode

    To run conntrackd in statistics mode:

    # conntrackd -S

    Alternatively, you can run conntrackd in daemon mode:

    # conntrackd -S -d

    In order to dump the statistics, just type:

    # conntrackd -s

    To dump the current connection forwarded, just type:

    # conntrackd -i

2007年4月16日月曜日

conntrackd のテストケース

2.6.18 から netfilter の state について netlink 経由でやり取りできるようになったらしい。このやり取りを multicast 使ってクラスタ組むデーモン conntrackdテストケースの意訳。ベタな上にちょっと長いけど。


Test Case

このドキュメントではシンプルなプライマリ/バックアップ設定に基づく、とてもシンプルな高可用性の設定について述べます。

Description

テストケースではファイアウォールとして動作する二つのホスト FW1 と FW2、またデスクトップとして動作する A と B から構成されます。ネットワーク概要については下図に詳述されています。

初めに、FW1 は図中赤色で強調された仮想 IP を保持していると見なします。このように配備された設定は FW1 がアクティブ FW2 がアクティブホストが落ちるのを待つという古典的なプライマリ/バックアップとなります。仮想IP を受け継ぐ過程を自動化するソフトウェアはkeepalived です。

Ruleset

FW1 と FW2 で実装されているフィルタリングポリシは以下の通りです。

[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 -I FORWARD -j LOG
[6] iptables -I POSTROUTING -t nat -s 192.168.0.3 -j SNAT --to 192.168.1.100
見た通り、転送するデフォルトのポリシは 破棄 [1]。ファイアウォールクラスタはホスト A から開始されるホスト B への新規 TCP 接続を 許可 [3,4] して逆方向は確立されたもののみ [2]。加えて、このクラスタはホスト A から B に向かう接続の 送信元 NATを行う。この転送ポリシに合致しないパケットは全てログに残される [5]。

Generating traffic

テストのため、ホスト A から B への SSH セッションを開始します。

Failure and Takeover

FW1 を落としてみると、すぐに FW2 が仮想 IP を受け継ぎます。

Problems

理屈では SSH 接続は FW2 にて転送されるべきですが、新たにアクティブとなったホストは、そのような接続については何も知らないため、これを新規接続と見なします。あいにく、この接続は実際は 確立されており、パケットを通過させるルール [2] に該当しません。このパケットの破棄はログに残されます。

Solution: Conntrackd

この問題を克服するためには FW1 と FW3 に conntrackd を配備しなければなりません。このデーモンはアクティブノードによって転送された接続の状態を複製するのでバックアップは適宜この接続を引き継ぐことができます。アクティブノードによって転送された接続の状態をダンプさせることができます。

(shell FW1)# conntrackd -i
tcp 6 ESTABLISHED src=192.168.0.3 dst=192.168.0.100 sport=51356
dport=22 src=192.168.0.100 dst=192.168.1.3 sport=22 dport=51356
[ASSURED] mark=0 [active since 5s]
バックアップノードでは複製された接続を観測することができます。
(shell FW2)# conntrackd -e
tcp 6 ESTABLISHED
src=192.168.0.3 dst=192.168.0.100 sport=51356 dport=22
src=192.168.0.100 dst=192.168.1.3 sport=22 dport=51356 [ASSURED] mark=0
[active since 2s]

2007年3月27日火曜日

libnetfilter_conntrack

svn update をしたところ、ちょこっと変更されていたので再 make。以前手元の automake (aclocal?) で作成された configure が不完全で無理矢理手直ししていたが解消。その代わりと言ってはナンだが pkg-config の設定? をきちんとせねばらななくなった。何のことは無い PKG_CONFIG_PATH=/usr/local/lib/pkgconfig して configure 走らせれば良いだけのコト。忘れないよーに。

2007年2月28日水曜日

conntrackd の internal と external cache

include/conntrackd.h から

struct ct_sync_state {
struct cache *internal; /* internal events cache (netlink) */
struct cache *external; /* external events cache (mcast) */

internal の netlink って kernel conntrack table と同義?