クラウド環境でのルータ設定(後編)

2013年1月に発表したSACMをベースとした機能課金モデル（※）で無償提供するサービスアダプタ「SA-W1」の開発について、「SEIL(ザイル)シリーズ」での経験を交えてご紹介します。
機器メーカーではないIIJの限られた開発リソースの中で、ISPだからこそのアイデア、設備・運用面での強みを最大限活用して独自の機器を低コストで開発するには、どうすべきなのか、尽きない試行錯誤の一端です。

• （※） SACMとレシピについては、プレスリリースを参照してください。

スクリプト支援機能第一弾:floatlinkの作成とIPsec VPNへの適用

まだ広く一般的に使っていただけるような状態ではないのですが、下地作りの第一弾として、SA-W1にはfloatlink機能を搭載しました。これは、あるSA-W1のIPアドレス情報をサーバに自動登録して、他のSA-W1のスクリプトを参照できるようにする仕組みです。ある場所に設置したSA-W1のfloatlink IDとパスワードが分かれば、他のSA-W1からいつでもアドレス情報を取得できます。これにより、静的アドレスでしか動作しないプロトコルや機能を、スクリプトの支援で動的アドレスに対応させることが容易になります。
既存のプロトコルを拡張して動的アドレスに対応させる場合、任意のアドレスからの要求を受け付けてから認証処理を行うなど、処理が複雑になりがちです。しかし、SMFとfloatlinkを利用してアドレス情報を同期していれば、そのような複雑な処理は全てSMFに任せられます。実際にSA-W1ではfloatlinkを利用することで、以下の2つを実現しました。

1. IPv4-over-IPv6/IPv4-over-IPv4トンネルの自動構築
2. IKEv1のMain modeを使用した安全な鍵交換によるトンネルへのIPsec適用

1.は一般的にはトンネルブローカーに分類される動作で、専用のプロトコルもいくつか提案されています。しかし、SA-W1においては、そうしたプロトコルを新規に実装することなく、クラウドに登録した情報とmrubyによる設定値生成で実現しました。

2.はAggressive modeを利用すると、IKEv1単体で動的アドレスに対応することが可能ですが、この構成については古くから認証処理に関してセキュリティ上の懸念が指摘されています。PKIを導入するなど、強固な認証方式を採用することもできますが、大規模な開発が発生します。これに対して、SA-W1では動的アドレス環境であっても大規模なPKI環境は必要ありません(floatlinkサーバへのアクセスにはSSLを利用しますので、サーバ証明書は利用します)。

floatlinkサーバ

floatlinkのIDとIPアドレスの対応を管理するサーバはインターネット上に設置してあり、SMFサーバ群の一部としてIIJが運用しています。IDとIPアドレスの対応という点ではDNSサーバに似た動作をします。実際、独自のDNSサーバを運用する、という案もありましたが、DNSの分散データベースとしての機能はオーバースペックで、余計なリスクを追い込むことになりかねないということで、最低限必要なWeb APIを用意するだけにとどめました。

floatlinkでは、複数のfloatlink ID(=SA-W1)をグループとして扱います。グループは実質的には「顧客」を意味しており、ある顧客は自分のグループに含まれるfloatlink IDに対応するIPアドレスを登録したり、検索したりすることが可能です。グループには顧客ごとの「鍵(パスフレーズ)」が設定されており、鍵を知らない限りグループに所属するfloatlink IDの情報にアクセスすることはできません。

あるSA-W1がfloatlinkサーバにアクセスする際には、「グループ鍵」と操作対象の「floatlink ID」を指定して、アドレスの登録・取得をリクエストします。floatlinkサーバは、ディレクトリ構造を持たない、ごく簡単な連想記憶ファイルシステムに「グループ鍵」と「floatlink ID」に対応する情報を保存しています。この「グループ鍵」と「floatlink ID」は、ハッシュ関数(SHA)にかけられて128ビットのハッシュ値に変換されます。そして、アドレス情報はこのハッシュ値に対応して保持されています。DNSのようなディレクトリ構造や権限委譲のないフラットなデータベースですが、この連想記憶の仕組みにより、高速な検索を実現しています。ハッシュ関数の計算はSA-W1側で実行することも可能ですので、通常、サーバ側では情報検索のための計算はほとんど発生しません。また、問い合わせにステートが含まれることもないので、負荷分散も容易な設計となっています。

今後の展望

現在のところ、SA-W1に対するスクリプトの組み込みは、IIJの製品開発部隊のみに制限されており、SACMのサーバ側についても、汎用スクリプトの組み込みは、やはり開発部隊に制限しています。ただし、サーバ上で設定値(テキスト情報)を生成する文字列マクロ処理については、SACMを利用したサービスの提供者に開放しており、サービスを利用契約しているSA-W1のIDなどは変数として参照できるようにしています。サービス側でIDをマクロ展開し、SA-W1上でIDからアドレス情報をfloatlink経由で参照するように設定マクロを作成すれば、それを再利用することで、契約に応じて全自動(SMFベースの技術なので電源投入以降はすべて自動処理されます)でフルメッシュのVPNを構築することが可能です。また、サービス仕様に応じてエンドユーザにいくつかのパラメータを入力してもらうことも可能です。最初のステップとしては、ある程度汎用性が高く、プログラミングの知識をそれほど必要としない仕組みになったのではないかと思います。

将来的にはスクリプトの開発をより広範囲にできれば、より柔軟性が高まるように思えます。ただ、単純なマクロ処理と異なり、実行時の難解なエラーや無限ループが容易に発生しうるスクリプトの開発を支援したり、事故の際に影響を最小限に抑える仕組みを構築したりするのは容易ではありません。そのため、別の方向として、現状のfloatlinkによる情報交換の仕組みを、より汎用化していくことも検討しています。また、floatlinkに含まれる、次の1～5までの基本的なパーツを洗練させると、シンプルかつ実用上十分な柔軟性を実現できる可能性もあります。

1. SA-W1での状態検知
2. SA-W1 からサーバへの通知
3. 通知を受け取ったサーバでの内部処理
4. サーバからSA-W1へのフィードバック
5. SA-W1からのサーバ上の情報参照

前述の通り、ネットワーク機器単体で処理するケースはすでに多々ありますが、サーバではリソースの制限があらゆる点で緩やかですし、SMFでは機器の識別、認証、コントロールといった点は、すでに解決しているので、かなり開発は効率的だと思っています。特に、自分の管理下にあるSA-W1の情報を当たり前に参照でき、方法によっては「IIJ GIO」などクラウドサービスのリソースとも連携できるという環境は、IIJならではのサービスに繋がるのではないかと考えています。

この仕組みは、「サービスを利用するための設定」という余計な作業を限りなく少なくできます。その中で今後、SEILシリーズやSA-W1は、エンドユーザからすると、特に存在を意識されない「ちょっと場所を取る邪魔な箱」になっていくでしょう。そう考えると一抹の寂しさはありますが、SEILも今年で15歳を迎え、人知れず縁の下の力持ちとしてがんばる「オトナの製品」になるべき時なのかもしれません。