【入門編】 DNAT(Destination NAT)のメカニズムとパブリックサブネットでのインバウンド制御 – クラウド＆コンテナネットワーク実践ガイド

インターネットの「玄関」で何が起きている？DNATとインバウンド通信の仕組みを紐解く

こんにちは！クラウドの海を泳ぐSREの皆さん、そしてこれからインフラの冒険に出ようとしている新人の皆さん。

クラウド環境でサーバーを構築していると、「パブリックサブネット」に置いたサーバーに外からアクセスさせるために、「インターネットゲートウェイ」や「NATゲートウェイ」といった言葉に必ずぶつかりますよね。でも、「結局、外からの通信ってどうやってサーバーまで届いているの？」という疑問、一度は抱いたことがあるはずです。

今日は、そんなネットワークの「玄関」で起きている魔法のような仕組み、DNAT（宛先NAT）について、郵便配達のストーリーに例えて一緒に紐解いていきましょう！

—

1. 郵便配達でイメージする「DNAT」の役割

インターネットの世界では、データは「パケット」という小さな封筒に入れて運ばれます。

皆さんがAWSやGCPでパブリックIPアドレスを割り当てた時、インターネットから送られてくる手紙（リクエスト）は、まずクラウドの「玄関（インターネットゲートウェイ）」に届きます。

ここで重要なのがDNAT（Destination NAT）です。

なぜ宛先を書き換える必要があるのか？

実は、パブリックサブネットにあるサーバーが、必ずしもインターネットから見えている「グローバルIPアドレス」を自分のネットワークカード（NIC）に直接持っているとは限りません。クラウドのネットワークでは、仮想ネットワーク内の「プライベートIPアドレス」が実際のサーバーの住所として使われています。

宛先IP: 203.0.113.10（外から見た玄関の住所）
届け先: 10.0.1.5（クラウド内のサーバーの本当の部屋番号）

インターネットから来た手紙には「203.0.113.10宛」と書かれています。でも、サーバーの本当の部屋は 10.0.1.5 ですよね。そこでルーターやゲートウェイが、「あ、これは10.0.1.5さん宛の荷物だな！」と判断し、宛先の住所を書き換えて、正しい部屋まで転送してくれる。 これがDNATの正体です。

—

2. インバウンド制御の肝：セキュリティグループとACL

宛先を書き換えて届けるだけなら簡単ですが、インターネットは悪意のあるアクセスも飛び交う無法地帯です。そこで登場するのが「門番」の役割を果たす2つの仕組みです。

1. セキュリティグループ（ステートフルな門番）:
「誰から来たか」よりも「どの通信の返事か」を覚えています。一度許可した通信なら、帰り道はチェックなしで通してくれます。
2. ネットワークACL（ステートレスな門番）:
非常に厳格な門番です。行きも帰りも、毎回「リストに載っているか？」を確認します。

実務では、セキュリティグループで「80番（HTTP）や443番（HTTPS）のポートだけ通してね」というルールを設定するのが基本中の基本です。

—

3. 実践！AWSでインバウンド通信を許可する設定例

実際にAWSでインフラを構成する際、Terraformなどのコードでこの「門番」を設定するイメージはこんな感じです。

# セキュリティグループの設定例
resource "aws_security_group" "web_server_sg" {
  name        = "web-server-sg"
  description = "Webサーバーへのインバウンド通信を許可"
  vpc_id      = aws_vpc.main.id

  # HTTP (80) と HTTPS (443) のアクセスだけを世界中から許可する
  ingress {
    description = "HTTP from Internet"
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"] # 全世界からのアクセスを許可
  }

  ingress {
    description = "HTTPS from Internet"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  # 帰り道の通信はセキュリティグループが自動で許可してくれる（ステートフル）
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

このコードを書くことで、クラウドの基盤側が自動的に「このポート宛の通信が来たら、内部のサーバーへDNATして転送する」というルートテーブルやNATのルールを自動的に構成してくれます。

—

4. なぜ「NATゲートウェイ」と「DNAT」を混同してはいけないのか？

ここが初心者さんが一番迷いやすいポイントです！

NATゲートウェイ（SNAT）: サーバーから外へ出る通信（アウトバウンド）用。サーバーのプライベートIPを、外に出る時にグローバルIPへ書き換える役割。
DNAT（インバウンド）: 外からサーバーへ入る通信用。インターネットゲートウェイやロードバランサーが、外から来たパケットの宛先を内部サーバーへ書き換える役割。

「外に出る時はNATゲートウェイ、外から入る時はロードバランサー（ALB）やパブリックIP」と覚えておくと、トラブルシューティングの時に頭が混乱しませんよ。

—

最後に：ネットワークを「見る」力を養おう

現場でトラブルが起きたとき、パケットがどこで止まっているのかを調べるには tcpdump や VPCフローログ を活用するのが一番の近道です。

「本当にパケットは届いているのか？」
「DNATされた後の宛先IPは正しいか？」

これらを確認できるようになれば、あなたはもう一人前のインフラエンジニアです。ネットワークは目に見えないけれど、一つずつ丁寧に紐解いていけば、必ず論理的な答えが待っています。

この記事が、皆さんのクラウド構築の旅の少しでも支えになれば幸いです！また次回の技術解説でお会いしましょう。