リモートアクセス型VPNの構築ポイント：インターネットVPNの接続環境とその機能（後編）（2/2 ページ）

» 2003年05月31日 00時00分公開

VPN接続環境の影響

　リモートアクセス型VPNの環境構築時には、VPN接続のエンドポイントに割り当てられるアドレス体系について考える必要がある。

　VPN環境を構築するとき、VPN機器をネットワークのどこに配置するかにより、VPNゲートウェイに割り当てられるアドレス体系が決まる。接続先VPNゲートウェイが組織のファイアウォールの内側のネットワーク上に設置されているのであれば、プライベートアドレスが使用される場合が多いのである。また、リモートアクセス型VPNでは、VPN接続時にダイヤルアップ接続や無線ネットワークなどを介して利用するが、その場合も接続サービスを提供するプロバイダにより割り当てられるアドレス体系は異なってくる。一般にプライベートアドレスがVPN機器に割り当てられた場合、インターネットを介して通信するためには通信経路上にプライベートアドレスからパブリックアドレスに変換するアドレス変換装置が存在することになる。ここでは、アドレス変換装置がIPSec通信に与える影響について説明する。

●NAT環境とIPSec標準

　アドレス変換には、NAT（Network Address Translation）あるいは、NAPT（Network Address and Port Translation）という仕組みが使用される。アドレス変換の仕組みを図4、図5に示す。

図4 ベーシックNAT（1対1）

図5 NAPT（多対1）

　IPSecを使用するVPN環境では、暗号化通信にESP（Encapsulation Security Payload）プロトコルを使用する。ESPプロトコルは図6のようなプロトコルフォーマットで構成される。

図6 ESPプロトコルのフォーマット

　では、VPNのエンドポイント間に存在するアドレス変換装置が、通過するESPパケットをどのように処理するのかについて説明しよう。

　サイト間接続型VPNの場合、接続相手は他方のVPNゲートウェイのみであるため、アドレス変換装置では、1対1のアドレス変換を実現する（ベーシックNAT）。ベーシックNATの場合は、変換の対象がIPヘッダのIPアドレス部分のみであるため、ESPプロトコルに影響を与えることはない。つまり、IPSecを使用して通信することが可能である。

　リモートアクセス型VPNの場合は、複数のVPNクライアントと接続を受け付けるVPNゲートウェイの間に存在するアドレス変換装置では、多対1というアドレス変換を実現する必要がある（NAPTを実現する）。図3で示したようにNAPTでは、IPヘッダ内のIPアドレス部とその次に位置するTCP/UDPヘッダ内のポート番号部を変換する。しかし、ESPプロトコルではIPヘッダの次にはESPヘッダが位置し、NAPTが操作しようとするポート番号部分が存在しないため、アドレス変換処理が失敗する。

　つまり、ポート番号の変換が生じないベーシックNAT環境（1対1変換）であれば、ESPプロトコルを使用した通信が可能であるが、多対1変換を実現するNAPT環境ではポート番号変換が生じるため、ESPプロトコルを使用できない。結果的に、現行のIPSec標準仕様ではリモートアクセス型VPN環境で必要となるNAPT環境に対応できないのである（図4）。

●NAPT環境への対応

　IETFでは、NAPT環境下でIPSecを使用するためのインターネットドラフトが提案されている。現在多くのVPNベンダが採用しているドラフトは以下の2つである。

NAT Traversal（Negotiation of NAT-Traversal in the IKE）
- VPNゲートウェイとVPNクライアント間にアドレス変換が存在しているか否かの検証。
- VPNゲートウェイとVPNクライアントのどちら側にNAT装置が存在するのかの検証。
UDP encapsulation（UDP Encapsulation of IPSec Packets）
- NAT装置上でのNAPTに対応するために、経路上でNATあるいはNAPTが検出された場合にESPパケットをUDPでカプセル化する。
- NAT装置上では、追加されたUDPヘッダー内のポート番号を変換する。

参考
NAT Traversal（draft-ietf-ipsec-nat-t-ike-05.txt）
UDP encapsulation（draft-ietf-ipsec-udp-encaps-06.txt）

相互接続性

　リモートアクセス型VPNでは、上記に説明した認証方式（XAUTH）やNAT環境対応（NAT Traversal／UDP encapsulation）のインターネットドラフトを独自に実装している。インターネットドラフトは、意見調整を経て、RFCとして標準化されるか、標準化されずに参考文献となる。今回取り上げたインターネットドラフトは、IPSecのRFCとはなっていないが、多くのベンダが参照し、実装していることもあり、“Proposal Standard（提案）”として扱われている。

　しかし、この現実が異なるベンダ製品間の相互接続性を困難なものとしている。例えば、NAT環境への対応について記述されたインターネットドラフトには複数のドキュメントバージョンがある（本記事執筆時点の最新バージョンは、version5である）。バージョンにより、通信メッセージのフォーマットが異なっているため、同じインターネットドラフトを実装しているといっても別物として認識する必要がある。環境を構築する場合は、導入する製品がどのバージョンを実装しているかを事前に確認する必要がある。また、同じバージョンを実装している場合でも実装方法はベンダによって異なる（つまり、IKEプロトコルの拡張方法が異なる）ため、実際は導入以前に十分な接続性評価作業が必要である。

●製品の選択

　リモートアクセス型VPN環境を実現する場合、相互接続性を維持するため同一ベンダの製品を利用した方が無難であるといえるのか？一般的には、その答えは“Yes”であろう。しかし、構築する環境において、選択した製品が利用を想定しているすべてのプラットフォーム上で動作しない場合がある。例えば、PDA端末でIPSec製品を利用する場合は、VPNゲートウェイ製品を提供するベンダとは異なるベンダの製品を利用する場合が多い。

　セキュリティ製品を導入する場合に重要なのは、「“何を”、“どんな環境下で”、“何のために”、実現したいのか？」を明確にすることである。例えば、アドレス体系の問題であれば、PHS端末を使用したダイヤルアップ接続を利用してプロバイダのアクセスポイントに接続することにより、VPNクライアントに割り当てられるIPアドレスはパブリックアドレスとなる。接続先のVPNゲートウェイのIPアドレスにパブリックアドレスを使用していれば、NAT環境の問題は回避することができるのである。

　今回は、IPSecを利用したリモートアクセス型VPN環境を構築する場合の留意点について、特に認証やNAT環境対応の実装に着目して説明をしたが、実際に環境を構築する場合は、ここで取り上げたポイント以外に、Re-Key（IKE／IPSecのライフタイムが満了した場合の再ネゴシエーション方法）やIKE KeepAliveパケットについても検証が必要である。また、プロバイダや組織内で利用可能なアクセス形態が、DSL、WiFiなどの普及により多様化してきているため、下位層のMTUサイズの相違がIPSec通信に影響を与える場合もある。評価作業時には、実際の利用形態を想定した接続試験が必須である。

　しかし、現状はこのようであっても、End-to-Endのセキュリティを実現するためには、現在のところIPSecが有力である。

「インターネットVPNの接続環境とその機能」バックナンバー