Hatena::ブログ(Diary)

log4moto

2012-04-10

[][]ENIについて考えてみた 04:28

VPCでENIが実現されてからしばらく経ったので、いろいろ試した上で出た考えをまとめてみた。

最初に

ライセンスサーバなどを持つ目的でMACアドレスを固定したい、というニーズについては確かに存在するので、これについては、是非使いましょう!

NIC2枚刺しをする目的

オンプレ環境でNICを2枚刺す場合には、以下のような前提や動機があると思われる

  1. アドレス空間が違う(Public IPを使うセグメント、Private IPを使うセグメント)
  2. それぞれのセグメントの間にルータがないため、直接通信ができない
  3. ネットワーク通信のパフォーマンスや冗長性を向上させる(bondingや、WebとDBトラフィックを分けるなど)
  4. バックセグメントを作ることでセキュアになる

しかしVPCではENIを使ったとしても、

  1. そもそもすべてPrivateアドレス空間である
  2. Subnet間にはRouterがあるので、デフォルトでは何も考えなくても各Subnet間はRoutingされる(Firewall機能もある!)
  3. 物理的な帯域が上がるわけでも、冗長性が向上するわけではない
  4. 元よりインターネットから直接アクセスできない(インターネットゲートウェイ+ElasticIPアドレスでNATする事はもちろん可能だが)

などの理由により、あまりメリットとはなりません。

そもそもVPCでSubunetを分ける目的は、

  1. Routingを変えたい(Internet GatewayVPN Gatewayを使用する/しないにより、便宜上のPublic/Private Subnetを定義する)
  2. Network ACLを使ってSubnet間の通信を制御したい
  3. アドレス空間を別にしたい(IPアドレスベースでのアクセスコントロールをもししたいのであれば)

などが考えられますが、VPC(EC2)ではインスタンス単位でアクセスコントロールを行えるSecurity Groupが存在するので、2と3についてはそれほどの動機とはならないと思います。

ENIの落とし穴

ENIのというよりもNICを2枚刺したホストの宿命ともいえますが、Routingの問題が付きまといます。

OSが認識するdefault gatewayは基本的に1つであり(Linuxの場合は0.0.0.0を向けられるのは1つ、Windowsの場合も一見複数存在できるがMetricなどに応じて実際には1つしか機能しない)、2つNICを刺すとさまざまな問題が起こりえます。

meta data server問題

その最たるものは、EC2のmeta data serverへのアクセスができず、OSが起動しないという物です。

f:id:j3tm0t0:20120411033825p:image

detault gatewayがeth0を向いている場合にはmeta data serverにアクセスできますが、eth1に向いてしまっているとmeta data serverにアクセスできません。

→鉄則その1:OS上のdefault gatewayはeth0!

public segment追加パターン

次に、元々privateなsubnetにいたインスタンスに、public subnetのENIを追加したパターンです。

f:id:j3tm0t0:20120411035324p:image

tcpdumpするとわかりますが、public subnetからのパケットインスタンスに届きますが、戻りのパケットをdefault gatewayであるeth0経由で戻そうとして、routeがないため届かないので、通信ができません。

→鉄則その2:追加したNICからは、routingが必要なホストと通信できない(と思え)

ENIを使う場合には、追加したSubnet内のホストとしか通信しないくらいのつもりで使用するべきです。

厳密にはOS上にstatic routeを設定することで、特定ホストやネットワークと通信させる事は不可能ではありませんが、美しくありませんので却下です。

ではどうするか?

極力ENIを使わない

必要がなければ使わないことです。VPCでは最初に説明したとおり、NIC2枚刺しにするメリットはほとんどありません。

それでもポリシー上使いたい

DBとFrontが同じネットワークに存在してはいけないようなポリシーがある場合を想定して、以下のような構成を考えてみました。

f:id:j3tm0t0:20120411040928p:image

この例では、DBの存在するセグメントをNetwork ACLを使って自閉セグメントとし、同じセグメントとしか通信を行わないように設定します。

フロントサーバ、管理用サーバDBの存在するSubnetにENIを持ち、default gatewayは元々ついていたeth0に設定します。

VPN Gateway越しに直接DBの存在するSubnetとは通信を行えないため、管理用のインスタンスを置くSubnetを作ります。

まとめ

オンプレミスと同じ構成をとるためだけにENIを使うというのは、あまりメリットがないことがお分かりいただけたと思います。

基本はSecurityGroupやACLによるアクセス制御を検討し、何かしらの制限(ポリシー、ソフトウェアの制約など)により必要な場合にのみENIを使用しましょう。

他にもこんな使い方があるぞ!というのを思いついたら、是非教えてください。

トラックバック - http://d.hatena.ne.jp/j3tm0t0/20120410/1334086123