クラウド時代のIPv4アドレス枯渇問題を考える

仮想ルータVyatta/VyOSで変わるネットワーク設計（4）

IPv4アドレス再利用の方式

　パブリッククラウドにおいて「図5. IPv4アドレスとポート番号における未使用空間」を出発点として、「使われていないポート番号を転送してインスタンス（仮想マシン）ごとに提供しよう！」というIPv4アドレス再利用の方式は、読者の皆様もすぐに浮かんでくるかと思います。この方式で昔から使われているのがNAT変換装置ですね（図8）。

　IPv4アドレス枯渇問題が先行するISP（インターネットサービスプロバイダ）が、この問題に取り組んだ結果、現在私たちの環境では高性能なNAT変換装置やソフトウェアソリューションが入手可能できるようになっています。価格・性能も千差万別なので、「IPv4アドレス移転コストよりもIPv4アドレス再利用に必要な機器およびソリューションが低価格」であるいう条件が満たされた時に使うことができます。

図8. パブリッククラウドにおけるNAT変換装置によるIPv4アドレス再利用

　ただ、NAT変換装置を取り入れた場合、すべてのトラフィック処理とNAT変換処理が集中するため、大きなボトルネックとなる可能性があります。これを解決するIPv4アドレス再利用の手法として、つぎにポリシーベースルーティング（PBR: Policy Base Routing）についてみていきましょう。

　ポリシーベースルーティングによるIPv4アドレス再利用では、NAT変換処理への集中のような状況を防ぐために、さらにL3DSR（Layer 3 Direct Server Response）と呼ばれる手法との組み合わせが考えられます（図9）。

図9. パブリッククラウドにおけるポリシーベースルーティングによるIPv4アドレス再利用

　少し複雑になるので、順番にポリシーベースルーティングを用いたL3DSRによるIPv4アドレス再利用についてみていきましょう。より理解が進むように、今回はポリシーベースルーティングにBrocade Vyatta vRouterを使ってみました。新人のシステムエンジニアの方には、理解が難しいところもあるかとは思いますが、頑張ってお付き合いください。

　まずパブリッククラウドの上位ルータにおいて、グローバルIPv4アドレスである「A.A.A.A/32」がポリシーベースルータに向けられます。ポリシーベースルータでは到達したパケットが「A.A.A.A:44022」というIPアドレスとポート番号の組み合わせの時のみ、インスタンス「10.10.10.10」へパケットを転送します（この時NAT処理されません）。インスタンスにはループバックインターフェースに「A.A.A.A/32」が設定されており、またポート番号44022でアプリケーションもListen状態にあるため、パケットを受信します。インスタンスのアプリケーションはデフォルトゲートウェイとして指定されている上位ルータへ向けてパケット送信を行いクライアントとの通信を確立します。この際、送信元は「A.A.A.A」のグローバルIPv4アドレスになります（この時もNAT処理されません）。

　さらに詳しく理解したい場合は「PBR-LB - Direct Server Return Load Balancing using Policy Based Routing （MEMO）」（SlideShare）も併せてご参考ください。

図10. Brocade Vyatta vRouterによるポリシーベースルーティングを用いたL3DSRの動作原理

　ポリシーベースルーティングでは特定条件のみパケット転送先を変更する処理が行え、L3DSRという仕組みをうまく使うことで、戻りパケットもポリシーベースルーティングを行う装置を介すことなく処理が行えます。これによりNAT変換装置のような特大のボトルネックを生むことはなくなるのです。

　このような非対称のパケット処理では、図11のようなトラフィック変化が起きます。最終的にインスタンスに転送されるパケットのSYN, ACK, PSH ACKなど、片側トラフィックだけがポリシーベースルーティングを行う装置を通過し、戻りパケットはL3DSRの仕組みによってインスタンスがデフォルトゲートウェイとして指定する別の上位ルータへ転送されるのです。

図11. ポリシーベースルーティングを用いたL3DSRにおける非対称トラフィック

　この仕組みにより、パブリッククラウドにおいてIPv4アドレス枯渇問題における最悪のシナリオが現実となった時への備えを今から持つことができることでしょう（図12）。

図12. 大規模なポリシーベースルーティングとL3DSRによるIPv4アドレス再利用の未来（仮）

　ネットワーク設計手法が変更になると、監視手法も変わってきます。古くからのシステムエンジニアの方にはお分かりのとおり、インターネット上からのping（ICMP）によるネットワーク監視がうまく動作しなくなります。

　これの対処として、TCPポート単位でのping監視という手法が必要です（「スタンドアローンで制御不能な兵器などナンセンス」と陸幕調査部別室の荒川さんも仰られています／（C）劇場版 機動警察パトレイバー2）。これにはLinuxでは、すでに多くの方が使われているhping3、npingなどが有効です （図13）

図13. LinuxにおけるTCPポート番号単位でのping監視

　Windowsでも同じく、Microsoft Windows Sysinternalsで収録されているpspingがそれに該当します。

図14. WindowsにおけるTCPポート番号単位でのping監視

　「クラウド時代のIPv4アドレス枯渇問題を考える」は、いかがでしたでしょうか？ ちょっと先の未来。IPv4アドレス移転の流動性がうまくいき、IPv6ネットワークの普及が順調にいったときはおそらく使うこともない未来の技術。さくらインターネット研究所で筆者が取り組ませていただいている3～5年先の未来のお話、少しでもお楽しみいただければ幸いです。

次回予告

　さて次回は、「いまさら聞けないモバイルとIPv6ネットワークのいま（前編）」と題して、仮想ルータを使ったちょっと未来のIPv6ネットワーク設計手法について解説していきます。ご期待ください。