Blog

RTX1300をMAP-E環境で使う:NATテーブルの管理とポート枯渇対策

はじめに

こんにちは。H173です。

ヤマハルーター RTX1300使っていますか?
IPv4 over IPv6にネイティブ対応したルーターは海外ベンダー製品ではまだ少なく、エンタープライズ向けのRTX1300は貴重な存在です。
自宅で使用している方も少なくないのではないでしょうか。

今回は、RTX1300をMAP-E環境で使用する際のNAT設定について解説します。

MAP-E と NAT

IPv4 over IPv6の主要な方式としてDS-LiteやMAP-Eがあります。
いずれもIPv4アドレスを複数のユーザーで共有する方式ですが、利用可能ポート数に厳しい制約があるのが特徴です。

  • DS-Lite: VNE側の設備(AFTR)でNATを行う
  • MAP-E: エンドユーザー側のルーターでNATを行う

DS-Liteではエンドユーザー側でできることが限られますが、MAP-Eの場合はユーザー側で外側ポートをいかに効率よく使用できるかが重要になります。

ポートセービングIPマスカレード

ヤマハルーターにはポートセービングIPマスカレードという機能が搭載されています。 これは、従来のNAPTでは1つのセッションで1つの外側ポートを消費するところを、宛先IPアドレスおよび宛先ポート番号が異なれば、同じ外側ポートを再利用できるという機能です。
この変換方式はRFC 4787で定義されるAddress and Port-Dependent Mapping(APDM)を基本として、外側ポートの再利用を積極的に行う処理が加えられたものと考えられますが、本記事では詳しい解説は割愛します。

NATテーブルの状態を調べる

MAP-E 環境では外側ポートの枯渇問題が常に隣り合わせです。
ポート枯渇が発生する原因はさまざまあり、実利用環境でどのような通信が原因となって発生しているか調べる必要があります。

まず、NATテーブルの消費状況をクライアントごとに確認します。

show nat descriptor address

このコマンドで、特定のクライアントが異常にセッションを消費していないかを確認します。

さらに、以下のコマンドで現在の全セッションを出力して詳しく調査します。

show nat descriptor address [NATディスクリプタ番号] detail

出力されたリストの宛先IPとポートを見ることで、特定のアプリケーションが大量に通信している、DNSリクエストが滞留しているといった傾向に目星をつけることができます。

また、以下のconfigを投入することでアドレス変換の結果をSyslogに出力させることができます。

nat descriptor log on

※NATディスクリプタのログは大量に出力されるため通常はoffにしておくことを推奨します。

もし外側ポートの枯渇が発生している場合、以下のようなログが出力されます。これが出力されていたら対策必須です。

[NAT] Session was limited. Port is exhausted for [宛先IPアドレス]

ポート枯渇の例

ポート枯渇の原因は環境により様々ですが、代表的なパターンを紹介します。

1. UDP/IP通信の大量発生

もっとも典型的な原因です。 TCPと異なりUDPはコネクションレスであるため、通信終了の明確な合図がありません。そのため、ルーターはタイマーの時間切れまでそのNATエントリーを保持し続けます。

特に、最近のQUIC/HTTP3を使用するアプリケーションはUDPを多用します。これらが終了した後もエントリーが残り続け、新しい通信のためのポートが確保できなくなるケースです。

2. Short-livedコネクション

TCPであっても、短時間に接続・切断を繰り返す通信(Short-livedコネクション)は要注意です。RTX1300はデフォルト設定でTCPFINを60秒間保持します。秒間数回のリクエストが発生するような環境では、この終了待ちエントリーだけで数千セッションに達し、ポートを食いつぶすことがあります。

3. VPNやSASEエージェントの利用

盲点になりやすいポイントです。クライアントPCでVPNエージェントやSASEエージェントを使用している場合、ルーターから見ると全ての通信の宛先がVPNゲートウェイのIPひとつだけに見えてしまいます。

ヤマハルーターのポートセービングIPマスカレードは、宛先IPおよび宛先ポートが別ならポートを再利用できる仕組みでした。しかし、通信の宛先が全て同じゲートウェイを向いてしまうと、ポートの再利用ができなくなります。 結果として、MAP-Eの割り当てポート上限に達した時点で通信ができなくなります。

ポート枯渇対策

1.タイマーの調整

ポート枯渇を防ぐにはNATの消去タイマーの値を変更することが第一に挙げられます。RTX1300のデフォルト設定ではTCP/UDPともに900秒という非常に長い値が設定されています。特にUDPの900秒保持はRFC 4787の推奨値である300秒と比較しても過剰なため、まずはUDPの消去タイマーから調整するとよいです。

以下はUDPのNAT消去タイマーを300秒に設定する例です。

nat descriptor timer [NATディスクリプタ番号] protocol=udp 300

実際は60秒未満あるいはもっと短い値に設定しても問題がないケースも多いですが、極端に短くすると通信品質に影響が出る可能性があるため、外側ポートの使用率を見ながら調整することを推奨します。

2. 動作タイプの変更

ポートセービングIPマスカレードには動作タイプが存在します。デフォルトは2で、TCPパケットに対してのみ有効です。タイプを3にすると、UDPに対してもポートセービングIPマスカレードが有効になります。UDPパケットが原因でポート枯渇が発生する場合に有効です。

nat descriptor backward-compatibility 3

3. DoT/DoHの利用

NATテーブルを確認すると、UDP:53のエントリーが大量に残っているケースがよく見受けられます。 UDP:53のタイマー短縮も効果的ですが、クライアント側のアプローチとして DNS over TLS (DoT) やDNS over HTTPS (DoH) を有効にする方法があります。
DNS名前解決がUDP:53からTCP:443、TCP:853に移行するため、UDPタイマー待ちによるテーブルの無駄遣いを減らすことができます。

このように、ルーターの設定だけでなく、クライアント側から発生する通信内容を変更することでポートの節約に繋がる例もあります。

まとめ

コンシューマー向けルーターではブラックボックスになりがちなNATテーブルの状態確認やタイマーの設定変更ができる点は、RTX1300をはじめとするヤマハルーターの強みです。

タイマーのデフォルト値は過剰な値が設定されていますが、実利用環境にあわせて調整していくことで効率的で安定した運用が可能になります。

ニフティでは、
さまざまなプロダクトへ挑戦する
エンジニアを絶賛募集中です!
ご興味のある方は以下の採用サイトより
お気軽にご連絡ください!

ニフティに興味をお持ちの方は
キャリア登録をぜひお願いいたします!

connpassでニフティグループに
参加いただくと
イベントの
お知らせが届きます!