Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Alles was *.domain.de ist muss an den internen NPM weitergeleitet werden. Pihole kann das nicht per Wildcard, sondern nur explizite Subdomains. Daher war der bind9 davor geschaltet.
Jetzt nutze ich Adguard und das kann das nativ, brauche den bind9 daher nicht mehr.
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Zwei habe ich nur beim pihole (Docker) gebraucht, da dieses öfters mal den Dienst quittiert hat.
Bei Adguard (LXC) habe ich noch keinen einzigen Absturz gehabt.
Oh doch, wenn ich schaue was Adguard trotzdem so alles blockt, trotz Browser mit uBlock. Viele Apps und Geräte versuchen weiterhin entsprechende Domains zu erreichen.
Wichtig ist in der Firewall die Nutzung eines anderen DNS per Regel zu blockieren, sodass sie den vorgegebenen nutzen müssen. Viele Entwickler hardcoden nämlich einen DNS und nutzen den per DHCP vorgegebenen nur wenn sie ihren nicht erreichen.
Für "html-load.com" lässt sich doch bestimmt was basteln, welches dessen Funktionen "Simuliert", dann könnte man die Anfragen dort hin umleiten 🤔
Verstehe auch nicht wirklich, worauf Du abstellst. Internes DNS macht doch zumeist eh der Router(/Firewall), da braucht es auch keine Redundanz. Und Host-Overrides (DNS rewrites), auch für Split-DNS ist super nützlich, dazu Ad-Blocking...
Mir ging es hier nur um die von asm@s24 geforderte Redundanz. Ich nutze auch (teilweise) AdGuard Home, aber der verwendet bei mir wiederum den Unbound der pfSense und dort mache ich die Overrides. Das mache ich so, weil nicht alle Hosts bei mir einen AdGuard brauchen.
Nicht wirklich. Die Webseiten, welche das nutzen, lagern CSS dorthin aus. Das ist ja gerade ein Anti-Adblock-Service, den sie einkaufen, um Dir den Spaß zu verderben.
Aber ok, hatte AdGuard mal vor 100 Jahren oder so als Browser-Extension. Die LXC-DNS-Variante kenn ich noch nicht, ich schau es mal an. Pihole und Technitium hab ich probiert und die überzeugen mich net so irre.
Netbird unterstützt doch auch diese Identity Provider oder nicht? Bei Tailscale ist es zumindest so und das hat mit dem Tunnelprotokoll nichts zu tun. Generell mag man das mit Netbird nicht müssen, aber dennoch muss ich ihnen und ihrer Software und ggf. Partnern vertrauen. Für mich löst aber ein Overlay-Netzwerk kein Problem. Hab auch nicht vor, anderen Leuten temporär hier Zugriff zu gewähren.
Ach so, ja, natürlich logg ich mit dem Google-Workspace ein, das macht es ja so praktisch. 🤘
In der Firma machen wir halt alles mit MS/Entra. Ohne IAM/SSO wird's schon mühsam mit der Zeit.
Und NetBird nehmen wir da auch.
Ich hatte es neulich in den Ferien, daß das Hotel-WLAN "klassisches" WG blockte. Das war dann, wo ich nun mal unterwegs war, schon ein Problem. Mußte also via grottenlahmem Mobilfunk operieren. Dazumal war Tailscale die Lösung, das ging auch im fremden WLAN. Mittlerweile gefällt mir Netbird besser. Ich mag nicht so gerne Keys handhaben ... umständlich ... unübersichtlich. Point'n'shoot in einer App geht viel bequemer, erst recht die Konfig der Peers (wer darf was wohin) in einer Weboberfläche.
Meine Mobildevices sind ja auch drin, werden bei Bedarf aktiviert. So bin ich immer überall mit dem Homelab verbunden, kann auf die Monitorseiten, PVE, eben alles. Gefällt mir.
Sicher kann man auch ohne diese Gimmicks leben, aber Spaß macht das nicht.
Hab es mal eben hopplahopp im Trixie-LXC aufgesetzt. Das ist wirklich irre schlank und sieht out-of-the-box tatsächlich gut aus. Kann sein, daß ich mich damit noch anfreunde. Hab jedenfalls Pihole (im Docker) vorerst stillgelegt. Jetzt interessiert mich das natürlich noch: https://netbird.io/knowledge-hub/adguard-home-dns-anywhere
Ich hab den LXC von community-scripts.org genommen, läuft auch top. Mein RAM-Verbrauch ist höher als eurer, weil ihr anscheinend kaum Listen benutzt.
Wenn ich die OPNsense als Haupt-Router nutzen würde, dann täte ich es wahrscheinlich dort laufen lassen.
Sosehr ich Proxmox als All in One (Hypervisor+NAS) schätze so sehr ärgert es mich immer wieder wie unsäglich umständlich SAMBA + Linux + Posix ACL sind. Habe jetzt bald eine Tag mit smb.conf gekämpft damit einfache SAMBA SMB shares einfach so funktionieren.
Mit ksmbd unter Proxmox wars sogar einfacher, der ist eh erheblich schneller.
Wers probieren möchte: curl -sL https://www.napp-it.org/cs_setup.sh | sh
Das kopiert den Ordner /opt/csweb-gui und startet einen Perl webserver ohne irgendwas an Proxmox zu ändern.
Dann Browser starten mit https://proxmoxip und im Menü Filesystem SMB für ein Dateisystem für eine Usergruppe, mit oder ohne Snaps aktivieren.
Über Rückmeldungen und Verbesserungswünsche würde ich mich freuen
Sosehr ich Proxmox als All in One (Hypervisor+NAS) schätze so sehr ärgert es mich immer wieder wie unsäglich umständlich SAMBA + Linux + Posix ACL sind. Habe jetzt bald eine Tag mit smb.conf gekämpft damit einfache SAMBA SMB shares einfach so funktionieren.
Hm ... hmm ...
Was mich am ZNAS immer wieder stört, es kann kein KSMBD. Und mit den Berechtigungen für nur zwei Win-Clients hier kämpfe ich auch immer wieder. Kann aber auch am scheiß Windows liegen.
Was bei Windows gerne Probleme macht, ist neben dem Caching der Zugangsdaten vor allem die höheren Sicherheitsanforderugen in aktuellem Windows (kein gastzugriff per default, verpflichtendes signing, kein smb1 mehr, encryption etc). Vor allem mit älteren SMB Servern gehts nicht mehr so einfach oder garnicht.
Das ist aber weniger ein Windows Problem. Ich begrüße das sogar. Man kann nicht immer über unsicheres Windows schimpfen und sich dann beklagen, wenn Microsoft alte Zöpfe abschneidet.
Mein aktuelle SAMBA Problem waren aber Debian Defaults in der smb.conf + pam defaults bei Usern ohne homedir (das deaktiviere ich per default und nutze nur ZFS Dateisysteme als Share weil nur da gibts saubere Zuordnung zu ZFS Snaps). Selbst mit Claude AI hats lange gebraucht um dahinter zu kommen.
Ksmbd gefällt mir aber immer besser, ist einfacher gestrickt als das total überladene SAMBA, bis ca 30% schneller dazu. napp-it erkennt selber ob ein ZFS Dateisystem-Share für ksmbd oder SAMBA aktiviert werden soll.
Hm ... hmm ...
Was mich am ZNAS immer wieder stört, es kann kein KSMBD. Und mit den Berechtigungen für nur zwei Win-Clients hier kämpfe ich auch immer wieder. Kann aber auch am scheiß Windows liegen.
Bei Samba /ksmbd muss man halt:
- acl installieren, neben samba oder ksmbd
- in der (k)smb.conf ein share für eine Gruppe aktivieren, ohne guest
- den Usern ein extra SAMBA (ksmbd) Passwort geben
- Die User der Linux Gruppe zuweisen
- Dem Ordner zusätzliche Posix Dateirechte für diese Gruppe geben
wenn man das alles auf der Linux Console sauber hinbekommt, klappts auch mit der WinDose, so zickig ist die garnicht wenn man nicht gerade ein Uralt SAMBA hat.
Es gibt viele mit einem älteren NAS/FreeBSD/Linux/OSX/Unix die jahrelang gut funktionierten und von heute auf morgen konnte das "blöde Windows" nicht mehr darauf zugreifen ....
Bin dabei etwas mit Netbird rumzuspielen.
Dabei ist mir jetzt aufgefallen das ein Exitnode es nicht mitbekommt, wenn sich die IP hinter der Domain des Management Servers ändert.
Sodass der Exitnode dann nicht mehr verfügbar ist.
Bei mir läuft dieser als LXC auf Proxmox.
Wie würdet ihr das nun handhaben?
Den LXC an einer festgesetzten Uhrzeit neu starten oder im LXC einen Cronjob laufen lassen, der dies macht?
Common misconception ...
Das, was die Peers untereinander austauschen, also Dein Netzwerk, ist end-to-end verschlüsselt. Ist ja WireGuard.
Bei NetBird wird lediglich die Konfig verwaltet. Die Peers holen sich ab, von wo nach wo sie was dürfen.
@asm@s24
Und wie bekommen die Peers die Keys mitgeteilt?
Genau über den Management Server.
Dort könnte eine Man in the Middle Attacke laufen.
Zweitens liegen die ganzen Metadaten ja auch auf dem Netbird Management Server, also wer darf wohin, wer sind die Peers usw.
The hosted version of NetBird means NetBird's company can see metadata about your network — which devices are connected, when, and what their public IPs are. They cannot see your Foundry traffic itself, because WireGuard handles end-to-end encryption between your devices and the private keys never touch their servers. But the metadata visibility is there.
Denke, das theoretische Problem ist ein anderes, WireGuard und die Keys sind es nicht. Aber die Entscheidung, wer mit wem reden darf, muss noch irgendwo anders stattfinden und da spielen halt die Identity Provider mit rein, die aus vertrauenswürdigen Großkonzernen wie MS und Co bestehen.
Für Otto-Normal reicht das natürlich vollkommen aus. Aber die Drei-Buchstaben-Dienste können vermutlich da nach Anordnung rein gucken. Die Metadaten werden eh schon erfasst und auch bei MS und Co fällt da vermutlich einiges an.
@toscdesign Vielleicht wäre ja auch Pangolin was für dich, um einfach noch was auf dich zu schmeißen. 😁
Nutze beides nicht, weil mein Netz teile ich nicht temporär.
They cannot see your Foundry traffic itself, because WireGuard handles end-to-end encryption between your devices and the private keys never touch their servers.
Kennst Du 'ne Firma, die nicht MS365 einsetzt? Ich nicht.
Hast Du ein iPhone ohne Apple-Account oder einen Androiden ohne Google-Account? Echt jetzt, wozu denn dann nicht lieber ein altes Nokia mit nur SMS ...