インターネットなしでグローバル IP アドレスを使用することは可能ですか?

Question 1

それは絶対に可能です。IPV4 空間には魔法のようなものは何もなく、すべて同じように機能します。頭痛の種となるのは、このネットワークがインターネットに統合される何年も後のことです。

Answer

それは絶対に可能です。IPV4 空間には魔法のようなものは何もなく、すべて同じように機能します。頭痛の種となるのは、このネットワークがインターネットに統合される何年も後のことです。

Question 2

はい、可能ですが、推奨されません。

代わりに、RFC1918 で割り当てられたブロックと、できる限り小さなネットワークを使用する必要があります。少数のデバイスがあるホームネットワークでは、10.0.0.0/8 を使用しないでください。

詳細はhttps://www.rfc-editor.org/rfc/rfc1918およびその代替https://www.rfc-editor.org/rfc/rfc6761

目安としては、ネットワーク上で実行できるデバイスの最大数の 4 倍、または /24 (254 ホスト) のいずれか大きい方のネットワークサイズを使用することです。/24 ではサブネット化も簡素化されます。

したがって、10.yourstreetnumber.yourbirthyear.0 または 192.168.yourheightincm.0 を使用してください。創造性を発揮してください。

サイト間 VPN を作成する可能性がある場合は、172.16 から 31.0.0 までの範囲を候補として検討してください。これは、少し複雑であまり使用されていないためです。

既存のパブリック範囲を使用しないもう 1 つの理由は、DNS キャッシュによって、ネットワークを変更するデバイスが混乱する可能性があるためです。IE ラップトップ、電話、タブレットは、「dns.google.com」を 8.8.8.8 としてキャッシュし、LAN に接続すると、そのレコードを使用し続ける可能性があります。または、誰かが家に帰り、8.8.8.8 に解決される「fileserver.local」のホスト名が、レコードの TTL までキャッシュされる可能性があります。

愚かな IP 再利用の例 - VMware Workstation の時代に、ループバックインターフェイスに適用された 127.0.0.0/8 よりも具体的であるという理由で、127.99.99.0/24 を IP ネットワークとして使用しようとしました。

これは、VMware および Linux VM では完璧に機能しました。しかし、Windows (XP?) では、IP アドレスの最初のオクテットに 127 を入力するとすぐに「停止、いいえ」と表示されました。当時、DHCP 経由で IP を割り当てようとしたことはありませんでした。

意図しない結果が生じる可能性は非常に大きいです。

また、まれに、クラスフルネットワークが問題を引き起こすこともあります。私は以前、192.168.0.0/16 のネットワークを運用していましたが、このネットワークでは、Windows 95、XP、NT4、Linux、Mac、プリンターなど、さまざまなものが問題なく共存していました。

その後、Linksys WRT54GL APを大量に入手しましたが、192.168で使用すると/24より大きいネットマスクを受け入れませんでした。これは、もともと192.168.0.0が次のように定義されていたためです。

256 個の連続したクラス C ネットワーク

そのため、ネットワークは 256 ホスト以下にする必要がありました。これは一部の Linksys キットでのみ発生し、OpenWRT のフラッシュでは完全な /16 ネットワークを使用できました。

結局のところ、/24 はほとんどのユーザーにとって十分すぎるほどです。/8 や /16 は大きすぎるサイズです。

Answer

はい、可能ですが、推奨されません。

代わりに、RFC1918 で割り当てられたブロックと、できる限り小さなネットワークを使用する必要があります。少数のデバイスがあるホームネットワークでは、10.0.0.0/8 を使用しないでください。

詳細はhttps://www.rfc-editor.org/rfc/rfc1918およびその代替https://www.rfc-editor.org/rfc/rfc6761

目安としては、ネットワーク上で実行できるデバイスの最大数の 4 倍、または /24 (254 ホスト) のいずれか大きい方のネットワークサイズを使用することです。/24 ではサブネット化も簡素化されます。

したがって、10.yourstreetnumber.yourbirthyear.0 または 192.168.yourheightincm.0 を使用してください。創造性を発揮してください。

サイト間 VPN を作成する可能性がある場合は、172.16 から 31.0.0 までの範囲を候補として検討してください。これは、少し複雑であまり使用されていないためです。

既存のパブリック範囲を使用しないもう 1 つの理由は、DNS キャッシュによって、ネットワークを変更するデバイスが混乱する可能性があるためです。IE ラップトップ、電話、タブレットは、「dns.google.com」を 8.8.8.8 としてキャッシュし、LAN に接続すると、そのレコードを使用し続ける可能性があります。または、誰かが家に帰り、8.8.8.8 に解決される「fileserver.local」のホスト名が、レコードの TTL までキャッシュされる可能性があります。

愚かな IP 再利用の例 - VMware Workstation の時代に、ループバックインターフェイスに適用された 127.0.0.0/8 よりも具体的であるという理由で、127.99.99.0/24 を IP ネットワークとして使用しようとしました。

これは、VMware および Linux VM では完璧に機能しました。しかし、Windows (XP?) では、IP アドレスの最初のオクテットに 127 を入力するとすぐに「停止、いいえ」と表示されました。当時、DHCP 経由で IP を割り当てようとしたことはありませんでした。

意図しない結果が生じる可能性は非常に大きいです。

また、まれに、クラスフルネットワークが問題を引き起こすこともあります。私は以前、192.168.0.0/16 のネットワークを運用していましたが、このネットワークでは、Windows 95、XP、NT4、Linux、Mac、プリンターなど、さまざまなものが問題なく共存していました。

その後、Linksys WRT54GL APを大量に入手しましたが、192.168で使用すると/24より大きいネットマスクを受け入れませんでした。これは、もともと192.168.0.0が次のように定義されていたためです。

256 個の連続したクラス C ネットワーク

そのため、ネットワークは 256 ホスト以下にする必要がありました。これは一部の Linksys キットでのみ発生し、OpenWRT のフラッシュでは完全な /16 ネットワークを使用できました。

結局のところ、/24 はほとんどのユーザーにとって十分すぎるほどです。/8 や /16 は大きすぎるサイズです。

Question 3

はい、これは可能です。いいえ、したくないでしょう。私が見た他の回答とは異なり、私はその理由についてさらに詳しく説明しようとしています (特に 2 番目の文について)。

コンピュータを制御していて、その IP アドレスを設定できるとします。そこで、IP アドレス 8.8.8.8 を入力します。それができますか? はい。

さて、「ルーティング」が問題になるかもしれません (この回答の後半で詳しく説明します)。ただし、それを回避する方法があるかもしれません。リモートエンドが ICMP サーバーに接続し、「ping 8.8.8.8」を実行したとします。ICMP サーバー (通常は「TCP/IP スタック」ソフトウェアコンポーネントに組み込まれています) は応答するでしょうか? はい、問題ありません。

このコンピューターで DNS サーバーなどのサーバーを起動するとします。コンピューターが DNS サーバーを実行しており、応答を受信した場合、応答してすべてが機能するでしょうか? はい、問題ありません。

HTTP サーバーを起動したとします。別のコンピューターが Web ブラウザーを開き、IP アドレスを使用してコンピューターと通信した場合、コンピューターは応答してすべて正常に動作しますか? ええと、以前は答えは「はい」でした。しかし、HPKP により、状況は少し複雑になりました。詳細については、次を参照してください。HTTP 公開鍵ピンニングに関する Wikipedia の Web ページ]。したがって、これはあまりうまく機能しない可能性があります。要約すると、一般的な Web ブラウザはこれを攻撃スタイルと見なし、世界のトップサイトの一部に対して適切な HTTPS 証明書/接続に関する詳細を提供しました。もう 1 つの関連手法は、HSTS (「HTTP Strict Transport Security」) に関連する「HSTS プリロード」です。したがって、ユーザーが最新バージョンの Web ブラウザをインストールすると、それらのブラウザには一部の Web サイトに関する詳細が提供される場合があります。偽の「Google」サイトが期待に沿わない場合、ブラウザが介入する可能性があります (おそらく、エンドユーザーに問題を知らせます)。

そして、あなたが示唆したように、このようなことを行うと、この IP アドレスでは正当なサイトに接続できなくなります。

さて、なぜこれをやりたくないと言っているのでしょうか?

まず、よりよい解決策があります。デバイスを DHCP に依存させます。次に、ローカルネットワークに、適切なアドレス (たとえば、FEC0:0:0:ffff::/126 または fd または fec0: で始まる IPv6 アドレス、または IETF BCP 5 ("RFC 1918") のアドレス範囲を使用する IPv4) でローカル DNS サーバーを使用する場所を示す DHCP サーバーを用意します。これをクライアントマシン用に標準化すると、モバイルシステムはリモートでもローカルネットワークでも希望どおりに機能する可能性があります。

期待どおりに物事を進める上での大きな課題はルーティングです。192.168.55.3/24 にアドレスを設定し、192.168.55.105/24 にある別のコンピュータが通信しようとすると、コンピュータは /24 (サブネットマスク 255.255.255.0) を認識し、最初の 3 つのオクテット (「192.168.55.」で始まる) に一致するものはすべてローカルネットワーク上にあると判断し、直接通信を試みます。

DNS クライアントが 192.168.55.105/24 にあり、8.8.8.8 と通信しようとすると、コンピュータは 8.8.8.8 が最初の 3 つのオクテットと一致しないことを認識し、トラフィックをゲートウェイデバイス (通常はインターネットに情報を送信する「デフォルトゲートウェイ」) に送信しようとします。(この「ゲートウェイ」デバイスはローカルネットワーク上に存在する必要があります。より専門用語で言えば、ゲートウェイは同じサブネット内に存在する必要があります。)

したがって、コンピュータを8.8.8.8と通信させるには、3つの方法があります。

クライアントシステムが 8.8.8.0/24 の範囲を不正に使用するようにすることができます。その場合、8.8.8.8 が近いように見えます。ただし、これにより 8.8.8.8 への有効な通信が中断され、この戦略を同時に使用して、ローカルコンピューターを別のアドレスと同じ近い IP 範囲に配置することはできないことに注意してください。
ローカルシステムで 192.168.55.105/24 の代わりに 192.168.55.105/0 を使用するように設定できます。これは、サブネットマスク 0.0.0.0 を使用していることを意味し、これで、8.8.8.8 がローカルアドレスであるとコンピュータに効果的に認識させることができます。そのため、通信は「デフォルトゲートウェイ」には送信されず、代わりにローカルネットワーク上の 8.8.8.8 に直接到達しようとします。クライアントとサーバーの両方がこれを実行している場合は、おそらくうまくいきます。
- しかし、ここで示した極端な例を使用すると、実際に実行されたのは、すべての IP アドレスがローカルネットワークの一部であるとコンピュータに信じ込ませることです。つまり、この不正な方法により、影響を受けたコンピュータは、インターネット全体がローカルネットワーク上にあるかのように扱われるようになったのです。これで、8.8.8.8 の正当な Google サイトとの通信が遮断される代わりに、インターネット上のすべての正当な IP アドレスとの通信が遮断されました。痛い。まずい。
「デフォルトゲートウェイ」デバイスにカスタムルーティングを設定すると、8.8.8.8 に送信された情報がインターネットサービスプロバイダーに渡されるのではなく、希望するローカル IP アドレスにリダイレクトされるようになります。

3 番目のアプローチは、理論的にはあまり問題や望ましくない副作用なく機能する可能性がありますが、最大の欠点は、トラフィックルーティングをいじらなければならないことです。何かいじる場合は、まずそれをよく理解することをお勧めします。

トラフィックルーティングを理解している者として、必要な正当な接続 (実際の 8.8.8.8 への接続) を切断しつつ、切断したくない正当な接続を切断しないようにするには、ある程度の専門知識が必要になると思います。また、それを実行できるほどの専門知識があるなら、確立されたプライベートアドレスで DNS サーバーを実行するだけの専門知識もおそらくあるでしょう。では、予測やトラブルシューティングが難しい、まれに発生する奇妙な副作用を引き起こす可能性が低い、標準化された方法で作業を行ってみてはいかがでしょうか。

質問の内容と質問の仕方に対する回答としては、技術的にはこのようなことは可能です。ただし、通信が本来の目的の場所に届かない場合は、多くの場合「中間者」(「MITM」) 攻撃と呼ばれることも覚えておいてください。Web ブラウザー接続は、このような悪ふざけを阻止するために HKPK をサポートするようにすでに進化しています。あまり知られていない事実として、DNS は EDNS (「DNS の拡張メカニズム」を使用) の使用に大きく置き換えられており、より広く知られている事実として、DNS セキュリティに DNSSec と呼ばれる新しい拡張機能がいくつかあることが挙げられます。このことをまったく知らなかった場合は、現在人気のあるインターネットベースのソフトウェアコードの保守担当者がすでにあなたよりはるかに先を行っている可能性があることを認識してください。そのため、監視するネットワークの何らかの新しい派手な設計の重要な部分として「MITM 攻撃」を組み込む前に、そのことを念頭に置いておくとよいでしょう。

まとめると、実際のネットワーク (可能性を模索するテストラボではなく) でこれを実行したくない主な理由は、単に、有用で正当な目標を達成するには、もっと良い方法があるからです。つまり、ネットワークの動作を設計しようとするときは、正しい方法で作業するということです。そうすれば、全体的に苦労が少なくなるでしょう。

忘れられているかもしれないので再度明確にしておきますが、私が言及している「正しい方法」とは、誰も騙さずにプライベートアドレスでローカル DNS サーバーを運用し、コンピューターにローカルプライベートアドレスを使用するか DHCP に依存するように促し、ローカル DHCP サーバーがデバイスにローカル DNS サーバーに依存するように指示することです。これは、パブリックサイトとの通信機能を損なわない、より誠実な設計スタイルであり、広くサポートされているため、インターネット標準の保守担当者が、世界中で使用されている多くのローカルネットワークでこのような正当な設計を壊すようなことを行う可能性は低くなります。

Answer

はい、これは可能です。いいえ、したくないでしょう。私が見た他の回答とは異なり、私はその理由についてさらに詳しく説明しようとしています (特に 2 番目の文について)。

コンピュータを制御していて、その IP アドレスを設定できるとします。そこで、IP アドレス 8.8.8.8 を入力します。それができますか? はい。

さて、「ルーティング」が問題になるかもしれません (この回答の後半で詳しく説明します)。ただし、それを回避する方法があるかもしれません。リモートエンドが ICMP サーバーに接続し、「ping 8.8.8.8」を実行したとします。ICMP サーバー (通常は「TCP/IP スタック」ソフトウェアコンポーネントに組み込まれています) は応答するでしょうか? はい、問題ありません。

このコンピューターで DNS サーバーなどのサーバーを起動するとします。コンピューターが DNS サーバーを実行しており、応答を受信した場合、応答してすべてが機能するでしょうか? はい、問題ありません。

HTTP サーバーを起動したとします。別のコンピューターが Web ブラウザーを開き、IP アドレスを使用してコンピューターと通信した場合、コンピューターは応答してすべて正常に動作しますか? ええと、以前は答えは「はい」でした。しかし、HPKP により、状況は少し複雑になりました。詳細については、次を参照してください。HTTP 公開鍵ピンニングに関する Wikipedia の Web ページ]。したがって、これはあまりうまく機能しない可能性があります。要約すると、一般的な Web ブラウザはこれを攻撃スタイルと見なし、世界のトップサイトの一部に対して適切な HTTPS 証明書/接続に関する詳細を提供しました。もう 1 つの関連手法は、HSTS (「HTTP Strict Transport Security」) に関連する「HSTS プリロード」です。したがって、ユーザーが最新バージョンの Web ブラウザをインストールすると、それらのブラウザには一部の Web サイトに関する詳細が提供される場合があります。偽の「Google」サイトが期待に沿わない場合、ブラウザが介入する可能性があります (おそらく、エンドユーザーに問題を知らせます)。

そして、あなたが示唆したように、このようなことを行うと、この IP アドレスでは正当なサイトに接続できなくなります。

さて、なぜこれをやりたくないと言っているのでしょうか?

まず、よりよい解決策があります。デバイスを DHCP に依存させます。次に、ローカルネットワークに、適切なアドレス (たとえば、FEC0:0:0:ffff::/126 または fd または fec0: で始まる IPv6 アドレス、または IETF BCP 5 ("RFC 1918") のアドレス範囲を使用する IPv4) でローカル DNS サーバーを使用する場所を示す DHCP サーバーを用意します。これをクライアントマシン用に標準化すると、モバイルシステムはリモートでもローカルネットワークでも希望どおりに機能する可能性があります。

期待どおりに物事を進める上での大きな課題はルーティングです。192.168.55.3/24 にアドレスを設定し、192.168.55.105/24 にある別のコンピュータが通信しようとすると、コンピュータは /24 (サブネットマスク 255.255.255.0) を認識し、最初の 3 つのオクテット (「192.168.55.」で始まる) に一致するものはすべてローカルネットワーク上にあると判断し、直接通信を試みます。

DNS クライアントが 192.168.55.105/24 にあり、8.8.8.8 と通信しようとすると、コンピュータは 8.8.8.8 が最初の 3 つのオクテットと一致しないことを認識し、トラフィックをゲートウェイデバイス (通常はインターネットに情報を送信する「デフォルトゲートウェイ」) に送信しようとします。(この「ゲートウェイ」デバイスはローカルネットワーク上に存在する必要があります。より専門用語で言えば、ゲートウェイは同じサブネット内に存在する必要があります。)

したがって、コンピュータを8.8.8.8と通信させるには、3つの方法があります。

クライアントシステムが 8.8.8.0/24 の範囲を不正に使用するようにすることができます。その場合、8.8.8.8 が近いように見えます。ただし、これにより 8.8.8.8 への有効な通信が中断され、この戦略を同時に使用して、ローカルコンピューターを別のアドレスと同じ近い IP 範囲に配置することはできないことに注意してください。
ローカルシステムで 192.168.55.105/24 の代わりに 192.168.55.105/0 を使用するように設定できます。これは、サブネットマスク 0.0.0.0 を使用していることを意味し、これで、8.8.8.8 がローカルアドレスであるとコンピュータに効果的に認識させることができます。そのため、通信は「デフォルトゲートウェイ」には送信されず、代わりにローカルネットワーク上の 8.8.8.8 に直接到達しようとします。クライアントとサーバーの両方がこれを実行している場合は、おそらくうまくいきます。
- しかし、ここで示した極端な例を使用すると、実際に実行されたのは、すべての IP アドレスがローカルネットワークの一部であるとコンピュータに信じ込ませることです。つまり、この不正な方法により、影響を受けたコンピュータは、インターネット全体がローカルネットワーク上にあるかのように扱われるようになったのです。これで、8.8.8.8 の正当な Google サイトとの通信が遮断される代わりに、インターネット上のすべての正当な IP アドレスとの通信が遮断されました。痛い。まずい。
「デフォルトゲートウェイ」デバイスにカスタムルーティングを設定すると、8.8.8.8 に送信された情報がインターネットサービスプロバイダーに渡されるのではなく、希望するローカル IP アドレスにリダイレクトされるようになります。

3 番目のアプローチは、理論的にはあまり問題や望ましくない副作用なく機能する可能性がありますが、最大の欠点は、トラフィックルーティングをいじらなければならないことです。何かいじる場合は、まずそれをよく理解することをお勧めします。

トラフィックルーティングを理解している者として、必要な正当な接続 (実際の 8.8.8.8 への接続) を切断しつつ、切断したくない正当な接続を切断しないようにするには、ある程度の専門知識が必要になると思います。また、それを実行できるほどの専門知識があるなら、確立されたプライベートアドレスで DNS サーバーを実行するだけの専門知識もおそらくあるでしょう。では、予測やトラブルシューティングが難しい、まれに発生する奇妙な副作用を引き起こす可能性が低い、標準化された方法で作業を行ってみてはいかがでしょうか。

質問の内容と質問の仕方に対する回答としては、技術的にはこのようなことは可能です。ただし、通信が本来の目的の場所に届かない場合は、多くの場合「中間者」(「MITM」) 攻撃と呼ばれることも覚えておいてください。Web ブラウザー接続は、このような悪ふざけを阻止するために HKPK をサポートするようにすでに進化しています。あまり知られていない事実として、DNS は EDNS (「DNS の拡張メカニズム」を使用) の使用に大きく置き換えられており、より広く知られている事実として、DNS セキュリティに DNSSec と呼ばれる新しい拡張機能がいくつかあることが挙げられます。このことをまったく知らなかった場合は、現在人気のあるインターネットベースのソフトウェアコードの保守担当者がすでにあなたよりはるかに先を行っている可能性があることを認識してください。そのため、監視するネットワークの何らかの新しい派手な設計の重要な部分として「MITM 攻撃」を組み込む前に、そのことを念頭に置いておくとよいでしょう。

まとめると、実際のネットワーク (可能性を模索するテストラボではなく) でこれを実行したくない主な理由は、単に、有用で正当な目標を達成するには、もっと良い方法があるからです。つまり、ネットワークの動作を設計しようとするときは、正しい方法で作業するということです。そうすれば、全体的に苦労が少なくなるでしょう。

忘れられているかもしれないので再度明確にしておきますが、私が言及している「正しい方法」とは、誰も騙さずにプライベートアドレスでローカル DNS サーバーを運用し、コンピューターにローカルプライベートアドレスを使用するか DHCP に依存するように促し、ローカル DHCP サーバーがデバイスにローカル DNS サーバーに依存するように指示することです。これは、パブリックサイトとの通信機能を損なわない、より誠実な設計スタイルであり、広くサポートされているため、インターネット標準の保守担当者が、世界中で使用されている多くのローカルネットワークでこのような正当な設計を壊すようなことを行う可能性は低くなります。

Question 4

理論的には、それで問題ないはずです。

実際には：

第三者の想定を覆す可能性があります。
特定のよく知られた IP 規則が適用されることを前提としたソフトウェア/ハードウェアを使用すると、これらの前提に違反したときに意図しない動作が発生する可能性があります。
隠れたバグを引き起こす可能性があります。
バグのあるソフトウェアはほとんどの場合問題なく動作しますが、奇妙な仕様によりバグが引き起こされる可能性があります。このようなバグは発見次第修正できますが、非標準の構成を使用すると、これまで誰も遭遇したことのないバグに遭遇する可能性が高くなる可能性があります。
ネットワークで作業している他のユーザーを混乱させる可能性があります。
社内ネットワーク内でそれが別の意味を持つことを覚えておいても問題ないとしても8.8.8.8、他の人を混乱させる可能性があります。同僚、技術サポート、ヘルプフォーラムで共有するログを読む人などが、困惑するかもしれません。
キャッシュに矛盾が生じる可能性があります。
ネットワーク上のデバイスが以前にグローバルインターネットに接続されていた場合、設定やファイアウォールルールなどに IPv4 アドレスが保存されている可能性があり、ローカルネットワークに参加したときに望ましくない衝突が発生する可能性があります。

理論的には、サードパーティの設計の悪さやバグはあなたのせいではないかもしれません。しかし、実際には、幽霊を信じ始めるかもしれない。

Answer

理論的には、それで問題ないはずです。

実際には：

第三者の想定を覆す可能性があります。
特定のよく知られた IP 規則が適用されることを前提としたソフトウェア/ハードウェアを使用すると、これらの前提に違反したときに意図しない動作が発生する可能性があります。
隠れたバグを引き起こす可能性があります。
バグのあるソフトウェアはほとんどの場合問題なく動作しますが、奇妙な仕様によりバグが引き起こされる可能性があります。このようなバグは発見次第修正できますが、非標準の構成を使用すると、これまで誰も遭遇したことのないバグに遭遇する可能性が高くなる可能性があります。
ネットワークで作業している他のユーザーを混乱させる可能性があります。
社内ネットワーク内でそれが別の意味を持つことを覚えておいても問題ないとしても8.8.8.8、他の人を混乱させる可能性があります。同僚、技術サポート、ヘルプフォーラムで共有するログを読む人などが、困惑するかもしれません。
キャッシュに矛盾が生じる可能性があります。
ネットワーク上のデバイスが以前にグローバルインターネットに接続されていた場合、設定やファイアウォールルールなどに IPv4 アドレスが保存されている可能性があり、ローカルネットワークに参加したときに望ましくない衝突が発生する可能性があります。

理論的には、サードパーティの設計の悪さやバグはあなたのせいではないかもしれません。しかし、実際には、幽霊を信じ始めるかもしれない。

インターネットなしでグローバル IP アドレスを使用することは可能ですか?

答え1

答え2

答え3

答え4

関連情報