デスティネーションNAT(DNAT)を徹底解説:仕組み・iptables設定例・運用上の注意とトラブル対策

デスティネーションNAT(DNAT)とは何か

デスティネーションNAT(Destination NAT、以下DNAT)は、ネットワークアドレス変換(NAT)の一種で、受信パケットの「宛先情報(IPアドレスおよび/またはポート)」を書き換える技術です。一般的な用途は、インターネット側から来たパケットの宛先を、プライベートネットワーク内のサーバやサービスに振り向ける「ポートフォワーディング」や「リバースプロキシ/ロードバランサ」としての役割です。

DNATの位置づけと基本動作

  • どの段階で変換されるか:Linuxのnetfilterであれば、DNATは主にnatテーブルのPREROUTINGチェインで行われます。PREROUTINGはルーティング決定の前に処理されるため、変換後の宛先に基づいてその後のルーティングが決定されます。
  • 変換される情報:宛先IPアドレスだけでなく、宛先ポート(例:TCP/UDPポート)も書き換えることができ、ポート番号を別のポートにマッピングする「ポート変換」も可能です。
  • 対になる概念:ソース側を書き換えるものはSNAT(Source NAT)またはMASQUERADEと呼ばれます。多くの公開サービス構成では、外部→内部の到着にDNAT、内部→外部の送信にSNAT(あるいはPOSTROUTINGでのMASQUERADE)を組み合わせます。

代表的なユースケース

  • 家庭や企業でのポートフォワーディング(例:外部のTCP/80を内部のWebサーバ10.0.0.5:80へ転送)
  • ロードバランサ(フロントエンドの公開IPを複数バックエンドサーバに分配する)
  • DMZやプロキシを経由した内部サービス公開(外部IPを受けて内部に振り分け)
  • IPv4アドレス不足時の共有アドレスでのサービス公開(単一のグローバルIPで複数サービスに振り分け)

パケット処理フロー(Linux/netfilterを例に)

典型的な受信パケットの処理順序(簡略):

  • パケット到着 → PREROUTING(natテーブル)処理(ここでDNATが適用される)
  • ルーティング判定(変換後の宛先に基づく)
  • フォワードすべきならFORWARD(filterテーブル)でフィルタリング、ローカルならINPUTへ
  • 必要に応じて応答パケットが作られると、POSTROUTING(natテーブル)でSNAT/MASQUERADEが適用される

ポイントは、DNATが「ルーティングより前」に行われるため、変換結果に基づいてパケットが内部ネットワークに向かう点です。

具体的なコマンド例(iptables)

代表的なポートフォワーディングの例:

iptables -t nat -A PREROUTING -d 203.0.113.10 -p tcp --dport 80 -j DNAT --to-destination 10.0.0.5:80

同時に内部サーバからの応答を正しく戻すためにPOSTROUTINGでSNAT/MASQUERADEを設定する典型例:

iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE

注意点:上記のDNATを有効にしても、カーネルのフィルタリング(FORWARDチェイン)でパケット転送を許可しないと通信は成立しません。

ポート変換(Port Translation)とサービスの多重化

DNATはポート番号を書き換えられるため、1つのグローバルIPで複数ポートを使い分けて異なる内部サービスに振り分けることができます。たとえば、外部の203.0.113.10:8080を内部の10.0.0.5:80に、203.0.113.10:8443を10.0.0.6:443にそれぞれDNATする、といった構成です。

ロードバランシングとDNAT

軽量なL4ロードバランサ(IPVS、nftablesのmap、またはiptablesのstatisticモジュールなど)は、受信パケットのDNAT先をラウンドロビンやハッシュで複数のバックエンドに振り分けます。クラウド環境の「ロードバランサ」は内部的にDNATやプロキシ方式を用いることが多いです。

特殊なケース・注意点

  • ヘアピン(ループバック)NAT:内部ネットワークから公開IP経由で自分の内部サービスにアクセスするとき、DNATが期待通りに働かない場合があります。これを解決する「hairpin NAT(NATループバック)」の設定が必要です。LinuxではPOSTROUTINGでMASQUERADEやSNATを組み合わせ、適切なFORWARDルールを追加することで実現します。
  • プロトコルの特殊性:FTPのアクティブモードやSIP、IPsec(ESP)、PPTPなどはペイロード内にアドレス情報や動的ポートを含むため、単純なDNATではうまく動かないことがあります。これらはプロトコルアシスト(helper)やアプリケーションレベルのプロキシが必要になります。Linuxではconntrackのヘルパーやnf_conntrack_ftpなどが用意されていますが、近年はセキュリティ観点で自動的に有効にしないケースもあるため明示的な設定が必要です。
  • MTU/フラグメント:NAT機器がパケットサイズを変更する場合、経路MTUやフラグメントの扱いに注意が必要です。特にパケット検査/書き換えが行われるとフラグメント処理が複雑になります。
  • チェックサム再計算:IPヘッダやトランスポート層のポートを書き換えると、システムはIP/TCP/UDPチェックサムを再計算します。これには多少のCPUコストがかかります。

接続追跡(Connection Tracking)と状態の管理

DNATを施した接続はカーネルのコネクション追跡(conntrack)テーブルにエントリが作成されます。これにより、戻りパケットが元の接続に関連付けられ、正しい翻訳が行われます。conntrackエントリはタイムアウトを持ち、UDPやTCPの状態に応じて異なる保持時間が設定されます。大量の同時接続がある環境ではconntrackテーブルの枯渇(オーバーフロー)に注意が必要です。

セキュリティ上の考慮点

  • 公開IPで特定のポートをDNATすると、その内部ホストは外部からの直接的な攻撃対象になります。公開するサービスは最小限にし、WAFやIDS/IPS、アクセス制御リストで保護することが推奨されます。
  • ログの取得と追跡:DNAT後のログは内部IPで記録されることがあるため、どの外部IPがどの内部ホストへ来たかを追跡できるようログに対応する情報を残す運用設計が重要です。
  • ポリシーの一貫性:フィルタリング(FORWARDやINPUTのルール)とNATルールの整合性を保つこと。NATだけ設定してフィルタで拒否してしまうミスがよくあります。

トラブルシューティングの手順

  • iptables/nftablesのnatテーブルにDNATルールが存在するか確認する。
  • フォワード可能かどうか(filterテーブルのFORWARDルール)を確認する。
  • 内部サーバのデフォルトゲートウェイが正しいか、戻りパケットが正しい経路を通るかを確認する(SNATが必要なケースが多い)。
  • conntrackテーブルの状態を確認し、タイムアウトやテーブルサイズ不足がないかをチェックする(conntrack-toolsなど)。
  • プロトコルの問題であれば、パケットキャプチャ(tcpdump)で実パケットを確認する。ヘルパーが必要なプロトコルかどうかも検討。

IPv6との関係

IPv6の設計方針は「エンドツーエンドのアドレス性」を保持する方向であり、IPv6ネイティブ環境ではNAT(特にアドレス変換)は推奨されません(ただし運用上の理由でNAT66等を使う場合はあります)。一方で、IPv4-IPv6間の相互接続(NAT64など)や、特定の運用目的でのIPv6 NAT(NAT66)という技術は存在しますが、DNATそのものがIPv6世界でも使われるかはケースバイケースです。

クラウド/商用機器でのDNAT

多くのクラウドプロバイダや商用ファイアウォールは管理画面で「ポートフォワーディング」や「パブリックIPのマッピング(Elastic IP/NAT Gateway)」「ロードバランサのリスナー→バックエンド」などの機能を提供しており、これらは内部的にDNATやプロキシを使っています。クラウド上では、セキュリティグループやACLと合せて設定する必要があります。

まとめ(設計/運用のチェックリスト)

  • 公開すべきサービスだけを最小限公開すること。
  • DNATはPREROUTINGで行われ、ルーティング決定に影響することを理解すること。
  • 内部→外部の応答にSNAT(または適切なルーティング)が必要な場合が多いこと。
  • 特殊プロトコル(FTP/SIP等)やヘアピンアクセスには追加設定が必要であること。
  • conntrackテーブル、MTU、チェックサム再計算、ログの取得といった運用面を確認すること。

参考文献