Beiträge von razor

Zitat von tomtim

Ich habe mir mal 2 von denen hier bestellt :

Amazon Lüfter

Mal sehen wie die sind. Werde ich mal testen. Das Geräusch nervt einfach.

Aktuell nimmt Amazon €15,90 / Lüfter: Noctua NF-A4x20 FLX.

Selbst mein Haus- und Hoflieferant CaseKing hat keinen anderen Preis.

Habe den Kanal in PETG schon Mal in Auftrag gegeben...

Zitat von Kref

Kann ich das alte USG einfach rausnehmen, das neue einsetzen und anschließen, einbinden und dann läuft es oder ist sonst noch was einzustellen?

Du solltest das USG im Controller vergessen und dann das neue Gateway hinzufügen. Nicht, dass Du am Ende noch zwei Gateway hast.

Zitat von S3N0C

Hallo zusammen,

ich habe ein Problem, bei dem ich langsam nicht mehr weiter komme. Ich habe einen Netgear Switch an einem USW-Pro-Aggregation hängen. Gebe ich dem Netgear Switch zum Beispiel auf Port 11 das VLAN 214 und stecke dort einen Laptop ran, bekomme ich keine IP Adresse.

Stecke ich den Laptop an einen UniFi Swtich, der auch an dem USW-Pro hängt und auf Port 11 das VLAN 214 hat, bekomme ich sofort eine IP Adresse. Ich weis langsam nicht mehr, was ich an dem Netgear Swtich noch einstellen soll.

Kann es sein, dass sich Unifi und Netgear untereinander einfach nicht vertragen?

VG

Alles anzeigen

Ich wette, dass der Client eine Adresse aus dem Pool 192.168.1.0/24 bekommt - oder APIPA.

Zitat von jkasten

Das sieht erstmal gut aus.

Das hängt leider maßgeblich davon ab :

Zitat von jkasten

Welchen Netgear hast du denn?

Falls der NetGEAR-Switch unmanaged ist, dann kann der das VLAN 214 so oder so nicht pro Port anbieten S3N0C .

Dann muss das VLAN 214 nativ (AccessPort) auf dem UniFi-Gerät konfiguriert werden und alle an dem nicht näher benannten NetGEAR-Switch bekommen IPs aus dem 214er VLAN.

Außerdem ist das VLAN lt. Screenshot tagged: das bedeutet, dass der Client das VLAN-Tag von dem IP-Paket entfernen können muss. Wenn da z.B. ein TV angeschlossen wird, dann wird der das sicher nicht können --> 214er VLAN muss nativ (AccessPort) anliegen. Damit entfernt der Switch das VLAN-Tag.

Falls der Switch managed sein sollte, dann musst Du auf dem Uplink-Port zwischen UniFi- und NetGEAR-Gerät auf beiden Seiten das 214er VLAN taggen. Dann kannst Du das auch auf dem NetGEAR-Switch verteilen.

Folgende Fragen stellen sich mir darüber hinaus:

• Wie ist der Uplink zwischen USW-Pro-Aggregation und UniFi Switch konfiguriert?
• Wie ist der Uplink zwischen USW-Pro-Aggregation und Netgear Switch konfiguriert?

Willkommen auch von mir aus der HauptStadt.

Zitat von gierig

Damit wird aber nur das NAT umgangen. Externe / Interne IP müssen trotzdem in Unterschiedlichen Netzen sein damit

auch der Router routen kann.

Transparent ins sinne einfach dazwischen hängen und ich muss Links und Rechts nicht ändern geht nicht.

Ganz allgemein gibt es auch nur ganz wenige Geräte die dafür da sind um Transparent irgendwo eingeschaltet zu werden.

Diese beruhen fast immer drauf das Beide Ports eine Bridge bilden (Zwei Port Switch) und verfolgen

eigentlich nur das Ziel um gezielt den Traffic Monitoren zu können.

Alles anzeigen

Dann müsste ich mir den wiki-Beitrag noch einmal durchlesen, um das genau zu verstehen.

ABER:

Zitat von daujens

Daher kann und will ich mein Netzwerk nicht umbauen.

Dann wirst Du das USG umsonst gekauft haben.

Zitat von Naichbindas

Und Geräte wo du schreibst das keine Ahnung woher könnten Wlan Geräte gewesen sein die eine variable MAC Adresse verwenden.

mfg

Üblicherweise wechseln die Geräte (Apple- wie Google-OS) die MAC-Adresse nicht ständing im WLAN, sondern nur wenn sie von einem WLAN in ein anderes kommen. Es könnte aber sein, dass der Client immer wieder zwischen 2,4GHz und 5GHz WLAN wechselt. Das wäre auch doof.

Herzlich willkommen auch aus der HauptStadt.

Herzlich willkommen auch aus der HauptStadt.

Auf meinem UC-CK mit Firmware 1.1.19 sieht die Config so aus - mit letzter verfügbarer Controller-Version 7.2.92:

root@CloudKey:~# cat /etc/nginx/sites-enabled/cloudkey-webui
server {
        listen [::]:80 ipv6only=off;

        root /usr/share/cloudkey-webui/www;
        index index.html;
        server_name localhost;
        access_log off;
        log_not_found off;
        server_tokens off;

        location /offline {
                try_files $uri $uri/ /index.html last;
                break;
        }

        location ~ /(config|css|js|images|data|locales|fonts) {
                try_files $uri $uri/ =404 last;
                break;
        }

        location ~ ^/api/ {
                rewrite ^/api/(.*) /api.php?$1 last;
        }

        location ~ \.html/ {
                rewrite ^(.*\.html)/ $1 last;
        }

        location ~ ^.+\.php {
                try_files $uri =404;
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                fastcgi_pass unix:/var/run/php5-fpm.sock;
                fastcgi_index index.php;
                include /etc/nginx/fastcgi.conf;
        }

        location ~ ^.+\.inc$ {
                deny all;
        }

        location / {
                return 302 https://$host$request_uri;
        }
}

server {
        listen [::]:443 ssl ipv6only=off;
        ssl_protocols TLSv1.2;

        root /usr/share/cloudkey-webui/www;
        index index.html;
        server_name localhost;
        access_log off;
        log_not_found off;
        server_tokens off;
        client_max_body_size 512M;
        send_timeout 600s;

        error_page 500 502 503 504  /status-500.html;
        error_page 403 /status-403.html;
        error_page 404 /status-404.html;

        ssl_certificate /etc/ssl/private/cloudkey.crt;
        ssl_certificate_key /etc/ssl/private/cloudkey.key;

        location / {
                try_files $uri $uri/ /index.html;
        }
        location = /favicon.ico {
                access_log off;
                log_not_found off;
        }
        location ~ ^/api/ {
                rewrite ^/api/(.*) /api.php/$1 last;
        }
        location ~ \.php/ {
                rewrite ^(.*\.php)/ $1 last;
        }
        location ~ \.html/ {
                rewrite ^(.*\.html)/ $1 last;
        }
        location ~ ^.+\.php$ {
                try_files $uri =404;
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                fastcgi_pass unix:/var/run/php5-fpm.sock;
                fastcgi_index index.php;
                include /etc/nginx/fastcgi.conf;
        }
        location ~ ^.+\.inc$ {
                deny all;
        }
}

Auf meinem UCK-G2-PLUS mit UniFi OS 3.2.10 und UniFi Network Application 8.0.26 sieht das aber mal ganz anders aus...

Ja, mit dem USG* kann man doppeltes NAT noch umgehen:

USG | doppeltes NAT abschalten (USG-only).

Das geht dann mit der gateway.config.json. Weiteres s.o.

Vielleicht kann sich ja BlackSpy noch an die Anhänge 1910 & 1911 erinnern.

Oder auch extern HIER.

Du hast Dir da ja ein schönes Projekt herausgesucht Kolungate . 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.

Hallo Rockhound53 ,

im wiki gibt es dazu einen Artikel:

DNS | DynDNS mit der UDM (Pro / Base) - ubiquiti - Deutsches Fan Forum

Vielleicht lohnt sich das Lesen. Du kannst natürlich gern Deine Frage dazu stellen.

Zitat von defcon

Eigentlich sollte da dein DNS Resolver drin stehen, welchen du im PiHole eingetragen hast.

Tja, es ist wie es ist. Dort stehen die root-Server drin, nix Provider.

Gespenstisch.

Zitat von defcon

Wenn du 2 DNS Server intern laufen hast z.B. 1. pihole 2. Telekom bzw. Per DHCP verteilst, kannst du nicht sicherstellen, dass immer der pihole genommen wird, auch wenn dieser an erster stelle steht.

Ich habe in den VLANs meine beiden pi-holes eingetragen. Das funktioniert sehr gut für mich. Allen Clients wird wie gewünscht ein pi-hole zugewiesen.

Zitat von sidewinder

Da ja teils aus den Screenshots von mir englische Kommentare ersichtlich sind – ich habe auch nach einer gefühlten Ewigkeit eine Info vom Support vom Ubiquiti Help Center erhalten, denen hatte ich das auch erläutert und ein Support-File mitgeschickt.

Hier die Antwort vom Support:

Das ist auch korrekt (gewesen), testweise habe ich jetzt dann mal in allen Netzwerken das Content Filtering rausgenommen, alles auf "None" gestellt und werde zu nachtschlafender Zeit die UDM mal restarten. Morgen schaue dann mal, was das gebracht hat. Ergibt auch Sinn für mich, was der Support da schreibt. In einem Netz hatte ich den Family-, in einem anderen den Work-Filter drin.

Ich berichte weiter, morgen oder so.

LMFAO! Hmkay...

Das habe ich nicht gesehen / ist mir nicht aufgefallen, da ich diese Feature selbst nicht benutze. Ich habe aber oben auch kein Bild ofer hinweis gefunden, dass Du den Content-Filter aktiviert hattest.

Zitat von Denyseus

Moin,

letztlich siehst du schnell welcher DNS-Server zur Auflösung genutzt wird. Ist bei mir z.b. manuell in den Netzwerkeinstellung 1.1.1.1 Cloudflare eingestellt erhalte ich auch genau diesen als Ergebnis:

Nehme ich die manuelle Einstellung wieder raus, nimmt er die die er per DHCP bekommen hat.

Diese verweisen dann ja auf den Adguard-Server. Der löst dann, je nach Einstellung innerhalb von Adguard, ja mit anderen DNS-Servern auf. Du siehst also direkt, ob Adguard genutzt wird, oder nicht.

Ist nichts manuell eingestellt, und per DHCP auch nichts manuell übertragen, nimmt er ja den DNS der in der Unifi eingestellt ist. Also wenn nichts geändert ist, der von deinem Internetanbieter.

Alles anzeigen

Dann war der Test doch erfolgreich? Das Ergebnis des erweiterten Tests sieht bei mir so aus (siehe Signatur für mein Setup):

Angezeigt wird meine öffentliche IP und der zugehörige Hostname. Ich habe zwar 2 DNS-Server auf dem Systen konfiguriert, von dem aus ich den Test gemacht habe, aber auch das könnte OK sein.

Zitat von Denyseus

Mal mit https://dnsleaktest.com geschaut welche DNS-Server genommen werden? Standardmäßig wird das ja der von deinem ISP sein.

Ich verstehe nicht, was das Ergebnis bedeuten soll. Mir wird meine IP und der zugehörige DNS-Name angezeigt, sonst nix. Oder ist der Test damit erfolgreich gewesen, denn ich verwende pi-holes in meinem LAN als Werbe-Blocker und unbound als DNS-Server?

Das Ergebnis von beiden Tests ist bei mir gleich.

Zitat von sidewinder

Die Ergebnisse bringen mir mehr Verwirrung denn Klarheit.

Das sehe ich auch so.

Alle meine Clients verwenden die in einem separaten VLAN vorhandenen pi-holes und ich sehe auch die LAN-IPs der Clients in den pi-holes.

Kannst Du in AdGuard auch die einzelnen Clients sehen sidewinder ? Die sollten da auftauchen, wenn Du die AdGuard-IP in den VLANs als DNS-Server eingetragen hast - so wie ich bei mir.

Wenn Du das nur in den UDM bei der Internet-Verbindung konfiguriert hast, dann wirst Du wahrscheinlich nur die UDM als Client sehen.

Zitat von bl4ckr4ptor

Auf den Devices stimmen überall der gateway 192.168.1.1 und die subnet mask 255.255.254.0?

Guter Hinweis.

Bei der o.g. Lösung ist das zwar wahrscheinlich kein Problem, auch deswegen nicht:

Zitat von MaT75

So... ich habe das Problem jetzt wie folgt gelöst:

Ich konnte das Problem so weit isolieren, dass die Shellies Gen 1 i.V.m. HomeKit mit dem U6 Pro nicht zusammenspielen. Ich habe jetzt die APs getauscht und den U6 Pro an eine Stelle gehängt, wo er keine Shelly Gen 1 bedienen muss und das Shelly-WLAN auf diesem AP deaktiviert. Damit bin ich das Problem umgangen.

Doof, weil es eigentlich der beste und hochwertigste AP ist, aber die U6 Lite funktionieren da tatsächlich besser.

Sollte aber dennoch stimmen. Sonst wird schwierig mit der Verbindung.

Zitat von Tobi68

Ich wollte umstellen auf Durchleitung PPPoe passtrue. (sorry falls ich mich da etwas ungenau ausdrücke.. versuche mich da reinzufuchsen)

PPPoE-Passthrough müsstest Du auf dem Gerät aktivieren, welches eine Anmeldung mit PPPoE durchlassen soll: in Deinem Fall also die FRITZ!Box, welche aktuell die Einwahl übernimmt.

Das sollte meiner Erinnerung nach einfach während des Betriebs aktiviert werden können und sollte maximal eine erneute PPPoE-Einwahl der FRITZ!Box nach sich ziehen - wenn überhaupt.

Wie oben auch schon erwähnt kann es sein, dass dieses Merkmal (2. PPPoE-Einwahl) durch Deinen ISP aktiviert / zugelassen werden muss, was wiederum zusätzliche Kosten bedeuten könnte.

Ob doppeltes NAT für Dich / bei Deinem Setup ein Problem ist, kann ohne Deine Anwendungsfälle zu kennen von außen niemand beurteilen. Doppel-NAT ist nicht per se notwendig zu vermeiden, erleichtert es einem aber wohl z.B. die Konfiguration von VPN-Zugriffen auf das (heimische) LAN. Bei einem Doppel-NAT-Setup muss man unter umständen etwas erfinderisch sein, um das ans Laufen zu bekommen. Oder wie hier beschrieben:

Beitrag

RE: Einrichtung der UDM SE mit Fritz 7590 nur noch als DSL Router

Guten Abend,

ich hatte einen sehr ähnlichen Ablauf wie du.

Am Ende war der sinnvollste Aufbau eine 7590(ax) als DSL Modem (die neuen Modelle haben im VDSL 35b Profil Bereich einfach die beste Performance) mit einer klassischen PPPoE Einwahl als erstes Gerät einzusetzen. In der Box dann die UDM-SE als Exposed Host deklarieren um diese öffentlich erreichbar zu machen (wenn man das will).
Hier musst du nur beachten, dass im Wireguard o.ä. nicht die private IP der UDM als Endpoint im cfg File…

SteveStar

20. Januar 2024

Zitat von Tobi68

Ich hab noch ne freie 7390 hier rum liegen, ich schaue mir den Punkt 4 von dir nochmal genauer an, evtl. habe ich da doch was übersehen.

Es kann sein, dass Du nicht alle Konfigurationsparameter angezeigt bekommst, wenn die Box nicht via DSL verbunden ist. Man kann den Verbindungstest aber überspringen - meine ich.

Außerdem kann die 7390 max. VDSL2 nach DT AG 1TR112 (auch IP-basiert) bzw. ITU G.993.2 (bis 17 MHz) (siehe HIER oder im Anhang).

Zitat von schnea

Öffne ich jetzt die Konfigurationsdatei am Mobiltelefon mit Wireguard APP und kriege folgende fehlermeldung "kann tunnel nicht importieren ungültiger name"

Bei dieser Meldung würde ich die Daten aus der Datei manuell in den Client übertragen und es dann ncoh einmal versuchen. Ich meine, dass ich bei Android beim Import auch Schwierigkeiten hatte, kann mich aber nicht mehr genau daran erinnern, was da nicht wollte. Benenne die config mal um bevor Du sie versuchst zu importieren: nur Buchstaben.

Android oder Apple? Das wäre auch ganz gut zu wissen. Kannste oben gern aktualisieren.

Falls dann (später) der Verbindungsaufbau nicht klappt: Hast Du eine echte öffentliche IPv4-Adresse? Kein CGNAT? DAS wird Dich beim Import der Config natürlich noch nicht stören - denke ich, aber spätestens beim Verbindungsaufbau dann.

Bitte prüfen.

Es kann zu Problemen kommen, wenn Du die VPN-Verbindung aus dem heimischen WLAN versuchst aufzubauen.

Außerdem: Wenn Du bei AllowedIPs die Adresse 0.0.0.0/0 aufnimmst kannst Du Dir alles andere sparen. Nicht, dass das der Fehler ist - was ich bei der obigen Meldung aber nicht annehmen würde.

Die Config hättest Du auch gern als Code (Schaltfläche </> oben) posten können.

Zitat von Sand-rox

Danke euch, ich werde es später mal testen. Muss erst mal noch was schaffen

Na? Wie waren die letzten neun Tage? Hoffentlich warst nicht die ganze Zeit offline.