UDPの冷たい現実：DNSとSyslogを殺すNATセッション管理の闇とチューニング極意
こんにちは。クラウドの底でうめき声を上げるパケットの群れに思いを馳せるのが日課のSRE、あるいはネットワークの深淵を覗き込むアーキテクトの皆さん。
私たちは普段、AWSの NAT Gateway や GCPの Cloud NAT を、あたかも「魔法の黒い箱」であるかのように扱っている。プライベートサブネットのインスタンスから外の世界へ向けてパケットを投げ捨てるだけで、いい感じにグローバルIPへ変換され、何事もなかったかのように通信が成立する――素晴らしい抽象化だ。
しかし、その「抽象化」の甘い蜜に酔いしれていると、本番環境の深夜、突発的なDNSの名前解決エラーや、監査ログのドロップという名の悪夢に叩き起こされることになる。
特に、UDPという「ステートレスな暴れ馬」を扱うとき、パブリッククラウドのNAT機構やLinuxカーネルのコネクション追跡（conntrack）は、私たちの予測を裏切る冷徹なルールで動いている。今回は、UDPプロキシとDNSフォワーディングにおけるNATセッション管理のメカニズムを解剖し、パケットロスを極限まで排除するための実践的なチューニング手法を紐解いていこう。
—
1. ステートレスの幻影：UDPトラフィックにおけるNATマッピングの生態系
TCPであれば、3ウェイハンドシェイクでセッションが確立され、FINやRSTによって綺麗に幕が下ろされる。NATデバイスやLinuxの netfilter は、このステートフルな遷移を見て「あ、この通信は終わったな」と判断し、ポートマッピング（NATエントリ）を速やかに解放できる。
だが、DNS（Port 53）やSyslog（Port 514）が好んで使うUDPはどうだろうか？
UDPは本質的にステートレスだ。パケットの送信元と宛先、ポート番号があるだけで、「今、会話が続いているのか、それとも終わったのか」をプロトコル自体は教えてくれない。ここに、クラウドのNATゲートウェイやKubernetesノードの kube-proxy（iptables / IPVS モード）が抱える構造的なジレンマがある。
タイムアウトという名の「忘却のアルゴリズム」
NATデバイスは、UDPパケットを初めて観測すると、プライベートIP/ポートとグローバルIP/ポートの対応関係をステートテーブルに記録する。問題は、「次にいつパケットが来るかわからないUDPセッションを、いつまでテーブルに保持し続けるべきか」という点だ。
各クラウドプロバイダやLinuxカーネルは、この保持期間（Idle Timeout）に独自のデフォルト値を設定している。
- AWS NAT Gateway: UDPのアイドルタイムアウトは一律 30秒。
- GCP Cloud NAT: デフォルトは 30秒だが、設定により1秒から最大3600秒まで変更可能。
- Linux Kernel (
nf_conntrack_udp_timeout): デフォルトでは通常 30秒（ストリーム状態によってはnf_conntrack_udp_timeout_streamの 120秒）。
この「30秒」という数字が、高負荷なDNSフォワーダーや、一定間隔（例えば60秒ごと）でしかメトリックやログを送らないSyslogクライアントにとって、いかに致命的であるかお気づきだろうか。
—
2. パケットロスと再送制御：NATエントリ消失が引き起こす沈黙の連鎖
ここで、典型的なトラブルシナリオを描いてみよう。
1. あるマイクロサービスが、内部のDNSフォワーダー（CoreDNSなど）を介して外部APIのドメインを名前解決した。
2. NATゲートウェイ上にUDPのNATエントリが作成される。
3. その後、35秒間、その宛先に対するDNSクエリが一切発生しなかった。
4. AWS NAT Gatewayはアイドルタイムアウトを検知し、容赦なくNATエントリを破棄（スロットから削除）した。
5. 36秒後、ふたたび同じサービスが別のドメインの逆引きや名前解決を行おうと、UDPパケットを送信した。
この瞬間、何が起きるか？
NATゲートウェイに到着したパケットの送信元IP/ポートの組み合わせは、もはや古いステートテーブルには存在しない。NATデバイスの挙動としては、新しいポートを割り当てて外へ流そうとするか、あるいはルーティング設定やセキュリティグループのステートによっては、「予期せぬパケット」として容赦なくドロップ（Drop）する。
クライアント側（アプリケーションやDNSライブラリ）は、タイムアウトするまで応答を待ち、その後リトライ（再送）を行う。このリトライによって初めて新しいNATエントリが作られ、通信が復旧する。
つまり、「アプリケーションは正常に動いているはずなのに、特定のタイミングで必ず数秒のレイテンシスパイクや名前解決エラーが発生する」という、インフラエンジニアの頭を悩ませる幽霊のような現象が完成するのだ。
—
3. 現場で使える実践的チューニング：Linuxカーネルとクラウドの設定最適化
この理不尽なタイムアウトとパケットロスを防ぐためには、レイヤーごとに適切なパラメータを叩き込む必要がある。
A. Linuxカーネル (netfilter / conntrack) のチューニング
もしあなたがKubernetesワーカーノードやベアメタルのルーター、あるいは独自に構築したNATインスタンスを管理しているなら、sysctl を用いてUDPのコネクション追跡タイムアウトを延長、あるいは適切に制御すべきだ。
以下の設定を /etc/sysctl.d/99-udp-nat.conf などに記述し、適用してほしい。
# デフォルトのUDPアイドルタイムアウトを60秒から120秒へ延長
# （※高トラフィック環境ではメモリ消費量とトレードオフになる点に注意）
net.netfilter.nf_conntrack_udp_timeout = 120
# ストリームを検出した場合（双方向通信を確認した場合）のタイムアウトを300秒へ
net.netfilter.nf_conntrack_udp_timeout_stream = 300
# コネクション追跡テーブルの最大サイズを拡大し、ハッシュ表溢れ（テーブルフルによるドロップ）を防ぐ
net.netfilter.nf_conntrack_max = 1048576
net.netfilter.ip_conntrack_max = 1048576設定を反映させるには、以下のコマンドを実行する。
sudo sysctl --systemB. パブリッククラウド（GCP Cloud NAT）でのタイムアウト調整
AWSのNAT GatewayはマネージドであるためUDPタイムアウト値（30秒）の変更は不可能だが、GCPのCloud NATであれば、ワークロードの特性に合わせて秒数をコントロールできる。
例えば、Google Cloud SDK (gcloud) を使って、特定のルーターのUDPタイムアウトを長めに設定するコマンドは以下の通りだ。
gcloud compute routers update my-nat-router \
--region=asia-northeast1 \
--udp-idle-timeout=120sこれにより、Syslogの送信間隔や、断続的に発生するDNSクエリのライフサイクルにNATの寿命を同調させ、セッションの不意な消滅を防ぐことが可能になる。
—
4. アーキテクチャからのアプローチ：UDPに依存しない設計へのシフト
いくらカーネルやクラウドのパラメータをいじっても、パブリックインターネットのどこかにある中間ルーターのNATタイムアウトまで制御することはできない。したがって、極限の信頼性を求めるシステムでは、UDPそのものの限界を見据えたアーキテクチャの選択が求められる。
1. DNS over TCP (DoT) / DNS over HTTPS (DoH) の採用
DNSを従来のUDP (Port 53) から、TCPベースのプロキシ、あるいはTLSでラップされたDoT/DoHに移行することは、ネットワーク信頼性の観点から非常に強力な解決策となる。
TCPであれば、セッションの生死が明確であり、キープアライブ（Keep-Alive）機構を維持することでNATエントリの自然消滅を防ぎやすい。さらに、暗号化によってパケットインスペクションやDNSハイジャックのリスクも軽減される。
2. アプリケーション層でのキープアライブとポーリングの最適化
もしカスタムのUDPプロキシやSyslogフォワーダーを自製している、あるいは運用しているならば、アプリケーション側から定期的に「ハートビート（空のパケットやステータス確認用パケット）」を送信し、NATセッションのタイマーを強制的にリセット（Refresh）する実装を取り入れるべきだ。
—
5. まとめ：パケットの「寿命」をデザインする
ネットワークのトラブルシューティングにおいて、最も恐ろしいのは「エラーログが出ないまま、パケットが静かに消え去る」現象だ。UDPプロキシやDNSフォワーディングにおけるNATセッションの管理不足は、まさにこのサイレントキラーの典型例と言える。
私たちが構築するインフラストラクチャは、単にコンテナを動かし、パケットをルーティングするだけではない。パケットが通過するすべてのレイヤーで「ステートがいつ生まれ、いつ消滅するのか」という時間軸（タイムライフ）を完全に把握し、デザインすることこそが、真のSRE、真のクラウドアーキテクトの仕事なのだ。
さあ、今夜は自宅の検証環境で tcpdump を立ち上げ、NATテーブルの瞬きを監視しながら、静かにコーヒーを味わうとしようか。
コメント