Möchten Sie einen Webserver mit einer IP einrichten, die sich nicht in meinem lokalen Netzwerk befindet?

Ich bin im lokalen Netzwerk 192.168.180.1. Ich möchte jedoch einen Webserver (Windows / Linux) mit IP 169.254.1.0 in meinem lokalen Netzwerk einrichten

Ich kann eine statische IP für den Server auf 169.254.1.0 festlegen, aber ich glaube nicht, dass es möglich ist, von einem Gerät mit 192.168.180.1 darauf zu routen. Daher ist es nicht sinnvoll, das Standard-Gateway für 169.254.1.0 auf 192.168.180.1 zu setzen.

Kann ich irgendetwas tun oder ist das unmöglich zu tun? Jede Hilfe wird sehr geschätzt.

Vielen Dank.

networking

— Dan007
quelle

Ist 169.254.1.0 die öffentliche IP-Adresse Ihres Routers?

— Tyson

Nein, nur eine statische IP Ich muss einen Test durchführen

— Dan007

Serms eine ungerade öffentliche IP ... 169.254. ist ziemlich bekannt als eine APIPA-Adresse ... eine .0-Adresse ist auch die Netzwerk-IP. Warum sollten Sie diese verwenden? Warum verwendet der Computer in Ihrem vorhandenen Subnetz keine IP-Adresse?

— Kinnectus

Warum benötigen Sie eine statische IP im lokalen Link-Bereich? Außerdem können Sie Geräten in der Regel mehrere IP-Adressen hinzufügen, sodass das andere Gerät auch eine Adresse im selben Block haben kann.

— Sami Kuhmonen

Sie müssen eine statische Route auf dem Server und auf dem Gateway für das 192.168.180.1-Netzwerk

— festlegen

Antworten:

169.254.xx / 16 nennt die IETF das IPv4 Link-Local-Subnetz ("APIPA" ist die proprietäre Fachsprache von Microsoft). Wenn die IP-Stacks Ihrer Geräte den IETF ZeroConf-Empfehlungen entsprechen, sollten sie dieses Subnetz als lokales Subnetz behandeln, auch wenn sie keine IP-Adresse in diesem Subnetz haben. Was Sie also in Betracht ziehen, sollte einfach funktionieren, es ist kein spezielles Setup erforderlich.

Im Gegensatz zu einigen Kommentaren hier ist 169.254.1.0 NICHT die Netzwerkadresse für dieses Subnetz, da es sich um ein / 16-Subnetz (Netzmaske 255.255.0.0) handelt, nicht um ein / 24-Subnetz (255.255.255.0).

Wenn Sie in diesem Subnetz eine statische IP-Adresse benötigen, sollte diese im dritten Oktett (169.254.0.x oder 169.254.255.x) Null oder 255 haben, da 169.254.1.0 bis 168.254.254.255 für die automatische Selbstverwaltung reserviert sind. Zuordnung, nicht manuelle Zuordnung.

Weitere Informationen finden Sie in RFC 3927 .

— Spiff
quelle

Wäre es möglich, dass 169.254.1.0das tatsächlich die Netzwerkadresse ist? Schließlich hat OP keine Netzmaske angegeben und kann eine / 24 wählen. Selbst wenn RFC 3927/5735 es als / 16 definiert, hindert dies Benutzer nicht daran, es für ihre eigenen Zwecke weiter zu subnetzen. Tatsächlich geht der RFC explizit auf Folgendes ein: "Diese Spezifikation ist für die Verwendung in kleinen Ad-hoc-Netzwerken vorgesehen ... Obwohl 65024 IPv4 Link-Local-Adressen im Prinzip verfügbar sind ... Netzwerkbetreiber mit mehr als 1300 Hosts auf einer einzelnen Verbindung Vielleicht möchten Sie diesen einzelnen Link in zwei oder mehr Subnetze aufteilen. "

— SSNOBODY

@ssnobody IP-Stacks, die mit RFC 3927 vertraut sind, erstellen automatisch eine Route für 169.254 / 16, die direkt an eine lokale Schnittstelle angeschlossen ist. Ich nehme an, Sie könnten eine Möglichkeit finden, das automatische Verhalten zu deaktivieren oder außer Kraft zu setzen, damit Sie die gewünschte Subnetzmaske festlegen können, aber ich glaube, das tut niemand wirklich. Außerdem erwähnte OP in einem Kommentar, dass er Software hat, die er nicht in der Lage ist, die fest codierte 169.254.1.0 als Webserver-Adresse zu ändern. Anscheinend glaubt die Software, mit der er es zu tun hat, auch nicht, dass es sich um eine Netzwerkadresse handelt.

— Spiff

Durch Hinzufügen einer IP im 169.254.1.0Netz zu anderen Hosts, für die das Subnetz festgelegt ist, 255.255.255.0wird ein Routeneintrag für die / 24 (anstelle der / 16) erstellt. Diese Route wird die spezifischere Route für das 169.254.1.0Netz sein, und insbesondere für die 169.254.1.1IP die OP-Kommentare, die er verwenden KANN. Dies gilt unabhängig davon, ob das Betriebssystem / 16 nativ unterstützt. Ich weiß nicht, ob das Einstellen des Subnetzes das ist, was Sie unter "Deaktivieren oder Außerkraftsetzen des automatischen Verhaltens" verstanden haben, aber das Einstellen eines Subnetzes ist bereits ein Teil dessen, was OP tut, wenn es statische IPs konfiguriert.

— SSNOBODY

Ich denke, damit dies mit zeroconf funktioniert und Sie keine 169.254statischen IPs auf den anderen Hosts festlegen müssen , die auf den Webserver in diesem Netz zugreifen möchten (ein Ansatz, den ich bevorzugen würde), müssen Sie auch eine Route hinzufügen auf dem Webserver, um ihm mitzuteilen, wie er mit dem 192.168.180Netz kommunizieren soll, oder er weiß nicht, wie er die zurückgegebenen Pakete weiterleiten soll, und Sie erhalten eine einseitige Kommunikation.

— SSNOBODY

@ssnobody Ich glaube nicht, dass Sie Abschnitt 2.6.2 von RFC 3927 gelesen haben. Dadurch ist das Subnetz 169.254 / 16 immun gegen Subnetz-Mismatch-Probleme. Computer mit IPv4-Link-Local-Adressen (und keinen routingfähigen Adressen) sollen alle Subnetze als lokal behandeln (sodass sein Webserver keine Route zu 192.168.180 / 24 benötigt). Siehe den Absatz, der zwischen dem Ende von Seite 14 und dem Anfang von Seite 15 aufgeteilt ist. Ich weiß, dass Apples IP-Stacks seit mindestens 2001 auf diese Weise funktionieren, vielleicht schon früher. Mac OS 9, OS X und iOS-Geräte tun dies alle. Sogar AirPort-Basisstationen und Xserve-RAIDs tun dies.

— Spiff

Es ist möglich. Sie können tatsächlich ein Gateway außerhalb des Subnetzes verwenden. Obwohl es ziemlich ungewöhnlich ist, habe ich ein paar Netzwerke gesehen, die dies taten.

Beachten Sie, dass die Standardeinstellungen für "Netzmaske" und "Gateway" nur auf automatisch generierte Routen ausgeweitet werden, von denen weitere auch manuell festgelegt werden können. (Beispielsweise kann eine Linkroute hinzugefügt werden, um dem Betriebssystem manuell mitzuteilen, dass sich ein Gerät mit einer seltsamen IP-Adresse im selben LAN wie Sie befindet.)
Beachten Sie auch, dass einer Netzwerkkarte mehrere Adressen zugewiesen werden können und sie bei Bedarf aus verschiedenen Subnetzen stammen können. (Auch unter Windows ist dies möglich, allerdings muss DHCP deaktiviert sein.)

Normalerweise haben Sie jetzt mehrere ähnliche Optionen, je nachdem, wer Ihren Server erreichen muss. Sie können Ihren Router oder die Client-PCs selbst konfigurieren (jedoch nur, wenn sie sich auf demselben Router wie der Server befinden).

Leider wird der spezifische 169.254.0.0/16Adressbereich als nicht routbar bezeichnet . Router wurden geschrieben, um die Weiterleitung von Paketen mit solchen IPs zu verweigern , unabhängig von Ihrer Konfiguration.

Das schränkt die Möglichkeiten etwas ein. Das heißt, der Webserver muss mit demselben LAN verbunden sein wie Sie (dh hinter demselben Router).

Die einzige verbleibende Option ist: Fügen Sie eine 169.254.x.x/16Adresse auf Ihrem eigenen PC hinzu, zusätzlich zu der üblichen 192.168.180.x/24, die Sie haben.

In diesem Fall ist die Konfiguration eines Gateways auf dem Webserver nicht erforderlich, da die Kommunikation über dasselbe Subnetz es ohnehin nicht verwendet. (Das bedeutet natürlich, dass der Webserver selbst keine Verbindung herstellen kann.)

— Grawity
quelle

Wenn Sie eine 169.254.x.xAdresse hinzufügen , die sich NICHT im 169.254.1.xNetzwerk befindet, stellen Sie sicher, dass Sie die Netzmaske auf BEIDEN Systemen auf einstellen 255.255.0.0. Wenn beide Systeme eingeschaltet sind, können 169.254.1.xSie die 255.255.255.0Netzmaske verwenden, obwohl in diesem Fall beide Netzmasken funktionieren.

— SSNOBODY

Die einzige Möglichkeit, die mir in den Sinn kommt, ist das Hinzufügen einer statischen Route in Ihrem Router.

Beispielsweise können Sie festlegen, dass die IP 169.254.1.0mit der Netzmaske /32(255.255.255.255) in Ihrer LANSchnittstelle ein Gateway verwenden soll 192.168.180.100(vorausgesetzt, dies ist der Server, auf dem sich der Webserver befindet).

Wie Spiff feststellt, könnte dies nicht funktionieren, wenn Ihr Router Abschnitt 2.6.2 des RFC einhält, da dies die CIDR-Adresse ist, die nicht weitergeleitet werden sollte. Ich habe dies jedoch gerade zu Hause mit einem TP-Link TD-W8970-Router getestet und es funktioniert tatsächlich. Die Pakete werden mit der Ziel-IP (169.254.1.0) weitergeleitet, die im Header nicht geändert wurde.

— nKn
quelle

Dazu müsste das OP einen Router einrichten, der den Verkehr zwischen diesen Netzen weiterleiten kann.

— SSNOBODY

RFC 3927, das die automatische IPv4-Link-Local-Adressierung im speziellen Subnetz 169.254 / 16 definiert, untersagt Routern insbesondere die Weiterleitung von Paketen an dieses Subnetz bzw. von diesem Subnetz. Siehe Abschnitt 2.6.2.

— Spiff

@Spiff Ich sage nicht das Gegenteil, ich versuche nur, einen Weg zu finden, wie das OP das von ihm benötigte Verhalten simulieren kann. Ich habe es einfach selbst ausprobiert und es hat funktioniert, das ist seltsam. Vielleicht, weil ich die statische Route nicht als / 16, sondern als / 32 definiert habe ... Wie ich bereits sagte, werden Pakete an das definierte Gateway weitergeleitet, wobei die Ziel-IP im Header unberührt bleibt.

— nKn

Sie sagten, Sie hätten keinen Grund gesehen, warum es nicht funktionieren sollte, und ich habe Ihnen nur einen gegeben. Es sollte nicht funktionieren, wenn der Router diesen etablierten Standard-Track-RFC einhält. Wenn seine Hosts dem RFC folgen, sollte er ihn nicht benötigen (siehe auch Abschnitt 2.6.2).

— Spiff