[0] 何を言っているか分からないと思うが備忘。Applogicでいわゆる「INOUT」を作る方法。もっと恐ろしい物の片鱗を(ry-[Id of Radiance ver.5]





■ 何を言っているか分からないと思うが備忘。Applogicでいわゆる「INOUT」を作る方法。もっと恐ろしい物の片鱗を(ry

 今んとこ需要はとても少ないと思われる話。なので分からない人には分からないと思いますが備忘なのでフォロー無しです。また、正しい手法であるかどーかはさっぱり保証しません。

 一般的なアプライアンスを構築する場合、入力のgwとして「IN」を作り、その下に何がしかのアプライアンスを配置するわけだが、この「IN」はそのままだとあくまで「外部からの入力とその戻り」しか通信を行わず、アプライアンス内部から外部へのアクセスは許可しない。そのためやはり一般的には「OUT」を出力のgwとして用意し、外部への出口とするわけだが、この「IN」と「OUT」にはそれぞれ異なるIPを設定せざるを得ないため、グローバルに配置しようとした場合に限りあるグローバルIPを2つ消費する事になる。
 例えばWebアプリのようなアプライアンスで「IN限定」と割りきって利用できるならば問題にはならないかもしれないが、例えばメールサーバなど「サーバ→外部」の通信を行うサーバなどはそうも行かない。そうじゃなくても各サーバのアップデートやウィルスパターン更新には外部へのアクセスが必要になるだろう(※まあこれらはWSUSなどで別の手法を構築することもできるだろうが)。
 そんなわけで、「IN」の特徴と「OUT」の特徴を合わせた、よくあるFWのような「特定のIN」と「サーバから発信した通信の戻り」だけを受け付けるステートフルインスペクション的な挙動をする「INOUT」を作りたくなるのが、リソースに限りのある貧乏性のサ・ガと言えよう。海外のApplogicフォーラムとかも参考にしながらよーやく実現できた。

 大雑把に結論だけ言うと「iptablesを制御する」に尽きる。

 1.GUIで「IN」と適当なアプライアンスを置く。
 この辺は人によって様々だろうから適当に読み替えてください。また、この方法は単純に「IN」とアプライアンスが1:1で存在することを前提としてます。
 また、アプライアンスが元々「IN」として必要なIP設定などは済ませてください。

 2.「IN」をブランチ化して「INOUT」と名称変更。
 まあ名称はお好みで。最終的にはコレをテンプレ化して再利用したいところ。

 3.「INOUT」の[modify Boundary]からIntercface「in」を追加する。
 ただし上手くやればコレはいらないかも。元からあるインターフェース「out」を入力としても使えるようiptablesを書けば済む話かもしれない。が、見た目わかりやすいのでこうします。
 またコレと並行してアプライアンス側の「net」を前後反転させとくとわかりやすいですが、そこは好みの問題かもしれないです。

 4.上記「in」とアプライアンスの「net」を接続。
 これでデフォゲが「INOUT」に向いてるはず。

 5.アプリ起動。INOUTにCLIログイン。
 ここから先は起動したINOUT上で制御します。

 6./appliance/iptables-fwrules.shを編集。
 起動したINOUTの「/appliance」には初期起動時のネットワーク制御に実行されるシェルが幾つか置かれています。その中でiptablesの設定を行っているのが「iptables-fwrules.sh」のようです。また「~fwrules~」に何らかのエラーが発生した場合に前の状態を復元するバックアップシェルとして「iptables-bkrules.sh」とゆーのもあるようです。
 iptables-fwrules.shの中身はシンプルにiptablesコマンドを実行するシェル。通常だとGUIのPropertyで設定したIPや許可設定を実現する設定が書かれてます(なので以降は標準的なIN設定が終わってることを前提とします)。
 ので、コレを書き換えます。ここからは更に細部化します。

 6-1.IP情報の取得
 まずシェルのアタマの方で自身のIPやらI/Fやらの名称を取得してるところがあります。これらを参考に(※ほぼコピペでイケる。一部別ファイルを参照する必要あり)、上記3で追加したインターフェース「in」のIPアドレス、I/F、MACアドレスなどを取得します。
 なおこの後「in」のIPのアドレスを「$IN2IP」、I/Fを「$IN2IF」、MACを「$I2HWADDR」とします。

 6-2.アプライアンスからの接続許可(※非必須)
 iptables -A INPUT -m state --state NEW -m tcp -p tcp -i $IN2IF -j ACCEPT
 とか書いて、$IN2IFからの新規接続許可を記述します。まあこれはアプライアンスからINOUTに何がしかの接続をするための設定なので、転送に限定したい場合は不要です。ただこの設定を行うことで、従来一般的なSSHクライアントからのアクセスができない「IN」(アプライアンスに転送されるため)に対し、「まずアプライアンスにSSHログイン→そこからSSHでINOUTに」とゆーマネができるようになります。
 なおプロトコルとかはお好きなモノを適当に。

 6-3.インターフェース「in」からの接続許可
 標準的な設定ならば普通の中→外を許可する
 iptables -A FORWARD -p tcp -i $INTIF  -s $INTIP -o $EXTIF -j ACCEPT
 があると思いますので、その下にinから来たものを外へ出すのを許可する
 iptables -A FORWARD -p all -i $IN2IF -o $EXTIF -j ACCEPT
 を追加します。

 6-4.静的NAT設定
 外部へ出る際のNAT設定を記述します。このあたりはむしろ「OUT」を作って参考にすると良いかも。
 iptables -t nat -A POSTROUTING -p all -o $EXTIF -j SNAT --to $EXTIP

 6-5.「hosts_allow」への小細工
 シェルの下の方にhosts_allow、hosts_denyの設定を行う箇所がありますが、hosts_allow設定の最後の「DROP」を行う記述の前に、$IN2IFからの許可設定…とゆーかスルーする「RETURN」設定を入れます。
 iptables -A hosts_allow -i $IN2IF   -j RETURN

 7.設定を保存したらアプリケーションを再起動する。
 このシェル実行すりゃ良いような気もするんですが、なぜかそれだと上手く行きません。アプリケーションごと再起動します。


 ここまででたぶんイケてるはず。入力側はGUIのプロパティで設定した内容を保持しつつ、アプライアンスのグローバル向けデフォgwとしてINOUTが使えてるはず。
 なおiptablesの強制書き換えはセキュリティ上の不備を生む可能性もあるので十分注意してください。上記のやり方で問題ないとは言いません(苦笑)。まーこーゆー情報を求めてる人ならばiptablesの制御は問題ないと思いますけどね。

 本音を言えばこれらiptablesの制御もApplogic上のGUI、CLIで行いたいところなのだがどうもマニュアルを見てもそーいった方法が見当たらない。
 サーバ側のApplogicの設定として今回の「/appliance」の他に「/etc/applogic」などがあり、GUIで行った設定を書き込んでる様子があるので、その辺を制御できれば今回のようなマネはしなくて済むと思うのだが。まだApplogic使い始めて日が浅いんでよくわからん。サポートはアテにならないし。他に良い方法をご存知の方はこちらに書きこんでいただけると助かります(苦笑)。

関連タグ:クラウド
2011-07-25 [技術]

関連記事: