Beiträge von DoPe

Zitat von phino

Auch wenn es möglicherweise ein Datenschützer anders sieht, es gibt eine Filterleiste und die darin enthaltenen Domains werden einfach nicht per DNS aufgelöst. Und wenn dies nicht gespeichert wird, ist es nicht auswertbar, also kein Problem.
Natürlich kommen jetzt Datenschützer mit wilden Ideen um die Ecke von wegen man erkennt ein Surfverhalten oder so, schei** darauf. Wenn der Kunde es nicht will, soll er woanders hingehen. Es steht ihm frei.

Wenn der Gesetzgeber solche DNS Filter vorschreibt für Provider, dann muss das ja legal sein. So hat doch Haarspay-Uschis Kinderpornograpieschutz gearbeitet und deshalb war es auch völlig sinnbefreit wenn auch das Anliegen äusserst sinnvoll war und ist.

Zitat von iTweek

Gabe die so bei mir gelöst.

N510 IP PRO - DECT IP Basisstation, verbindungen über Wireless und DECT, bis zu 4 externe Anrufe gleichzeitig, 6 Mobilteile, 6 VoIP-Accounts, schwarz https://www.amazon.de/dp/B005O…n_dp_HRAMXSHPTHDHA88PMX8P

Das ist doch aber nur eine einzelne Basis oder nicht?

Zitat von madi

Ok danke,

Wenn ich drei Basisstationen möchte reichen mir dann 3 x AGFEO DECT IP-Basis XS?

oder brauche ich zusätzlich noch ein Kommunikationssystem wie ES 542?

Das ES System benötigst Du in jedem Fall und natürlich die DECT Systemtelefone. Ist also absolut keine Günstig Lösung.

Ich vermute mal, dass der TE das so auch nicht möchte. Sinn ist vermutlich dass die Clients am Wunsch AP hängen solange der verfügbar ist, was die Clients wohl gerne nicht tun. Wenn der Wunsch AP aber mal nicht verfügbar ist, dann könnten die Clients sich nicht umloggen wegen dem "Minimum RSSI". Es geht hier ja nicht um bewegliche Clients. Würde mich bei Shellys wundern.

Das kenne ich leider nicht (glaube ich). Gibts noch weitere Einstellungen für DNS Server? Also den vom OS unten drunter zum Beispiel? Oder das ist evtl. ausm Cache weil schon abgefragt bevor richtig konfiguriert und der fragt gerade nicht mehr ab?

Aber hier gibts sicher Leute die AdGuard benutzen.

Aus den Ports kommt jetzt nur das Management LAN ungetaggt raus (also direkt mit PC nutzbar).

Blockiert werden alle anderen Netze, sprich die sind nicht getaggt da mit drauf. Wenn Du da einen Accesspoint anschliesst mit WLAN für beide Netze, dann geht das WLAN fürs Management LAN, bei dem 2. WLAN würdest Du wieder keine IP bekommen, weil das Netz dort nicht "verbunden" ist.

Mal einfach und nicht 100% korrekt:

• Ungetaggtes Netzwerk: Das sind Pakete ohne Zettel, die werden dann entsprechend verarbeitet.
• Getaggtes Netzwerk: An den Paketen sind Zettel mit der VLAN ID, wenn ein Port diese ID nicht kennt, oder eben diese ID blockiert werden soll dann werden die Pakete nicht verarbeitet.

Du hast vermutlich nur 2 Netze. Da ist Netz1 untagged und Netz2 tagged erlauben ja das gleiche wie Netz1 tagged und keine Restriction (also alle erlauben). Da bin ich neulichs auch mal drübergestolpert

Trag da diese Netze ein. Das sind alle privaten IP Bereiche nach RFC. Sonst hast Du irgendwann wieder ein Loch wenn Du mal ein neues VLAN dazu packst.

10.0.0.0/8

172.16.0.0/12

192.168.0.0/16

Ja genau mit NSlookup und dann halt PTR abfragen. Sollte dann ja wenn Du die IP eingibst den Namen ausspucken.

im Cmd Fenster:

nslookup -q=PTR <IP von einem Gerät> <IP des DNS Servers der abgefragt wird>

Sollte dann irgendsowas rauskommen wenn es klappt.

13.0.22.172.in-addr.arpa name = rackstation.hro.domain.com

Kannste dann auch noch gegen den anderen DNS Server prüfen.

Agfeo ES Anlage mit DECT IP Multizellensystem. Das Fax dann einfach per Kabel an einen a/b Port wie eben früher auch.

Müssen muss bei SFP+ Modul und SFP Port erstmal gar nix ... wie man hier ja sieht gibt es viele verschiedene DACs von vielen Herstellern und auch die unterschiedlichen Ubnt Switch Generationen können sich unterschiedlich verhalten.

Ich habe das mit dem fest einstellen nur mal so dazu geschrieben, damit im Falle eines Falles evtl. weitere Rückfragen erspart bleiben können. Ich hoffe der TE findet jetzt auch noch seine Antworten.

Bei einem Port an dem ein normales Endgerät dran hängt, stellst Du nur das Netzwerk ein zu dem das Gerät gehören soll. Das Traffic beschränken regelt dann nur, welche VLANs getagged auch auf dem Port liegen oder eben auch nicht. Bei Endgeräten mach dort meist alles blockieren Sinn, da diese meist nicht in der Lage sind mit getaggten Paketen umzugehen. Bei Verbindungen zwischen Switchen und auch zu Accesspoints mit mehreren WLANs, sollten die VLANs die man benötigt bei Erlauben ausgewählt werden, damit der Traffic da auch durchgeht.

Wenn das Deine Frage war

Zitat von Wombert

Der Fehler hier ist die Nutzung von "LAN Local". Das wird nur auf Traffic vom entsprechenden Netz zur UDM SE selbst angewandt (z.B. für DNS, oder auf das Management-Interface, oder Protect, oder oder oder).

Du musst für inter-VLAN-Verkehr aber "LAN In" und "LAN Out" nutzen. Hauptsächlich ersteres - Traffic aus einem LAN in das Gateway rein, zum Zwecke der Weiterleitung, und du willst es schon blockieren, bevor es die Firewall passiert (z.B. alles aus IoT in alle anderen Netze, es sei denn es ist Established/Related, die Regel kommt ja weit vorher).

Vielleicht hilft auch das: https://community.ui.com/quest…69-4749-b224-0dee15374de9

Brauch ich eine neue Brille? Da steht LAN_IN bei den Screens. Falls Du das Zeug weiter unten in den Regeln meinst, das sind wohl für die Sperrung des Zugriffs auf die Gateway IPs für die VLANs.

Bitte bei Port 1 das alle Blockieren weg machen. Dein 2. VLAN wird dort nicht durchgelassen. Ist Vergleichbar als wenn Du deinen Mac an einen Switch anschliesst, dieser aber nicht am Router angeschlossen ist. Halt nur virtuell und nur für dieses VLAN.

Du musst die VLANs immer soweit durch die Switche durchreichen, wie Du die verteilt haben willst. Die Standardeinstellung ist dafür eigentlich auch korrekt gewesen.

Was beinhaltet die "Gruppe Local IP Adresses" ?

Und was steht in den Regeln vor dem VLAN Blockieren konkret drin?

Hast Du mal die UDR direkt abgefragt ob die überhaupt Namen kennt? Ist die UDR DHCP?

Und evtl. ist es notwendig, dass Du den SFP+ fest auf 1GBit einstellst, falls auf der anderen Seite nur SFP da ist und kein Link zustande kommt.

Du kannst das Primary Network einstellen ... das ist dann ungetagged auf dem Port. Mit den Traffic Restrictions kannst Du dann zusätzlich Netzwerke erlauben oder verbieten. Diese Netzwerke werden dann mit der entsprechenden VLAN ID getagged.

Normalerweise macht man sowas nur bei Infrastruktur ... wie Verbindungen zwischen Switchen, Accesspoints, Router Uplink oder Virtualisierungshosts.

Die meisten Endgeräte können nur ungetaggtes Netzwerk benutzen. Manche Netzwerkkartentreiber für Windows Desktops können dann auch ein getaggtes VLAN allerdings immer nur das eine oder andere. Bei Linux sieht das teilweise besser aus, wie Du ja beim Home Assist sehen kannst.

Die Geräte melden sich da an, wo entsprechend ihrer Auswahlkriterien die "bessere" Verbindung hergestellt werden kann. Startest Du einen Accesspoint neu oder schaltest ihn kurzzeitig ab, dann verbinden sich die Geräte zu einem anderen Accesspoint, falls einer in Reichweite ist. In der Regel wechseln die Geräte nicht wieder zurück wenn der ursprüngliche Accespoint wieder verfügbar ist. Aber auch das kann passieren, liegt halt daran wie das beim WLAN Client geregelt ist. Ist halt bei sich bewegenden Clients auch so ... manche halten an der Verbindung fest bis diese abbricht bevor sie auf einen viel besseren Accesspoint wechseln, andere Geräte wechseln auch vorher.

Wenn Du nicht festlegen willst an welchem Accesspoint ein Client sich anmelden kann, dann kannst Du nicht festlegen an welchem Accesspoint sich ein Client anmeldet

In den meisten Fällen führt so ein Stromausfall dazu dass die Datenbank des UniFi Controllers zerschossen wird. Das war auch schon beim Cloudkey Gen1 so ... Das ist ein Glücksspiel ... Hab Cloudkeys und auch UDMs mehrfach vom Strom gezogen ohne Fehler. Allerdings hab ich auch schon erlebt, dass ein Cloudkey direkt beim ersten mal abziehen vom POE Port nur noch Factoryresettet und neu konfiguriert werden musste. Ne Sicherung gabs da noch nicht, weil nicht fertig eingerichtet

Das hat Ubiquiti dann ja mit den Cloudkey2 versucht zu fixen ... Die Idee war gut, die Umsetzung der internen Akkus ... muss man nix zu sagen.