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

ポリシング

ingress の qdisc 例を探していたところホストを SYN フラッドから守るなるものがあった。filter を理解していないので、すっごい adhoc だけど eth0 の ingress ポリシングは

tc qdisc add dev eth0 handle ffff: ingress
tc filter add dev eth0 parent ffff: protocol ip prio 20 u32 match u8 0 0 police rate 1Mbit buffer 20Kb drop flowid :1

みたいな感じで OK っぽい。ただ最後の flowid :1 って何かわからん。
結局何が言いたいかと言うと、先日の TBF って頑張らなくても filter - police - action drop で同じことができるのでは? とゆー話。

有益そうなリンク。以前 netdev でアナウンスされたことがあった記憶が...で IFB って使うとデバイスにヒモ付かなくても qdisc 使えるの?

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]

TBF

ポリシングとシェーピングあたりが違いがわかりやすかった。加えて Linux 特化な部分があるけど このあたりにある
Other info: very good paper about tbf (6 pages, 17 May 2001)
からの図もわかりやすい。意訳すると...

バケツがトラフィックフローの平均送信レートを表すトークンによって補充されるレートである rate。トークンバケツが貯めることができるトークン数である bucket size あるいは burst size。limit はバケツのサイズとキューのサイズの合計。これによって TBF がポリシングするかシェーピングするか決める。limit が bucket size と同じならばキューのサイズは 0 となり、(descipline に) 従わないパケットはドロップされる。つまりポリシング。limit が bucket size より大きいならば...

で、ポリシングの場合は

tc qdisc add dev eth1 root tbf rate 1Mbit burst 20Kb limit 20Kb

で iperf 使って測ると見事ソレらしい数値になった。
もう一回。limit と burst が同じならばポリシング、limit が burst より大きくなると、それなりにシェーピング。

libnetfilter_conntrack

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

virtual IP

結果としては keepalived.conf の virtual_ipaddress のサブネットを指定し忘れていたのがイカンかった。正しくは

virtual_ipaddress {172.27.100.254/24 } 

のサブネット /24 を指定しなかったために /32 が via 実アドレスで OSPF に流れてしまい、さてこの /32 をどうやって消そうか。とウンウン悩んでしまった。

なので設定ミス。ということだったけど VRRP (HSRP) の Virtual IP アドレスを OSPF で配布する場合の一般的な方法ってどうしてるんだろ? 今回は keepalived の向こう側のセグメントを static で virtual IP アドレス。としてしまったが。

本来は広告する側で制御すべきものだと思うのだけど directory connected なので route-map 使えないし OSPF で distribute-list 使わん方が良いと書かれているし Cisco の FAQ 見ると RFC でエリア内は必ず優先する。ってある。む〜ん...

うっとーしー ssh アクセスの客

自宅につなぎっぱのノート PC があり、どこからでも ssh のアクセス OK だけどパスワード認証はだめだよ。としていたけど

Mar 12 23:59:30 localhost sshd[6163]: Invalid user test from  ###.###.###.###
Mar 12 23:59:31 localhost sshd[6165]: Invalid user guest from  ###.###.###.###
Mar 12 23:59:32 localhost sshd[6167]: Invalid user admin from  ###.###.###.###

みたいなログが沢山で ADSLモデムのランプがちゃかちゃかと...

何か良いものは無いかと探したところ perl のスクリプトでログ見て iptables のルール作るようなものがあったけど...で、更に探してみたところ iptables の recent というモジュールがあった。先にこっち見付けるべきだろ。

-A INPUT -i ppp0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --rsource
-A INPUT -i ppp0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 5 --name DEFAULT --rsource -j DROP

ssh の最初の syn を送ってきたソースアドレスを DEFAULT という名前のリストに保存。このリストにエントリがあって 60秒間に 5回以上アクセスしてきたら DROP。う〜ん、ありがたい...