CGNAT とは｜ポート開放できない理由とセキュリティ運用への影響

はじめに

「ルーターでポート開放を設定したのに、外部からまったくアクセスできない」「WAN 側の IP アドレスを確認したら 100.64.x.x という見慣れないアドレスだった」。この状況に遭遇したら、原因は CGNAT（Carrier-Grade NAT、キャリアグレード NAT） である可能性が高いと考えられます。

CGNAT は、ISP が 1 つのグローバル IPv4 アドレスを複数の契約者で共有させるために、ISP 側のネットワークで行う NAT です。『NAT とは｜変換テーブルの仕組みと NAPT・IP マスカレードの違い』で解説した NAT の性質が、契約者の手の届かない場所（ISP のネットワーク内）で発生する ことが、この技術の本質的な難しさを生みます。

本記事では、CGNAT の仕組み（NAT444 の二重構造、RFC 6598 の共有アドレス空間）から、ポート開放ができない理由、そして見落とされがちな セキュリティ運用への影響（IP ベースのアクセス制限が機能しない、インシデント調査でログから個人を特定できない）までを解説します。一次資料として RFC 6888（CGN の共通要件）・RFC 6598（共有アドレス空間）を参照します。

なお、NAT・NAPT そのものの動作原理については、関連記事『NAT とは｜変換テーブルの仕組みと NAPT・IP マスカレードの違い』を参照してください。

先に結論を示すと、CGNAT 環境では契約者側でポート開放を行う手段は原則としてありません。変換を行っているのが自分のルーターではなく ISP の設備だからです。対処は「固定 IP アドレスのオプション契約」「PPPoE の併用」「VPN やリバースプロキシなど外部の公開点を経由する構成」のいずれかになります。また、セキュリティ運用の観点では、送信元 IP アドレスが個人・組織を一意に指し示さなくなる という点が、アクセス制限やインシデント調査の前提を崩します。

CGNAT とは（NAT444 の仕組み）

CGNAT は、RFC 6888 で「複数の契約者間で同じ IPv4 アドレスを共有するために使われる、NAT ベースの論理機能」として定義されています。

参考: RFC 6888 – Common Requirements for Carrier-Grade NATs (CGNs)
“A NAT-based logical function used to share the same IPv4 address among several subscribers. A CGN is not managed by the subscribers”
（複数の契約者間で同一の IPv4 アドレスを共有するために使用される、NAT ベースの論理機能。CGN は契約者によって管理されません）
https://www.rfc-editor.org/rfc/rfc6888.html

定義の後半、「契約者によって管理されない」 という一文が、この技術のすべての制約の出発点です。同じ RFC は、”carrier-grade” という語が NAT の品質を意味するものではなく、NAT が ISP のネットワーク内に配置されるという位置関係を示す修飾語 であるとも補足しています。

なぜ CGNAT が必要とされるのか（IPv4 枯渇と ISP 側の事情）

ハブ記事で解説した通り、IPv4 アドレスの枯渇に対する最初の対策が「プライベートアドレス＋ NAT」でした。しかしこの方式では、契約者 1 件につき 1 つのグローバル IPv4 アドレスが必要 です。契約者数の増加とアドレス在庫の枯渇が進むと、この前提自体が維持できなくなります。

CGNAT は、この問題に対する ISP 側の解です。契約者宅のルーターにはグローバルアドレスを配らず、ISP 内部でのみ有効なアドレスを割り当て、ISP の設備（CGN）でさらに NAT を行って、少数のグローバルアドレスを多数の契約者で共有 します。RFC 6888 も、IPv4 アドレスの不足を背景に、多くの ISP が 1 つのパブリック IPv4 アドレスを多数の契約者で共有するサービスを提供したいと考えることが予想される、と述べています。

NAT444 という二重 NAT の構造

CGNAT 環境では、パケットが 2 回 NAT される ことになります。この構造は、IPv4 → IPv4 → IPv4 と 3 つの IPv4 領域を経由することから NAT444 と呼ばれます。

図の点線枠が示す通り、契約者が設定を変更できるのは 1 回目の NAT（自宅・自社のルーター）までです。2 回目の NAT は ISP の設備で行われており、契約者側から変換ルールを追加することはできません。これが、次の章で解説する「ポート開放ができない」という制約の根本原因です。

RFC 6598 共有アドレス空間（100.64.0.0/10）

CGNAT 環境で契約者ルーターの WAN 側に割り当てられるアドレスには、RFC 6598 が定義する 共有アドレス空間（Shared Address Space） が使われます。

参考: RFC 6598 – IANA-Reserved IPv4 Prefix for Shared Address Space
“IANA has recorded the allocation of an IPv4 /10 for use as Shared Address Space. The Shared Address Space address range is 100.64.0.0/10”
（IANA は、共有アドレス空間として使用する IPv4 の /10 の割り当てを記録しました。共有アドレス空間のアドレス範囲は 100.64.0.0/10 です）
https://datatracker.ietf.org/doc/html/rfc6598

範囲は 100.64.0.0 〜 100.127.255.255 の約 400 万アドレスです。WAN 側の IP アドレスがこの範囲にあれば、その回線は CGNAT 配下にあると判断できます。切り分けの第一歩として覚えておく価値のあるレンジです。

ここで疑問になるのが、「なぜ既存のプライベートアドレス（RFC 1918）を使わなかったのか」という点です。理由は アドレスの衝突 にあります。ISP が CGN と契約者ルーターの間に 192.168.0.0/16 や 10.0.0.0/8 を使うと、契約者が家庭内・社内で使っているアドレスと重複する可能性が高く、ルーティングが破綻します。

参考: RFC 6598 – IANA-Reserved IPv4 Prefix for Shared Address Space
“Shared Address Space is distinct from RFC 1918 private address space because it is intended for use on Service Provider networks”
（共有アドレス空間は、サービスプロバイダーのネットワークでの使用を意図しているため、RFC 1918 のプライベートアドレス空間とは区別されます）
https://www.rfc-editor.org/rfc/rfc6598.html

この衝突を避けるために、ISP 専用の中立的なアドレス帯として 100.64.0.0/10 が予約されました。このレンジは ISP 用であり、企業や家庭の内部ネットワークで使うべきではありません。社内ネットワークの設計でこのレンジを流用すると、CGNAT 配下の回線や一部の VPN 製品（Tailscale などがこのレンジを使用します）と衝突するリスクがあります。

CGNAT がもたらす制約

CGNAT の構造上の制約は、すべて前章で確認した「2 回目の NAT を契約者が管理できない」という一点から導かれます。ここでは、実務で問題になる 3 つの側面を整理します。

ポート開放ができない理由

ハブ記事で解説した通り、外部からの新規通信を内部へ届けるには、通信より先に変換テーブルへ恒久的なエントリを用意しておく（静的 NAT・ポート開放）必要があります。

CGNAT 環境では、この静的エントリを 2 つの NAT の両方に用意しなければなりません。

1. 契約者宅のルーター: ポート開放の設定が可能です。
2. ISP の CGN: 契約者は設定できません。

つまり、契約者宅のルーターでどれだけ正しくポート開放を設定しても、その手前にある CGN の段階でパケットが破棄されるため、外部からの通信はルーターまで到達しません。「設定は合っているのに繋がらない」という切り分けの難しい事象になるのは、この二重構造が原因です。

WAN 側の IP アドレスが 100.64.x.x である、あるいは外部サイトで確認したグローバル IP とルーターの WAN 側 IP が一致しない場合、CGNAT 配下にあると判断できます。この場合、ルーター側の設定を見直しても解決しません。対処は最終章で解説します。

NAT 越え（穴あけ）成功率の低下

ポート開放と並んで影響を受けるのが、NAT 越え（NAT traversal）です。関連記事『NAT 越えの仕組み｜STUN・TURN・ICE と NAT タイプの関係』で解説した通り、VoIP・オンラインゲーム・P2P アプリケーションは、STUN による穴あけで NAT の内側同士の直接通信を確立します。

CGNAT 環境では、この成功率が低下します。理由は 2 つあります。

NAT が二重になることで、穴あけの前提が複雑になる

STUN で得られるのは CGN 変換後のアドレスですが、そこへ届いたパケットが CGN で正しく契約者ルーターへ、さらに端末へと折り返される必要があります。

CGN の実装がシンメトリック NAT 相当の挙動をする場合、穴あけは原理的に失敗する

RFC 6888 は CGN に対して、同一の内部アドレスに紐づくすべてのセッションで同じ外部 IP アドレスのマッピングを使うことを求めていますが、ポート単位のマッピング挙動は実装によって差があります。

オンラインゲームのコンソールが表示する「NAT タイプ: 厳格」という判定の背景に CGNAT があるケースは少なくありません。この場合、宅内ルーターの設定変更では改善せず、回線契約側での対処が必要 になります。

日本の IPoE 方式（MAP-E / DS-Lite）との関係

日本の光回線で普及している IPoE（IPv4 over IPv6）は、方式によって CGNAT との関係が異なります。実務上、この違いの理解が対処の分岐点になります。

DS-Lite（transix、クロスパス、v6 コネクト等）

IPv4 の NAPT を ISP 側の設備（AFTR）で行う方式です。構造的に CGNAT そのもの であり、契約者側でポート開放を行う手段はありません。

MAP-E（v6 プラス、OCN バーチャルコネクト等）

NAPT を契約者側のルーター（CE）で行う方式です。1 つのグローバル IPv4 アドレスを複数の契約者で ポート番号の範囲で分割して共有 します。ISP 側での動的な NAT は行われませんが、利用できるポートが機械的に割り当てられた範囲に限定される ため、80 番・443 番といった標準ポートでの公開はできません。

MAP-E は「CGNAT ではないがアドレスは共有している」という中間的な位置づけです。割り当てられたポート範囲内であればサーバー公開が可能 という点が DS-Lite との決定的な違いであり、外部公開の要件がある場合は方式の選択が重要になります。

各方式の詳細（ポート数の割り当て、対応機種、セッション不足の対処など）は、関連記事『IPoE（MAP-E・DS-Lite）の仕組みと PPPoE との違い｜方式の選び方と機種対応』で解説しています。

なお、これらの方式では ヘアピン NAT（内部から自分のグローバル IP 宛への折り返し）も利用できない場合があります。YAMAHA の公式ドキュメントでは、MAP-E の IP アドレス共有契約および DS-Lite の環境で、ヘアピン NAT 機能を利用できないことが明記されています。詳細は関連記事『ヘアピン NAT とは｜内部からグローバル IP でアクセスできない原因と対処』を参照してください。

セキュリティ運用への影響

CGNAT の議論は「ポート開放ができない」という個人利用者向けの話題に偏りがちですが、セキュリティ運用の観点では、より根深い問題を引き起こします。1 つのグローバル IP アドレスの背後に数十〜数百の契約者がいるという状態は、「送信元 IP アドレスは通信相手を識別する手がかりになる」という、長年の運用が前提としてきた考え方を崩します。

IP アドレスによるアクセス制限が機能しなくなる

送信元 IP アドレスによるアクセス制限（許可リスト・拒否リスト）は、実務で広く使われる基本的な制御手段です。CGNAT は、この両方向に影響します。

許可リスト（アクセスを許可する側）の問題

「特定の拠点・在宅勤務者の IP アドレスからのみ管理画面へのアクセスを許可する」という設計は、その回線が CGNAT 配下にある場合、意図せず同じグローバル IP を共有する無関係の契約者すべてを許可する ことになります。共有相手が誰であるかを利用者は知ることも制御することもできません。

さらに、CGNAT のグローバル IP アドレスは ISP 側の都合で変わり得るため、許可リストに登録した IP アドレスが予告なく別の契約者に割り当てられる 可能性もあります。在宅勤務環境やモバイル回線からのアクセスを IP アドレスで制限する設計は、CGNAT 環境では成立しないと考えるのが安全 です。VPN や証明書ベースの認証など、IP アドレスに依存しない手段への置き換えが推奨されます。

拒否リスト・レート制限（アクセスを遮断する側）の問題

逆に、攻撃元の IP アドレスをブロックする、あるいは IP アドレス単位でレート制限をかける運用も影響を受けます。1 つの IP アドレスをブロックすると、その背後にいる無関係の多数の利用者まで巻き添えで遮断されます。

ログイン試行回数の制限やボット対策で IP アドレス単位のしきい値を設定している場合、CGNAT 配下の多数の正当な利用者が、合算されたアクセス数によってしきい値に達してしまう という事象も起こります。IP アドレス単位の制御は、CGNAT の普及により、かつてほど信頼できる粒度ではなくなっています。

インシデント調査でのログの限界

インシデント発生時、サーバーのアクセスログに残った送信元 IP アドレスから発信元を特定する、という調査手順は基本中の基本です。CGNAT 環境では、この IP アドレスが数百人の契約者を指し示す可能性があります。

RFC 6888 も、CGN 管理者が濫用に対処するために契約者を特定する必要が生じる場合があると述べた上で、その困難さを指摘しています。

参考: RFC 6888 – Common Requirements for Carrier-Grade NATs (CGNs)
“It may be necessary for CGN administrators to be able to identify a subscriber based on external IPv4 address, port, and timestamp”
（CGN 管理者は、外部 IPv4 アドレス、ポート、タイムスタンプに基づいて契約者を特定できる必要が生じる場合があります）
https://www.rfc-editor.org/rfc/rfc6888.txt

重要なのは、「IP アドレス」だけでは足りず、「ポート番号」と「タイムスタンプ」の 3 点が揃って初めて特定が可能になる という点です。これは、被害者側（サービス提供者側）の運用にも直接影響します。

• アクセスログに送信元ポート番号を記録していないシステムは、CGNAT 配下からのアクセスについて発信元を追跡できません。多くの Web サーバーのデフォルトのログ設定では、送信元ポートは記録されません。
• 時刻の正確性が決定的に重要になります。CGN の変換エントリは短時間で再利用されるため、サーバー側とキャリア側の時刻がずれていると、別の契約者を指し示してしまう可能性があります。NTP による時刻同期の徹底が、単なるベストプラクティスではなく 追跡可能性の前提条件 になります。

インシデント対応・フォレンジックの体制を設計する際は、「送信元 IP アドレス＋送信元ポート＋正確なタイムスタンプ」をログに残す ことを要件に含めることが推奨されます。

CGNAT のログ保持要件（RFC 6888）

ISP 側から見ると、CGNAT の運用は膨大なログ保持のコストを伴います。セッション単位で「いつ、どの契約者に、どの外部アドレスとポートを割り当てたか」を記録すると、ログ量は現実的でない規模に膨れ上がります。

RFC 6888 が推奨する解決策が、ポートブロック単位での割り当てとログ記録 です。セッションごとにポートを 1 つずつ動的に割り当てるのではなく、契約者ごとに一定範囲のポート（ブロック）をまとめて割り当てることで、ログはブロックの割り当て・解放の記録だけで済み、ログ量を大幅に削減できます。

この仕組みは、本ブログの機器別記事でも登場しています。FortiGate の IP Pool における PBA（Port Block Allocation）タイプは、まさにこの考え方の実装です。詳細は関連記事『FortiGate NAT 設定の手順｜VIP と IP Pool の使い分けと確認コマンド』で解説しています。

サービス提供者側の視点で押さえておきたいのは、CGNAT 環境からのアクセスについて発信元の開示を求める場合、ISP 側にログが残っている期間内に、正確な情報（IP・ポート・時刻）を揃えて照会する必要がある という点です。ログの保持期間は ISP の方針・法令によって異なるため、インシデント発生時の迅速な対応が求められます。

実務での対処

CGNAT 環境で外部公開や NAT 越えが必要になった場合、契約者側で取れる選択肢を整理します。契約者宅のルーターの設定変更では解決しない ことが前提となるため、対処は「回線契約の変更」と「構成の変更」の 2 系統に分かれます。

対処 1: 固定 IP アドレスのオプションを契約する（最も確実）

多くの ISP が、専有のグローバル IPv4 アドレスを提供する固定 IP オプションを用意しています。このオプションを契約すると CGNAT の配下から外れ、すべてのポートを自由に使えるようになります。MAP-E 環境における固定 IP オプションでも同様に、ポート数の制限が解除されます。

外部公開が業務要件である場合、追加費用はかかりますが最も確実で構成もシンプルです。回線の切り替え作業が発生する場合があるため、事前に ISP へ確認することが推奨されます。

対処 2: PPPoE を併用する

IPoE（MAP-E / DS-Lite）を利用しつつ、外部公開が必要な通信だけを PPPoE 接続経由にする構成です。PPPoE では従来通りグローバル IPv4 アドレスが払い出され、任意のポートを開放できます。

日常のインターネットアクセスは IPoE の速度メリットを享受しつつ、サーバー公開・VPN 終端だけを PPPoE 側に寄せる、という使い分けが可能です。ただし、ルーターが 2 つの経路を同時に扱い、通信を振り分ける設計（ポリシールート等）が必要 になり、構成の複雑さは増します。

対処 3: 外部の公開点を経由する（VPN・リバースプロキシ・トンネルサービス）

回線契約を変えずに済む方法として、グローバルアドレスを持つ外部の拠点を経由して公開する 構成があります。

• クラウド上に VPS を用意し、拠点から VPN やトンネルを張って、VPS 側で外部公開する。
• リバースプロキシ型のサービス（Cloudflare Tunnel などの、内側から外向きに接続を確立してトンネルを維持するタイプ）を利用する。

いずれも、内側から外向きに通信を開始することで NAT の変換テーブルにエントリを作り、そのセッションを維持し続ける という発想です。ハブ記事で解説した「エントリは内側からの通信で作られる」という原理を逆手に取った構成であり、CGNAT の制約を構造的に回避できます。ただし、経由する外部サービス・拠点の可用性とコストが新たな考慮事項になります。

対処 4: 制限を前提とした設計に切り替える

そもそも「外部から自宅・自社へ着信する」構成をやめる、という判断も現実的な選択肢です。ファイル共有はクラウドストレージへ、リモートアクセスはゼロトラスト型のサービスへ、といった置き換えにより、ポート開放そのものを不要にできます。CGNAT 環境が今後さらに広がることを踏まえると、着信を前提としない設計への移行は、長期的にはコストの低い選択 になり得ます。

サービス提供者側の対処

前章で解説した通り、サービスを提供する側にも対応が必要です。要点は以下の通りです。

• IP アドレス単位のアクセス制限・レート制限は、CGNAT 環境の利用者を巻き添えにする前提で設計する。可能であれば認証情報・セッション単位の制御へ移行する。
• アクセスログに送信元ポート番号を記録し、NTP による正確な時刻同期を維持する。CGNAT 配下からのアクセスを追跡できる唯一の手段です。

まとめ

本記事では、CGNAT（キャリアグレード NAT）の仕組みを NAT444 の二重構造から整理し、ポート開放ができない理由と、セキュリティ運用への影響を解説しました。契約者から見れば「手の届かない場所で NAT が行われている」こと、サービス提供者から見れば「IP アドレスが利用者を一意に指さない」ことが、それぞれの立場で押さえるべき本質です。

• CGNAT は ISP 側で行う NAT であり契約者は管理できない
• WAN 側が 100.64.0.0/10 なら CGNAT 配下と判断できる
• 契約者側でポート開放を行う手段は原則としてない
• DS-Lite は構造的に CGNAT、MAP-E は割当ポート範囲内なら公開可能
• IP アドレス単位のアクセス制限は無関係の利用者を巻き添えにする
• 発信元の特定には IP・ポート・正確な時刻の 3 点が必要となる
• 対処は固定 IP 契約、PPPoE 併用、外部公開点の経由が中心

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