Posts by Lardie

Ich sehe das ganz ähnlich – nativ läuft WireGuard einfach näher am System, weniger Overhead, und man spart sich das Container-Verschachteln. Besonders wenn schon mehrere Docker-Container auf dem NAS werkeln, ist es angenehm, wenn wenigstens das VPN nicht noch eine zusätzliche Netzwerkschicht aufmacht. Die Performance ist beim nativen Modul in der Praxis tatsächlich meist minimal besser, besonders bei Durchsatz und Latenz. Was viele unterschätzen: Auch die Fehlersuche wird einfacher, weil man nicht ständig zwischen DSM, Docker-Netzen und Container-Logs switchen muss. 😊

Aus der Praxis kann ich aber ein paar Knackpunkte nennen, die man auf dem Schirm haben sollte – gerade bei Inkompatibilitäten nach DSM-Updates oder Kernel-Änderungen. Ich hab mir angewöhnt, nach jedem großen Update auf der Synology gezielt zu prüfen, ob das WireGuard-Modul noch lädt (mit lsmod | grep wireguard). Notfalls muss man das Kernel-Modul manchmal neu bauen oder die richtige Version nachziehen. Wer das nicht regelmäßig kontrolliert, steht unter Umständen plötzlich ohne VPN da…

Was den Autostart angeht: Das rc.d-Skript ist funktional, aber ich hab erlebt, dass gelegentlich nach Updates oder wenn DSM zickig wird, das Skript nicht ausgeführt wird oder Rechteprobleme auftreten. Hier hilft es, das Skript auf Standard-Shebang (#!/bin/sh) und Ausführbarkeit (chmod +x) zu prüfen. Wenn’s damit nicht läuft, kann man testweise auf einen systemd-approach umdenken – ist aber auf DSM ein ziemlicher Hack. Alternativ regelmäßige Healthchecks per Cron, die prüfen, ob das Interface läuft, und sonst einen Neustart triggern.

Abschließend noch ein schneller Vergleich, damit’s jeder im Blick hat:

Falls jemand das noch sauber mit UGREEN-Backuplösungen oder Synology Apps kombinieren will: Ich hab festgestellt, dass es am stabilsten läuft, wenn WireGuard als erstes Netz-Interface nach dem Hochfahren steht – dann meckert keine andere App wegen fehlender Connectivity...

Falls wer bessere Wege für Autostart/Update-Überwachung hat, gern her damit, ich probiere sowas immer gern! Bin mir auch nicht sicher, ob ich vll irgendwo was übersehe... 😅

Bei solchen E-Mail-Zustellungsproblemen hab ich ehrlich gesagt schon alles gesehen – von simplen DNS-Aussetzern bis zu richtig fiesen Konfigurations-Hickups. Mein Ansatz ist oft gar nicht mal der berühmte „Alles auf einmal“-Check, sondern eher wie so’n Werkzeugkoffer: Immer ein Tool nach dem andern raus, sonst verheddert man sich völlig.

Hier mal meine Step-by-Step-Checkliste, die sich bei mir mit Exchange Server 2016 (CU20, falls’s jemand wissen will) bewährt hat – und die funktioniert mit kleinen Abwandlungen eigentlich quer durch die Exchange-Versionen:

1. Transportrouten im Blick behalten
   • „Get-TransportService“ plus „Get-SendConnector“ in der Exchange Shell: Zeigt oft schon, ob da was im Argen ist (z.B. Tippfehler in Ziel-Domains, fehlende Authentisierung).
2. Nachrichtenverfolgung (MessageTrackingLog)
   • Für mich das Go‑To‑Tool. „Get-MessageTrackingLog -Recipients user@domain.de -Start (Get-Date).AddHours(-4)“ – da siehst du fast alles, besonders gut um Fehlercodes abzugreifen.
   • Tipp: Die Filter für „EventID“ (RECEIVE, DELIVER, FAIL) helfen bei der groben Einordnung, ob die E-Mail stecken bleibt, geblockt wird oder irgendwo im Nirvana verschwindet.
3. Queue Viewer
   • Gerade bei spürbaren Verzögerungen: Schauen, ob E-Mails „hängen“. Ich hatte mal den Fall, dass die UGWREN Switches im Rack gepatzt haben – da war gar kein Exchange-Problem, sondern einfach Pakete verloren.
4. Protokollprotokolle (SMTP/Connectivity)
   • „ProtocolLoggingLevel“ mal auf verbose setzen, so siehst du, an welchem Punkt die Verbindung abbricht. Aber Vorsicht: Nicht vergessen, das wieder zurückzusetzen, sonst platzt die Platte voll.
5. DNS- und Reverse Lookup
   • Nicht unterschätzen! Ein schräger PTR-Eintrag (Reverse DNS) hat mir schon mal einen halben Tag Suche gekostet… und am Ende wars nur ein kleiner Zahlendreher.

Wenn du deine eigenen E-Mail-Flows auf dem Synology NAS (z.B. mit MailPlus oder auch als Relay) laufen lässt: Da ist die Kombination aus NAS-eigenem Logfile und Exchange-Tracking besonders spannend. Einfach mal die Logs gegeneinander halten, vll sieht man da Timeshift oder Blockaden.

Was ich mich manchmal frage: Wie dokumentiert ihr eigentlich eure Troubleshooting-Schritte? Steht alles irgendwo in OneNote oder gibts bei euch noch klassisch Zettelwirtschaft? Würde mich interessieren, ob ihr Tools wie z.B. UGREEN Docking-Stationen für schnelle Log-Sicherung nutzt – oder ist das zu nerdig?

Also ich muss ehrlich sagen, das Thema KI auf der NAS hat für mich was total Handfestes – aber auch so seine Tücken. Die AI Console klingt erstmal spannend, aber ich hab gemerkt, dass viele sofort denken: „Wow, jetzt hab ich ChatGPT direkt auf meiner Diskstation laufen!“ Dabei ist’s ja eigentlich „nur“ ne ziemlich schlaue Brücke zu externen Diensten… aber halt unter den eigenen Datenschutz-Bedingungen. Finde ich persönlich beruhigend, weil’s eh schon genug Datenkraken gibt. 😅

Hab gestern mal testweise die Anbindung an OpenAI konfiguriert (was ehrlich gesagt ein bisschen Fummelei war, weil der API-Key ja richtig gesetzt und die Dienste freigeschaltet werden müssen). Tipp von mir: Leg am besten einen eigenen API-Schlüssel pro Anwendung an und begrenze die Rechte auf das Nötigste in der AI Console. Und immer schön im Log nachsehen, welche Zugriffe laufen – Synology protokolliert das zum Glück ziemlich transparent. Bei mir im Office ist vor allem das automatische Verschlagworten von Dokumenten für die Drive-App nützlich. Spart tatsächlich Zeit, selbst wenn nicht alles 100% korrekt erkannt wird. Kleine Randnotiz: Die automatische Zusammenfassung längerer E-Mails in MailPlus haut manchmal daneben… einfach mal ausprobieren und nicht blind vertrauen. 😉

Was ich auch cool finde: Die AI Console lässt wirklich granular steuern, welche Apps überhaupt auf KI-Dienste zugreifen dürfen. Für Admins, die so einen Kontrollzwang haben (wie ich manchmal), goldwert. Allerdings – für Privatanwender mit kleiner Home-NAS weiß ich nicht, wie groß der praktische Nutzen ist. Wer seine NAS eh nur als Backup-Kiste benutzt, wird mit der AI Console vermutlich nix anfangen können. Aber wer viel mit Dokumenten, Notizen und Office-Kram arbeitet, da sehe ich echtes Potenzial. So als persönlicher Mini-Assistent eben… Manche Datenbank-Aufgaben würde ich trotzdem nach wie vor nicht aus der Hand geben, aber für Routine-Geschichten ist’s echt nützlich. (Nebenbei: Kaffee hat heute früh den Weg über meinen Schreibtisch gefunden… Tastatur lebt noch.)

Was mich jetzt interessieren würde: Nutzt hier jemand die AI Console produktiv im Team oder auch im Familienbetrieb, und gab’s schon echte Aha-Erlebnisse oder (unerwartete) Probleme? Wo seht ihr aktuell die größten Stolpersteine – eher bei der Technik oder bei der Akzeptanz der Nutzer?

Also, ich hab mal noch einen anderen Ansatz zum NFON Cloudya-Thema, der bisher ein bisschen zu kurz kam: Wie holt ihr das Maximum an Übersicht und Kontrolle raus, wenn ihr mehrere Standorte oder Teams habt? Ich habe bei ein paar Kunden gemerkt, dass da oft Unordnung reinkommt, gerade wenn die Cloudya-Anlage mit mehreren Außenstellen oder Homeoffice-Leuten aufgesetzt wird… Da hilft dann auch die beste Videoanleitung irgendwann nicht mehr, wenn die Struktur fehlt. 😅

Hier meine kleine Werkzeugkasten-Liste zum „Cloudya aufräumen & skalierbar halten“, vor allem wenn’s größer wird:

1. Namenskonventionen für Nebenstellen und Gruppen:
   Ihr glaubt nicht, wie oft ich schon wilde Zahlen und Fantasienamen gesehen hab… Am besten direkt zu Beginn überlegen: Einheitliches Schema für User, Orte, Durchwahlen (z.B. „MS-FRANKFURT-102“ statt „Anna“ oder „Küche“), dann gibt’s später viel weniger Sucherei.
2. Regelmäßige Nutzer-/Gruppen-Checks:
   Kurz alle 3 Monate (z.B. per Excel-Tabelle exportieren) durchgehen: Wer ist aktiv? Welche Gruppen braucht’s wirklich noch? Gerade bei hoher Fluktuation im Team schleicht sich da viel toter Eintrag ein. Macht das ruhig wie so’n kleinen Hausputz.
3. Verteilte Admin-Rechte:
   Klingt erstmal riskant, aber: Gebt pro Standort einen lokalen „Telefon-Admin“. Das verhindert, dass alle Änderungen nur zentral (und oft zu spät) passieren. Voraussetzung: Klare Checkliste, was gemacht werden darf – notiere ich mir immer auf Papier neben dem Monitor… naja, ihr wisst schon.

Zusätzlich – ist jetzt vielleicht ne blöde Frage, aber nutzt ihr die Cloudya-Reports zur Nachverfolgung von Anrufen/Festnetz-Ausfällen überhaupt? Ich hab die früher total ignoriert, dann aber einmal im Support gemerkt, wie schnell man damit auch Fehlerquellen aufspürt. Zum Beispiel, ob die Weiterleitung wirklich wie geplant in jedem Szenario greift, gerade wenn komplexes Routing im Spiel ist.

Hier noch meine Step-by-Step-Lösung für typischen Supportfall „Anruf kommt nicht durch“:

• User/Gruppe identifizieren
• Letzte Änderungen in der Cloudya-Historie prüfen
• Testanruf aus Fremdnetz protokollieren
• Report-Auswertung (Fehlerquellen, Weiterleitung, Zeitsteuerung)
• Erst jetzt Störung beim Anbieter melden – nicht vorher! 😉

Kleine Anekdote am Rande: Ich hatte ein Mal das Problem, dass die Zeitsteuerung auf Sommerzeit noch nicht umgestellt war und dadurch ein ganzer Standort ab 17:00 „unsichtbar“ wurde. Seitdem prüfe ich bei jeder Zeitumstellung auch die Cloudya-Regeln… Spart Nerven! 👀

Hat sonst noch jemand Tipps zum Thema „Cloudya sauber und zukunftsfähig halten“, gerade bei mehreren Standorten? Würde mich interessieren, welche Routinen ihr nutzt oder ob jemand schon mal was komplett automatisiert hat.