ISC DHCP から置き換わるであろう Kea の話し中編

Kea DHCPにまつわる話を前、中、後編という感じで書きます。

本記事は中編です。以下の記事は2017/12/10にwebにある情報を元に記述しています。

またこの記事は富士通クラウドテクノロジーズ Advent Calendar 2017 の11日目です。

昨日は @alice02 さんの「サーバ脆弱性スキャンの定期実行・結果通知を自動化してみた」でした。

この世に存在しているサーバは常に悪意のある攻撃者からの攻撃対象になっています。

と言う一文が、脆弱性対策の重要性をよく表していると思いますので、まだチェックしていない方は是非チェックしてみてください。

前置き

新卒入社2年目の @yaaamaaaguuu です。PHP, Python, Golang を NGINX Unit で動かしてみた - /var/log/study とかを書いた人です。

2017年12月11日現在、富士通クラウドテクノロジーズ(FJCT) で、二フクラのためのソフトウェアエンジニアをやっています。去年のAdventCalenderでは「レガシーなPHPを改善する為に(新入社員が勝手に)取り組んだ3つの事」という記事を書くくらいはWeb寄りのエンジニアでしたが、部署配属によりインフラに近いエンジニアとなりました。大まかな担務としては物理を含まないネットワークを中心に取り扱っています。

そんな自分が去年 ~ 今年にかけて任された仕事のうちの1つに Keaの検証 というのがあり、日本語で公開されている知見は少ないため書き残しておこうと思います。

と言う意図の記事を書いていたらめちゃくちゃ長くなったので ~~前後編~~ 3分割しました。DHCP としてKeaが革新的なのはAPIがあることなので、AdventCalender的にはこの記事で登録しています。

前篇のあらすじ

ISC DHCPの開発もサポートも終わろうとしている
今後ISCは Kea というDHCPを開発していく
Keaは色々便利機能とかがあるけど、特にWebAPIサーバーが生えていて便利！！！

今回書く話し

Kea DHCPを動かしてみる
Kea DHCPについているAPIの動かし方と注意点
ログのフォーマット
Keaの検証してみて良いと思った話しとまとめ

対象

DHCPとDockerを動かしていきますので、DHCP プロトコルを知っているかたかつ Dockerの動かし方を知っている方向けに書いています。

最新版の動作を試すには？

前篇でKeaの特徴などを述べてきましたが、ではKeaを動作させるにはどうしたら良いか？を書いておきます。

2017/12/10、現在インストールのページを眺めても、最新版であるv1.3.0のパッケージは提供されていません。v1.2.0を提供しているのもBSD系とArchLinuxだけですね。せめてv1.2.0以上でないとAPIサーバーの機能が使えず嬉しさ半減です。

なので、最新版をDockerのイメージとして用意いたしました。 (ただし、野良ビルドですので、プロダクション等で利用されても特に責任は取れせんので注意してください。)

https://hub.docker.com/r/shouhei/kea-dhcp/

dockerをインストール済みの方は、以下のコマンドでイメージをダウンロード可能です。

docker pull shouhei/kea-dhcp:v1_3_0

自分ではLinux上で動くことしか検証していません。DHCPがリクエストを受けられるようにhost networking機能を使っているためMacでは動作しないのがわかっています。(もしAPIだけ動けば良いんだ！という気持ちならば、host networkingの設定を外したり、コメントアウトしたりしたら良いと思います。 )

設定ファイルのサンプルは以下においてあるので、それを利用します。ホストについている全てのネットワークインターフェスから、192.168.10.0/24 でIPを配布する設定となっています。検証の環境に合わせて適宜変更してください。変更する際は管理者リファレンスの8.2を参照すると良いです。

kea-docker/config.json.example at master · shouhei/kea-docker · GitHub

肝心の動作方法は以下のような感じで。

docker run --net=host -v ${PWD}/config.json.example:/etc/kea-config.json -it kea-dhcp:latest kea-dhcp4 -c /etc/kea-config.json

すると、設定ファイルで指定したインターフェースがつながっているネットワークでIPの配布が可能になるはずです。

ここまでは極々普通のDHCPサーバーです。

Kea の API サーバーを動かす

まず、KeaのAPIサーバーをDockerで試すには、以下の理由から少し工夫が必要です。

Dockerの1プロセス1コンテナのモデルを守りたい
APIサーバーであるControl-Agentは、Dhcp4サーバー等に処理をディスパッチするためのwebの受け口である
- ディスパッチの経路がソケットファイル

図にすると以下のように動いて欲しいのです。

f:id:yaaamaaaguuu:20171211025058p:plain

なので、上記を満たすためのdocker-composeファイルと設定ファイルも作成しておきました。

gist.github.com

上記をローカルにコピーして docker-compose up を実施すると動くはずです。

サンプルの設定は簡易版です。後述する config-write というAPIでKeaの持つ設定を別名で書き出すことも、同名で書き出すこともできますが、同名で書き出すとControl-Agent用の設定か、DHCP4の設定が上書きされて消されるのできちんとやる場合は設定ファイルを分割して読み込ませてください。

APIの叩き方は以下のコマンドの様に、curlを使って、Headerに Content-Type: application/json をつけ、POSTメソッドでJSONを投げつけます。

curl -H "Content-Type: application/json" -d '{"command": "list-commands", "service": ["dhcp4"]}' localhost:8080

基本的には以下の3つのkeyとvlaueを指定することでAPIを動作させます。

command
- コマンド
- apiのlist-commandsで一覧が見れる
- 後述するサービスとの組み合わせで利用できるコマンドが異なるのに注意
service
- dhcp4なのか、dhcp6なのかとか
- 配列形式での指定
- 癖があるので後述する
arguments
- apiによって異なるのでリファレンス参照

APIリファレンス自体は http://kea.isc.org/docs/kea-guide.html#ctrl-channel にあります。

現状標準で使えるAPIとしては大きく分けて3つあります。

設定変更等を含むサーバー操作系
リース情報の操作系
サーバーが受け取ったパケットの統計情報の閲覧系

サーバー操作系のAPIではconfig全体を書き換える、読み取るくらいしかできないのですが、それでもプログラムから設定の自動生成、投入するには事足りると思います。

また(有料のAPI群にまぎれて)リース情報の操作系を取り扱うhookとAPIはv1.3.0からは同梱されるようになりました。hookを読み込むことで使えるようになります。リース情報のデータベースを初期化したりするapiが生えています。 http://kea.isc.org/docs/kea-guide.html#lease-cmds に詳しい情報が書いてあります。が検証しきれていないので特に言及はしないことにします。

Kea の APIの挙動

APIの種類やコマンドKeaのAPIは挙動に癖があると感じています。これらはおそらくバージョンが上がっていくごとに改善されていくと思うのですが、現状の挙動と癖を書いておこうと思います。

設定変更等を含むサーバー操作系のAPIの注意点

リファレンスには書いてあるのですが、自分が最初に触ったときに若干引っかかったことを記載しておきます。

config-write
- 現在DHCPがメモリ上に持っている設定をファイルに書き出す
config-set
- リクエストとして送ったデータをDHCPの設定としてメモリ上に持つようにする
- ファイルには書き出さない
  - 書き出したい場合は上記の config-write を呼び出す。
- config-setの後、特にサーバーの再起動等は不要
- argumentsとして渡すのは、全設定となる
  - 渡さなかった設定値は、サーバーで設定されているデフォルト値となるはず
- config-setの際はソケットファイルの設定だけは書き換えないように注意する必要がある
  - ソケットファイルを書き換えたが最後、DHCP的にはソケットファイルが見つからず、APIのリクエストが通らなくなる気がします

引数について

serviceにはリスト形式でdhcp4やdhcp6が指定できますが、何も指定しないと、control-agentを指定する事になります。

また、v1.3.0 では control-agentを文字列で指定できません。(ソースを読む限りそうなっていますし、文字列で指定するように修正するのは大変そうだなぁと思っています。)

つまり、dhcp4とcontrol-agentを同時に指定することは不可能です。なので、config-write で設定を上書きしたい際は設定ファイルを分割させる必要があります。

APIレスポンスについて

後述しますが、ログが充実している代わりに、APIレスポンスのメッセージが凄く貧弱です。

HTTPのレスポンス的には200と400しか返さなかったと記憶しています。もしかしたら201と404くらいは追加であったかも。

でもそれくらい貧弱で、たまーにエラーでもhttp的には200を返したりします。なので、APIのレスポンスは result というkeyを信じる事にしましょう。

result indicates the outcome of the command. A value of 0 means success while any non-zero value designates an error or at least a failure to complete the requested action. Currently 1 is used as a generic error, 2 means that a command is not supported and 3 means that the requested operation was completed, but the requested object was not found.

とドキュメントにも記載があるので。

ログの話

APIレスポンスの話の際に、ログが充実していると記載しました。ログのメッセージ自体はリファレンスにありますがKeaのログのフォーマットと、ISC DHCPのログのフォーマットを比較しておきます。

ISC

ISC DHCPはDHCP プロトコルのメッセージに沿ったログの出力をしています。ぱっと見たときはわかりやすいのですが、Keaと見比べると異常系のログはなぜ？という情報が少なく思えます。

#具体例
Dec 11 10:35:31 isc-dhcp-server dhcpd: DHCPACK on 192.168.0.55 to xx:xx:xx:xx:xx:xx via eth0
# 説明
日付 ホスト名 dhpcd: DHCPメッセージ on ipアドレス to macaddress via インターフェース

Kea

keaの内部の動作に沿ったログの出力をしています。以下のパターンの場合は、メッセージマニュアルページで DHCP4_BUFFER_RECEIVED を調べるとログの出力の理由がわかるようになっています。また内部のコンポーネントのどこからメッセージが出力されたか？は kea-dhcp4.packets を管理者リファレンス・マニュアルで調べるとわかるようになっています。

#具体例
2017-12-10 22:12:15.972 DEBUG [kea-dhcp4.packets/1] DHCP4_BUFFER_RECEIVED received buffer from 0.0.0.0:68 to 255.255.255.255:67 over interface ens224
#説明
日付 ログレベル [ログの出力元] メッセージ(大文字の箇所) 詳細(大文字以降)

Keaを検証して、良いサーバーだと思えた箇所とまとめ

まとめに入っていこうと思います。Keaを検証してよいと思えた点は、以下だと思いってます。

API
リファレンスとログメッセージの充実具合

ここまでで、APIサーバーとしてこまった箇所をいくつもあげてしまいましたが、web apiが生えて利便性は確実に高まったと思っています。設定変更のためにサーバーにログインして設定ファイルを書き換えて... と言った仕事を減らすことがより簡単に可能になると思います。また将来的には、そのAPIを活用してIPAM等との連携も視野に入れているようです。(そこらへんは後編で書くつもりです。)

運用の自動化、効率化とは別の側面を考えると (前篇で問題としてあげていた) ISC DHCPから Kea DHCPへの乗り換えというのがあると思っています。その際に効果を発揮してくるのが、ドキュメント類の充実具合です。どのようなサーバーよりKeaのドキュメントは充実していると思うので、開発する際はお手本にしたいと思えるくらい充実しています。

そのメッセージリファレンスが活躍するのはログ出力を眺めているときで、Keaではサーバーの内部挙動に合わせたログ出力になっています。設計段階からログ出力とメッセージリファレンスを突き合わせることで内部がどの様に動いたかを提示しやすくする様に考えているはずで、困ったときは大体メッセージリファレンスと再現するか？の検証で事が足ります。ISCとKEAで開発会社が同じだけ合って、困りどころがよくわかっているなぁと感心してしまいます。

ということで、将来的にはDHCPを置き換えるであろう、Keaの話しの中編を投稿させていただきました。

プログラムは3度作り直されるというのを過去に何処かで読んだ事があります。そこには 荒削りなプログラム -> 機能満載で使いづらいプログラム -> 洗練されたプログラム という流れをたどると書いてあったと記憶しています。 ISC DHCP -> BIND10 -> Kea という形を経て、確実に良いサーバーになっていると思うので、DHCPを構築運用している方はKeaを試してみるべきだと思います。

明日の話し

まず個人的な話をするとこの記事の後では、個人的には統計情報APIや有料hook, 開発のマイルストーンなど、前編、中編で拾えなかった話を後編として落穂拾いをしていきます。

アドベントカレンダー的な話しをすると、明日は @Ken-Moriizumi さんの「KONGでニフクラスクリプトもチームもマネジメントする話」という記事です。

たぶん https://github.com/Kong/kong のことだと思いますが、マイクロサービス向けのAPI ゲートウェイとのことで、API ゲートウェイの話しがどのようにしてチームマネージメントにまで繋がるか？が個人的には気になるところです。

KONGのアイコンがめっちゃかっこいい。どうでも良いですが、動物続き(keaはニュージーランドの高山に住むオウムの名前って書いてありました。)な事に気が付きました。

引き続き、富士通クラウドテクノロジーズ Advent Calendar 2017 をチェックしていただければと思います。

よろしくお願いいたします。

ISC DHCP から置き換わるであろう Kea の話し 中編

前置き