[AdGuard Home] Ervaringen & discussie

[Videopac]

Pierre schreef op zaterdag 6 juli 2024 @ 11:55:
Ik heb ook AH draaien op een RaspBerry, echter ik krijg het niet voor elkaar om de filmpjes die via NU.nl geserveerd worden af te spelen, hij blockt ze op een of andere manier.

Als ik deze blokkeerlijst uitschakel dan werken die filmpje wel:

https://raw.githubusercon...ists/master/blocklist.txt

Bij inschakelen doen ze het weer niet

Dit heb bij de aangepaste filter regels gezet maar dit doet niet wat ik wil, iemand hier die weet wat ik moet doen.

@@||nu.nl^
@@||cmp.nu.nl^
@@||media.nu.nl^
@@||dpg.pexi.nl^
@@||myprivacy-static.dpgmedia.net^
@@||metrics.nu.nl^
@@||temptation.nu.nl^
@@||graph.nu.nl^

Kijken in de logs. Filter op het ip adres van het apparaat waarop je nu.nl probeert te laden en kijk wat er geblokkeerd wordt.

[Glassertje]

Pierre schreef op zaterdag 6 juli 2024 @ 11:55:
Ik heb ook AH draaien op een RaspBerry, echter ik krijg het niet voor elkaar om de filmpjes die via NU.nl geserveerd worden af te spelen, hij blockt ze op een of andere manier.

Als ik deze blokkeerlijst uitschakel dan werken die filmpje wel:

https://raw.githubusercon...ists/master/blocklist.txt

Bij inschakelen doen ze het weer niet

Dit heb bij de aangepaste filter regels gezet maar dit doet niet wat ik wil, iemand hier die weet wat ik moet doen.

@@||nu.nl^
@@||cmp.nu.nl^
@@||media.nu.nl^
@@||dpg.pexi.nl^
@@||myprivacy-static.dpgmedia.net^
@@||metrics.nu.nl^
@@||temptation.nu.nl^
@@||graph.nu.nl^

Misschien heb je hier wat aan? Er staan een paar domeinen tussen die op je blocklist staan. Lees

[Pierre]

Glassertje schreef op zaterdag 6 juli 2024 @ 21:30:
[...]

Misschien heb je hier wat aan? Er staan een paar domeinen tussen die op je blocklist staan. Lees

Dat was hem inderdaad, deze op de whitelist cdn.jwplayer.com gezet en het werkt, bedankt.

[Glassertje]

Pierre schreef op zaterdag 6 juli 2024 @ 21:57:
[...]

Dat was hem inderdaad, deze op de whitelist cdn.jwplayer.com gezet en het werkt, bedankt.

Mooi dat het gelukt is.

Zie overigs dat ik nog een zin wilde typen, die ik niet heb afgemaakt. 🤣

[Dennisb1]

Ik heb AdGuard nu al maanden geinstalleerd maar na een reboot van de host loop ik er tegen aan dat het toch wel enkele minuten duurt voor AdGuard start.

Met

systemctl start AdGuardHome

start die vervolgens wel "direct" op al blijft dit commando wel een 20-30 seconden hangen.

Wat gaat hier mis? Het gaat hier om een Proxmox CT die uitsluitend voor AdGuard dient.

code:

systemctl status AdGuardHome.service 
* AdGuardHome.service - AdGuard Home: Network-level blocker
     Loaded: loaded (/etc/systemd/system/AdGuardHome.service; enabled; preset: enabled)
     Active: active (running) since Sat 2024-07-13 15:27:26 CEST; 14min ago
   Main PID: 1076 (AdGuardHome)
      Tasks: 8 (limit: 76650)
     Memory: 79.3M
        CPU: 1.584s
     CGroup: /system.slice/AdGuardHome.service
             `-1076 /root/AdGuardHome/AdGuardHome -s run

Jul 13 15:27:26 adguard AdGuardHome[1076]: 2024/07/13 15:27:26.287800 [info] go to http://192.168.2.241:80
Jul 13 15:27:26 adguard AdGuardHome[1076]: 2024/07/13 15:27:26.287803 [info] go to http://[fe80::be24:11ff:fe39:8529%eth0]:80
Jul 13 15:27:26 adguard AdGuardHome[1076]: 2024/07/13 15:27:26.287976 [info] clients: processing addresses
Jul 13 15:27:27 adguard AdGuardHome[1076]: 2024/07/13 15:27:27.543209 [info] dnsproxy: starting dns proxy server
Jul 13 15:27:27 adguard AdGuardHome[1076]: 2024/07/13 15:27:27.543334 [info] dnsproxy: creating udp server socket 0.0.0.0:53
Jul 13 15:27:27 adguard AdGuardHome[1076]: 2024/07/13 15:27:27.543386 [info] dnsproxy: listening to udp://[::]:53
Jul 13 15:27:27 adguard AdGuardHome[1076]: 2024/07/13 15:27:27.543400 [info] dnsproxy: creating tcp server socket 0.0.0.0:53
Jul 13 15:27:27 adguard AdGuardHome[1076]: 2024/07/13 15:27:27.543424 [info] dnsproxy: listening to tcp://[::]:53
Jul 13 15:27:27 adguard AdGuardHome[1076]: 2024/07/13 15:27:27.545084 [info] dnsproxy: entering udp listener loop on [::]:53
Jul 13 15:27:27 adguard AdGuardHome[1076]: 2024/07/13 15:27:27.545128 [info] dnsproxy: entering tcp listener loop on [::]:53

[ Voor 73% gewijzigd door Dennisb1 op 13-07-2024 15:44 ]

[Hmmbob]

Start je hele container traag, of start alleen AdGuard traag?

Je kan vanuit Proxmox in de console meekijken tijdens het booten van de container

[Jazco2nd]

Ik ben nogal verbaasd dat ondanks de lijsten die ik gebruik:

- OISD Big
- AWavenue ads rule (specifiek voor mobiele ads)
- Dandelion Sprout game console
- Dandelion Sprout & Perflyst Smart TV
- uBlock Badware
- Phishing URL block list

Toch de volgende mobile ad netwerken en ad servers niet daarin voorkomen en dus in games op mn telefoon gewoon ads tonen:



Vooral Inmobi schrik ik van dat is namelijk 1 van de eerste mobiele ad netwerken.. bestaat al 11 jaar..
Verder is Vast = een video ad formaat. En Double verify een vrij bekende partij..
Liftoff is ook een grote mobile ad speler.
Enzovoorts..

[ Voor 7% gewijzigd door Jazco2nd op 31-07-2024 00:29 ]

[alex3305]

@Jazco2nd Zou bijna denken dat er iets mis gaat bij je . Bij mij wordt Inmobi geblockt door de standaard AdGuard DNS filter.



In OISD big vind ik inmobi.com niet terug. Maar wel gerelateerde domeinnamen, dus wellicht is daar onlangs iets veranderd?

[gielie]

Vandaag merk ik dat er heel veel ads bij mij doorkomen. Waar voorheen 95% geblokt werd via komen nu de ads van Yahoo, doubleclick, Google ads en vele andere er gewoon doorheen. Ik gebruik bijna alle standaard lijsten die ik in AH kan gebruiken. Meer mensen last van en weet iemand welke lijst ik nog meer moet gebruiken?

[Hmmbob]

Probeer eens "minder" in plaats van "meer" lijsten. Best kans dat er in 1 van die lijsten een verkeerde allow is terecht gekomen.

OISD is een goede start.

[fuzzyduck]

Vraagje. Ik heb nu (heel dommig) 3 proxmox LXC containers draaien met daarin elk een Wireguard, voor elk apparaat dat ik met VPN naar huis wil laten verbinden. Zo zie ik in Aguard welke LXC het is en dus welk apparaat.

voorbeeld in Adguard:
192.168.1.10 mobiel1
192.168.1.11 mobiel2
192.168.1.12 mobiel3

Dit slaat natuurlijk nergens op en wil hier 1 wireguard LXC van maken voor alle apparaten. Hoe kan ik in adguard of in de LXc iets aanpassen zodat er een onderscheid gemaakt wordt?

[TheCeet]

Ik heb ooit eens wat zitten spelen met conainers. En dit is hoe ik het aanpakte:

Container met Dietpi OS.
Daarin installeerde ik "PiVPN".
En dan was het easy peasy.
Gewoon command

code:

pivpn add

en zo kon ik tal van clients aanmaken. In AdGuardHome maakte ik dan de clients manueel aan zodat ik ze duidelijke naam kon geven welk IP welke client is.
Werkte zeer goed bij mij.

[Mirabis]

fuzzyduck schreef op zaterdag 14 september 2024 @ 21:17:
Vraagje. Ik heb nu (heel dommig) 3 proxmox LXC containers draaien met daarin elk een Wireguard, voor elk apparaat dat ik met VPN naar huis wil laten verbinden. Zo zie ik in Aguard welke LXC het is en dus welk apparaat.

voorbeeld in Adguard:
192.168.1.10 mobiel1
192.168.1.11 mobiel2
192.168.1.12 mobiel3

Dit slaat natuurlijk nergens op en wil hier 1 wireguard LXC van maken voor alle apparaten. Hoe kan ik in adguard of in de LXc iets aanpassen zodat er een onderscheid gemaakt wordt?

Je kan een WireGuard server opzetten en de clients zo configureren dat ze elk een ander IP-address krijgen. Vervolgens de IP-adressen als clients koppelen in Adguard Home?

Bovenstaande doe ik rechtstreeks in OPNsense, maar zou ook zonder moeten kunnen.

[fuzzyduck]

Mirabis schreef op zaterdag 14 september 2024 @ 23:06:
[...]


Je kan een WireGuard server opzetten en de clients zo configureren dat ze elk een ander IP-address krijgen. Vervolgens de IP-adressen als clients koppelen in Adguard Home?

Bovenstaande doe ik rechtstreeks in OPNsense, maar zou ook zonder moeten kunnen.

De vpn clients zijn in de range 10.0.0.1/24. Ofwel 10.0.0.2 10.0.0.3 etc. toch gaat al dit dns verkeer uiteindelijk de lxc uit als 182.168.1.50( willekeurig voorbeeld ip) richting Aduard en hiermee kan ik dus niet filteren per vpn apparaat.

[Mirabis]

fuzzyduck schreef op zondag 15 september 2024 @ 00:10:
[...]


De vpn clients zijn in de range 10.0.0.1/24. Ofwel 10.0.0.2 10.0.0.3 etc. toch gaat al dit dns verkeer uiteindelijk de lxc uit als 182.168.1.50( willekeurig voorbeeld ip) richting Aduard en hiermee kan ik dus niet filteren per vpn apparaat.

Ah op die manier. Umm je kan op 1 LXC wireguard meerdere keren draaien op een andere poort of dezelfde poort maar op een ander (virtueele) NIC. En dan voor elk van die clients een eigen NIC , njah...mooi is het niet.

[alex3305]

En als je de Wireguard clients ook IP's geeft in de 192.168.0.0/16 range? Bijvoorbeeld 192.168.25.0/24? Worden ze dan wel herkend door Adguard Home?

Bij mij werkt een dergelijke setup prima via mijn ASUS router.

[fuzzyduck]

alex3305 schreef op zondag 15 september 2024 @ 11:15:
En als je de Wireguard clients ook IP's geeft in de 192.168.0.0/16 range? Bijvoorbeeld 192.168.25.0/24? Worden ze dan wel herkend door Adguard Home?

Bij mij werkt een dergelijke setup prima via mijn ASUS router.

Als ik in wireguard LXC de wireguard server een vrij ip geef uit mn 192.168.1.x netwerk en de peer ook dan krijg ik wel verbinding tx/rx maar geen daadwerkelijk internet.

maar dit wordt meer een wireguard vraagstuk dan adguard geloof ik

[Wachten...]

Heeft iemand hier enig idee waarom ik een hele hoge response tijd heb op mijn Roborock?

Ik heb echt responsetijden van 10000ms. Hij kijkt dan naar xx.xx.pi.xiaomi.com (xx varieert bij alle aanvragen)

[ Voor 90% gewijzigd door Wachten... op 29-09-2024 23:51 ]

[gerritjan]

Wachten... schreef op zondag 29 september 2024 @ 21:23:
Heeft iemand hier enig idee waarom ik een hele hoge response tijd heb op mijn Roborock?
Ik heb echt responsetijden van 10000ms. Hij kijkt dan naar api.xiaomi.com

Terwijl ik probeer te begrijpen wat een stofzuiger met AGH te maken heeft zie ik dat api.xiaomi.com niet bestaat, dus er hoort geen IP-adres bij.
Ik denk dat je wat beter moet uitleggen wat precies je probleem is, maar misschien heb je aan bovenstaande info al genoeg.

[Wachten...]

gerritjan schreef op zondag 29 september 2024 @ 23:42:
[...]

Terwijl ik probeer te begrijpen wat een stofzuiger met AGH te maken heeft zie ik dat api.xiaomi.com niet bestaat, dus er hoort geen IP-adres bij.
Ik denk dat je wat beter moet uitleggen wat precies je probleem is, maar misschien heb je aan bovenstaande info al genoeg.

De roborock vraagt steeds naar iets met dus iets van xx.xx.api.roborock.com echter zijn die response tijden enorm hoog.

Het is dus niet dat de roborock iets met AGH te maken heeft, maar wel de requests die het opvraagt.

[gerritjan]

Wachten... schreef op maandag 30 september 2024 @ 17:25:
[...]
De roborock vraagt steeds naar iets met dus iets van xx.xx.api.roborock.com echter zijn die response tijden enorm hoog.

Het is dus niet dat de roborock iets met AGH te maken heeft, maar wel de requests die het opvraagt.

Je vertelt niet wat je zelf al hebt uitgeprobeerd en uitgezocht. Ook onbekend of de hoge responsetijd een probleem is bij het gebruik van die Roborock.
Bijvoorbeeld: Gebruik je misschien een blocklist die *.api.roborock.com tegenhoudt?

Ik zou eerst proberen of AGH wel het probleem is. Dus in de DHCP-server het ip van AGH vervangen door 8.8.8.8 en kijken of de problemen voorbij zijn.
Als het zonder AGH wel werkt wordt het zoeken in de logs van AGH of andere upstream-servers proberen denk ik.

[Hmmbob]

Hier geen problemen met die API, zowel HA als de stofzuiger kunnen hem snel bereiken.

Ik gebruik de Big OISD lijst, en tls://1.1.1.1:853 en tls://dns.quad9.net als upstream.

[alex3305]

Hier ook geen enkel probleem:

[Glassertje]

Update AdGuard Home v0.107.53

[icecreamfarmer]

Heeft iemand een tailscale funnel icm adguard add on werkend gekregen.
Ik heb tailscale al jaren draaien en wilde gisteren dit proberen maar hij de add on van tailscale sluit elke keer af en in de logs krijg ik niet echt gevonden waarom. Mijn gok is de combi van magic dns met adguard en dat daar iets fout gaat.

Heb dit gevolgd:

https://vigonotion.com/bl...ome-assistant-everywhere/
https://tailscale.com/kb/1223/funnel

Moet ik ergens een upstream dns instellen?

[Wachten...]

Ik heb dus nu wat problemen met mij DMD. De instellingen voor de DMD kreeg ik niet meer naar voren al ik op F1 drukte.

Ik dacht dus, ik stel mijn screenresidentifier even opnieuw in, maar ik krijg dan een foutmelding als ik het op wil slaan.



Heeft iemand enig idee hoe ik dit op kan lossen, want ik kan momenteel niks meer

[Harmen]

Gisteren is helaas mn OPNSense firewall overleden. Heb de UBC1318 modem weer als router in laten stellen.
Kan iemand mij helpen met de interface van de Ubee, vind het niet echt logisch, had bij de dhcp server een dns setting verwacht. Heb het nu ingesteld bij dns overide, maar voor mijn gevoel werkt dat niet helemaal lekker.

Heb Ipv6 uitgezet maar die blijft met dhcp mee komen, kan dit wellicht de oorzaak zijn?

jesco_white schreef op vrijdag 10 november 2023 @ 21:33:
[...]
Ligt er aan welk modem denk ik. Ik heb van Ziggo een UBC1318 modem in gebruik en kan gewoon mijn Adguard Home in mijn thuisnetwerk opgeven als DNS server in het modem.

[jurroen]

Wachten... schreef op vrijdag 25 oktober 2024 @ 21:52:
Ik heb dus nu wat problemen met mij DMD. De instellingen voor de DMD kreeg ik niet meer naar voren al ik op F1 drukte.

Ik dacht dus, ik stel mijn screenresidentifier even opnieuw in, maar ik krijg dan een foutmelding als ik het op wil slaan.

[Afbeelding]

Heeft iemand enig idee hoe ik dit op kan lossen, want ik kan momenteel niks meer

Verkeerde draadje?

Geen idee wat DMD is of wat een screenresidentifier met AGH van doen heeft. Je screenshot toont in ieder geval een permissie fout. Waarschijnlijk mist je gebruiker permissies voor dat tekstbestand.

[ Voor 13% gewijzigd door jurroen op 25-10-2024 23:21 ]

[Wachten...]

jurroen schreef op vrijdag 25 oktober 2024 @ 23:16:
[...]


Verkeerde draadje?

Geen idee wat DMD is of wat een screenresidentifier met AGH van doen heeft. Je screenshot toont in ieder geval een permissie fout. Waarschijnlijk mist je gebruiker permissies voor dat tekstbestand.

Jep, ik had 2 schermen open staan, dus verkeerd draadje

[Harmen]

Heb m'n AdGuard dhpc server gemaakt, ging best soepeltjes. Veel fijnere interface dan de standaard Ziggo modem/router.
Loop nog wel tegen een issue aan dat mn Pixel 8 ads laat zien, onder dns staat er nog steeds een ipv6 dns adres. Iemand een idee hoe je dit kan uitzetten?

[EverLast2002]

Harmen schreef op zaterdag 26 oktober 2024 @ 19:29:
Heb m'n AdGuard dhpc server gemaakt, ging best soepeltjes. Veel fijnere interface dan de standaard Ziggo modem/router.
Loop nog wel tegen een issue aan dat mn Pixel 8 ads laat zien, onder dns staat er nog steeds een ipv6 dns adres. Iemand een idee hoe je dit kan uitzetten?

Pixel is Google, check even of ie niet hardcoded naar 8.8.8.8 DNS zoekt.
IPv6 heb ik geblokkeerd in mijn firewall, gebruik ik niet.

[alex3305]

@Harmen Sommige Android smaakjes, waaronder OnePlus, gebruiken altijd een fallback naar Google DNS. Nou ja, eigenlijk hebben die zelfs een voorkeur voor de internet DNS. Dat komt omdat Android alleen SLAAC en geen DHCPv6 ondersteund. Met SLAAC mag het device zelf (stateless) de configuratie bepalen.Er is een specifieke naam voor het gebruik van deze DNS servers, maar helaas kom ik er even niet op . Je kunt dit omzeilen door de Google DNS servers te blokkeren in de Connectbox. Bij mij werkte dat een beetje houtje-touwtje.

[manusjevanalles]

Ik ben Adguard aan het opzetten. Die draait in een container op Proxmox op 10.0.0.6. Ik probeer ads ook te blokkeren op onze Android telefoons. Maar ik krijg het niet voor elkaar, ik blijf ads zien en ik zie in het Dashboard van Adguard ook niets in de logs.

Ik heb zowel geprobeerd DNS-requests te forceren naar 10.0.0.6:




Alsmede 8.8.8.8 en 8.8.4.4 te blokkeren (niet tegelijk met bovenstaande settings), en dns en tns over tls voor zowel 8.8.8.8 als 8.8.4.4


Maar het lijkt allemaal niets te doen. Wat doe ik fout? Ipv6 staat uit in de router.

[alex3305]

Welke DNS server krijgt je telefoon @manusjevanalles? En wat heb je in de DHCP ingesteld?

Je kunt ook Net Analyzer proberen voor meer informatie en om DNS requests uit te proberen. Ik vind die zelf altijd enorm prettig werken om te troubleshooten.

[manusjevanalles]

alex3305 schreef op dinsdag 29 oktober 2024 @ 20:50:
Welke DNS server krijgt je telefoon @manusjevanalles? En wat heb je in de DHCP ingesteld?

Je kunt ook Net Analyzer proberen voor meer informatie en om DNS requests uit te proberen. Ik vind die zelf altijd enorm prettig werken om te troubleshooten.

De telefoons staan gewoon op DHCP, en ik zie dat 10.0.0.1 de DNS-server is. In pfSense heb ik 10.0.0.6 als DNS-server ingesteld.


Misschien moet ik 10.0.0.6 ook als DNS-server instellen op de telefoons, maar dat zou eigenlijk gewoon via dhcp via de router moeten verlopen.

8.8.8.8 mag nog gewoon naar buiten lijkt, deze zou geblokkeerd moeten worden.


Ook een rule die al het LAN-verkeer naar 8.8.8.8 redirect naar 10.0.0.6 doet niets:


Edit: inmiddels lijkt alles te werken. Ik had nog een instelling in pfSense verkeerd staan, waardoor deze AdGuard niet als DNS gebruikte. Op de telefoons nu direct de DNS-servers ingesteld ipv automatisch via de router, zodat ik in AG per device logs kan zien.
En gek genoeg werken de NAT-rules in de firewall nu wel. Ik heb 8.8.8.8 en 8.8.4.4 doorgelust naar 127.0.0.1, dus de DNS-server van pfSense (= dan weer AG) worden gebruikt. Ik zie dat nu ook in de traceroute van de app Network Analyzer.

[ Voor 56% gewijzigd door manusjevanalles op 30-10-2024 07:58 ]

[gielie]

Ik heb een probleem dat er verkeerde hostnames bij de ip adressen staan, dit zijn oude namen maar die blijft hij toewijzen aan de ip adressen.
Waar slaat ADH deze data op? en zou ik die verkeerde hostnames kunnen wissen dat zodra er een device met dit ip zich weer aanmeld er de juiste hostname verschijnt?

Ik draait ADH in een VM, iemand een tip?


Ik heb nog een vraag.
Ik draai dus AGH (192.168.1.2) in een VM op mijn synology en ik heb verschillende vlans die op mijn unifi draaien.
ik heb 192.168.1.1 *.*.2.1 *.*3.1 en *.*.4.1
De eerste 3 (1.1 2.1 en 3.1) zie ik keurig terug in ADH maar de 4.1 zie ik niet, dit is een guest netwerk met een guest wifi.
Alle devices krijgen keurig 192.168.1.2 als DNS en de ad's worden ook gewoon geblockt.
In mijn log zie ik echter de devices die met 4.1 zijn verbonden niet, deze komen in de log terecht met het ip van de AP (ik heb er 3) en zo kan ik de guest devices niet uit elkaar houden.

Wie weet wat er hier fout gaat en welke instelling moet ik hiervoor aanpassen, in het unifi draadje weet niemand het antwoord.

[ Voor 50% gewijzigd door gielie op 31-10-2024 13:43 ]

[alex3305]

@gielie Bij DNS settings heb je daar ook netjes Private Reverse DNS settings aangegeven? Dat zou dan zoiets moeten zijn:

192.168.1.1
[/168.192.in-addr.arpa/]192.168.1.1

mits uiteraard 192.168.1.1 jouw Unifi is.

Ik weet niet of Unifi nog iets speciaals doet met een guest network, maar ik moest bijvoorbeeld bij mijn VPN Clients op mijn ASUS Router ook PTR records aanmaken om deze met hostname zichtbaar te krijgen in AdGuard Home.

[alex3305]

Het zal vast aan mijn Unbound configuratie liggen, maar ik heb de laatste dagen wat problemen met hostnames die op CDN's zitten. Met name cdn.nos.nl geeft regelmatig een timeout. Ik draai deze Unbound container en heb een klein beetje het gevoel dat het komt omdat in de standaardconfiguratie Unbound ook expired resultaten serveert.

Misschien kan ik nog testen met een andere Unbound container, maar welke dan?

[EverLast2002]

manusjevanalles schreef op dinsdag 29 oktober 2024 @ 20:21:
Ik ben Adguard aan het opzetten. Die draait in een container op Proxmox op 10.0.0.6. Ik probeer ads ook te blokkeren op onze Android telefoons. Maar ik krijg het niet voor elkaar, ik blijf ads zien en ik zie in het Dashboard van Adguard ook niets in de logs.

Ik heb zowel geprobeerd DNS-requests te forceren naar 10.0.0.6:
[Afbeelding]

[Afbeelding]

Alsmede 8.8.8.8 en 8.8.4.4 te blokkeren (niet tegelijk met bovenstaande settings), en dns en tns over tls voor zowel 8.8.8.8 als 8.8.4.4
[Afbeelding]

Maar het lijkt allemaal niets te doen. Wat doe ik fout? Ipv6 staat uit in de router.

In plaats van keihard te blocken gebruik ik een redirect rule.
Clients die 8.8.8.8 (hardcoded) gebruiken krijgen dan geen "connection time-out of een webpage unavailable, maar ze worden doodleuk naar mijn interne DNS server doorgesluisd.
Daar gebruik ik de "!" optie voor in OPNsense Rules.

[manusjevanalles]

EverLast2002 schreef op donderdag 31 oktober 2024 @ 21:12:
[...]


In plaats van keihard te blocken gebruik ik een redirect rule.
Clients die 8.8.8.8 (hardcoded) gebruiken krijgen dan geen "connection time-out of een webpage unavailable, maar ze worden doodleuk naar mijn interne DNS server doorgesluisd.
Daar gebruik ik de "!" optie voor in OPNsense Rules.

Zo doe ik het nu ook, ik redirect ze ook door. Wat bedoel je met het uitroepteken? Kan je wellicht eens screenshot delen van je rules?

[ThinkPad]

! is ‘NOT’. Ik vermoed dat de regel van @EverLast2002 alles wat niet de AGH DNS als destination heeft, ombuigt naar AGH.

Je kan AGH trouwens ook op je pfSense draaien als plug-in. Dat heb ik met OPNsense ook en werkt erg stabiel. Zonder AGH heeft je telefoon geen DNS en dus geen internet meer. Even je Proxmox server herstarten o.i.d. is niet zo goed voor je relatie Tenzij je pfSense ook virtueel hebt draaien natuurlijk, dan win je er niet echt wat mee. OPNsense is bij mij een fysieke machine (bewust, vroeger router wel als VM gedraaid maar ik wil onderhoud aan server kunnen doen zonder uitval internet).

[ Voor 29% gewijzigd door ThinkPad op 01-11-2024 07:32 ]

[alex3305]

@ThinkPad Ik heb (toevallig) twee fysieke nodes naast mijn router draaien. Een waar heel mijn homelab op draait en een ander die wat kleine zaken afhandelt. Op die tweede node heb ik een kopie van mijn primaire Adguard Home draaien die ik bijgewerkt houdt met adguardhome-sync. Die tweede instantie heb ik als secundaire DNS toegevoegd en zolang een van beide nodes dus online blijft, blijft 'het internet' ook werken.

Ik manage dit via Docker Compose:

YAML:

---
services:
  adguardhome:
    container_name: ${COMPOSE_PROJECT_NAME}
    image: adguard/adguardhome:${ADGUARD_HOME_VERSION:-latest}
    restart: on-failure
    depends_on:
      - unbound
    networks:
      private:
    ports:
      - 53:53/tcp
      - 53:53/udp
    volumes:
      - adguard-data:/opt/adguardhome
    cpus: 1
    labels:
      "com.centurylinklabs.watchtower.scope": "${COMPOSE_PROJECT_NAME}"

  adguardhome-sync:
    container_name: ${COMPOSE_PROJECT_NAME}-sync
    image: ghcr.io/bakito/adguardhome-sync:${ADGUARD_HOME_SYNC_VERSION:-latest}
    restart: on-failure
    command: run
    depends_on:
      - adguardhome
    networks:
      private:
    environment:
      CRON: "*/30 * * * *"
      ORIGIN_URL: ${SYNC_ORIGIN_URL}
      REPLICA_URL: http://adguardhome:3000
      REPLICA_AUTO_SETUP: true
      REPLICA_USERNAME: ${SYNC_REPLICA_USERNAME}
      REPLICA_PASSWORD: ${SYNC_REPLICA_PASSWORD}
      RUN_ON_START: true
    cpus: 0.5
    labels:
      "com.centurylinklabs.watchtower.scope": "${COMPOSE_PROJECT_NAME}"

  unbound:
    container_name: ${COMPOSE_PROJECT_NAME}-unbound
    image: klutchell/unbound:${UNBOUND_VERSION:-latest}
    restart: on-failure
    networks:
      private:
        ipv4_address: 10.100.100.20
    healthcheck:
      disable: true
    cpus: 1
    labels:
      "com.centurylinklabs.watchtower.scope": "${COMPOSE_PROJECT_NAME}"

  watchtower:
    container_name: ${COMPOSE_PROJECT_NAME}-watchtower
    image: containrrr/watchtower
    environment:
      TZ: ${TZ:-Europe/Amsterdam}
      WATCHTOWER_CLEANUP: true
      WATCHTOWER_LOG_LEVEL: error
      WATCHTOWER_SCHEDULE: "0 0 5 * * *"
      WATCHTOWER_SCOPE: ${COMPOSE_PROJECT_NAME}
    network_mode: bridge
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    cpus: 0.1
    labels:
      "com.centurylinklabs.watchtower.scope": "${COMPOSE_PROJECT_NAME}"

volumes:
  adguard-data:
    name: adguard-data

networks:
  private:
    name: ${COMPOSE_PROJECT_NAME}
    ipam:
      driver: default
      config:
        - subnet: 10.100.100.0/24

Resolven vindt plaats via een lokale Unbound container. Ik wil dit eigenlijk nog over meerdere nodes heen hebben met zoiets als Swarm, maar hier ben ik nog niet aan toegekomen. Updates gaan automatisch via Watchtower waarbij mijn primaire node een ander updateschema heeft.

Met deze setup heb ik eigenlijk geen omkijken naar de secundaire node. Het verkeer is ook niet bijzonder. Ongeveer 10% van alle DNS requests gaan naar de secundaire instantie. Dus dat die node underpowered is doet er ook niet zo toe. Met Unbound heb ik nog steeds een average response time van 6ms.

[manusjevanalles]

ThinkPad schreef op vrijdag 1 november 2024 @ 07:27:
! is ‘NOT’. Ik vermoed dat de regel van @EverLast2002 alles wat niet de AGH DNS als destination heeft, ombuigt naar AGH.

Je kan AGH trouwens ook op je pfSense draaien als plug-in. Dat heb ik met OPNsense ook en werkt erg stabiel. Zonder AGH heeft je telefoon geen DNS en dus geen internet meer. Even je Proxmox server herstarten o.i.d. is niet zo goed voor je relatie Tenzij je pfSense ook virtueel hebt draaien natuurlijk, dan win je er niet echt wat mee. OPNsense is bij mij een fysieke machine (bewust, vroeger router wel als VM gedraaid maar ik wil onderhoud aan server kunnen doen zonder uitval internet).

Dat vermoedde ik al. Ik draai nu nog pfsense in een VM, maar ben een nieuwe server aan het inrichten. Ik ben er nog niet over uit wat ik doe met de router. Ik zou naar OPNSense willen, maar zodra ik die VM opstart, geeft dat 4W extra verbruik. Mogelijk dat ik toch over ga naar de Asusrouter die Merlin draait (doet nu alleen dienst als AP).
Maar ik vind het idee om AGH primair op pf/OPNSense te draaien en een backup in een container wel een goed idee. Maar alles zal op dezelfde server blijven draaien, dus bij een herstart is het internet even weg.

[manusjevanalles]

alex3305 schreef op vrijdag 1 november 2024 @ 11:06:
@ThinkPad Ik heb (toevallig) twee fysieke nodes naast mijn router draaien. Een waar heel mijn homelab op draait en een ander die wat kleine zaken afhandelt. Op die tweede node heb ik een kopie van mijn primaire Adguard Home draaien die ik bijgewerkt houdt met adguardhome-sync. Die tweede instantie heb ik als secundaire DNS toegevoegd en zolang een van beide nodes dus online blijft, blijft 'het internet' ook werken.

Ik manage dit via Docker Compose:

YAML:

---
services:
  adguardhome:
    container_name: ${COMPOSE_PROJECT_NAME}
    image: adguard/adguardhome:${ADGUARD_HOME_VERSION:-latest}
    restart: on-failure
    depends_on:
      - unbound
    networks:
      private:
    ports:
      - 53:53/tcp
      - 53:53/udp
    volumes:
      - adguard-data:/opt/adguardhome
    cpus: 1
    labels:
      "com.centurylinklabs.watchtower.scope": "${COMPOSE_PROJECT_NAME}"

  adguardhome-sync:
    container_name: ${COMPOSE_PROJECT_NAME}-sync
    image: ghcr.io/bakito/adguardhome-sync:${ADGUARD_HOME_SYNC_VERSION:-latest}
    restart: on-failure
    command: run
    depends_on:
      - adguardhome
    networks:
      private:
    environment:
      CRON: "*/30 * * * *"
      ORIGIN_URL: ${SYNC_ORIGIN_URL}
      REPLICA_URL: http://adguardhome:3000
      REPLICA_AUTO_SETUP: true
      REPLICA_USERNAME: ${SYNC_REPLICA_USERNAME}
      REPLICA_PASSWORD: ${SYNC_REPLICA_PASSWORD}
      RUN_ON_START: true
    cpus: 0.5
    labels:
      "com.centurylinklabs.watchtower.scope": "${COMPOSE_PROJECT_NAME}"

  unbound:
    container_name: ${COMPOSE_PROJECT_NAME}-unbound
    image: klutchell/unbound:${UNBOUND_VERSION:-latest}
    restart: on-failure
    networks:
      private:
        ipv4_address: 10.100.100.20
    healthcheck:
      disable: true
    cpus: 1
    labels:
      "com.centurylinklabs.watchtower.scope": "${COMPOSE_PROJECT_NAME}"

  watchtower:
    container_name: ${COMPOSE_PROJECT_NAME}-watchtower
    image: containrrr/watchtower
    environment:
      TZ: ${TZ:-Europe/Amsterdam}
      WATCHTOWER_CLEANUP: true
      WATCHTOWER_LOG_LEVEL: error
      WATCHTOWER_SCHEDULE: "0 0 5 * * *"
      WATCHTOWER_SCOPE: ${COMPOSE_PROJECT_NAME}
    network_mode: bridge
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    cpus: 0.1
    labels:
      "com.centurylinklabs.watchtower.scope": "${COMPOSE_PROJECT_NAME}"

volumes:
  adguard-data:
    name: adguard-data

networks:
  private:
    name: ${COMPOSE_PROJECT_NAME}
    ipam:
      driver: default
      config:
        - subnet: 10.100.100.0/24

Resolven vindt plaats via een lokale Unbound container. Ik wil dit eigenlijk nog over meerdere nodes heen hebben met zoiets als Swarm, maar hier ben ik nog niet aan toegekomen. Updates gaan automatisch via Watchtower waarbij mijn primaire node een ander updateschema heeft.

Met deze setup heb ik eigenlijk geen omkijken naar de secundaire node. Het verkeer is ook niet bijzonder. Ongeveer 10% van alle DNS requests gaan naar de secundaire instantie. Dus dat die node underpowered is doet er ook niet zo toe. Met Unbound heb ik nog steeds een average response time van 6ms.

Dank voor het delen van je docker compose! Wat is het voordeel van Unbound boven de dns resolver van de router?

[Villager]

manusjevanalles schreef op vrijdag 1 november 2024 @ 21:52:
[...]


Dank voor het delen van je docker compose! Wat is het voordeel van Unbound boven de dns resolver van de router?

Mooi gedaan!
Ik doe ongeveer hetzelfde, maar dan met Technitium als DNS en Adblocker. Heb 2 instanties draaien in een Proxmox container en deze syncen met elkaar op deze manier. Ik gebruik geen Adguard en Unbound meer, dus eigenlijk hoort het niet thuis in dit forum :-)

[lolgast]

Ik gebruik gewoon de API om mijn Adguard instances in sync te houden. Dat doe ik via NodeRED. Wijzigingen doe ik altijd op dezelfde en binnen een minuut is dat verwerkt in de 2e instance. Ik heb ze jaren lang beide om dezelfde Proxmox host gehad maar omdat ik sinds kort toch een 2e heb draaien is het nu gescheiden.

Ik gebruik mijn DNS servers ook remote, via DoH. Nadeel is dat ik nu 2 keer heb gehad dat ik thuis een internetstoring had waardoor ik onderweg ineens geen internet meer leek te hebben. Dat wil ik eigenlijk nog ergens in Cloudflare proberen af te vangen, maar heb nog geen idee of/hoe dat mogelijk is

[alex3305]

manusjevanalles schreef op vrijdag 1 november 2024 @ 21:52:
Dank voor het delen van je docker compose!

Geen probleem. Op de andere node draait een zeer vergelijkbare setup, maar dan uiteraard zonder de sync container en Watchtower met een ander update schema.

Wat is het voordeel van Unbound boven de dns resolver van de router?

Dat is hier en in het Pi-Hole topic al veel besproken en hier staat het heel uitgebreid, maar kort door de bocht gaat Unbound zelf DNS requests doen in plaats van via jouw provider of Google of Cloudflare. Het nadeel is dat je veel hogere latency hebt, maar dat kan opwegen tegen veel betere privacy. Immers heb je niets meer te maken met een tussenpartij.

Overigens heb ik inmiddels mijn provider (KPN) wederom toegevoegd aan AGH omdat de door mij gebruikte Unbound container blijkbaar problemen geeft. Gisteren liep ik wederom tegen het probleem aan wat ik afgelopen week ook opmerkte. Bepaalde hosts geven dan een SERVFAIL. Ik had de logging van Unbound al verhoogd om te testen, maar eigenlijk heb ik ook gewoon geen zin om uit te zoeken waar het precies misgaat. Wellicht dat ik de komende dagen een downgrade van de Unbound container doe om te kijken of het daar aan ligt.

[alex3305]

lolgast schreef op zaterdag 2 november 2024 @ 08:25:
Ik gebruik mijn DNS servers ook remote, via DoH. Nadeel is dat ik nu 2 keer heb gehad dat ik thuis een internetstoring had waardoor ik onderweg ineens geen internet meer leek te hebben. Dat wil ik eigenlijk nog ergens in Cloudflare proberen af te vangen, maar heb nog geen idee of/hoe dat mogelijk is

Ik heb een hele tijd DoT gedraaid. Waarbij ik het certificaat van NGINX Proxy Manager gebruikte voor AGH, dat werkte verrassend goed. Ik heb daarvoor in Cloudlfare een specifiek wildcard subdomain zitten die niet geproxied wordt door Cloudflare als CNAME. Bijvoorbeeld *.private.example.com. Ik gebruikte dan de identifier onder de Client Settings in AGH om toegang te verlenen:


Dus in dit geval werd alleen verkeer toegelaten wat van: alex.private.example.com of kwam. Mijn router zorgde er dan voor dat alleen verkeer op 443 vanuit Cloudflare of in dit geval 853 toegestaan werd. En dat laatste werd dan gerouteerd via NGINX Proxy Manager naar AdGuard Home.

Maar zoals ik al zei, ik heb dat een hele tijd gedraaid. Inmiddels niet meer omdat ik tegen dezelfde beperking als jou aan liep. Als er ergens een hikje in de verbinding was. Of dat nou mijn thuisverbinding was of mijn mobiele verbinding dan ging mijn Android telefoon zeuren dat ik geen internet meer had. Dat vond ik bijzonder irritant.

Inmiddels ben ik naar de open-source WG Tunnel client overgestapt die naadloos een Wireguard tunnel naar mijn router opzet wanneer ik naar mobiele data wissel. Ik gebruik daar nog wel steeds de niet geproxydet URL voor, bijvoorbeeld: vpn.private.example.com zodat ik niet afhankelijk ben van mijn IP adres. Die veranderd overigens mee door middel van ddclient, maar dat is hier helemaal off topic .

[Glassertje]

Ik heb hier thuis 2 Pi's met AGH. Beide hebben een domein geregistreerd en deze moet ik binnenkort verlengen. Nu je ook in AGH een backup DNS kunt instellen, zou ik daar het lokale ip van mijn 2e Pi in kunnen zetten, dan heb ik maar 1 domein nodig. Maar aan de andere kant, als mijn 1e Pi niet meer reageert, werkt mijn internet op mijn telefoon niet meer. Ik vroeg me af hoe andere dit opgelost hebben?

Ik gebruik nu beide domeinen in de AdGuard Android app met DoH en dit werkt ook wel goed.

[sjongenelen]

Ik gebruik duckdns. Werkt gratis en ook met lets encrypt

[Glassertje]

sjongenelen schreef op zondag 3 november 2024 @ 12:37:
Ik gebruik duckdns. Werkt gratis en ook met lets encrypt

Owja, dat ik die vergeten ben zeg. Dankje voor de tip. 😁

[alex3305]

Glassertje schreef op zondag 3 november 2024 @ 12:16:
Ik heb hier thuis 2 Pi's met AGH. Beide hebben een domein geregistreerd en deze moet ik binnenkort verlengen. Nu je ook in AGH een backup DNS kunt instellen, zou ik daar het lokale ip van mijn 2e Pi in kunnen zetten, dan heb ik maar 1 domein nodig. Maar aan de andere kant, als mijn 1e Pi niet meer reageert, werkt mijn internet op mijn telefoon niet meer. Ik vroeg me af hoe andere dit opgelost hebben?

Ik gebruik nu beide domeinen in de AdGuard Android app met DoH en dit werkt ook wel goed.

Waarom heb je twee domeinen ? Waarom gebruik je niet één domein met een reverse proxy? En dan kun je ook nog kiezen voor bijvoorbeeld een subdomein. Daarnaast is/kan DuckDNS veel minder betrouwbaar zijn dan bijvoorbeeld Cloudflare DNS. Zie ook deze Reddit post van circa twee weken geleden.

Als je een DNS server op je router kunt draaien of aanpassen zou je zelfs een dubbel A-record in kunnen stellen zodat er automatische fallover is wanneer een van je Pi's down gaat.

[EverLast2002]

manusjevanalles schreef op vrijdag 1 november 2024 @ 07:11:
[...]


Zo doe ik het nu ook, ik redirect ze ook door. Wat bedoel je met het uitroepteken? Kan je wellicht eens screenshot delen van je rules?

Hier is mijn Port Forward redirect rule om alles via Unbound te laten lopen:

interface = LAN, TCP/UDP, source = ! Unbound, destination = ! Unbound, port 53, NAT = Unbound, port 53

(Unbound is bij mij een alias, ik heb hier 2 items in staan).

[Glassertje]

alex3305 schreef op zondag 3 november 2024 @ 20:59:
[...]

Waarom heb je twee domeinen ? Waarom gebruik je niet één domein met een reverse proxy? En dan kun je ook nog kiezen voor bijvoorbeeld een subdomein. Daarnaast is/kan DuckDNS veel minder betrouwbaar zijn dan bijvoorbeeld Cloudflare DNS. Zie ook deze Reddit post van circa twee weken geleden.

Als je een DNS server op je router kunt draaien of aanpassen zou je zelfs een dubbel A-record in kunnen stellen zodat er automatische fallover is wanneer een van je Pi's down gaat.

Ik heb toen 2 domeinen genomen, omdat ik op dat moment weinig tijd had, om uit te zoeken hoe het allemaal precies werkt, want heb geen flauw idee. Maar ik ga er zeker naar kijken, om het anders te doen. Bedankt voor je reactie.

Ik heb wel een Asus router, maar vind het zonde om mijn Pi's niet te gebruiken. Als ze ooit overleden zijn, dan ga ik het wel op mijn Asus zetten.

Zelfde als het probleem dat ik vast blijf hangen aan de Adguard Android app, terwijl als ik private dns zou gebruiken, het laden van web pagina's veel sneller gaat. Maar dat heb je als je moeite met verandering hebt. Maar is work in progress. 😁

[alex3305]

Glassertje schreef op maandag 4 november 2024 @ 09:37:
[...]

Ik heb toen 2 domeinen genomen, omdat ik op dat moment weinig tijd had, om uit te zoeken hoe het allemaal precies werkt, want heb geen flauw idee. Maar ik ga er zeker naar kijken, om het anders te doen. Bedankt voor je reactie.

Maar de domeinen gaan via een A-record toch naar hetzelfde outbound IP-adres? Daar heb je dan toch een SPoF. En het maakt dan niet uit of het dns1.example.com en dns2.example.com is of dns.example1.com en dns.example2.com. Dat is uiteindelijk toch alleen maar een naam met verwijzing.

Ik heb wel een Asus router, maar vind het zonde om mijn Pi's niet te gebruiken. Als ze ooit overleden zijn, dan ga ik het wel op mijn Asus zetten.

Nee nee. Je snapt niet helemaal wat ik bedoel . Ik bedoel niet om AdGuard Home (of iets anders) op de ASUS router te zetten. Dat heb ik op mijn ASUS AX86S geprobeerd en was een drama. Ook met extra swap ruimte.

Ik heb ook twee AdGuard Home instanties draaien en die configureer ik op mijn ASUS router in de DHCP:


Intern gebruik ik dus AGH en wanneer mijn primaire node omvalt dan gebruiken alle andere systemen in mijn netwerk automatisch de secundaire server. So far, so good.

Naast DNS heb ik ook diensten draaien die via HTTPS bereikbaar zijn. Daarvoor gebruik ik dus een reverse proxy. In mijn geval Caddy met automatische discovery. Daar heb ik in het Docker topic ook al het een en ander over geschreven. De reverse proxy zorgt er dan voor dat op basis van de Host name die binnenkomt er wordt gerouteerd naar de juiste achterliggende dienst. In mijn geval routeert bijvoorbeeld dns.example.com naar mijn primaire AdGuard Home en dns2.example.com naar mijn secundaire instantie. Tevens gebruik ik mijn reverse proxy voor HTTPS termination, authenticatie en autorisatie.

Maar wat je zou kunnen doen, en dat moet ik zelf eigenlijk ook nog bouwen , is dat je dnsmasq op de ASUS router gebruikt met een dubbel A-record om automatische fallover te hebben. Dus je kunt een reverse proxy dan op Pi A en Pi B draaien, en bij problemen bij Pi A wordt automatisch teruggegrepen naar Pi B. Als je Merlin hebt geïnstalleerd op de router en JFFS aan hebt staan kun je namelijk extra dnsmasq configuratie toevoegen in /jffs/configs/dnsmasq.conf.add. Bijvoorbeeld:

code:

address=/example.com/192.168.1.254
address=/example.com/192.168.1.4

En met dig krijg je dan:

❯ dig +short example.com @192.168.1.1
192.168.1.4
192.168.1.254

Mocht je dan de ASUS router niet als upstream gebruiken, dan kun je dit ook uitzonderen voor jouw eigen domein:

code:

[//]192.168.1.1
[/lan/]192.168.1.1
[/internal/]192.168.1.1
[/example.com/]192.168.1.1

Waarbij die onderste regel dus de ASUS router gebruikt als DNS upstream.

Het geinige van deze opzet bij mij is dat er buiten de deur Cloudflare wordt gebruikt. Daar zit dan een WAF op en block ik het e.e.a. door middel van regels. Bijvoorbeeld op regio. Ook heb ik hiermee (D)DoS bescherming en doe ik ook nog een stukje (dubbele) authenticatie. Maar intern, en via VPN, gaat dus alles lokaal. Dat is een stuk sneller dan alles via een cloud provider te laten lopen.

Wellicht wat complex en off-topic hier, maar ik vind het ook wel leuk om wat inzicht te geven hoe ik o.a. AdGuard Home gebruik.

Zelfde als het probleem dat ik vast blijf hangen aan de Adguard Android app, terwijl als ik private dns zou gebruiken, het laden van web pagina's veel sneller gaat. Maar dat heb je als je moeite met verandering hebt. Maar is work in progress. 😁

Private DNS in Android vond ik niet lekker werken. Ik ben overgegaan naar Wireguard met de open source wgtunnel client. Deze schakelt bij mij automatisch en zowat naadloos over naar Wireguard wanneer ik van de thuis wifi af ben. Dit was super eenvoudig in de ASUS router op te zetten vanwege de native ondersteuning. Alleen moest ik dan de DNS server naar AdGuard Home handmatig aanpassen na het inladen van de configuratie op de client.

[Glassertje]

alex3305 schreef op maandag 4 november 2024 @ 12:33:
[...]

Maar de domeinen gaan via een A-record toch naar hetzelfde outbound IP-adres? Daar heb je dan toch een SPoF. En het maakt dan niet uit of het dns1.example.com en dns2.example.com is of dns.example1.com en dns.example2.com. Dat is uiteindelijk toch alleen maar een naam met verwijzing.


[...]

Nee nee. Je snapt niet helemaal wat ik bedoel . Ik bedoel niet om AdGuard Home (of iets anders) op de ASUS router te zetten. Dat heb ik op mijn ASUS AX86S geprobeerd en was een drama. Ook met extra swap ruimte.

Ik heb ook twee AdGuard Home instanties draaien en die configureer ik op mijn ASUS router in de DHCP:
[Afbeelding]

Intern gebruik ik dus AGH en wanneer mijn primaire node omvalt dan gebruiken alle andere systemen in mijn netwerk automatisch de secundaire server. So far, so good.

Naast DNS heb ik ook diensten draaien die via HTTPS bereikbaar zijn. Daarvoor gebruik ik dus een reverse proxy. In mijn geval Caddy met automatische discovery. Daar heb ik in het Docker topic ook al het een en ander over geschreven. De reverse proxy zorgt er dan voor dat op basis van de Host name die binnenkomt er wordt gerouteerd naar de juiste achterliggende dienst. In mijn geval routeert bijvoorbeeld dns.example.com naar mijn primaire AdGuard Home en dns2.example.com naar mijn secundaire instantie. Tevens gebruik ik mijn reverse proxy voor HTTPS termination, authenticatie en autorisatie.

Maar wat je zou kunnen doen, en dat moet ik zelf eigenlijk ook nog bouwen , is dat je dnsmasq op de ASUS router gebruikt met een dubbel A-record om automatische fallover te hebben. Dus je kunt een reverse proxy dan op Pi A en Pi B draaien, en bij problemen bij Pi A wordt automatisch teruggegrepen naar Pi B. Als je Merlin hebt geïnstalleerd op de router en JFFS aan hebt staan kun je namelijk extra dnsmasq configuratie toevoegen in /jffs/configs/dnsmasq.conf.add. Bijvoorbeeld:

code:

address=/example.com/192.168.1.254
address=/example.com/192.168.1.4

En met dig krijg je dan:

❯ dig +short example.com @192.168.1.1
192.168.1.4
192.168.1.254

Mocht je dan de ASUS router niet als upstream gebruiken, dan kun je dit ook uitzonderen voor jouw eigen domein:

code:

[//]192.168.1.1
[/lan/]192.168.1.1
[/internal/]192.168.1.1
[/example.com/]192.168.1.1

Waarbij die onderste regel dus de ASUS router gebruikt als DNS upstream.

Het geinige van deze opzet bij mij is dat er buiten de deur Cloudflare wordt gebruikt. Daar zit dan een WAF op en block ik het e.e.a. door middel van regels. Bijvoorbeeld op regio. Ook heb ik hiermee (D)DoS bescherming en doe ik ook nog een stukje (dubbele) authenticatie. Maar intern, en via VPN, gaat dus alles lokaal. Dat is een stuk sneller dan alles via een cloud provider te laten lopen.

Wellicht wat complex en off-topic hier, maar ik vind het ook wel leuk om wat inzicht te geven hoe ik o.a. AdGuard Home gebruik.


[...]

Private DNS in Android vond ik niet lekker werken. Ik ben overgegaan naar Wireguard met de open source wgtunnel client. Deze schakelt bij mij automatisch en zowat naadloos over naar Wireguard wanneer ik van de thuis wifi af ben. Dit was super eenvoudig in de ASUS router op te zetten vanwege de native ondersteuning. Alleen moest ik dan de DNS server naar AdGuard Home handmatig aanpassen na het inladen van de configuratie op de client.

Bedankt voor je uitgebreide post. Ik heb gisteren unbound verwijderd, omdat ik al een tijdje allemaal vage foutmeldingen kreeg op 1 van mijn newsservers. Ik heb unbound vervangen voor Cloudflare en Quad9 en de meldingen zijn weg. Dus laat het maar zo.

Ik denk dat ik maar gewoon weer naar dat ik AGH binnenshuis gebruik en op mijn Android gebruik ik de AdGuard app wel. Heeft jaren goed gewerkt en nu ik geen unbound meer gebruik, zie ik ook de meerwaarde er niet van om AGH op mijn Android te gebruiken.

Maar ik blijf wel aandachtig meelezen.

[alex3305]

Ik liep net nog wel tegen een zeer onverwacht probleem aan met mijn setup. Ik verwees altijd naar mijn reverse proxy via een custom filtering rule:

code:

||example.com^$dnsrewrite=192.168.1.5,client=192.168.0.0/16

maar ik wilde dat beheer dus nu verleggen naar mijn router met:

code:

[//]192.168.1.1
[/lan/]192.168.1.1
[/internal/]192.168.1.1
[/example.com/]192.168.1.1

en dan de verwijzing op mijn router vastleggen in dnsmasq:

code:

address=/example.com/192.168.1.5

Maar het blijkt dat Cloudflare sinds een paar jaar HTTPS records aanmaakt volgens RFC 9460. Helemaal maar dan werken mijn sites dus niet meer in Chromium-browsers . Want die prefereren de HTTPS header boven A en daar staat het IP adres van Cloudflare in:

❯ dig echo.example.com @1.1.1.1 HTTPS

;; ANSWER SECTION:
echo.example.com.            300     IN      HTTPS   1 . alpn="h3,h2" ipv4hint=188.114.96.0,188.114.97.0 ipv6hint=2a06:98c1:3120::,2a06:98c1:3121::

Nu kan ik die overschrijven in dnsmasq met een dns-rr regel. Dus die heb ik gegenereerd aan de hand van dit Python script:

code:

dns-rr=example.com,65,0001000001000602683302683200040004C0A80105

Alleen werkt dat blijkbaar alleen voor dat specifieke domein en niet voor subdomeinen . Voorlopig dus nog maar even terug naar de custom filtering rule.

[Hmmbob]

download: AdGuard Home 0.107.54

[alex3305]

Over mijn bovenstaande probleem omtrent het HTTPS DNS record heb ik dat toch via Adguard Home (gedeeltelijk) op kunnen lossen. Ik had dit wellicht liever via dnsmasq gedaan, maar soms moet je roeien met de riemen die je hebt.

In de DNS upstreams heb ik mijn domein toegevoegd met als verwijzing naar mijn router waar ik in dnsmasq een verwijzing heb staan naar de reverse proxy. Waarom op deze manier? Onder andere omdat Unraid dan niet afhankelijk is van de eigen gehostte AdGuard Home om online te komen. Daar heb ik dus mijn router als DNS server ingesteld. Echter wil ik wel graag dat verkeer wat naar mijn homelab toe moet, lokaal blijft en niet via Cloudflare gerouteerd wordt. Daar heb ik tevens nog een aanvullende authenticatielaag ingesteld, die ik binnenshuis niet nodig heb. Dus in de dnsmasq configuratie staat het volgende:

code:

# Static routes for servers
address=/example.com/192.168.1.5

En in Adguard Home dus:

code:

[/example.com/]192.168.1.1

onder upstreams. Dat werkt dan prima, behalve dus voor HTTPS DNS records die Cloudflare sinds een aantal jaar toevoegt:

❯ dig +short example.com @192.168.1.1 A
192.168.1.5
❯ dig +short example.com @192.168.1.1 HTTPS
1 . alpn="h3,h2" ipv4hint=104.21.84.56,172.67.187.25 ech=AEX+DQBBfgAgACBWSgoC+LfGL5dCtxVW4zWpfAVWq8Gz5/Sd7GU+bO3RPAAEAAEAAQASY2xvdWRmbGFyZS1lY2guY29tAAA= ipv6hint=2606:4700:3032::ac43:bb19,2606:4700:3036::6815:5438

Omdat o.a. Chromeium browsers HTTPS records prefereren boven A records zorgt dit er voor dat de website onbereikbaar is. Echter in de documentatie omtrent custom filtering rules wordt het HTTPS record ook expliciet genoemd. Dit had ik even gemist. Het is dus mogelijk om deze records te overschrijven. Bijvoorbeeld:

code:

||example.com^$dnstype=HTTPS

Waarbij HTTPS records voor example.com (en subdomeinen) geblokkeerd wordt:

code:

❯ dig +short example.com @192.168.1.4 A
192.168.1.5
❯ dig +short example.com @192.168.1.4 HTTPS

Maar het is dus ook mogelijk om dit specifieke type te overschrijven:

code:

||example.com^$dnstype=HTTPS,dnsrewrite=NOERROR;HTTPS;1 . alpn=h3 ipv4hint=192.168.1.5

Waarbij er momenteel helaas wel een beperking zit op de parameters en waardes in de value list. Een voorbeeld volgens de documentatie:

code:

ipv4hint=127.0.0.1             // Supported.
ipv4hint="127.0.0.1"           // Unsupported.
ipv4hint=127.0.0.1,127.0.0.2   // Unsupported.
ipv4hint="127.0.0.1,127.0.0.2" // Unsupported.

Wat ik wel jammer vind, want ik had graag de hint voor ondersteunde http2 gegeven en mijn andere node toegevoegd zodat ik een fallover zou hebben via de ipv4hint parameter. Als je dat toch probeert te configureren wordt de waarde van de upstream teruggegeven.

Echter krijg ik nu wel netjes van Adguard Home mijn HTTPS record terug:

❯ dig +short example.com @192.168.1.4 HTTPS
1 . alpn="h3" ipv4hint=192.168.1.5

En applicaties werken nu netjes met HTTP3 (met nog een klein beetje HTTP2). Bijvoorbeeld Home Assistant:


En als ik de regel weghaal en HTTPS records blokkeer zien we dus alleen maar HTTP2 terugkomen:


Het lijkt allemaal iets snappier aan te voelen. Maar wellicht is dat meer subjectief. Ik heb geen performance tests gedaan. Maar ik ben wel blij met dit voorlopige resultaat .

[alex3305]

alex3305 schreef op donderdag 31 oktober 2024 @ 15:18:
Het zal vast aan mijn Unbound configuratie liggen, maar ik heb de laatste dagen wat problemen met hostnames die op CDN's zitten. Met name cdn.nos.nl geeft regelmatig een timeout. Ik draai deze Unbound container en heb een klein beetje het gevoel dat het komt omdat in de standaardconfiguratie Unbound ook expired resultaten serveert.

Misschien kan ik nog testen met een andere Unbound container, maar welke dan?

Toch nog even mezelf quoten. Inmiddels heb ik Technitium DNS Server in gebruik genomen als vervanging van Unbound als recursive DNS. Met webinterface wellicht ook wat makkelijker beheerbaar dan Unbound. Althans het geeft wellicht wat meer inzicht in hoe het e.e.a. werkt. Het zou zelfs als vervanging van Adguard Home kunnen werken aangezien het een vergelijkbare feature set heeft.

In ieder geval lijken de door mij genoemde problemen vooralsnog hiermee opgelost.

[gerritjan]

Interessant verschijnsel. Sinds een paar weken krijg ik allemaal DoT-requests binnen van buitenlandse IP's, in dit geval uit iets dat de Alibaba-cloud heet.
Op zich niet zo vreemd, want poort 853 staat open voor de hele wereld. Maar ik begrijp niet waarom iets of iemand bij mij DNS-requests zou willen doen.





Binnenkort de firewall maar eens wat strenger afstellen.

[Mirabis]

gerritjan schreef op woensdag 13 november 2024 @ 13:23:
Interessant verschijnsel. Sinds een paar weken krijg ik allemaal DoT-requests binnen van buitenlandse IP's, in dit geval uit iets dat de Alibaba-cloud heet.
Op zich niet zo vreemd, want poort 853 staat open voor de hele wereld. Maar ik begrijp niet waarom iets of iemand bij mij DNS-requests zou willen doen.

[Afbeelding]

[Afbeelding]

Binnenkort de firewall maar eens wat strenger afstellen.

Bijv. DNS amplification attacks https://www.cloudflare.co...mplification-ddos-attack/

Waarom heb je het open voor de hele wereld?

[gerritjan]

Mirabis schreef op woensdag 13 november 2024 @ 14:08:
[...]

Bijv. DNS amplification attacks https://www.cloudflare.co...mplification-ddos-attack/

Waarom heb je het open voor de hele wereld?

Ik zag tot nu toe geen reden om het verder dicht te zetten. Het gaat trouwens niet hard genoeg om het een DDOS-aanval te noemen.

[EverLast2002]

gerritjan schreef op woensdag 13 november 2024 @ 14:19:
[...]

Ik zag tot nu toe geen reden om het verder dicht te zetten. Het gaat trouwens niet hard genoeg om het een DDOS-aanval te noemen.

Dan nog....waarom zet je die poort open?
DDOS attack is dit niet, ze gebruiken nu gewoon jouw DNS mogelijkheid.

[Mirabis]

gerritjan schreef op woensdag 13 november 2024 @ 14:19:
[...]

Ik zag tot nu toe geen reden om het verder dicht te zetten. Het gaat trouwens niet hard genoeg om het een DDOS-aanval te noemen.

Artikel was voornamelijk gericht op jouw vraag "Maar ik begrijp niet waarom iets of iemand bij mij DNS-requests zou willen doen.". Men gebruikt meerdere open DNS resolvers om een "slachtoffer" aan te vallen. Dat hoeft niet te betekenen dat jij slachtoffer wordt van een DDOS-aanval maar je kan wel een onderdeel van de chain worden/zijn.

Het publiekelijk toegankelijk maken stelt je bloot aan aanvallen van buitenaf. Iedereen kan proberen een kwetsbaarheid te vinden op jouw instantie - of een al bestaande uit te voeren mits je een kwetsbare versie draait.

Maar goed, keuzes... denk aan je eigen "cyberweerbaarheid" .

[gerritjan]

EverLast2002 schreef op woensdag 13 november 2024 @ 14:30:
[...]
Dan nog....waarom zet je die poort open?

Die poort staat open zodat ik de Private DNS-setting van Android kan gebruiken. Ook een paar familieleden maken daar gebruik van.

[EverLast2002]

gerritjan schreef op woensdag 13 november 2024 @ 14:35:
[...]

Die poort staat open zodat ik de Private DNS-setting van Android kan gebruiken. Ook een paar familieleden maken daar gebruik van.

Ik denk dat ik snap wat je wilt bereiken, maar dit werkt toch al zonder externe poorten open te zetten?
sorry, ik maakte een denkfout..

[ Voor 5% gewijzigd door EverLast2002 op 14-11-2024 15:42 ]

[Hmmbob]

EverLast2002 schreef op woensdag 13 november 2024 @ 14:40:
[...]


Ik denk dat ik snap wat je wilt bereiken, maar dit werkt toch al zonder externe poorten open te zetten?

Euh, hoe zie je dat voor je?

[glaswerk]

Hmmbob schreef op woensdag 13 november 2024 @ 14:48:
[...]

Euh, hoe zie je dat voor je?

Ik heb ook DoT (en DoH) openstaan voor Android (en iOs) private DNS. Maar AGH accepteert alleen specifieke client IDs (ingesteld bij "Allowed clients", naast IP-ranges van intern netwerk en VPN). Zonder de juiste client ID geen respons. Dat is natuurlijk niet waterdicht, maar is wel al een heel effectieve eerste hindernis voor queries door onbekenden.

[Hmmbob]

Dat snap ik, maar dat kan nooit werken zonder een externe poort open te zetten - dat was het punt.

[sjongenelen]

Ja. Client id en dan ook nog het liefst nginx met geoblock. Bij mij nam het aantal snel toe zonder beveiliging

[lolgast]

Ik heb nog nooit met allowed clients gewerkt, maar op de volgende manier nog nooit een externe lookup gehad:
- AdGuardHome is extern voor DoH bereikbaar via een Cloudflare tunnel
- Een request móet met https://[FQND]/dns-query/* binnenkomen bij Cloudflare om doorgezet te worden

Op die manier heb ik geen poorten open op mijn eigen firewall en AGH kan niet misbruikt worden door random poorten te proberen zonder de juiste URL+pad te gebruiken.

[alex3305]

@gerritjan Ik heb in deze post hoe je eenvoudig met een client id kunt werken om ongewenst verkeer te blokkeren. Dat is ook eenvoudig in te stellen voor familieleden.

[gerritjan]

alex3305 schreef op woensdag 13 november 2024 @ 22:15:
@gerritjan Ik heb in deze post hoe je eenvoudig met een client id kunt werken om ongewenst verkeer te blokkeren. Dat is ook eenvoudig in te stellen voor familieleden.

Bedankt, maar je eenvoudige oplossing gaat mij enigszins boven m'n pet. Komt misschien ook omdat ik geen idee heb wat ik met Cloudfare kan of zou moeten doen.
Als het echt te gek wordt met ongewenste requests zal ik me eens verdiepen in client-id, voorlopig lijkt mij een geoblock afdoende.

[alex3305]

gerritjan schreef op woensdag 13 november 2024 @ 22:41:
[...]

Bedankt, maar je eenvoudige oplossing gaat mij enigszins boven m'n pet. Komt misschien ook omdat ik geen idee heb wat ik met Cloudfare kan of zou moeten doen.

Het Cloudflare gedeelte is hier voor jou niet van toepassing als je dat niet gebruikt . Het gaat daarbij met name om de DNS instelling.

Als het echt te gek wordt met ongewenste requests zal ik me eens verdiepen in client-id, voorlopig lijkt mij een geoblock afdoende.

Als je een wildcard DNS record instelt, bijvoorbeeld met een CNAME en in AdGuard Home ook een wildcard certificaat hebt, dan kun je het wildcard gedeelte gebruiken als client id. Dus bij mijn DNS provider heb ik de volgende zone ingesteld:

code:

NAME                    TYPE   VALUE
--------------------------------------------------
*.dns.example.com.      CNAME  example.com.
example.com.            A      192.0.2.23

Uiteraard fictieve data

Eenzelfde instelling doe je dan in AdGuard Home:


Tevens heb (eigenlijk had) ik in AdGuard Home mijn wildcard certificaat toegevoegd die ik via Let's Encrypt heb aangevraagd op die zone:


Die certificaten heb ik via de DNS-01 challenge laten genereren vanuit NGINX Proxy Manager. Want dat werkt wel zo makkelijk . Dan blijven ze ook bijgewerkt en met een Docker volume mapping, map ik die readonly naar de AdGuard Home Container:

NGINX Proxy Manager

YAML:

services:
  nginx:
    container_name: nginx-proxy-manager
    image: lepresidente/nginxproxymanager:${NPM_VERSION:-latest}
    restart: on-failure
    network_mode: host
    environment:
      TZ: "Europe/Amsterdam"
      DB_SQLITE_FILE: '/data/database.sqlite'
    volumes:
      - /opt/appdata/nginx-proxy-manager/data:/data
      - /opt/appdata/letsencrypt:/etc/letsencrypt

AdGuard Home

YAML:

services:
  adguardhome:
    container_name: adguardhome
    image: adguard/adguardhome:${ADGUARD_HOME_VERSION:-latest}
    restart: on-failure
    network_mode: host
    volumes:
      - /opt/appdata/adguard/workingdir:/opt/adguardhome/work
      - /opt/appdata/adguard/config:/opt/adguardhome/conf
      - /opt/appdata/letsencrypt:/opt/letsencrypt:ro

Uiteraard zijn dit de relevante snippets en niet mijn volledige configuratie

Nu is het zo dat wanneer ik DNS-over-TLS benader met een waarde in de wildcard, dat die waarde dan als client id wordt gebruikt door AdGuard Home. Als ik dus in Android mijn private DNS instel op: alex.dns.example.com dan kan ik deze client ook een mooie naam geven:


In de query log komt dan netjes naar voren dat dan Alex is verbonden.

In de DNS instellingen kun je vervolgens onder Access Settings, en dat was ik volgens mij in mijn vorige post vergeten te noemen, alleen clients toestaan of weigeren die aan jouw eisen voldoen. Dus in mijn geval accepteer ik alleen lokale verbindingen en de client id Alex:


Een IP-filter of geoblock werkt overigens net zo goed. Ook hier. Alleen vond ik dit wel een hele chique oplossing die je in (bijna) puur AdGuard kunt implementeren.

[gerritjan]

alex3305 schreef op donderdag 14 november 2024 @ 11:02:
[...]
In de query log komt dan netjes naar voren dat dan Alex is verbonden.
Een IP-filter of geoblock werkt overigens net zo goed. Ook hier. Alleen vond ik dit wel een hele chique oplossing die je in (bijna) puur AdGuard kunt implementeren.

Bedankt voor je uitleg, wordt gewaardeerd! Betekent dus wel dat elke user een andere URL krijgt als private DNS als ik het goed begrijp.

[alex3305]

gerritjan schreef op donderdag 14 november 2024 @ 13:44:
Bedankt voor je uitleg, wordt gewaardeerd!

Dank je. Ik besef me dat deze oplossing wellicht (te) complex is en dus niet voor iedereen is weggelegd. Aan de ander kant vond ik het belangrijk om het nog even toe te lichten. Want uiteindelijk vind ik het wel een enorm mooie oplossing .

Betekent dus wel dat elke user een andere URL krijgt als private DNS als ik het goed begrijp.

Ja dat kan. Zo had ik het inderdaad. Je kunt per user een aparte client id instellen in allowed clients, bijvoorbeeld:

code:

alex
henk
ingrid

wat overeenkomt met alex.dns.example.com, henk.dns.example.com en ingrid.dns.example.com. Maar je zou natuurlijk ook alle users dezelfde client id kunnen geven met bijvoorbeeld een random string, bijvoorbeeld mpj6p0gb5oaazdqsk4kqp4zmee8obomv.dns.example.com. Of een combinatie van beide als een soort sleutel: b5oaazdq-alex.dns.example.com. Dat is een vorm van security through obsecurity, maar wel met een misbruik kans die nihil is..

Die informatie komt dan ook zo weer in je access log. Dat kan handig zijn voor bijvoorbeeld troubleshooting.

[EverLast2002]

alex3305 schreef op vrijdag 8 november 2024 @ 11:06:
[...]

Toch nog even mezelf quoten. Inmiddels heb ik Technitium DNS Server in gebruik genomen als vervanging van Unbound als recursive DNS. Met webinterface wellicht ook wat makkelijker beheerbaar dan Unbound. Althans het geeft wellicht wat meer inzicht in hoe het e.e.a. werkt. Het zou zelfs als vervanging van Adguard Home kunnen werken aangezien het een vergelijkbare feature set heeft.

In ieder geval lijken de door mij genoemde problemen vooralsnog hiermee opgelost.

@alex3305
Ben ook Technitium aan het bekijken, ziet er prima uit.
Alleen ben ik benieuwd naar de continuiteit omdat alles vanuit 1 persoon lijkt te komen (Shreyas Zare, uit Mumbai India).
Kweetniet hoe jij hier in staat?

[alex3305]

@EverLast2002 Kort door de bocht vind ik dit helemaal ruk. Niet alleen vanwege de continuïteit, maar ook omdat er in principe maar één paar ogen naar zoiets belangrijks als DNS kijken.

Overigens blijft de NOS bij mij moeilijk doen. Ook met Technitium. Ik verwacht dat de NOS CDN iets onconventioneels doet om (D)DoS te beperken. Grotere DNS providers zullen hier geen last van hebben omdat zij toch de resultaten cachen en die met grote regelmaat zal worden bijgewerkt.

Kleine nabrander: Ik had vooral voor Technitium gekozen omdat deze recursive is en ik dan ook Unbound uit kan sluiten als oorzaak voor mijn problemen.

[ Voor 13% gewijzigd door alex3305 op 14-11-2024 17:29 ]

[EverLast2002]

alex3305 schreef op donderdag 14 november 2024 @ 17:28:
@EverLast2002 Kort door de bocht vind ik dit helemaal ruk. Niet alleen vanwege de continuïteit, maar ook omdat er in principe maar één paar ogen naar zoiets belangrijks als DNS kijken.

Overigens blijft de NOS bij mij moeilijk doen. Ook met Technitium. Ik verwacht dat de NOS CDN iets onconventioneels doet om (D)DoS te beperken. Grotere DNS providers zullen hier geen last van hebben omdat zij toch de resultaten cachen en die met grote regelmaat zal worden bijgewerkt.

Kleine nabrander: Ik had vooral voor Technitium gekozen omdat deze recursive is en ik dan ook Unbound uit kan sluiten als oorzaak voor mijn problemen.

Ik kijk vluchtig door de logs van Technitium, en kom verwijzingen tegen naar een locatie
die de maker gebruikt heeft (Z:\Technitium\Projects\DnsServer\DnsServerCore\WebServiceAuthApi.cs: line 688)
En nog enkele soortgelijke meldingen.
Verder werkt alles prima zover ik kan nagaan.

[Villager]

EverLast2002 schreef op donderdag 14 november 2024 @ 20:09:
[...]


Ik kijk vluchtig door de logs van Technitium, en kom verwijzingen tegen naar een locatie
die de maker gebruikt heeft (Z:\Technitium\Projects\DnsServer\DnsServerCore\WebServiceAuthApi.cs: line 688)
En nog enkele soortgelijke meldingen.
Verder werkt alles prima zover ik kan nagaan.

Ik zie ze ook staan. Heb Technitium Support de vraag gesteld waar deze voor zijn.

[Hmmbob]

alex3305 schreef op donderdag 14 november 2024 @ 11:02:
[...]

Het Cloudflare gedeelte is hier voor jou niet van toepassing als je dat niet gebruikt . Het gaat daarbij met name om de DNS instelling.


[...]

Als je een wildcard DNS record instelt, bijvoorbeeld met een CNAME en in AdGuard Home ook een wildcard certificaat hebt, dan kun je het wildcard gedeelte gebruiken als client id. Dus bij mijn DNS provider heb ik de volgende zone ingesteld:

code:

NAME                    TYPE   VALUE
--------------------------------------------------
*.dns.example.com.      CNAME  example.com.
example.com.            A      192.0.2.23

Uiteraard fictieve data

Eenzelfde instelling doe je dan in AdGuard Home:
[Afbeelding]

Tevens heb (eigenlijk had) ik in AdGuard Home mijn wildcard certificaat toegevoegd die ik via Let's Encrypt heb aangevraagd op die zone:
[Afbeelding]

Die certificaten heb ik via de DNS-01 challenge laten genereren vanuit NGINX Proxy Manager. Want dat werkt wel zo makkelijk . Dan blijven ze ook bijgewerkt en met een Docker volume mapping, map ik die readonly naar de AdGuard Home Container:

NGINX Proxy Manager

YAML:

services:
  nginx:
    container_name: nginx-proxy-manager
    image: lepresidente/nginxproxymanager:${NPM_VERSION:-latest}
    restart: on-failure
    network_mode: host
    environment:
      TZ: "Europe/Amsterdam"
      DB_SQLITE_FILE: '/data/database.sqlite'
    volumes:
      - /opt/appdata/nginx-proxy-manager/data:/data
      - /opt/appdata/letsencrypt:/etc/letsencrypt

AdGuard Home

YAML:

services:
  adguardhome:
    container_name: adguardhome
    image: adguard/adguardhome:${ADGUARD_HOME_VERSION:-latest}
    restart: on-failure
    network_mode: host
    volumes:
      - /opt/appdata/adguard/workingdir:/opt/adguardhome/work
      - /opt/appdata/adguard/config:/opt/adguardhome/conf
      - /opt/appdata/letsencrypt:/opt/letsencrypt:ro

Uiteraard zijn dit de relevante snippets en niet mijn volledige configuratie

Nu is het zo dat wanneer ik DNS-over-TLS benader met een waarde in de wildcard, dat die waarde dan als client id wordt gebruikt door AdGuard Home. Als ik dus in Android mijn private DNS instel op: alex.dns.example.com dan kan ik deze client ook een mooie naam geven:
[Afbeelding]

In de query log komt dan netjes naar voren dat dan Alex is verbonden.

In de DNS instellingen kun je vervolgens onder Access Settings, en dat was ik volgens mij in mijn vorige post vergeten te noemen, alleen clients toestaan of weigeren die aan jouw eisen voldoen. Dus in mijn geval accepteer ik alleen lokale verbindingen en de client id Alex:
[Afbeelding]

Een IP-filter of geoblock werkt overigens net zo goed. Ook hier. Alleen vond ik dit wel een hele chique oplossing die je in (bijna) puur AdGuard kunt implementeren.

1 aanvulling die vooral van belang is als je AdGuard lang draait zonder reboot/restart: gewijzigde certificaten worden pas actief bij een herstart van AdGuard. Stel dat je nginx de certs vernieuwd heeft, dan pikt AGH het niet automatisch op maar pas na een herstart. Tot die tijd gebruikt hij het oude cert, wat dan na verloop van tijd verloopt.

[Villager]

Villager schreef op donderdag 14 november 2024 @ 20:19:
[...]


Ik zie ze ook staan. Heb Technitium Support de vraag gesteld waar deze voor zijn.

Heb al antwoord gekregen:
The error logs contain the full path of the source code (when it was compiled) due to the .pdb debug files that are included with the software. They help when someone shares the error logs so that I can look at the exact line number in the code to try to find the issue.

Klinkt logisch. Er staan inderdaad regelnummers bij.

[alex3305]

Hmmbob schreef op vrijdag 15 november 2024 @ 09:03:
[...]

1 aanvulling die vooral van belang is als je AdGuard lang draait zonder reboot/restart: gewijzigde certificaten worden pas actief bij een herstart van AdGuard. Stel dat je nginx de certs vernieuwd heeft, dan pikt AGH het niet automatisch op maar pas na een herstart. Tot die tijd gebruikt hij het oude cert, wat dan na verloop van tijd verloopt.

Dat is een hele goede aanvulling. Dat wist ik niet.

Ik update en herstart mijn AdGuard Home automatisch met Watchtower. Aangezien ik twee instanties heb draaien doe ik dit op twee verschillende momenten om het risico op downtime te beperken. Dus ik ben hier nooit tegen aan gelopen.

[gerritjan]

Hmmbob schreef op vrijdag 15 november 2024 @ 09:03:
[...]
1 aanvulling die vooral van belang is als je AdGuard lang draait zonder reboot/restart: gewijzigde certificaten worden pas actief bij een herstart van AdGuard. Stel dat je nginx de certs vernieuwd heeft, dan pikt AGH het niet automatisch op maar pas na een herstart. Tot die tijd gebruikt hij het oude cert, wat dan na verloop van tijd verloopt.

In mijn geval gaat dat goed. AGH draai ik in docker op een Synology NAS. De NAS heeft een beperkte nginx-implementatie. Ik ververs op de NAS eens per kwartaal het Letsencrypt-WC-certificaat en importeer dat in AGH.

[alex3305]

Nav. de post van @EverLast2002 gisteren, en omdat mijn NOS problemen toch niet opgelost waren met Technitium, ben ik maar weer teruggegaan naar Unbound. Maar ik laat nu de NOS dus maar via de DNS van mijn provider lopen:

Upstream DNS servers

code:

# Unbound
10.100.100.20
# Workaround 
[/nos.nl/]192.168.1.1
# Internal routing
[//lan/internal/example.com/]192.168.1.1

Niet mooi. Maar voorlopig even functioneel.

[Pierre]

Ik heb AGH op een Raspberry draaien, maar updaten naar een nieuwe versie lukt niet via de webinterface of doe ik iets fouts.
Ik zie namelijk geen update button
Hoe kan ik nu precies updaten? Iemand die dat weet

[Hmmbob]

Welke versie draai je dan?

(Helemaal onderaan dit scherm)

[Pierre]

Had ik er even bij moeten vermelden ik heb versie v0.102.0. Uiteraard kan ik op de update button klikken naast dat maar dan zie ik alleen maar dat het gelukt is.

[TheCeet]

Ik veronderstel dat je deze draait op een raspberry pi.
In dat geval gewoon inloggen en navigeren naar de folder waar die installed is en simpel volgend commando triggeren:

code:

./AdGuardHome --update

Manueel kan ook op andere manier, zie:
https://github.com/adguar...ing-Started#manual-update

Je zal zo maar effe een sprong van 4j in updates maken

[bertdrenth]

Bij werkt Snapchat gewoon, en ja ik heb op safe gedrukt.
Avenguard draaid bij op dockers in een synology 718 nas. De dns staat goed in gesteld hij blokkeert wel bepaalde zaken alleen geen Snapchat of TikTok. Wat kan de oorzaak zijn?

[gerritjan]

bertdrenth schreef op zaterdag 14 december 2024 @ 17:48:
Bij werkt Snapchat gewoon, en ja ik heb op safe gedrukt.
Avenguard draaid bij op dockers in een synology 718 nas. De dns staat goed in gesteld hij blokkeert wel bepaalde zaken alleen geen Snapchat of TikTok. Wat kan de oorzaak zijn?

wat zie je in de logs voorbijkomen? Bij mij ziet het er zo uit:

[bertdrenth]

gerritjan schreef op zaterdag 14 december 2024 @ 18:46:
[...]

wat zie je in de logs voorbijkomen? Bij mij ziet het er zo uit:

[Afbeelding]

Net getest kom er gewoon op ondanks dat hij geblokkeerd zegt


instelling fritzbox

[ Voor 30% gewijzigd door bertdrenth op 15-12-2024 11:19 ]

[FLA NL]

Bij werkt Snapchat gewoon, en ja ik heb op safe gedrukt.
Avenguard draaid bij op dockers in een synology 718 nas. De dns staat goed in gesteld hij blokkeert wel bepaalde zaken alleen geen Snapchat of TikTok. Wat kan de oorzaak zijn?

Kan het niet zijn dat het device wat je gebruikt een private dns optie aan heeft staan? Tegenwoordig staat dat default op automatisch in android bijvoorbeeld. Ik heb daar ook last van gehad, Hagezi heeft daar ook weer een blocklist voor om externe dns services te blocken:

https://raw.githubusercon...ists/main/adblock/doh.txt

Verder zou je nog een stap verder kunnen gaan door port 853 upd/tcp te blokkeren in je router/firewall. En Asus routers hebben met de Merlin firmware nog een optie om dns (dns director) verkeer voor port 53 dat naar buiten te gaat om te leiden naar een lokale dns zoals adguard, zodat devices buiten die je lan omzeilen om een andere dns zoals google te gebruiken nog steeds kan forceren dat ze naar adguardhome gaan. Let wel als je dit doet dat adguardhome ge-exclude moet worden anders creëer je een loop indien je je router als upstream gebruikt. Daar heb je dan geen last van als je dns over https gebruikt in adguard zelf.

Daarnaast bestaat er bij Asus bij de wan instellingen ook nog een setting die voorkomt dat browsers als Firefox zelf kiezen om dns over https te gebruiken.

En zelfs als dit allemaal ingesteld is kan een device nog steeds gebruik maken van dns over https, als het IP nummer niet geresolved wordt bij de url maar voorgedefinieerd is. Dan zou je weer moeten gaan ip blocken.

[ Voor 3% gewijzigd door FLA NL op 16-12-2024 18:57 ]

[bertdrenth]

FLA NL schreef op zondag 15 december 2024 @ 11:51:
[...]


Kan het niet zijn dat het device wat je gebruikt een private dns optie aan heeft staan? Tegenwoordig staat dat default op automatisch in android bijvoorbeeld. Ik heb daar ook last van gehad, Hagezi heeft door ook weer een blocklist voor om externe dns services te blocken:

https://raw.githubusercon...ists/main/adblock/doh.txt

Verder zou je nog een stap verder kunnen gaan door port 853 upd/tcp te blokkeren in je router. En Asus routers hebben met de Merlin firmware nog een optie om dns (dns director) verkeer voor port 53 dat naar buiten te gaat om te leiden naar een lokale dns zoals adguard, zodat devices buiten die je lan omzeilen om een andere dns zoals google te gebruiken nog steeds kan forceren dat ze naar adguardhome gaan. Let wel als je dit doet dat adguardhome ge-exclude moet worden anders creëer je een loop indien je je router als upstream gebruikt. Daar heb je dan geen last van als je dns over https gebruikt in adguard zelf.

Daarnaast bestaat er bij Asus bij de wan instellingen ook nog een setting die voorkomt dat browsers als Firefox zelf kiezen om dns over https te gebruiken.

En zelfs als dit allemaal ingesteld is kan een device nog steeds gebruik maken van dns over https, als het IP nummer niet geresolved wordt bij de url maar voorgedefinieerd is. Dan zou je weer moeten gaan ip blocken.

Ik ga het proberen, dank voor het meedenken

[bertdrenth]

Het blokkeren van de dns heeft het gedaan.

https://gist.githubuserco...1af057c/doh-blocklist.txt
https://raw.githubusercon...er/public-dns-servers.txt

FLA NL schreef op zondag 15 december 2024 @ 11:51:
[...]


Kan het niet zijn dat het device wat je gebruikt een private dns optie aan heeft staan? Tegenwoordig staat dat default op automatisch in android bijvoorbeeld. Ik heb daar ook last van gehad, Hagezi heeft door ook weer een blocklist voor om externe dns services te blocken:

https://raw.githubusercon...ists/main/adblock/doh.txt

Verder zou je nog een stap verder kunnen gaan door port 853 upd/tcp te blokkeren in je router. En Asus routers hebben met de Merlin firmware nog een optie om dns (dns director) verkeer voor port 53 dat naar buiten te gaat om te leiden naar een lokale dns zoals adguard, zodat devices buiten die je lan omzeilen om een andere dns zoals google te gebruiken nog steeds kan forceren dat ze naar adguardhome gaan. Let wel als je dit doet dat adguardhome ge-exclude moet worden anders creëer je een loop indien je je router als upstream gebruikt. Daar heb je dan geen last van als je dns over https gebruikt in adguard zelf.

Daarnaast bestaat er bij Asus bij de wan instellingen ook nog een setting die voorkomt dat browsers als Firefox zelf kiezen om dns over https te gebruiken.

En zelfs als dit allemaal ingesteld is kan een device nog steeds gebruik maken van dns over https, als het IP nummer niet geresolved wordt bij de url maar voorgedefinieerd is. Dan zou je weer moeten gaan ip blocken.

[Videopac]

Ik luister voor het eerst in tijden weer eens commerciële internetradio en het viel me op dat in ieder geval bij FFH Weihnachtradio, Arrow Classic Rock, Sky Radio en Sky Radio Christmas er een preroll reclame voor de radiostream geplakt wordt. Ik zie zelf niet iets in de log wat het zou kunnen zijn. Zijn er mensen die preroll reclame bij internetradio effectief geblokkeerd hebben? Ik gebruik, voor zover ik weet, de orginele streams zoals vermeldt op https://www.webradiostreams.nl/:
https://playerservices.st...-redirect/SKYRADIOAAC.aac
https://playerservices.st...-redirect/SRGSTR08AAC.aac
https://mp3.ffh.de/ffhchannels/hqxmas.aac
https://stream.player.arrow.nl/arrowcr

[ Voor 3% gewijzigd door Videopac op 15-12-2024 16:54 ]

[RichardKim06]

Hopelijk kunnen jullie mij helpen. Ik heb Adguard draaien op mijn Home Assistant. Die draait vervolgens op een Raspberry PI. Enkele dagen geleden kreeg ik plotseling weer een lading ads te zien. Ik kon niet achterhalen waar het precies aan lag dus heb ik ervoor gekozen om Adguard opnieuw te installeren. Dit is nu de huidige setup:

Router: Fritzbox waarbij ik mijn Home Assistant als DNS server heb ingesteld. Als ik op mijn verbonden apparaten kijk zie ik dat ze inderdaad naar mijn Home Assistant worden gestuurd als zijnde DNS server dus dat gaat goed.

Adguard Add-on van home assistant: Luistert naar het correcte IP adres. Verder heb ik alle mogelijke blokkeerlijsten geimporteerd en aangevinkt. En bescherming staat "aan".

Toch overal reclames, is er iemand die zegt: hé dit ben je nog vergeten! Ik ben erg benieuwd :-)

[Harmen]

@RichardKim06 Welke apparaten laten ads zien? Android telefoons hebben vaak de neiging om 8.8.8.8 als dns server te gebruiken. Ik heb zelf dns naar andere adressen geblocked in mn netwerk (Unifi UXG). Daarnaast kan ipv6 ook issues geven in het lokale netwerk, zou dat uitschakelen.

[RichardKim06]

@Harmen Dank voor je antwoord. Dit is gewoon op mijn Windows 10 PC. Ik zal IPv6 eens uitschakelen

Edit: IPv6 compleet uitschakelen zorgt dat ik mijn interverbinding in zijn geheel verlies. Is het een vereiste van KPN dat dit is ingeschakeld?

Ik heb nu mijn Home Assistant ook een statisch IPv6 adres gegeven en dit vervolgens in de router ingesteld. Nu ben ik van alle ads verlost dus initieel probleem is weg.

Nu ben ik niet thuis in IPv6 en schakel ik dit toch liever op mijn thuisnetwerk uit maarja dan wel weer ads. Iemand een idee hoe dit in te stellen in de Fritzbox?

[ Voor 71% gewijzigd door RichardKim06 op 27-12-2024 10:13 ]