Aufbau Unternehmensnetzwerk

Es gibt 20 Antworten in diesem Thema, welches 1.813 mal aufgerufen wurde. Der letzte Beitrag () ist von Tomcat.

  • Hallo zusammen,


    als im Dezember endlich das "GO" durch die Geschäftsführung kam, die schon lange angedachten neuen Netzwerkkomponenten auch kaufen zu können, hatte dies zwar Euphorie ausgelöst - der Mund blieb mir dann aber doch eher etwas offen, als ich sah, wieviel das letzten Endes war, als der Lastenaufzug zweimal hoch und runter musste, um das Material komplett angeliefert zu bekommen. :smiling_face:

    Ich habe allerdings kein Bild davon gemacht :grinning_face_with_smiling_eyes:


    Mit diesem Foreneintrag möchte ich einige Dinge zusammentragen, um hieraus gerne eine kleines To-Do abzuleiten, was man zum Ausrollen von UI im Unternehmen allen unternehmen muss. Zunächst jedoch wende ich mich mit konkreten Fragen an euch.


    1. Installation von UDM-SE / UDM-Pro

    Bei der Installtion, die größtenteils App-gestützt erfolgen kann, habe ich mich in der Vergangeheit immer zweiter Videos bedient, die die Installtion gut beschreiben und auch die ersten Schritte gut aufgreifen:


    --> Schon etwas älter, die Videoreihe setzt sich aber zudem auch mit der Initialisierung von Netzwerken auseinander, was aber nur rudiementäre Optionen abdeckt.


    --> Aus 2023 mit einem guten und schnellen Einstieg in die Materia


    2. Weiterführende Netzwerkeinrichtung --> Hier kommen die Fragen

    Ich habe Technik für zunächst 4 Niederlassungen gekauft (von so ca. 70 Stück), und ein Neubauprojekt dient als "Erstlingswerk". Der Komplex verfügt zudem über einen Nebenbau, der - ich kann hier nur den Kopf schütteln (und die IT hat das mehrfach eingefordert und angemahnt) - über keine Netzwerkverbindung zum Hauptgebäude verfügt (wurde dann letzten Endes "vergessen"). Das werde ich in der Folgezeit ändern lassen. Aber Momentan haben wir ein Gebäude A und ein Gebäude B.

    Beide Gebäude sollen über ein Netzwerk verfügen, und hier sich auch die gleichen WLAN-Netz teilen und wenn möglich (haha etwas dümlich ohne direkte Verbindung) auch noch den gleichen DHCP teilen.


    Ich denke daher (wir können auch kein Richt-Beam verwenden, um von A nach B zu kommen), dass wir ein Site-to-Site-VPN schaffen müssen. Hier habe ich ein paar Verständnisprobleme.

    Bisher nutzen wir über einen NAS-Anbieter das VPN (der Server ist nicht auf dem NAS) und fahren damit recht gut, weil wir auch viele Außendienstler haben, die mittels VPN auf den Server zugreifen können.


    Frage 1:

    Kommen sich Site-to-Site und VPN-Nutzer von extern in die Quere, oder kann ich beiden parallel fahren lassen. Die UDM-Pro unterstützt VPN, dass ich auch zu Hause nutze - aber ich weiß nicht, ob das parallel zu Site-to-Site klappt, oder ob sich beode VPN gegeneinander auschließen.


    Frage 2:

    Beiden Gebäude sollen im Netz sein, Sagen wir mal, dass wir für Gebäude A 192.168.9.x nehmen und für Gebäude B 192.168.1.x bzw. in beiden Gebäuden diese Netze gegeben sein sollten. Nennen wir das 192.168.9.x-Netz einfach mal Mitarbeiter bzw. MA-Netz und das 192.168.1.x-Netz einfachheithalber K-Netz für Kunden. Beides sind virtuelle Netze. Das MA-Netz initialisiere ich quasie als erstes als Main-Network.

    Wie erreiche ich nun, dass beide Netze in beiden Gebäude gegeben sind, und die DHCP-Vergabe sich nicht in die Quere kommt? Ich wil erreichen, dass in beiden Gebäudeteilen MA im Netz sind und eine IP bekommen, sich aber dann nicht gegenseitig blockieren (weil die gleiche IP zugewiesen wurde)

    Gibt es eine Möglöichkeit die eine UDM-SE quasie nur als "Slave" zu betreiben, die einfach die Site-to-Site abdeckt, alle DHCP-Vergaben aber von der Master-UDM-SE im Hauptgebäude gesteuert wird, oder wie kann ic das praktisch umsetzen. Zudem will ich ja, dass ein Mitarbeiter im Gebäude B im MA-Netz auf das MA-Netz in Gebäude A bzw. den dortigen Server zugreifen kann.


    Gleiches auch bei den Kunden. Die sollen sich zwischen den beäuden frei bewegen können, ohne Gefahr zu laufen, dass sie mit ihren Geräten doppelte IPs bekommen und dann nicht in einemd er beiden Gebäuden ins Netzwerk kommen.


    Frage 3:

    Einbindung in eine Übersicht: Kann man die verschiedenen Standorte in einer Übersicht entsprechend auseinanderhalten? Wir nutzen bisher AVM. Da hat man eine große Überischt der Standort und kann alles mit einem Account sehen. Über UI scheint es für solche Zwecke einen Enterprise-Zugriff zu geben. Hat da jemand mehr Ahnung, ob ich hier auch User anlegen kann (Mitarbeiter der IT) , die dann die Technik warten können?


    Weitere Fragen schreiben ich dann in einen neuen Eintrag. Ergebnisse aus den Fragen schreibe ich dann in einen To-Do um.


    Vielen Dank im Voraus für Eure Mithilfe.

  • 1. Installation von UDM-SE / UDM-Pro

    Bei der Installtion, die größtenteils App-gestützt erfolgen kann, habe ich mich in der Vergangeheit immer zweiter Videos bedient, die die Installtion gut beschreiben und auch die ersten Schritte gut aufgreifen:

    Ich mache sowas am liebsten über die Web Oberfläche aber das ist Geschmackssache.


    Frage 1:

    Kommen sich Site-to-Site und VPN-Nutzer von extern in die Quere, oder kann ich beiden parallel fahren lassen. Die UDM-Pro unterstützt VPN, dass ich auch zu Hause nutze - aber ich weiß nicht, ob das parallel zu Site-to-Site klappt, oder ob sich beode VPN gegeneinander auschließen.

    Das sind ja mal Grundlegend unterschiedliche Techniken, ich kann mir nicht vorstellen, dass dies nicht funktioniert.

    Beiden Gebäude sollen im Netz sein, Sagen wir mal, dass wir für Gebäude A 192.168.9.x nehmen und für Gebäude B 192.168.1.x bzw. in beiden Gebäuden diese Netze gegeben sein sollten. Nennen wir das 192.168.9.x-Netz einfach mal Mitarbeiter bzw. MA-Netz und das 192.168.1.x-Netz einfachheithalber K-Netz für Kunden. Beides sind virtuelle Netze. Das MA-Netz initialisiere ich quasie als erstes als Main-Network.

    Wie erreiche ich nun, dass beide Netze in beiden Gebäude gegeben sind, und die DHCP-Vergabe sich nicht in die Quere kommt? Ich wil erreichen, dass in beiden Gebäudeteilen MA im Netz sind und eine IP bekommen, sich aber dann nicht gegenseitig blockieren (weil die gleiche IP zugewiesen wurde)

    Gibt es eine Möglöichkeit die eine UDM-SE quasie nur als "Slave" zu betreiben, die einfach die Site-to-Site abdeckt, alle DHCP-Vergaben aber von der Master-UDM-SE im Hauptgebäude gesteuert wird, oder wie kann ic das praktisch umsetzen. Zudem will ich ja, dass ein Mitarbeiter im Gebäude B im MA-Netz auf das MA-Netz in Gebäude A bzw. den dortigen Server zugreifen kann.


    Gleiches auch bei den Kunden. Die sollen sich zwischen den beäuden frei bewegen können, ohne Gefahr zu laufen, dass sie mit ihren Geräten doppelte IPs bekommen und dann nicht in einemd er beiden Gebäuden ins Netzwerk kommen.

    Es ist doch vollkommener quatsch überall die gleichen Netze zu fahren... das macht die Sache nur unübersichtlich und fehleranfällig.

    Wenn du die S2S Verbindung hast dann ist es ja eh "verbunden"


    Frage 3:

    Einbindung in eine Übersicht: Kann man die verschiedenen Standorte in einer Übersicht entsprechend auseinanderhalten? Wir nutzen bisher AVM. Da hat man eine große Überischt der Standort und kann alles mit einem Account sehen. Über UI scheint es für solche Zwecke einen Enterprise-Zugriff zu geben. Hat da jemand mehr Ahnung, ob ich hier auch User anlegen kann (Mitarbeiter der IT) , die dann die Technik warten können?

    Ja über das Portal, da werden alle deine Sites aufgelistet.



    Was mich aber stutzig macht, ist die Tatsache, dass du als IT-ler Videos zur Einrichtung benötigst... mit etwas Fachkenntnis ist das doch alles selbsterklärend über die schöne Klicki Bunti GUI.

    Ich hoffe, dass du dich mit diesem Projekt nicht übernimmst, da ich hier irgendwie das Gefühl beim lesen bekommen habe, das da auch einige Kenntnisse fehlen.

    Bitte nehme die Aussage jetzt nicht zu persönlich. Ich drücke dir die Daumen, dass die Umsetzung problemlos abläuft.

    Gruß

    defcon

  • Es ist doch vollkommener quatsch überall die gleichen Netze zu fahren... das macht die Sache nur unübersichtlich und fehleranfällig.

    Wenn du die S2S Verbindung hast dann ist es ja eh "verbunden"

    Hier stimme ich defcon zu, das es sehr unübersichtlich wird.
    Mal ganz davon abgesehen ob es überhaupt funktionieren würde auf beiden Seiten den gleichen Adressbereich zu haben bei einer Site-to-Site-VPN Verbindung...

    Frage 2:

    Beiden Gebäude sollen im Netz sein, Sagen wir mal, dass wir für Gebäude A 192.168.9.x nehmen und für Gebäude B 192.168.1.x bzw. in beiden Gebäuden diese Netze gegeben sein sollten. Nennen wir das 192.168.9.x-Netz einfach mal Mitarbeiter bzw. MA-Netz und das 192.168.1.x-Netz einfachheithalber K-Netz für Kunden. Beides sind virtuelle Netze. Das MA-Netz initialisiere ich quasie als erstes als Main-Network.

    Wie erreiche ich nun, dass beide Netze in beiden Gebäude gegeben sind, und die DHCP-Vergabe sich nicht in die Quere kommt? Ich wil erreichen, dass in beiden Gebäudeteilen MA im Netz sind und eine IP bekommen, sich aber dann nicht gegenseitig blockieren (weil die gleiche IP zugewiesen wurde)

    Gibt es eine Möglöichkeit die eine UDM-SE quasie nur als "Slave" zu betreiben, die einfach die Site-to-Site abdeckt, alle DHCP-Vergaben aber von der Master-UDM-SE im Hauptgebäude gesteuert wird, oder wie kann ic das praktisch umsetzen. Zudem will ich ja, dass ein Mitarbeiter im Gebäude B im MA-Netz auf das MA-Netz in Gebäude A bzw. den dortigen Server zugreifen kann.


    Gleiches auch bei den Kunden. Die sollen sich zwischen den beäuden frei bewegen können, ohne Gefahr zu laufen, dass sie mit ihren Geräten doppelte IPs bekommen und dann nicht in einemd er beiden Gebäuden ins Netzwerk kommen.

    Wie defcon schon geschrieben hat, sind beide Gebäude miteinander "Verbunden".
    Es wäre besser wenn du z.B. in Gebäude A für das MA-Netz 192.168.10.x & K-Netz 192.168.11.x und in Gebäude B für das MA-Netz 192.168.20.x & K-Netz 192.168.22.x verwendest. (Adressbereich ist nur ein Beispiel)
    Damit man von Gebäude A MA-Netz auf das Gebäude B MA-Netz zugreifen kann, sind wenige Firewall oder Traffic Regeln zu konfigurieren. (Umgekehrt das selbe)

    Ich habe selbst nur eine VPN-Client Verbindung bei mir konfiguriert und Traffic Regeln erstellt, um den zugriff zu begrenzen, da ich keine Site-to-Site-VPN Verbindung benötige.

  • Mach dir mal einen Netwzerkplan. Abteilungen,...... alles ordentlich trennen

    Hier noch ein Video (manche Menüpunkte sind inzwischen woanders, aber egal) über die vlan auftrennung. Das thema vlan solltest du dir sowieso genauer zu gemüte führen, denn das ist bei einem Firmennetzwerk essentiell.

    Der Kanal hat noch einige Videos mehr zu dem thema. und ignorier dass es ne UDR ist, die Software ist identisch

  • Wenn die Gebäude per VPN verbunden werden, dann schliesst sich das "ich möchte auf allen Seiten die gleichen Netzwerke" aus. VPN routet und das geht nicht wenn auch nur ein IP Bereich mehrfach vorhanden ist. Das gilt bereits bei einem Netzwerk pro Standort. Dann sind die Netzwerke aber sowieso nicht die gleichen Netzwerke nur weil sie den gleichen Namen (IP Bereich) tragen.


    Andere Sache wäre die Gebäude mit LWL zu Verbinden. Dann kannst Du ja auch über alle Switche die Netze verfügbar machen. Aber das ist vermutlich nicht gegeben.

  • Respekt über deinen Mut Kolungate, dass in einem Unternehmen einzubauen.

  • Hallo zusammen


    Vielen Dank zunächst für eure Hilfestellungen :smiling_face: Ich werde mal versuchen in Teilen zu Antworten.


    defcon Ja es ist etwas ganz neues, eine "neue" Technik zu implementieren, die man zunächst nur im privaten nutzt. Es ist natürlich auch "heikel" mit der neuen Technik gleich ganz neue ANwendungen umzusetzen, die man vorher noch noch gar nicht experimentell im privaten Umfeld realisiert hat, wie S2S. Da ich aus dem beitrag auch ein To-Do ableiten will, ist das aufzeigen von Videos zur Erstinstallation eben nicht "trivial", da es meiner Meinung nach genug User gibt, die Gleiches wollen und ebenso verunsichert sind am Anfang. :smiling_face:


    defcon, Timo19731, DoPe ... JA ich weiß. Die EInstellungen im S2S in der UDM-Pro sind hier schon eindeutig:


    Die Frage war eher eine Vergewisserung. So wie ich das im Auswahlfeld deute, kann ich auswählen, welche Netzwerke ich auf der "anderen Seite" ebenfalls haben möchte. So kann ich wohl veranlassen, dass an der "Gegenstelle" bestimmte Netze vorhanden sind und manche nicht. Ich hatte mich nur gefagt, wer dann der DHCP ist - aber die Frage wird insofern schon beantwortet, als dass das auszuwählende Netzwerk in UI ja bereits ausreichend Konfiguriert ist, d.h. hier steh ja schon ein DHCP drinnen - das ist dann die UDM-SE in Gebäude A (beispielsweise). Ich mutmaße daher, dass bei Anfrage nach einer IP (User in Gebäude B) die UDM-SE in B die UDM-Se in A anfrägt, und diese eine IP mitteilt. So wäre es ja auch der Fall, wenn alles in einem Netzwerkt ist, was bei S2S ja sinnigerweise der Fall ist.

    Und die Konfiguration samt Hilfe-Artikel: https://help.ui.com/hc/en-us/articles/12646699585047 suggeriert mir, die Beantwortung der restlichen Fragen. Mh mal lieber den Hilfeartikel lesen sollenm, als sioch hiier die Blöse zu geben :grinning_squinting_face: :grinning_squinting_face:


    thghh : Vielen Dank. Ich denke die Herausforderung spornt mich an.


    Im Großen und Ganzen haben wir aber an den STandorten eben NICHT die Gegebenheit, S2S zu realisieren. Ich würde es aber dennoch gerne machen, d.h. alle Standorte einer Region in ein S2S zu setzen, sodass wir auch die lokalen Server zurückbauen können - das könnte man ja auch ohnehin schon, wenn wir alle User per VPN-Clients, an den Hauptserver anbinden - was klar leichter wäre.... :winking_face:


    Vielen Dank. Ich werde jedoch weiterhin Fragen stellen zum Projekt - auch wenn ich mich da dem Verdacht ausgesetzt sehe, noch WIssenlücksen zu haben :grinning_face_with_smiling_eyes:


    mfg

    Kolungate

    Einmal editiert, zuletzt von Kolungate ()

  • Dein Verständnis über S2S, routing, DHCP ist grundlegend falsch! Bitte belese Dich über die Grundlagen, bevor Du solch ein Projekt angehst. Das wird sonst wohl daneben gehen.

    Hallo

    Das kommt eigentlich aus einem Beitrag von UI in deren Supportforum. Also man kann DHCP via VPN Site-to.Site weiterleiten. Nur UI selbst empfiehlt das nicht, da im Ausnahmefall (also wenn bei mir Gebäude A ausfällt) in Gebäude B niemand mehr per DHCP ins Netzwerk kommt.

    --> https://community.ui.com/quest…96-4188-9622-7c0a51536895


    Dennoch dämmert mir gerade das eigentliche Problem: Adressierung in den gleichen Netzen in A und B. Wenn ich in A bin und z.B. 192.168.10.4 aufrufe - es das 192.168.10.x-Netz aber in A und B gibt - werde ich nicht bei 192.168.10.4 in B rauskommen. Egal ob VPN oder Site-to-Site kann ich keine doppelten IP-Netzwerke haben. AUSSER ich habe in A und B nicht die gleichen IP-Adressen in Verwendung - zumindest ist das bei VPN-over-QNAP der Fall? Wenn ich mittels VPN zugreife, und ich habe lokal das Netzt 192.168.10.x und greife auf ein Netz dergleichen Gestalt zu, dann komme ich i.d.R. nicht auf die Zieladresse raus, wenn diese schon mit einem PC (beispielsweise) belegt ist. Da QNAP im Hintergrund aber eine Zwischen-Ebene aufbaut (10.8.0.x) kann ich dennoch auf 192.168.10.x (am Standort B) zugreifen, wenn ich mich gleichermaßen in 192.168.10.x am Standort A aufhalte.


    Es würde nur gehen, wenn ich meine 192.168.10.x-Netze hinter anderen Netzen verstecke --> https://sysadms.de/2018/09/17/…-vpn-bei-gleichen-netzen/

    Ich glaube auch zu verstehen, dass das Site-to-Site im eigentlichen Sinne macht. Wenn ich mir gerade das Video zu SiteMagc ansehen (-->

    ), ist das zumindest der Weg. Ich brauche an allen Standorten verschiedene Netze - also 192.168.n.x, 192.168.n-1.x, 192.168.n-2.x und 192.168.n-3.x Bei SiteMagic kann ich also zwischen den Netzen aufeinanderzugreifen, als befände ich mich in einem Netzwerk.


    Das scheint bisher mein Denkfehler gewesen zu sein: Ich nahm an, dass Site-to-Site grundsätzlich gleiche Netzwerke habe, und damit auch die Netzwerke gleich wären - also überall die 192.168.10.x gegeben wäre. Das ist allerdings nur die User-Sicht (wenn man sich keine Mühe macht das Konstrukt dahinter zu verstehen. Site-to-Site und SiteMagic machen diese unterschiedlichen Netze eben als User durchgängig/durchlässig.... mmh WOW das würde ja mehr Sinn machen als Vorher :grinning_face_with_smiling_eyes: @kollidierende IP-Netze der gleichen Art.


    Mit

    wurden mir erstmal alle Fragen beantwortet. Ich melde mich erneut, wenn ich eine Frage habe und bedanke mich zunächst erstmal bei der Community.


    Mfg

    3 Mal editiert, zuletzt von Kolungate ()

  • Kolungate

    Hat das Label von offen auf erledigt geändert.
  • Um Dir vernünftig helfen zu können wäre es sinnvoll, wenn Du folgende Dinge bereitstellen würdest (Diese solltest Du auch eigentlich schon haben, bevor man so ein Projekt plant):

    • Welche Komponenten hast Du
    • Wo möchtest Du welche Komponenten verwenden
    • Grobe Netzwerkübersicht: Gebäude / Standorte / Verbindungen untereinander / WAN / VPN / etc.
    • Gewünschte Netzwerke: LAN / WLAN / VLAN und wie sollen die Zugriffsberechtigungen sein

    Ich sehe das ganze Projekt auch etwas kritisch. Wer ein Unternehmensnetzwerk mit mehreren Standorten aufbauen möchte, sollte eigentlich ohne YouTube-Anleitungen auskommen, vor allem wenn man diese schon für die grundlegende Installation benötigt werden.


    Ich würde Dir empfehlen externe Hilfe in Anspruch zu nehmen.

    30 Sites - 500 APs - 150 Switche - EdgeRouter - UXG-Pro - UDM-Pro - USG-PRO-4 - OPNsense - IPUs

  • :smiling_face:

    hey Leute...


    Also wenn sich die "Hilfe" darin erschöpft dem Fragenden ständig vorzuhalten, dass er Youtube-Anleitungen anschaut oder man es kritisch sehe, dann sollte man ggf. das Forum umbenennen. Schade. In der englisch-sprachigen Community habe ich meine Fragen beantwortet bekommen. An dieser Stelle ziehe ich daher meine Frage hier zurück und werde in naher Zukunft auch erstmal keine weitere Frage stellen.


    Ich persönlich bin Quer-Einsteiger und auch wenn die IT-Administratoren-Kaste sich hier wohl als geschlossene, erlauchte Gruppe definiert, so ist mir das Prinzip fremd. Hätte ich früher zu meinen Studenten gesagt "Hey du verstehst das Gram-Schmidtsches Orthogonalisierungsverfahren nicht - dann geh sterben du Opfer: ich sehe das kritisch, dass du die LA-Vorlesung packst...", dann hätte ich gute Studierende in die Wüste geschicht, aus denen heute was geworden ist.


    JA ich verstehe natürlich eure Bedenken und sie wurden gehört. Ich, für meine Seite bin jedoch der Auffassung, dass man die Kirche auch mal im Dorf lassen sollte. EIn Projekthilfe-Forum bzw. die entsprechende Kategorie in diesem Forum lebt meiner Meinung nach von qualifizierenden Beiträgen. Wenn ich mich irre, dann bin ich natürlich ein Verirrter. :smiling_face:

    Ich werde jetzt einfach mal das Projekt weiter betreiben, indem ich die Standorte zunächst. getrennt belasse. Die User mit den Zugriffen in die anderen netze läse ich erstmal mit einem VPN-Server und Client-Zugriff.

    Mein eigentliches Anliegen realsiere ich erstmal in einer Testarea und wende das an, was mir die englisch-sprachige Community mit auf den Weg gegeben hat. ich denke, dass ich alles soweit habe, um es an den Start zu bringen. Aber vielleicht schadet es nicht, sich noch etwas zu belesen.


    usr-adm: Natürlich habe ich einen Plan und die entsprechenden Dinge ausgearbeitet - nur hier an dieser Stelle wollte ich es eigentlich erstmal nur verbalisieren.


    Ich wünsche noch eine schöne Zeit. Vielen Dank erstmal an dieser Stelle. Beitrag kann geschlossen werden.

  • Also wenn sich die "Hilfe" darin erschöpft dem Fragenden ständig vorzuhalten, dass er Youtube-Anleitungen anschaut oder man es kritisch sehe, dann sollte man ggf. das Forum umbenennen. Schade.

    Das ist ja erst mal nicht böse gemeint. Aber jeden Tag werden x-Themen bzgl. Hilfestellung erstellt. Einige User hier sind sehr aktiv und haben schon viele "überforderte" bzw. "übermotivierte" Projektstarter betreut. Man erkennt aber recht schnell, ob das Projekt realisierbar ist oder nicht.


    EIn Projekthilfe-Forum bzw. die entsprechende Kategorie in diesem Forum lebt meiner Meinung nach von qualifizierenden Beiträgen.

    Zu einem qualifizierten Beitrag gehört aber auch, den Helfenden gewissen Informationen zur Verfügung zu stellen. Vor allem bei einem so großen Projekt benötigt man einige Informationen um das ganze Projekt zu überschauen und planen zu können. Nur so kann man Tipps und Verbesserungen einbringen.


    Weiterhin muss man auch damit leben, dass kritische Fragen gestellt werden, oder man auf gewissen Fehler hingewiesen wird. Anhand Deiner Fragen ist aber schon ersichtlich geworden, dass Dir grundlegendes Wissen im Bezug auf komplexe Netzwerke fehlt.


    Da Du das ganze auch nicht privat macht, sondern für ein Unternehmen, sind kritische Hinweise mehr als berechtigt.


    Wenn Du gezielte Fragen hast, kannst Du diese natürlich gerne stellen.

    30 Sites - 500 APs - 150 Switche - EdgeRouter - UXG-Pro - UDM-Pro - USG-PRO-4 - OPNsense - IPUs

  • Du hast Dir da ja ein schönes Projekt herausgesucht Kolungate:smiling_face_with_heart_eyes: . Klingt spannend. Ob die UniFi-Produkte in einem so großen Netzwerk die richtige Wahl waren bleibt noch abzuwarten. Ich empfehle weiters das nicht allein (ein Mitarbeiter) aufzubauen - und zu verwalten. Bei dem Vorhaben kannst Du sicher noch ein oder gar zwei Kollegen brauchen, damit Du auch mal beruhigt in den Urlaub fahren kannst. Ich habe auch Spaß an Netzwerken, aber nur im privaten Umfeld. Ich bin froh, dass ich das bei meinem Arbeitgeber nicht machen muss, auch wenn das sicher auch Spaß machen würde.


    Um es aber noch einmal klar zu stellen:

    • Wenn Du ein UniFi-Gateway installiert, in welchem schon ein Controller eingebaut ist (UDM*), dann kannst Du diese Geräte nicht in einem anderen Controller als dem lokalen verwalten. (Bei USGs und deren direkten Nachfolgern OHNE eingebautem Controller: kein Problem.)
      Wenn Du alle Controller mit Ubiquiti kommunizieren lässt, dann kannst Du das zwar dort auswählen, damit kannst Du aber dennoch das eine oder andere Feature nicht umsetzen - so weit ich weiß, z.B. die einfache Erstellung einer VPN-Verbindung zwischen mehreren Standorten.
    • Es darf GAR KEINE IP-Adress-Überschneidungen zwischen ALLEN Partnern geben, welche direkt miteinander kommunizieren sollen.
      • Alles Standorte brauchen ihren eigenen Bereich, z.B. 10.0.0.0/16 für die Zentrale, 10.1.0.0./16 für den ersten Standort usw. Dann solltest Du auch jeweils mit VLANs arbeiten, um gleiche Clients zu gruppieren. Das kam aber auch schon als Vorschlag / Empfehlung.
      • Niemand, der sich von außen einwählen möchte, darf sich in einem Netzwerk mit einem eben solchen Adressraum befinden, denn sonst klappt das Routing nicht mehr - s.o.
      • Es dürfen selbstverständlich die Mitarbeiter zu Hause alle das Netzwerk 192.168.178.0/24 (AVM-Standard) haben, da die sich ja dann jeweils zu einem 10er Netzwerk verbinden. Da gibt es natürlich keine Probleme.
        Wenn aber mehrere FRITZ!Boxen wiederum untereinander kommunizieren können sollen gilt wieder: Es darf GAR KEINE IP-Adress-Überschneidungen zwischen ALLEN Partnern geben, welche direkt miteinander kommunizieren sollen. Aber das sollte Dich nicht stören.

    Viel Spaß bei der Umsetzung. :smiling_face:

  • Hallo razor


    vielen Dank für deine Einlassungen.

    Zunächst verbessert UI unseren bestehenden Standard: AVM und unmanaged Netgearswitche. Ich glaube da wäre alles andere auch ein Fortschritt - ich wollte aber unbedingt ein SDN, dass ich auch aus der Ferne sichten kann - da erschien mir UI die korrekt Wahl, zumal UI auch nicht so teuer ist.


    Wir brauchen gar keine große Infrastruktur. Wir haben einige Standorte und wir haben beschlossen, jedem Standort eine eigene C-Netz-Adresse zu geben - also Standort A 192.168.1.0/24, B 192.168.2.0/24 C 192.168.3.0/24 usw. - jeweils mit Subnetmask 255.255.255.0.


    Damit sind die Netzwe divergent und haben keine Berührungspunkte - was ja Basiswissen VPN ist (eigentlich ginge das schon, dass 192.168.1.0/24 per VPN auf 192.168.1.0/24 zugreifen kann, wenn das Zielnetzwerk HINTER einem Zugangsnetzwerk liegt, wie das beispielsweise QNAP macht d.h. also:

    Quelle 192.168.1.25 --> VPN --> QNAP --> 10.8.0.5 --> 192.168.1.26 Ziel


    Das führt aber genauso zu Problemen, wenn im Quell-IP-Netz Drucker die gleichen IP-Adressen haben wie im Ziel-IP-Netz und dann der Druck irgendwo raus kommt.


    Ich denke wir probieren es einfach aus. Allein die Verbesserung im WLAn war die Anschaffung des UI wert. AVM kann ja nur eine SSID verwalten - UI mehrere. Das allein ist Gold wert :smiling_face: Und die Map, die uns mögliche Probleme aufzeigt, der Load-Balancing-Server für WAN usw....


    ich melde mich erneut

  • Wir brauchen gar keine große Infrastruktur. Wir haben einige Standorte und wir haben beschlossen, jedem Standort eine eigene C-Netz-Adresse zu geben - also Standort A 192.168.1.0/24, B 192.168.2.0/24 C 192.168.3.0/24 usw. - jeweils mit Subnetmask 255.255.255.0.

    Ich würde mir aber Spielraum lassen, z.B.:

    Standort 1: 192.168.1.0/24

    Standort 2: 192.168.10.0/24

    Standort 3: 192.168.20.0/24


    Wenn weitere Netze/Anforderungen dazukommen hast Du nachher kein durcheinander.


    Alternativ ein B-Netz mit z.B. /20. Dann hast Du für die Zukunft genügend Spielraum für Erweiterungen.


    Damit sind die Netzwe divergent und haben keine Berührungspunkte - was ja Basiswissen VPN ist (eigentlich ginge das schon, dass 192.168.1.0/24 per VPN auf 192.168.1.0/24 zugreifen kann, wenn das Zielnetzwerk HINTER einem Zugangsnetzwerk liegt, wie das beispielsweise QNAP macht d.h. also:

    Quelle 192.168.1.25 --> VPN --> QNAP --> 10.8.0.5 --> 192.168.1.26 Ziel

    Wenn Du Site-to-Site VPN hast, darf es keine Überschneidungen geben.


    Wenn Du Road Warrior VPN nutzt, also einzelne Geräte Zugriff auf Dein Netzwerk bekommen, kann die Quell und Zieladresse identisch sein, weil der Tunnel einen eigenen IP-Adressbereich bekommt und dieser entsprechend geroutet wird. (ganz einfach ausgedrückt)


    LG

    30 Sites - 500 APs - 150 Switche - EdgeRouter - UXG-Pro - UDM-Pro - USG-PRO-4 - OPNsense - IPUs

  • Ich würde an keinem Standort für das Produktivnetz die folgenden IP Bereiche nutzen.


    192.168.0.0/24

    192.168.1.0/24

    192.168.2.0/24

    192.168.178.0/24


    Wer weiß was die Zukunft noch bringt. Aber das dürften die weitverbreitesten IP Netze sein, da bei viel Routern der default. Gerade in Hinsicht auf Mitarbeiter VPNs... tut ja auch nicht weh die wegzulassen.

  • jedem Standort eine eigene C-Netz-Adresse

    Alternativ ein B-Netz mit z.B. /20

    Da werde ich Pingelig bitte nicht Persöhnlich nehmen hat auch nicht mit dem Thema an sich zu tun.

    aber die 80er haben angerufen und wollen ihre Netzklassen zurück.


    CIDR (Classless Inter-Domain Routing) wurde 1993 eingeführt.


    bzw. ein „B“ Netz war niemals ein /20

    Das Klassenhafte „B" Netz war der IP Bereich

    von 128.0.0.0 – 191.255.255.255 der für Private zwecke vorgesehene Bereich in der Netzklassen war / ist

    172.16.0.0 - 172.31.255.255 das endet in einem /12 (255.240.0.0)

    Das Klassen denken hat daraus dann nochmal in 16 Subnetze gemacht um auf die übliche /16 Maske zu kommen.


    und kommt mir nicht mit „Umgangssprache“ sonst fange ich an eure Einspritzanlagen als Vergaser zu bezeichnen :smiling_face:

  • Sehr gern.


    Unterstütze ich zu 100%!

    Ich würde in einer Firma sogar noch weiter gehen und auf 10.0.0.0/8 wechseln und dort dann in 24er Netze zu splitten.

    Ich habe das zum Spaß zu Hause auch so gemacht und konnte damit sogar die V-IDs in der IP abbilden, was natürlich technisch sowas von nicht erforderlich ist. :grinning_squinting_face:

    und kommt mir nicht mit „Umgangssprache“ sonst fange ich an eure Einspritzanlagen als Vergaser zu bezeichnen :smiling_face:

    :grinning_squinting_face: :grinning_squinting_face: :grinning_squinting_face:

  • Ich würde in einer Firma sogar noch weiter gehen und auf 10.0.0.0/8 wechseln und dort dann in 24er Netze zu splitten.

    Ich habe das zum Spaß zu Hause auch so gemacht und konnte damit sogar die V-IDs in der IP abbilden, was natürlich technisch sowas von nicht erforderlich ist. :grinning_squinting_face:

    Hach ja, du sprichst mir aus der Seele, so siehts bei mir zu Hause auch aus :smiling_face:

    Gruß

    defcon

  • Ich würde in einer Firma sogar noch weiter gehen und auf 10.0.0.0/8 wechseln und dort dann in 24er Netze zu splitten.

    Ich habe das zum Spaß zu Hause auch so gemacht und konnte damit sogar die V-IDs in der IP abbilden, was natürlich technisch sowas von nicht erforderlich ist.

    Habe ich Tatsächlich auch bei mir so außer das Default 192.168.1.0/24 schleppe ich nun seit > 20 Jahren daheim rum.

    Habs irgendwie lieb gewonnen :smiling_face: Alle anderen VLAN, Virtual kram, Tunnel zu Externen Server sind mit 10./8 IP und dort

    Je nach zweck auch mal nur als als /28 oder /29 (für die Transfer Tunnel)