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

Question

明らかに、プライベートIPアドレスはインターネットアクセスなしで使用する必要があります。しかし、私はプライベートIPとして任意のIPアドレスを使用できるかどうか興味があります。そうすることは可能ですか？

たとえば、プライベートネットワークのプライベートIPアドレスとして8.8.8.8を使用できますか（インターネットにアクセスできないため、ネットワークの誰も8.8.8.8がGoogle DNSとして使用されていることを知りません）

davidgo · Answer

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

Criggie · Answer

はい可能ですが、お勧めしません。

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

詳細は https://tools.ietf.org/html/rfc1918 とその代替 https://tools.ietf.org/html/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に接続した後もそのレコードを使用し続けることができます。または、誰かが家に帰り、「fileserver 8.8.8.8に解決する.local "は、レコードのTTLまでキャッシュできます。

愚かなIPの再利用の例-昔のvmwareワークステーションで、127.99.99.0/24をIPネットワークとして使用してみました。これは、ループバックインターフェイスに適用される127.0.0.0/8よりも具体的だったためです。

これはvmwareとlinux VMで完全に機能しました。しかし、Windows（xp？）は、IPアドレスの最初のオクテットに127を入力するとすぐに、「やめなさい」と言いました。当時、私はDHCP経由でIPを割り当てようとしませんでした。

意図しない結果の可能性は計り知れません。

そして、まれに、クラスフルネットワーキングが混乱することがあります。以前は192.168.0.0/16のネットワークを使っていましたが、Windows 95、XP、NT4、linux、macs、プリンターなど、多くのものが共存しています。

次に、一連のLinksys WRT54GL APを取得しました。これらのAPは、192.168で使用した場合、/ 24より大きいネットマスクを受け入れません。これは、もともと192.168.0.0が

256の隣接するクラスCネットワーク

したがって、ネットワークは256ホスト以下でなければなりませんでした。これはこれまでに一部のlinksysキットでのみ登場し、OpenWRTを搭載したフラッシュは、完全な/ 16ネットワークを使用して満足しています。

これの効果は、ほとんどのユーザーにとって/ 24で十分です。/8または/ 16はばかげた特大です。

TOOGAM · Answer

はい、できます。いいえ、したくありません。私が目にする他のいくつかの回答とは異なり、私はなぜ（特に2番目の文について）理由の詳細を掘り下げようとしています。

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

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

このコンピュータでDNSサーバーなどのサーバーを起動するとします。コンピュータがDNSサーバーを実行していて、応答を受け取った場合、応答してすべてが機能する可能性はありますか？はい。問題ない。

HTTPサーバーを起動するとします。別のコンピューターがWebブラウザーを開いて、最終的にIPアドレスを使用してコンピューターと通信した場合、コンピューターは応答し、すべてが機能しますか？ええと…ええと…昔は「はい」だった。しかし、今では、HPKPにより、状況は少し複雑になりました。詳細については、 HTTP公開キーのピン留めに関するWikipediaのWebページ ]を参照してください。だから、それはあまりうまくいかないかもしれません。要約すると、人気のあるWebブラウザーはこれを攻撃のスタイルと見なし、世界のトップサイトのいくつかに対する適切なHTTPS証明書/接続に関する詳細を備えていました。別の関連技術は、HSTS（「HTTP Strict Transport Security」）に関連する「HSTS preloading」です。したがって、最新バージョンのWebブラウザーをインストールすると、それらのブラウザーには一部のWebサイトに関する詳細が表示される場合があります。偽の "Google"サイトが期待と一致しない場合、ブラウザが介入する可能性があります（おそらくエンドユーザーに問題を通知します）。

そして、あなたが提案したように、あなたがこれらの種類のことをするならば、正当なサイトはこのIPアドレスで連絡することができません。

さて、なぜあなたはこれをしたくないと言っているのですか？

まず、より良い解決策があります。デバイスをDHCPに依存させる。次に、ローカルネットワーク上で、ローカルDNSサーバーを使用する場所を適切なアドレス（例：FEC0：0：0：ffff ::/126またはfdまたはfec0で始まるIPv6アドレス）でポイントするDHCPサーバーを用意します。、またはIETF BCP 5（ "RFC 1918"））のアドレス範囲を使用するIPv4。これをクライアントマシン用に標準化すると、モバイルシステムはリモートおよびローカルネットワークで必要に応じて動作する可能性があります。

期待どおりの処理を行う上での大きな課題はルーティングです。 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の拡張メカニズム"を使用）であり、より広く知られている事実は、DNSSecと呼ばれるDNSセキュリティに新しい拡張機能があることです。これに気づかなかった場合は、現在普及しているインターネットベースのソフトウェアコードのメンテナーがすでにあなたより先にいる可能性があることを理解してください。そのため、「MITM攻撃」を含める前に、あなたが監督するネットワークのある種の派手な新しいデザインの重要な部分。

つまり、要約すると、（可能性を模索しているテストラボではなく）実際のネットワークでこれを実行したくないと思う主な理由は、有用な正当な目標を達成するには、より良い方法があるということです。。つまり、ネットワークの動作を設計しようとしているときに、正しい方法で物事を実行します。全体的に痛みが少なくなるでしょう。

これが忘れられた場合の再明確化のために、私が言及している「正しい方法」は、ローカルDNSサーバーをプライベートアドレスで操作し、だれもだまさないようにし、コンピューターにローカルプライベートアドレスの使用またはDHCPに依存するように促すことです。また、ローカルDHCPサーバーがデバイスにローカルDNSサーバーに依存するように指示します。これは、公開サイトとの通信機能を損なうことのないより正直なスタイルのデザインであり、広くサポートされているため、インターネット標準の保守担当者は、全体で使用される多くのローカルネットワークでこのような正当なデザインを壊すようなことをする可能性が低くなります。世界。

fraxinus · Answer

それが可能であるだけでなく、グローバルIPアドレスを特徴とし、インターネットに接続されている読み書きのできない管理者によって作成されたいくつかのネットワークを見てきました（NATファイアウォール経由）。

唯一の実際の問題は、同じIP範囲を持つ正当なネットワークにアクセスできないことです。大規模で大規模なインターネット上のどこかにある256個のIPアドレスについては、大したことではありません。

Nat · Answer

理論的には、それで問題ありません。

実際には：

サードパーティの前提を破る可能性があります。
特定の既知のIP規則が成立することを前提とするソフトウェア/ハードウェアを使用すると、これらの前提を破ると、意図しない動作が発生する可能性があります。
隠れたバグを引き起こす可能性があります。
一部のバグのあるソフトウェアはほとんどの場合正常に動作しますが、奇妙な詳細が原因となる場合があります。このようなバグは気づいたときに修正できますが、非標準の構成を使用すると、他の誰もが遭遇する機会がなかったバグに遭遇する可能性が高まる可能性があります。
ネットワークで作業している他のユーザーを混乱させる可能性があります。
あなたがそれを覚えているのがクールでも、8.8.8.8は、内部ネットワークの他の何かを意味します。これにより、他のユーザーを混乱させる可能性があります。同僚、テクニカルサポート、ヘルプフォーラムで共有したログを読んでいる人などが問題を抱えている可能性があります。
キャッシュに矛盾が生じる可能性があります。
ネットワーク上のデバイスが以前にグローバルインターネットに接続されていた場合、それらのデバイスの設定、ファイアウォールルールなどにIPv4アドレスが格納されている可能性があり、ローカルネットワークに参加するときに望ましくない衝突を引き起こす可能性があります。

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