[Pi-Hole] Ervaringen & discussie

[webside007]

Pierre schreef op dinsdag 18 augustus 2020 @ 10:54:
Toevallig gister de update gedaan naar v5.1.2 en ik zag inderdaad dat die oisd lijsten niet goed meer zijn, als ik thuis ben ze maar even op disable zetten, welke alternatief raad je aan @jpgview

Bij mij draait Pihole in docker (op Synology).
En update is ook gedaan:
Pi-hole v5.1.2
Web interface v5.1.1
FLT v5.2

De oisd lijsten werken nog? En kunnen nog worden bijgewerkt...?
retrieval succesful -> received 1251927 domains

[jpgview]

Pierre schreef op dinsdag 18 augustus 2020 @ 10:54:
welke alternatief raad je aan

In mijn eerste reactie over de oisd lijst, gaf ik al aan dat die lijst werkt, maar zeker niet zalig makend is.

Ik heb een scriptje dat de efficiencie van mijn lijsten uitzoekt (het resultaat is alleen relevant voor mijn browser gedrag). Dat scriptje geeft b.v. nu het volgende (partial resultaat):

| hits | unique | adlist
| 19 | 0 | https://raw.githubusercon...nBlack/hosts/master/hosts
| 12 | 0 | https://adaway.org/hosts.txt
| 12 | 0 | https://dbl.oisd.nl
| 20 | 3 | https://raw.githubusercon...list/master/adservers.txt
| 21 | 0 | https://raw.githubusercon...rgon/hostsVN/master/hosts
| 10 | 0 | https://raw.githubusercontent.com/vokins/yhosts/master/hosts
| 5 | 1 | https://v.firebog.net/hosts/static/w3kbl.txt
| 9 | 0 | https://winhelp2002.mvps.org/hosts.txt
| 30 | 5 | https://www.github.develo...and-tracking-extended.txt

nogmaals, resultaat is louter een weerspiegeling van mijn browser gedrag, maar toont wel aan dat er geen unieke entries in de oisd lijst zijn.

Ik heb altijd deze site gebruikt, om betrouwbare lijsten toe te voegen. Er zijn een aantal keuzes, afhankelijk van hoeveel tijd je wil steken in whitelisten, ik gebruik de nocross lijsten (For when someone is usually around to whitelist falsely blocked sites). Dus ga naar de site kies het profiel (Ticked , Non-crossed, All) dat je wil gebruiken en voeg die lijsten toe.

Ik ben er redelijk van overtuigd dat ook de oisd lijst een aantal van deze lijsten gebruikt, om een geconsolideerde lijst te maken, waardoor, wanneer je zelf de firebog lijsten toevoegd, de oisd lijst heel wat minder toegevoegde waarde zal bieden. Ik vind nergens (wat niet wil zeggen dat het niet bestaat) een lijst die sjhgvr gebruikt om de geconsolideerde oisd lijst te maken.

[lier]

Ben bezig geweest om te kijken of ik twee Pi-Holes kan draaien in Docker op mijn Synology. Helaas nog niet gelukt en lees dat het ook niet mogelijk is.

Iemand die hier uitsluitsel over kan geven?

Reden om het te doen: bij uitval en onderhoud wil ik dat de service beschikbaar blijft (oftewel, twee DNS servers voor mijn clients).

[JayOne]

lier schreef op dinsdag 18 augustus 2020 @ 11:24:
Ben bezig geweest om te kijken of ik twee Pi-Holes kan draaien in Docker op mijn Synology. Helaas nog niet gelukt en lees dat het ook niet mogelijk is.

Iemand die hier uitsluitsel over kan geven?

Reden om het te doen: bij uitval en onderhoud wil ik dat de service beschikbaar blijft (oftewel, twee DNS servers voor mijn clients).

Uitval en onderhoud op je NAS heeft dan wel gelijk impact op je DNS omgeving. Waarom niet een instantie buiten je NAS om opzetten. Dus een Pi in je netwerk voorzien van Pi-Hole als backup, secundaire DNS.

[sphere]

@jpgview die blocklist zou ideaal zijn om te delen met torrent. Waarom je dat centraal host is mij onduidelijk.

[Webgnome]

jpgview schreef op dinsdag 18 augustus 2020 @ 10:42:
Ik vermelde hier al dat het niet botert tussen de pihole developers en sjhgvr, de maintainer van de oisd lijst.

Dit lijk nu te escaleren, lees hier. De oorzaak van deze (bijna Trump like) vete is deze post, waarin soms harde woorden vallen (bv hier)

Uiteraard heeft de pihole user hier allemaal geen boodschap aan, echter, sommigen onder ons zullen het negatieve effect (download failed) hiervan aan de lijve ondervinden.

Gelukkig zijn er work arrounds.
- wijzig het gravity script (NIET AANBEVOLEN, wijzigingen zullen bij pihole -up of pihole -r ongedaan gemaakt worden, en de impact op andere downloads is niet voorspelbaar)
- gebruik een mirror, er zijn er in het reddit artikel een aantal vermeld, ik heb ze zelf niet getest! Een GitHub download kan, bij mijn weten niet geblocked worden, de download is beschikbaar voor iedereen (of helemaal niet e.g. niemand)

Het staat natuurlijk iedereen vrij de overstap te maken naar Adguard Home, echter, het niet langer beschikbaar zijn van een lijst (geconsolideerd van andere lijsten), lijkt mij niet echt een goede reden.

wat ik er van lees is dat Phole geen gzip ondersteund waardoor zijn dataverbruik ENORM is. De devs geven aan dat het wel kan worden geimplementeerd maar moet worden getest en dat soort zaken en vervolgens trekt @sjhgvr zijn lijst in voor pihole gebruikers? Is dat een beetje in een nutshell wat er aan de hand is?

[Freee!!]

JayOne schreef op dinsdag 18 augustus 2020 @ 12:05:
[...]
Uitval en onderhoud op je NAS heeft dan wel gelijk impact op je DNS omgeving. Waarom niet een instantie buiten je NAS om opzetten. Dus een Pi in je netwerk voorzien van Pi-Hole als backup, secundaire DNS.

Precies, ik heb geen NAS (RPi bleek daar niet zo geschikt voor ), maar wel twee RPi's, ieder met Pi-Hole (en twee Unbounds).

[chaoscontrol]

lier schreef op dinsdag 18 augustus 2020 @ 11:24:
Ben bezig geweest om te kijken of ik twee Pi-Holes kan draaien in Docker op mijn Synology. Helaas nog niet gelukt en lees dat het ook niet mogelijk is.

Iemand die hier uitsluitsel over kan geven?

Reden om het te doen: bij uitval en onderhoud wil ik dat de service beschikbaar blijft (oftewel, twee DNS servers voor mijn clients).

Als je een 2e NIC hebt kun je de 2e container onder dat IP draaien.

[pennywiser]

lier schreef op dinsdag 18 augustus 2020 @ 11:24:
Ben bezig geweest om te kijken of ik twee Pi-Holes kan draaien in Docker op mijn Synology. Helaas nog niet gelukt en lees dat het ook niet mogelijk is.

Iemand die hier uitsluitsel over kan geven?

Reden om het te doen: bij uitval en onderhoud wil ik dat de service beschikbaar blijft (oftewel, twee DNS servers voor mijn clients).

2 dezelfde dockers op 1 machine kan altijd. Je kan met swarm ha regelen, macvlan netwerk ervoor voor toegang via je normale netwerk, hiermee geef je je dockers een nic.

Portainer container erbij voor een Docker webinterface en dan ben je helemaal klaar.

[ Voor 9% gewijzigd door pennywiser op 18-08-2020 12:57 ]

[lier]

chaoscontrol schreef op dinsdag 18 augustus 2020 @ 12:54:
Als je een 2e NIC hebt kun je de 2e container onder dat IP draaien.

Dat dacht ik dus ook...echter ondanks dat ik de containers expliciet koppel (als host) aan de betreffende nics, start de tweede niet op.

JayOne schreef op dinsdag 18 augustus 2020 @ 12:05:
Uitval en onderhoud op je NAS heeft dan wel gelijk impact op je DNS omgeving. Waarom niet een instantie buiten je NAS om opzetten. Dus een Pi in je netwerk voorzien van Pi-Hole als backup, secundaire DNS.

Zou een oplossing zijn (ook hiervoor), maar vooralsnog wil ik niet die kant op gaan.

pennywiser schreef op dinsdag 18 augustus 2020 @ 12:55:
2 dezelfde dockers op 1 machine kan altijd. Je kan met swarm ha regelen, macvlan netwerk ervoor voor toegang via je normale netwerk, hiermee geef je je dockers een nic.

Portainer docker erbij voor een Docker webinterface en dan ben je helemaal klaar.

Ik ga eens kijken, dank!

[ Voor 21% gewijzigd door lier op 18-08-2020 12:57 ]

[pennywiser]

lier schreef op dinsdag 18 augustus 2020 @ 12:57:
[...]

Dat dacht ik dus ook...echter ondanks dat ik de containers expliciet koppel (als host) aan de betreffende nics, start de tweede niet op.

Macvlan

[Freee!!]

pennywiser schreef op dinsdag 18 augustus 2020 @ 12:58:
[...]
Macvlan

AMEN!
Zo heb ik Pi-Hole V5 getest naast V4.

[sjhgvr]

jpgview schreef op dinsdag 18 augustus 2020 @ 10:42:
Ik vermelde hier al dat het niet botert tussen de pihole developers en sjhgvr, de maintainer van de oisd lijst.

Dit lijk nu te escaleren, lees hier. De oorzaak van deze (bijna Trump like) vete is deze post, waarin soms harde woorden vallen (bv hier)

Op zich oud nieuws .. maar lees ff verder;

jpgview schreef op dinsdag 18 augustus 2020 @ 10:42:
Uiteraard heeft de pihole user hier allemaal geen boodschap aan, echter, sommigen onder ons zullen het negatieve effect (download failed) hiervan aan de lijve ondervinden.
Gelukkig zijn er work arrounds.
- wijzig het gravity script (NIET AANBEVOLEN, wijzigingen zullen bij pihole -up of pihole -r ongedaan gemaakt worden, en de impact op andere downloads is niet voorspelbaar)
- gebruik een mirror, er zijn er in het reddit artikel een aantal vermeld, ik heb ze zelf niet getest! Een GitHub download kan, bij mijn weten niet geblocked worden, de download is beschikbaar voor iedereen (of helemaal niet e.g. niemand)

Ik had "gzip enforcing" aangezet, (zodat de blocklist niet langer door Pi-hole gedownload kon worden omdat Pi-hole geen gzip support bied) om Pi-hole devs (indirect, door klachten van Pi-hole gebruikers van de oisd lijst) dwars te zitten, en gzip support te laten inbouwen.
Ik was t even zat om lief te zijn... soms moet je ff dwars doen, dit was zo'n moment van mij... maaaaar;

wat blijkt:
Ik was iets te voorbarig en 16 dagen geleden is het weer in gang gezet, gemerged, en de volgende versie van Pi-hole gaat gzip support ondersteunen! https://github.com/pi-hole/pi-hole/pull/3641

"Gzip enforcing" teruggedraaid,

Dus niks aan de hand, alles werkt weer zoals voorheen

jpgview schreef op dinsdag 18 augustus 2020 @ 10:42:
Het staat natuurlijk iedereen vrij de overstap te maken naar Adguard Home, echter, het niet langer beschikbaar zijn van een lijst (geconsolideerd van andere lijsten), lijkt mij niet echt een goede reden.

Niet nodig dus

[ Voor 5% gewijzigd door sjhgvr op 18-08-2020 13:34 ]

[sjhgvr]

jpgview schreef op dinsdag 18 augustus 2020 @ 11:15:
Ik ben er redelijk van overtuigd dat ook de oisd lijst een aantal van deze lijsten gebruikt, om een geconsolideerde lijst te maken, waardoor, wanneer je zelf de firebog lijsten toevoegd, de oisd lijst heel wat minder toegevoegde waarde zal bieden. Ik vind nergens (wat niet wil zeggen dat het niet bestaat) een lijst die sjhgvr gebruikt om de geconsolideerde oisd lijst te maken.

Gewoon te vinden op de includes pagina? https://includes.oisd.nl/

[ Voor 9% gewijzigd door sjhgvr op 18-08-2020 13:33 ]

[sjhgvr]

Webgnome schreef op dinsdag 18 augustus 2020 @ 12:18:
[...]


wat ik er van lees is dat Phole geen gzip ondersteund waardoor zijn dataverbruik ENORM is. De devs geven aan dat het wel kan worden geimplementeerd maar moet worden getest en dat soort zaken en vervolgens trekt @sjhgvr zijn lijst in voor pihole gebruikers? Is dat een beetje in een nutshell wat er aan de hand is?

Correct.
Edit: Ofja .. ENORM ? : Momenteel 9 TB/ maand met gratis Cloudflare account .. kan nergens fatsoenlijk vinden wat de grens is .. dus ~70% minder data door gebruik van gzip is wel lekker dan toch?

[ Voor 19% gewijzigd door sjhgvr op 18-08-2020 13:39 ]

[Pierre]

Dus @sjhgvr ik kan je listen dus gewoon weer op enable zetten

[Miki]

@sjhgvr ik maak ook graag gebruik van je lijst dus ik ben blij dat het is opgelost. Wellicht is jou lijst voor de puristen onder ons haram maar het bevalt ons hier in het gezin uitstekend. De balans is prima tussen wat er wordt gefilterd en wat er wordt toegelaten dus ik ben nogmaals blij om te horen dat er een oplossing is gevonden

Ps. Onder de docker gebruikers kijk ook eens naar Proxmox als je toevallig een server draait. Ik ben super tevreden over het draaien van pi-hole in een LXC container. Het voordeel is dat je geen gedoe meer hebt met poorten en ip-adressen doordat iedere LXC container zijn eigen ip-adres krijgt. Daarnaast kun je gebruik maken van de interne upgrade functie van pi-hole.

[ Voor 36% gewijzigd door Miki op 18-08-2020 14:50 ]

[webside007]

Miki schreef op dinsdag 18 augustus 2020 @ 14:46:
@sjhgvr ik maak ook graag gebruik van je lijst dus ik ben blij dat het is opgelost. Wellicht is jou lijst voor de puristen onder ons haram maar het bevalt ons hier in het gezin uitstekend. De balans is prima tussen wat er wordt gefilterd en wat er wordt toegelaten dus ik ben nogmaals blij om te horen dat er een oplossing is gevonden

Ps. Onder de docker gebruikers kijk ook eens naar Proxmox als je toevallig een server draait. Ik ben super tevreden over het draaien van pi-hole in een LXC container. Het voordeel is dat je geen gedoe meer hebt met poorten en ip-adressen doordat iedere LXC container zijn eigen ip-adres krijgt. Daarnaast kun je gebruik maken van de interne upgrade functie van pi-hole.

Ik heb docker op Synology draaien...
Heb je een Proxmox tutorial hiervoor toevallig?
Interne updgrade functie? niet meer pihole -up? (heb ik iets gemist?)

[pennywiser]

webside007 schreef op dinsdag 18 augustus 2020 @ 14:53:
[...]

Interne updgrade functie? niet meer pihole -up? (heb ik iets gemist?)

Met docker update je niet zelf, mogelijk sloop je dan je container. Je pakt gewoon de nieuwe docker van de hub. Je data staat lokaal op volumes (als het goed is).

[webside007]

pennywiser schreef op dinsdag 18 augustus 2020 @ 14:57:
[...]

Met docker update je niet zelf, mogelijk sloop je dan je container. Je pakt gewoon de nieuwe docker van de hub. Je data staat lokaal op volumes (als het goed is).

Dat weet ik Vinzz.
Maar Miki zei dat je met Proxmox de interne update functie van Pihole kan gebruiken...

[bluecupra]

pennywiser schreef op dinsdag 18 augustus 2020 @ 14:57:
[...]

Met docker update je niet zelf, mogelijk sloop je dan je container. Je pakt gewoon de nieuwe docker van de hub. Je data staat lokaal op volumes (als het goed is).

Of met behulp van een tool als Portainer kan je de bestaande container dupliceren en gebruik maken van de laatste versie. Erg snelle manier om je Docker containers bij te werken

[Freee!!]

Miki schreef op dinsdag 18 augustus 2020 @ 14:46:
[...]
Ps. Onder de docker gebruikers kijk ook eens naar Proxmox als je toevallig een server draait. Ik ben super tevreden over het draaien van pi-hole in een LXC container. Het voordeel is dat je geen gedoe meer hebt met poorten en ip-adressen doordat iedere LXC container zijn eigen ip-adres krijgt.

Datzelfde heb ik door gebruik van macvlan (en dat snap ik ondertussen ).

Daarnaast kun je gebruik maken van de interne upgrade functie van pi-hole.

Daarvoor heb ik Watchtower.

bluecupra schreef op dinsdag 18 augustus 2020 @ 15:02:
[...]
Of met behulp van een tool als Portainer kan je de bestaande container dupliceren en gebruik maken van de laatste versie. Erg snelle manier om je Docker containers bij te werken

Watchtower doet het automatisch voor mij.

[ Voor 22% gewijzigd door Freee!! op 18-08-2020 15:03 ]

[pennywiser]

bluecupra schreef op dinsdag 18 augustus 2020 @ 15:02:
[...]


Of met behulp van een tool als Portainer kan je de bestaande container dupliceren en gebruik maken van de laatste versie. Erg snelle manier om je Docker containers bij te werken

for image in $(sudo docker image ls | awk '{print $1}' | grep -ve "none\|REPOSITORY" | sort | uniq); do sudo docker pull $image ;done

En alles is geüpdatet Inclusief Portainer.

[Freee!!]

code:

docker run -d \
 --name Watchtower4 \
 -e TZ=Europe/Amsterdam \
 -e WATCHTOWER_CLEANUP=True \
 -e WATCHTOWER_NOTIFICATIONS=email \
 -e WATCHTOWER_NOTIFICATION_EMAIL_FROM=[e-mail] \
 -e WATCHTOWER_NOTIFICATION_EMAIL_TO=[e-mail] \
 -e WATCHTOWER_NOTIFICATION_EMAIL_SERVER=192.168.2.236 \
 -e WATCHTOWER_POLL_INTERVAL=300 \
 -e WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PORT=25 \
 -e WATCHTOWER_NOTIFICATION_EMAIL_SERVER_TLS_SKIP_VERIFY=True \
 -e WATCHTOWER_DEBUG=false \
 -v /var/run/docker.sock:/var/run/docker.sock:rw \
 -v /etc/localtime:/etc/localtime:ro \
 --restart unless-stopped \
 containrrr/watchtower

[nero355]

pennywiser schreef op maandag 17 augustus 2020 @ 20:26:
Als je en wat vlottere SD kaart wilt, kan ik je een Samsung EVO SD kaart aanraden. Een stuk vlotter dan alles wat ik tot nu toe van Sandisk en Kingston heb gebruikt.

Het microSDXC slot van een Raspberry Pi kan helemaal niet zoveel data verwerken dus snelheid is daar helemaal niet boeiend, maar wel de betrouwbaarheid en daarvoor hebben de betere merken allen een leuk model voor

Vroeger had ik een wat professioneler Samsung model in gebruik, echter heb ik die weggegeven aan familie, want 128 GB model en gebruik ik tegenwoordig dit model alweer ongeveer 2 jaar lang zonder enig probleem : https://www.dataio.nl/san...-pro-a1-u3-geheugenkaart/

Heeft zelfs een paar "stroomstoringen" overleefd!

chaoscontrol schreef op dinsdag 18 augustus 2020 @ 12:54:
Als je een 2e NIC hebt kun je de 2e container onder dat IP draaien.

Maak gewoon een alias interface aan desnoods dan heb je hetzelfde, maar dan anders

Miki schreef op dinsdag 18 augustus 2020 @ 14:46:
@sjhgvr ik maak ook graag gebruik van je lijst dus ik ben blij dat het is opgelost. Wellicht is jou lijst voor de puristen onder ons haram maar het bevalt ons hier in het gezin uitstekend. De balans is prima tussen wat er wordt gefilterd en wat er wordt toegelaten dus ik ben nogmaals blij om te horen dat er een oplossing is gevonden

Precies de reden dat ik de lijst niet gebruik! _{What's haram in a name... ?!}

Ik heb zelfs de laatste tijd het idee dat de standaard blocklists soms te weinig blokkeren of dingen die ze vroeger blokkeerden niet meer blokkeren dus daar moet ik nog effe een keer wat meer over uitzoeken!

Ps. Onder de docker gebruikers kijk ook eens naar Proxmox als je toevallig een server draait. Ik ben super tevreden over het draaien van pi-hole in een LXC container. Het voordeel is dat je geen gedoe meer hebt met poorten en ip-adressen doordat iedere LXC container zijn eigen ip-adres krijgt. Daarnaast kun je gebruik maken van de interne upgrade functie van pi-hole.

Als elke Synology/QNAP/enz. gebruiker nou eens gewoon een cheapass Intel NUCje (Of die van AsRock/Zotac/enz.) zou kopen en daarop Proxmox zou draaien dan waren ze zoveel gelukkiger ondertussen!

webside007 schreef op dinsdag 18 augustus 2020 @ 14:59:
Miki zei dat je met Proxmox de interne update functie van Pihole kan gebruiken...

Omdat je gewoon virtualiseert zonder gezeik en dus de volledige controle hebt!

[pennywiser]

nero355 schreef op dinsdag 18 augustus 2020 @ 15:15:
[...]

Het microSDXC slot van een Raspberry Pi kan helemaal niet zoveel data verwerken dus snelheid is daar helemaal niet boeiend, maar wel de betrouwbaarheid en daarvoor hebben de betere merken allen een leuk model voor

Wie zegt dat ik een Raspberry Pi gebruik

Orange Pi Zero Plus hier met Armbian en Pihole/Pivpn, Rpi's vraten mij elke keer de sd kaarten op. Met Opi nergens meer last van, ik gebruik deze nu 3 jaar.

Toch merk ik wel wat verschil met Samsung Evo kaartjes, reageert net wat vlotter dan de Kingston kaartjes die ik hiervoor had. Is het heel schokkend, nee, vlotter ja wel degelijk.

[Freee!!]

pennywiser schreef op dinsdag 18 augustus 2020 @ 15:20:
[...]
Wie zegt dat ik een Raspberry Pi gebruik

Orange Pi Zero Plus hier met Armbian en Pihole/Pivpn, Rpi's vraten mij elke keer de sd kaarten op. Met Opi nergens meer last van, ik gebruik deze nu 3 jaar.

Toch merk ik wel wat verschil met Samsung Evo kaartjes, reageert net wat vlotter dan de Kingston kaartjes die ik hiervoor had. Is het heel schokkend, nee, vlotter ja wel degelijk.

Totaal geen probleem met RPi's die kaarten opvreten, gebruik altijd SanDisk.

[nero355]

pennywiser schreef op dinsdag 18 augustus 2020 @ 15:20:
Wie zegt dat ik een Raspberry Pi gebruik

Wat je ook gebruikt : De regels zijn hetzelfde

Orange Pi Zero Plus hier met Armbian en Pihole/Pivpn, Rpi's vraten mij elke keer de sd kaarten op. Met Opi nergens meer last van, ik gebruik deze nu 3 jaar.

Ik ken iemand die zo'n beetje elk ARM based bordje heeft en die heeft nooit echt grote verschillen tussen al die modellen meegemaakt qua microSDXC kaartjes opvreten

Toch merk ik wel wat verschil met Samsung Evo kaartjes, reageert net wat vlotter dan de Kingston kaartjes die ik hiervoor had. Is het heel schokkend, nee, vlotter ja wel degelijk.

Tuurlijk, maar op een bepaald moment knal je tegen een grens aan en maakt het niks meer uit!

[pennywiser]

nero355 schreef op dinsdag 18 augustus 2020 @ 15:15:

[...]

Omdat je gewoon virtualiseert zonder gezeik en dus de volledige controle hebt!

Maar wat is het nou dan, een lxc container of een vm?

Moet erbij zeggen dat ik Proxmox niet ken.

[ Voor 8% gewijzigd door pennywiser op 18-08-2020 16:13 ]

[nero355]

pennywiser schreef op dinsdag 18 augustus 2020 @ 16:10:
Maar wat is het nou dan, een lxc container of een vm?

Hij gebruikt LXC wat in feite een Container is die delen van de Proxmox Kernel gebruikt om een OS op te starten.

Ik gebruik altijd gewoon volledige VM's omdat die dan volledig afgesloten zijn en je alles gewoon in de VM dumpt

Moet erbij zeggen dat ik Proxmox niet ken.

Installeer het op een testbakkie en ga ermee spelen, want het is echt leuk spul en flexibeler dan bijvoorbeeld VMWare voor thuisgebruik!

[pennywiser]

nero355 schreef op dinsdag 18 augustus 2020 @ 16:31:
[...]

Hij gebruikt LXC wat in feite een Container is die delen van de Proxmox Kernel gebruikt om een OS op te starten.

[...]

In dat geval zou ik geen pihole -up gebruiken, maar de laatste image pullen en de container herstarten. Oude Pihole image weggooien.

Inderdaad ik ga er eens mee stoeien, tnx voor de tip. Draai je dit op een Pi?

[nero355]

pennywiser schreef op dinsdag 18 augustus 2020 @ 16:34:
Inderdaad ik ga er eens mee stoeien, tnx voor de tip. Draai je dit op een Pi?

Nee, dat kan niet en zal je dus zoals ik al eerder zei richting een cheapo NUC achtig kastje moeten gaan denken

Zelf draai ik het gewoon op een volledige PC met 32 GB RAM en die gebruik ik voornamelijk om af en toe wat te testen voor mezelf of voor anderen

[Miki]

Freee!! schreef op dinsdag 18 augustus 2020 @ 15:03:
[...]

Datzelfde heb ik door gebruik van macvlan (en dat snap ik ondertussen ).

[...]

Daarvoor heb ik Watchtower.

[...]

Watchtower doet het automatisch voor mij.

Draai je pi-hole op een Pi dan geef ik je groot gelijk, ik heb er tot voor kort ook erg veel plezier van gehad.
Mocht je een pc over hebben of ergens een Intel Nuc hebben liggen dan kan ik je Proxmox van harte aanraden. Dat is echt wel een bazen distro voor thuisgebruik om containers en vm's met groot gemak te kunnen draaien. Ik zal niet zo snel meer teruggrijpen naar Docker nu ik zelf volledige controle heb over wat ik per VM of container draai en minder afhankelijk ben van anderen die wat beschikbaar stellen op docker hub.

[Freee!!]

Miki schreef op dinsdag 18 augustus 2020 @ 17:10:
[...]
Draai je pi-hole op een Pi dan geef ik je groot gelijk, ik heb er tot voor kort ook erg veel plezier van gehad.
Mocht je een pc over hebben of ergens een Intel Nuc hebben liggen dan kan ik je Proxmox van harte aanraden. Dat is echt wel een bazen distro voor thuisgebruik om containers en vm's met groot gemak te kunnen draaien. Ik zal niet zo snel meer teruggrijpen naar Docker nu ik zelf volledige controle heb over wat ik per VM of container draai en minder afhankelijk ben van anderen die wat beschikbaar stellen op docker hub.

Ik ben ook niet totaal afhankelijk van wat anderen beschikbaar stellen op Docker Hub, ik ben bezig me te verdiepen in het maken en gebruiken van nieuwe images/containers. Maar van Docker onder WSL2 ben ik nog niet echt onder de indruk, om het serieus aan te pakken heb ik gewoon nog een derde RPi nodig.

[deHakkelaar]

sjhgvr schreef op dinsdag 18 augustus 2020 @ 13:26:
Ik had "gzip enforcing" aangezet, (zodat de blocklist niet langer door Pi-hole gedownload kon worden omdat Pi-hole geen gzip support bied) om Pi-hole devs (indirect, door klachten van Pi-hole gebruikers van de oisd lijst) dwars te zitten, en gzip support te laten inbouwen.
Ik was t even zat om lief te zijn... soms moet je ff dwars doen, dit was zo'n moment van mij... maaaaar;

Wat een manieren.
Dat is gewoon afpersing.
Ik weet wel één ding en dat is dat ik jou lijsten nooit zal gebruiken.
Gewoon vanwege één ding ... vertrouwen.
Mogelijk had ook een mod hier moeten ingrijpen aangezien dit niet over Pi-hole gaat maar over lijsten en een persoonlijke vete.
Bah.

[Just Me Or Tha One]

Ik heb op de NAS ook OpenVPN draaien (package van Synology). Als ik van buitenaf (via mobiel internet) verbind met mijn netwerk kan ik gewoon internetten. Echter als ik een profiel aanmaak met pihole als DNS-server krijgt mijn telefoon geen IP-adressen meer terug over de VPN.

mobiel op 4G -> Open VPN op NAS -> internet werkt
mobiel op 4G -> Open VPN op NAS -> pihole in docker op NAS -> internet werkt niet

In de logs van pihole zie ik dat het het IP-adress van docker (172-reeks) een reactie krijgt. Echter moet dat natuurlijk terug naar de IP-reeks van OVPN (10-reeks).

Heeft iemand een idee?

Heeft iemand een idee?

[sjhgvr]

deHakkelaar schreef op dinsdag 18 augustus 2020 @ 17:54:
[...]
Wat een manieren.
Dat is gewoon afpersing.
Ik weet wel één ding en dat is dat ik jou lijsten nooit zal gebruiken.
Gewoon vanwege één ding ... vertrouwen.
Mogelijk had ook een mod hier moeten ingrijpen aangezien dit niet over Pi-hole gaat maar over lijsten en een persoonlijke vete.
Bah.

Ik houd ook van jou.

[deHakkelaar]

sjhgvr schreef op dinsdag 18 augustus 2020 @ 18:26:
[...]

Ik houd ook van jou.

xxx

[sjhgvr]

Mocht je gzip support aan willen zetten in je Pi-hole:

code:

sudo sed -i 's/curl -s/curl --compressed -s/' /opt/pihole/gravity.sh

[sphere]

Zou de default moeten zijn...

[Pierre]

sjhgvr schreef op dinsdag 18 augustus 2020 @ 18:35:
Mocht je gzip support aan willen zetten in je Pi-hole:

code:

sudo sed -i 's/curl -s/curl --compressed -s/' /opt/pihole/gravity.sh

Heeft deze optie niet heel schrijf acties op je sd card?

[sjhgvr]

Pierre schreef op dinsdag 18 augustus 2020 @ 18:44:
[...]

Heeft deze optie niet heel schrijf acties op je sd card?

Ik zou toch denken dat CURL dat in RAM oplost alvorens de file op te slaan.
Dit zou betekenen dat t voor schrijf acties geen verschil maakt.

[TFHfony]

Dankzij de eerder tips hier lopen de DNS aanvragen van alle clients in het netwerk nu netjes via de PiHole, zowel voor IPv4 als IPv6. Ik heb in mijn Fritz!Box 7590 de functie "Unique Local Addresses (ULA) altijd toewijzen" aangezet. Toch loopt de clientlist van PiHole helemaal vol met IPv6 clients.
Zie ik hier iets over het hoofd?

[jpgview]

TFHfony schreef op dinsdag 18 augustus 2020 @ 21:24:
Toch loopt de clientlist van PiHole helemaal vol met IPv6 clients.
Zie ik hier iets over het hoofd?

work in progress. read here, here and here.

[htca]

nero355 schreef op maandag 17 augustus 2020 @ 16:00:
[...]

Nou... lekker dan...

Niet stiekem ergens een cronjob die dat doet of zo


[...]

Gewoon de WiFi helemaal uitschakelen en alleen de Ethernet verbinding van je Pi gebruiken!


[...]

Uninstalleren kan, maar is nergens voor nodig! Gewoon niet gebruiken is genoeg


[...]

Vast wel, maar dan wel op voorwaarde dat jij alles goed instelt!

Paar avondjes klussen maar dan heb je ook wat.... Domoticz vanuit de backup teruggezet en weer draaien. Maar op de een of andere manier kreeg ik de DHCP van pihole niet stabiel, dus weer terug gegaan naar DHCP op de router maar een DNS server op pihole en een op het adres van de router... dan maar de kans dat een aantal request niet zouden worden worden, maar de berusting die ik dacht te vinden vond ik niet....

Toen viel mijn oog op een AP (of eigenlijk de voormalige router van mijn partner).... Sinds een paar jaar hebben mijn partner en ik een gezamenlijk huishouden en moesten er 2 huishoudens worden samengevoegd. "grappig" dacht ik destijds "we hebben precies dezelfde router".... (toen al een hoop shit, want we hadden allebei de default SSID gehandhaaft....)
Maar laat zij nou en RT-N66U hebben en ik een RT-AC66U hebben (en de RT-AC66U in gebruik gehouden als router en de N66U als AP ingesteld)... en de eerste wel ondersteund worden door Merlin en de tweede niet....

Anyway; de RT-N66U geflasht ingesteld als DHCP, de verse domoticz pi voorzien van de pihole software en de boel weer opgestart en jawel; 2 velden voor een DNS server in de LAN settings op de router.
Restte alleen nog de openvpn en de dns daarin ook meegeven....
#happyuser

Vragen voor hier;

• ik gebruik de default lijsten die mee kwamen bij de installatie, die lijken ok voor nu, of zijn absoluut lijsten die ik zou moeten gebruiken. Ik heb 3 pubers hier in huis... maw gezeik als het internet het (deels) niet doet, wel een bedankje voor de "reclamevrije browser ervaring"
• ik lees met interesse de unbound opties; ik twijfel om deze aan te zwengelen. Wat zijn jullie ervaringen?

[beerns]

ik gebruik unbound en dat gaat prima. Geen problemen eigenlijk.
Kan ook niet zeggen of mn verbinding sneller of trager is; wat ik wel weet ik dat ik geen dns queries meer richting het internet stuur. Ik heb aan mn wan kant OpenDNS geconfigureerd en heb daar een account. Dus kan zien welke domeinen ik bezoek.
Dat is beperkt tot een momenteel (mn USG zoekt elke dag naar een firmware update bij UBNT) en verder is er dus geen verkeer meer richting OpenDNS. En dat wilde ik.

Installatie etc is vrij straightforward en goed te doen. Jammer vind ik wel dat de repository via Raspberry Pi OS een paar versies achter loopt. Ik compileer niet mn eigen versie. Heb de tijd niet om dat bij te houden.
Ik weet dat er een versie 1.11.0 is maar via de CLI zegt dat mijn versie is 1.9.0-2+deb10u2 En er is geen update beschikbaar via apt-get update
Nevertheless; het hangt niet aan het internet; dus voor internal use is dit voor nu prima; had ik 'm aan het internet hangen dan was ik hier minder blij mee (want groot security risk).

Daarnaast gebruik ik de lijsten van de medewerker @sjhgvr en IK ben daar blij mee. Heb wat zaken in de whitelist gegooid (bepaalde spellen werken niet zonder Google ads) voor 2 ip adressen intern (dat kan tegenwoordig handig met Pi Hole); maar voor het overgrote deel gaat dit uitstekend.
Is je dat teveel dan kun je https://v.firebog.net/hosts/lists.php daar ook je eigen lijsten er uit halen.
(tip van @jpgview )

[sjhgvr]

beerns schreef op vrijdag 21 augustus 2020 @ 07:52:
Daarnaast gebruik ik de lijsten van de medewerker @sjhgvr en IK ben daar blij mee. Heb wat zaken in de whitelist gegooid (bepaalde spellen werken niet zonder Google ads) ...

Welke ? Ben zeer benieuwd

[hp-got]

htca schreef op donderdag 20 augustus 2020 @ 20:02:
[...]
ik lees met interesse de unbound opties; ik twijfel om deze aan te zwengelen. Wat zijn jullie ervaringen?

Tegen welke gevaren wil je je beschermen?
- privacy? De ISP / DNS provider / .... die ziet welke queries je doet?
- DNS poisoning?
Het antwoord op die vragen bepaalt of Unbound iets toevoegt in jouw situatie.

Mijn ervaring is erg goed, Unbound werkt altijd, is (volgens GRC DNS test) ook de snelste optie, dus alles prima.

Als je nog geen DNSSEC zou gebruiken is dat meteen geregeld

Unbound draait hier op een RPi 3B, samen met Pihole, jaren en jaren op hetzelfde SD kaartje zonder dat er iets stuk gaat, ik ben er blij mee.

[jpgview]

beerns schreef op vrijdag 21 augustus 2020 @ 07:52:
ik gebruik unbound en dat gaat prima.

beerns schreef op vrijdag 21 augustus 2020 @ 07:52:
Ik weet dat er een versie 1.11.0 is maar via de CLI zegt dat mijn versie is 1.9.0-2+deb10u2 En er is geen update beschikbaar via apt-get update
Nevertheless; het hangt niet aan het internet; dus voor internal use is dit voor nu prima; had ik 'm aan het internet hangen dan was ik hier minder blij mee (want groot security risk).

Ik weet niet hoe je unbound geconfigureerd hebt, als je unbound volgens deze guide hebt opgezet, hangt unbound wel degelijk aan het internet, en loop je daarmee wel degelijk een groot security risk. Unbound heeft versie 1.9.6 uitgebracht (zie versies) NA een security audit, waar een groot aantal problemen mee aan het licht gebracht werden. Alle versies, lager dan 1.9.6, zijn dus uitermate kwetsbaar voor de in die, en later uitgebrachte versies, bugs.

Als je unbound hebt geconfigureerd (dat kan ook) om alleen OpenDNS als upstream resolver te gebruiken, vraag ik me af wat het nut van unbound nog is, als je dat even wil verduidelijken, leren we misschien nog iets bij. Zelfs in dat geval hangt unbound nog aan het internet, dat is nu eenmaal vrijwel het enige doel van unbound (DNS info opvragen bij externe resolvers).

[beerns]

@jpgview ik heb inderdaad die handleiding gevolgd. Ik gebruik voor alle interne systemen dus het ip van de Rasp.Pi als DNS. Daar achter hangt een USG, en op de USG staat als WAN Dns, OpenDNS als upstream.
En dat werkt prima volg mij, maar als ik een configuratie fout heb gemaakt; dan hoor ik dat natuurlijk graag.

En ja; ik wilde onlangs een paar keer updaten naar de nieuwste versie; maar mn rasp PI (ca 2 mnd geleden from scratch begonnen en dus een recente versie vh OS lijkt mij) verteld me me als ik apt-get update en dan apt full-upgrade doe (als SU); dan krijg ik momenteel geen updates (hoor). Dus als jij een betere manier weet hoe ik naar de meest recente versie kan upgraden; dan hoor ik dat heel graag

[beerns]

sjhgvr schreef op vrijdag 21 augustus 2020 @ 09:19:
[...]


Welke ? Ben zeer benieuwd

googleads.g.doubleclick.net is noodzakelijk voor de iPad app; klaverjassen. Zonder deze te whitelisten stopt het spel na 3 rondjes. Steevast kapt ie er dan mee. Dus dit voor het ip vd iPad in de whitelist en het draait weer.

Overigens @jpgview en @sjhgvr ; mn MAC maakt van medetweaker op eigen houtje medewerker..Sorry :-)

[ Voor 12% gewijzigd door beerns op 21-08-2020 10:09 ]

[jpgview]

beerns schreef op vrijdag 21 augustus 2020 @ 10:03:
@jpgview ik heb inderdaad die handleiding gevolgd. Ik gebruik voor alle interne systemen dus het ip van de Rasp.Pi als DNS. Daar achter hangt een USG, en op de USG staat als WAN Dns, OpenDNS als upstream.

Ik kan uiteraard verkeerd zijn, heb zelf geen ervaring met USG, wat ik ervan begrijp (link), is dat de USG als DNS forwarder wordt gebruikt, in jouw geval dus naar OpenDNS

de bedoeling van unbound als recursive resolver is net dat de DNS queries naar de DNS servers worden gestuurd die het antwoord hebben. e.g.

veronderstel query naar gathering.tweakers.net, wat doet unbound:
- vraagt aan de root servers: wie heeft info over net
- vraagt aan de net servers: wie heeft info over tweakers
- vraagt aan de tweaker server (of de server waar tweakers zijn DNS host): wat is IP voor gathering

wat is de winst: privacy. de DNS server van tweakers weet dat je gathering hebt bezocht, niemand anders weet dat. Als je later een query doet naar support.zyxel.eu zal ook weer alleen zyxel weten dat je support hebt bezocht, over je eerdere bezoek aan tweakers hebben ze geen informatie. Dit alles is relatief (privacy). Nadat je het IP van gathering.tweakers.net te pakken hebt, vraagt je browser content op van die site. Alle content passeert via je ISP, en de opgevraagde content informatie ( jouw IP en de site) is perfect zichbaar voor hen.

Door jouw setup laat je unbound dit process nu verlopen zoals beschreven, maar op het einde van de rit worden alle queries door de USG omgeleid naar OpenDNS, e.g. Nu weten OpenDNS en je ISP alles over je.

Unbound in jouw config doet:
client -> pihole-FTL -> unbound -> USG -> OpenDNS
unbound is hier totaal overbodig, heeft geen toegevoegde waarde en is een extra tussenstap die de boel alleen maar vertraagd, je zal hier weinig van merken, omdat pihole-FTL en unbound op dezelfde machine draaien, het gaat over milliseconden.
zelfs de DNS forwarder op de USG is overbodig, als je dan toch OpenDNS wil gebruiken:
client -> pihole-FTL -> OpenDNS

Misschien ben ik fout, correct me if I'm wrong, ik heb geen USG, maar de bedoeling van de eerder genoemde unbound guide is "verdeel en heers" (geen info naar één DNS server, maar de vraag stellen aan de DNS server die effectief het antwoord weet. De USG doet dat gewoon teniet, door alles door te sluizen naar OpenDNS.

[beerns]

Nee ik denk dat je hier fout gaat.
Mn internetverbinding (glas, fritzbox) staat in bridgemode. Al het verkeer wordt 1op1 doorgestuurd naar het ip vd usg. Dat is mn router.

Op een USG heb je mogelijkheid tot een custom Json file. Dat gebruik ik.
Daarvoor forceer ik (via DIG kan ik dat netjes testen, dus dig google.nl @8.8.8.8 en dan komt de reactie terecht op mn PI hole/Unbound ip) Ik forceer dus het verkeer netjes richting het juiste ip adres en daar wordt dus alles afgewikkeld. Zie ook hier voor wat info
De usg heeft een WAN DNS nodig om te functioneren.

Ik weet vrijwel zeker dat ik dit juist heb geconfigureerd.

maar dan heb ik aan jou de vraag, weet dat je vrij veel doet met Pi Hole / unbound; hoe kan ik een recente versie van de Unbound geïnstalleerd krijgen als mn apt-get upgrade zegt:
root@raspberrypi:/home/pi# apt-get update
Get:1 http://archive.raspberrypi.org/debian buster InRelease [32.6 kB]
Get:2 http://raspbian.raspberrypi.org/raspbian buster InRelease [15.0 kB]
Fetched 47.6 kB in 1s (57.6 kB/s)
Reading package lists... Done
root@raspberrypi:/home/pi# apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

[beerns]

en overigens, ik kan netjes zien in OpenDNS welke domeinen / ip adressen bezocht worden. Zet ik mn pi hole ff uit voor een dagje ;dan zie ik al het verkeer langs komen (en thats ok in dat geval) maar nu is er lettl NUL verkeer.
Mn pi hole is geconfigureerd om al het verkeer (ook van de chromecasts etc (dus de hardcoded devices)) lokaal te houden; en dat lukt mij. Dat weet ik zeker. En unbound is voor PI Hole / USG de DNS oplossing
ik gebruik OpenDNS puur als laatste redmiddel.

[jpgview]

beerns schreef op vrijdag 21 augustus 2020 @ 10:59:
maar dan heb ik aan jou, weet dat je vrij veel doet met Pi Hole / unbound; hoe kan ik een recente versie van de Unbound geïnstalleerd krijgen als mn apt-get upgrade zegt:

Alles wat met de buitenwereld communiceert moet je zelf compileren, vertrekkend van de source van de laatste versies. Raspbian word niet frequent genoeg geupdate (laatste update is alweer geleden van eind mei), en zelfs dan komt het niet altijd met de laatste versie van all packages.

[beerns]

ja; dat dus

[jpgview]

beerns schreef op vrijdag 21 augustus 2020 @ 11:19:
ja; dat dus

hier is een oude post, die je op weg zal helpen, kan de post niet meer updaten, dus versie nummer aanpassen…

This only works if unbount isn’t already on your system, uninstall & purge older versions before continuing!

let op, compiled unbound draait met chroot, dus alle filespecs in de unbound config file zijn relatief (dus b.v. niet root-hints: "/etc/unbound/root.hints" maar root-hints: "/root.hints"

[beerns]

@jpgview had ik ondertussen reeds gevonden; is idd voor een iets oudere versie. Ga er een keer mee aan de rommel. Toch blijf ik 't vd gekke vinden dat ze blijkbaar de repository niet ' gewoon ' een update kunnen / willen geven.

[Freee!!]

jpgview schreef op vrijdag 21 augustus 2020 @ 11:13:
[...
Alles wat met de buitenwereld communiceert moet je zelf compileren

En hoe veilig is de compiler
Lees voor de grap dit maar eens.

[ed1703]

beerns schreef op vrijdag 21 augustus 2020 @ 11:51:
@jpgview had ik ondertussen reeds gevonden; is idd voor een iets oudere versie. Ga er een keer mee aan de rommel. Toch blijf ik 't vd gekke vinden dat ze blijkbaar de repository niet ' gewoon ' een update kunnen / willen geven.

Dat komt omdat Debian een bepaalde manier van werken heeft. Want daar is raspbian wel van afhankelijk.
De CVE's zijn wel verwerkt in de laatste stable versie.

Er staat je verder ook niets in de weg om te gaan backporten
Maar dan heb je wel vaak issues met andere packages en komt compilen van source al vaak in beeld.

https://packages.debian.org/buster-backports/unbound

[Pietervs]

htca schreef op donderdag 20 augustus 2020 @ 20:02:
[...]


Vragen voor hier;

• ik gebruik de default lijsten die mee kwamen bij de installatie, die lijken ok voor nu, of zijn absoluut lijsten die ik zou moeten gebruiken. Ik heb 3 pubers hier in huis... maw gezeik als het internet het (deels) niet doet, wel een bedankje voor de "reclamevrije browser ervaring"
• ik lees met interesse de unbound opties; ik twijfel om deze aan te zwengelen. Wat zijn jullie ervaringen?

1. Voeg in ieder geval https://dbl.oisd.nl toe. Andere lijsten zijn naar smaak toe te voegen, maar oisd.nl is een hele fijne blocklist (vind ik)
2. ik heb een tijdje tegen het installeren van unbound aan zitten hikken. Komt er feitelijk op neer: gewoon doen Geen merkbare vertraging (in tegendeel, ik heb het idee dat sommige sites zelfs sneller reageren). Ik gebruik twee Raspberry Pi's (redundancy, altijd fijn ) maar merkte wel dat het het makkelijkst werkt als je de versie uit de repository installeert. Ik heb nog even zitten klungelen met een handmatige installatie, maar dat gaf wel wat rare dingen. Dus die er weer afgegooid en teruggegaan naar de repository. Als je de handleiding volgt is het eigenlijk een peulenschilletje.

[htca]

hp-got schreef op vrijdag 21 augustus 2020 @ 09:20:
[...]

Tegen welke gevaren wil je je beschermen?
- privacy? De ISP / DNS provider / .... die ziet welke queries je doet?
- DNS poisoning?
Het antwoord op die vragen bepaalt of Unbound iets toevoegt in jouw situatie.

Ik heb pihole geïnstalleerd om reclame te filteren en tracking te voorkomen. Ik had zelf het idee dat unbound voordelen heeft ten aanzien van een lokale DNS en de caching verzorgd. In mijn geval is de DNS provider ook mijn ISP en wat ik van hen zie in de support sfeer doet mij het ergste vrezen voor de stabiliteit van het internet service die ze leveren (regelmatig ook storingen). Maar of ze daarmee een bedreiging vormen voor mijn privacy kan ik niet zo goed beoordelen, maar better safe than sorry....
in de reactie van @jpgview lees ik dat unbound volgens deze handleiding een gevaar betekent.

Wat netwerken betreft ben ik redelijk "novice" zeg maar. Maar probeer het wel zo veilig mogelijk te doen. Toen ik van de week iemand tijdelijk via sftp toegang gaf tot een afgezonderde map op mijn synology en blocking (geactiveerd voor ip adressen die 10x tevergeefs proberen in te loggen) binnen een aantal minuten een groot aantal ip-adressen rapporteerde weet je meteen weer waarom je eea veilig moet doen en niet "zomaar" dingen moet doen. Ik probeer te leren, dus vergeef me als ik domme vragen stel.....

[hp-got]

htca schreef op vrijdag 21 augustus 2020 @ 14:06:
[...]
in de reactie van @jpgview lees ik dat unbound volgens deze handleiding een gevaar betekent.

Dat heb ik ook gelezen.
Vervolgens heb ik me even verdiept in de Security Advisories van Unbound.
Het zou natuurlijk veel fijner zijn als er geen enkele bug in zat, maar ik ga daar toch niet minder van slapen

Het alternatief is zelf compileren of een backport gebruiken, maar met mijn vaardigheden met Linux weet ik waar dat op uit gaat lopen, dat wordt een drama....

[ed1703]

hp-got schreef op vrijdag 21 augustus 2020 @ 14:23:
[...]

Dat heb ik ook gelezen.
Vervolgens heb ik me even verdiept in de Security Advisories van Unbound.
Het zou natuurlijk veel fijner zijn als er geen enkele bug in zat, maar ik ga daar toch niet minder van slapen

Het alternatief is zelf compileren of een backport gebruiken, maar met mijn vaardigheden met Linux weet ik waar dat op uit gaat lopen, dat wordt een drama....

Mis ik hier iets mbt CVE's?

unbound (1.9.0-2+deb10u2) buster-security; urgency=high

* Apply NLnet Labs patch for CVE-2020-12662, CVE-2020-12663

-- Robert Edmonds <[e-mail]> Mon, 25 May 2020 16:23:43 -0400

apt-cache policy unbound
Version table:
1.9.0-2+deb10u2 500
500 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages

[hp-got]

ed1703 schreef op vrijdag 21 augustus 2020 @ 14:33:
[...]

Mis ik hier iets mbt CVE's?
[...]

Ik weet niet of je iets mist.

Misschien ben ik wel te naïef?

Waar ben je bang voor, wat is het ergste dat er kan gebeuren als je Unbound met deze CVE's op een RPi / Pihole draait?

[ed1703]

hp-got schreef op vrijdag 21 augustus 2020 @ 14:39:
[...]

Ik weet niet of je iets mist.

Misschien ben ik wel te naïef?

Waar ben je bang voor, wat is het ergste dat er kan gebeuren als je Unbound met deze CVE's op een RPi / Pihole draait?

Ik kan mij niet onttrekken aan het gevoel dat men hier het versienummer relateerd aan of er wel of niet bugs in zitten. Debian patched echter gewoon in de laatste stable (buster). Raspbian vaart daar gewoon in mee. De laatste bugs uit Mei 2020 zijn namelijk gewoon gefixed via een patch.

[hp-got]

ed1703 schreef op vrijdag 21 augustus 2020 @ 14:45:
[...]

Ik kan mij niet onttrekken aan het gevoel dat men hier het versienummer relateerd aan of er wel of niet bugs in zitten. Debian patched echter gewoon in de laatste stable (buster). Raspbian vaart daar gewoon in mee. De laatste bugs uit Mei 2020 zijn namelijk gewoon gefixed via een patch.

Ik heb dat vaker gehoord / gelezen en ik neem graag aan dat het waar is.

Het 'probleem' is dat ik niet eenvoudig kan verifiëren welke kwetsbaarheden van welk package in welke Raspbian enz. opgelost zijn.
Misschien kan het wel maar weet ik de weg niet.....

[ed1703]

hp-got schreef op vrijdag 21 augustus 2020 @ 14:55:
[...]


Ik heb dat vaker gehoord / gelezen en ik neem graag aan dat het waar is.

Het 'probleem' is dat ik niet eenvoudig kan verifiëren welke kwetsbaarheden van welk package in welke Raspbian enz. opgelost zijn.
Misschien kan het wel maar weet ik de weg niet.....

Als je stable draait van Raspbian (buster dus) kun je gewoon op de package-site van debian zoeken:

https://packages.debian.org/buster/unbound

Rechts staat een link met de changelog:

Unbound (1.9.0-2+deb10u2) buster-security; urgency=high

* Apply NLnet Labs patch for CVE-2020-12662, CVE-2020-12663

Doe op je pihole Raspberry:

apt-cache policy unbound

unbound:
Installed: (none) <-- hier staat bij jou de geinstalleerde versie
Candidate: 1.9.0-2+deb10u2
Version table:
1.9.0-2+deb10u2 500
500 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages

Duidelijk?

Draai je ouder, dan patchen ze alleen zeer kritieke CVE's

[ Voor 3% gewijzigd door ed1703 op 21-08-2020 15:08 ]

[hp-got]

ed1703 schreef op vrijdag 21 augustus 2020 @ 15:05:
[...]

Als je stable draait van Raspbian (buster dus) kun je gewoon op de package-site van debian zoeken:
[...]
Duidelijk?

Handig zo'n wegwijzer, dank je!

Ik was hier niet opgekomen, alleen al omdat in mijn begrip Raspbian != Debian, ik zou dus bij Raspbian blijven zoeken en nergens uitkomen

Maar goed, blijkbaar werkt het hier zo en, belangrijker, zijn de bekende kwetsbaarheden in Unbound verholpen dus is er niks aan de hand.

[nero355]

jpgview schreef op vrijdag 21 augustus 2020 @ 09:27:
Ik weet niet hoe je unbound geconfigureerd hebt, als je unbound volgens deze guide hebt opgezet, hangt unbound wel degelijk aan het internet, en loop je daarmee wel degelijk een groot security risk.

Unbound doet daar alleen een Client spelen dus hoezo hangt die aan het internet volgens jou als er vervolgens niet één poort is doorgemapped vanaf de WAN kant of dat ding niet in een DMZ hangt

Unbound heeft versie 1.9.6 uitgebracht (zie versies) NA een security audit, waar een groot aantal problemen mee aan het licht gebracht werden. Alle versies, lager dan 1.9.6, zijn dus uitermate kwetsbaar voor de in die, en later uitgebrachte versies, bugs.

Zoals meerdere mensen al hebben uitgelegd : Dat zegt niet zoveel, want men patched gewoon oudere versies net als ze dat deden met DNSmasq destijds onder oudere *Bian versies

Zaai alsjeblieft niet onnodig paniek!

htca schreef op donderdag 20 augustus 2020 @ 20:02:
[...]

Paar avondjes klussen maar dan heb je ook wat.... Domoticz vanuit de backup teruggezet en weer draaien. Maar op de een of andere manier kreeg ik de DHCP van pihole niet stabiel, dus weer terug gegaan naar DHCP op de router maar een DNS server op pihole en een op het adres van de router... dan maar de kans dat een aantal request niet zouden worden worden, maar de berusting die ik dacht te vinden vond ik niet....

Toen viel mijn oog op een AP (of eigenlijk de voormalige router van mijn partner).... Sinds een paar jaar hebben mijn partner en ik een gezamenlijk huishouden en moesten er 2 huishoudens worden samengevoegd. "grappig" dacht ik destijds "we hebben precies dezelfde router".... (toen al een hoop shit, want we hadden allebei de default SSID gehandhaaft....)
Maar laat zij nou en RT-N66U hebben en ik een RT-AC66U hebben (en de RT-AC66U in gebruik gehouden als router en de N66U als AP ingesteld)... en de eerste wel ondersteund worden door Merlin en de tweede niet....

Anyway; de RT-N66U geflasht ingesteld als DHCP, de verse domoticz pi voorzien van de pihole software en de boel weer opgestart en jawel; 2 velden voor een DNS server in de LAN settings op de router.
Restte alleen nog de openvpn en de dns daarin ook meegeven....
#happyuser

NICE!!!

ik lees met interesse de unbound opties; ik twijfel om deze aan te zwengelen. Wat zijn jullie ervaringen?

Gewoon doen!

[Tolstoi]

Ik wil graag YouTube advertenties blokken op de Chromecast en daarom ben ik van plan om pi-hole op mijn Synology nas te installeren.

Kan deze opzet redelijk eenvoudig werken en/of vereist het veel onderhoud?

Ik ben ook op zoek naar een goede tutorial/handleiding om dit alles op te zetten.

[ Voor 21% gewijzigd door Tolstoi op 21-08-2020 18:56 ]

[Pierre]

Tolstoi schreef op vrijdag 21 augustus 2020 @ 18:51:
Ik wil graag YouTube advertenties blokken op de Chromecast en daarom ben ik van plan om pi-hole op mijn Synology nas te installeren.

Kan deze opzet redelijk eenvoudig werken en/of vereist het veel onderhoud?

Ik ben ook op zoek naar een goede tutorial/handleiding om dit alles op te zetten.

Ik wens je veel succes met advertenties blokken op YouTube, ik heb intussen de moed op gegeven. Dan maar wachten en niet kijken naar de advertenties.

[jpgview]

nero355 schreef op vrijdag 21 augustus 2020 @ 17:26:
Unbound doet daar alleen een Client spelen dus hoezo hangt die aan het internet volgens jou als er vervolgens niet één poort is doorgemapped vanaf de WAN kant of dat ding niet in een DMZ hangt

Leuk dat je er zo over denkt. Alles wat ik (en vele anderen) gebruiken zijn clients. Ik (en vele anderen) heb niet één poort doorgemapt vanaf de WAN. Dat wil alleen maar zeggen dat ze na een port scan geen open poorten vinden, die ze vervolgens zouden kunnen benutten voor een aanval.

Telkens wanneer een client (dus ook unbound) een request verzend, komt er ook een antwoord. Dat antwoord is niet altijd even vriendelijk bedoeld. Zodra je, naast het up to date houden van al je software, ook nog software zoals SNORT of SURICATA gebruikt, merk je pas hoeveel aanvals pogingen er per dag plaats vinden.
Zelf draai ik SURICATA op pfsense, met de ETOpen emerging Threats rules en de snort rules. In die rules (je gebruikt alleen die rules die op jouw omgeving van toepassing zijn) zit o.a. een categorie emerging-dns rules. Die rule set gebruik ik, en resulteerd dagelijks in tientallen blocked packets (die dus de client nooit bereiken, maar dat wel zouden doen, zonder SURICATA). Waarschijnlijk zitten er in unbound ook wel een aantal checks ingebouwd, om te voorkomen dat er foute dingen gebeuren, naar aanleiding van foute antwoorden. Zeggen dat unbound dus niet beschermd en up to date moet zijn, omdat het uitsluitend een client is, is aan mij in ieder geval niet besteed.

Dit gezegd zijnde, iedereen doet wat hij/zij wil. Als users tevreden zijn met de met Raspbian geleverde versie van unbound, prima. Zelf heb ik al heel lang geleden beslist om unbound te compileren, o.a. om features te kunnen gebruiken, die in de Raspbian distro versie van unbound gewoon niet beschikbaar waren (ondertussen is die specifieke feature uiteraard wel beschikbaar). Eens je weet hoe het moet, is het een kleine moeite om het systeem up to date te houden met de meest recente versie.

nero355 schreef op vrijdag 21 augustus 2020 @ 17:26:
Zaai alsjeblieft niet onnodig paniek!

Aanbevelen om internet connected software up to date te houden != paniek zaaien.

[nero355]

jpgview schreef op vrijdag 21 augustus 2020 @ 19:50:
Telkens wanneer een client (dus ook unbound) een request verzend, komt er ook een antwoord. Dat antwoord is niet altijd even vriendelijk bedoeld.

Uiteraard, maar dan moet er maar net iemand weten dat jij bepaalde software gebruikt, waar die naartoe connect, enz...

Zodra je, naast het up to date houden van al je software, ook nog software zoals SNORT of SURICATA gebruikt, merk je pas hoeveel aanvals pogingen er per dag plaats vinden.

Zet maar eens een SSH of HTTP/HTTPS poortje open en het is al feest inderdaad!

En je router wordt sowieso met allerlei meuk bestookt

Zelf draai ik SURICATA op pfsense, met de ETOpen emerging Threats rules en de snort rules. In die rules (je gebruikt alleen die rules die op jouw omgeving van toepassing zijn) zit o.a. een categorie emerging-dns rules. Die rule set gebruik ik, en resulteerd dagelijks in tientallen blocked packets (die dus de client nooit bereiken, maar dat wel zouden doen, zonder SURICATA). Waarschijnlijk zitten er in unbound ook wel een aantal checks ingebouwd, om te voorkomen dat er foute dingen gebeuren, naar aanleiding van foute antwoorden.

Leuk, maar overkill voor 99% van de gebruikers hier

Zeggen dat unbound dus niet beschermd en up to date moet zijn, omdat het uitsluitend een client is, is aan mij in ieder geval niet besteed.

Dat zeg ik dan ook niet, maar als je over dingen als zelf compilen begint vanwege geen vertrouwen in de software en dergelijke dan krijg ik daar best wel wat momentjes van...

Dit gezegd zijnde, iedereen doet wat hij/zij wil. Als users tevreden zijn met de met Raspbian geleverde versie van unbound, prima. Zelf heb ik al heel lang geleden beslist om unbound te compileren, o.a. om features te kunnen gebruiken, die in de Raspbian distro versie van unbound gewoon niet beschikbaar waren (ondertussen is die specifieke feature uiteraard wel beschikbaar). Eens je weet hoe het moet, is het een kleine moeite om het systeem up to date te houden met de meest recente versie.

Ik deed al iets van 15 jaar geleden of zo uitsluitend via cvsup en de ports tree van FreeBSD mijn systeem onderhouden dus een probleem zou het niet zijn, echter draait alles op een Pi en om nou daarop alles te gaan compilen elke keer... ehh... NEE

Aanbevelen om internet connected software up to date te houden != paniek zaaien.

Nogmaals : Daar is niks mis mee!

De manier waarop je het brengt wel... Vooral voor de minder ervaren gebruikers!

* nero355 is daar ook weleens aan schuldig, maar probeert het een beetje in de gaten te houden

[ed1703]

jpgview schreef op vrijdag 21 augustus 2020 @ 19:50:
[...]
Dit gezegd zijnde, iedereen doet wat hij/zij wil. Als users tevreden zijn met de met Raspbian geleverde versie van unbound, prima. Zelf heb ik al heel lang geleden beslist om unbound te compileren, o.a. om features te kunnen gebruiken, die in de Raspbian distro versie van unbound gewoon niet beschikbaar waren (ondertussen is die specifieke feature uiteraard wel beschikbaar). Eens je weet hoe het moet, is het een kleine moeite om het systeem up to date te houden met de meest recente versie.

Prima hoor. Alleen is dat wel hoe het debian/raspbian systeem werkt. Een package met compleet nieuwe features komt nooit een stable versie in. Simpelweg omdat zoiets in testing moet gebeuren en als je geluk hebt in debian raspbian 11. Patches dus wel.

Aanbevelen om internet connected software up to date te houden != paniek zaaien.

Paniek zaaien is ook wel wat overdone, wel heb ik even de moeite genomen om recht te zetten dat debian versies (en dus ook raspbian) ongepatched zouden zijn. Dat is niet zo, men hoogt alleen de updateversie op en patched dus de huidige versie.
Dat lijkt heel onlogisch maar is het niet, want je hebt namelijk alle features van die versie met de updates qua bugs van de complete software.

[ Voor 5% gewijzigd door ed1703 op 21-08-2020 20:48 ]

[deHakkelaar]

jpgview schreef op vrijdag 21 augustus 2020 @ 19:50:
Aanbevelen om internet connected software up to date te houden != paniek zaaien.

Dat is wel een beetje paniek zaaien.
Als er belangrijke updates nodig zijn worden die zeker ge-backport.
En er is een rede waarom je vaak niet de laatste versie in de stable repositories ziet.
De laatste versie hoeft helemaal niet stabiel te zijn.
Dat wijst zich pas uit na een poosje testen.
En met de laatste versie kunnen er ook beveiligings risicos in sluipen.
Daarom zie je meestal niet de laatste versies in de stable repositories voor de meeste distros.

EDIT: oops ik zag de posting van ed1703 niet met een beetje de zelfde strekking.

[ Voor 5% gewijzigd door deHakkelaar op 22-08-2020 01:29 ]

[deHakkelaar]

nero355 schreef op vrijdag 21 augustus 2020 @ 20:04:
Zet maar eens een SSH of HTTP/HTTPS poortje open en het is al feest inderdaad!

Het is rustig de laatste tijd met brute force pogingen op SSH:

code:

$ fail2ban-client status ssh
Status for the jail: ssh
|- filter
|  |- File list:        /var/log/auth.log
|  |- Currently failed: 0
|  `- Total failed:     12
`- action
   |- Currently banned: 0
   |  `- IP list:
   `- Total banned:     1

Dat was een jaartje geleden wel anders met gemiddeld 10 bans ongeveer.

[jpgview]

ed1703 schreef op vrijdag 21 augustus 2020 @ 14:33:
unbound (1.9.0-2+deb10u2) buster-security; urgency=high

* Apply NLnet Labs patch for CVE-2020-12662, CVE-2020-12663

Nogmaals, iedereen doet waar hij/zij zin in heeft. Wil je de versie uit Raspbian of andere distros gebruiken, fine by me.

Aangezien Raspbian blijkbaar versie 1.9.0 gebruikt, heb ik even op deze pagina onderaan op toggle older versions geclicked, en een blik geworpen op de entries van het changelog tussen 1.11.0 en 1.9.0. Als ik daar de CVE entries (including duplicates) tel, is de count = 6. Een search op fix levert dit 260 matches op

Ik begrijp uit alle bovenstaande verklaringen dat de CVEs opgelost worden door releases zoals 1.9.0-2+deb10u2 en via apt-get update o.a.de unbound versie van de Raspbian distro updaten, e.g. bescherming bieden tegen deze vulnerabilities (CVEs).

Ik ga er dan vanuit dat alle fixes, die niet onder de noemer CVE vallen, niet in de Raspbian versie worden opgenomen. Een aantal van die fixes zijn cosmetic, of niet van toepassing op de raspbian distro, echter een noemenswaardig aantal van de fixes lossen wel degelijk real life problemen op; als ik b.v. zoek op memory leak, vind ik opnieuw 9 hits, waarvan een aantal op mijn systeem wel degelijk impact hebben.

Een user die een basic configuratie gebruikt (zie guide) zal hier allemaal weinig hinder van ondervinden, zodra je de unbound config begint te optimaliseren, word het een ander verhaal.
Vraag is of die users uberhaupt dit, of andere forums volgen (en dan "panikeren" bij het lezen van mijn entries), meestal komen ze pas op het forum te voorschijn, als er een probleem met hun installatie is, dat zie je ook aan de kwaliteit van de vragen die gesteld worden (het debug log, waar door de moderators om gevraagd word, bevat gelijk ook de oplossing voor het probleem).

deHakkelaar schreef op zaterdag 22 augustus 2020 @ 01:16:
En er is een rede waarom je vaak niet de laatste versie in de stable repositories ziet.
De laatste versie hoeft helemaal niet stabiel te zijn.
Dat wijst zich pas uit na een poosje testen.
En met de laatste versie kunnen er ook beveiligings risicos in sluipen.
Daarom zie je meestal niet de laatste versies in de stable repositories voor de meeste distros.

Voor mij is dit een twee maten / twee gewichten verhaal. Het is, met deze redenering, dus OK om unbound niet te updaten, e.g. slaafs de distro volgen, maar zodra er een nieuwe versie is van pihole, begint iedereen onmiddelijk te updaten, want er zou eens een nieuw leuk item in de web interface kunnen zitten …

pihole v5.0 is uitvoerig getest in het beta stadium, zelfs daar zaten nog probleempjes in de final release, de nieuwere versies zijn gereleased zonder beta faze. Het argument dat verschilende branches, met nieuwe features wel getest worden (pihole checkout …), is een non-argument in dit verhaal, deze branches bevatten oplossingen voor een specifiek probleem en worden door zeer weinig gebruikers ook effectief getest (lees de feedback / testresultaten) op discourse.

Als de laatste nieuwe versie van unbound problemen geeft, is het een kleine moeite om een stap terug te zetten, bij pihole is dit vrijwel onmogelijk. Als je dus aanraad de stable version van unbound uit de distro te gebruiken, moet je dezelfde argumentatie gebruiken om pihole pas na x aantal weken / maanden te updaten, hopende dat je met die update niet plotseling twee versies vooruit gaat…

Mijn samenvatting: Als je Raspbian + pihole (curl -sSL https://install.pi-hole.net | bash) + unbound (guide) opzet, en daarmee tevreden bent, prima, geen commentaar. Beweren dat dit de meest performante, trouble free, secure oplosssing is, dat is voor mij een stap te ver. Het is hooguit een oplossing die op de meeste devices een paar ads en trackers zal blocken, en daarmee de meeste gebruikers een voldaan en vals gevoel van veiligheid en privacy geven.

[ed1703]

jpgview schreef op zaterdag 22 augustus 2020 @ 11:32:
[...]

Voor mij is dit een twee maten / twee gewichten verhaal. Het is, met deze redenering, dus OK om unbound niet te updaten, e.g. slaafs de distro volgen, maar zodra er een nieuwe versie is van pihole, begint iedereen onmiddelijk te updaten, want er zou eens een nieuw leuk item in de web interface kunnen zitten …

Met deze opmerking veeg je de workload waar het securityteam van debian dagelijks mee bezig is, compleet van tafel. Want je vergeet namelijk alle afhankelijkheden in de software mee te nemen.

Compile je dan ook alle dependencies van unbound? Hoort er ook bij he.. zitten ook bugs in

Het is helemaal niet gezegd dat je van alle bugs die NLnetlabs in z'n changelog heeft staan last hebt, want wanneer zijn deze bugs ontstaan? Welke afhankelijkheden met andere packages hebben deze bugs? Om dat dagelijks uit te zoeken kun je bijna op afstuderen. Nog afgezien van het feit dat unbound multi-os is, dus van een flink aantal bugs heb je helemaal geen last.

En altijd maar de laatste versie draaien is geen garantie voor een secure systeem, alleen al omdat de maintainer niet alle os-en en variaties van die os-en test. Dat kun je ook niet verwachten.
Daarvoor hebben we dus ook iets moois om dat te tackelen en dat heet github, zodat je actief kunt meehelpen. Zelf doe je dat al deels.

[ Voor 15% gewijzigd door ed1703 op 22-08-2020 13:26 ]

[deHakkelaar]

jpgview schreef op zaterdag 22 augustus 2020 @ 11:32:
Beweren dat dit de meest performante, trouble free, secure oplosssing is, dat is voor mij een stap te ver.

ed1703 troeft me weer af.
Ik wou ook vragen idd ofdat je de kernel en iproute2 zelf compilieert van laatste sources ?
Als het weer eens fout gaat ben je weer uren zoet met problemen oplossen.
Dat kan voor een boel gebruikers een negatieve ervaring opleveren.
Het kan ook soms problemen opleveren met support als jouw systeem afwijkt van al die anderen.
Ik doe het niet ... ik heb wel wat beters te doen

[Freee!!]

deHakkelaar schreef op zaterdag 22 augustus 2020 @ 13:17:
[...]
Ik wou ook vragen idd ofdat je de kernel en iproute2 zelf compilieert van laatste sources ?

Ik zou vragen of hij de compiler ook zelf compileert en dan de compiler-listing en binary controleert.

[Toet3r]

Ik heb een probleem waar ik na veel zoeken wel de oorzaak van gevonden heb maar nog niet de oplossing.

In pi-hole webinterface bij setttings - DNS - interface listening behavior
staat ie op listen to all interfaces krijg wel connectie via wireguard vpn maar heb ik geen internet op vlans anders dan die waar mijn pi hole in zit.
Zet ik hem op listen only on interface eth0 krijg ik geen verbinding via wireguard vpn maar heb wel internet op de vlans in mijn netwerk.

Ik was maar aan het zoeken in mijn router firewall regels of daar iets verkeerd stond, geen wonder dat ik het niet kon vinden. is iemand bekend met dit verschijnsel? Kan zo niet vinden hoe dit op te lossen zodat beide werken.

[Freee!!]

Toet3r schreef op zaterdag 22 augustus 2020 @ 17:16:
Ik heb een probleem waar ik na veel zoeken wel de oorzaak van gevonden heb maar nog niet de oplossing.

In pi-hole webinterface bij setttings - DNS - interface listening behavior
staat ie op listen to all interfaces krijg wel connectie via wireguard vpn maar heb ik geen internet op vlans anders dan die waar mijn pi hole in zit.
Zet ik hem op listen only on interface eth0 krijg ik geen verbinding via wireguard vpn maar heb wel internet op de vlans in mijn netwerk.

Ik was maar aan het zoeken in mijn router firewall regels of daar iets verkeerd stond, geen wonder dat ik het niet kon vinden. is iemand bekend met dit verschijnsel? Kan zo niet vinden hoe dit op te lossen zodat beide werken.

Meer info nodig, Pi-Hole in Docker met macvlan

[Toet3r]

@Freee!!

Nee, heb pihole en pivpn gewoon in Rapsberry Pi OS geïnstalleerd.

[Freee!!]

Toet3r schreef op zaterdag 22 augustus 2020 @ 18:31:
@Freee!!

Nee, heb pihole en pivpn gewoon in Rapsberry Pi OS geïnstalleerd.

Dan zou ik het niet weten, ik ken de beperkingen van macvlan op dat gebied en weet de weg daaromheen.

[htca]

@Toet3r geef je het DNS adres actief mee in pivpn aan je clients? ik moes dat pushen...

[Toet3r]

@htca
Tijdens installatie van pivpn detecteert ie pihole en wordt gevraagd of ik pihole ook wil gebruiken voor pivpn clients. Verder heb ik geen instellingen veranderd, alleen client profiles aangemaakt.

[htca]

wat krijg je in openvpn.log als je de client connect?

[Toet3r]

Heb het gevonden.
Met dank aan deze post https://www.reddit.com/r/...en_set_to_listen_only_on/

Heb in /etc/dnsmasq.d/05-custom.conf

interface=wg0

toegevoegd. reboot en het werkt

[nero355]

Toet3r schreef op zaterdag 22 augustus 2020 @ 20:32:
Heb het gevonden.
Met dank aan deze post https://www.reddit.com/r/...en_set_to_listen_only_on/

Heb in /etc/dnsmasq.d/05-custom.conf

[...]
toegevoegd. reboot en het werkt

Dat is best wel gek, want dat hoort PiVPN voor je te doen tijdens de installatie als ik me niet vergis

Daarnaast staat die optie al een aantal keer in dit topic vermeld voor zowel VPN als VLAN/extra interfaces gebruik!

[TFHfony]

Ik zie in mijn PiHole logs dat localhost (dus de Raspberry Pi zelf) stipt om het hele uur binnen een seconde of 2 zo'n 90 DNS aanvragen de deur uit doet, allemaal van het type PTR. Grotendeels hele rare zoals 2.e.c.8.9.d.f.9.7.b.d.8.c.d.5.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa welke dan ook een NXDOMAIN vanuit de cache krijgen, maar ook een aantal zoals 8.8.8.8.in-addr.arpa & 8.8.8.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpa welke vanuit de cache een OK krijgen. De laatste lijken Google DNS gerelateerd, welke ik ook als DNS upstream provider heb ingesteld.
Iemand enig idee?

[jpgview]

TFHfony schreef op zondag 23 augustus 2020 @ 21:36:
Ik zie in mijn PiHole logs dat localhost (dus de Raspberry Pi zelf) stipt om het hele uur binnen een seconde of 2 zo'n 90 DNS aanvragen de deur uit doet, allemaal van het type PTR.

Elk uur probeert pihole-FTL de namen van de client devices op te lossen en deze in de database te updaten (database /etc/pihole/pihole-FTL.db / table network / field name). Waarschijnlijk heb je (Windows 10) devices die IPv6 gebruiken, privacy extentions enabled. Het Temporary IPv6 Address (ipconfig), dat je (Windows 10) computer gebruikt kan nooit resolved worden omdat er geen entry in de zone ip6.arpa zit. Omdat pihole-FTL echter altijd extern naar een naam zoekt, als er lokaal geen antwoord beschikbaar is, zal je die queries blijven zien, en het zullen er alleen maar meer worden, omdat de client (Windows 10) telkens, wanneer het device reboot een nieuw random Temporary IPv6 Address genereert.

Wanneer je aan /etc/pihole/pihole-FTL de setting DEBUG_RESOLVER=TRUE toevoegd (pihole-FTL herstarten om te activeren), kan je dit process volgen in /var/log/pihole-FTL.log, daar zal je ook zien dat pihole-FTL ook voor de ingestelde resolvers (bij jou 8.8.8.8) een reverse lookup uitvoert. Als je de resolver 8.8.8.8 in iets anders zou wijzigen, zie je ook een query voor de nieuwe gekozen resolver verschijnen.

Waarom doet pihole-FTL dit?
De IPv6 resverse lookups gebeuren om in de web interface (query log) een device name te kunnen tonen i.p.v. een IP address, De reverse lookup voor 8.8.8.8 gebeurt om in het dashboard de resolvernaam te kunnen tonen.

Om dit alles op te lossen, zijn er verschillende testen aan de gang, lees o.a. hier, hier en hier, of daarmee de PTR requesten (elk uur) zullen verdwijnen, valt nog af te wachten.

Er zijn, zoals gewoonlijk, verschillende meningen over het nut van de (Windows 10) privacy extensions, je kan dit uitschakelen (search duckduckgo).
Tweakers gebruikt ook IPv6, telkens wanneer ik opnieuw inlog, krijg ik een mail dat ik heb ingelogd op een nieuw device. Hier is het voor tweakers een koud kunstje om het Temporary IPv6 Address te koppelen aan mijn ID. Als ik echter een service gebruik, waar geen authentication vereist is, is het al veel moeilijker om het Temporary IPv6 Address te kopplelen aan mijn persoon (onmogelijk???). Zoals ik meestal aangeef, iedereen doet hiermee waar hij/zij zin in heeft.

[hp-got]

TFHfony schreef op zondag 23 augustus 2020 @ 21:36:
Ik zie in mijn PiHole logs dat localhost (dus de Raspberry Pi zelf) stipt om het hele uur binnen een seconde of 2 zo'n 90 DNS aanvragen de deur uit doet, allemaal van het type PTR.
[...]

Even in aanvulling op het uitgebreide verhaal van @jpgview:

Als al die reverse lookups in de statistieken je storen kan je in de instellingen aangeven dat je alleen A en AAAA queries wil zien.

De lookups gaan uiteraard gewoon door, maar ze komen dan niet meer in de statistiek terecht.

In de documentatie van Pi-hole staat onder Statistics settings hoe je dat doet: klik

[jpgview]

TFHfony schreef op zondag 23 augustus 2020 @ 21:36:
Ik zie in mijn PiHole logs dat localhost (dus de Raspberry Pi zelf) stipt om het hele uur binnen een seconde of 2 zo'n 90 DNS aanvragen de deur uit doet, allemaal van het type PTR.

Ik heb je 90 PTR queries vermeld, lees hier, in een topic dat al een tijdje loopt, blijkbaar was men verwonderd (de developers gebruiken geen windows 10), maar vond men het wel belangrijk genoeg om er in de toekomst iets aan te doen, lees hier.

Een oplossing is dus onderweg, timeframe onbekend...

[TFHfony]

Mag ik u allen bedanken voor de zeer uitgebreide uitleg!
Gewoon even wachten een nieuwe versie, dan komt het allemaal wel goed

[Henkske]

Allen,

Hierbij even mijn korte uitleg zoals ik het vandaag gedaan heb op mijn test ubuntu server. Ik zeg niet dat dit de juiste manier is maar het is misschien een hulpmiddel voor andere beginners zoals ik.

cd /opt/
sudo mkdir docker
sudo chmod -R 775 docker
cd /opt/docker
sudo mkdir etc-pihole
sudo mkdir etc-dnsmasqd
sudo nano /etc/resolv.conf -> add 8.8.8.8
docker network create --driver=macvlan --gateway=192.168.1.1 --subnet=192.168.1.0/24 --ip-range=192.168.1.238/32 -o parent=eno1 pihole

subnet 192.168.1.0/24 staat gelijk aan 255.255.255.0
gateway is router IP
parent=eno1 = netwerkkaart die verbinding maakt met inet. Te vinden met ifconfig
pihole= macvlan naam
192.168.1.238/32 is static ip die ik PIHOLE geef

sudo nano /opt/docker/docker-compose.yml

code:

version: '3.3'
services:
    pihole:
        container_name: pi-hole
        restart: always
        volumes:
            - '/opt/docker/config:/config'
            - '/opt/docker/dnsmasq:/dnsmasq'

        dns:
            - 1.0.0.1
            - 1.1.1.1
        environment:
            - DNS1=1.1.1.1
            - DNS2=1.0.0.1
            - ServerIP=192.168.1.238
            - DNSMASQ_LISTENING=all
            - WEBPASSWORD=test
            - TZ=Europe/Berlin
        network_mode: pihole
        image: 'pihole/pihole:latest'

docker-compose up -d
http://192.168.1.238/admin/

[ComTech]

Na het updaten van mijn Pi-Hole met sudo pihole -up blijf ik onderin de melding krijgen update available.

Pi-hole v5.0 · Update available! Web Interface v5.1.1 FTL v5.2.

Hoe kan ik zorgen dat hij volledig update of gaat er wat anders mis?

[nero355]

@ComTech : Gebruik je wel een browser met een lege Cache om dat te checken

Als dat niet helpt dan moet je effe op hun forum rondneuzen, want ik heb dat soort dingen wel vaker langs zien komen

[freestyler2]

Freee!! schreef op zaterdag 22 augustus 2020 @ 18:13:
[...]

Meer info nodig, Pi-Hole in Docker met macvlan

Hier een soortgelijke situatie. Pi hole in Docker op een synology. Heb je een work around?

[tdn135]

Ik krijg veel requests naar het domein "." van mijn lokale ip adres is 172.17.0.1. Ik heb pi-hole via docker draaien. Er zijn geen docker instanties die dit specifieke ip adres hebben, dus moet het wel de host zijn. Iemand enig idee hoe ik de requests naar het domein . er uit kan halen?