Bin gespannt auf ein wenig Feedback, wie andere das machen.
Ein Standort, den ich mir ansehe, hat mehrere Gebäude, die über Glasfaser verbunden sind und sich jeweils in einem eigenen Subnetz befinden.
192.168.0.0 - Building 1 - VLAN10
192.168.1.0 - Building 2 - VLAN20
192.168.2.0 - Building 3 - VLAN30
usw
(fürs Protokoll: Ich verstehe die unerwünschten Auswirkungen, die sich aus der Zugehörigkeit zu einem 192.168-Subnetz ergeben)
Jedes Gebäude betreibt sein eigenes kleines Rechenzentrum mit DHCP-Servern und Domänencontrollern.
Mein großes Problem ist, dass es meiner Meinung nach sehr verwirrend ist, Server zu haben,
192.168.0.1 - building 1
192.168.0.5 - building 1
192.168.1.11 - building 2
192.168.2.5 - building 3
etc.
Natürlich könnte ich sagen, alle Netzwerkgeräte sollen im Subnetz 192.168.0.0 und alle Server bei 192.168.1.0 und DHCP bei 192.168.3.0 untergebracht werden, aber dadurch würden Crossover-VLANs entstehen.
Beispielsweise würde ich wahrscheinlich immer noch einen DHCP-Server in VLAN20 mit allen Computern in diesem Gebäude wollen, und ebenso einen DHCP-Server in VLAN10 mit den Computern in diesem Gebäude.
Traditionell werden VLANs 1:1 mit ihrem Subnetz gehalten.
Wie schaffen das andere? Wissen Sie einfach, dass 192.168.0.1-.50 für Servergeräte reserviert ist?
Ich kam von einem 10.1.0.0/21-Netzwerk, also hatten wir genug Adressen, um alles getrennt zu halten, und haben überhaupt kein VLAN verwendet.
Antwort1
Diese Frage lässt sich nur schwer auf Szenariobasis beantworten, da viele Faktoren zu berücksichtigen sind und nur wenige Informationen zur Verfügung stehen. Im Allgemeinen sind hier jedoch meine Erkenntnisse.
Erstens stimme ich den Kommentaren zu der Frage zu, dass keine private Adressgruppe mehr oder weniger wünschenswert ist als eine andere, wenn sie anfällig für Ähnlichkeiten mit Heimanwendern ist. Meiner Erfahrung nach gilt: Egal, wie sehr Sie versuchen, Konflikte mit VPN-Benutzern zu vermeiden, wenn es bei Benutzer „A“ nicht auftritt, wird es irgendwann einen Benutzer „B“ geben, bei dem es auftritt.
Ein wichtiger Punkt, den Sie in der Frage nicht erwähnt haben, ist die Anzahl der Geräte und das erwartete Wachstum über die Lebensdauer der Infrastruktur. Aufgrund des offenen Umfangs und der Mehrdeutigkeit werde ich die Punkte allgemein halten.
Wenn Sie Ihr Netzwerk in Subnetze pro Gebäude aufteilen möchten, ermitteln Sie zunächst die Anzahl der benötigten Gebäude und überlegen Sie dann, wie wahrscheinlich es ist, dass dies langfristig (5-10 Jahre) ausreicht. Versuchen Sie, eine nicht übermäßige, aber realistische Anzahl von Netzwerken zu ermitteln. Normalerweise wäre ich großzügig und würde einen geringen Mehraufwand zulassen. Verwenden Sie diese Option, um den engsten praktischen Bereich für Subnetze auf höherer Ebene zu definieren.
Wenn Sie beispielsweise 3 Gebäude haben, aber davon ausgehen, dass diese Zahl in 10 Jahren auf 5 anwachsen könnte, wählen Sie ein hierfür sinnvolles Vielfaches zur Basis 2 und teilen Sie das erste nutzbare Oktett mit diesem Präfix auf. Beispiel: 172.16.xx mit bis zu 8 Netzwerken:
000 | x xxxx . xxxx xxxx - Common Equiptment. 192.168.0.0 /19
001 | x xxxx . xxxx xxxx - Building 1. 172.16.32.0 /19
010 | x xxxx . xxxx xxxx - Building 2. 172.16.64.0 /19
011 | x xxxx . xxxx xxxx - Building 3. 172.16.96.0 /19
100 | x xxxx . xxxx xxxx - Building 4. 172.16.128.0 /19
Dadurch wird Ihr Adressumfang maximiert und eine weitere Subnetzbildung ermöglicht. Außerdem wird die Routendefinition vereinfacht, wenn alle Subnetze innerhalb eines .19-Umfangs für den Großteil des verbleibenden Netzwerks über denselben Knoten laufen. Beachten Sie, dass diese Balance in zwei Richtungen funktionieren sollte. Nehmen wir beispielsweise an, Sie haben zusätzlich zu Ihren Hauptgebäuden eine kleine Anzahl von Gebäuden, wie z. B. Außenstellen, die nicht viele Adressen benötigen, sondern einfach verbunden werden müssen. Sie könnten diesen ein einzelnes Gebäude-„übergeordnetes“ Subnetz zuweisen und es aufteilen, um sie zu bedienen. Ihr Ziel ist es letztendlich, den größten Adressraum dort zu behalten, wo er wahrscheinlich am meisten benötigt wird.
Von hier aus können Sie Ihr Netzwerk möglicherweise noch weiter aufteilen, in anwendungsspezifische Zuteilungen. Sie könnten beispielsweise wie folgt vorgehen:
Gebäude 1 (von oben).
001 | 0 0 | xxx . xxxx xxxx - Building 1's Default Network. 172.16.32.0 /21
001 | 0 1 | xxx . xxxx xxxx - Building 1's Misc Networks. 172.16.40.0 /21
001 | 1 0 | xxx . xxxx xxxx - Building 1's Phone Network. 172.16.48.0 /21
Wir könnten noch weiter gehen und Folgendes erreichen:
001 | 0 1 | xxx . xxxx xxxx - Building 1's Misc Networks. 172.16.40.0 /21
001 | 0 1 | 001 . xxxx xxxx - Management Network. 172.16.41.0 /24
001 | 0 1 | 010 . xxxx xxxx - Security Camera Network. 172.16.42.0 /24
001 | 0 1 | 011 . xxxx xxxx - Alarm System Network. 172.16.43.0 /24
Ich denke, das Wichtigste ist, eine Lösung zu finden, die für Ihr Szenario funktioniert. Sie möchten wahrscheinlich:
- Maximieren Sie den Wachstumsspielraum dort, wo er am wahrscheinlichsten auftritt. Ich würde vermuten, dass dies das Netzwerk Ihrer Endbenutzer ist.
- Behalten Sie möglichst konsistente Muster bei, damit ACLs und Firewall-Regeln vereinfacht werden können. Wenn Sie beispielsweise im 3. Oktett wissen, dass das 4. und 5. Bit mit dem Muster „01“ immer die „verschiedenen Netzwerke“ bezeichnen, können Sie eine Bitmaske verwenden, um alle Gebäude in einer einzigen Regel zu erfassen.
- Anstatt sich darauf zu konzentrieren, ob ein Adressraum mit dem Heimnetzwerk eines Benutzers in Konflikt geraten könnte, sollten Sie Ihr Design darauf ausrichten, wie er ihn nutzen wird. Wenn es sich beispielsweise um ein Punkt-zu-Punkt-VPN ohne Übersetzung oder Überlastung handelt, durch das zusätzlicher gerouteter Datenverkehr geleitet wird, kann es wichtig sein, kompatible Adressbereiche beizubehalten. Für die meisten Heimanwender spielt die Kollision jedoch keine Rolle, da sie sich von ihrem Endgerät aus verbinden und ihr Gerät ihre Verbindung als Gateway für den gesamten Datenverkehr behandelt. Jede Abweichung hiervon könnte gegen Ihre Nutzungsrichtlinien verstoßen und außerhalb Ihres Unterstützungsumfangs liegen.
- Netzwerke desselben Subnetzes müssen nicht im selben VLAN sein, sollten es aber wahrscheinlich. Die VLAN-ID ist genau das: nur eine Nummer. Sie muss nicht auf allen angeschlossenen Geräten gleich sein, wenn sie sie nicht austauschen, aber ich kann mir keine Szenarien vorstellen, in denen eine inkonsistente VLAN-ID-Struktur von Vorteil wäre. Um zwei verschiedene VLANs desselben Netzwerks miteinander zu verbinden, würden Sie eine Brücke (einen Switch) verwenden. Im Wesentlichen würden Sie einen Switch in mehrere Sub-Switches aufteilen und diese ineffizient auf eine Weise verbinden, die schwer zu warten ist.
- Minimieren Sie unnötiges Routing. Obwohl es schön und logisch sein kann, alle diese Netzwerke zu haben, reicht es nicht aus, einfach davon auszugehen, dass der Router dies unterstützt, wenn ein hohes Datenvolumen über einen Router von Netzwerk A zu Netzwerk B geleitet wird und die Portgeschwindigkeiten ausreichend sind. Beispielsweise hat der Cisco 1941 Dual-Gigabit-Ethernet-Router trotz seiner Dual-Gigabit-Ports nur einen geschätzten Durchsatz von 153 Mbit/s zwischen Netzwerken. (Durchsatzspezifikationen)
- Haben Sie nicht zu wenige Netzwerke (... im Sinne des Widerspruchs). Wenn Sie Ihr Netzwerk nicht in Subnetze aufteilen würden, würde eine Übertragung alle Geräte erreichen. Wenn Sie feststellen, dass bestimmte Gerätegruppen nicht oft direkt kommunizieren müssen, ist dies ein guter Hinweis darauf, dass sie getrennt werden sollten.
- Nutzen Sie horizontale Skalierbarkeit, sowohl innerhalb als auch zwischen Netzwerken. Anstatt einen großen Server für alle Ihre Benutzer zu haben, sollten Sie für jedes Netzwerk einen kleineren Server haben, der nur die Clients bedient. Sie könnten eine gemeinsame Datenquelle nutzen und so auch Ihren Router entlasten. Es gibt jedoch viele Möglichkeiten, horizontale Skalierung zu erreichen.
Ich hoffe, das hilft Ihnen oder gibt Ihnen einige Ideen :)