Aufbau mehrerer 10er Netze

[diptastic]

Hallo,

mich beschäftigt seit einigen Tagen der Aufbau unseres Netzwerks. Vielleicht ist jemand so nett und kann mir weiterhelfen. Ich bin kein Profi.

Also ich habe einen FritzBox-Router von Vodafone. Dahinter ist eine "Ubiquiti Dream Machine Pro" über einen "Exposed Host". Das funktioniert so einigermaßen und befindet sich alles in einem Gebäude.

Mein Wunsch ist es, dass ich mehrere getrennte Netze habe:

1. Privat --> FritzBox
2. HomeOffice --> aktuell Privat
3. Firma 1 --> aktuell Privat
4. Firma 2 mit Hotspot mit 20-400 Geräten --> UDM-Pro

Wie würdet Ihr das gestalten? Sind die Netze aktuell überhaupt getrennt, ein Router sollte die Netze doch trennen oder? Stoße ich bei Firma 2 an eine mögliche Grenze mit den IPs?

Was mich auch in den Fingern juckt, ist das 10er Netz. Also sowas wie 10.0.0.1. Wäre cool, wenn ich sowas hätte wie 10.[Netz].[Host.Host] für jedes Gerät. Ergibt das Sinn? Wäre die Subnetzmaske dann 255.255.0.0. Und müsste dann in jedem Router angegeben werden definiert werden, richtig? Aktuell habe ich:

und

Freue mich auf eure Antworten.
Grüße!

 

[Raijin]

Die Subnetze sollte man in der Tat nicht zu groß machen, einfach aus Prinzip. So groß wie nötig, aber so klein wie möglich. Es gillt im Allgemeinen, den richtigen Mittelweg zu finden. Bei 80 Gästen kann man wohl mit 2 Geräten pro Gast im Schnitt rechnen, maximal. Das sind also 160 IP-Adressen, die bei Vollbelegung benötigt werden. Da ist ein /24 Subnetz mit 254 Host-Adressen vollkommen ausreichend, wenn die Lease Time entsprechend niedrig ist, wie zB die von @Joe Dalton vorgeschlagenen 1-2h.

Aber mit /22 sollte ich mit ca. 1000 Hosts genug über haben für 24h oder spricht etwas dagegen? Wieviele gleichzeitig im Netz sind variiert sehr stark. Wir haben bis zu 80 Gäste die ziemlich zeitgleich anreisen. Plus eigene Geräte. Plus Geräte der Mitarbeiter. Kameras...

Eigene Geräte und Geräte der Mitarbeiter sowie Kameras haben aber nun mal sowas von gar nichts im Netzwerk der Gäste zu suchen... Von sowas rede ich doch die ganze Zeit! In einem befreundeten Hotel, in dem der Besitzer ebenfalls meinte, das alles selbst machen zu können (Fritz-Equipment all the way, regelmäßige Beschwerden), habe ich das mal eindrucksvoll demonstriert. Das Hotel liegt in der Oberpfalz, Bayern, und ich als Hamburger habe während eines Gesprächs mit ihm über das WLAN hinter ihm die HSV-Raute ausgedruckt und während er nachschaute was da aus dem Drucker kam tönte es "Hamburg, meine Perle" aus seiner Sonos-Anlage. Warum? Weil er auch alles in ein Netz gepackt hat. Sogar das Kassensystem (Windows XP) war im selben Netzwerk sowie sein Büro-PC. Ich habe es nicht ausprobiert, aber ich hätte sicherlich noch mehr anstellen können, habe ihm dann aber ein vollständiges Unifi-System inkl. Firewall eingerichtet.

Das ist es wovor ich warne und das ist es was passiert, wenn derjenige, der das einrichtet, zu blauäugig an die Sache herangeht.


Im obigen Beispiel hatte ich genau aus dem Grunde an der UDM2 für das Hotel zwei Netzwerke dargestellt, eines für eigene Geräte, Mitarbeiter und Kameras, während das andere aussschließlich den Gästen vorbehalten ist. So geht die Rechnung mit max 160 Geräten bei 80 Gästen in einem /24 Subnetz mit 254 IP-Adressen auch auf. Und selbst wenn das nicht ausreichen sollte, weil die Clientel beispielsweise aus Jugendlichen besteht, die vielleicht noch Tablet und Laptop mitbringen, dann bohrt man das Subnetz auf /23 auf und hat 510 Adressen, aber /22 ist sinnfrei.


Der Hintergrund warum man Subnetze passend gestalten sollte, ist u.a. Fernzugriff via VPN. Überschneidende Subnetze auf beiden Seiten der VPN-Verbindung sind Gift für selbige. Wenn du also mal in einem Hotel bist und es daheim Probleme gibt und du via VPN einloggen willst, das dortige Hotel aber überschneidende Subnetze verwendet, wird es haarig. Das Beispiel aus #19 beinhaltet bereits 5 Subnetze @ /24. Ich habe vergleichsweise ungewöhnliche Subnetze gewählt, um die Trefferquote einer Überschneidung zu minimieren (geht aber noch besser), aber um mal bei deinem eigenen Beispiel aus #1 zu bleiben:
Mit 10.0.0.0/16 wie du es dort vorschlägst, "blockierst" du bei VPN gewissermaßen schon den kompletten 10.0.x.y Bereich, 65.536 IPs, während in meinem Beispiel lediglich 1280 blockiert wären. Und ich könnte aus dem Stegreif gefühlt 5 Hotels nennen, aus denen keine VPN-Verbindung zu dir nach Hause möglich wäre, weil die ebenfalls 10.0..... verwenden.

Wähle deine Subnetze daher möglichst kreativ. Nimm beispielsweise Geburtstage zur Orientierung. Man darf auch gerne die Subnetze an der UDM1 in 10er Subnetze legen, während man bei UDM2 172er Subnetze nimmt. Man darf auch wild mischen solange man sich im Rahmen von RFC1918 bewegt (siehe #17 Mitte)

 

[foo_1337]

Wenn du in einem Hotel bist, zu deinem VPN connectest und die lokale IP Range des Hotels ein Problem darstellt, hast du etwas falsch gemacht. Du musst im Hotel ausschließlich den GW erreichen. Der Rest kann in den Tunnel gerouted werden. Sprich: Die Gateway IP ist das einzige, was du dann in deinem VPN nicht erreichen könntest.

 

[Raijin]

Und damit willst du jetzt was genau sagen, @foo_1337 ? Dass es Jacke wie Hose ist welches Subnetz man verwendet? Und wie genau würdest du das Routing dann konfigurieren? Schließlich gibt es bereits eine automatische Route für das lokale Subnetz und du müsstest mit der Metrik arbeiten, um eine identische Route über eine andere Schnittstelle zu routen. Abgesehen davon gibt es ggfs nur Teilüberschneidungen der Subnetze, die man unter Umständen gesondert behandeln muss, weil sich dann die Subnetzmaske lokal/remote unterscheidet und entsprechende Routen in der Routingtabelle unterschiedlich priorisiert werden - bevor die Metrik überhaupt herangezogen wird.

Fakt ist, dass man mit sinnvoll gewählten Subnetzen im eigenen Netzwerk solchen Fummeleien grundsätzlich vorbeugen kann, insbesondere wenn man nur mäßiges Wissen über die Funktionsweise der Routingtabelle hat., wie es beim TE ja anzunehmen ist.

 

[foo_1337]

Dass es Jacke wie Hose ist welches Subnetz man verwendet?

Ja, natürlich ist es Jacke wie Hose. Solange ich RFC1918 verwende, kann ich nie sicher verhindern, dass die Netze doppelt vergeben werden. Wenn ich nun krampfhaft versuche, irgendwelche Ranges zu nehmen, die vermutlich niemand anderes nimmt, hat das schon was esoterisches. Wer das effektiv verhindern will, nutzt IPv6 oder ist in der Glücklichen lage, genug v4 Prefixe zu besitzen.

Schließlich gibt es bereits eine automatische Route für das lokale Subnetz und du müsstest mit der Metrik arbeiten, um eine identische Route über eine andere Schnittstelle zu routen.

Ich kenne keine Implementation, die es nicht erlaubt, dass die Route in den Tunnel die local preference overruled. Das einzige was bleibt ist der Weg zum Gateway, der Rest geht in den Tunnel. Was sollten denn dann die Firmen machen, die 192.168.0/24 oder 192.168.2/24 nutzen? Ihren Mitarbeitern sagen, dass sie zuhause renumbern sollen?

Abgesehen davon gibt es ggfs nur Teilüberschneidungen der Subnetze, die man unter Umständen gesondert behandeln muss, weil sich dann die Subnetzmaske lokal/remote unterscheidet und entsprechende Routen in der Routingtabelle unterschiedlich priorisiert werden - bevor die Metrik überhaupt herangezogen wird.

Ja, man kann das ganze auch unnötig komplex machen. Deiner Logik nach dürften wohl 95% aller Unternehmesvpn nicht funktionieren, denn die beiden oben genannten Netze sind nach wie vor sehr häufig anzutreffen.

Fakt ist, dass man mit sinnvoll gewählten Subnetzen im eigenen Netzwerk solchen Fummeleien grundsätzlich vorbeugen kann

Nein, das ist kein Fakt sondern ein Lotteriespiel. Es kann klappen, muss es aber nicht. Und als Fummelei würde ich das nicht betrachten, sondern als gängige Praxis. Bin ich ein Unternehmen, konfiguriere ich den Kram so, dass die Mitarbeiter alles was ich brauche in den Tunnel gerouted bekommen. Egal ob das Netz lokal bereits in Verwendung ist oder nicht.
Und wenn du tatsächlich dieser Vorangehensweise glaubst, ist es völlig egal, ob du ein /24 oder /22 nutzt, denn die Wahrscheinlichkeit gleiche Netze zu haben, erhöht sich dadurch nur sehr wenig. Der Aufwand, später zu renumbern ist dann viel größer, wenn man

nur mäßiges Wissen über die Funktionsweise der Routingtabelle hat., wie es beim TE ja anzunehmen ist.

 

[Raijin]

Was sollten denn dann die Firmen machen, die 192.168.0/24 oder 192.168.2/24 nutzen?

Deiner Logik nach dürften wohl 95% aller Unternehmesvpn nicht funktionieren, denn die beiden oben genannten Netze sind nach wie vor sehr häufig anzutreffen.

Steile These. In Unternehmen mit halbwegs vernünftiger IT gibt es solche Subnetze nicht.

Wenn ich nun krampfhaft versuche, irgendwelche Ranges zu nehmen, die vermutlich niemand anderes nimmt, hat das schon was esoterisches.

Was heißt krampfhaft? Dagegen halte ich:

"Wenn ich blauäugig einfach immer die Standardeinstellung meines Routers verwende, hat das schon etwas Faules"

Wem tut es denn weh, sich bei der Auswahl des Subnetzes auch nur 3 Sekunden Gedanken zu machen? Wo ist das Problem?

Ich kenne keine Implementation, die es nicht erlaubt, dass die Route in den Tunnel die local preference overruled.

Das wäre die Metrik, die aber als allerletztes überhaupt zur Routingentscheidung herangezogen wird und auch nur dann, wenn zwei gleich-spezifische Routen in Frage kämen. Ist eine Route spezifischer, wird die Metrik gar nicht angefasst.

Mit erweiterten Routing-Mechanismen wie PBR kann man sicherlich viel machen. Das setzt aber ein Betriebssystem voraus, das PBR unterstützt, was zB bei Windows nicht der Fall ist. Windows routet ausschließlich nach Ziel-IP vs Routensubnetz+Maske und erst wenn da 2 gleichwertige Routen auftauchen, kommt die Metrik. Wenn du also einfach das lokale Subnetz zum VPN-Gateway routest, musst du mindestens die Metrik für den VPN-Adapter kleiner halten als die Metrik der physischen Schnittstelle.

 

[foo_1337]

Steile These. In Unternehmen mit halbwegs vernünftiger IT gibt es solche Subnetze nicht.

Ebenfalls steile These Stichwort: Gewachsene Strukturen. Gibt's öfter als man meint.

"Wenn ich blauäugig einfach immer die Standardeinstellung meines Routers verwende, hat das schon etwas Faules"

Die Router, die ich in Unternehmen einsetze, haben eine Standardeinstellung. Aber das tut auch nix zur Sache, denn:

Wem tut es denn weh, sich bei der Auswahl des Subnetzes auch nur 3 Sekunden Gedanken zu machen? Wo ist das Problem?

Und du verlässt dich darauf, dass du jetzt z.B. 10.197.83.0/24 konfigurierst, sich das bestimmt niemals mit einem lokalen Netz eines Hotels überlappt? Die Wahrscheinlichkeit ist zwar gering, aber ausschließen würde ich es nicht.

Das wäre die Metrik, die aber als allerletztes überhaupt zur Routingentscheidung herangezogen wird und auch nur dann, wenn zwei gleich-spezifische Routen in Frage kämen. Ist eine Route spezifischer, wird die Metrik gar nicht angefasst.

route add -host x.x.x.x -interface (ppp0|tun0). Die VPN Clients sind so schlau das duplicate Netz zu erkennen und für jeden im Netz Host einen einzelnen routing eintrag zu machen und das Gateway auszulassen. Somit overrulest du die local preference, da die Hostrouten zuerst genommen werden. Wenn der Client das nicht kann, muss man das eben scripten.

Windows routet ausschließlich nach Ziel-IP vs Routensubnetz+Maske und erst wenn da 2 gleichwertige Routen auftauchen, kommt die Metrik. Wenn du also einfach das lokale Subnetz zum VPN-Gateway routest, musst du mindestens die Metrik für den VPN-Adapter kleiner halten als die Metrik der physischen Schnittstelle.

Siehe oben, das funktioniert auch unter Windows so. Man benötigt weder Metriken noch pbr oder gar ein dynamisches routing Protokoll.

 

[Raijin]

Ebenfalls steile These Stichwort: Gewachsene Strukturen. Gibt's öfter als man meint.

Dann haben wir eben beide steile Thesen

Die VPN Clients sind so schlau das duplicate Netz zu erkennen und für jeden im Netz Host einen einzelnen routing eintrag zu machen und das Gateway auszulassen. Somit overrulest du die local preference, da die Hostrouten zuerst genommen werden.

Puh, schon bei einem /24er Subnetz sind das schlanke 253 Routen. Wenn es größere Subnetze sind, entsprechend mehr. Bei unserem Konzern-VPN wären das schlanke 65k Einträge in der Routingtabelle. Nicht schlecht. Würde mich ehrlich gesagt gar nicht wundern, wenn Microsoft da irgendwo ein Softcap eingebaut hat, weil Bill mal meinte "mehr als 100 Routen braucht eh keiner am PC".

Und du verlässt dich darauf, dass du jetzt z.B. 10.197.83.0/24 konfigurierst, sich das bestimmt niemals mit einem lokalen Netz eines Hotels überlappt? Die Wahrscheinlichkeit ist zwar gering, aber ausschließen würde ich es nicht.

Klar kann es trotzdem passieren, aber die Wahrscheinlichkeit ist dermaßen gering. Schon bei 192.168.3.0/24 sinkt das Konfliktpotential massiv, da zumindest mir kein Router mit diesem Standard-Subnetz geläufig ist.


Wie auch immer, jeder kann machen was er für richtig hält. Ich rate grundsätzlich dazu, sich bei der Auswahl des Subnetzes Gedanken zu machen, selbst wenn kein VPN im Spiel ist. Warum? Warum denn nicht? Man minimiert etwaige Konflikte, wenn man sich eben nicht mit so mit Routing auskennt und/oder der VPN-Client das nicht automatisch tut. Aus dem Stegreif wäre mir jetzt beispielsweise nicht bewusst, dass zB OpenVPN da in irgendeiner Form etwas automatisch macht, abgesehen von den /1er Routen bei redirect-gateway def1. Von WireGuard habe ich (noch) keine Ahnung, weil ich es bisher nicht eingesetzt habe.

 

[foo_1337]

Puh, schon bei einem /24er Subnetz sind das schlanke 253 Routen. Wenn es größere Subnetze sind, entsprechend mehr. Bei unserem Konzern-VPN wären das schlanke 65k Einträge in der Routingtabelle.

Das macht er doch nur bei dem Subnetz, das lokal schon existiert. Der Rest sind /xyz Netzrouten.
Bei Pulse Secure ist das sogar default.

Wie auch immer, jeder kann machen was er für richtig hält. Ich rate grundsätzlich dazu, sich bei der Auswahl des Subnetzes Gedanken zu machen, selbst wenn kein VPN im Spiel ist.

Ich auch, keine Frage. Ich würde es nur nicht als Showstopper hinstellen, wenn es nicht so ist. Der oben beschriebene Weg hat ja auch Nachteile, wenn man z.B. nen lokalen IP Drucker hat. Dann muss man sich immer disconnecten, wenn man druckt (oder spielt selbst an der Routing Table rum)