Beiträge von DoPe

    Ein Netzwerk würde ich möglichst immer sternförmig strukturieren. Auf keinen Fall eine lange Reihe von Switchen (sowas wie ein Bus). Und auf keinen Fall einen Ring ... dann hättest Du einen Loop und ggf. geht gar nix.


    Das Ganze bezieht sich allerdings dann darauf wie gepatcht wird und nicht darauf wie die Kabel physikalisch verlegt sind.


    Wie man das ganze am besten verkabeln kann hängt natürlich vom Anwendungszweck und den örtlichen Gegebenheiten ab. Optimal wäre Ein Ring mit 30 Fasern die von einem Gebäude zum nächsten gehen und dort jeweils komplett auf LWL Patchfeld abgelegt sind. Dann kannst DU dir die Patchverbindungen logisch fast herstellen wie Du möchtest.


    Sollte das Kabel kaputt gemacht werden, kannst Du (da als Ring verlegt) schnell die Verbindung über die andere Richtung des Ringes patchen und es funktioniert wieder. Auch kannst Du so einen defekten Switch "umgehen" oder aber der hat nichtmal einen Einfluss auf das restliche Netz, da der Coreswitch jeweils eine direkte Verbindung zu allen anderen Switchen hat (was perfekt wäre) Dafür musst DU nur entsprechend viele LWL Duplex Patchkabel haben :smiling_face:

    Zattoo ist kein IPTV im herkömmlichen Sinne. Das sind in der Regel Receiver vom Anbieter (Tripple Play Angebote) die IGMP Snooping etc. benötigen wie z.B. die Magenta TV Receiver. Da hat der Provider dann sein Netz entsprechend konzipiert um Traffic sinnig zu lenken.


    Zattoo ist eher wie Netflix, Twitch, WaipuTV und Co.


    Dein Problem wird an keiner Einstellung liegen. In der Regel ist die App einfach nur nicht gut programmiert oder auf die Hardware abgestimmt und stürtzt ab oder wird einfach beendet. Läge es am Datenfluß, dann hättest Du Standbild (wie bei IPTV ohne IGMP Snooping etc.) oder es würde eine Meldung ala keine Verbindung mehr oder ähnliches kommen. Solche Probleme findest Du bei jeglichem Android Device mit einer Vielzahl Apps ... egal ob FireTV, Chromecast, WaipuTV Stick und was es da noch so gibt. Ich hab einen FireTV und WaipuStick bei einem klappt Twitch gelegentlich zu, beim anderen Netflix. Die gleichen Apps laufen auf dem jeweils anderen Stick problemlos.


    Wenns nicht durch ein Update verschwindet, wirst Du damit leben müssen.

    Öhm das ist der Controllername und nicht wirklich die Fritzbox die Du da siehst, wenn mich nicht alles täuscht.


    Geh mal lokal auf deinen Controller unter System -General ... steht da bei Device Name zufällig das Fritz!Box 7490 ?

    Mach bitte mal eine Skizze wie Du was an welchem Port angeschlossen hast. Die Fritzbox sollte nicht zu sehen sein wenn die vor der USG hängt. Irgendwas ist da völlig verkehrt gelaufen.

    Ich glaube dann möchte ich aber gerade lieber PoE Injektoren nehmen, die sind sehr viel günstiger als ein übertriebener Switch. Oder spricht etwas dagegen?

    Kabelsalat. Ansonsten wüsste ich erstmal kein Gegenargument. Bei 2-3 Geräten mag das alles noch gehen.

    Kann die UDM Pro "Exposed Host"?
    Kann ich einen Weiteren Router / Firewall (testweise) hinter die UDM schalten und daran dann einen Test Client verbinden?

    Nein (zumindest nicht mit einem Haken wie bei AVM) und Ja, aber wozu benötigt man da Exposed Host? UDM macht unabänderlich NAT, Musst Du also ggf. Portforwards an den WAN des "weiteren Routers" einrichten.

    Ein letztes: Sehe ich das gerade richtig, dass der Standard 16 PoE Switch mit 42W total PoE gerade mal drei U6 Pro Access Points versorgen können wird?

    Jepp ... sind ja auch nur 8 Ports die POE können. Wenn man nicht gerade verfressene Accesspoints da dran hat, reichen die 42W auch oft für 8 Geräte ... z.B. IP Phones Wenn Du mehr Dampf brauchst könntest Du auch den USW-24-POE nehmen.


    Für alles andere gibts dann ja die PRO POE Switche.

    Dein Controller ist auf dem Home Assist als self hosted installiert? Auf den kommst Du via internem Zugriff mittels Browser drauf? IST DER AKTUELL?


    Dann mach mal Haken bei Allow weg und Übernehmen. Dann Remove remote access und Bestätigen.

    Anschliessend wieder anmachen. Dann wird dein ui Account abgefragt und anschliessend sollte der Controller wieder unter https://unifi.ui.com/network-servers auftauchen.

    Hab das gerade auf einem Controller aktiviert der auf einem Debian läuft.


    Wenn das nicht klappt ... Gibts Firewallregeln?

    Zu deinen Frage.


    DHCP bringt dir den Vorteil, dass Du dich nicht um die Vergabe von IP Adressen an den Endgeräten kümmern musst. Hast Du kein DHCP, dann musst du an jedem Netzwerkgerät IP, Subnetmaske, Standardgateway und DNS Server händisch fest einstellen. Dabei muss man auch darauf achten, dass man keine IP 2mal vergibt ... also ziemlicher Frickelkram. Dazu kommt dann dass man mobile Geräte hat, welche auch anderweitig in fremden Netzen verwendet werden. Die Wahrscheinlichkeit, dass die Konfiguration aus deinem Netz dann auch überall sonst passt und keine Probleme macht ist nahezu NULL. Sprich Du musst dann woanders wieder auf DHCP umstellen und bei dir Zuhause wieder auf statisch ... unpraktikabel.

    Mit DHCP Reservierungen kannst Du trotzdem einem Gerät eine bestimmte IP zuweisen, falls nötig.


    Was NAS und Pi angeht... Nur weil es viele haben, heisst es nicht dass Du es auch benötigst. Hast Du keine große Datenmengen oder willst bestimmte Dateien permanent für alle zugänglich haben, dann brauchst Du wahrscheinlich kein NAS. Zum Virtualisieren wäre das noch was ... Gleiches gilt eigentlich auch für den Pi ... Normalerweise kauft man nicht unbedingt Hardware und generiert dann irgendwie den Bedarf. Netzwerk Reserve einplanen und dann wenn der Bedarf für die Lösung einer Aufgabe besteht, schauen wie man es lösen kann und womit :winking_face:


    Die Firewall musst Du wie gierig schon schrieb immer von zwei Seiten betrachten. Es gibt da so flags bzw. Statis von Paketen die durch die Firewall wollen. New, Related usw. Mit diesen kann man den Spaß verfeinern und z.B. eine neue Verbindung aus Admin VLAN ins IOT zulassen. Aus dem IOT dürfen related Pakete ins Admin Netz ... und schon kannst Du aus dem Adminnetz mit IOT Geräten kommunizieren. Damit IOT Geräte nicht auf das Admin Netz zugreifen dürfen (eine neue Verbindung aufbauen) musst Du dann quasi Pakete mit new flag aus dem IOT Netz zum Admin Netz blocken. Das ganze kann man dann mit Quell- und Ziel-Adressen und Ports sehr granular gestallten.

    Die Cloudkeys fahren nach etwa 10s schon herunter ... ausser die Akkus stehen schon kurz vor der Explosion und füllen das Gehäuse komplett aus. Dann gehen die Instant aus. Leider aufgrund der vorherrschenden Thermik eine ziemliche Fehlkonstruktion und so machen die Akkus teilweise nach 6 Monaten schon dicke Backen.

    Verstehe die Frage leider auch nicht. Die Cloudkeys werden dort schlichtweg mit der IP Adresse angezeigt, die der Cloudkey auf seinem LAN Interface benutzt. Selbst eine UDM welche hinter einer Fritte hängt (man also doppeltes NAT hat), wird dort nur mit der privaten IP des WAN Ports der UDM angezeigt.


    Sicherlich hätte Ubnt das auch mit der IP überschreiben können, von der die entsprechenden Pakete kommen.

    Bitte alle Ports vom Router, den ankommenden Switch Ports und die abgehenden Switch Port prüfen, welche Router/Switche und Accesspoints verbinden. An mindestens einem wird das VLAN 20 nicht verbunden sein.


    Die Ports sollten als natives Netzwerk das Default Netz eingetragen haben und der Haken bei Traffic Restriction sollte nicht gesetzt sein. Dann wird dein VLAN 20 dort auch getaggt übertragen und steht dann auch erst auf den Switchen und Accesspoints zur Verfügung. Fehlt das auch nur an einer Stelle wird es gar nicht oder nur teilweise funktionieren, je nachdem wo es fehlt.


    Es fehlt sozusagen mindestens ein virtuelles Patchkabel.

    Gibt es eine Möglichkeit nur einzelne IP-Adressen, in meinem Fall, die der DockerVM, aus dem Routing zu nehmen. In den Routing Einstellungen kann ich zwar "Alle Clients" auswählen, aber dann nicht wieder einzelne entfernen :neutral_face: ?

    Bei den Routing Rules kann man doch auch die einzelne Devices statt eines ganzen VLANs auswählen.


    Hast du einen PiHole im Einsatz? Dort müsstest du dann DNS Einträge für deine öffentlichen DNS Namen setzen die intern erreichbar sein sollen. Dieser Zeigt dann auf die Interne IP Adresse deines Proxy. Im Anschluss musst du sicherstellen, dass deine VPN Clients auch den PiHole für DNS nutzen.


    Verstehe ich richtig, dass deine UDP als Client zu Proton VPN verbunden ist und deine anderen Endgeräte (Mobiltelefon, etc.) auch?

    Was soll das denn bringen, die interne Namensauflösung zu verbiegen? Es geht doch um den Zugriff aus dem Internet auf die diversen Seiten, der nicht funktioniert wenn Proxy über VPN antwortet. Ich vermute mal dass der Zugriff nicht ausschliesslich über VPN erfolgen soll, denn dann könnte man ja den Proxy auch gleich weglassen und durch den Tunnel auf die expliziten Adressen der Dienste zugreifen.

    Leitest Du wirklich den ganzen Verkehr über den VPN Tunnel? Falls ja dürfte es daran liegen, dass wenn Du deine öffentliche IP aufrufst für den Zugriff über den Proxy auf einen Dienst, dieser seine Antwort durch den VPN Tunnel schubst und der anfragende Client Antwortpakete von einer völlig anderen öffentlichen IP bekommt.


    In etwa damit zu vergleichen, wenn Du 2 DSLer hast über einen hast Du brac die Portweiterleitung zum Proxy ... aber deine Geräte benutzen als Standardgateway den Router der am 2. DSLer hängt. Die Antwortpakete müssen zwingend von der gleichen öffentlichen IP kommen.

    Ich hab´ parallel auf einem anderen Gerät keine Probleme gehabt. Der pihole reicht dann die DNS-Antworten ja unangetastet durch.


    Das Testgerät ist ein Samsung Galaxy. Ist nichts besonderes drauf. Oder gibt es eine besondere App bei Samsung, die im Hintergrund installiert ist?


    Bei nem iPad hatte ich aber ähnliches Verhalten.

    Die Geräte die funktionieren sind völlig unerheblich. Das wurde bereits geklärt, dass andere Geräte zur gleichen Zeit kein Problem haben. Also bitte auf mal auf ein Problemgerät beschränken und bei Ausfall der Internetverbindung abprüfen, ob die IP Settings passen und ob intern eine Kommunikation möglich ist - inkl. Namensauflösung externer Webseiten.


    Was war denn nun mit dem pihole? War der jetzt aktiv oder nicht? Wenn nicht aktiv ... was hat dann die Namensauflösung bereitgestellt?


    Funktioniert das eigentlich von alleine irgendwann wieder? Oder trennst Du WLAN im Gerät und aktivierst das wieder? Oder startest Du irgenwas neu?



    So out-of-the-box sollte eigentlich auf keinem Samsung oder gar Apple Gerät irgendeine Software drauf sein, die solche Probleme verursacht. Dachte da eher an ominöse nachinstallierte "Sicherheitstools" die evtl. Amok laufen. So ala zusätzliche Softwarefirewalls für Windows, die im Zweifelsfall mal alles dicht machen, weil durch minimale Änderungen plötzlich ein neues Netzwerk erkannt und daher ein neues Profile (mit eben diesen "Wir machen mal alles dicht" Einstellungen ) geladen wird. Das kann man also wohl ausschliessen.

    Kleines Experiment: ich habe es jetzt am Handy geschafft nachzusehen, was los ist, wenn ich kein Internet habe.


    Ich bin im richtigen WLAN eingebucht und habe eine gültige IP-Adresse. Aber es gibt keine Verbindung zu Webseiten.


    Den pihole hatte ich testweise deaktiviert.

    Gibt es denn in dem Zustand Kommunikation mit Netzwerkzielen? Ping auf Gateway / DNS ?

    Was sagt die Namensauflösung von externen Webseiten? Für den Test hast Du hoffentlich auch einen DNS Server aktiv gehabt, wenn der pihole deaktiviert wurde. Ansonsten wäre das nicht erreichen von Webseiten ja logisch.


    Das Handy selbst ist aber frei von fragwürdigen Sicherheits Apps?

    Wie der ganze Spaß mit der Glasfaser realisiert ist, hängt vom Provider ab. Kann sein dass man eine Glasfaserschnittstelle als Übergabepunkt bekommt und dann seinen Router dort anschliessen muss (Glasfaser Fritzbox, oder wie hier einige SFP Module für das WAN nutzen). Viele Provider haben eine eine RJ45 Schnittstelle als Übergabepunkt. Entweder "Modem" im ONT integriert oder als externes LWL "Modem". Die "Einwahl" ist ebenso providerspezifisch ... PPPoE (mit oder ohne irgendwelchen VLAN IDs) oder DHCP Client


    7490 kannst Du dann entweder als Client oder als Router (mitverwenden eines vorhandenen Anschlusses, WAN = LAN1) verwenden. Welche Option hängt davon ab wie Du die Fritte im LAN haben willst. Ggf. da dann noch bei den SIP Einstellungen die Zeit für das offenhalten der Verbindung kleiner machen, falls die Telefonie einschläft (nach einer weile von aussen nicht mehr anrufbar).


    Wird in diesem Szenarion etwas häufiger so benutzt, da Unifi keine entsprechenden analogen Ports oder DECT zur Verfügung stellt. Hat man keine IP Telefone, nutzt man so die Fritzbox als IP TK-Anlage.