ネットワーク障害事例～NATテーブル枯渇～

インフラテックソリューショングループのK.Kです。
今回は[NAT]＋[非対称ルーティング]構成に伴い発生する通信障害の事例をご紹介します。
※ネットワーク構成は紹介用に簡易的なものを作成しています。

ネットワーク構成

外部回線を送信元としたTCP通信を想定し、宛先はFirewallで設定されているアドレスとなります。

RouterにてStaticNAT（3.3.3.3⇒192.168.0.1）を設定しています。

通信断が発生

設計誤りでFirewall経由の戻り通信がRouter#2へ向いてしまう非対称ルーティングとなっている構成を想定します。

この状態で外部回線から絶え間なく新規TCP通信を発生させると、時間経過に伴い通信断が発生しました。

通信断の原因

直接原因はルータのNATテーブルエントリが増え続け、メモリ使用率の高騰により通信を捌けなくなることです。

続いて、なぜメモリ使用率が高騰するのかといった根本原因について説明します。

Ciscoルータのデフォルト値でのケースとなりますが、新規TCP通信が発生すると以下の流れでNATテーブルエントリとタイムアウト時間が遷移します。

(1) TCPパケットが検出されたらNATテーブルにエントリが作成され、タイムアウト60sのタイマーを開始します。
(2) TCP3ウェイハンドシェイクが完了すると、タイムアウトのタイマー残り時間から24hへ変更します。
(3) セッション終了(FIN)が検出されたらタイムアウトのタイマー残り時間を60sへ変更し、60s後エントリが削除されます。

対称ルーティングとなっている場合はFINをきっかけに60sでNATテーブルからエントリが削除されますが、

本構成の非対称ルーティングの場合は、(1),(2)まで成立した後(3)が発動するためのFINがFirewall配下のサーバから発生している場合はRouter#1にてFINを検知できません。

したがって、Router#1のNATテーブルにはタイムアウト時間24hで生成されたエントリが増え続けます。

すると、24h以内にメモリを逼迫させてしまう通信量が発生する場合はメモリ使用率が高騰し、通信断や機器の再起動が発生します。

対策

暫定対処としてはNATテーブルエントリのクリアや再起動が挙げられますが、あくまで一時的な処置となります。
根本的には非対称ルーティングであることが問題のため、戻りの通信におけるFWからのネクストホップをRouter#1へ向ける必要があります。

最後に

本ケースの場合、通信が発生してからある程度の時間が経過することで障害が発生するため、たちが悪いです。
特に本構成にサービス通信を切り替えた場合、切り替え直後は通信が正常に処理されていたからネットワークは被疑箇所ではないと決めてしまうと
障害調査に時間がかかります。

また、今回のケース以外にも通信ルートが非対称であることにより、通信が失敗するケースもあります。
参考事例

設計をするうえでは非対称ルーティングが発生しないように意識する必要があります。
設計は正しくても設定誤りによる非対称ルーティングが発生する可能性もあるため、
構築後の試験にて設計通りのルートを通っているか確認できるような試験内容を考える必要があります。
例えば接続後にPingが通ったからOKではなく、双方向からのTracerouteの結果を見て対称のルートを通っていることを確認できれば確実です。

最後までお読みいただき、ありがとうございました。