Subnetze

Es gibt 11 Antworten in diesem Thema, welches 3.341 mal aufgerufen wurde. Der letzte Beitrag () ist von Tuxtom007.

  • Hallo,


    das Ethernet ist aus mehreren Gründen bewusst in mehrere Subnetze unterteilt worden. Siehe auch hier.


    In Folge dessen funktioniert die lokale DNS-Auflösung nur pro Subnetz.


    Sinnvoller wäre eine subnet-übergreifende DNS-Verwaltung.


    Kann mir jemand erläutern, wie das umgesetzt werden kann?


    Nachtrag:

    Jeder Subnet-Bereich wurde als eigenständiger DHCP Server mt eindeutiger VLAN ID eingerichtet

    Einmal editiert, zuletzt von Ben2003 ()

    • Offizieller Beitrag

    Moin Ben2003 ,


    falls das nur so funktioniert, wie Du beschreibst, dann ist das in der Tat ein Ärgernis. :pouting_face:


    Ich habe vor ein paar Jahren schon das erste Mal mit dem pi-hole zu tun gehabt und benutze nun dieses auch als lokalen DNS-Resolver meiner Hosts. Funktioniert für mich hervorragend und kann darüber hinaus auch diverse Webseiten durch das Unterbinden von Werbung beschleunigen. Ich pflege nun meine Host-Records im pi-hole - schön per GUI oder auch auf der Console. Zum Glück ändert sich nicht so oft etwas in meinem LAN, was es nötig machen würde ständige neue Einträge erzeugen zu müssen. :grinning_squinting_face:

    Im Wiki gibt es einen schönen Betrag, der noch "weiter" geht: PiHole mit DoT+DNSSEC oder DoH.

  • Ich pflege nun meine Host-Records im pi-hole

    Das funktioniert doch nur dann, wenn die Hosts zuvor mit festen IP-Adressen versehen wurden. Bei dynamischen IP Adressen wird der Host nicht auffindbar sein.


    Eine doppelte Verwaltung der Hosts wollte ich eigentlich vermeiden.


    Im Unifi-Controller ist doch bereits eine vollständige Liste aller Clients bzw. Hosts von allen Subnetzen enthalten. Anhand dieser Liste sollten die Anfragen aufgelöst werden.

  • Sinnvoller wäre eine subnet-übergreifende DNS-Verwaltung.

    Wird ja auch in großen Netzen so gemacht.


    Bei mir erledigt das ein PiHole ( bzw. zwei synchronisierte ) die in einem VLAN sitzen und dort von allen anderen VLAN's per Firewallregel erreicht werden.

    Im Regelfall soll der PiHole Anfragen zu lokalen Clients an den DHCP-Server weiterleiten und der diese dann beantworten, da nur der DHCP-Server die aktuelle IP-Adresse des Clients kennt.


    Jetzt sind wir aber wieder beim Thema "Unifi und Software" und das funktioniert eher semi-optimal.

    Mein PiHole leite die Anfragen an die UDMPro weiter aber die beantwortet die nicht.


    Ich behelfe mir daher, das ich für nahezu alle Geräte IP-Reservierungen habe und die IPs/Hostnamen im PiHole eingetragen sind und von ihm dann beantwortet werden.


    Ich bin mal gespannt, ob das demnächst mit der OPNSense besser funktioniert, habe da große Hoffnung.

    • Offizieller Beitrag

    Das funktioniert doch nur dann, wenn die Hosts zuvor mit festen IP-Adressen versehen wurden. Bei dynamischen IP Adressen wird der Host nicht auffindbar sein.


    Eine doppelte Verwaltung der Hosts wollte ich eigentlich vermeiden.


    Im Unifi-Controller ist doch bereits eine vollständige Liste aller Clients bzw. Hosts von allen Subnetzen enthalten. Anhand dieser Liste sollten die Anfragen aufgelöst werden.

    Wie viele Geräte hast Du denn, bei denen sich ein DNS-Eintrag lohnt, bei denen sich die IP so oft wechselt? :thinking_face:

    Du hast aus meiner Sicht 2 Optionen:

    1. Lease-Zeit erhöhen, falls die Geräte zu lange weg vom Netz sind und damit möglicherweise eine andere IP erhalten als beimletzten Mal
    2. Statische Adress-Zuweisug via DHCP.

    Feel free.

  • Wie viele Geräte hast Du denn

    Es geht mir ums Prinzip. Wenn man einmal eine Lösung gefunden hat, bei der die DNS Weiterleitung funktioniert, kann diese Lösung bei großen wie auch bei kleinen Netzen angewandt werden.


    Wird ja auch in großen Netzen so gemacht.

    Das ist mir bekannt. Nur kenne ich es bislang nur von Windows Domains. Hier wird es u.a. mit einem Wins-Server geregelt. Solche Dienste sind in Windows Servern enthalten und brauchen nur installiert und eingerichtet werden.


    Ich habe mir vorgestellt, dass es auch ein Pendant für Linux-Server geben muss. Scheinbar gibt es entsprechende Lösungen nur als bezahlte Pakete.

    • Offizieller Beitrag

    Es geht mir ums Prinzip. Wenn man einmal eine Lösung gefunden hat, bei der die DNS Weiterleitung funktioniert, kann diese Lösung bei großen wie auch bei kleinen Netzen angewandt werden.

    OK. Das verstehe ich, geht aber nicht auf meine Frage ein.

    Das ist mir bekannt. Nur kenne ich es bislang nur von Windows Domains. Hier wird es u.a. mit einem Wins-Server geregelt. Solche Dienste sind in Windows Servern enthalten und brauchen nur installiert und eingerichtet werden.


    Ich habe mir vorgestellt, dass es auch ein Pendant für Linux-Server geben muss. Scheinbar gibt es entsprechende Lösungen nur als bezahlte Pakete.

    Man kann sehr wohl auch eine Domäne mit Samba installieren. Damit kannst Du u.U. nicht alles, was Dir ein ADS bietet (z.B. Rechte auf einzelne OUs vergeben), aber das von Dir genannte lässt sich so auch wunderbar umsetzen.

    Zusätlich könnte auch ein ISC-DHCP-Server die Arbeit eines UniFi-Gateways übernehmen. Kein Problem.

  • Ich habe mir vorgestellt, dass es auch ein Pendant für Linux-Server geben muss. Scheinbar gibt es entsprechende Lösungen nur als bezahlte Pakete.

    DHCP / DNS - Server für Linux gibt es kostenlos und zwar verdammt gute.


    "bind" als DNS-Server ist der Standart auch bei Internetprovider, bei meinem letzten AG haben wir damit etliche Millionen Internetkunden versorgt, wer da Windows nimmt ist selber schuld.

    "isc-dhcp-server" als DHCP-Server, der kann auch problemlos mit VLan's umgehen.


    Kaufen muss man da gar nichts, ausser man will Support haben, wie wir in der Firma Support über RedHat haben.

  • Habe heute erst gesehen, dass selbst in Synology Diskstation auch ein Wins-Server integriert ist. Dieser ist unter dem Protokoll-Namen "smb" benannt und standardmäßig deaktiviert.


    Nach dieser Webseite kann man mit dem folgendem Consolen-Befehl (?) einen WIN Server in einer DHCP eintragen:


    Code
    set service dhcp-server shared-network-name [LAN-NAME] subnet [SUBNET/24] wins-server [IP-WINS SERVER]

    Mal schauen, ob das was bringt und vor alem, wie lange diese Einstellung erhalten bleibt.


    Die weiterführenden Links auf der Webseite auf das wiki.ubnt.com sind leider schon veraltet und können nicht mehr verwendet werden.



    Nachtrag:


    Auf dieser Webseite steht, wie z.B. ein Wins-Server eingetragen werden kann.


    Ich bin verantwortlich für eine privat aufgebaute Infrastruktur an drei Standorten. Diese wurden mal mit Einsatz von FritzBoxen und VPN miteinander vernetzt. Aktuell ist kein VPN mehr aktiv, da bei mir die FritzBox ausgedient hat. Nun ist nur noch eine Unifi-USG mit einem Modem im Einsatz.


    Worauf ich hinaus will, ist folgendes:

    Als die drei Standorte vernetzt waren, konnte man nur mit IP-Adressen auf den entfernten Standort zugreifen. Das war für viele Teilnehmer nicht vermittelbar, die nix mit technischen Details zu tun haben wollten. Es war auch noch nicht mal so, dass bei Windows-Systemen in der Netzwerkumgebung die Systeme an den anderen Standorten nicht aufgelistet wurden, die gerade online waren. So war das VPN-Netz zwar da, aber so richtig genutzt hat es keinem. Viele haben sogar weiterhin via USB-Stick die Dateien untereinander ausgetauscht, weil eben die IP-Adresse es anderen unbekannt war. Dadurch waren von vielen Dokumenten mehrere Versionen im Einsatz, wo zum Schluss niemand mehr genau sagen konnte, welches nun der letzte Stand ist. :grinning_face_with_smiling_eyes:


    Mittlerweile wurde ein Nextcloud auf einem System installiert, die über eine öffentliche Domain-Namen erreichbar ist. Mal sehen, ob das ausreicht, um wenigstens gemeinsame Dateien besser untereinander austauschen zu können.


    Viele Teilnehmer haben als System Windows in verschiedenen Varianten im Einsatz. Manche haben Android Tablets oder Macintosh.


    Wenn in den DHCP die Erweiterte Optionen der Code 44 gesetzt werden sollen, wird folgende Meldung angezeigt:


    This code is already in use. Please use a different value


    44 steht für "WINS Server".


    Die Option 44 wurde mit einem "set dhcp-server shared-network-name ..." bereits gesetzt worden. Die gesetzte Option wird in der Web-Oberfläche nicht angezeigt.


    Weiß jemand, wie die Option "44" entfernt werden kann?

    3 Mal editiert, zuletzt von razor () aus folgendem Grund: 2 Beiträge von Ben2003 mit diesem Beitrag zusammengefügt.

  • Mein Projekt

    • Offizieller Beitrag

    Als die drei Standorte vernetzt waren, konnte man nur mit IP-Adressen auf den entfernten Standort zugreifen. Das war für viele Teilnehmer nicht vermittelbar, die nix mit technischen Details zu tun haben wollten.

    Das hätte man mit einem DNS-Server sehr schön uns sauber lösen können.

    Es war auch noch nicht mal so, dass bei Windows-Systemen in der Netzwerkumgebung die Systeme an den anderen Standorten nicht aufgelistet wurden, die gerade online waren. So war das VPN-Netz zwar da, aber so richtig genutzt hat es keinem. Viele haben sogar weiterhin via USB-Stick die Dateien untereinander ausgetauscht, weil eben die IP-Adresse es anderen unbekannt war.

    #Broadcast-Domain - Diese hört an der Netzgrenze (/24 oder /23 oder oder oder) auf. Damit ist es nicht möglich Clients in anderen Netzwerken (z.B. 192.168.0.0/24 vs. 192.168.1.0/24) zu sehen: works as designed.

    Für eine solche Konstruktion ist eine FRITZ!Box von AVM auch nicht ganz das richte Einsatzgebiet - mMn, auch wenn das viele versuchen.

    #MicDrop

  • Für eine solche Konstruktion ist eine FRITZ!Box von AVM auch nicht ganz das richte Einsatzgebiet - mMn, auch wenn das viele Versuchen.

    Da stimme ich zu, eine FritzBox ist als All-In-One Router für den Hausgebrauch gedacht und entsprechend auch aufgebaut.

    Nichts gegen FritzBox - ich nutze die zuhause auch seit etlichen Jahren - aber für Firmeneinsätze würde eher auf "richtige" Firewall setzen, was aber leider auch den Aufwand und die Kosten in die Höhe treibt, aber auch wesentlich flexibler sind.