なぜ自宅ではホームサーバーにアクセスできるのに、外出先からはできないのですか？

自宅でホームサーバーにアクセスできるのは、スマホ、ノートパソコン、サーバーが同じプライベートネットワーク内にあるからです。彼らはルーターを介して192.168.x.xのようなローカルIPアドレスで通信できます。 192.168.x.x, 10.x.x.x、またはローカルホスト名。

リモートアクセスは異なります。モバイルデータ、オフィスWi-Fi、または別のネットワークにいるとき、デバイスはこれらのプライベートアドレスを直接見ることができません。トラフィックはあなたのパブリックIPを見つけ、ISPを通過し、ルーターのNATとファイアウォールルールを越え、正しい内部デバイスに到達し、実際に待ち受けているサービスに届く必要があります。その経路のどこかが欠けていると、ローカルアクセスは成功してもリモートアクセスは失敗します。

ローカルアクセスとリモートアクセスは異なる経路を使います

よくある症状は単純です：あなたは 192.168.1.50:8080、NASの名前、Jellyfinのアドレス、または自宅のSSHターゲットなどで、それが機能します。ところが家を出てモバイルデータに切り替えると同じアドレスが使えなくなります。これは必ずしもサーバーが壊れているわけではありません。

自宅ではクライアントデバイスとホームサーバーは同じLAN上にあります。ルーターは内部デバイス間のトラフィックを移動させるだけで済みます。外部からは、まずパブリック向けのエンドポイントに到達し、ルーターが正しい内部サーバーにトラフィックを送るためのルールやプライベートアクセス方法が必要です。

ローカルアクセスはサービスが自宅ネットワークで稼働していることを証明しますが、インターネットから到達可能であることを証明しません。リモートでの失敗は通常、外部経路が欠落しているか、ブロックされているか、誤ってルーティングされているか、または直接公開より安全な設定になっていることを意味します。

あなたのホームサーバーはインターネットから到達できないプライベートIPを持っています

多くのユーザーは、自宅で使える同じアドレスに外部からアクセスしようとします。例えば 192.168.1.50 または server.localそのアドレスは自宅内では意味がありますが、インターネット上の公開先ではありません。

家庭内でよく使われるプライベートアドレス範囲は内部ネットワーク用に予約されています。RFC 1918では、10.0.0.0/8、172.16.0.0/12、192.168.0.0/16のようなアドレスブロックをプライベートインターネット用に定義しており、これがプライベートIPアドレスがローカルネットワーク内に留まる理由です。

外部からLANのIPを使おうとすると、設計上失敗します。リモートアクセスには別の経路が必要です：ポートフォワーディングを設定したグローバルIP、デバイスをプライベートネットワークに接続するVPN、または自宅から到達可能なエンドポイントへアウトバウンド接続を作るトンネルです。

NATとルーターのファイアウォールはデフォルトで着信トラフィックをブロックします

ホームサーバーは通常、特別な設定なしでインターネットにアクセスできます。アップデートのダウンロード、Dockerイメージの取得、時刻同期、外部APIの呼び出しが可能です。だから多くのユーザーは「サーバーは外に出られるのに、なぜ外からは入れないのか？」と疑問に思います。

理由は接続の方向にあります。NATは内部デバイスが会話を開始するときにうまく機能します。なぜならルーターは戻りのトラフィックの行き先を記憶できるからです。しかし、インターネット上の未知のデバイスがあなたのパブリックIPに新しい接続を開始すると、ルーターはどの内部デバイスが受け取るべきか自動的にはわかりません。

これはランダムな失敗ではなく有用な安全上のデフォルトです。ルーターはLANを不正な着信トラフィックから保護しています。リモートアクセスを許可するには、ポートフォワーディング、VPN、メッシュVPN、リバーストンネルなどの意図的な方法を選ぶ必要があります。

ポートフォワーディングは経路全体が正しい場合にのみ機能します

ポートフォワーディングは古典的な解決策ですが、経路のすべての部分が合致している場合にのみ機能します。サーバーIPが変わったり、サービスが別のポートで待ち受けていたり、サーバーファイアウォールがトラフィックをブロックしたり、ISPがトラフィックをルーターに届けなかったりすると、ルーターのルールだけでは不十分です。

動作するポートフォワードには、安定した内部サーバーIP、正しい内部サービスポート、正しい外部ポート、一致するルーターのルール、サーバーファイアウォールのルール、インターネットからの実際のパブリック経路が必要です。どれか一つでも間違っていると、リモートリクエストはアプリに届く前に止まることがあります。

ポートフォワーディングは、慎重に保護されたHTTPSサイトやゲームサーバーなど、インターネットからアクセスされることを意図した公開サービスに適しています。NASの管理パネル、パスワード認証のSSH、古いウェブアプリ、プライベートダッシュボードを公開する最初の選択肢としては通常適していません。

動的IPとDNSは以前は動作していた設定を壊すことがあります

リモートアクセスがある日は動作し、翌日は失敗することがあります。サーバーは変わっておらず、ルーターのルールも存在し、アプリも自宅で動作しています。その場合、パブリックアドレスが変わっている可能性があります。

多くの家庭用インターネット接続は動的なパブリックIPアドレスを使用しています。モデムの再起動、ISPのメンテナンス、リースの変更、再接続後、昨日使っていたパブリックIPはもう自宅を指していないかもしれません。ブックマークやドメインが古いアドレスを指していると、リモートアクセスは間違った場所に行きます。

長期的なリモートアクセスには、パブリックIPを覚えることに頼らないでください。ダイナミックDNSや安定したトンネルホスト名を使い、ルーター、NAS、ホームサーバーなど常にオンラインのデバイスでアップデーターを実行しましょう。

CGNATはポートフォワーディングがルーターに届かない可能性があることを意味します

CGNATは最も厄介な原因の一つで、ユーザーがすべて正しく設定しても失敗することがあります。サーバーはリッスンしており、ルーターのルールも正しく、ファイアウォールも開いているのに、外部からのテストでは閉じているかタイムアウトになります。

手がかりはルーターのWAN IPです。ルーターのWANアドレスが外部のIP確認サイトで表示されるパブリックIPと一致しない場合、ルーターは真のパブリックアドレスを持っていない可能性があります。RFC 6598は100.64.0.0/10のような共有アドレス空間を定義しており、これはキャリアグレードNATに関連付けられることが多く、キャリアグレードNATはトラフィックが家庭用ルーターに到達する前に着信アクセスをブロックすることがあります。

CGNATが経路にある場合、従来のポートフォワーディングでは問題を解決できないことが多いです。実用的な解決策は、ISPにパブリックIPを依頼する、メッシュVPNを使う、またはネットワーク内から外部に接続するリバーストンネルを使うことです。

サーバーファイアウォールやサービスのバインドがリモートトラフィックをブロックしている可能性があります

ルーターとISPの経路が正しい場合、次の問題はサーバー自体にあるかもしれません。Linuxのファイアウォールルール、Windowsファイアウォール、Dockerのポートマッピング、リバースプロキシ設定、またはアプリレベルのバインドアドレスが、トラフィックがマシンに到達した後でもブロックすることがあります。

Ubuntuのサーバーファイアウォールのドキュメントでは、どのサービスやポートが許可されているかを制御するファイアウォールツールの使い方が示されており、リモートアクセスのトラブルシューティング時にはサーバーファイアウォールルールを確認する必要があります。もう一つのよくある問題は、サービスが127.0.0.1のみにバインドされていることで、これはサーバー自身からの接続は受け入れますが他のデバイスからは接続できません。

サービスが正しいインターフェースとポートでリッスンしていることを確認してください。 127.0.0.1 はローカル専用です。 0.0.0.0 またはサーバーのLAN IPは、ファイアウォールやルーターの経路が許可していれば他のデバイスからのアクセスを可能にします。Dockerの場合は、コンテナのポートが実際にホストに公開されていることを確認してください。

ローカルホスト名はLAN外では機能しないことが多い

ホスト名も誤解を招くことがあります。家庭内では、 nas.local, homeserver.localルーターのデバイス名や内部DNSレコードは正常に機能することがありますが、外部からは同じ名前がまったく解決しないことがあります。

多くのローカル名はmDNS、NetBIOS、ルーターのDNS機能、または内部DNSサーバーによって処理されます。パブリックDNSはこれらの名前を自動的に認識しません。たとえドメインを所有していても、家庭内で使う内部アドレスと外部で使うパブリックアドレスは別々のDNS動作が必要な場合があります。

自宅で使える名前がリモートアクセス用の名前だと決めつけないでください。VPNで接続した後は内部名を使うか、外部からアクセスする場合は適切なパブリックDNS、DDNS、またはトンネルのホスト名を使いましょう。

ランダムな設定を直す前にアクセス方法を選びましょう

ユーザーがポートフォワーディング、UPnP、DDNS、ファイアウォール変更、VPNアプリ、リバースプロキシ、トンネルを一度に試すとリモートアクセスは混乱します。いくつかの変更後、どの設定が役立ち、どの設定がリスクを生んだのか分かりにくくなります。

よりクリーンなアプローチは、まず一つのアクセスモデルを選ぶことです。ポートフォワーディングは選択したインターネットトラフィックを直接内部サービスに送ります。VPNやMesh VPNはまずデバイスを認証し、その後プライベートLAN上にいるかのように振る舞わせます。リバーストンネルはホームサーバーからパブリックエンドポイントへのアウトバウンド接続を作成し、インバウンドポートがブロックされているかCGNATがある場合に有用です。

個人アクセスには通常、VPNまたはMesh VPNがより安全なデフォルトです。パブリックなウェブサイトやゲームサーバーにはポートフォワーディングやトンネルが適しています。CGNAT、アパートのネットワーク、または制限されたISPルーターの場合、トンネルやMesh VPNの方がルーターと戦うより現実的です。

VPNとMesh VPNは個人アクセスにおいてしばしば優れています

ほとんどのホームサーバーユーザーはパブリックサービスを運用しようとはしていません。彼らは外出先からNAS、Home Assistant、Jellyfin、SSH、ダッシュボード、ファイル、またはDockerアプリにアクセスしたいだけです。これらのサービスは通常、インターネット全体に公開する必要はありません。

VPNはまずプライベートな経路を作成し、その後デバイスがまるでLAN内にいるかのように内部サービスにアクセスできるようにします。WireGuardのクイックスタートは自宅ネットワークへのプライベートVPNアクセスの参考になります。Mesh VPNツールは同様の目的を持ちつつ、NATトラバーサル技術を加えて難しいネットワーク間でもデバイスを接続します。TailscaleのプライベートリモートアクセスのためのNATトラバーサルの説明は、直接のインバウンドアクセスが難しい場合でもなぜこれが機能するのかを示しています。

セキュリティ上の利点はシンプルです。プライベートサービスがインターネット上のすべてのスキャナーに公開されません。リモートデバイスは最初に認証され、その後内部IPやホスト名にアクセスします。1人または1家族の場合、複数のポートを開けるよりも通常はこれがより安全です。

着信ポートを開けない場合にリバーストンネルが役立ちます

CGNATの背後にいる場合、アパートのインターネットを使っている場合、制限されたルーターの背後でサーバーを持ち歩いている場合、またはISPが着信トラフィックをブロックしている場合、ポートフォワーディングは利用できないかもしれません。その場合、サーバーは外向きに接続を確立する必要があります。

リバーストンネルはまさにそれを行います。ホームサーバーがトンネルプロバイダーにアウトバウンド接続を開き、リモートクライアントはプロバイダーの公開エンドポイントを通じて接続します。Cloudflare Tunnelは着信ポートを開けずに使うリバーストンネルの一般的な例です。

これは非常に実用的ですが、信頼モデルを変えます。サードパーティのトンネルレイヤー、アカウントのセキュリティ、トンネルの設定、アクセスルールに依存することになります。考えなしにすべてのプライベートサービスを公開する手段としてではなく、意図的に使用してください。

ポートフォワーディングは必ずしも最初に試すべき安全な方法ではありません

最も簡単な考え方は「ポートを開ければ動く」というものです。それは正しい場合もありますが、弱いサービスを数分でインターネットにさらすことにもなりかねません。自動スキャナーは常に開いているSSH、ウェブ管理パネル、古いメディアサーバー、デフォルトパスワード、古いアプリを探しています。

サービスを公開しなければならない場合は、それを公共サービスとして扱いましょう。HTTPS、強力な認証、更新、ログ記録、最小権限アクセス、そして可能であればリバースプロキシやアクセス制御レイヤーを使用してください。NASの管理パネル、ルーターのUI、パスワードベースのSSH、またはローカルで動作しているだけの古いセルフホストアプリを公開しないでください。

あなたや家族だけがアクセスする場合は、VPNまたはメッシュVPNを最初の選択肢にすべきです。公開アクセスは例外であり、デフォルトのトラブルシューティング手順ではありません。

実践的なトラブルシューティングの順序

リモートアクセスの問題は、ランダムに設定を変更するのではなく、一方向に進むことで解決しやすくなります。まずLAN内から始め、次にルーター、ISP、DNS、そしてリモートクライアントへと進んでください。

まず、サーバーのLAN IPとサービスポートを確認します。次に、サービスが単ににバインドされていないことを確認します。 127.0.0.1サーバーファイアウォールを確認してください。ルーターが本物のパブリックWAN IPを持っているか、CGNATの背後にあるかを確認してください。選択したアクセス方法（ポートフォワーディング、VPN、メッシュVPN、トンネル）を確認し、実際の外部ネットワークからテストしてください。

ルーターがヘアピンNATをサポートしていることを知らない限り、同じ家庭用Wi-Fiからリモートアクセスをテストしないでください。最も確実なテストは、モバイルデータを使ったスマホ、別のネットワークのデバイス、または外部ポートチェックです。ログも重要です：サーバーログに接続試行が全く記録されていなければ、トラフィックはサーバーに届いていない可能性が高いです。

ホームサーバーのより安全なデフォルトはプライベートリモートアクセスです

ほとんどのホームサーバーのワークロードは本質的にプライベートです：個人ファイル、家族の写真、ダッシュボード、バックアップ、メディアライブラリ、Home Assistant、SSH、Dockerアプリ、内部メモなど。これらはリモートで便利ですが、通常は公開アクセスを必要としません。

プライベートリモートアクセスはデフォルトの境界を維持します。サーバーはLAN内に留まり、信頼できるデバイスはVPN、メッシュVPN、またはプライベートトンネルを通じて内部サービスに接続できます。これにより、公開されるサービスの数が減り、アクセスの管理が容易になります。

目標は単にサーバーにアクセス可能にすることではありません。目標は、正しい人が正しい経路を通じて、可能な限り小さい公開攻撃面でアクセスできるようにすることです。

このセットアップにおけるパーソナルサーバーの位置づけ

パーソナルサーバーは、常に稼働し、予測可能なLANアドレスを持ち、VPN、コンテナ、ダッシュボード、プライベートクラウドツール、メディアアプリ、または自動化スクリプトなどのサービスを実行できるため、良いリモートアクセスノードになり得ます。しかし、ハードウェアはネットワークの問題を解決しません。

リモートアクセスは依然として同じ経路に依存しています：プライベートIP、パブリックIP、NAT、ファイアウォール、DNS、ISPの挙動、および選択したアクセス方法です。安定したサーバーはセットアップを容易にしますが、公開されたサービスを自動的に安全にするわけではありません。

サーバーはサービスホストとして扱い、セキュリティ計画ではありません。セキュリティ計画はアクセス方法、認証、更新ポリシー、ファイアウォールルール、バックアップ戦略で構成されます。

まとめ

自宅ではサーバーが動作するのにリモートで動作しない場合、サーバー自体は問題ない可能性があります。ローカルアクセスはLAN経路が機能していることを示します。リモートアクセスにはパブリックIP、ルーターNAT、ファイアウォールルール、ISPの挙動、DNS、サービス設定を通る別の経路が必要です。

個人利用の場合、VPNやメッシュVPNはポートを直接公開するより安全です。パブリックサービスの場合はポートフォワーディングやトンネルが使えますが、強力な認証、HTTPS、更新、監視が必要です。まずアクセス方法を決めてから、経路を段階的にトラブルシュートしましょう。

よくある質問

なぜ自宅のサーバーはWi-Fiでは動作するのにモバイルデータでは動作しないのですか？

家庭のWi-Fiはローカルネットワークを使うため、プライベートIPアドレスやローカルホスト名が機能します。モバイルデータはLAN外なので、ルーター、ISP、ファイアウォール、DNS、VPN/トンネル設定を通るパブリック経路が必要です。

192.168.x.xを使ってサーバーにリモートアクセスできますか？

いいえ。以下のようなアドレスは 192.168.x.x と 10.x.x.x はプライベートLANアドレスです。VPNや他のプライベートアクセス方法を使わない限り、パブリックインターネットから直接アクセスできません。

ポートフォワーディングを設定したのに動作しないのはなぜですか？

サーバーのIPが変わった、サービスが別のポートで動作している、サーバーファイアウォールがブロックしている、サービスがlocalhostのみでリッスンしている、DNSが間違ったIPを指している、またはISPがCGNATを使用している可能性があります。

自分がCGNATの背後にいるかどうかはどうやってわかりますか？

ルーターのWAN IPと外部のIP確認サイトで表示されるパブリックIPを比較してください。一致しない場合やWAN IPが共有/プライベート範囲内の場合、ISPがCGNATを使用している可能性があります。

VPNはポートフォワーディングより優れていますか？

個人利用の場合は通常そうです。VPNやメッシュVPNはプライベートサービスをオープンなインターネットから守り、信頼できるデバイスが認証を通過してからホームネットワークにアクセスできます。

Cloudflare Tunnelや他のリバーストンネルはいつ使うべきですか？

インバウンドポートを開けない場合、CGNATがポートフォワーディングをブロックしている場合、またはルーターを直接公開せずにパブリックエンドポイントを作りたい場合はリバーストンネルを使用してください。アクセス制御は慎重に設定しましょう。

NASの管理パネルをインターネットに公開すべきですか？

いいえ。NASの管理パネルは基本的に非公開にしておくべきです。管理UIを直接パブリックインターネットに公開するのではなく、VPNやメッシュVPNアクセスを使用してください。

なぜ自宅ではドメインが機能するのに外出先では機能しないのですか？

ローカルホスト名、分割DNS、またはプライベートIPを指すレコードを使用している可能性があります。リモートアクセスには、デバイスが内部名を解決できるパブリックDNS/DDNS名、トンネルホスト名、またはVPN接続が必要です。