NAT関連の問題を克服する

NAT関連の問題は、パケットの断片化をサポートしないhide NATデバイスで発生します。

リモートアクセスクライアントが相手のSecurity GatewayとVPNトンネルを作成しようとすると、IKEまたはIPsecパケットが最大伝送単位（MTU）値より大きくなることがあります。結果として生じるパケットare がMTUより大きい場合、パケットはオペレーティングシステムのTCP/IPスタックのデータリンク層で断片化されます。

このようなパケットの断片化をサポートしないHide NATデバイスの背後にリモートアクセスクライアントがある場合、問題が発生します。

項目

説明

1

サーバ

2

セキュリティゲートウェイ閉じた Check Point ソフトウェアを実行してトラフィックを検査し、接続されたネットワークリソースにセキュリティポリシーを適用する専用Check Pointサーバ。

3

インターネット

4

ルータ

5

リモートクライアント

Hide NATは、IPヘッダだけでなく、UDPヘッダに含まれるポート情報も変更します。例えば、UDPパケットが長すぎる場合、リモートクライアントはパケットを断片化します。最初のフラグメントは、IPヘッダに加えてUDPヘッダとデータの一部から構成されています。2番目のフラグメントは、IPヘッダと2番目のデータフラグメントのみから構成される。NATデバイスは、すべてのフラグメントを待ち、再アセンブルしてNATする方法を知らない。

最初のフラグメントが到着すると、NAT装置はIPヘッダーのアドレス情報とUDPヘッダーのポート情報を正常に変換し、パケットを転送します。2番目のフラグメントが到着したとき、NATデバイスは2番目のパケットにUDPヘッダーが含まれていないため、ポート情報を変換することができず、パケットはドロップされます。IKEネゴシエーションに失敗しました。

IKEフェーズIの間

なぜ大きなUDPパケットが発生するのかを理解するためには、IKEの第1フェーズを詳しく見てみる必要があります。IKEフェーズIでは、リモートアクセスクライアントとセキュリティゲートウェイは互いの認証を試行します。認証の方法のひとつに、証明書の利用がある。証明書または証明書失効リスト（CRL）が長い場合、大きなUDPパケットが発生し、リモートクライアントのオペレーティングシステムによって断片化されます。

注 - VPNピア同士が事前共有秘密を使用して認証する場合、大きなUDPパケットは生成されませんが、証明書の方がより安全であるため、推奨されます。

IKE over TCP

IKE over TCP は、IKEフェーズIで作成される大きなUDPパケットの問題を解決します。IKEネゴシエーションは、TCPパケットを使用して実行されます。TCPパケットは断片化されません。TCPパケットのIPヘッダでは、DFフラグ（"do not fragment"）がオンになっています。フェーズIの間、IKEネゴシエーションのためにピア間で完全なTCPセッションが開かれます。

IKEフェーズII期間中

あるリモートアクセスクライアントは、暗号化および完全性の方法に関するポリシーを持っていない。リモートアクセスクライアントは、一連の提案を通じて暗号化と完全性のための方法を交渉し、セキュリティゲートウェイとall 可能な組み合わせを交渉する必要があります。このため、UDPパケットが大きくなり、送信前にリモートクライアントのOSによって再び断片化される可能性があります。リモートクライアントの前にあるNAT装置は、UDPヘッダー（ポート情報を含む）がないパケットをドロップします。ここでもIKEネゴシエーションは失敗します。

Why not use IKE over TCP again, as in phase I?

IKE over TCPは、長いパケットの断片化の問題を解決しますが、フェーズIIでは、セキュリティゲートウェイがリモートクライアントとの接続をinitiate する必要がある場合があります。(リモートクライアントのみがフェーズIを開始するが、どちらの側も鍵のフェーズII更新の必要性を認識できる。セキュリティゲートウェイが必要性を認識した場合、セキュリティゲートウェイが接続を開始する)。

Security Gatewayが接続を開始する場合、Security GatewayはNATデバイスのIPアドレスを知っていますが、リモートクライアントbehind NATingデバイスに変換するポート番号を提供することはできません。(以前の接続時に使用されたポート番号は一時的なものであり、すぐに変更される可能性があります)。 NATデバイスがリモートクライアントの接続を正しく転送できず、Security Gatewayが開始した接続に失敗します。

IKE over TCPを使用することも可能ですが、この場合、TCP接続を常にオープンにしておく必要があります。オープンセッションは、セキュリティゲートウェイ上のソケットを予約するため、貴重なシステムリソースを消費します。より合理的な方法は、UDPの「キープアライブ」パケットをセキュリティゲートウェイに送信してNATデバイスのポートをオープンにしておき、通常の方法でIKEフェーズIIを実行することです。しかし、UDPパケットの断片化を防ぐために、UDPパケットを短くする必要性があります。

小型IKEフェーズII課題

セキュリティゲートウェイとリモートピアの両方が、暗号化と完全性のための少数の方法を提案することによってIKEネゴシエーションを開始します。より一般的な方法は、小さな提案に含まれています。

リモートクライアントとセキュリティゲートウェイの間でプロポーザルが一致すれば，提案された方法が使われ，一致しなければ，より多くのプロポーザルが作られる．通常、小さな提案で一致するものが見つかり、フラグメンテーションは問題にならなくなる。ただし、マッチングが取れず、より多くの提案が必要な場合もあります。(これは、リモートセキュリティゲートウェイが暗号化にAES-128を使用しており、AES-128が小さな提案に含まれていない場合に発生する可能性が高いです)。

プロポーザルの数が多いと、UDPパケットのサイズが大きくなることがあります。これらの大きなパケットは、クライアント上のTCP/IPスタックのデータリンク層で再び断片化され、断片化をサポートしないHide NATデバイスによって廃棄される。AES-128の場合、AES-128を好ましい方式と定義することで、この暗号化方式を小さなプロポーザルに含めることができる。

IPsec時

NATトラバーサル（ファイアウォールとプロキシのためのUDPカプセル化技術）

IKEフェーズIとIIのネゴシエーションに成功し、IPsecステージに移行します。例えばAESやSHAで暗号化されたデータペイロードは、IPsecのパケット内に配置される。しかし、このIPsecパケットには、もはやTCPやUDPのヘッダーは含まれていない。Hide NAT装置は、ヘッダー内のポート情報を変換する必要があります。TCP/UDPヘッダーはデータペイロードとともに暗号化されており、NATデバイスからは読み取れなくなりました。

ポート番号の付加が必要です。UDPカプセル化とは、IPsecパケットに読み取り可能なポート情報を含む特別なUDPヘッダを付加する処理である。

IPsec パスの最大伝送単位

IPsec Path MTUは、IPsecパケットの断片化に対処するための方法である。データリンク層は、物理ネットワーク上で送信できるパケットのサイズに上限を設けており、これを最大送信単位（MTU）という。パケットを送信する前に、オペレーティングシステムのTCP/IPスタックは、ローカルインタフェースに問い合わせ、そのMTUを取得します。TCP/IPスタックのIP層は，ローカルインタフェースのMTUとパケットサイズを比較し，必要に応じてパケットを断片化します。

リモートクライアントがセキュリティゲートウェイと複数のルータにまたがって通信する場合、重要なのはall の最小の MTU である。これはpath MTU (PMTU) であり、リモートアクセスクライアントには、IPsec パケットが大きすぎる場合にクライアントの OS が IPsec パケットを断片化しないための特別なIPsec PMTU 発見メカニズムが存在します。

しかし、インターネット上のルーティングは動的であるため、リモートクライアントとセキュリティゲートウェイ間のPMTUは一定ではありません。セキュリティゲートウェイからクライアントへの経路は両方向で同じとは限らないので、各方向で独自のPMTUを持つことができる。VPNでは、2つの方法でこれを処理します。

  • アクティブIPsec PMTU

  • パッシブIPsecのPMTU

アクティブIPsec PMTU

IKEフェーズIIの後、IPsecステージの前に、リモートアクセスクライアントはセキュリティゲートウェイに様々なサイズの特別な発見IPsecパケットを送信します。パケットのDF（do not fragment）ビットが設定されている。パケットがどのルータのMTUよりも長い場合、ルータはパケットをドロップし、リモートクライアントにICMPエラーメッセージを送信します。フラグメント化されていない最大のパケットから、リモートクライアントは適切なPMTUを解決します。このPMTUはOSに直接伝えられることはありません。オペレーティングシステムが知らないうちに、TCPの3ウェイハンドシェイク中に、SYNおよびSYN-ACKパケットの最大セグメントサイズ（MSS）が、PMTUを反映して変更されるのです。これは、Active IPsec PMTU として知られています。

パッシブIPsecのPMTU

Passive IPsec PMTUは、動的なインターネットルーティングの問題を解決します。Passive IPsec PTMUは、経路の変更に起因するICMPエラーメッセージをどちらかが受信した場合に発生する処理である。インターネットでは経路が動的に変化するため、別のルータがDFビットが設定されたパケットをフラグメント化する必要がある場合、ルータはパケットを破棄し、ICMPの「cannot fragment」エラーメッセージを生成します。エラーメッセージは、パケットを送信したVPNピアに送信されます。このエラーメッセージを受信したピアは、PMTUを減少させて再送信を行います。

注 - システム管理者の観点からは、PMTUについて設定するものはありません。IPsecのPMTU発見メカニズムは、アクティブとパッシブの両方で、自動的に実行されます。

セキュリティゲートウェイからクライアントへのNATとバックコネクト

次の図では、リモートクライアントはNATデバイスの背後にあり、セキュリティゲートウェイまたはクラスタ閉じた 冗長構成で連携する2つ以上のセキュリティゲートウェイ（ハイアベイラビリティまたは負荷分散）をクラスタ化します。に接続しています。

項目

説明

1

LAN

2

内部スイッチ

3

セキュリティゲートウェイまたはクラスタ

4

外部スイッチ

5

インターネット

6

NATedデバイス

7

リモートアクセスクライアント

これは、Security Gateway側でNATedを行う場合も同様です。

通常、リモートアクセスVPN閉じた リモートアクセスクライアント（Endpoint Security VPNなど）とSecurity Gatewayの間の暗号化されたトンネル。クライアントは、セキュリティゲートウェイの背後にあるホストと通信するために、VPNセキュリティゲートウェイへの接続を初期化する必要があります。しかし、リモートアクセスVPNクライアントが接続を開いた後、VPNセキュリティゲートウェイの背後にあるホストは、リモートアクセスVPNクライアントに対してリターンまたはバック接続を開くことが可能です。裏接続を成功させるためには、リモートアクセスクライアントとVPNセキュリティゲートウェイの間のすべてのデバイス、およびVPNセキュリティゲートウェイ自体で、リモートアクセスクライアントの詳細情報を維持する必要があります。

  1. SmartConsole閉じた Check Point 環境の管理に使用される Check Point GUI アプリケーション-セキュリティポリシーの構成、デバイスの構成、製品とイベントの監視、アップデートのインストールなど。で、Menu > Global properties をクリックします。

  2. Remote Access ページを選択します。

  3. Remote Access > Additional Propertiesセクションをクリックし、Enable Back Connections (from gateway to client)を選択します。

  4. OKをクリックします。

  5. このSecurity Gatewayオブジェクトにアクセスコントロールポリシーをインストールします。