NATとポートフォワーディングの仕組み｜自宅・オフィスからサーバー公開までの通信経路

「自宅のPCで動かしているアプリを外から見せたいのに、ルーターのポート開放をしてもつながらない」「クラウドの“NATゲートウェイ”と家のルーターのNATは同じものなのか」。ネットワークの授業では習ったはずのNATですが、実際に自分でサーバーを公開しようとすると、どこで何が変換されているのかが見えずに詰まりがちです。

この記事では、プライベートIPとグローバルIPの関係から、ルーターが内部で持つNAPT変換テーブルの動き、ポートフォワーディングの設定手順とその危険性、CGNATのせいで公開できないケースの見分け方、そしてクラウドのNATゲートウェイやElastic IPが家庭用ルーターのどの機能に対応するかまでを順に解説します。IPアドレスやポート番号の基礎はエンジニアのためのネットワーク基礎を前提とします。

プライベートIPとグローバルIP：NATが必要になる理由

世界で一意なアドレスと、組織内だけで有効なアドレス

インターネット上で直接やり取りできるのはグローバルIPアドレス（パブリックIP）だけです。IPv4のアドレスは約43億個しかなく、とうの昔に枯渇しているため、家庭やオフィスの内部では「プライベートIPアドレス」を使い、外に出るときだけ1つのグローバルIPを共有します。プライベートIPとして予約されている範囲は次の3つです。

範囲	CIDR	アドレス数	よく使われる場面
10.0.0.0〜10.255.255.255	10.0.0.0/8	約1,677万	企業ネットワーク、クラウドVPC
172.16.0.0〜172.31.255.255	172.16.0.0/12	約104万	Dockerのデフォルトブリッジ、AWSデフォルトVPC
192.168.0.0〜192.168.255.255	192.168.0.0/16	約6.5万	家庭用ルーター、小規模オフィス

これらのアドレス宛てのパケットは、インターネット上のルーターでは転送されません。つまり、家のPCが192.168.1.10を持っていても、外からその番号を指定して届くことはありません。内側と外側の橋渡しをするのがNAT（Network Address Translation）で、家庭用ルーターは例外なくこの機能を持っています。

NAPT変換テーブル：ルーターの中で何が起きているか

IPアドレスだけでなくポート番号も書き換える

家庭やオフィスで使われているNATは、正確にはNAPT（Network Address Port Translation、IPマスカレードとも呼ばれます）です。単純にIPアドレスだけを1対1で置き換えるのではなく、ポート番号も同時に書き換えることで、複数の端末が1つのグローバルIPを共有できるようにしています。

たとえば、内側のPC（192.168.1.10）がブラウザからexample.com（203.0.113.5）の443番へ接続するとき、送信元ポートとしてOSは適当な番号（たとえば51000）を選びます。ルーターはこのパケットを外へ送る際、送信元を「自分のグローバルIP（198.51.100.20）：ルーターが選んだポート（たとえば40001）」に書き換え、同時に次のような対応表（変換テーブル）を記憶します。

内側アドレス:ポート      外側アドレス:ポート       宛先:ポート
192.168.1.10:51000  <->  198.51.100.20:40001  <->  203.0.113.5:443
192.168.1.11:51000  <->  198.51.100.20:40002  <->  203.0.113.5:443

example.comから返ってきたパケットは宛先が198.51.100.20:40001なので、ルーターは表を引いて192.168.1.10:51000へ書き戻して届けます。2台目のPCが偶然同じ51000番を使っても、外側のポートを変えて区別できるのがNAPTの肝です。この表のエントリは通信が終わるか、一定時間無通信になると消えます。

「内から外」は自動で通り、「外から内」は通らない

ここで重要なのは、変換テーブルのエントリは内側から外へパケットが出たときに初めて作られる点です。外から突然「198.51.100.20の8080番」宛てにパケットが来ても、対応する行がないためルーターは捨てるしかありません。これがサーバー公開を阻む理由であり、同時にNATが「外からの侵入を防ぐ簡易的な壁」として機能してきた理由でもあります。この壁に意図的に穴を開けるのがポートフォワーディングです。

ポートフォワーディングの設定手順と危険性

静的な変換ルールを事前登録する

ポートフォワーディング（ポート開放、静的NAT、仮想サーバーなどメーカーによって呼び名が異なります）は、「外側のポートXに来たパケットは、内側のこのIP:ポートへ転送する」というエントリを手動で固定登録する機能です。動的に作られる変換テーブルの前に、常に存在する行を1つ追加するイメージです。手順はどのルーターでも概ね次の流れになります。

1. 公開するサーバーの内側IPを固定する。DHCPのままだと再起動でIPが変わり、転送先がずれる。ルーターのDHCP予約（MACアドレスとIPの紐づけ）か、サーバー側の静的IP設定で固定する
2. サーバーでサービスが待ち受けていることを確認する。ss -tlnpで0.0.0.0またはサーバーのIPで該当ポートがLISTENしているかを見る。127.0.0.1だけで待ち受けていると転送されても応答できない
3. サーバー側のファイアウォール（ufw/firewalld）で該当ポートを許可する
4. ルーターの管理画面で「外側ポート → 内側IP:ポート、プロトコル（TCP/UDP）」を登録する。外側と内側のポートは同じでなくてもよい（外側8443→内側443など）
5. 外部から確認する。同じLAN内からグローバルIPを叩いても、ルーターによってはヘアピンNAT非対応で失敗するため、スマートフォンのテザリングなどLAN外の回線から試す

# サーバー側：待ち受けの確認（0.0.0.0 か LAN のIPで LISTEN していること）
ss -tlnp | grep ':8080'

# サーバー側：ファイアウォールの許可
sudo ufw allow 8080/tcp

# 自分のグローバルIPを確認（ルーターのWAN側IPと比較する）
curl -s https://ifconfig.me

# 外部の回線から到達確認
nc -zv 198.51.100.20 8080

ポート開放の危険性：開けた瞬間から世界中に見える

ポートを開放すると、そのサービスはインターネット上の誰からでも到達可能になります。グローバルIPは常時スキャンされており、SSH（22）やRDP（3389）、MySQL（3306）を開けると数分から数時間で総当たり攻撃のログが並び始めるのが普通です。ポート番号を変えるだけの対策はスキャナーには通用しません。開放する場合は最低限、SSHは公開鍵認証のみ・パスワード認証無効にし、DBやRedisなど認証の弱いサービスは決して直接開けないでください。SSHの鍵認証の設定はLinuxのSSH接続入門を参照してください。

そもそも本当にポート開放が必要かも検討に値します。外部からWebhookを受けたい、デモを見せたいといった一時的な用途なら、ルーターに触れずに内側から外へトンネルを張るngrokやCloudflare Tunnelの方が安全で手軽です。自宅からの常時公開なら、Cloudflare Tunnelのようなサービスを前段に置き、オリジンのポートは一切開けない構成が現実的です。

CGNATで公開できないケースの見分け方

ルーターの外側にもう1段NATがある

ポート開放を正しく設定したのに外から届かない場合、家のルーターの外側にさらにNATがある可能性を疑います。ISP側でグローバルIPを複数契約者で共有するCGNAT（Carrier-Grade NAT、大規模NAT）や、ONU（光回線の終端装置）にルーター機能が内蔵されていて自分のルーターと二重になっているケース（二重NAT）が典型です。上流のNATに変換テーブルを作ってもらう手段が自分にはないため、ポート開放は届きません。

見分け方はシンプルで、ルーターの管理画面に表示されるWAN側IPアドレスと、curl https://ifconfig.meで見える自分のグローバルIPを比べます。一致していれば自分のルーターがインターネットに直接面しています。WAN側IPが100.64.0.0〜100.127.255.255の範囲（CGNAT専用に予約された100.64.0.0/10）ならCGNAT確定、192.168.x.xや10.x.x.xなら手前に別のルーターがある二重NATです。

CGNAT環境での選択肢

CGNAT下でどうしても公開したい場合の選択肢は限られます。ISPに固定グローバルIPのオプションを申し込む、IPv6で公開する（IPv6にはNATがなく端末が直接グローバルアドレスを持てるため、ISPがIPv6を提供していれば有力な選択肢です）、あるいは前述のトンネルサービスやVPSを中継点にして内側から接続を張る方法です。二重NATであれば、ONU側のルーター機能を無効化（ブリッジモード）するか、ONU側でも同じポートを自分のルーター宛てに転送する二段の設定で解決できます。

クラウドのNATゲートウェイとの対応関係

家庭用ルーターの機能はクラウドではバラバラに提供される

クラウドのVPCでも考え方は同じですが、家庭用ルーターが1台で担っていた機能が別々のサービスに分かれています。対応関係を整理すると、AWSやGCPの構成図がぐっと読みやすくなります。

家庭・オフィスの機能	AWS	GCP	役割
ルーターのNAPT（内→外）	NATゲートウェイ	Cloud NAT	プライベートサブネットから外向きにだけ通信させる。外からは届かない
グローバルIPを1台に固定で割当	Elastic IP＋インターネットゲートウェイ	外部IPアドレス	1対1のNATで、外から直接到達可能
ポートフォワーディング	ロードバランサー（ALB/NLB）	Cloud Load Balancing	公開用の入口を1つ作り、内側の複数サーバーへ振り分ける
ルーターの簡易ファイアウォール	セキュリティグループ／NACL	VPCファイアウォールルール	到達可能なポートと送信元を制限する

クラウドのNATゲートウェイは「内から外だけ」の機能で、ポート開放に相当するものはありません。プライベートサブネットのサーバーを公開したいなら、NATゲートウェイをいじるのではなく、パブリックサブネットにロードバランサーを置いて転送するのが正解です。逆に「DBはプライベートサブネットに置き、パッケージ更新のためだけにNATゲートウェイ経由で外へ出す」という定番構成は、まさに家庭のNATと同じ「内から外は通す、外からは届かない」性質を利用したものです。各クラウドでの具体的な構築手順はAWS VPCのネットワーク設計入門とGCP VPCネットワーク設計入門にまとめています。

トラブル事例：ポート開放したのに外からつながらない

症状

自宅のミニPCで動かしている検証用Webアプリ（8080番）を、ルーターでポートフォワーディングして外部から見せようとした。LAN内の別PCからは192.168.1.10:8080で見えるが、スマートフォンの回線からグローバルIP:8080に接続するとタイムアウトする。

原因

ルーターの管理画面でWAN側IPを確認すると100.70.x.xだった。これはCGNAT用に予約された100.64.0.0/10の範囲で、ISP側でさらにNATされているため、自分のルーターのポート開放はそもそも届いていなかった。設定に誤りはなく、経路上の「もう1段のNAT」が原因だった。

対処

検証用途で固定IPの契約費用をかけたくなかったため、Cloudflare Tunnelをミニ PC上で起動し、内側から外へトンネルを張って独自ドメインで公開する構成に切り替えた。ルーターのポート開放は削除し、結果的にオリジンが一切露出しない安全な構成になった。恒久的に公開が必要な場合は、ISPのIPv6提供状況を確認して、IPv6で直接公開する案も検討している。

まとめ

NAT（NAPT）は、内側から出たパケットの送信元IPとポートを書き換え、その対応表を使って戻りのパケットを届ける仕組みです。表は内側からの通信で初めて作られるため、外からの接続は届かず、ポートフォワーディングはその表に固定の行を事前登録する操作だと理解できます。ポート開放は世界中に公開することと同義なので、認証の弱いサービスは開けない、可能ならトンネルサービスで代替するのが安全です。つながらないときはルーターのWAN側IPとifconfig.meの結果を比べ、CGNATや二重NATを疑ってください。クラウドではNATゲートウェイが「内から外」、Elastic IPやロードバランサーが「外から内」を担っており、家庭用ルーターの機能を分解したものとして対応づけると理解が早まります。サブネット設計に必要なCIDRの計算はサブネットマスクとCIDR表記の計算方法で解説しています。

オフィスやクラウドのネットワーク設計、サーバー公開の安全な構成についてお困りの際は、Harmonic Societyのシステム開発・インフラ支援にご相談ください。