NAT ゲートウェイのユースケース - Amazon Virtual Private Cloud
プライベートサブネットからインターネットにアクセスする許可リストに含まれる IP アドレスを使用してネットワークにアクセスする重複するネットワーク間の通信を有効にする

NAT ゲートウェイのユースケース

次に、パブリック NAT ゲートウェイおよびプライベート NAT ゲートウェイのユースケースの例を示します。

プライベートサブネットからインターネットにアクセスする

パブリック NAT ゲートウェイを使用して、プライベートサブネット内のインスタンスがアウトバウンドトラフィックをインターネットへの送信を有効にすると同時に、インターネットからインスタンスへの接続の確立を防ぎます。

概要

次の図表は、このユースケースを示しています。アベイラビリティーゾーンが 2 つあり、それぞれのアベイラビリティーゾーンに 2 つのサブネットがあります。各サブネットのルートテーブルは、トラフィックのルーティング方法を決定します。アベイラビリティーゾーン A では、パブリックサブネットのインスタンスはインターネットゲートウェイへのルートを介してインターネットに到達できますが、プライベートサブネットのインスタンスにはインターネットへのルートがありません。アベイラビリティーゾーン B では、パブリックサブネットに NAT ゲートウェイが含まれており、プライベートサブネット内のインスタンスは、パブリックサブネット内の NAT ゲートウェイへのルートを介してインターネットに到達できます。プライベート NAT ゲートウェイとパブリック NAT ゲートウェイはどちらも、インスタンスの送信元プライベート IPv4 アドレスをプライベート NAT ゲートウェイのプライベート IPv4 アドレスにマッピングしますが、パブリック NAT ゲートウェイの場合、インターネットゲートウェイはパブリック NAT ゲートウェイのプライベート IPv4 アドレスを NAT ゲートウェイに関連付けられた Elastic IP アドレスにマッピングします。インスタンスに応答トラフィックを送信するとき、パブリック NAT ゲートウェイであってもプライベート NAT ゲートウェイであっても、NAT ゲートウェイはアドレスを元の送信元 IP アドレスに変換します。

パブリックサブネットとプライベートサブネット、NAT ゲートウェイ、およびインターネットゲートウェイを備えた VPC です。

アベイラビリティーゾーン A のプライベートサブネットにあるインスタンスもインターネットにアクセスする必要がある場合は、このサブネットからアベイラビリティーゾーン B の NAT ゲートウェイへのルートを作成することができます。または、インターネットアクセスを必要とするリソースが含まれる各アベイラビリティーゾーンに NAT ゲートウェイを作成することで、耐障害性を向上させることができます。図の例については、「例: プライベートサブネットにサーバーがある VPC および NAT」を参照してください。

ルーティング

以下は、アベイラビリティーゾーン A のパブリックサブネットに関連付けられたルートテーブルです。最初のエントリはローカルルートで、サブネット内のインスタンスがプライベート IP アドレスを使用して VPC 内の他のインスタンスとの通信を有効にします。2 番目のエントリは、他のすべてのサブネットトラフィックをインターネットゲートウェイに送信し、サブネット内のインスタンスのインターネットアクセスを有効にします。

デスティネーション ターゲット
VPC CIDR ローカル
0.0.0.0/0 internet-gateway-id

以下は、アベイラビリティーゾーン A のプライベートサブネットに関連付けられているルートテーブルです。エントリはローカルルートで、サブネット内のインスタンスはプライベート IP アドレスを使用して VPC 内の他のインスタンスとの通信を有効にします。このサブネットのインスタンスはインターネットにアクセスできません。

デスティネーション ターゲット
VPC CIDR ローカル

以下は、アベイラビリティーゾーン B のパブリックサブネットに関連付けられているルートテーブルです。最初のエントリはローカルルートで、サブネット内のインスタンスがプライベート IP アドレスを使用して VPC 内の他のインスタンスとの通信を有効にします。2 番目のエントリは、他のすべてのサブネットトラフィックをインターネットゲートウェイに送信し、サブネット内の NAT ゲートウェイのインターネットアクセスを有効にします。

デスティネーション ターゲット
VPC CIDR ローカル
0.0.0.0/0 internet-gateway-id

以下は、アベイラビリティーゾーン B のプライベートサブネットに関連付けられているルートテーブルです。最初のエントリはローカルルートで、サブネット内のインスタンスがプライベート IP アドレスを使用して VPC 内の他のインスタンスとの通信を有効にします。2 番目のエントリは、他のすべてのサブネットトラフィックを NAT ゲートウェイに送信します。

デスティネーション ターゲット
VPC CIDR ローカル
0.0.0.0/0 nat-gateway-id

詳細については、「ルートテーブルの使用」を参照してください。

パブリック NAT ゲートウェイのテスト

NAT ゲートウェイを作成してルートテーブルを更新したら、プライベートサブネットのインスタンスからインターネット上のリモートアドレスに対して ping を送信し、インスタンスがインターネットに接続できることをテストします。これを行う方法の例については、「インターネット接続をテストする」を参照してください。

インターネットに接続できる場合は、さらに以下のように、インターネットトラフィックが NAT ゲートウェイを介してルーティングされているかどうかをテストできます。

  • プライベートサブネットのインスタンスからのトラフィックのルートを追跡します。これを行うには、プライベートサブネットの Linux インスタンスから traceroute コマンドを実行します。出力で、NAT ゲートウェイのプライベート IP アドレスがホップのいずれか (通常は最初のホップ) に表示されます。

  • プライベートサブネットのインスタンスから接続すると、送信元 IP アドレスが表示されるようなサードパーティのウェブサイトやツールを使用します。送信元 IP アドレスとして NAT ゲートウェイの elastic IP アドレスが表示される必要があります。

これらのテストが失敗した場合は、NAT ゲートウェイのトラブルシューティング を参照してください。

インターネット接続をテストする

次の例は、プライベートサブネットのインスタンスからインターネットに接続できるかどうかをテストする方法を示しています。

  1. パブリックサブネットのインスタンスを起動します (これを踏み台ホストとして使用します)。起動ウィザードで、Amazon Linux AMI を選択し、インスタンスにパブリック IP アドレスを割り当てます。セキュリティグループルールで、ローカルネットワークの IP アドレス範囲からのインバウンド SSH トラフィック、およびプライベートサブネットの IP アドレス範囲へのアウトバウンド SSH トラフィックが許可されていることを確認します (このテストでは、インバウンドおよびアウトバウンド SSH トラフィックの両方に 0.0.0.0/0 を使用することもできます)。

  2. プライベートサブネットのインスタンスを起動します。起動ウィザードで、Amazon Linux AMI を選択します。インスタンスにパブリック IP アドレスを割り当てないでください。パブリックサブネットで起動したインスタンスの IP アドレスからのインバウンド SSH トラフィックとすべてのアウトバウンド ICMP トラフィックが、セキュリティグループのルールで許可されていることを確認します。パブリックサブネットのインスタンスの起動に使用したのと同じキーペアを選択する必要があります。

  3. ローカルコンピュータの SSH エージェント転送を設定し、パブリックサブネットの踏み台ホストに接続します。詳細については、「Linux または macOS の SSH エージェント転送を設定するには」または「Windows 用に SSH エージェント転送を設定するには」を参照してください。

  4. 踏み台ホストからプライベートサブネットのインスタンスに接続し、プライベートサブネットのインスタンスからインターネット接続をテストします。詳細については、「インターネット接続をテストするには」を参照してください

Linux または macOS の SSH エージェント転送を設定するには

  1. ローカルマシンから、認証エージェントにプライベートキーを追加します。

    Linux の場合は、次のコマンドを使用します。

    ssh-add -c mykeypair.pem

    macOS の場合は、次のコマンドを使用します。

    ssh-add -K mykeypair.pem

  2. -A オプションを使用してパブリックサブネットのインスタンスに接続して SSH エージェント転送を有効にし、インスタンスのパブリックアドレスを使用します。次に例を示します。

    ssh -A ec2-user@54.0.0.123
Windows 用に SSH エージェント転送を設定するには

Windows で利用可能な OpenSSH クライアントを使用するか、希望する SSH クライアント (PuTTY など) をインストールできます。

OpenSSH

「Getting started with OpenSSH for Windows」の説明に従って、Windows 用 OpenSSH をインストールします。次に、認証エージェントにキーを追加します。詳細については、「Key-based authentication in OpenSSH for Windows」を参照してください。

PuTTY

  1. 既にインストールされていない場合は、PuTTY のダウンロードページから Pageant をダウンロードしてインストールします。

  2. プライベートキーを .ppk 形式に変換します。詳細については、「Amazon EC2 ユーザーガイド」の「PuTTYgen を使用したプライベートキーの交換」を参照してください。

  3. Pageant を起動し、タスクバーの Pageant アイコン (非表示の場合があります) を右クリックして、[Add Key] を選択します。作成した .ppk ファイルを選択し、必要に応じてパスフレーズを入力して、[Open (開く)] を選択します。

  4. PuTTY セッションを開始し、パブリック IP アドレスを使用してパブリックサブネットのインスタンスに接続します。詳細については、「Linux インスタンスへの接続」を参照してください。[Auth] カテゴリで、必ず [Allow agent forwarding] オプションを選択し、[Private key file for authentication] ボックスは空のままにします。
インターネット接続をテストするには

  1. パブリックサブネットのインスタンスから、プライベート IP アドレスを使用して、プライベートサブネットのインスタンスに接続します。次に例を示します。

    ssh ec2-user@10.0.1.123

  2. プライベートインスタンスから、ICMP が有効なウェブサイトに対して ping コマンドを実行して、インターネットに接続できることをテストします。

    ping ietf.org
    PING ietf.org (4.31.198.44) 56(84) bytes of data.
64 bytes from mail.ietf.org (4.31.198.44): icmp_seq=1 ttl=47 time=86.0 ms
64 bytes from mail.ietf.org (4.31.198.44): icmp_seq=2 ttl=47 time=75.6 ms
...

    ping コマンドをキャンセルするには、Ctrl + C を押します。ping コマンドが失敗した場合は、「インスタンスがインターネットにアクセスできない」を参照してください。

  3. (オプション) 必要がなくなった場合は、インスタンスを終了します。詳細については、「Amazon EC2 ユーザーガイド」の「インスタンスの終了」を参照してください。

許可リストに含まれる IP アドレスを使用してネットワークにアクセスする

プライベート NAT ゲートウェイを使用することで、許可リストに含まれるアドレスのプールを使用して、VPC からオンプレミスネットワークへの通信を有効にすることができます。各インスタンスに許可リストの IP アドレス範囲から個別の IP アドレスを割り当てる代わりに、許可リストの IP アドレス範囲から IP アドレスを使用してプライベート NAT ゲートウェイ経由して、サブネットからオンプレミスネットワーク宛のトラフィックをルーティングできます。

概要

次の図表は、インスタンスが AWS VPN を介してオンプレミスリソースにアクセスする方法を示しています。インスタンスからのトラフィックは、仮想プライベートゲートウェイから VPN 接続を介して、カスタマーゲートウェイにルーティングされ、そしてオンプレミスネットワークの宛先にルーティングされます。ただし、宛先が特定の IP アドレス範囲 (100.64.1.0/28 など) からのトラフィックのみを許可するとします。これにより、これらのインスタンスからのトラフィックがオンプレミスネットワークに到達するのを防ぐことができます。

AWS VPN 接続を使用したオンプレミスネットワークへのアクセス。

次の図は、このシナリオの設定に重要なコンポーネントを示しています。VPC には、元の IP アドレス範囲に加え、許可された IP アドレス範囲があります。VPC には、プライベート NAT ゲートウェイを使用して許可された IP アドレス範囲のサブネットがあります。インスタンスからのオンプレミスネットワーク宛のトラフィックは、VPN 接続にルーティングされる前に、NAT ゲートウェイに送信されます。オンプレミスネットワークは、NAT ゲートウェイの送信元 IP アドレスが許可された IP アドレスの範囲のインスタンスからのトラフィックを受信します。

VPC サブネットからのトラフィックは、NAT ゲートウェイの IP アドレスを送信元アドレスとして使用し、プライベート NAT ゲートウェイを介してルーティングされます。

リソース

次のようにリソースを作成または更新します。

  • 許可された IP アドレス範囲を VPC に関連付けます。

  • 許可された IP アドレスの範囲から VPC にサブネットを作成します。

  • 新しいサブネット内にプライベート NAT ゲートウェイを作成します。

  • インスタンスでサブネットのルートテーブルを更新して、オンプレミスネットワーク宛てのトラフィックを NAT ゲートウェイに送信します。オンプレミスネットワーク宛てのトラフィックを、仮想プライベートゲートウェイに送信するプライベート NAT ゲートウェイを使用して、サブネットのルートテーブルにルートを追加します。

ルーティング

以下は、最初のサブネットに関連付けられているルートテーブルです。VPC CIDR ごとにローカルルートが存在します。ローカルルートにより、サブネット内のリソースは、プライベート IP アドレスを使用して VPC 内の他のリソースとの通信が有効化されます。3 番目のエントリは、オンプレミスネットワーク宛てのトラフィックを、プライベート NAT ゲートウェイに送信します。

デスティネーション ターゲット
10.0.0.0/16 local
100.64.1.0/24 ローカル
192.168.0.0/16 nat-gateway-id

以下は、2 番目のサブネットに関連付けられたルートテーブルです。VPC CIDR ごとにローカルルートが存在します。ローカルルートにより、サブネット内のリソースは、プライベート IP アドレスを使用して VPC 内の他のリソースとの通信が有効化されます。3 番目のエントリは、オンプレミスネットワーク宛てのトラフィックを、仮想プライベートゲートウェイに送信します。

デスティネーション ターゲット
10.0.0.0/16 local
100.64.1.0/24 ローカル
192.168.0.0/16 vgw-id

重複するネットワーク間の通信を有効にする

プライベート NAT ゲートウェイを使用して、重複する CIDR 範囲がある場合でも、ネットワーク間の通信を有効にできます。例えば、VPC A のインスタンスが VPC B のインスタンスによって提供されるサービスにアクセスする必要があるとします。

CIDR の範囲が重複する VPC が 2 つあります。

概要

次の図は、このシナリオの設定に重要なコンポーネントを示しています。まず、IP 管理チームは、重複できるアドレス範囲 (ルーティング不可能なアドレス範囲) と重複できないアドレス範囲 (ルーティング可能なアドレス範囲) を決定します。IP 管理チームは、ルーティング可能なアドレス範囲のプールから、アドレス範囲をリクエストに応じてプロジェクトに割り当てます。

各 VPC には、ルーティング不可能な元の IP アドレス範囲に加えて、IP 管理チームによって割り当てられたルーティング可能な IP アドレス範囲があります。VPC A には、プライベート NAT ゲートウェイを使用して、ルーティング可能な範囲からのサブネットがあります。プライベート NAT ゲートウェイは、サブネットから IP アドレスを取得します。VPC B には、Application Load Balancer を使用して、ルーティング可能な範囲からのサブネットがあります。Application Load Balancer は、サブネットから IP アドレスを取得します。

VPC A のルーティング範囲外のサブネットのインスタンスから VPC B のルーティング範囲外のサブネットのインスタンス宛のトラフィックは、プライベート NAT ゲートウェイを経由して送信され、 Transit Gateway にルーティングされます。Transit Gateway は、トラフィックを Application Load Balancer に送信します。これにより、Application Load Balancer は、トラフィックを VPC B のルーティング範囲外のサブネットのターゲットインスタンスの 1 つにルーティングします。Transit Gateway からアプリケーションロードバランサーへのトラフィックには、プライベート NAT ゲートウェイの送信元 IP アドレスが含まれます。そのため、ロードバランサーからのレスポンストラフィックは、プライベート NAT ゲートウェイのアドレスを宛先として使用します。レスポンストラフィックは Transit Gateway に送信され、プライベート NAT ゲートウェイにルーティングされます。これにより、VPC A のルーティング範囲外のサブネットにあるインスタンスに宛先が変換されます。

プライベート NAT ゲートウェイと Transit Gateway を使用した VPC では、重複する CIDR を使用する VPC 間の通信を有効にします。

リソース

次のようにリソースを作成または更新します。

  • 割り当てられたルーティング可能な IP アドレスの範囲を、それぞれの VPC に関連付けます。

  • ルーティング可能な IP アドレスの範囲から VPC A にサブネットを作成し、この新しいサブネットにプライベート NAT ゲートウェイを作成します。

  • ルーティング可能な IP アドレスの範囲から VPC B にサブネットを作成し、この新しいサブネットに Application Load Balancer を作成します。ロードバランサーのターゲットグループに、ルーティング範囲外のサブネットのインスタンスを登録します。

  • VPC 間を接続する Transit Gateway を作成します。ルート伝達は必ず無効にしてください。各 VPC を Transit Gateway に接続するときは、VPC のルーティング可能なアドレス範囲を使用します。

  • VPC A のルーティング範囲外のサブネットのルートテーブルを更新して、VPC B のルーティング可能なアドレス範囲宛てのトラフィックをすべてプライベート NAT ゲートウェイに送信します。VPC A のルーティング可能なサブネットのルートテーブルを更新して、VPC B のルーティング可能なアドレス範囲宛てのトラフィックをすべて Transit Gateway に送信します。

  • VPC B のルーティング可能なサブネットのルートテーブルを更新して、VPC A のルーティング可能なアドレス範囲宛てのトラフィックをすべて Transit Gateway に送信します。

ルーティング

以下は、VPC A のルーティング範囲外のサブネットのルートテーブルです。

デスティネーション ターゲット
10.0.0.0/16 local
100.64.1.0/24 ローカル
100.64.2.0/24 nat-gateway-id

以下は、VPC A のルーティング可能なサブネットのルートテーブルです。

デスティネーション ターゲット
10.0.0.0/16 local
100.64.1.0/24 ローカル
100.64.2.0/24 transit-gateway-id

以下は、VPC B のルーティング範囲外のサブネットのルートテーブルです。

デスティネーション ターゲット
10.0.0.0/16 local
100.64.2.0/24 ローカル

以下は、VPC B のルーティング可能なサブネットのルートテーブルです。

デスティネーション ターゲット
10.0.0.0/16 local
100.64.2.0/24 ローカル
100.64.1.0/24 transit-gateway-id

以下は、Transit Gateway のルートテーブルです。

CIDR Attachment ルートタイプ
100.64.1.0/24 VPC A のアタッチメント 静的
100.64.2.0/24 VPC B のアタッチメント 静的