ソリューションアーキテクトの荒木(twitter:
ar1)です。
EC2-VPCでできること、EC2-Classicでできることには違いがあります。機能面については、皆様がよくご存知の通り、複数IPアドレス、複数ネットワークインターフェース、セキュリティグループの付け外し等大きく拡張されています。
このような魅力的な機能を持つVPCは、昨年からデフォルトで全てのEC2利用者に利用いただいています。
とはいえ、VPCは物理的な線があり、NICがあるいわゆる物理環境と違うのも事実です。そしてAWSがサポートしていないことがいくつかあることがわかっています。それはIPv6対応であり、Multicast対応であり、イーサネットフレームのコピーであったりします。そんなことを実現するために、トンネリングがしばしば使われます。
その方法は多数知られています。パケットをいじる以上、そのいじり方に応じてトレードオフがあり、それぞれの目的のために実装も異なります。標準化されている方法としては、IP-in-IP (rfc1853)、Generic Routing Encapsulation (rfc2784)が、よく使われています。また、ネットワークデバイスの仮想化技術として知られるTUNとTAPもよく使われています。乱暴ですが、これらをまとめると次のようになります。
| |
カプセル化対象 |
オーバーヘッド |
コメント |
| IP-in-IP |
IPのみ |
小 |
20オクテットのIPヘッダを先頭に付与 |
| GRE |
IP,AppleTalk,Multicast,IPv6等 |
小 |
IPヘッダ+4オクテットのGREヘッダを先頭付与 |
| TUN |
IP |
中 |
ネットワーク層のデバイスを模擬 |
| TAP |
イーサネット |
大 |
イーサネットデバイスを模擬 |
下にいくほど汎用的に使える反面、処理のオーバーヘッドも大きくなります。
また、VPNの構成要素として、これらを使うためには安全を保つ仕組みが必要です。
LAN間を接続するVPNとしては、IPSecが広く知られています。IPSecでは、暗号化したうえ、認証データ、シーケンス番号等を加えたESP(Encapsulating Security Payload)にIPヘッダをつけてデータ転送をします。そのため、オーバーヘッドは単純なトンネルに比べてさらに大きなものとなります。
| Offsets |
Octet16 |
0 |
1 |
2 |
3 |
| Octet16 |
Bit10 |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
25 |
26 |
27 |
28 |
29 |
30 |
31 |
| 0 |
0 |
Security Parameters Index (SPI) |
| 4 |
32 |
Sequence Number |
| 8 |
64 |
Payload data (ここが元々送るべき内容) |
| … |
… |
| … |
… |
|
|
| … |
… |
|
Padding (0-255 octets) |
|
| … |
… |
|
Pad Length |
Next Header |
| … |
… |
Integrity Check Value (ICV)… |
| … |
… |
当たり前のことですが、EC2-VPCでは、これらのトンネリングを自由に使うことができます。
「パケットの気持ちになって考え」たことはあるでしょうか?パケットの持っている情報を理解し、次の動きを考えてみたことはあるでしょうか?ファイアウォールの下などの制限されたネットワークからすこしでも自由なネットワークに出て行きたい、そんなことでもないかぎり、「パケットの気持ちになって考え」ることは無いかもしれません。
様々なユーザーが参加し、一歩前へ、進める企画を用意しているJAWS DAYS 2014が今週末の土曜に迫りました。Track3: AWS Technical Deep Diveでは、「マルチキャストがないならユニキャストすればいいじゃない/ほしいプロトコルはカプセルすればいいじゃない」というタイトルで、荒木と安川のセッションを担当します。
制限されたネットワークでも自由なシステムを創りあげるためとはいえ、オーバーヘッドは小さいに越したことはないでしょう。このセッションでは、いくつかのパケットのあしらい方を紹介します。皆様のシステム作りに寄与できることを祈っています。