Beiträge von DoPe

Zitat von phino

Das hängt stark von deinem Umfeld ab. Wenn du nur @ Home unterwegs bist, wir es kaum Sinn machen. Außer du hast ein rege Fluktuation von Jugendlichen im Haus. Einfach 2 VLAn ein zum Zocken eins zu recherchier. Jetzt kannst du diesen PW zuordnen. Und die sind dann schnell geändert.

einfach 2 SSIDs mit 2 Kennwörtern für 2 VLANs ... eins zum Recherchieren und eins zum Zocken. Kennwörter können genauso schnell geändert werden. Wo ist da jetzt der große Nutzen von PPSK? Im Gegenteil ich kann bei den meisten Geräten keine 2 Kennwörter für eine SSID speichern und somit nicht mit wenigen Klicks das WLAN und somit das VLAN wechseln.

Und für gewerbliche Nutzung sehe ich da noch weniger sinnvolle Anwendungen als Zuhause.

Kann mir wer ein Szenario mit wirklichem Mehrwert nennen? Vielleicht verstehe ich das ja nur nicht richtig

Versuch mal nach Anmeldung bei unifi.ui.com auf https://unifi.ui.com/network-servers zu wechseln. Evtl. taucht dein Pi dort auf. Ich habe 2 Unifi Accounts und bei einem sind noch diverse alte Cloudkeys der Generation 1 drin. Bei diesem Account ist das Menü links anders als bei dem Account wo nur UDMs und Cloudkeys Gen 2 drin sind. Und die Unterseite ist dann eben die oben stehende.

Wenn Du im Pi Remote Access aktiviert hast, sollte der Controller des PIs auf einer von beiden Seiten auftauchen. Ich hatte den Controller unseres root Servers da früher auch mal drin. Ansonsten kannst Du den Controller auf dem Pi halt nur direkt mittels Portforwarding erreichbar machen. Da müsste Weiterleiten von Port 8443 TCP auf den Pi glaube ich schon reichen. Auch wenn es dann evtl. "Fehlermeldungen" mit STUN oder ähnlichem gibt. Kann aber sein dass das nur auftritt wenn man externe Standorte an diesem Controller verwaltet. Dann muss auch mehr weitergeleitet werden an den Pi.

Das Thema hatten wir vor kurzem gerade schon mal mit einem Proxy und DynDNS. Bis zum Ende wurde es nicht ausdiskutiert. Allerdings sind wir so weit gekommen, dass die Firewallregeln welche den Traffic zwischen den VLANs blockieren schuld daran sind, dass es nicht klappt.

Das Hairpin NAT nutzt source und destination NAT Regeln. Das heisst die Geräte kommunizieren nicht über die WAN Schnittstelle (wo ja der DDNS hinzeigt) wie es Geräte aus dem Internet zwanghaft tun müssen. Der Router leitet die Pakete direkt an die Adresse für die Portweiterleitung und verändert dabei ggf. Quell- und Ziel-Adresse der Pakete. Du musst also zumindest die Kommunikation der beteiligten Geräte (das Ziel Gerät und das aufrufende Gerät) in der Firewall erlauben. Das kann dann aber trotzdem nicht klappen, weil ggf. bei der Abarbeitung der Firewallregeln schon andere Bedingungen für die Pakte gelten weil SNAT/DNAT bereits angewendet wurden.

Ich würde einfach mal die Firewallregeln anpassen für direkte Kommunikation. Das ist auch für Split-DNS notwendig, was ich persönlich favorisieren würde.

Eigentlich erschliesst sich mir der Sinn vom PPSK nicht so richtig. Standard ist das sicherlich nicht

Wenn Du den Speedport für die Telefonie weiter als Router vor der UDM laufen lässt, dann kann der Receiver doch wie bisher auch am Speedport bleiben. Dann lohnt sich das wenigstens mit dem Doppelten NAT ... Ob Doppeltes NAT für dich wirklich ein Problem ist, hängt von der Nutzung des Netzwerkes und Internetanschlusses ab.

Wir haben sehr viele Anschlüsse/LANs mit doppeltem NAT bei denen es gar keine Probleme gibt.

Zitat von Steve16061980

Vielleicht mache auch einfach 3 Doppeldosen hin, und erspare mir den den zusätzlichen Switch da ich dann alles direkt im Rack verbinden kann.

Das dürfte die kostengünstigste Version sein, bei der man nicht auf Hinz und Kunzes Hilfe angewiesen ist. Da Du dabei sogar einen Switch einsparst, solltest Du unter dem Strich auch mit den Stromkosten nicht schlechter liegen und die Gerätschaften haben alle schön einen eigenen Link zur "Zentrale".

Meiner Erfahrung nach ist eine Elektrofirma mit dem Thema LWL meistens total überfordert. Wenn die nicht zufällig fähige Mitarbeiter haben, dann stehen die oft schon mit Kupfer Datenkabeln und deren korrekter Beschaltung auf Kriegsfuß. Früher ist man dann auch gerne über 10DA und größer gestolpert, bei dem mal alle bunten Drähte benutzt wurden und alle weißen Drähte nicht ... weil man die nicht auszählen konnte. Also bei Elektrofirmen immer etwas vorsichtig sein, bei allen Kabeln die keine 230V führen oder mehr als schwarz/grau/braun/blau/grün-gelb markiert sind.

Zum Glück gibt es aber auch Ausnahmen.

160MHz im 5GHz WLAN ist überdenkenswert.

Im Backup sind alle Daten die in der Network App hinterlegt sind. Aber wenn Du Switches und Accesspoints auf Werkseinstellung zurück setzt, dann sind diese nach einspielen des Backups in die UDM dort zwar angezeigt aber nicht mehr funktionabel!

Zitat von phino

6.6.36 ist die aktuelle offizielle Version für AP.

Tjaa dann sollten die mal ihre Downloadsection in Ordnung bringen ... die werden auch immer schlampiger

Zitat von Naichbindas

Hallo

Was hast du denn hier eingestellt?

Gar nix ... gibts in meiner UDM nicht Early Access ist aber nicht angehakt.

Warum wird bei mir eigentlich seit 2 Wochen die 6.6.36 als Update für den U6-Mesh angezeigt? Bei mir läuft nix im RC oder EA Zweig.

Hatte das erst nach dem Update mitbekommen, dass das ne Beta ist weil gar nicht auf der offiziellen Downloadseite .... Prompt hatte Mister FireTV Stick auch keine Lust mehr auf WLAN. Also Downgrade und gut ist es ... ausser das generve, da wäre ein Update.

Redest Du von einem Netz das kein Internet mehr haben darf oder sind das mehrere VLANs und die sollen alle nicht mehr ins Internet kommen wenn VPN ausfällt?

Kannst evtl. im WAN-OUT ne Firewall Regel erstellen, die alles aus den gewünschten Quell Netzen blockt. Wäre die einzige Idee die ich so hätte.

Ich bin immer wieder überrascht was manche Menschen sich so ausdenken

Wofür ist das ganze gut - rein informativ?

Hmm sieht auch erstmal nicht so logisch aus. Was hast Du denn so an Firewallregeln für Traffic von VLAN 1 nach VLAN 3? Ist im NAS irgendwas an Firewall aktiv?

Da müsste man wohl Wireshark bemühen um evtl. zu ermitteln wer da eigentlich wirklich mit wem kommuniziert und was da an den Paketen wie auch immer SNATet und/oder DNATet wird. Allerdings muss ich zugeben mit Wireshark hab ich mich noch nie befassen müssen und es ist für mich ein Buch mit 7 Siegeln.

Aber ansonsten macht doch der 2. Versuch genau das was Du möchtest und hat sogar den Vorteil, dass Du nicht den Zugriff auf das komplette VLAN1 erlauben musst. Ist jetzt halt nur die Frage warum ist das so, ist das auch wirklich sicher und ist das evtl. auch nur irgendein BUG.

Die Regeln musst Du in LAN-IN erstellen!

Von der Reihenfolge her als erstes die Regel fürs Server erlauben und dann die Regel für Port 25,x,x für alle verbieten, so wie Du es wohl schon gemacht hast.

Du könntest bei theoretisch noch das Protokoll auf TCP stellen wenn es ums Mailen geht.

Sinn der Sache ist man konfiguriert die VPN und dann läuft die permanent. Soll der Administrator etwa jedesmal bei Bedarf die VPN anmachen wenn ein Benutzer die benötigt?

Für temoräre VPNs nutzt man eigentlich einen Client auf der Maschine des Nutzers und der kann dann selbst aktivieren/deaktivieren.

Welchen zweck hat denn das trennen?

probier mal via ssh (im Zweifelsfall mit Sudo)

/etc/init.d/openvpn stop

/etc/init.d/openvpn start

Hab kein OpenVPN konfiguriert und kann dementsprechend nicht schauen was genau passiert und was da überhaupt läuft.

Zitat von anton

können tut man immer, dann braucht man nativ Vlan fähige Hardware, was günstige Switches halt nicht sind deswegen ist es bei UI halt recht einfach, da sonst das Vlan Routing die UDM/... übernimmt. hängt da die AP´s an ner Fritzbox(mit nem "dummen" POE Switch dazwischen), kannst du auf den AP´s Vlans konfigurieren wieviel du willst, das wird nix, da die Fritzbox das nicht kann.

Es hat schon nen grund, warum ich das gesagt hab. Mach mal n Vlan mit Unifi AP´s die auf Omada Switches und ner Fritzbox, hängen,... und such dann Fehler bzw probier es fehlerfrei zum laufen zu bewegen. viel spass dabei (und schlaflose Wochen).

Nicht alles, was theoretisch irgendwie geht ist sinnvoll. und wenn du es doch irgendwie zu laufen bekommst, und hast dann n fehler, wird jeder hersteller die Schuld auf die anderen schieben, bei so heterogenen mischmasch sind sie raus

Keine Ahnung was Du gelesen hast, aber in meinem Post steht genau das drin.

Und mit UniFI APs, irgendeinem VLAN fähigen Switch und einer Fritzbox bekommt man spielend einfach 2 getrennte Netze mit getrennten WLANs und gemeinsamen Internetzugang hin. Gar kein Problem. Die Trennung ist zwar fest und die Netzanzahl auf 2 fixiert aber es soll ja auch dafür Bedarf geben.

Was sinnvoll und was nicht sinnvoll ist, entscheidet der Anwendungsfall und das Budget ... Für das Geld einer Fritzbox kann man auch problemlos Modem und ER-X kaufen und hat da einige Möglichkeiten mehr als mit Fritzbox, selbst als mit UDM und co. Natürlich muss man sich dann mit mehreren Konfigurationen "quälen".

Hab mal son Teil angeschlossen das auch konfiguriert ist. Wie man sieht ist die Version nicht ganz taufrisch und wird trotzdem in gängigen Browsern angezeigt. Die Seite sollte eigentlich immer erscheinen. Möglicherweise gibts in manchen Versionen Bugs mit bestimmten Browsern und irgendwelche Schaltflächen funktionieren dann nicht.

Das kommt wenn man die IP des Cloudkeys im Browser aufruft https://IP-Adresse (natürlich mit Zertifikatswarnung)

mit https://IP-Adresse:8443/ kommt das Login in die eigentliche Controller Oberfläche (jetzt Network APP) http:// geht hier nicht. Gültiger Benutzer und Passwort kann hier alles mögliche sein, da ja Benutzer angelegt und gelöscht werden können. Kommt da nichts oder fehlt das ganze sogar, dann ist vermutlich die Mongo DB platt (Stromausfälle) dann geht nur noch Factory Reset und ggf. Backup einspielen, falls aktiviert und SD Karte ok.

https://IP-Adresse/login führt zu den Einstellungen des Cloudkeys (IP Einstellungen usw.) Hier gab es was Benutzer und Kennwörter anging bei einem Firmwareupdate Änderungen. Bei meiner Version ist ändern des Benutzers und Kennwortes möglich. Da war aber irgendwas, vonwegen gleicher Kennwörter für die diversen Logins, wenn ich mich recht erinnere

Solltest Du dich in den Controller (2. Bild) einloggen können dann kann man in den Einstellungen der Site(Standort) sehen ob SSH aktiviert ist und welcher Benutzer und welches Kennwort gültig ist. Diese Daten sollten bei einer adoptierten USG das default Login überschrieben haben. Achtung das ist pro Site!

Sollten die UniFi Geräte nach Änderungen des Benutzers und/oder Kennwortes nicht mehr mit dem Controller kommuniziert haben (Provisioning) und dies jetzt auch nicht tun, also Offline sein, dann besteht die Möglichkeit, dass in den Geräten das Vorgänger Kennwort enthalten ist.

Passwort Recover sollte wie folgt gehen, falls ein Backup vorhanden ist. Gleiches auch wenn MongoDB defekt. Der blinkt dann weiß soweit noch erkennbar.

1. SD Karte auf Backups checken, Windows kann das so nicht lesen, da Linux Filesystem, Karte nicht im eingeschalteten Zustand rein oder raus, Backups auf den Konfigurations PC ziehen
2. Wenn Backups vorhanden und auf PC, Karte rein (mit glück geht Restore auch von da) und Booten lassen
3. Wenn fertig gebootet einen Factory Reset machen und Neustart abwarten
4. Dann mit default login/password anmelden
5. Das letzte verfügbare Backup wieder herstellen
6. Neuen Admin und Passwort erstellen
7. Firmwareupdate Cloudkey
8. Update Controller Network APP
9. Geräte Firmware Updaten

7. 8. 9. Aufpassen wegen uralt Accesspoints, Da wurden mal welche in EOL geschoben. Ich weiß nicht ob die noch Konfigurierbar sind, wenn Controller zu neu. Die 6.0.45 die auf meinem Key hier drauf ist, war glaube ich die letzte Controllerversion vor dem Stichtag. Hier die Ankündigung von damals:

https://community.ui.com/questions/Select-UniFi-Access-Point-AP-Models-Obsoletion-Date-March-1-2021/65487283-ce9d-49f4-85b9-b6aa54659ef7

Zitat von WowaDriver

Holt mich mal ab, was brauch ich den wenn ich einen VPN Anbieter als Tunnel für alle meine Geräte haben will, ich nahm an einen Server oder?

Nee eher einen Client. Du willst Dich ja beim VPN Server des VPN Anbieters "einwählen". Wenn Du bei Dir einen Server einrichtest, dann müsste der Anbieter sich bei dir einwählen.

Bei Wireguard ist Server und Client als Bezeichnung nicht mehr so ganz zutreffend / eindeutig, zumal die Konfig ziemlich gleich ist.

Aber der Controller wird für VLANs auch nur zum Konfigurieren benötigt. Und man kann sehr wohl dort VLANs erstellen für die UniFi Gerätschaften. Hat man anderen Router und/oder Switches muss man diese mit deren Konfigurationsoberfläche passend konfigurieren (Gleiche VLAN/VLANIDs anlegen und richtig auf die Ports verteilen).

Dafür müssen allerdings die Frendgeräte auch VLAN Unterstützung haben. UDM und co. sowie USWs haben das soweit an Board.

zeitnah ... ich liebe dieses Wort ich drück die Daumen.