Ist es möglich, globale IP-Adressen ohne Internet zu verwenden?

Question 1

Das ist absolut möglich. Der IPV4-Bereich ist nichts Magisches und alles funktioniert auf die gleiche Weise. Die Probleme kommen erst viele Jahre später, wenn dieses Netzwerk in das Internet integriert wird.

Answer

Das ist absolut möglich. Der IPV4-Bereich ist nichts Magisches und alles funktioniert auf die gleiche Weise. Die Probleme kommen erst viele Jahre später, wenn dieses Netzwerk in das Internet integriert wird.

Question 2

Ja, es ist möglich, wird aber nicht empfohlen.

Stattdessen sollten Sie die von RFC1918 zugewiesenen Blöcke und ein möglichst kleines Netzwerk verwenden. Vermeiden Sie die Verwendung von 10.0.0.0/8 für Ihr Heimnetzwerk mit einer Handvoll Geräten.

Weitere Details unterhttps://www.rfc-editor.org/rfc/rfc1918und sein Ersatzhttps://www.rfc-editor.org/rfc/rfc6761

Eine gute Faustregel ist, eine Netzwerkgröße von 4x der maximalen Anzahl von Geräten zu verwenden, die Sie in diesem Netzwerk ausführen können, oder /24 (254 Hosts), je nachdem, was größer ist. Ein /24 vereinfacht auch die Subnetzbildung.

Verwenden Sie also 10.IhreHausnummer.IhrGeburtsjahr.0 oder 192.168.IhreGrößeincm.0. Seien Sie kreativ!

Wenn Sie wahrscheinlich ein Site-to-Site-VPN erstellen, sollten Sie den Bereich 172.16 bis 31.0.0 als Kandidat in Betracht ziehen, da dieser etwas unübersichtlicher ist und daher weniger verwendet wird.

Ein weiterer Grund, keinen vorhandenen öffentlichen Bereich zu verwenden, besteht darin, dass DNS-Caching Geräte durcheinander bringen könnte, die das Netzwerk wechseln. IE-Laptops, -Telefone und -Tablets könnten „dns.google.com“ als 8.8.8.8 zwischenspeichern und diesen Eintrag weiterhin verwenden, sobald sie eine Verbindung zu Ihrem LAN herstellen. Oder jemand geht nach Hause und Ihr Hostname „fileserver.local“, der sich in 8.8.8.8 auflöst, könnte bis zur TTL des Eintrags zwischengespeichert werden.

Beispiel für dumme IP-Wiederverwendung – Damals, zu Zeiten von VMware Workstation, habe ich versucht, 127.99.99.0/24 als IP-Netzwerk zu verwenden, da es spezifischer war als das auf Loopback-Schnittstellen angewendete 127.0.0.0/8.

Dies funktionierte perfekt für VMware und Linux-VMs. Aber Windows (XP?) sagte „Stopp, nein“, sobald Sie 127 als erstes Oktett der IP-Adresse eingaben. Ich habe damals nie versucht, IPs über DHCP zuzuweisen.

Die Möglichkeiten unbeabsichtigter Folgen sind enorm.

Und manchmal, selten, bringt Sie Classful Networking durcheinander. Ich hatte mal ein Netzwerk mit der Adresse 192.168.0.0/16, in dem viele Dinge problemlos nebeneinander existierten: Windows 95, XP, NT4, Linux, Macs, Drucker usw.

Dann bekamen wir eine Reihe von Linksys WRT54GL APs und sie akzeptierten keine Netzmaske größer als /24, wenn sie mit 192.168 verwendet wurden. Das liegt daran, dass 192.168.0.0 ursprünglich definiert war als

256 zusammenhängende Klasse-C-Netzwerke

Das Netzwerk musste also 256 Hosts oder weniger umfassen. Dies kam nur bei einigen Linksys-Kits vor, und ein Flash mit OpenWRT konnte problemlos das gesamte /16-Netzwerk nutzen.

Das Fazit ist, dass /24 für die meisten Benutzer mehr als ausreichend ist. /8 oder /16 sind völlig überdimensioniert.

Answer

Ja, es ist möglich, wird aber nicht empfohlen.

Stattdessen sollten Sie die von RFC1918 zugewiesenen Blöcke und ein möglichst kleines Netzwerk verwenden. Vermeiden Sie die Verwendung von 10.0.0.0/8 für Ihr Heimnetzwerk mit einer Handvoll Geräten.

Weitere Details unterhttps://www.rfc-editor.org/rfc/rfc1918und sein Ersatzhttps://www.rfc-editor.org/rfc/rfc6761

Eine gute Faustregel ist, eine Netzwerkgröße von 4x der maximalen Anzahl von Geräten zu verwenden, die Sie in diesem Netzwerk ausführen können, oder /24 (254 Hosts), je nachdem, was größer ist. Ein /24 vereinfacht auch die Subnetzbildung.

Verwenden Sie also 10.IhreHausnummer.IhrGeburtsjahr.0 oder 192.168.IhreGrößeincm.0. Seien Sie kreativ!

Wenn Sie wahrscheinlich ein Site-to-Site-VPN erstellen, sollten Sie den Bereich 172.16 bis 31.0.0 als Kandidat in Betracht ziehen, da dieser etwas unübersichtlicher ist und daher weniger verwendet wird.

Ein weiterer Grund, keinen vorhandenen öffentlichen Bereich zu verwenden, besteht darin, dass DNS-Caching Geräte durcheinander bringen könnte, die das Netzwerk wechseln. IE-Laptops, -Telefone und -Tablets könnten „dns.google.com“ als 8.8.8.8 zwischenspeichern und diesen Eintrag weiterhin verwenden, sobald sie eine Verbindung zu Ihrem LAN herstellen. Oder jemand geht nach Hause und Ihr Hostname „fileserver.local“, der sich in 8.8.8.8 auflöst, könnte bis zur TTL des Eintrags zwischengespeichert werden.

Beispiel für dumme IP-Wiederverwendung – Damals, zu Zeiten von VMware Workstation, habe ich versucht, 127.99.99.0/24 als IP-Netzwerk zu verwenden, da es spezifischer war als das auf Loopback-Schnittstellen angewendete 127.0.0.0/8.

Dies funktionierte perfekt für VMware und Linux-VMs. Aber Windows (XP?) sagte „Stopp, nein“, sobald Sie 127 als erstes Oktett der IP-Adresse eingaben. Ich habe damals nie versucht, IPs über DHCP zuzuweisen.

Die Möglichkeiten unbeabsichtigter Folgen sind enorm.

Und manchmal, selten, bringt Sie Classful Networking durcheinander. Ich hatte mal ein Netzwerk mit der Adresse 192.168.0.0/16, in dem viele Dinge problemlos nebeneinander existierten: Windows 95, XP, NT4, Linux, Macs, Drucker usw.

Dann bekamen wir eine Reihe von Linksys WRT54GL APs und sie akzeptierten keine Netzmaske größer als /24, wenn sie mit 192.168 verwendet wurden. Das liegt daran, dass 192.168.0.0 ursprünglich definiert war als

256 zusammenhängende Klasse-C-Netzwerke

Das Netzwerk musste also 256 Hosts oder weniger umfassen. Dies kam nur bei einigen Linksys-Kits vor, und ein Flash mit OpenWRT konnte problemlos das gesamte /16-Netzwerk nutzen.

Das Fazit ist, dass /24 für die meisten Benutzer mehr als ausreichend ist. /8 oder /16 sind völlig überdimensioniert.

Question 3

Ja, das ist möglich. Nein, das möchten Sie nicht. Im Gegensatz zu einigen anderen Antworten, die ich sehe, werde ich näher auf die Gründe eingehen (insbesondere für meinen zweiten Satz).

Angenommen, Sie steuern einen Computer und können seine IP-Adresse festlegen. Sie geben also die IP-Adresse 8.8.8.8 ein. Ist das möglich? Ja.

Nun könnte „Routing“ ein Problem sein (wie ich in einem späteren Teil dieser Antwort näher erläutern werde). Es kann jedoch Möglichkeiten geben, dies zu umgehen. Nehmen wir also an, dass ein Remote-Ende Ihren ICMP-Server kontaktiert und „ping 8.8.8.8“ ausgeführt hat. Würde Ihr ICMP-Server (normalerweise in Softwarekomponenten des „TCP/IP-Stacks“ integriert) antworten? Ja. Kein Problem.

Angenommen, Sie starten auf diesem Computer einen Server, beispielsweise einen DNS-Server. Wenn auf Ihrem Computer ein DNS-Server ausgeführt wird und er die Antwort erhält, könnte er antworten und könnte alles funktionieren? Ja. Kein Problem.

Nehmen wir an, Sie starten einen HTTP-Server. Wenn ein anderer Computer einen Webbrowser öffnet und schließlich über die IP-Adresse mit Ihrem Computer kommuniziert, könnte Ihr Computer dann antworten und alles funktioniert? Ähm... also... früher war die Antwort "Ja". Aber jetzt ist es aufgrund von HPKP etwas komplizierter geworden. Weitere Einzelheiten finden Sie unterWikipedia-Webseite zum HTTP Public Key Pinning]. Das funktioniert also möglicherweise nicht so gut. Um es zusammenzufassen: Beliebte Webbrowser betrachteten dies als eine Art von Angriff und lieferten einige Details zu korrekten HTTPS-Zertifikaten/Verbindungen für einige der weltweit wichtigsten Websites. Eine andere verwandte Technik könnte „HSTS-Vorladen“ sein, das mit HSTS („HTTP Strict Transport Security“) verwandt ist. Wenn Benutzer also moderne Versionen von Webbrowsern installieren, liefern diese Browser möglicherweise einige Details zu einigen Websites. Wenn Ihre gefälschte „Google“-Site nicht den Erwartungen entspricht, greift der Browser möglicherweise ein (und informiert den Endbenutzer vermutlich über ein Problem).

Und wenn Sie diese Dinge tun, kann die legitime Site, wie Sie vorgeschlagen haben, nicht über diese IP-Adresse kontaktiert werden.

Warum sage ich nun, dass Sie das nicht tun möchten?

Erstens gibt es eine bessere Lösung. Lassen Sie die Geräte auf DHCP angewiesen sein. Dann haben Sie in Ihrem lokalen Netzwerk einen DHCP-Server, der Orte auf Ihre lokalen DNS-Server verweist, und zwar an eine sinnvolle Adresse (z. B. FEC0:0:0:ffff::/126 oder eine IPv6-Adresse, die mit fd oder vielleicht fec0: beginnt, oder IPv4 unter Verwendung der Adressbereiche von IETF BCP 5 („RFC 1918“)). Wenn Sie das für Client-Rechner standardisieren, werden mobile Systeme wahrscheinlich wie gewünscht remote und in Ihrem lokalen Netzwerk funktionieren.

Die große Herausforderung, die Dinge wie erwartet zu erledigen, ist das Routing. Wenn Sie eine Adresse unter 192.168.55.3/24 einrichten und ein anderer Computer unter 192.168.55.105/24 versucht, mit Ihnen zu kommunizieren, erkennen die Computer /24 (auch bekannt als Subnetzmaske von 255.255.255.0) und stellen fest, dass sich alles, was den ersten drei Oktetten entspricht (beginnend mit „192.168.55“), im lokalen Netzwerk befindet, und versuchen eine direkte Kommunikation.

Wenn sich ein DNS-Client bei 192.168.55.105/24 befindet und versucht, mit 8.8.8.8 zu kommunizieren, erkennt der Computer, dass 8.8.8.8 nicht mit den ersten drei Oktetten übereinstimmt, und versucht daher, den Datenverkehr an ein Gateway-Gerät zu senden, in der Regel ein „Standard-Gateway“, das Informationen an das Internet sendet. (Dieses „Gateway“-Gerät muss sich im lokalen Netzwerk befinden. Um es technischer auszudrücken: Das Gateway muss sich im selben Subnetz befinden.)

Es gibt also drei Ansätze, mit denen Sie Ihre Computer weiterhin mit 8.8.8.8 kommunizieren lassen können.

Sie könnten Ihre Clientsysteme dazu bringen, den Bereich 8.8.8.0/24 unrechtmäßig zu verwenden. Dann würde 8.8.8.8 naheliegend erscheinen. Beachten Sie, dass dadurch die gültige Kommunikation mit 8.8.8.8 unterbrochen würde und Sie diese Strategie nicht gleichzeitig verwenden könnten, um Ihre lokalen Computer im selben nahen IP-Bereich wie eine andere Adresse zu haben.
Sie könnten Ihr lokales System so einrichten, dass es 192.168.55.105/0 statt 192.168.55.105/24 verwendet. Das bedeutet, dass Sie eine Subnetzmaske von 0.0.0.0 verwenden, sodass Sie Ihren Computer effektiv davon überzeugt haben, dass 8.8.8.8 eine lokale Adresse ist. Die Kommunikation wird also nicht an Ihr „Standard-Gateway“ gehen, sondern stattdessen versuchen, 8.8.8.8 direkt in Ihrem lokalen Netzwerk zu erreichen. Wenn sowohl der Client als auch der Server dies tun, wird dies wahrscheinlich funktionieren.
- In dem hier gezeigten Extrembeispiel haben Sie Ihren Computer jedoch tatsächlich davon überzeugt, dass alle IP-Adressen Teil Ihres lokalen Netzwerks sind. Diese unrechtmäßige Methode hat den betroffenen Computer also davon überzeugt, dass das gesamte Internet so zu behandeln ist, als ob es Teil Ihres lokalen Netzwerks wäre. Anstatt nun die Kommunikation mit der legitimen Google-Site unter 8.8.8.8 zu unterbrechen, haben Sie effektiv die Kommunikation mit allen legitimen IP-Adressen im Internet unterbrochen. Autsch. Schlecht.
Sie könnten auf Ihrem „Standard-Gateway“-Gerät eine benutzerdefinierte Weiterleitung einrichten, sodass an 8.8.8.8 gesendete Informationen an die gewünschte lokale IP-Adresse umgeleitet werden, anstatt an Ihren Internetdienstanbieter weitergegeben zu werden.

Der dritte Ansatz könnte zwar theoretisch ohne allzu viele Probleme oder unerwünschte Nebenwirkungen funktionieren, der größte Nachteil ist jedoch, dass Sie sich mit der Verkehrsführung herumschlagen müssen. Wenn Sie sich mit etwas herumschlagen, schlage ich vor, dass Sie es zuerst gut verstehen.

Als jemand, der sich mit Verkehrsrouting auskennt, würde ich vorschlagen, dass Sie möglicherweise ein gewisses Maß an Fachwissen benötigen, um die gewünschten legitimen Verbindungen (zum echten 8.8.8.8) erfolgreich zu unterbrechen, ohne gleichzeitig legitime Verbindungen zu unterbrechen, die Sie nicht unterbrechen möchten. Und wenn Sie über so viel Fachwissen verfügen, um dies durchzuziehen, verfügen Sie wahrscheinlich auch über das Fachwissen, um einfach einen DNS-Server unter einer etablierten privaten Adresse auszuführen. Warum also nicht die standardisierte Methode verwenden, bei der weniger wahrscheinlich seltsame, seltene Nebenwirkungen auftreten, die schwerer vorherzusehen und zu beheben sind?

Als Antwort auf Ihre Frage und die Art und Weise, wie Sie sie gestellt haben: Ja, technisch könnte so etwas möglich sein. Bedenken Sie aber auch, dass, wenn die Kommunikation nicht dorthin gelangt, wo sie hingehen sollte, dies oft als „Man In The Middle“-Angriff („MITM“) bezeichnet wird. Webbrowser-Verbindungen wurden bereits so weiterentwickelt, dass sie HKPK unterstützen, um solche Machenschaften zu verhindern. Eine weniger bekannte Tatsache ist, dass DNS weitgehend durch die Verwendung von EDNS (unter Verwendung von „Erweiterungsmechanismen für DNS“) ersetzt wurde, und eine allgemein bekannte Tatsache ist, dass es einige neuere Verbesserungen der DNS-Sicherheit gibt, die als DNSSec bezeichnet werden. Wenn Sie nichts davon wussten, dann seien Sie sich bewusst, dass die aktuellen Entwickler von beliebtem internetbasiertem Softwarecode Ihnen möglicherweise schon weit voraus sind. Sie sollten dies also im Hinterkopf behalten, bevor Sie versuchen, einen „MITM-Angriff“ als kritischen Teil eines ausgefallenen neuen Designs eines von Ihnen überwachten Netzwerks einzubinden.

Zusammenfassend lässt sich also sagen, dass der Hauptgrund, warum Sie dies meiner Meinung nach nicht für ein echtes Netzwerk tun sollten (sondern für ein Testlabor, in dem Sie Möglichkeiten erkunden), einfach darin besteht, dass es zum Erreichen nützlicher, legitimer Ziele einen besseren Weg gibt. Wenn Sie versuchen, das Verhalten Ihres Netzwerks zu gestalten, tun Sie es richtig. Insgesamt werden Sie wahrscheinlich weniger Probleme haben.

Um es noch einmal klarzustellen, falls dies vergessen wurde: Der „richtige Weg“, auf den ich mich beziehe, besteht darin, Ihren lokalen DNS-Server einfach unter einer privaten Adresse zu betreiben, niemanden zu täuschen und Computer dazu zu bringen, die lokale private Adresse zu verwenden oder sich auf DHCP zu verlassen, und Ihre lokalen DHCP-Server Geräte anweisen zu lassen, sich auf Ihren lokalen DNS-Server zu verlassen. Dies ist ein ehrlicherer Designstil, der die Fähigkeit zur Kommunikation mit einer öffentlichen Site nicht beeinträchtigt und weithin unterstützt wird, sodass die Betreuer von Internetstandards weniger wahrscheinlich etwas tun, das ein so legitimes Design in vielen lokalen Netzwerken auf der ganzen Welt unterbricht.

Answer

Ja, das ist möglich. Nein, das möchten Sie nicht. Im Gegensatz zu einigen anderen Antworten, die ich sehe, werde ich näher auf die Gründe eingehen (insbesondere für meinen zweiten Satz).

Angenommen, Sie steuern einen Computer und können seine IP-Adresse festlegen. Sie geben also die IP-Adresse 8.8.8.8 ein. Ist das möglich? Ja.

Nun könnte „Routing“ ein Problem sein (wie ich in einem späteren Teil dieser Antwort näher erläutern werde). Es kann jedoch Möglichkeiten geben, dies zu umgehen. Nehmen wir also an, dass ein Remote-Ende Ihren ICMP-Server kontaktiert und „ping 8.8.8.8“ ausgeführt hat. Würde Ihr ICMP-Server (normalerweise in Softwarekomponenten des „TCP/IP-Stacks“ integriert) antworten? Ja. Kein Problem.

Angenommen, Sie starten auf diesem Computer einen Server, beispielsweise einen DNS-Server. Wenn auf Ihrem Computer ein DNS-Server ausgeführt wird und er die Antwort erhält, könnte er antworten und könnte alles funktionieren? Ja. Kein Problem.

Nehmen wir an, Sie starten einen HTTP-Server. Wenn ein anderer Computer einen Webbrowser öffnet und schließlich über die IP-Adresse mit Ihrem Computer kommuniziert, könnte Ihr Computer dann antworten und alles funktioniert? Ähm... also... früher war die Antwort "Ja". Aber jetzt ist es aufgrund von HPKP etwas komplizierter geworden. Weitere Einzelheiten finden Sie unterWikipedia-Webseite zum HTTP Public Key Pinning]. Das funktioniert also möglicherweise nicht so gut. Um es zusammenzufassen: Beliebte Webbrowser betrachteten dies als eine Art von Angriff und lieferten einige Details zu korrekten HTTPS-Zertifikaten/Verbindungen für einige der weltweit wichtigsten Websites. Eine andere verwandte Technik könnte „HSTS-Vorladen“ sein, das mit HSTS („HTTP Strict Transport Security“) verwandt ist. Wenn Benutzer also moderne Versionen von Webbrowsern installieren, liefern diese Browser möglicherweise einige Details zu einigen Websites. Wenn Ihre gefälschte „Google“-Site nicht den Erwartungen entspricht, greift der Browser möglicherweise ein (und informiert den Endbenutzer vermutlich über ein Problem).

Und wenn Sie diese Dinge tun, kann die legitime Site, wie Sie vorgeschlagen haben, nicht über diese IP-Adresse kontaktiert werden.

Warum sage ich nun, dass Sie das nicht tun möchten?

Erstens gibt es eine bessere Lösung. Lassen Sie die Geräte auf DHCP angewiesen sein. Dann haben Sie in Ihrem lokalen Netzwerk einen DHCP-Server, der Orte auf Ihre lokalen DNS-Server verweist, und zwar an eine sinnvolle Adresse (z. B. FEC0:0:0:ffff::/126 oder eine IPv6-Adresse, die mit fd oder vielleicht fec0: beginnt, oder IPv4 unter Verwendung der Adressbereiche von IETF BCP 5 („RFC 1918“)). Wenn Sie das für Client-Rechner standardisieren, werden mobile Systeme wahrscheinlich wie gewünscht remote und in Ihrem lokalen Netzwerk funktionieren.

Die große Herausforderung, die Dinge wie erwartet zu erledigen, ist das Routing. Wenn Sie eine Adresse unter 192.168.55.3/24 einrichten und ein anderer Computer unter 192.168.55.105/24 versucht, mit Ihnen zu kommunizieren, erkennen die Computer /24 (auch bekannt als Subnetzmaske von 255.255.255.0) und stellen fest, dass sich alles, was den ersten drei Oktetten entspricht (beginnend mit „192.168.55“), im lokalen Netzwerk befindet, und versuchen eine direkte Kommunikation.

Wenn sich ein DNS-Client bei 192.168.55.105/24 befindet und versucht, mit 8.8.8.8 zu kommunizieren, erkennt der Computer, dass 8.8.8.8 nicht mit den ersten drei Oktetten übereinstimmt, und versucht daher, den Datenverkehr an ein Gateway-Gerät zu senden, in der Regel ein „Standard-Gateway“, das Informationen an das Internet sendet. (Dieses „Gateway“-Gerät muss sich im lokalen Netzwerk befinden. Um es technischer auszudrücken: Das Gateway muss sich im selben Subnetz befinden.)

Es gibt also drei Ansätze, mit denen Sie Ihre Computer weiterhin mit 8.8.8.8 kommunizieren lassen können.

Sie könnten Ihre Clientsysteme dazu bringen, den Bereich 8.8.8.0/24 unrechtmäßig zu verwenden. Dann würde 8.8.8.8 naheliegend erscheinen. Beachten Sie, dass dadurch die gültige Kommunikation mit 8.8.8.8 unterbrochen würde und Sie diese Strategie nicht gleichzeitig verwenden könnten, um Ihre lokalen Computer im selben nahen IP-Bereich wie eine andere Adresse zu haben.
Sie könnten Ihr lokales System so einrichten, dass es 192.168.55.105/0 statt 192.168.55.105/24 verwendet. Das bedeutet, dass Sie eine Subnetzmaske von 0.0.0.0 verwenden, sodass Sie Ihren Computer effektiv davon überzeugt haben, dass 8.8.8.8 eine lokale Adresse ist. Die Kommunikation wird also nicht an Ihr „Standard-Gateway“ gehen, sondern stattdessen versuchen, 8.8.8.8 direkt in Ihrem lokalen Netzwerk zu erreichen. Wenn sowohl der Client als auch der Server dies tun, wird dies wahrscheinlich funktionieren.
- In dem hier gezeigten Extrembeispiel haben Sie Ihren Computer jedoch tatsächlich davon überzeugt, dass alle IP-Adressen Teil Ihres lokalen Netzwerks sind. Diese unrechtmäßige Methode hat den betroffenen Computer also davon überzeugt, dass das gesamte Internet so zu behandeln ist, als ob es Teil Ihres lokalen Netzwerks wäre. Anstatt nun die Kommunikation mit der legitimen Google-Site unter 8.8.8.8 zu unterbrechen, haben Sie effektiv die Kommunikation mit allen legitimen IP-Adressen im Internet unterbrochen. Autsch. Schlecht.
Sie könnten auf Ihrem „Standard-Gateway“-Gerät eine benutzerdefinierte Weiterleitung einrichten, sodass an 8.8.8.8 gesendete Informationen an die gewünschte lokale IP-Adresse umgeleitet werden, anstatt an Ihren Internetdienstanbieter weitergegeben zu werden.

Der dritte Ansatz könnte zwar theoretisch ohne allzu viele Probleme oder unerwünschte Nebenwirkungen funktionieren, der größte Nachteil ist jedoch, dass Sie sich mit der Verkehrsführung herumschlagen müssen. Wenn Sie sich mit etwas herumschlagen, schlage ich vor, dass Sie es zuerst gut verstehen.

Als jemand, der sich mit Verkehrsrouting auskennt, würde ich vorschlagen, dass Sie möglicherweise ein gewisses Maß an Fachwissen benötigen, um die gewünschten legitimen Verbindungen (zum echten 8.8.8.8) erfolgreich zu unterbrechen, ohne gleichzeitig legitime Verbindungen zu unterbrechen, die Sie nicht unterbrechen möchten. Und wenn Sie über so viel Fachwissen verfügen, um dies durchzuziehen, verfügen Sie wahrscheinlich auch über das Fachwissen, um einfach einen DNS-Server unter einer etablierten privaten Adresse auszuführen. Warum also nicht die standardisierte Methode verwenden, bei der weniger wahrscheinlich seltsame, seltene Nebenwirkungen auftreten, die schwerer vorherzusehen und zu beheben sind?

Als Antwort auf Ihre Frage und die Art und Weise, wie Sie sie gestellt haben: Ja, technisch könnte so etwas möglich sein. Bedenken Sie aber auch, dass, wenn die Kommunikation nicht dorthin gelangt, wo sie hingehen sollte, dies oft als „Man In The Middle“-Angriff („MITM“) bezeichnet wird. Webbrowser-Verbindungen wurden bereits so weiterentwickelt, dass sie HKPK unterstützen, um solche Machenschaften zu verhindern. Eine weniger bekannte Tatsache ist, dass DNS weitgehend durch die Verwendung von EDNS (unter Verwendung von „Erweiterungsmechanismen für DNS“) ersetzt wurde, und eine allgemein bekannte Tatsache ist, dass es einige neuere Verbesserungen der DNS-Sicherheit gibt, die als DNSSec bezeichnet werden. Wenn Sie nichts davon wussten, dann seien Sie sich bewusst, dass die aktuellen Entwickler von beliebtem internetbasiertem Softwarecode Ihnen möglicherweise schon weit voraus sind. Sie sollten dies also im Hinterkopf behalten, bevor Sie versuchen, einen „MITM-Angriff“ als kritischen Teil eines ausgefallenen neuen Designs eines von Ihnen überwachten Netzwerks einzubinden.

Zusammenfassend lässt sich also sagen, dass der Hauptgrund, warum Sie dies meiner Meinung nach nicht für ein echtes Netzwerk tun sollten (sondern für ein Testlabor, in dem Sie Möglichkeiten erkunden), einfach darin besteht, dass es zum Erreichen nützlicher, legitimer Ziele einen besseren Weg gibt. Wenn Sie versuchen, das Verhalten Ihres Netzwerks zu gestalten, tun Sie es richtig. Insgesamt werden Sie wahrscheinlich weniger Probleme haben.

Um es noch einmal klarzustellen, falls dies vergessen wurde: Der „richtige Weg“, auf den ich mich beziehe, besteht darin, Ihren lokalen DNS-Server einfach unter einer privaten Adresse zu betreiben, niemanden zu täuschen und Computer dazu zu bringen, die lokale private Adresse zu verwenden oder sich auf DHCP zu verlassen, und Ihre lokalen DHCP-Server Geräte anweisen zu lassen, sich auf Ihren lokalen DNS-Server zu verlassen. Dies ist ein ehrlicherer Designstil, der die Fähigkeit zur Kommunikation mit einer öffentlichen Site nicht beeinträchtigt und weithin unterstützt wird, sodass die Betreuer von Internetstandards weniger wahrscheinlich etwas tun, das ein so legitimes Design in vielen lokalen Netzwerken auf der ganzen Welt unterbricht.

Question 4

Theoretisch sollte das in Ordnung sein.

In der Praxis:

Kann Annahmen Dritter zerstören.
Sie verwenden möglicherweise Software/Hardware, die von der Einhaltung bestimmter bekannter IP-Konventionen ausgeht. Wenn Sie diese Annahmen nicht einhalten, kann dies zu unbeabsichtigtem Verhalten führen.
Kann versteckte Fehler auslösen.
Manche fehlerhafte Software funktioniert in den meisten Fällen einwandfrei, aber seltsame Details können sie auslösen. Solche Fehler können behoben werden, wenn sie bemerkt werden, aber wenn Sie eine nicht standardmäßige Konfiguration verwenden, kann die Wahrscheinlichkeit steigen, auf Fehler zu stoßen, die noch niemand zuvor entdeckt hat.
Kann andere verwirren, die mit Ihrem Netzwerk arbeiten.
Auch wenn Sie sich merken können, dass dies 8.8.8.8in Ihrem internen Netzwerk etwas anderes bedeutet, könnte dies möglicherweise andere verwirren. Kollegen, der technische Support, Leute, die ein Protokoll lesen, das Sie möglicherweise in einem Hilfeforum teilen usw., könnten damit Probleme haben.
Kann zu Widersprüchen in Caches führen.
Wenn Geräte in Ihrem Netzwerk zuvor mit dem globalen Internet verbunden waren, sind in den Einstellungen, Firewall-Regeln usw. dieser Geräte möglicherweise IPv4-Adressen gespeichert, was beim Beitritt zum lokalen Netzwerk möglicherweise zu unerwünschten Kollisionen führt.

Theoretisch sind schlechte Designs von Drittanbietern und Fehler möglicherweise nicht Ihre Schuld. Aber in der PraxisSie könnten anfangen, an Geister zu glauben.

Answer

Theoretisch sollte das in Ordnung sein.

In der Praxis:

Kann Annahmen Dritter zerstören.
Sie verwenden möglicherweise Software/Hardware, die von der Einhaltung bestimmter bekannter IP-Konventionen ausgeht. Wenn Sie diese Annahmen nicht einhalten, kann dies zu unbeabsichtigtem Verhalten führen.
Kann versteckte Fehler auslösen.
Manche fehlerhafte Software funktioniert in den meisten Fällen einwandfrei, aber seltsame Details können sie auslösen. Solche Fehler können behoben werden, wenn sie bemerkt werden, aber wenn Sie eine nicht standardmäßige Konfiguration verwenden, kann die Wahrscheinlichkeit steigen, auf Fehler zu stoßen, die noch niemand zuvor entdeckt hat.
Kann andere verwirren, die mit Ihrem Netzwerk arbeiten.
Auch wenn Sie sich merken können, dass dies 8.8.8.8in Ihrem internen Netzwerk etwas anderes bedeutet, könnte dies möglicherweise andere verwirren. Kollegen, der technische Support, Leute, die ein Protokoll lesen, das Sie möglicherweise in einem Hilfeforum teilen usw., könnten damit Probleme haben.
Kann zu Widersprüchen in Caches führen.
Wenn Geräte in Ihrem Netzwerk zuvor mit dem globalen Internet verbunden waren, sind in den Einstellungen, Firewall-Regeln usw. dieser Geräte möglicherweise IPv4-Adressen gespeichert, was beim Beitritt zum lokalen Netzwerk möglicherweise zu unerwünschten Kollisionen führt.

Theoretisch sind schlechte Designs von Drittanbietern und Fehler möglicherweise nicht Ihre Schuld. Aber in der PraxisSie könnten anfangen, an Geister zu glauben.

Ist es möglich, globale IP-Adressen ohne Internet zu verwenden?

Antwort1

Antwort2

Antwort3

Antwort4

verwandte Informationen