NAT トラバーサルに関する構成上の追加考慮事項

以下のリストには、NAT トラバーサルに関連した構成上の追加考慮事項が記載されています。

• NAT トラバーサルの使用時、z/OS® は、z/OS ホーム・リスト内に構成されたアドレスとして、自分自身のアドレスを見なします。 z/OS ホストが NAT の背後にある場合、このアドレスはプライベート・アドレスです。 そうでない場合は、z/OS ホストのパブリック・アドレスです。

  z/OS 実装では、リモート IKE ピアまたはリモート IP 接続エンドポイントを記述するのに、自分自身の構成内のプライベート・アドレスを使用しません。 z/OS は、IPSec ピアおよびリモート IP 接続エンドポイントを、パブリック IP アドレスと見なします。IPSec ピアの前に NAT がある場合、z/OS ホストは、IPSec ピアと接続エンドポイントのアドレスがその NAT のアドレスであるものとして認識します。

• IKEv1 セキュリティー・アソシエーションについては、NAT 背後に複数のリモート・ピアがあり、それらのピアがそれぞれ固有の RemoteSecurityEndpoint 指定に対してマップしない場合は、メインモードで事前共有秘密鍵を構成しないでください。 RFC 3947 では、メインモードでは事前共有秘密鍵は使用できないと規定しています。ただし、例外として、NAT の背後にあるすべてに対してグループ共有秘密鍵が配備される場合を除きます。グループ事前共有秘密鍵はセキュリティー・リスクと見なされます。
• NAT アドレスが動的 NAT プールから取られる場合は、プールからホストに割り当てられるアドレスには、プールに含まれているアドレスのどれでも割り当てることができます。この場合は、追加の考慮事項があります。 z/OS がレスポンダーの場合、ホストを対象とする IPSec ポリシーは、動的 NAT プール内の全 IP アドレス範囲をカバーできるだけの十分に広範なものでなければなりません。z/OS がイニシエーターであり、レスポンダーが NAT の背後にあるときは、ターゲット・ホストの身元があいまいになることがあります。z/OS ホストを、あいまいなターゲット・ホストを対象として開始するように構成しないでください。
• リモート・セキュリティー・エンドポイントが NAT の背後にある場合は、そのエンドポイントの身元は固有にする必要があります。 フェーズ 1 ネゴシエーションの際に、リモート・セキュリティー・エンドポイントは、自身の身元識別情報を ID ペイロードに含めて送信します。 IKE デーモンは、複数のリモート・セキュリティー・エンドポイントが NAT 背後にない場合に、同一 ID を使用してそれらのエンドポイントを管理可能です。しかし、あるリモート・セキュリティー・エンドポイントが NAT 背後にある場合は、そのエンドポイントは固有の IKE 身元を使用する必要があります。
• リモート・セキュリティー・エンドポイントが NAT 背後のセキュリティー・ゲートウェイであるか、NAPT 背後のホストである場合、TCP、UDP、および ICMP トラフィックのみがサポートされます。ICMP トラフィックのサポートは限定されています。
• z/OS は、TCP 接続の保全性検査が可能である限り、その TCP 接続用のトラフィックの継続を許可します。z/OS が接続の保全性を検査できなくなるのは、次の 2 つの場合です。
  • TCP 接続に対する IPSec 保護の追加または除去

    TCP 接続が NAT をトラバースする場合、フィルター・ポリシーの変更 (その変更が原因で接続のトラフィックが IPSec 保護トラフィックから平文に変更、または平文から IPSec 保護トラフィックに変更) 後は、その TCP 接続を再開する必要があります。

  • NAT IP アドレスの再マップ

    NAT デバイスのタイムアウトまたはリブートが原因で、ピアの IP アドレスが NAT により再マップされた場合は、TCP 接続を再始動する必要があります。