[Pi-Hole] Ervaringen & discussie

[Kopernikus.1979]

stormfly schreef op maandag 16 augustus 2021 @ 13:46:
[...]


Ik begrijp het knutselgehalte als Tweaker. 2x een PiHole DNS aan het OS meegeven via DHCP werkt toch ook? En eens per x periode de config eruit via de eerste pihole via teleporter en er weer in op de tweede pihole?

Hiervoor had ik AdGuard, zij hebben geen config export/import dat maakt het beheer wel serieus lastig.

Ben nog steeds op zoek naar het golden thing wat de complexe PiHole HA + config sync rechtvaardigt? Is het via pfSense te doen dat je verkeer redirect naar 2 servers, of kan je dat slechts naar 1?

Doe ik via keepalived, de config is niet echt complex.
Tutorial: https://jekhokie.github.i...ocking-with-failover.html

[nero355]

stormfly schreef op maandag 16 augustus 2021 @ 13:46:
Ik begrijp het knutselgehalte als Tweaker. 2x een PiHole DNS aan het OS meegeven via DHCP werkt toch ook? En eens per x periode de config eruit via de eerste pihole via teleporter en er weer in op de tweede pihole?

Het probleem is dat je dan haperingen kan krijgen als één van de twee down gaat...

Fun Fact : Ik geef 1 IP maar liefst 4 keer op in mijn DHCP config om eventuele alternatieve DNS Servers te overrulen!

Hiervoor had ik AdGuard, zij hebben geen config export/import dat maakt het beheer wel serieus lastig.

Dat is een vies woord hier!

Ben nog steeds op zoek naar het golden thing wat de complexe PiHole HA + config sync rechtvaardigt?

Het is gewoon de betere oplossing, maar vereist dus wel wat scripting en zo...

Is het via pfSense te doen dat je verkeer redirect naar 2 servers, of kan je dat slechts naar 1?

Volgens mij moet dat wel te doen zijn

Als het DNS verkeer niet naar IP #1 of #2 gaat dan routeren naar IP #1 of #2 lijkt me een redelijk verzoek van een Firewall ?!

Overigens heeft pfSense ook pfBlockerNG dus dat kan ook nog een optie zijn

[stormfly]

nero355 schreef op maandag 16 augustus 2021 @ 16:42:
[...]

Fun Fact : Ik geef 1 IP maar liefst 4 keer op in mijn DHCP config om eventuele alternatieve DNS Servers te overrulen!

Tell me more about it?

Volgens mij moet dat wel te doen zijn

Als het DNS verkeer niet naar IP #1 of #2 gaat dan routeren naar IP #1 of #2 lijkt me een redelijk verzoek van een Firewall ?!

Overigens heeft pfSense ook pfBlockerNG dus dat kan ook nog een optie zijn

Nee ik denk het niet, het IP redirect field in de NAT rule heeft maar een optie tot het invullen van één IP. Een regel eronder gaat niet matchen, toch? Ik redirect nu allen het verkeer wat niet naar mijn reguliere PiHole of Unbound servers loopt. Om de hardcoded DNS requests ook te filteren.

//lichtjes offtopic/// ik zag gisteren een youtube over een VPN killswitch, als de VPN down gaat dan mag dat verkeer niet terug failen over je reguliere WAN IP. Hij doet dat als volgt, hij geeft de redirect rule voor private internet access een tag mee "vpntraffic". Daarna maakt hij een direct match rule op de WAN port waarbij hij zegt: als je hier verkeer met de tag vpntraffic ziet -> direct blokkeren.

Ik had een beginnend idee, als ik die tag nu eens gebruik voor het redirecten van DNS, en die rule laat ik 2x matchen. Misschien kan je zelfs 2x taggen: tag:pihole1 tag:pihole2

Nou ja iets om verder over na te denken.

[ed1703]

stormfly schreef op maandag 16 augustus 2021 @ 13:46:
[...]


Ik begrijp het knutselgehalte als Tweaker. 2x een PiHole DNS aan het OS meegeven via DHCP werkt toch ook? En eens per x periode de config eruit via de eerste pihole via teleporter en er weer in op de tweede pihole?

Mee eens.. ik heb vooral in HA draaien zodat bij mij beide adressen alltijd online zijn.
Ik heb dus active <---> passive en passive <---> active draaien zeg maar. In DHCP staan 2 adressen geconfigureerd.
Omdat het kan ofzo. 1 Adres is eigenlijk genoeg, alleen staat er dan altijd een PI'tje uit z'n neus te eten.
Zo wat minder.

[ Voor 18% gewijzigd door ed1703 op 16-08-2021 17:32 ]

[nero355]

stormfly schreef op maandag 16 augustus 2021 @ 17:09:
Tell me more about it?

Mijn USG heeft 4 DNS Server hokjes en die vul ik dan allemaal in om onder andere te voorkomen dat Android telefoons stiekem de Google DNS Servers als 2de/3de/4de keuze gebruiken!

Nee ik denk het niet, het IP redirect field in de NAT rule heeft maar een optie tot het invullen van één IP. Een regel eronder gaat niet matchen, toch? Ik redirect nu allen het verkeer wat niet naar mijn reguliere PiHole of Unbound servers loopt. Om de hardcoded DNS requests ook te filteren.

Ik zou eens wat regels aanmaken en dan kijken of je die via config files kan finetunen

[GG85]

Allemaal al over op Debian Bullseye?

Gebruik zelf een mini-pc met DietPi ipv een RPi (geen gezeur meet SD kaartjes) en daar moest ik even handmatig de PHP versie op 7.4(?) zetten ipv op 7.3. voordat alles weer werkte.
Voor de rest heel soepel allemaal

[gastje01]

nero355 schreef op dinsdag 17 augustus 2021 @ 00:21:
[...]

Mijn USG heeft 4 DNS Server hokjes en die vul ik dan allemaal in om onder andere te voorkomen dat Android telefoons stiekem de Google DNS Servers als 2de/3de/4de keuze gebruiken!


[...]

Ik zou eens wat regels aanmaken en dan kijken of je die via config files kan finetunen

Werkt dat echt zo? Ik heb maar een Pi-Hole draaien en dus ook maar 1 server ingevuld, in mijn perceptie is dat dan ook de enige server die gebruikt wordt. Uitzondering is de ChromeCast, die heeft volgens mij GoogleDNS hardcoded en doet niets met de DNS servers die je via DHCP uitdeelt.

[Church of Noise]

GG85 schreef op dinsdag 17 augustus 2021 @ 09:25:
Allemaal al over op Debian Bullseye?

Gebruik zelf een mini-pc met DietPi ipv een RPi (geen gezeur meet SD kaartjes) en daar moest ik even handmatig de PHP versie op 7.4(?) zetten ipv op 7.3. voordat alles weer werkte.
Voor de rest heel soepel allemaal

M'n secundaire Pi Zero W draait al even Bullseye icm DietPi (beta), draait even vlot als de primaire op Buster.
Het zal wel nog even wachten worden op de Raspberry Pi OS 'implementatie' van Bullseye als ik de laatste communicaties goed begrepen heb (2-3 maand wordt geopperd).
Ik moet ook een specifieke command line gebruiken om Pi-Hole te updaten omdat ie Bullseye nog niet erkent.

code:

PIHOLE_SKIP_OS_CHECK=true sudo -E pihole -up

[nero355]

GG85 schreef op dinsdag 17 augustus 2021 @ 09:25:
Allemaal al over op Debian Bullseye?

Eerlijk gezegd hou ik dat echt heel slecht bij op mijn Raspberry Pi en zou ik niet weten wat ik nog erop heb draaien...

Als het goed is Buster en sinds ik Debian Bullseye Testing op mijn HTPC draai zou ik niet al teveel achter moeten lopen

gastje01 schreef op dinsdag 17 augustus 2021 @ 09:49:
Werkt dat echt zo?

Volgens meerdere ervaringen in dit topic : YUP!

Ik heb maar een Pi-Hole draaien en dus ook maar 1 server ingevuld, in mijn perceptie is dat dan ook de enige server die gebruikt wordt.

Het ligt er een beetje aan per apparaat, maar het kan geen kwaad om gewoon hetzelfde IP meerdere keren aan te bieden.

Wat ook weleens voorkomt : Routers die de 2de/3de/4de DNS IP gaan aanvullen met de 1ste/2de DNS Server IP aan de WAN kant als je die niet invult!

Uitzondering is de ChromeCast, die heeft volgens mij GoogleDNS hardcoded en doet niets met de DNS servers die je via DHCP uitdeelt.

Het ligt er een beetje aan hoe en wat :
- Mijn Nvidia Shield TV 2017 met ingebouwde Chromecast lijkt zich eraan te houden.
- De LG WebOS TV ook.

Zo'n Google Chromecast moet je echter voor de gek houden met DNAT/SNAT regels op je Router zodat al het verkeer richting 8.8.4.4 en 8.8.8.8 alsnog bij je Pi-Hole belandt

[Raven]

nero355 schreef op dinsdag 17 augustus 2021 @ 14:52:
[...]

Eerlijk gezegd hou ik dat echt heel slecht bij op mijn Raspberry Pi en zou ik niet weten wat ik nog erop heb draaien...

Als het goed is Buster en sinds ik Debian Bullseye Testing op mijn HTPC draai zou ik niet al teveel achter moeten lopen

* Raven heeft Raspbian 9 (Stretch) nog op een Pi draaien...
Nooit nodig gevonden bij te werken naar v10, plus PiHole is dan net als TVHeadend tijdje niet beschikbaar

Overigens is Buster (reguliere Debian) vrij snel bijgewerkt naar Bullseye, VM met Debian had er incl downloaden (~50MB/s) tussen 5 en 6m voor nodig. Daar kan MS wat van leren

[ Voor 14% gewijzigd door Raven op 17-08-2021 17:39 ]

[nero355]

Raven schreef op dinsdag 17 augustus 2021 @ 17:38:
* Raven heeft Raspbian 9 (Stretch) nog op een Pi draaien...
Nooit nodig gevonden bij te werken naar v10, plus PiHole is dan net als TVHeadend tijdje niet beschikbaar

F... Die hadden we ook nog! Dan is het bij mij ook Stretch

Overigens is Buster (reguliere Debian) vrij snel bijgewerkt naar Bullseye, VM met Debian had er incl downloaden (~50MB/s) tussen 5 en 6m voor nodig. Daar kan MS wat van leren

Laatst ook zitten timen op de HTPC met Debian Testing die al meerdere maanden niet was gebruikt/geüpdate : Binnen 15 minuten klaar en dat was dan zelfs nog i.c.m. een 2,5 inch HDD als OS Storage

Windows zou dan misschien net klaar zijn met downloaden...

[ed1703]

Raven schreef op dinsdag 17 augustus 2021 @ 17:38:
[...]

* Raven heeft Raspbian 9 (Stretch) nog op een Pi draaien...
Nooit nodig gevonden bij te werken naar v10, plus PiHole is dan net als TVHeadend tijdje niet beschikbaar

Overigens is Buster (reguliere Debian) vrij snel bijgewerkt naar Bullseye, VM met Debian had er incl downloaden (~50MB/s) tussen 5 en 6m voor nodig. Daar kan MS wat van leren

Weet ook niet wat raspberrypi.org van plan is met RaspiOS, want deze upgraden ook lopende een release in de 'main' sommige van de packages. Dat is bij een reguliere debian uit den boze.

[Raven]

nero355 schreef op dinsdag 17 augustus 2021 @ 17:56:
[...]

Laatst ook zitten timen op de HTPC met Debian Testing die al meerdere maanden niet was gebruikt/geüpdate : Binnen 15 minuten klaar en dat was dan zelfs nog i.c.m. een 2,5 inch HDD als OS Storage

Windows zou dan misschien net klaar zijn met downloaden...

offtopic:
15 minuten? Hell no , downloaden wordt telkens onderbroken door updateproces tiworker.exe die maar één core kan gebruiken

[R009]

Goeie avond,

Ik heb een heel raar probleem met mijn Raspberry Pi 3B+ waar Pi-Hole op draait. Op random tijdstippen stopt mijn internet met werken... Het enige wat dan helpt is de Pi zonder stroom te zetten, even te wachten en weer stroom te geven. Hieronder even de uitleg hoe ik mij Pi geconfigureerd heb.

Ik heb Raspbian Lite via de Raspberry Pi image op de SD-kaart geschreven. Daarna een ssh en een wpa_supplicant.conf file toegevoegd aan de root folder. Via SSH heb ik kunnen inloggen en daarna Pi-Hole geïnstalleerd.

Na de installatie kon ik inloggen op de admin pagina van de Pi-Hole, Daar heb ik enkel wat adlists toegevoegd en via de ssh de pihole -g commando laten lopen...

Verder ben ik naar mijn fritzbox router gegaan en daar via het menu Thuisnetwerk - Netwerk - Netwerkinstellingen de IPv4-adressen knop de Lokale DNS-server veranderd naar het IP adres van mijn Raspberry Pi. Na een ipconfig /release - /renew gaan mijn requests via de Raspberry Pi.
----------------

Zelf heb ik wat trouble shooting gedaan. Ik heb de SD kaart geformatteerd en Raspbian Lite weer geïnstalleerd. Verder heb ik ook een update en upgrade van de Pi gedaan. Ook de wpa_supplicant.conf file nog eens herbekeken en opnieuw toegevoegd.
Wanneer ik geen internet meer heb, heb ik ook de Lokale DNS-server op de fritzbox weer veranderd naar 192.168.1.1. Als ik dan het IP adres van mijn Raspberry Pi ping antwoord deze niet. Wel staat die in mijn router overzicht als verbonden.

Mijn gevoel is dat er soms iets vast loopt en zijn pedalen verliest op verschillende tijdstippen maar momenteel heb ik geen enkel idee wat er fout loopt. Hopelijk heeft iemand hier een idee.

[stormfly]

R009 schreef op dinsdag 17 augustus 2021 @ 21:44:
Goeie avond,

Ik heb een heel raar probleem met mijn Raspberry Pi 3B+ waar Pi-Hole op draait. Op random tijdstippen stopt mijn internet met werken... Het enige wat dan helpt is de Pi zonder stroom te zetten, even te wachten en weer stroom te geven. Hieronder even de uitleg hoe ik mij Pi geconfigureerd heb.

Ik heb Raspbian Lite via de Raspberry Pi image op de SD-kaart geschreven. Daarna een ssh en een wpa_supplicant.conf file toegevoegd aan de root folder. Via SSH heb ik kunnen inloggen en daarna Pi-Hole geïnstalleerd.

Na de installatie kon ik inloggen op de admin pagina van de Pi-Hole, Daar heb ik enkel wat adlists toegevoegd en via de ssh de pihole -g commando laten lopen...

Verder ben ik naar mijn fritzbox router gegaan en daar via het menu Thuisnetwerk - Netwerk - Netwerkinstellingen de IPv4-adressen knop de Lokale DNS-server veranderd naar het IP adres van mijn Raspberry Pi. Na een ipconfig /release - /renew gaan mijn requests via de Raspberry Pi.
----------------

Zelf heb ik wat trouble shooting gedaan. Ik heb de SD kaart geformatteerd en Raspbian Lite weer geïnstalleerd. Verder heb ik ook een update en upgrade van de Pi gedaan. Ook de wpa_supplicant.conf file nog eens herbekeken en opnieuw toegevoegd.
Wanneer ik geen internet meer heb, heb ik ook de Lokale DNS-server op de fritzbox weer veranderd naar 192.168.1.1. Als ik dan het IP adres van mijn Raspberry Pi ping antwoord deze niet. Wel staat die in mijn router overzicht als verbonden.

Mijn gevoel is dat er soms iets vast loopt en zijn pedalen verliest op verschillende tijdstippen maar momenteel heb ik geen enkel idee wat er fout loopt. Hopelijk heeft iemand hier een idee.

Is je Pi verbonden met WiFi, je clients via WiFi halen hun DNS op via de Pi welke ook op WiFi aangesloten zit?

Ik zou zorgen dat de Pi met een UTP kabel in je router komt.

[R009]

stormfly schreef op dinsdag 17 augustus 2021 @ 22:14:
[...]


Is je Pi verbonden met WiFi, je clients via WiFi halen hun DNS op via de Pi welke ook op WiFi aangesloten zit?

Ik zou zorgen dat de Pi met een UTP kabel in je router komt.

Hoi Wopper,

Inderdaad alles is verbonden via WiFi. Spijtig genoeg kan ik geen UTP kabel meer verbinden. Alle poorten zijn al in gebruikt genomen door apparaten zoals een alarm, NAS, Digibox en TV. Mijn Pi ligt niet zo heel ver van de router dus het signaal zou wel uitstekend moeten zijn.

[MdO82]

R009 schreef op dinsdag 17 augustus 2021 @ 22:43:
[...]


Hoi Wopper,

Inderdaad alles is verbonden via WiFi. Spijtig genoeg kan ik geen UTP kabel meer verbinden. Alle poorten zijn al in gebruikt genomen door apparaten zoals een alarm, NAS, Digibox en TV. Mijn Pi ligt niet zo heel ver van de router dus het signaal zou wel uitstekend moeten zijn.

Heb je geen mogelijkheid om een switch te plaatsen om je pi te verbinden via utp ?

[ Voor 6% gewijzigd door MdO82 op 17-08-2021 22:48 ]

[stormfly]

R009 schreef op dinsdag 17 augustus 2021 @ 22:43:
[...]


Hoi Wopper,

Inderdaad alles is verbonden via WiFi. Spijtig genoeg kan ik geen UTP kabel meer verbinden. Alle poorten zijn al in gebruikt genomen door apparaten zoals een alarm, NAS, Digibox en TV. Mijn Pi ligt niet zo heel ver van de router dus het signaal zou wel uitstekend moeten zijn.

Een kleine switch met 5 poorten ernaast aansluiten. Wat je ervaart is dat je pihole van WiFi af is, want je kunt hem niet pingen. En je modem gui loopt minuten achter dat is een slechte indicator.

Je kunt testen door een van de andere apparaten los te gooien en die poort te gebruiken.

[deHakkelaar]

stormfly schreef op maandag 16 augustus 2021 @ 07:39:
[..]
Welk grote voordeel zien jullie met pihole HA, het user mgmt blijft vanaf 2 nodes individueel uitgevoerd worden meen ik?

Kopernikus.1979 schreef op maandag 16 augustus 2021 @ 14:03:
[..]
Doe ik via keepalived, de config is niet echt complex.
Tutorial: https://jekhokie.github.i...ocking-with-failover.html

Ik vind het ook een beetje overdreven om DNS met de complexiteit van HA op te zetten, KISS.
DNS laat toe om meerder servers op te geven en software is zich hiervan bewust.
HTTP(S) URL's of andere URI schemas niet, waar HA meer op van toepassing is.
Aangezien je hier praat over milisecondes zal het hooguit een 100ms zijn dat een client éénmalig ervaart dat een DNS server down is en overschakelt naar een van de alternatieve IP's.
En met een HA virtual IP duurt het meestal ook even voordat deze klaar is met de "fail-over".

De enige uitzondering waarvoor ik HA zou opzetten is als ik alles in sync zou moeten houden dus niet alleen de gravity database maar ook de queries database pihole-FTL.db, de "local DNS records" en de DHCP leases.
En daarvoor is keepalive met fail-over IP en gravity sync niet toereikent.
Daarvoor zal je toch echt moeten denken aan shared storage (NAS/SAN/SCSI enclosure) voor opslag van de databases, DNS records, DHCP leases etc.
Deze opslag zal net als het virtual IP en de pihole-FTL daemon ge-orchestreerdt moeten worden door cluster resources software/daemons.
Oa om ervoor te zorgen dat mocht het mis gaan, dat dan niet twee of meerdere nodes tegelijk toegang hebben tot de dezelfde resources zoals opslag en de boel vernaggelen.
Wat je eigenlijk ook nodig hebt is dat nodes kunnen stemmen voor het geval dat een falende node (bepaald door heuristics) moet worden afgeschoten (STONITH fencing).
En een extra stem in de vorm van een quorum partitie/file ingeval van split brain.
Hieronder zo'n setup maar dit is niet makkelijk en eigenlijk heb je dan van alles dubbel nodig of zelfs meer (NIC/HBA's, opslag, uplinks, etc):
https://access.redhat.com...igh-availability-clusters

[ Voor 3% gewijzigd door deHakkelaar op 18-08-2021 01:45 . Reden: +heuristics ]

[nero355]

deHakkelaar schreef op woensdag 18 augustus 2021 @ 00:08:
Ik vind het ook een beetje overdreven om DNS met de complexiteit van HA op te zetten, KISS.
DNS laat toe om meerder servers op te geven en software is zich hiervan bewust.

Ja, maar die time-outs dan...

En met een HA virtual IP duurt het meestal ook even voordat deze klaar is met de "fail-over".

Korte Hello/Dead times gebruiken!

De enige uitzondering waarvoor ik HA zou opzetten is als ik alles in sync zou moeten houden dus niet alleen de gravity database maar ook de queries database pihole-FTL.db, de "local DNS records" en de DHCP leases.
En daarvoor is keepalive met fail-over IP en gravity sync niet toereikent.
Daarvoor zal je toch echt moeten denken aan shared storage (NAS/SAN/SCSI enclosure) voor opslag van de databases, DNS records, DHCP leases etc.
Deze opslag zal net als het virtual IP en de pihole-FTL daemon ge-orchestreerdt moeten worden door cluster resources software/daemons.
Oa om ervoor te zorgen dat mocht het mis gaan, dat dan niet twee of meerdere nodes tegelijk toegang hebben tot de dezelfde resources zoals opslag en de boel vernaggelen.
Wat je eigenlijk ook nodig hebt is dat nodes kunnen stemmen voor het geval dat een falende node moet worden afgeschoten (STONITH fencing).
En een extra stem in de vorm van een quorum partitie/file ingeval van split brain.
Hieronder zo'n setup maar dit is niet makkelijk en eigenlijk heb je dan van alles dubbel nodig of zelfs meer (NIC/HBA's, opslag, uplinks, etc):
https://access.redhat.com...igh-availability-clusters

Ennn.... HOPPA!!! Ceph toestanden om een beetje Pi-Hole te kunnen draaien!

[deHakkelaar]

Kopernikus.1979 schreef op zondag 15 augustus 2021 @ 14:49:
[..]
Ik heb ook https ingeschakeld voor elke Pihole, zoals dit (met een wildcard cert):

ed1703 schreef op zondag 15 augustus 2021 @ 16:13:
[...]
Een wildcard cert kun je toch gewoon copyen naar je secondary server cq pihole? Zolang *.domein klopt zou dat gewoon moeten werken.
Als dit letsencrypt is, is het wel een gedoe vind ik persoonlijk dan.

Een wildcard cert is veels te onveilig en sommige software zou deze kunnen weigeren.
Je hebt de SAN exentesie voor dit welke toelaat om meerder domeinnamen mee te geven in een cert.
Ik geloof ook zelfs dat LetsEncrypt SAN ondersteund.
Beneden wat ik ff zo snel kon vinden:
https://community.letsenc...te-on-ubuntu-18-04/107265

[deHakkelaar]

R009 schreef op dinsdag 17 augustus 2021 @ 21:44:
Goeie avond,

Ik heb een heel raar probleem met mijn Raspberry Pi 3B+ waar Pi-Hole op draait.

Heb je al KVM aangesloten om te kijken wat er op scherm wordt weergegeven?
Zonder de muis uiteraard

En check ook voor "under-voltage" en meer tips hieronder:
deHakkelaar in "[Pi-Hole] Ervaringen & discussie"

[ed1703]

deHakkelaar schreef op woensdag 18 augustus 2021 @ 00:23:
[...]


[...]


Een wildcard cert is veels te onveilig en sommige software zou deze kunnen weigeren.
Je hebt de SAN exentesie voor dit welke toelaat om meerder domeinnamen mee te geven in een cert.
Ik geloof ook zelfs dat LetsEncrypt SAN ondersteund.
Beneden wat ik ff zo snel kon vinden:
https://community.letsenc...te-on-ubuntu-18-04/107265

Nee, letsencrypt ondersteund api’s met authenticatie voor bepaalde dns providers, daarom is het helemaal niet zo onveilig als men denkt.

Daarbuiten ben je overgeleverd aan _acme txt records. Dus letsencrypt heeft daar echt wel over nagedacht.
Overigens zit de zwakke schakel van SSL niet in SSL zelf, maar de extra schakel die je nodig hebt in de vorm van DNS.

nero355 schreef op woensdag 18 augustus 2021 @ 00:18:

Korte Hello/Dead times gebruiken!

Yep, daar verlies je misschien 3/4 pingetjes mee

deHakkelaar schreef op woensdag 18 augustus 2021 @ 00:08:

Aangezien je hier praat over milisecondes zal het hooguit een 100ms zijn dat een client éénmalig ervaart dat een DNS server down is en overschakelt naar een van de alternatieve IP's.

Je zal zeker langere tijd ervaren (vooral met windows) dat er een dns-server down is.

deHakkelaar schreef op woensdag 18 augustus 2021 @ 00:08:
https://access.redhat.com...igh-availability-clusters

Volgens mij sla je een beetje door voor iets wat thuis draait..

[ Voor 49% gewijzigd door ed1703 op 18-08-2021 08:26 ]

[Pietervs]

Kopernikus.1979 schreef op maandag 16 augustus 2021 @ 14:03:
[...]


Doe ik via keepalived, de config is niet echt complex.
Tutorial: https://jekhokie.github.i...ocking-with-failover.html

Dit ziet er makkelijk genoeg uit
Maar als ik het goed begrijp is dat die dus alleen maar er voor zorgt dat 1 van de 2 werkt als Master, er is dus geen synchronisatie van configuraties en dergelijke tussen de Raspberries? Want daar zit ik eigenlijk meer naar te kijken: allebei de Pi's halen iedere nacht de nieuwe lijsten op (pihole -g), maar als ik een lijst of adres toevoeg moet dat iedere keer handmatig op beide nodes gebeuren.

[Kopernikus.1979]

Pietervs schreef op woensdag 18 augustus 2021 @ 08:19:
[...]

Dit ziet er makkelijk genoeg uit
Maar als ik het goed begrijp is dat die dus alleen maar er voor zorgt dat 1 van de 2 werkt als Master, er is dus geen synchronisatie van configuraties en dergelijke tussen de Raspberries? Want daar zit ik eigenlijk meer naar te kijken: allebei de Pi's halen iedere nacht de nieuwe lijsten op (pihole -g), maar als ik een lijst of adres toevoeg moet dat iedere keer handmatig op beide nodes gebeuren.

De HA (keepalived) zorgt ervoor als de "master" down gaat het virtueel IP adres verwijst naar de 2de Pi-hole. Om ze synchroon te houden gebruik ik Gravity sync, deze synchroniseert de white list/black list/regex/dns/cnames, wat deze niet synchroniseert zijn de statistieken, maar daar heb ik geen problemen mee.

Momenteel draai ik deze op 2 Raspi's, maar het zou ook kunnen met docker of VM's.
Zou er een verschil zijn in performance (puur Pihole/Unbound) tussen de Raspi4 en docker?
Want ik zit erover te denken om bv de "backup" op mijn Unraid te plaatsen of omgekeerd, vandaar mijn vraag.

Of helemaal gek kan ook:

[deHakkelaar]

ed1703 schreef op woensdag 18 augustus 2021 @ 07:15:
[...]

Nee, letsencrypt ondersteund api’s met authenticatie voor bepaalde dns providers, daarom is het helemaal niet zo onveilig als men denkt.

Daarbuiten ben je overgeleverd aan _acme txt records. Dus letsencrypt heeft daar echt wel over nagedacht.

Als je de api bedoelt die certbot ook gebruikt om een acme challenge te initeren, dat is toch alleen maar om een cert te genereren/vernieuwen?
Hoe je het signed cert toepast als je deze hebt ontvangen zal LetsEncrypt een worst wezen.
En dan is een cert specifiek met namen toch altijd veiliger als een wildcard cert.
En inderdaad, je bent afhankelijk ofdat een cert subject of san correct resolved via DNS.

ed1703 schreef op woensdag 18 augustus 2021 @ 07:15:
[...]
Volgens mij sla je een beetje door voor iets wat thuis draait..

Ik zei ook:

deHakkelaar schreef op woensdag 18 augustus 2021 @ 00:08:
[...]
De enige uitzondering waarvoor ik HA zou opzetten is als ik alles in sync zou moeten houden dus niet alleen de gravity database maar ook de queries database pihole-FTL.db, de "local DNS records" en de DHCP leases.

En dat hoef ik niet perse

[ed1703]

deHakkelaar schreef op woensdag 18 augustus 2021 @ 08:50:
Als je de api bedoelt die certbot ook gebruikt om een acme challenge te initeren, dat is toch alleen maar om een cert te genereren/vernieuwen?
Hoe je het signed cert toepast als je deze hebt ontvangen zal LetsEncrypt een worst wezen.
En dan is een cert specifiek met namen toch altijd veiliger als een wildcard cert.
En inderdaad, je bent afhankelijk ofdat een cert subject of san correct resolved via DNS.

Het security probleem van SSL zit ook niet in SSL maar in het manke DNS. Er is op DNS na in 3 maanden geen enkele controle of je wel de rechtmatige eigenaar bent. Je kunt er mee doen wat je maar wilt. Zolang inderdaad DNS maar klopt.

Maargoed dit is nogal off-topic.

[ Voor 4% gewijzigd door ed1703 op 18-08-2021 09:02 ]

[deHakkelaar]

@ed1703 , Dat is waar.
Maarja men gaat ervan uit dat als je publieke DNS records goed staan, dat je ook gemachtigd bent om certs te genereren ofwel met de acme challenge of records.
Niet helemaal onlogisch lijkt mij.

[deHakkelaar]

ed1703 schreef op woensdag 18 augustus 2021 @ 07:15:

[...]
Je zal zeker langere tijd ervaren (vooral met windows) dat er een dns-server down is.
[...]

Volgens onderstaande één hele seconde:
https://docs.microsoft.co...lient-resolution-timeouts

EDIT: Geen idee hoelang het duurt voor een IP failover.

[ Voor 7% gewijzigd door deHakkelaar op 18-08-2021 09:21 ]

[Pietervs]

Kopernikus.1979 schreef op woensdag 18 augustus 2021 @ 08:49:
[...]


De HA (keepalived) zorgt ervoor als de "master" down gaat het virtueel IP adres verwijst naar de 2de Pi-hole. Om ze synchroon te houden gebruik ik Gravity sync, deze synchroniseert de white list/black list/regex/dns/cnames, wat deze niet synchroniseert zijn de statistieken, maar daar heb ik geen problemen mee.

Momenteel draai ik deze op 2 Raspi's, maar het zou ook kunnen met docker of VM's.
Zou er een verschil zijn in performance (puur Pihole/Unbound) tussen de Raspi4 en docker?
Want ik zit erover te denken om bv de "backup" op mijn Unraid te plaatsen of omgekeerd, vandaar mijn vraag.

Of helemaal gek kan ook:

[Afbeelding]

Ok, dan moet ik eens een blikje gaan werpen op Gravity.

Misschien een idee om naast de Pi's ook een docker te draaien? Als er dan een SD kaartje kapot gaat (of worst case: allebei de Pi's tegelijk af zouden branden) dan heb je in ieder geval de docker nog Ik ga er vanuit dat keepalived ook tussen 3 in plaats van 2 stations zou moeten werken, aangezien dit werkt op basis van vrrp.

Ik heb geen idee of er performance verschil tussen docker en Raspberries zit, dat zou je moeten testen. Zou me eigenlijk verbazen als dat echt merkbaar verschil maakt, maar je weet ooit nooit

Klinkt in ieder geval alsof ik een leuk klusje heb voor het weekend

[Verwijderd]

ed1703 schreef op woensdag 18 augustus 2021 @ 08:59:
[...]

Het security probleem van SSL zit ook niet in SSL maar in het manke DNS. Er is op DNS na in 3 maanden geen enkele controle of je wel de rechtmatige eigenaar bent. Je kunt er mee doen wat je maar wilt. Zolang inderdaad DNS maar klopt.

Maargoed dit is nogal off-topic.

SSL/TLS is alleen voor het encrypten van het verkeer. De rest wat je leest of hoort zijn eenvoudig sprookjes.

[ed1703]

deHakkelaar schreef op woensdag 18 augustus 2021 @ 09:19:
[...]

Volgens onderstaande één hele seconde:
https://docs.microsoft.co...lient-resolution-timeouts

EDIT: Geen idee hoelang het duurt voor een IP failover.

Dus geen 100 ms

Verwijderd schreef op woensdag 18 augustus 2021 @ 10:11:
[...]
SSL/TLS is alleen voor het encrypten van het verkeer. De rest wat je leest of hoort zijn eenvoudig sprookjes.

Voor sprookjes ga ik naar Kaatsheuvel. Ik zou graag een renew-check zien lager dan 3 maanden, maar dat veroorzaakt een enorme load aan netwerkverkeer en men meent dat dit onnodig is. Via DNS of een HTTPS-challenge is mij om het even. Al komt DNS meer in aanmerking omdat niet elk SSL-certificaat tbv HTTPS is.

[Freee!!]

Pietervs schreef op woensdag 18 augustus 2021 @ 09:46:
[...]
Ok, dan moet ik eens een blikje gaan werpen op Gravity.

Misschien een idee om naast de Pi's ook een docker te draaien? Als er dan een SD kaartje kapot gaat (of worst case: allebei de Pi's tegelijk af zouden branden) dan heb je in ieder geval de docker nog Ik ga er vanuit dat keepalived ook tussen 3 in plaats van 2 stations zou moeten werken, aangezien dit werkt op basis van vrrp.

Ik heb geen idee of er performance verschil tussen docker en Raspberries zit, dat zou je moeten testen. Zou me eigenlijk verbazen als dat echt merkbaar verschil maakt, maar je weet ooit nooit

Klinkt in ieder geval alsof ik een leuk klusje heb voor het weekend

Kleine kanttekening, Docker is geen hardware maar software, draait ook op diezelfde Pi's, dus het probleem van een kapot SD kaartje blijft gewoon hetzelfde.

[Kopernikus.1979]

Freee!! schreef op woensdag 18 augustus 2021 @ 10:55:
[...]

Kleine kanttekening, Docker is geen hardware maar software, draait ook op diezelfde Pi's, dus het probleem van een kapot SD kaartje blijft gewoon hetzelfde.

We doelden op docker op Unraid of een andere machine als backup voor de RasPi.
Vandaar ik me afvroeg als er een verschil merkbaar zou zijn in performantie.
Dus de RasPi als master of de docker container?

[Freee!!]

Kopernikus.1979 schreef op woensdag 18 augustus 2021 @ 10:58:
[...]
We doelden op docker op Unraid of een andere machine als backup voor de RasPi.
Vandaar ik me afvroeg als er een verschil merkbaar zou zijn in performantie.
Dus de RasPi als master of de docker container?

Het verschil dat je merkt, komt vrijwel volledig op conto van de gebruikte hardware. En verder verzoek ik je toch iets nauwkeuriger te communiceren, ik heb twee Pi-Holes, die allebei als een Docker-container draaien, ieder op een eigen RPi. Alleen "Docker" vertelt precies niets over de gebruikte hardware en vertroebeld de discussie.

[Verwijderd]

ed1703 schreef op woensdag 18 augustus 2021 @ 10:30:
Voor sprookjes ga ik naar Kaatsheuvel. Ik zou graag een renew-check zien lager dan 3 maanden, maar dat veroorzaakt een enorme load aan netwerkverkeer en men meent dat dit onnodig is. Via DNS of een HTTPS-challenge is mij om het even. Al komt DNS meer in aanmerking omdat niet elk SSL-certificaat tbv HTTPS is.

Drie maanden is al ruim en ik zie het eerder korter worden dan langer. Het kan geheel geautomatiseerd worden gedaan. Zelf moet ik het nog handmatig doen en doe het graag.

Ehhhh, de wijze van hoe de challange te bevestigen staat geheel los waar het certificaat voor gebruikt gaat worden. DNS kent DoT en ik ga die andere wijze voor DNS niet noemen omdat juist gebruikt wordt om mensen te volgen, i.p.v. waar het juist meer privacy zou moeten opleveren. Maar dat is een ander verhaal.

De load op het netwerk is miniem door de wijze waarop de DNS structuur is ontworpen. TTL is een beperkende factor en het lijkt mij zo, dat LE de TTL negeert want niet iedereen kan zelf een korte TTL instellen voor DNS.

[Pietervs]

Freee!! schreef op woensdag 18 augustus 2021 @ 10:55:
[...]

Kleine kanttekening, Docker is geen hardware maar software, draait ook op diezelfde Pi's, dus het probleem van een kapot SD kaartje blijft gewoon hetzelfde.

Oh
Ik ging uit van de docker op mijn NAS, maar je kan natuurlijk ook docker draaien op een Pi...

[Freee!!]

Pietervs schreef op woensdag 18 augustus 2021 @ 12:29:
[...]
Oh
Ik ging uit van de docker op mijn NAS, maar je kan natuurlijk ook docker draaien op een Pi...

Ik heb zelfs Docker gedraaid op mijn laptop (in een Linux VM).

[R009]

stormfly schreef op dinsdag 17 augustus 2021 @ 23:26:
[...]


Een kleine switch met 5 poorten ernaast aansluiten. Wat je ervaart is dat je pihole van WiFi af is, want je kunt hem niet pingen. En je modem gui loopt minuten achter dat is een slechte indicator.

Je kunt testen door een van de andere apparaten los te gooien en die poort te gebruiken.

Ja dat is wat ik nu net ook weer heb meegemaakt. Ongeveer 24uur heeft het goed gewerkt en toen ineens weer geen verbinding. Ff de Pi uit getrokken en terug in de stekker gestoken en alles werkt weer…
Denk je dat met wicd mijn Pi automatisch terug te laten verbinden met mijn WiFi mijn probleem kan oplossen?

[ed1703]

R009 schreef op woensdag 18 augustus 2021 @ 22:38:
[...]


Ja dat is wat ik nu net ook weer heb meegemaakt. Ongeveer 24uur heeft het goed gewerkt en toen ineens weer geen verbinding. Ff de Pi uit getrokken en terug in de stekker gestoken en alles werkt weer…
Denk je dat met wicd mijn Pi automatisch terug te laten verbinden met mijn WiFi mijn probleem kan oplossen?

Heb je al eens gekeken wat er in je logging staat? Problemen met je netwerk bedraad of wireless komen beide in /var/log/syslog terecht.
Een pi die z’n netwerk niet hersteld is meestal geen netwerkprobleem.

[deHakkelaar]

Verwijderd schreef op woensdag 18 augustus 2021 @ 11:14:
[...]
Het kan geheel geautomatiseerd worden gedaan. Zelf moet ik het nog handmatig doen en doe het graag.

certbot automatiseert al een boel.
Sheduled via systemd:

$ systemctl --no-pager --full -a list-timers
NEXT                          LEFT          LAST                          PASSED       UNIT                         ACTIVATES
[..]
Thu 2021-08-19 02:00:43 CEST  3h 17min left Wed 2021-08-18 21:37:58 CEST  1h 4min ago  certbot.timer                certbot.service

Leest deze onderstaande config om een cert te vernieuwen:

$ cat /etc/letsencrypt/renewal/dehakkelaar.nl.conf
# renew_before_expiry = 30 days
version = 0.28.0
archive_dir = /etc/letsencrypt/archive/dehakkelaar.nl
cert = /etc/letsencrypt/live/dehakkelaar.nl/cert.pem
privkey = /etc/letsencrypt/live/dehakkelaar.nl/privkey.pem
chain = /etc/letsencrypt/live/dehakkelaar.nl/chain.pem
fullchain = /etc/letsencrypt/live/dehakkelaar.nl/fullchain.pem

# Options used in the renewal process
[renewalparams]
account = aa98xxxxxxxxxxxxxxxx
authenticator = webroot
rsa_key_size = 4096
post_hook = echo '1' > /usr/local/ispconfig/server/le.restart
server = https://acme-v02.api.letsencrypt.org/directory
[[webroot_map]]
www.dehakkelaar.nl = /usr/local/ispconfig/interface/acme
dehakkelaar.nl = /usr/local/ispconfig/interface/acme

Bovenstaande post_hook herstart/reload ook apache om het nieuwe cert te activeren.
Je zou deze post_hook ook gewoon de web daemon kunnen laten herstarten of reloaden.
En kleine kantekening, bovenstaande is een public facing server!
Heb geen ervaring met de acme challenge (authenticator) via een DNS record voor mogelijk private domeinen.

[ Voor 1% gewijzigd door deHakkelaar op 18-08-2021 23:49 . Reden: typo + certbot linkje ]

[stormfly]

R009 schreef op woensdag 18 augustus 2021 @ 22:38:
[...]


Ja dat is wat ik nu net ook weer heb meegemaakt. Ongeveer 24uur heeft het goed gewerkt en toen ineens weer geen verbinding. Ff de Pi uit getrokken en terug in de stekker gestoken en alles werkt weer…
Denk je dat met wicd mijn Pi automatisch terug te laten verbinden met mijn WiFi mijn probleem kan oplossen?

Zou automatisch moeten herstellen. Heb je de voeding nagekeken? Welk type voeding heb je?

Deel je syslog even als je wilt?

Heb zelf een PiZero welke carrier lost meldingen geeft op WiFi. Kwam deze tegen, morgen eens kijken. https://www.raspberrypi.o...234058&p=1432916#p1432916

[ Voor 17% gewijzigd door stormfly op 18-08-2021 23:18 ]

[jpgview]

advanced question for unbound users.

zoals je hier kan lezen, wanneer pihole -g of pihole -up draait, is er een moment dat alle inkomende queries als allowed worden beschouwd.
In het voorbeeld dat ik geef wil ik voorkomen dat mijn locatie met google gedeeld word (domain userlocation.googleapis.com), die is dan ook geblocked. Echter door pihole -up te draaien (frequente activiteit als je op de dev branch zit) word heel af en toe het domain toch toegelaten, waardoor google toch mijn locatie te pakken krijgt.



Om dit te voorkomen zijn we aan het testen, de vraag is nog maar of de change er ooit komt, er zijn in het verleden nog testen uitgevoerd, die nooit in de master branch zijn opgenomen.
Vandaar mijn backup strategie, als pihole-FTL het dan toch af en toe doorlaat, kan unbound het nog steeds opvangen / blocken.

Duckduckgo leert echter dat er verschillende manieren zijn om dit te verwezelijken:

1.

code:

local-zone: "<domain>" redirect
local-data: "<domain> A 0.0.0.0"
local-data: "<domain> AAAA ::"

2.

code:

local-zone: "<domain>" always_nxdomain

3. (tweede file nodig, éénmaal voor alle blocks)

code:

auth-zone:
    name: "userlocation.googleapis.com."
    zonefile: "/blocked.zone"

blocked.zone content:

code:

$TTL 10800
@   IN SOA localhost. nobody.invalid. (
    1
    3600
    1200
    604800
    10800
    )

De voor de hand liggende vraag: Alle methodes werken, welk is de meest aangewezen methode?

Thanks.

[ Voor 0% gewijzigd door jpgview op 19-08-2021 10:07 . Reden: IPv6 ]

[stormfly]

jpgview schreef op donderdag 19 augustus 2021 @ 10:00:
advanced question for unbound users.

zoals je hier kan lezen, wanneer pihole -g of pihole -up draait, is er een moment dat alle inkomende queries als allowed worden beschouwd.
In het voorbeeld dat ik geef wil ik voorkomen dat mijn locatie met google gedeeld word (domain userlocation.googleapis.com), die is dan ook geblocked. Echter door pihole -up te draaien (frequente activiteit als je op de dev branch zit) word heel af en toe het domain toch toegelaten, waardoor google toch mijn locatie te pakken krijgt.

[Afbeelding]

Om dit te voorkomen zijn we aan het testen, de vraag is nog maar of de change er ooit komt, er zijn in het verleden nog testen uitgevoerd, die nooit in de master branch zijn opgenomen.
Vandaar mijn backup strategie, als pihole-FTL het dan toch af en toe doorlaat, kan unbound het nog steeds opvangen / blocken.

Duckduckgo leert echter dat er verschillende manieren zijn om dit te verwezelijken:

1.

code:

local-zone: "<domain>" redirect
local-data: "<domain> A 0.0.0.0"
local-data: "<domain> AAAA ::"

2.

code:

local-zone: "<domain>" always_nxdomain

3. (tweede file nodig, éénmaal voor alle blocks)

code:

auth-zone:
    name: "userlocation.googleapis.com."
    zonefile: "/blocked.zone"

blocked.zone content:

code:

$TTL 10800
@   IN SOA localhost. nobody.invalid. (
    1
    3600
    1200
    604800
    10800
    )

De voor de hand liggende vraag: Alle methodes werken, welk is de meest aangewezen methode?

Thanks.

Die ene website zou ik gewoon blocken in de firewall van mijn router.

Die split second dat de informatie lekt, als ik 95% filter is het voor mij ook prima. Zo heeft ieder zijn eigen normen en waarden, waar ik zelf voor zou waken is dat je twee systemen hebt te managen...schadowIT.

[Verwijderd]

deHakkelaar schreef op woensdag 18 augustus 2021 @ 23:07:
[...]

certbot automatiseert al een boel.
Sheduled via systemd:

knip

Bovenstaande post_hook herstart/reload ook apache om het nieuwe cert te activeren.
Je zou deze post_hook ook gewoon de web daemon kunnen laten herstarten of reloaden.
En kleine kantekening, bovenstaande is een public facing server!
Heb geen ervaring met de acme challenge (authenticator) via een DNS record voor mogelijk private domeinen.

Ik deed dat ook zo voordat ik overging op wildcard certificaten.

Ik moet dan een hash plaatsen in de DNS regels. Het vernieuwen kost totaal vijf minuten en is best te doen voor mij.

[Verwijderd]

In Unbound kun je ook alleen 0.0.0.0 of ::0 teruggeven.

code:

local-zone: "<domain>" always_null

code:

always_refuse
  Like refuse, but ignores local data and refuses the query.

 always_nxdomain
  Like  static, but ignores local data and returns nxdomain for the query.

 always_nodata
   Like static, but ignores local data and  returns  nodata  for the query.

 always_deny
   Like deny, but ignores local data and drops the query.

 always_null
   Always  returns  0.0.0.0  or  ::0 for every name in the zone.
   Like redirect with zero data for A and AAAA.   Ignores  local
   data in the zone.  Used for some block lists.

[ Voor 76% gewijzigd door Verwijderd op 19-08-2021 12:06 ]

[nero355]

jpgview schreef op donderdag 19 augustus 2021 @ 10:00:
3. (tweede file nodig, éénmaal voor alle blocks)

code:

auth-zone:
    name: "userlocation.googleapis.com."
    zonefile: "/blocked.zone"

De voor de hand liggende vraag: Alle methodes werken, welk is de meest aangewezen methode?

Ik denk dat die optie het beste is qua overzichtelijkheid i.c.m. een aparte file voor al je Unbound Blocked meuk : 99-MyBlockedDomains.conf of iets in die trant

[simonanton]

Draai pi-hole op mijn ubuntu-server (NUC). Zit echter te worstelen met poorten die open moeten enz. Heb deze instellingen en het werkt allemaal perfect i.c.m. unbound. https://docs.pi-hole.net/main/prerequisites/ Maar ik twijfel of ik nu kwetsbaar ben of niet. Op mijn router (Asus met Merlin) staan alle poorten dicht. Niets geforward. Deze scan is positief: https://www.grc.com/shieldsup

Iemand een tip? Trouwens elke reboot staat ufw weer op inactief. Moet ik weer via commando aanzetten. Nog niet eerder opgemerkt.

[ Voor 6% gewijzigd door simonanton op 29-08-2021 13:18 ]

[gastje01]

Waarschijnlijk iets simpels, maar ik kom er niet uit. Ik gebruik PiHole (2 devices) als DNS maar niet als DHCP server, daar heb ik mijn Unifi spul voor. Ik krijg echter bij client names de verkeerde namen te staan op IP adressen die ze (al lang) niet meer hebben. Hoe krijg ik PH zo ver om dit (automatisch) correct te resolven?

De PiHoles zitten beiden in hetzelfde subnet als de clients, hosts file is leeg. Flush logs werkt niet,flush network table werkt niet, conditional forwarding is ingesteld. Never forward FDQN staat uit, never revers lookup staat ook uit.

[deHakkelaar]

simonanton schreef op zondag 29 augustus 2021 @ 11:28:
Draai pi-hole op mijn ubuntu-server (NUC). Zit echter te worstelen met poorten die open moeten enz. Heb deze instellingen en het werkt allemaal perfect i.c.m. unbound. https://docs.pi-hole.net/main/prerequisites/ Maar ik twijfel of ik nu kwetsbaar ben of niet. Op mijn router (Asus met Merlin) staan alle poorten dicht. Niets geforward. Deze scan is positief: https://www.grc.com/shieldsup

Iemand een tip? Trouwens elke reboot staat ufw weer op inactief. Moet ik weer via commando aanzetten. Nog niet eerder opgemerkt.

Als GRC zegt dat alles dicht staat naar je publieke IP dan is dat goed genoeg.
Op de router hoef je helemaal niks open te gooien of te port forwarden om Pi-hole te kunnen draaien.

Wbt UFW, check ofdat deze "enabled" is om te starten at boot.
In onderstaande voorbeeld voor de SSH daemon geeft de eerste "enabled" de huidige status aan.
En de tweede "enabled" geeft aan wat de package default is bij installatie.

pi@ph5b:~ $ systemctl status sshd
[..]
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)

Ik draai zelf geen UFW maar ik geloof dat de systemd unit/service naam is ufw.service:

pi@ph5b:~ $ apt-file list ufw
[..]
ufw: /lib/systemd/system/ufw.service

Dus dan wordt dat:

code:

systemctl status ufw.service

Mocht de eerste niet enabled zijn, dan kun je deze aan flippen met onderstaande:

code:

sudo systemctl enable ufw.service

En rebooten om te testen.
Mocht dit niet werken, check de systemd journal logs:

code:

sudo journalctl -u ufw.service

[deHakkelaar]

gastje01 schreef op zondag 29 augustus 2021 @ 12:16:
Waarschijnlijk iets simpels, maar ik kom er niet uit. Ik gebruik PiHole (2 devices) als DNS maar niet als DHCP server, daar heb ik mijn Unifi spul voor. Ik krijg echter bij client names de verkeerde namen te staan op IP adressen die ze (al lang) niet meer hebben. Hoe krijg ik PH zo ver om dit (automatisch) correct te resolven?

De PiHoles zitten beiden in hetzelfde subnet als de clients, hosts file is leeg. Flush logs werkt niet,flush network table werkt niet, conditional forwarding is ingesteld. Never forward FDQN staat uit, never revers lookup staat ook uit.

Probeer ééns een reverse lookup voor een aktieve <DHCP_CLIENT_IP> tegen de <DHCP_SERVER_IP>:

code:

nslookup <DHCP_CLIENT_IP> <DHCP_SERVER_IP>

Voorbeeldje om de naam achter IP 10.0.0.9 te achterhalen:

C:\>nslookup 10.0.0.9 10.0.0.2
Server:  ph5a.home.dehakkelaar.nl
Address:  10.0.0.2

Name:    avr.home.dehakkelaar.nl
Address:  10.0.0.9

Pi-hole doet iets vergelijkbaars met conditional forwarding en default ververst dit elk uur geloof ik.

[simonanton]

@deHakkelaar Bedankt voor je reactie. Prefereer je de DNS van je provider boven unbound? Wat is veiliger? Ik vraag me af wat de risico’s van unbound zijn tov een provider als KPN.

[deHakkelaar]

@simonanton , ik draai unbound recursief.
Maar is moeilijke vraag.
Het komt allemaal neer op vertrouwen.
En ik vertrouw meer op unbound als deze recursief staat ingesteld.

EDIT: Allemaal vragen ze de root en authoritative DNS servers.
Je ISP DNS zit er dan dus tussenin.

[ Voor 21% gewijzigd door deHakkelaar op 29-08-2021 14:43 ]

[simonanton]

@deHakkelaar Wanneer je de handleiding van Pi Hole volgt moet je ook firewalld activeren en wel als volgt:

firewall-cmd --permanent --add-service=http --add-service=dns --add-service=dhcp --add-service=dhcpv6
firewall-cmd --permanent --new-zone=ftl
firewall-cmd --permanent --zone=ftl --add-interface=lo
firewall-cmd --permanent --zone=ftl --add-port=4711/tcp
firewall-cmd --reload

Uiteindelijk conflicteert ufw met firewalld. Althans nadat ik dit had uitgevoerd:

sudo systemctl stop firewalld.service
sudo systemctl disable firewalld.service

sudo ufw enable
sudo reboot

Werkte het weer.
sudo ufw status leverde me een Status: actief op.

[deHakkelaar]

@simonanton , ik moest ff nalezen maar je moet ze niet allemaal doen.
Het is of via IPTables of via FirewallD of via UFW (EDIT: welke je het handigst lijkt, of welke al voorraadig is of misschien diegene waar je al bekent mee bent).
Uiteindelijk manipuleren ze allemaal de Netfilter kernel module genaamd nf_tables:

pi@ph5b:~ $ lsmod
Module                  Size  Used by
nf_tables             196608  0
[..]

pi@ph5b:~ $ modinfo nf_tables
filename:       /lib/modules/5.10.17+/kernel/net/netfilter/nf_tables.ko
alias:          nfnetlink-subsys-10
author:         Patrick McHardy <[e-mail]>
license:        GPL
srcversion:     BE3FA39958629A733737CCE
depends:        nfnetlink
intree:         Y
name:           nf_tables
vermagic:       5.10.17+ mod_unload modversions ARMv6 p2v8

[ Voor 9% gewijzigd door deHakkelaar op 29-08-2021 19:08 ]

[nero355]

simonanton schreef op zondag 29 augustus 2021 @ 11:28:
Draai pi-hole op mijn ubuntu-server (NUC). Zit echter te worstelen met poorten die open moeten enz. Heb deze instellingen en het werkt allemaal perfect i.c.m. unbound. https://docs.pi-hole.net/main/prerequisites/ Maar ik twijfel of ik nu kwetsbaar ben of niet. Op mijn router (Asus met Merlin) staan alle poorten dicht. Niets geforward. Deze scan is positief: https://www.grc.com/shieldsup

Iemand een tip? Trouwens elke reboot staat ufw weer op inactief. Moet ik weer via commando aanzetten. Nog niet eerder opgemerkt.

Ik zou zeggen vergeet die Firewall meuk zolang je Pi-Hole niet richting het Internet open staat d.m.v. DMZ of iets dergelijks...

Iets wat je trouwens helemaal niet moet willen, want dan word je al gauw voor DDoS toestanden misbruikt!

[Vihaio]

Ik heb een paar dagen geleden pi-hole op m'n Raspberry pi gezet en dat bevalt best goed. Ik snap dat het handig kan zijn om een tweede pi te gebruiken voor het geval dat de eerste stopt met werken.

Ik kan alleen niet echt vinden wat de beste manier is om dat te doen. Moet ik dan gewoon een kloon van m'n eerste pi maken, ip-adres aanpassen en de tweede pi als tweede dns-server instellen in m'n router? Ik neem aan dat dat werkt, maar ik heb dan wel 2, dashboards, moet 2 keer de blacklists instellen, dingen updaten en zo.

Klopt het dat het op die manier werkt?

[simonanton]

@deHakkelaar @nero355 Bedankt voor jullie reacties! Dit onderwerp leeft. Erg fijn om zo snel antwoorden te krijgen! Nogmaals dank.

[Freee!!]

Vihaio schreef op zondag 29 augustus 2021 @ 19:17:
Ik heb een paar dagen geleden pi-hole op m'n Raspberry pi gezet en dat bevalt best goed. Ik snap dat het handig kan zijn om een tweede pi te gebruiken voor het geval dat de eerste stopt met werken.

Ik kan alleen niet echt vinden wat de beste manier is om dat te doen. Moet ik dan gewoon een kloon van m'n eerste pi maken, ip-adres aanpassen en de tweede pi als tweede dns-server instellen in m'n router? Ik neem aan dat dat werkt, maar ik heb dan wel 2, dashboards, moet 2 keer de blacklists instellen, dingen updaten en zo.

Klopt het dat het op die manier werkt?

In de basis klopt het, er zijn methodes om ze automatisch te synchroniseren.

EDIT: Een relatief eenvoudige methode is Gravity Sync.

[ Voor 3% gewijzigd door Freee!! op 29-08-2021 19:47 ]

[deHakkelaar]

nero355 schreef op zondag 29 augustus 2021 @ 19:15:
[...]

Ik zou zeggen vergeet die Firewall meuk zolang je Pi-Hole niet richting het Internet open staat d.m.v. DMZ of iets dergelijks...

Iets wat je trouwens helemaal niet moet willen, want dan word je al gauw voor DDoS toestanden misbruikt!

De die hard Tux nerds zullen zeggen dat een lokale firewall niet nodig is als je je systeem goed opzet.
Goed kijken welke services je adverteert en op welke sockets met bv netstat en dan beslissen ofdat je een firewall nodig hebt.
Ook met zaken zoals meerdere interfaces, masquerading, hardening etc zal je misschien een lokale firewall nodig hebben.

pi@ph5b:~ $ sudo netstat -nltup
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:4711          0.0.0.0:*               LISTEN      21752/pihole-FTL
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      499/lighttpd
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      21752/pihole-FTL
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      483/sshd
tcp        0      0 127.0.0.1:5335          0.0.0.0:*               LISTEN      496/unbound
tcp        0      0 127.0.0.1:8953          0.0.0.0:*               LISTEN      496/unbound
tcp        0      0 127.0.0.1:6010          0.0.0.0:*               LISTEN      28575/sshd: pi@pts/
tcp6       0      0 ::1:4711                :::*                    LISTEN      21752/pihole-FTL
tcp6       0      0 :::80                   :::*                    LISTEN      499/lighttpd
tcp6       0      0 :::53                   :::*                    LISTEN      21752/pihole-FTL
tcp6       0      0 :::22                   :::*                    LISTEN      483/sshd
tcp6       0      0 ::1:6010                :::*                    LISTEN      28575/sshd: pi@pts/
udp        0      0 0.0.0.0:53              0.0.0.0:*                           21752/pihole-FTL
udp        0      0 0.0.0.0:68              0.0.0.0:*                           11836/dhcpcd
udp        0      0 127.0.0.1:5335          0.0.0.0:*                           496/unbound
udp6       0      0 :::53                   :::*                                21752/pihole-FTL

EDIT: Ik zie boven dat poortje 68 onnodig open staat voor alle IP's 0.0.0.0.
dhcpcd 68 UDP is voor als de host als DHCP client functioneert en dat istie niet.

[ Voor 3% gewijzigd door deHakkelaar op 30-08-2021 15:44 . Reden: typo ]

[deHakkelaar]

Vihaio schreef op zondag 29 augustus 2021 @ 19:17:
Ik heb een paar dagen geleden pi-hole op m'n Raspberry pi gezet en dat bevalt best goed. Ik snap dat het handig kan zijn om een tweede pi te gebruiken voor het geval dat de eerste stopt met werken.

Ik kan alleen niet echt vinden wat de beste manier is om dat te doen. Moet ik dan gewoon een kloon van m'n eerste pi maken, ip-adres aanpassen en de tweede pi als tweede dns-server instellen in m'n router? Ik neem aan dat dat werkt, maar ik heb dan wel 2, dashboards, moet 2 keer de blacklists instellen, dingen updaten en zo.

Klopt het dat het op die manier werkt?

Je adverteert beide Pi-hole IP's via je DHCP server naar de clients toe.
Voor sync heb je GravitySync wat populair is.
Er zijn ook lieden die HA prefereren met een fail-over (virtual) IP als enkel eindpunt voor de clients en GravitySync daarbovenop.

[ Voor 0% gewijzigd door deHakkelaar op 29-08-2021 20:39 . Reden: dtttdt ]

[Vihaio]

Okay helder. Bedankt @Freee!! en @deHakkelaar

[deHakkelaar]

@Vihaio , ow nog één dingetje, het is niet "good practice" om een disk te clonen zoals je suggereerde.
De SSH sleutels en andere cryptische dingen zullen dan het zelfde zijn wat de veiligheid niet ten goed komt.

[nero355]

deHakkelaar schreef op zondag 29 augustus 2021 @ 19:59:
De die hard Tux nerds zullen zeggen dat een lokale firewall niet nodig is als je je systeem goed opzet.
Goed kijken welke services je adverteert en op welke sockets met bv netstat en dan beslissen ofdat je een firewall nodig hebt.

Dat is inderdaad ook mijn manier van denken!

deHakkelaar schreef op zondag 29 augustus 2021 @ 20:34:
@Vihaio , ow nog één dingetje, het is niet "good practice" om een disk te clonen zoals je suggereerde.
De SSH sleutels en andere cryptische dingen zullen dan het zelfde zijn wat de veiligheid niet ten goed komt.

Ik wilde daar eigenlijk wat over zeggen, maar dacht laat ook maar, want dan krijg je weer 10 tegenberichten in de trant van "Ja, maar ik clone mijn kaartjes altijd en dat werkt PERFECT!"

[gastje01]

deHakkelaar schreef op zondag 29 augustus 2021 @ 14:09:
[...]

Probeer ééns een reverse lookup voor een aktieve <DHCP_CLIENT_IP> tegen de <DHCP_SERVER_IP>:

code:

nslookup <DHCP_CLIENT_IP> <DHCP_SERVER_IP>

Voorbeeldje om de naam achter IP 10.0.0.9 te achterhalen:

C:\>nslookup 10.0.0.9 10.0.0.2
Server:  ph5a.home.dehakkelaar.nl
Address:  10.0.0.2

Name:    avr.home.dehakkelaar.nl
Address:  10.0.0.9

Pi-hole doet iets vergelijkbaars met conditional forwarding en default ververst dit elk uur geloof ik.

Dan krijg ik inderdaad de foutieve naam terug die ook in de web interface van Pi-Hole staat.

Zou dit dan vast hangen in de (ARP?) cache van m'n router? Als ik daar op de web interface inlog (zowel de Unifi controller als de pagina van de router zelf), zie ik gewoon de juiste naam. Ofwel PiHole stuurt de verzoeken niet door naar m'n router, of de router geeft geen juist antwoord terug?

Edit: Oorzaak gevonden, ouder hostnames zaten 'vast' in de hosts file van mijn USG. Nadat ik deze leeg gemaakt hebt werkt alles zoals verwacht.

[ Voor 6% gewijzigd door gastje01 op 30-08-2021 14:45 ]

[andregroeneveld]

Ik wou mijn Pi-Hole updaten en kreeg toen een onderbreking in mijn netwerk. Hierna opnieuw geprobeerd maar nu wil hij niet updaten en blijft met dezelfde melding komen. Ik heb sudo apt-get update && sudo apt-get -y upgrade en sudo apt-get update geprobeerd maar krijg steeds dezelfde melding, zie bijlage.


Wat kan ik nu doen?

[Exocet]

andregroeneveld schreef op maandag 30 augustus 2021 @ 09:31:
Ik wou mijn Pi-Hole updaten en kreeg toen een onderbreking in mijn netwerk. Hierna opnieuw geprobeerd maar nu wil hij niet updaten en blijft met dezelfde melding komen. Ik heb sudo apt-get update && sudo apt-get -y upgrade en sudo apt-get update geprobeerd maar krijg steeds dezelfde melding, zie bijlage.
[Afbeelding]

Wat kan ik nu doen?

Probeer anders eens:

code:

sudo apt-get autoclean

https://www.how2shout.com...toclean-clean-autoremove/

[ Voor 5% gewijzigd door Exocet op 30-08-2021 09:36 ]

[andregroeneveld]

Heb ik gedaan en dan een reboot en daarna opnieuw maar steeds dezelfde melding.

[ed1703]

andregroeneveld schreef op maandag 30 augustus 2021 @ 09:44:
Heb ik gedaan en dan een reboot en daarna opnieuw maar steeds dezelfde melding.

code:

$ sudo rm -rf /var/lib/apt/lists/*
$ sudo apt update

[andregroeneveld]

Dit werkt, dank je wel.

[deHakkelaar]

gastje01 schreef op maandag 30 augustus 2021 @ 08:50:
[...]
Edit: Oorzaak gevonden, ouder hostnames zaten 'vast' in de hosts file van mijn USG. Nadat ik deze leeg gemaakt hebt werkt alles zoals verwacht.

Rare jongens die USG:
Kopernikus.1979 in "[Pi-Hole] Ervaringen & discussie"

[gastje01]

deHakkelaar schreef op maandag 30 augustus 2021 @ 15:17:
[...]

Rare jongens die USG:
Kopernikus.1979 in "[Pi-Hole] Ervaringen & discussie"

Haha die had ik even gemist

Blij dat het werkt in ieder geval.

[marapuru]

De afgelopen weken merk ik dat steeds meer advertenties door mijn pi-hole heen glippen. Deze ads worden geserveerd vanaf een domein dat niet direct te herleiden is als advertentie domein. Hebben jullie tips hoe je deze advertenties zou kunnen blokkeren?

Een voorbeeld zou je hier kunnen zien: https://forum.festileaks....the-rabbit-hole-forum.21/ Daar krijg ik nu bovenin beeld een icetea reclame die geserveerd wordt vanaf hun eigen domein.

Ik kan natuurlijk met uBlock Origin in de weer en met allerlei wildcards specifieke CSS codes blocken. Maar ik zou het liever vanuit mijn pi-hole in 1 keer regelen.

Iemand tips?

[Cyberpope]

Als zij deze advertentie serveren vanaf hun eigen domein (dus feitelijk onderdeel van de webpagina) dan ga je hem via pihole niet blokken. Pihole kan niet zien of een plaatje reclame is of een plaatje van de website.

[dss58]

marapuru schreef op woensdag 1 september 2021 @ 08:47:
De afgelopen weken merk ik dat steeds meer advertenties door mijn pi-hole heen glippen. Deze ads worden geserveerd vanaf een domein dat niet direct te herleiden is als advertentie domein. Hebben jullie tips hoe je deze advertenties zou kunnen blokkeren?

Een voorbeeld zou je hier kunnen zien: https://forum.festileaks....the-rabbit-hole-forum.21/ Daar krijg ik nu bovenin beeld een icetea reclame die geserveerd wordt vanaf hun eigen domein.

Ik kan natuurlijk met uBlock Origin in de weer en met allerlei wildcards specifieke CSS codes blocken. Maar ik zou het liever vanuit mijn pi-hole in 1 keer regelen.

Iemand tips?

Cyberpope schreef op woensdag 1 september 2021 @ 09:12:
Als zij deze advertentie serveren vanaf hun eigen domein (dus feitelijk onderdeel van de webpagina) dan ga je hem via pihole niet blokken. Pihole kan niet zien of een plaatje reclame is of een plaatje van de website.

precies zoals cyberpope zegt, je kunt met pihole alleen op domain blocken, youtube advertenties kun je er ook niet mee blocken en is hetzelfde verhaal.

[marapuru]

Dat begrijp ik, ik weet in de kern wat Pi-hole is. Ik dacht wellicht zijn er tips om met bijvoorbeeld wildcards bepaalde domeinen te blocken zonder dat dat direct ten koste gaat van reguliere content.

[heeten12]

Als ik er even naar kijk dan maak jij gebruik van forum.festileaks.com de afbeelding is gehost op festilieaks.com

Als je nu eens forum.festileaks.com whitelist en vervolgens festileaks.com Blacklist?

Dan zou forum.festileaks.com volgens mij toegankelijk moeten zijn. Niet thuis om te testen

[dss58]

heeten12 schreef op woensdag 1 september 2021 @ 14:29:
Als ik er even naar kijk dan maak jij gebruik van forum.festileaks.com de afbeelding is gehost op festilieaks.com

Als je nu eens forum.festileaks.com whitelist en vervolgens festileaks.com Blacklist?

Dan zou forum.festileaks.com volgens mij toegankelijk moeten zijn. Niet thuis om te testen

heej wat slim, zojuist geprobeerd en werkt

[heeten12]

Haha mooi zo!

[Freee!!]

heeten12 schreef op woensdag 1 september 2021 @ 14:29:
Als ik er even naar kijk dan maak jij gebruik van forum.festileaks.com de afbeelding is gehost op festilieaks.com

Als je nu eens forum.festileaks.com whitelist en vervolgens festileaks.com Blacklist?

Dan zou forum.festileaks.com volgens mij toegankelijk moeten zijn. Niet thuis om te testen

Nog even afhankelijk van de (al geslaagde) test, dat klopt gewoon, whitelist wordt eerst gecontroleerd en omdat die specifieker is dan de blacklist entry, werkt het.

[marapuru]

heeten12 schreef op woensdag 1 september 2021 @ 14:29:
Als ik er even naar kijk dan maak jij gebruik van forum.festileaks.com de afbeelding is gehost op festilieaks.com

Als je nu eens forum.festileaks.com whitelist en vervolgens festileaks.com Blacklist?

Dan zou forum.festileaks.com volgens mij toegankelijk moeten zijn. Niet thuis om te testen

Thanks! Ik wist nog niet dat de whitelisting voor de blacklisting kwam. Nice!

[Kopernikus.1979]

Hi,

Ik heb een vraagje, mijn host-records en c-names (voornamelijk voor mijn nginx reverse proxy) staan gedefinieerd in een xx-host.conf file, werkt allemaal prima.

Nu is het probleem dat als een hostname in een cname staat Pi-Hole enkel het IP weergeeft ipv van de hostname, doe ik dat met een host-record werkt dit wel, nu mijn vraag is hoe zou ik dit kunnen laten werken?

Dus:

host-record=nginx.mijndomein.be,10.10.60.10,86400
cname=service1.mijndomein.be,service2.mijndomein.be,nginx.mijndomein.be,86400

Bij service 1&2 verschijnt het IP (waar nginx deze naartoe heeft geforwared) ipv de hostname
Ik zou natuurlijk 2 extra host records kunnen bijmaken, maar dat zal dan conflict geven met de cname

Iemand een idee?

[Verwijderd]

Wij mogen @jpgview feliciteren met het er door krijgen van https://github.com/pi-hole/FTL/pull/1159

[deHakkelaar]

Kopernikus.1979 schreef op zaterdag 11 september 2021 @ 14:37:
Hi,

Ik heb een vraagje, mijn host-records en c-names (voornamelijk voor mijn nginx reverse proxy) staan gedefinieerd in een xx-host.conf file, werkt allemaal prima.

Nu is het probleem dat als een hostname in een cname staat Pi-Hole enkel het IP weergeeft ipv van de hostname, doe ik dat met een host-record werkt dit wel, nu mijn vraag is hoe zou ik dit kunnen laten werken?

Dus:

host-record=nginx.mijndomein.be,10.10.60.10,86400
cname=service1.mijndomein.be,service2.mijndomein.be,nginx.mijndomein.be,86400

Bij service 1&2 verschijnt het IP (waar nginx deze naartoe heeft geforwared) ipv de hostname
Ik zou natuurlijk 2 extra host records kunnen bijmaken, maar dat zal dan conflict geven met de cname

Iemand een idee?

Snap um niet helemaal.
En log output is altijd handig.
Ik heb hieronder het IP veranderd naar 10.0.0.4 voor mijn Pi-hole setup met lighttpd (als vervanging van jouw nginx proxy):

pi@ph5b:~ $ sudo nano /etc/dnsmasq.d/99-my-settings.conf
host-record=nginx.mijndomein.be,10.0.0.4,86400
cname=service1.mijndomein.be,service2.mijndomein.be,nginx.mijndomein.be,86400

pi@ph5b:~ $ pihole-FTL --test
dnsmasq: syntax check OK.

pi@ph5b:~ $ sudo service pihole-FTL reload
pi@ph5b:~ $

Probeer ééns onderstaande testjes uit?

pi@ph5b:~ $ dig +short @localhost nginx.mijndomein.be a
10.0.0.4

pi@ph5b:~ $ dig +short @localhost service1.mijndomein.be cname
nginx.mijndomein.be.

pi@ph5b:~ $ dig +short @localhost service2.mijndomein.be cname
nginx.mijndomein.be.

pi@ph5b:~ $ dig +short @localhost service1.mijndomein.be a
nginx.mijndomein.be.
10.0.0.4

pi@ph5b:~ $ dig +short @localhost service2.mijndomein.be a
nginx.mijndomein.be.
10.0.0.4

Als bovenstaande dig's fout gaan, laat dan het +short argument weg en check de Pi-hole logs voor meer details.

pi@ph5b:~ $ curl -sSLI http://service1.mijndomein.be --resolve service1.mijndomein.be:80:10.0.0.4
HTTP/1.1 200 OK
X-Pi-hole: A black hole for Internet advertisements.
Content-type: text/html; charset=UTF-8
Expires: Sun, 12 Sep 2021 03:19:50 GMT
Cache-Control: max-age=0
Date: Sun, 12 Sep 2021 03:19:50 GMT
Server: lighttpd/1.4.53

pi@ph5b:~ $ sudo tail -F /var/log/lighttpd/access.log
[..]
1631416868|127.0.0.1|GET /admin/scripts/pi-hole/php/queryads.php?domain=service1.mijndomein.be&bp HTTP/1.0|200|101
1631416868|service1.mijndomein.be|HEAD / HTTP/1.1|200|0

pi@ph5b:~ $ curl -sSLI http://service2.mijndomein.be --resolve service2.mijndomein.be:80:10.0.0.4
HTTP/1.1 200 OK
X-Pi-hole: A black hole for Internet advertisements.
Content-type: text/html; charset=UTF-8
Expires: Sun, 12 Sep 2021 03:20:16 GMT
Cache-Control: max-age=0
Date: Sun, 12 Sep 2021 03:20:16 GMT
Server: lighttpd/1.4.53

pi@ph5b:~ $ sudo tail -F /var/log/lighttpd/access.log
[..]
1631416888|127.0.0.1|GET /admin/scripts/pi-hole/php/queryads.php?domain=service2.mijndomein.be&bp HTTP/1.0|200|101
1631416888|service2.mijndomein.be|HEAD / HTTP/1.1|200|0

Zoals je boven in de lighttpd logs kunt zien wordt de CNAME alias niet vertaalt/omgezet naar het werkelijke domein dus zul je op je nginx web proxy twee extra aliasen moeten aanmaken voor de nginx.mijndomein.be vhost.
Een browser zal éérst via DNS het IP achterhalen, daarna verbinden met de web server IP via HTTP en dan om de content voor het gewenste domein vragen.

Als de dig antwoorden kloppen, zou ik toch willen adviseren om je probleem op het juiste support forum te plaatsen.
nginx proxies is niet echt on-topic

[deHakkelaar]

Verwijderd schreef op zaterdag 11 september 2021 @ 22:29:
Wij mogen @jpgview feliciteren met het er door krijgen van https://github.com/pi-hole/FTL/pull/1159

Beetje raar om hier te vissen voor respect.
Ook raar dat je een linkje plaats waar @jpgview helemaal niet in voorkomt.
Ik weet dat op Pi-hole Discourse een draadje loopt.
Was handiger geweest als je die hier ook had gelinkt met de bijdrages van @jpgview.

Toch bedankt @jpgview!

[TheCeet]

Nieuwe versie beschikbaar.

Pi-hole FTL v5.9, Web v5.6 and Core v5.4 released

https://pi-hole.net/2021/...6-and-core-v5-4-released/

[Asprine]

Probeer de laatste versie up te krijgen en mijn oude settings te behouden maar de docker container crasht. Werkwijze: Haalde de docker image van de laatste versie naar beneden, bracht de oude down en deed een rename naar old, deed een duplicate settings en heb daarin het versie nummer naar de juiste versie aangepast.
Iemand een tip wat ik vergeet of fout doe?
Thanks.

[Verwijderd]

deHakkelaar schreef op zondag 12 september 2021 @ 06:42:
[...]

Beetje raar om hier te vissen voor respect.
Ook raar dat je een linkje plaats waar @jpgview helemaal niet in voorkomt.
Ik weet dat op Pi-hole Discourse een draadje loopt.
Was handiger geweest als je die hier ook had gelinkt met de bijdrages van @jpgview.

Toch bedankt @jpgview!

Dit loopt al sinds ik nog in het forum van Pihole aanwezig was. Heel geduldig moeten zijn om dit langs de neus van Grumpy te krijgen. Engelen geduld was het motto en het wachten met weer opbrengen als de tijd rijp was. DL6ER heeft een goede neus voor zoiets.

Het begon hiermee: https://discourse.pi-hole...engine-improvements/34751

[deHakkelaar]

@Verwijderd duidelijk.
Ik snap wel dat ze soms het bootje afhouden.
Ik heb ook nog een lijst met zaken waar ik aan moet beginnen maar vanwege complexiteit en ontbreken van kennis deze taken steeds uitstel
Deze nieuwe feature heeft ook wel een heel kleine doelgroep.
Ik kan ook nog geen "use case" bedenken voor mij op dit moment voor deze nieuwe feature.
Maar wat niet is kan altijd nog komen

[deHakkelaar]

Asprine schreef op zondag 12 september 2021 @ 09:29:
Probeer de laatste versie up te krijgen en mijn oude settings te behouden maar de docker container crasht. Werkwijze: Haalde de docker image van de laatste versie naar beneden, bracht de oude down en deed een rename naar old, deed een duplicate settings en heb daarin het versie nummer naar de juiste versie aangepast.
Iemand een tip wat ik vergeet of fout doe?
Thanks.

Geen ervaring met de Docker versie van Pi-hole maar werkt de Teleporter niet in Docker?

[nero355]

TheCeet schreef op zondag 12 september 2021 @ 07:48:
Nieuwe versie beschikbaar.

Pi-hole FTL v5.9, Web v5.6 and Core v5.4 released

https://pi-hole.net/2021/...6-and-core-v5-4-released/

Interessant :

Interface-dependent handling of pi.hole and the machine’s hostname
This makes FTL automatically reply with the appropriate IP address to both pi.hole and the machines hostname. Before this change, FTL always used a hard-coded address set during the weekly gravity updates (pihole -g). The new method is interface-aware and may reply with different addresses on different interfaces (e.g. Ethernet, WiFi or Wireguard network). The address FTL replies with can be overwritten using the REPLY_ADDR4/6 settings in /etc/pihole/pihole-FTL.conf.

@deHakkelaar
Betekent dit dat een verandering in pihole-FTL.conf de volgende keer niet zal worden overschreven na/tijdens een update ?!

[deHakkelaar]

@nero355 , denk het wel.
FF testen:

pi@ph5b:~ $ pihole -v
  Pi-hole version is v5.3.1 (Latest: v5.3.1)
  AdminLTE version is v5.5 (Latest: v5.5.1)
  FTL version is v5.8.1 (Latest: v5.8.1)

pi@ph5b:~ $ cat /etc/pihole/pihole-FTL.conf
PRIVACYLEVEL=0

pi@ph5b:~ $ sudo tee -a /etc/pihole/pihole-FTL.conf <<< 'REPLY_ADDR4=99.99.99.99'
REPLY_ADDR4=99.99.99.99

pi@ph5b:~ $ cat /etc/pihole/pihole-FTL.conf
PRIVACYLEVEL=0
REPLY_ADDR4=99.99.99.99

pi@ph5b:~ $ pihole -up
[..]
Update Complete!

  Current Pi-hole version is v5.4
  Current AdminLTE version is v5.6
  Current FTL version is v5.9

pi@ph5b:~ $ cat /etc/pihole/pihole-FTL.conf
REPLY_ADDR4=99.99.99.99
PRIVACYLEVEL=0

pi@ph5b:~ $ dig +short @localhost pi.hole
99.99.99.99

[RaijRaij]

Ik draai al een tijdje 'probleemloos' pihole op mijn raspberry pi 3. Zolang het draait is er niets aan de hand. Nu heb ik al een paar keer gehad dat als de stroom uitvalt en daarna alles weer opstart ik geen internet heb. Voor mij niet zo'n probleem maar anderen hier in huis weten het niet te herstellen.

Mijn dhcp wordt gehandeld door pihole. Dhcp in mijn router(experiabox V10) staat daarom uit. Pi heeft een statisch IP die als dns is opgegeven in mijn router. Toch moet ik na zo'n stroomuitval de dhcp van mijn router even aanzetten en die van pihole uit om internet weer op gang te krijgen. Daarna zet ik alles terug en draait het probleemloos. Iemand enig idee waar de fout in mij config zit of wat dit probleem veroorzaakt (naast de waterkoker, oven en vaatwasser gelijktijdig aanzetten ;-))

[ Voor 5% gewijzigd door RaijRaij op 12-09-2021 15:48 ]

[stormfly]

RaijRaij schreef op zondag 12 september 2021 @ 15:34:
Ik draai al een tijdje 'probleemloos' pihole op mijn raspberry pi 3. Zolang het draait is er niets aan de hand. Nu heb ik al een paar keer gehad dat als de stroom uitvalt en daarna alles weer opstart ik geen internet heb. Voor mij niet zo'n probleem maar anderen hier in huis weten het niet te herstellen.

Mijn dhcp wordt gehandeld door pihole. Dhcp in mijn router(experiabox V10) staat daarom uit. Pi heeft een statisch IP die als dns is opgegeven in mijn router. Toch moet ik na zo'n stroomuitval de dhcp van mijn router even aanzetten en die van pihole uit om internet weer op gang te krijgen. Daarna zet ik alles terug en draait het probleemloos. Iemand enig idee waar de fout in mij config zit of wat dit probleem veroorzaakt (naast de waterkoker, over en vaatwasser gelijktijdig aanzetten ;-))

Als je de pi direct aan je laptop koppelt met UTP kan je hem dan pingen als je de laptop ook een statisch IP geeft?

Voelt alsof de Pi het statische adres toch niet helemaal zelfstandig toe kan kennen. Ook GW bij het statische adres ingevuld?

[deHakkelaar]

@RaijRaij , aanvullend, check ofdat dhcpcd een statisch adres toewijst, het using static address gedeelte in onderstaande voorbeeld, of dat ie misschien via DHCP een adres probeert te verkrijgen:

pi@ph5b:~ $ journalctl -u dhcpcd
[..]
Sep 12 15:48:32 ph5b systemd[1]: Starting dhcpcd on all interfaces...
Sep 12 15:48:32 ph5b dhcpcd[30529]: dev: loaded udev
Sep 12 15:48:32 ph5b dhcpcd[30529]: DUID 00:01:00:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
Sep 12 15:48:32 ph5b dhcpcd[30529]: eth0: IAID eb:xx:xx:xx
Sep 12 15:48:32 ph5b dhcpcd[30529]: eth0: using static address 10.0.0.4/24
Sep 12 15:48:32 ph5b dhcpcd[30529]: eth0: adding route to 10.0.0.0/24
Sep 12 15:48:32 ph5b dhcpcd[30529]: eth0: adding default route via 10.0.0.1
Sep 12 15:48:33 ph5b dhcpcd[30543]: eth0: pid -2047853952 deleted default route via 10.0.0.1
Sep 12 15:48:33 ph5b dhcpcd[30529]: forked to background, child pid 30543
Sep 12 15:48:33 ph5b systemd[1]: Started dhcpcd on all interfaces.
Sep 12 15:48:33 ph5b dhcpcd[30543]: eth0: soliciting an IPv6 router
Sep 12 15:48:45 ph5b dhcpcd[30543]: eth0: no IPv6 Routers available

[RaijRaij]

deHakkelaar schreef op zondag 12 september 2021 @ 15:54:
@RaijRaij , aanvullend, check ofdat dhcpcd een statisch adres toewijst, het using static address gedeelte in onderstaande voorbeeld, of dat ie misschien via DHCP een adres probeert te verkrijgen:

pi@ph5b:~ $ journalctl -u dhcpcd
[..]
Sep 12 15:48:32 ph5b systemd[1]: Starting dhcpcd on all interfaces...
Sep 12 15:48:32 ph5b dhcpcd[30529]: dev: loaded udev
Sep 12 15:48:32 ph5b dhcpcd[30529]: DUID 00:01:00:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
Sep 12 15:48:32 ph5b dhcpcd[30529]: eth0: IAID eb:xx:xx:xx
Sep 12 15:48:32 ph5b dhcpcd[30529]: eth0: using static address 10.0.0.4/24
Sep 12 15:48:32 ph5b dhcpcd[30529]: eth0: adding route to 10.0.0.0/24
Sep 12 15:48:32 ph5b dhcpcd[30529]: eth0: adding default route via 10.0.0.1
Sep 12 15:48:33 ph5b dhcpcd[30543]: eth0: pid -2047853952 deleted default route via 10.0.0.1
Sep 12 15:48:33 ph5b dhcpcd[30529]: forked to background, child pid 30543
Sep 12 15:48:33 ph5b systemd[1]: Started dhcpcd on all interfaces.
Sep 12 15:48:33 ph5b dhcpcd[30543]: eth0: soliciting an IPv6 router
Sep 12 15:48:45 ph5b dhcpcd[30543]: eth0: no IPv6 Routers available

Mijn output is gelijkend aan de jouw.

@stormfly Ga ik straks proberen. Wat bedoel je met GW?

[deHakkelaar]

@RaijRaij , dan zou ik als het weer gebreurt, voordat je de router DHCP service activeert/deactiveert, inloggen desnoods via console, en IP connectivity testen:

pi@ph5a:~ $ ip -br -4 address
lo               UNKNOWN        127.0.0.1/8
eth0             UP             10.0.0.2/24

pi@ph5a:~ $ ip -br -4 route
default via 10.0.0.1 dev eth0 src 10.0.0.2 metric 202
10.0.0.0/24 dev eth0 proto dhcp scope link src 10.0.0.2 metric 202

pi@ph5a:~ $ traceroute -n 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  10.0.0.1  0.800 ms  0.612 ms  0.622 ms
 2  192.168.1.1  1.116 ms  0.798 ms  1.193 ms
 3  62.58.240.1  9.061 ms  8.643 ms  8.046 ms
 4  212.53.25.201  10.897 ms  10.692 ms  13.201 ms
 5  * * *
 6  * * *
 7  8.8.8.8  8.221 ms  7.997 ms  8.004 ms

Checken ofdat local records resolven:

pi@ph5a:~ $ dig +short @localhost pi.hole
10.0.0.2

En een domein testen die geforward moet worden upstream door Pi-hole:

pi@ph5a:~ $ dig +short @localhost pi-hole.net
3.18.136.52

De Pi-hole logs tail-en voor DHCP:

pi@ph5a:~ $ tail -F /var/log/pihole.log | grep dnsmasq-dhcp

De DHCP lease op een client vernieuwen (zit momenteel achter een winpc):

C:\>ipconfig /renew

Windows IP Configuration


Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . : home.dehakkelaar.nl
   IPv4 Address. . . . . . . . . . . : 10.0.0.11
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 10.0.0.1

Je kunt de lease ook vernieuwen door client netwerk even los te koppelen of een mobieltje kort in airplane mode te zetten.
Als goed is hoor je zoiets als hieronder te zien:

pi@ph5a:~ $ tail -F /var/log/pihole.log | grep dnsmasq-dhcp
Sep 12 16:19:07 dnsmasq-dhcp[6202]: DHCPREQUEST(eth0) 10.0.0.11 00:1e:0b:xx:xx:xx
Sep 12 16:19:08 dnsmasq-dhcp[6202]: DHCPACK(eth0) 10.0.0.11 00:1e:0b:xx:xx:xx hakpc

EDIT: ow boven draait nog de oude Pi-hole versie.
Beneden is het antwoord met de nieuwe laatste versie:

pi@ph5b:~ $ dig +short @localhost pi.hole
127.0.0.1

[ Voor 5% gewijzigd door deHakkelaar op 12-09-2021 17:12 . Reden: EDIT+typo ]

[stormfly]

RaijRaij schreef op zondag 12 september 2021 @ 16:05:
[...]


Mijn output is gelijkend aan de jouw.

@stormfly Ga ik straks proberen. Wat bedoel je met GW?

Gateway/router adres.

[sambaloedjek]

Blijkbaar is het sinds kort ook mogelijk om Pihole direct op bepaalde Mikrotik routers te draaien als docker container:
https://help.mikrotik.com/docs/display/ROS/Container

[RaijRaij]

Bedankt voor de reacties, ik kan weer even verder met uitproberen/testen.