NAT を使用する事業所モデル (IPSec を使用するホスト対ゲートウェイ通信) を構成するためのステップ

NAT を使用する事業所モデルは、セキュリティー・ゲートウェイの前に NAT が含まれるように、事業所モデル・トポロジーを変更します。

始める前に

このモデルの説明では、ホスト対ゲートウェイ動的 IKE ネゴシエーションに対する NAT の影響について取り扱います。

ローカルおよびリモートのデータ・エンドポイント
ローカルおよびリモートのセキュリティー・エンドポイント
IKE イニシエーターとレスポンダーの役割
HowToAuth プロトコルに対する制限 (AH はサポートされない)

事業所モデルを構成するためのステップ: パート 1 (IPSec を使用するホスト対ゲートウェイ通信)では、ホストとセキュリティー・ゲートウェイの両方を持ったネットワーク・トポロジーが想定されていました。この他に、そのセキュリティー・ゲートウェイの背後にある幾つかのホストがパブリック IP アドレスを使用しているネットワーク・トポロジーも想定されていました。セキュリティー・エンドポイントの一方または両方が、プライベート IP アドレスを使用する NAT の背後にあることがよくあります。

事業所モデル・トポロジーを、セキュリティー・ゲートウェイの前に NAT が含まれるように変更すると、NAT を使用する事業所トポロジーは図 1 のようになります。

図 1. NAT を使用する事業所モデル

事業所モデルに似ていますが、NAT 装置は事業所のセキュリティー・ゲートウェイの前に追加されています。

この例では、ホスト対セキュリティー・ゲートウェイ環境において、NAT ソリューションを実装して NAT デバイスをトラバースする場合の、構成上の考慮事項と要件について説明します。 NAT を使用する事業所モデルの場合も、基本的なセキュリティー要件は事業所モデルの場合と同じです。 NAT を使用する事業所モデルの場合に追加または変更される構成ステートメントは、太字で示されています。この例では、ホスト 9.3.3.3 のポリシーについて説明します。

この例では、ゾーン C、つまりプライベート IP アドレスを使用する事業所ネットワーク (10.3.0.0/16) から、このホスト上のパブリック IP アドレス (9.3.3.3) へのネットワーク通信を使用可能にするために、以下の要件が満たされていなければならないものとします。事業所ネットワーク上のホストは、NAT 背後の事業所ゲートウェイ・サーバーを介してインターネットに接続されます。このモデルでは、NAT は、セキュリティー・ゲートウェイのプライベート・アドレス 10.3.3.3 からパブリック・アドレス 9.5.5.5 への静的マッピングを保有しています。

事業所ゾーン C のセキュリティー・ゲートウェイからこのホストへの IKE トラフィックを許可する。
事業所ゾーン C から、このホストで実行されている EE サービスへの、強い認証と暗号化を伴う動的 VPN を使用した EE トラフィックを許可する。セキュリティー・ゲートウェイの背後 (事業所ゾーン C) にある 1 つのホストのみが、EE トラフィックを送信することができます。
ガイドライン: ほとんどの場合、NAT 背後のセキュリティー・ゲートウェイの背後には、EE ホストは配置しないようにしてください。その代わりに、各 EE ホストごとにホスト対ホスト・セキュリティー・アソシエーションをネゴシエーションする必要があります。

事業所モデルを構成するためのステップ: パート 1 (IPSec を使用するホスト対ゲートウェイ通信)では、LocalDynVpnRule ステートメントの AutoActivate パラメーターを Yes に設定することにより、z/OS® スタックの初期化時に VPN が活動化されることになっていました。このシナリオでは、ゲートウェイの背後にあるホストは、ポリシー内で構成できるパブリック・アドレスを持っていません。したがって、ホスト 9.3.3.3 からセキュリティー・ゲートウェイ 9.5.5.5 へのセキュリティー・アソシエーションの開始は不明確なものとなります。その理由は、リモート・データ・エンドポイントの IP アドレスが不明であるからです。z/OS は、セキュリティー・ゲートウェイへの UDP カプセル化トンネル・モードのセキュリティー・アソシエーションの開始を許可しません。セキュリティー・ゲートウェイ 9.5.5.5 とホスト 9.3.3.3 の間のセキュリティー・アソシエーションは、セキュリティー・ゲートウェイにより開始され、ホスト 9.3.3.3 がレスポンダーとしての役割を果たす必要があります。
事業所ゾーン C から、このホストで実行されている FTP サーバーへの、強い認証と暗号化を伴う動的 VPN を使用した通常の FTP トラフィックを許可する。事業所モデルを構成するためのステップ: パート 1 (IPSec を使用するホスト対ゲートウェイ通信)では、管理者が z/OS UNIX コマンド行から VPN を活動化していました。この場合も、z/OS は、セキュリティー・ゲートウェイへの UDP カプセル化トンネル・モードのセキュリティー・アソシエーションの開始を許可しません。セキュリティー・ゲートウェイとホスト 9.3.3.3 の間のセキュリティー・アソシエーションは、セキュリティー・ゲートウェイにより開始され、ホスト 9.3.3.3 がレスポンダーとしての役割と果たす必要があります。
ピアは、事前共有秘密鍵方式を使用して互いに相手を認証する。

手順

これらの要件を満たし、NAT を使用する事業所モデルを構成するには、以下のステップを実行します。

保護するゾーン数を判別します。この事業所は、ゾーン C という 1 つのゾーンで表されます。
各ゾーンについて、どのようなサービスが許可されるかを決定し、必要とするそれぞれのサービスについて IpService ブロックを定義します。サービスは、それぞれのプロトコルと使用するウェルノウン・ポートにより定義されます。
FTP トラフィックを記述する定義は、1 つの IP サービス・グループにまとめることができます。一般に、FTP クライアントは、NAT の背後にあるときは、パッシブ・モード (PASV) または拡張パッシブ・モード (EPSV) を使用して、FTP サーバーに接続します。アクティブ・モードとパッシブ・モードの FTP についての詳細は、NAT トラバース時の IPSec カプセル化 FTP トラフィックに関する考慮事項を参照してください。

データ接続について指定されるサーバー・ポートの範囲には、サーバーの FTP.DATA ファイル内で PASSIVEDATAPORTS に指定されているポート範囲が反映されます。PASSIVEDATAPORTS について詳しくは、「z/OS Communications Server: IP 構成解説書」を参照してください。

以下の定義は、PASV または EPSV の場合にサーバーが必要とするサービスを示しています。
```
IpServiceGroup               FTPServer
{
  IpService                  FTPServer-Control
  {
    SourcePortRange            21
    Protocol                   tcp
    Direction                  bidirectional InboundConnect
    Routing                    local 
    SecurityClass              0        		
  }
  IpService                  FTPServer-Data-Passive
  {
    SourcePortRange            50000 50200  
    Protocol                   tcp
    Direction                  bidirectional InboundConnect
    Routing                    local
    SecurityClass              0
  }
}
```
Enterprise Extender のトラフィック・パターンは、以下のように 1 つの IpService ブロック内で定義することができます。
```
IpService                    Enterprise-Extender
{
  SourcePortRange            12000 12004
  DestinationPortRange       12000 12004
  Protocol                   udp
  Direction                  bidirectional
  Routing                    local
  SecurityClass              0
}
```
保護するデータ・エンドポイントを判別します。この例では、ローカル・ホストのパブリック IP アドレス 9.3.3.3 について、以下のステートメントを定義します。
```
IpAddr                       PublicServerAddressA1
{
  Addr                       9.3.3.3
}
```
この例では、リモート・データ・エンドポイントは事業所の内部ネットワーク内にあります。 z/OS NATT 実装では、リモート・エンドポイントに対するプライベート・アドレスのコーディングは不要です。代わりに、このセキュリティー・ゲートウェイのパブリック・アドレスがリモート・データ・エンドポイントと見なされます。 NAT はこのセキュリティー・ゲートウェイに対して静的マッピングを使用しているため、ゲートウェイのパブリック・アドレスが指定されます。NAT が動的マッピングを使用しているとすると、セキュリティー・ゲートウェイをマップできる対象のパブリック IP アドレス範囲をこの定義に含める必要があります。
```
IpAddr                       BranchOfficeGateway
{
  Addr                       9.5.5.5
}
```
この IP アドレスは、ローカル・パブリック・サーバーとリモート事業所ゲートウェイの間の IKE トラフィックを許可するためにも必要です。
各セットのデータ・エンドポイント間に必要なセキュリティーのレベルを判別します。この例では、EE と FTP の両方のトラフィックについて強い認証と暗号化が必要なので、ESP 認証と ESP 暗号化が使用されます。 NAT トラバーサル・サポートを使用している場合は、ESP を使用する必要があります。
必要なセキュリティー・レベル (permit、deny、ipsec) と、接続をログに記録するかどうかを指定するために、以下のように IpGenericFilterAction ステートメントを構成します。
```
IpGenericFilterAction        ipsec
{
  IpFilterAction             ipsec
}
```
どの 2 つのエンドポイント間にも IPSec が必要な場合は、以下のアクションを実行します。
1. 以下のようにして、フェーズ 1 ネゴシエーションのパラメーターを定義する鍵交換ポリシーを構成します。
  1. フェーズ 1 セキュリティー・アソシエーションについて、必要な保護のタイプと強度を判別します。
    この例では、MD5 よりセキュア度が高い SHA1 認証、および 3DES とセキュア度が同じ AES 暗号化を使用します。
  2. どのタイプのピア認証を使用するかを決定します。
    この例では、要件の 1 つとして事前共有秘密鍵認証が指定されています。一般的には、多くの利点があるため RSA シグニチャーの方が優先されますが、ここでは、この例の目的を達成するために事前共有秘密鍵方式を使用します。事業所シナリオでは、リモート IKE ピアは 1 つだけ (リモート・セキュリティー・ゲートウェイ) であり、また構成方法が比較的単純であるという利点を考えれば、事前共有秘密鍵認証は妥当な選択肢と言えます。
  3. 以下のようにして、フェーズ 1 ネゴシエーションのパラメーターを定義する KeyExchangeOffer ステートメントを構成します。
```
KeyExchangeOffer             SHA1-AES-PSK
{
  HowToEncrypt               AES_CBC KeyLength 128
  HowToAuthMsgs              SHA1
  HowToAuthPeers             PresharedKey
  DHGroup                    Group14
}
```
  4. NAT トラバーサルを許可するかどうかを決定します。
    KeyExchangePolicy および KeyExchangeAction ステートメントの AllowNat パラメーターは、IKED が NAT トラバーサル・サポートを公示できるようにします。このモデルの場合は、KeyExchangePolicy ステートメントの AllowNat パラメーターに Yes を指定することにより、すべてのフェーズ 1 セキュリティー・アソシエーションについて、NAT トラバーサル・サポートを公示することを許可します。
```
AllowNat Yes
```
    このモデルでは、NatKeepAliveInterval パラメーターにはデフォルト値の 20 秒を使用します。 z/OS が NAT の背後にある場合は、KeyExchangePolicy ステートメントの NatKeepAliveInterval パラメーターに指定されているインターバルで NAT キープアライブ・タイマーが開始されます。このモデルでは、z/OS が NAT の背後にないため、NatKeepAliveInterval に指定されている値、またはデフォルト値に関係なく、NAT キープアライブは維持されません。
  5. Main (メイン) または Aggressive (アグレッシブ) のいずれかのネゴシエーション・モードを決定します。
    NAT 使用の事業所モデルではセキュリティーが優先事項の 1 つなので、フェーズ 1 ネゴシエーションには、保護機能の高い Main (メイン) モードを使用します。
  6. 以下のように KeyExchangeAction ステートメントを構成します。
```
KeyExchangeAction            Gold-PSK
{
  HowToInitiate              main
  HowToRespondIKEv1          main
  KeyExchangeOfferRef        SHA1-AES-PSK
}
```
  7. 以下のように、LocalSecurityEndpoint ステートメントと RemoteSecurityEndpoint ステートメントを構成します。
```
LocalSecurityEndpoint        Public_IKED
{
  Identity                   IpAddr 9.3.3.3
  LocationRef                PublicServerAddressA1
}

RemoteSecurityEndpoint       ZoneC_IKED
{
  Identity                   Fqdn gateway.BO.example.com
  LocationRef                BranchOfficeGateway
}
```
  8. 以下のように、2 つのエンドポイントと鍵交換アクションを含む KeyExchangeRule ステートメントを構成します。
```
KeyExchangeRule              ZoneC_KeyExRule1
{
  LocalSecurityEndpointRef   Public_IKED
  RemoteSecurityEndpointRef  ZoneC_IKED
  KeyExchangeActionRef       Gold-PSK
  PresharedKey               abracadabra
}
```
  9. 以下のように、KeyExchangePolicy ステートメント・ブロックに KeyExchangeRule ステートメントを含めます。
```
KeyExchangePolicy
{
    AllowNat                   Yes
    KeyExchangeRuleRef         ZoneC_KeyExRule1
}
```
2. 以下のように、フェーズ 2 ネゴシエーションの制御を定義する IpDynVpnAction ステートメントを構成します。
  1. フェーズ 2 セキュリティー・アソシエーションについて、必要な IPSec 保護のタイプと強度を判別します。
    この例では、認証は ESP HMAC_SHA1 で、暗号化は AES です。
  2. トンネル・モードまたはトランスポート・モードが必要かどうかを判別します。
    トンネル・モードが必要なのは、セキュリティー・エンドポイントの 1 つがセキュリティー・ゲートウェイである場合です。
  3. 以下のように、フェーズ 2 ネゴシエーションのパラメーターを定義する IpDataOffer ステートメントを構成します。
```
IpDataOffer                  SHA-AES-Tunnel
{
  HowToEncap                 tunnel
  HowToEncrypt               AES_CBC KeyLength 128
  HowToAuth                  ESP HMAC_SHA1
}
```
  4. ネゴシエーションの開始をどのピアに許可するかを決定します。
    このシナリオでは、ゲートウェイの背後にあるホストは、ポリシー内で構成できるパブリック・アドレスを持っていません。したがって、ホスト 9.3.3.3 からセキュリティー・ゲートウェイ 9.5.5.5 へのセキュリティー・アソシエーションの開始は不明確なものとなります。その理由は、リモート・データ・エンドポイントの IP アドレスが不明であるからです。z/OS は、セキュリティー・ゲートウェイへの UDP カプセル化トンネル・モードのセキュリティー・アソシエーションの開始を許可しません。セキュリティー・ゲートウェイ 9.5.5.5 とホスト 9.3.3.3 の間のセキュリティー・アソシエーションは、セキュリティー・ゲートウェイにより開始され、ホスト 9.3.3.3 がレスポンダーとしての役割を果たす必要があります。
  5. 以下のように、フェーズ 2 ネゴシエーションの制御情報を定義する IpDynVpnAction ステートメントを構成します。
```
IpDynVpnAction               Gold-TunnelMode
{
  Initiation                 remoteonly
  InitiateWithPfs            group2
  AcceptablePfs              group2
  IpDataOfferRef             SHA-AES-Tunnel
}
```
3. セキュリティー・アソシエーションをどのように活動化するかを決定します。
  1. Gold-TunnelMode IpDynVpnAction ステートメントの Initiation パラメーターの指定に従い、セキュリティー・アソシエーションのリモート開始のみが許可されます。LocalDynVpnRule または IpLocalStartAction ステートメントは必要ありません。
  2. IPSec トラフィック (ESP) を許可する IpFilterRule ステートメントを作成するか、またはグローバル IpFilterPolicy ステートメントのパラメーター PreDecap を off に設定します。
    この例では、IpFilterPolicy ステートメントで PreDecap off を使用します。
データ・エンドポイントの各セットについて、IpFilterRule ステートメントを定義します。規則には、許可されるサービス (許可される各サービスについてそれぞれ 1 つの IpService ステートメント)、および、必要なセキュリティーのレベル (IpGenericFilterAction ステートメントに対する参照) を含める必要があります。 IPSec が必要な場合は、IKE トラフィック (UDP、ポート 500 および 4500) を許可する IpFilterRule ステートメントを作成します。前に構成した IpAddr および IpAddrSet ステートメントを参照してください。
```
IpFilterRule                 Rule1C
{
   IpSourceAddrRef            PublicServerAddressA1
   IpDestAddrRef              BranchOfficeGateway
   IpServiceRef               IKE-local-500
   IpServiceRef               IKE-local-4500
   IpGenericFilterActionRef   permit
}

IpFilterRule                 Rule2C
{
   IpSourceAddrRef            PublicServerAddressA1
   IpDestAddrRef              BranchOfficeGateway
   IpServiceRef               Enterprise-Extender
   IpServiceGroupRef          FTPServer
   IpGenericFilterActionRef   ipsec
   IpDynVpnActionRef          Gold-TunnelMode
}
```
各ゾーンについて IpFilterGroup ステートメントを定義し、それぞれのゾーンに属する IpFilterRule ステートメントを組み込みます。
IpFilterPolicy ブロックに、すべての IpFilterGroup 参照と、必要に応じて追加の IpFilterRule ステートメントを組み込みます。
構成したすべてのステートメントをスタック固有 IP セキュリティー構成ファイルに含めます。

タスクの結果

以下に示すポリシーは、ローカル・セキュア・サーバーからゾーン C へのトラフィックの、完全な IP セキュリティー・ポリシーです。これは、再使用可能ステートメントが共通 IP セキュリティー構成ファイルに含まれていると想定しています。

#-------------------------------------------------------
# Filter Policy for Secure Server
#-------------------------------------------------------
IpFilterPolicy
{
  PreDecap                   off
  FilterLogging              on
  AllowOnDemand              no
  IpFilterGroupRef           ZoneC
}

#-------------------------------------------------------
# KeyExchange Policy for Secure Server
#-------------------------------------------------------
KeyExchangePolicy
{
  AllowNat                   Yes
  KeyExchangeRuleRef         ZoneC_KeyExRule1
}

########################################################
#               Connectivity Profile
#              Secure Server To Zone C
#
#   Server to Trusted Branch Office Network
#
########################################################
IpFilterGroup                ZoneC
{
   #-------------------------------------------------------
   # Permitted Zone C traffic:
   #    Allow IKE traffic from the gateway IKE Server
   #    for branch office to this host.
   #
   #    IKE  (UDP port 500/4500) - IKE negotiations
   #-------------------------------------------------------

   IpFilterRule                 Rule1C
   {
     IpSourceAddrRef            PublicServerAddressA1
     IpDestAddrRef              BranchOfficeGateway
     IpServiceGroupRef          IKE
     IpGenericFilterActionRef   permit
   }

   #-------------------------------------------------------
   # IPSec-protected Zone C traffic:
   #    
   #    Enterprise Extender (ports 12000-12004)
   #    FTP Server - SubnetC to PublicServerAddressA
   #-------------------------------------------------------

   IpFilterRule                 Rule2C
   {
     IpSourceAddrRef            PublicServerAddressA1
     IpDestAddrRef              BranchOfficeGateway
     IpServiceRef               Enterprise-Extender
     IpServiceGroupRef          FTPServer
     IpGenericFilterActionRef   ipsec
     IpDynVpnActionRef          Gold-TunnelMode
   }
}


KeyExchangeRule              ZoneC_KeyExRule1
{
  LocalSecurityEndpointRef   Public_IKED
  RemoteSecurityEndpointRef  ZoneC_IKED
  KeyExchangeActionRef       Gold-PSK
  PresharedKey               abracadabra
}