[Pi-Hole] Ervaringen & discussie

[jellebelle]

Sinds 2 maanden ben ik aan de slag met Pi-Hole op een Rapberry Pi.
Leuke software, en het werkt bijna helemaal goed! Ik bedoel: De meeste clients in mijn netwerk zijn grotendeels advertentie-vrij. Maar er glipt nog best wel wat doorheen en het lijkt ook willekeurig te gebeuren. Ik test vaak even met Nu.nl, dan zie je het vrij snel…

Waarom floepen er soms toch advertenties door?
Na lang lezen, denken, proberen & doen heb ik het vermoeden dat het temaken heeft met IPv6...

Situatie:

Ziggo Ubee EVW321B modem/router
- 192.168.178.1
- Deze functioneert als DHCP server
- LAN Static DNS 1 = 192.168.178.30
- LAN Static DNS 2 = 0.0.0.0
- LAN Static DNS 3 = 0.0.0.0

Raspberry-Pi
- 192.168.178.30 (Static lease op Ziggo router via MAC Adress)
- Software: Pi-Hole v5.2

In mijn lokale netwerk zitten DHCP clients waaronder: 2x Windows PC, 1x Linux PC, 1x iPad, 3x Android phone. En eigenlijk op alle clients geldt: het werkt, maar soms ook “even niet”.

De enige client die 100% goed gaat is de Linux PC en dat komt volgens mij omdat ik daar de ethernet verbinding heb ingesteld op IPv6 = “ignore”. Die client werkt dus uitsluitend met IPv4.

Wat heb ik verder geprobeerd:

1)
De Raspberry Pi als DHCP server ingesteld > geen verandering > weer teruggezet naar Router.

2)
Pi-Hole opnieuw installeren, tijdens de installatie krijg je deze opties:

Select protocols
• IPv4 – Block ads over IPv4
• IPv6 – Block ads over IPv6

Ik heb zowel een installatie met als zonder IPv6 gedaan en uitvoerig getest.
Ik merk geen verschil.
Ook snap ik deze keuze niet… Waarom zou iemand IPv6 willen uitvinken?

3)
Ten einde raad heb ik een verzoek bij Ziggo gedaan om mij op IPv4-only te zetten.
Na wat uitleg was men bereid dit te doen. Is nu een week geleden, maar ik blijft een IPv6 IP-adres behouden. En ik zie ook nog steeds bij de clients 1 of meerdere IPv6 adressen en DNS servers staan. Navraag bij Ziggo: “U staat echt op IPv4-only, dit zou niet moeten kunnen”

4)
Veel Google-zoeken, lezen, dit forum, andere forums….
Het valt me op dat veel mensen stoeien met IPv6 en Pi-Hole.

Het lijkt in mijn situatie schier onmogelijk om IPv6 de nek om te draaien, en eigenlijk zou dat ook niet nodig moeten zijn...

Mijn vragen:
Hoe is dit nou onder controle te krijgen?
IPv4 gaat goed, DNS wordt door de router netjes naar 192.168.178.30 gestuurd.
IPv6 leidt een eigen leven en blijft (volgens mij) om de Pi-Hole heen fietsen…
De Pi-Hole heeft wel een IPv6 adres, maar hoe weten de DHCP clients dat?
Volgens de instructies van Pi-Hole zou de Static DNS instelling op het router voldoende moeten zijn (zie ook de screenshot op https://pi-hole.net/ bij puntje 3)

Tot slot – Upstream DNS:
Hoe moeten de vinkjes staan bij de Upstream DNS Server?
Stel ik gebruik Cloudflare, dan staan daar 4 mogelijkheden om een vinkje te zetten (2x IPv4 en 2x IPv6).
Of hier beter de DNS van mijn ISP instellen? Zo ja, alleen IPv4 of ook IPv6?

[ed1703]

Ben.Hahlen schreef op zondag 20 december 2020 @ 09:45:
[...]

En om er voor te zorgen dat ook mijn TV (en andere devices) zich aan de PiHole DNS houdt:

code: Custom Firewall Rules

#keep network on pi-hole
iptables -t nat -I PREROUTING -i lan -p tcp --dport 53 -j DNAT --to 192.168.2.5:53
iptables -t nat -I PREROUTING -i lan -p udp --dport 53 -j DNAT --to 192.168.2.5:53

#punch DNS hole for pi-hole
iptables -t nat -I PREROUTING -i lan -p tcp -s 192.168.2.5 --dport 53 -j ACCEPT
iptables -t nat -I PREROUTING -i lan -p udp -s 192.168.2.5 --dport 53 -j ACCEPT

Je hebt vziw ook nog een MASQ-regel nodig.. om geen nslookup-errors te krijgen als 8.8.8.8 op een device niet anders instelbaar is.

code:

iptables -t nat -A POSTROUTING -d 192.168.2.5 -o lan -p udp --dport 53  -m comment --comment "source-error-fix udp 53" -j MASQUERADE

iptables -t nat -A POSTROUTING -d 192.168.2.5 -o lan -p tcp --dport 53  -m comment --comment "source-error-fix tcp 53" -j MASQUERADE

jellebelle schreef op zondag 20 december 2020 @ 10:17:

Mijn vragen:
Hoe is dit nou onder controle te krijgen?
IPv4 gaat goed, DNS wordt door de router netjes naar 192.168.178.30 gestuurd.
IPv6 leidt een eigen leven en blijft (volgens mij) om de Pi-Hole heen fietsen…

Als IPv6 RA niet is in te stellen met eigen DNS-servers heb je toch wel een uitdaging.
Ziggo blijven lastig vallen, liefst via de eigen community om IPv6 uit te schakelen.
Redelijk stuitend dat DNS op RA/DHCPv6 nog steeds niet is in te stellen bij Ziggo.
Niet helemaal onverwacht, maar wel iets wat Ziggo moet gaan oplossen aangezien het gewoon zorgt voor het niet kunnen toepassen van een fatsoenlijke LAN-DNS.

[deHakkelaar]

ocaj schreef op zondag 20 december 2020 @ 09:17:
[...]
(mijn router heeft dus wel de pihole als dns ivm Gast-netwerk.

Ben.Hahlen schreef op zondag 20 december 2020 @ 09:45:
[...]
Aangezien mijn router DHCP uitgeeft, is het toch juist de bedoeling dat deze de PiHole als DNS gebruikt?
[...]

Julie beiden maken de klassieke fout en voeren Pi-hole op als upstream DNS in de router:
https://docs.pi-hole.net/main/post-install/

[deHakkelaar]

jellebelle schreef op zondag 20 december 2020 @ 10:17:
Waarom floepen er soms toch advertenties door?
Na lang lezen, denken, proberen & doen heb ik het vermoeden dat het temaken heeft met IPv6...

Grote kans dat de clients ook een DNS server gebruiken die niet Pi-holed is.
Grote kans dat ze een DNS server(s) hebben toegewezen gekregen via IPv6 router discovery.
Check DNS servers toegewezen/discovered/geconfigureerd in een Windows command prompt met onderstaande twee:

code:

netsh interface ipv4 show dnsservers

code:

netsh interface ipv6 show dnsservers

Op de Linux client kun je met onderstaande controleren

code:

cat /etc/resolv.conf

Voor Android heb je de "Network Info" app.
Voor de iPad zal wel een vergelijkbare app beschikbaar zijn.

jellebelle schreef op zondag 20 december 2020 @ 10:17:
Ook snap ik deze keuze niet… Waarom zou iemand IPv6 willen uitvinken?

Omdat een dual stack IPv4 + IPv6 vaak onnodig is als je ISP geen IPv6 support upstream:
https://ipv6-test.com/

Een dual stack betekent ook dat je alles dubbel moet doen, DNS, firewall, routing etc.
Zelfs als mijn ISP besluit om IPv6 uit te rollen voor mijn verbinding, zal ik toch nog alleen IPv4 gebruiken.
Zat discusies te vinden op het net over voor/nadelen.

jellebelle schreef op zondag 20 december 2020 @ 10:17:
Hoe is dit nou onder controle te krijgen?

Ja dat kan lastig zijn.
Ik kan alles IPv6 aan de LAN zijde uitschakelen in de router.
En heb IPv6 opties in Pi-hole ook uitgeschakeld.

jellebelle schreef op zondag 20 december 2020 @ 10:17:
De Pi-Hole heeft wel een IPv6 adres, maar hoe weten de DHCP clients dat?

Dat is waarschijnlijk het link local address en hoef je geen zorgen over te maken:

code:

pi@ph5:~ $ ip -br -6 address show eth0
eth0             UP             fe80::40aa:xxxx:xxxx:xxxx/64

jellebelle schreef op zondag 20 december 2020 @ 10:17:
Tot slot – Upstream DNS:
Hoe moeten de vinkjes staan bij de Upstream DNS Server?
Stel ik gebruik Cloudflare, dan staan daar 4 mogelijkheden om een vinkje te zetten (2x IPv4 en 2x IPv6).
Of hier beter de DNS van mijn ISP instellen? Zo ja, alleen IPv4 of ook IPv6?

Als je ISP IPv6 support upstream (zie linkje eerder) en Pi-hole is geconfigureerd met een geldig IPv6 adres, kun je ze alle 4 aanvinken.
Testen kun je met:

code:

pi@ph5:~ $ cat /etc/pihole/dns-servers.conf
[..]
Cloudflare;1.1.1.1;1.0.0.1;2606:4700:4700::1111;2606:4700:4700::1001

code:

pi@ph5:~ $ nslookup tweakers.net 1.1.1.1
Server:         1.1.1.1
Address:        1.1.1.1#53

Non-authoritative answer:
Name:   tweakers.net
Address: 213.239.154.30
Name:   tweakers.net
Address: 2001:9a8:0:e:1337:0:80:1

code:

pi@ph5:~ $ nslookup tweakers.net 2606:4700:4700::1111
;; connection timed out; no servers could be reached

[Ben.Hahlen]

deHakkelaar schreef op maandag 21 december 2020 @ 01:00:
[...]

[...]

Julie beiden maken de klassieke fout en voeren Pi-hole op als upstream DNS in de router:
https://docs.pi-hole.net/main/post-install/

Ok... Die pagina leidt mij naar https://discourse.pi-hole...e-as-their-dns-server/245

Daarin geven ze aan Method 2 als preferred te hebben, waar weer in staat dat ik er voor moet zorgen dat OpenWRT het IP van PiHole moet adverteren naar de clients, middels de list dhcp_option '6,192.168.2.5' optie. So far, so good.

Dan gaat dus de optie list dns '192.168.2.5' uit de /etc/config/network.

Wat ik dan niet helemaal begrijp, is dat er wordt gezegd dat je in PiHole géén Upstream DNS moet kiezen, maar daar juist weer de router moet opgeven.
Betekent dat dan dat ik, in de router, de DNS van bv CloudFlare opgeef?

(Ik probeer de rationale een beetje te begrijpen, maar het verwarrende is dat elke guide die je tegenkomt, net weer wat anders vertelt over hoe het zou moeten...)

...en de IPV6 is een volgend projectje

[Ben.Hahlen]

deHakkelaar schreef op maandag 21 december 2020 @ 01:00:
[...]

[...]

Julie beiden maken de klassieke fout en voeren Pi-hole op als upstream DNS in de router:
https://docs.pi-hole.net/main/post-install/

...even in een nieuwe reactie, want volgens mij snap ik het nu:

De instelling die ik nu heb, zorgt ervoor dat de DNS zo loopt:
Client -> PiHole -> Router -> PiHole -> Upstream
of, in een extremer geval:
Client -> PiHole -> Router -> PiHole -> Router -> PiHole -> Router -> PiHole -> Upstream

Want, de clients krijgen via de DHCP al door dat de DNS op <IP_PIHOLE> leeft, maar omdat ik die ook nog eens in mijn router gedefinieerd heb als DNS server, krijg je daar de loop.

Ik moet dus in mijn router de upstream definiëren, om zo de loop te doorbreken.

Het enige wat ik dan nog niet zeker weet: moet ik dan de "Conditional Forwarding" aan of uit hebben?

[Anoniem: 567735]

Ben.Hahlen schreef op maandag 21 december 2020 @ 11:31:
Het enige wat ik dan nog niet zeker weet: moet ik dan de "Conditional Forwarding" aan of uit hebben?

Dat hangt er vanaf of je voor lokale lan ook 'mooie adressen' (i.p.v. lokale IP-adressen) hebben wilt in de webinterface als je Pi-Hole niet de DHCP-server is.

Van het weekend heb ik Pi-Hole op een NanoPi NEO3 gezet, en dat draait fantastisch. Ik gebruik DietPi als onderliggend platform. Verder nog DNSCrypt erbij gezet, en gedownclockt naar 400 MHz, de load blijft superlaag.

Neemt op volledige snelheid ongeveer 350mA uit de USB-poort, op 400MHz nog 270mA, dus een USB-poortje op een router voldoet hiervoor best.

[ocaj]

deHakkelaar schreef op maandag 21 december 2020 @ 01:00:


Julie beiden maken de klassieke fout en voeren Pi-hole op als upstream DNS in de router:
https://docs.pi-hole.net/main/post-install/

Nee, volgens mij maak ik die fout niet. Mijn router (fritz-box) is DHCP-server en die geeft als DNS-optie aan dhcp-clients het ip-adres van mijn pihole mee. Zowel voor IPv4 als IPv6.
In de pihole staan de 4 (2x IPv4 + 2 xIPv6)DNS-servers van XS4all als upstream dns ingesteld.

Dus dan krijgen alle clients via DHCP het pihole-adres als DNS-server.
Client -> Pihole -> Upstream

Uitzondering is het gastennetwerk dat de fritz-box aanmaakt. Die clients kunnen niet bij de pihole komen en krijgen het router-adres als dns-server. Om ook het gastennetwerk via de pihole te laten lopen heb ik op de fritzbox ingesteld dat deze de pihole als dns-server moet gebruiken voor dns-queries. Dan krijg je dus:

Gast-Client -> Router -> Pihole -> Upstream

Overigens kwam ik er net achter dat ik mijn proxmox-hostmachine niet op dhcp heb staan en dat die nog naar de router kijkt voor dns. Ook alle LX-containers nemen dit over van de host-machine. Maar dan heb ik nog steeds geen dns-loop, alleen 1 tussenstap meer dan nodig.

Client -> Router -> Pihole -> Upstream

(voor ik dat aanpas moet ik trouwens nog even goed nadenken: Mijn pihole draait nl. als container op mijn proxmox-host. Het voelt niet heel verstandig om de dns-server van de host te laten wijzen naar een container die op diezelfde host draait. Geen idee, of proxmox tijdens het booten DNS nodig heeft, of prima zonder DNS kan booten...)

Maar alles bij elkaar kan dat toch prima werken? Zo niet, dan snap ik nog steeds niet welke "klassieke fout" ik maak...?

[Anoniem: 567735]

Als je in dit scherm het lokale IP-adres (onder lokaler DNS-Server, hoe de vertaling ook maar is in het Nederlands of Engels) hebt staan is het OK:



Als je het in dit scherm doet:



Dan zit je niet OK, dat zijn de upstream DNS-servers (bij mij zijn 192.168.168.2 en 192.168.168.202 lokale ongefilterde DNS(Crypt)-forwarders)

[ Voor 4% gewijzigd door Anoniem: 567735 op 21-12-2020 14:45 ]

[deHakkelaar]

Ben.Hahlen schreef op maandag 21 december 2020 @ 11:31:
[...]

De instelling die ik nu heb, zorgt ervoor dat de DNS zo loopt:
Client -> PiHole -> Router -> PiHole -> Upstream
of, in een extremer geval:
Client -> PiHole -> Router -> PiHole -> Router -> PiHole -> Router -> PiHole -> Upstream
[..]
Het enige wat ik dan nog niet zeker weet: moet ik dan de "Conditional Forwarding" aan of uit hebben?

ocaj schreef op maandag 21 december 2020 @ 13:15:
[...]
Maar alles bij elkaar kan dat toch prima werken?

Ik antwoord maar voor beiden voor het gemak
Dit is de bedoeling wbt DNS queries:

Client --> Pi-hole --> Upstream DNS server(s)

Upstream DNS servers kunnen die zijn die met Pi-hole zijn meegeleverd (Cloudeflare etc), of custome ones zoals bv je eigen router, je Windows DC's of een eigen recursive DNS server zoals bv Unbound:
https://docs.pi-hole.net/guides/unbound/
Als Pi-hole ook DHCP doet, hoef je verder niks meer te doen.

Doet Pi-hole geen DHCP, dan zal op de web GUI alleen IP's worden weergegeven en geen hostnamen vd clients.
Dit omdat alleen de DHCP doos van de hostnamen van clients af weet.
Tijdens de DHCP dialoog adverteerd de client namelijk zijn eigen hostname aan de DHCP server:

code:

dehakkelaar@laptop:~$ cat /etc/dhcp/dhclient.conf
[..]
send host-name = gethostname();

En aangezien de meeste "smart routers" ook een caching DNS service draaien, worden dan automatisch PTR, A en AAAA DNS records aangemaakt voor de clients.
Om toch hostnamen weer te geven in deze situatie heeft Pi-hole de "conditional forwarding" (CF) optie in het leven geroepen.
Pi-hole doet dan voor nieuw ontdekte LAN (private) IP addressen namelijk een reverse lookup tegen de doos die DHCP doet vergelijkbaar met onderstaande:

code:

pi@ph5:~ $ host 10.0.0.220 localhost
Using domain server:
Name: localhost
Address: ::1#53
Aliases:

220.0.0.10.in-addr.arpa domain name pointer laptop.dehakkelaar.nl.

Pi-hole ververst/update deze ook, ik geloof, om het uur.

Door die CF optie kan dus ook een DNS forwarding loop ontstaan en dan zie je duizenden van dezelfde queries op de web GUI die maar looptie loop doen

[jellebelle]

deHakkelaar schreef op maandag 21 december 2020 @ 01:53:
Ja dat kan lastig zijn.
Ik kan alles IPv6 aan de LAN zijde uitschakelen in de router.

Dank dank voor de uitgebreide reactie.
Ik heb maar zeer beperkte instelmogelijkheden voor IPv6, echter na wat vinkjes en ook "Number of adresses" op "0" te hebben gezet lijkt het erop dat ik er ben. Fingers crossed...

[deHakkelaar]

jellebelle schreef op maandag 21 december 2020 @ 19:06:
[...]
Ik heb maar zeer beperkte instelmogelijkheden voor IPv6, echter na wat vinkjes en ook "Number of adresses" op "0" te hebben gezet lijkt het erop dat ik er ben. Fingers crossed...

Hmm kans is groot dat clients nog steeds via IPv6 router discovery een ongewenste DNS server toegespeeld krijgen:

deHakkelaar schreef op maandag 21 december 2020 @ 01:53:
[...]
Grote kans dat de clients ook een DNS server gebruiken die niet Pi-holed is.
Grote kans dat ze een DNS server(s) hebben toegewezen gekregen via IPv6 router discovery.
Check DNS servers toegewezen/discovered/geconfigureerd in een Windows command prompt met onderstaande twee:

code:

netsh interface ipv4 show dnsservers

code:

netsh interface ipv6 show dnsservers

Op de Linux client kun je met onderstaande controleren

code:

cat /etc/resolv.conf

Voor Android heb je de "Network Info" app.
Voor de iPad zal wel een vergelijkbare app beschikbaar zijn.
[...]

DHCPv6 is namelijk wat anders als IPv6 router discovery.
Maar ik heb bitter weinig ervaring met IPv6 dus wacht maar totdat iemand anders langs komt die het misschien haarfijn kan uitleggen.

Ps. Onderstaande FAQ kan daarbij ook helpen:
https://discourse.pi-hole...ddresses-for-pi-hole/2127

[ed1703]

jellebelle schreef op maandag 21 december 2020 @ 19:06:
[...]


Dank dank voor de uitgebreide reactie.
Ik heb maar zeer beperkte instelmogelijkheden voor IPv6, echter na wat vinkjes en ook "Number of adresses" op "0" te hebben gezet lijkt het erop dat ik er ben. Fingers crossed...

[Afbeelding]

De vraag is dan of SLAAC ook uit staat, want anders is het dus nog steeds mogelijk dat systemen een ipv6 adres krijgen en aannemelijk de dns adressen van ziggo. Is SLAAC überhaupt wel uit te zetten op die box?

[jellebelle]

ed1703 schreef op maandag 21 december 2020 @ 19:56:
[...]

De vraag is dan of SLAAC ook uit staat, want anders is het dus nog steeds mogelijk dat systemen een ipv6 adres krijgen en aannemelijk de dns adressen van ziggo. Is SLAAC überhaupt wel uit te zetten op die box?

Ja volgens mij wel.
Zie eerdere screenshot, heb dus ook vinkje gezet bij "Disable Stateless Dhcpv6"

[jellebelle]

deHakkelaar schreef op maandag 21 december 2020 @ 01:53:
Check DNS servers toegewezen/discovered/geconfigureerd in een Windows command prompt met onderstaande twee:

code:

netsh interface ipv4 show dnsservers

code:

netsh interface ipv6 show dnsservers

Output bij IPv4 is wenselijk:

code:

Configuration for interface "Wi-Fi"
    DNS servers configured through DHCP:  192.168.178.30
    Register with which suffix:           Primary only

Output bij IPv6 is als volgt:

code:

Configuration for interface "Wi-Fi"
    DNS servers configured through DHCP:  2001:b88:1002::10
                                          2001:b88:1202::10
                                          2001:730:3e42:1000::53
    Register with which suffix:           Primary only

Ik kan dit niet helemaal doorgronden... echter sinds de wijzigingen in het router bij LAN DHCPv6 lijkt het wel opgelost want in het modem/ router van Ziggo zie ik in het overzicht met verbonden clients uitsluitend nog IPv4 adressen. Ik denk dat op het LAN IPv6 nu wel echt ge-killed is!

[deHakkelaar]

jellebelle schreef op maandag 21 december 2020 @ 22:37:
[...]
Output bij IPv6 is als volgt:

code:

Configuration for interface "Wi-Fi"
    DNS servers configured through DHCP:  2001:b88:1002::10
                                          2001:b88:1202::10
                                          2001:730:3e42:1000::53
    Register with which suffix:           Primary only

Die zijn van Ziggo en dus niet Pi-holed:

code:

pi@ph5:~ $ host 2001:b88:1002::10
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.1.8.8.b.0.1.0.0.2.ip6.arpa domain name pointer dns-resolver1-mnd-anycast.ziggo.nl.

EDIT: Let wel op, als je iets wijzigt, breng dan de test client netwerk verbinding down en weer up zodat de wijzigingen kunnen propageren/actief worden.

EDIT:2 Als onderstaande voor jouw op de Windows PC resolved naar IP addressen heb je dus een lek en werkt Pi-hole niet volledig effectief:

code:

nslookup tweakers.net 2001:b88:1002::10

EDIT3: Als je dit op de één of andere manier kan verstoren, zullen de clients gewoon terug vallen op het IPv4 address van Pi-hole voor DNS.

[ Voor 26% gewijzigd door deHakkelaar op 21-12-2020 23:12 ]

[nero355]

Anoniem: 567735 schreef op maandag 21 december 2020 @ 12:04:
Van het weekend heb ik Pi-Hole op een NanoPi NEO3 gezet, en dat draait fantastisch. Ik gebruik DietPi als onderliggend platform. Verder nog DNSCrypt erbij gezet, en gedownclockt naar 400 MHz, de load blijft superlaag.

Neemt op volledige snelheid ongeveer 350mA uit de USB-poort, op 400MHz nog 270mA, dus een USB-poortje op een router voldoet hiervoor best.

Waren deze vroeger niet voor minder dan € 10 tekoop

En is deze nieuwe versie tenminste wat beter te doen qua koeling dan de voorganger ?
Die werd vaak erg warm bij het minste geringste qua belasting!

ocaj schreef op maandag 21 december 2020 @ 13:15:
(voor ik dat aanpas moet ik trouwens nog even goed nadenken: Mijn pihole draait nl. als container op mijn proxmox-host. Het voelt niet heel verstandig om de dns-server van de host te laten wijzen naar een container die op diezelfde host draait. Geen idee, of proxmox tijdens het booten DNS nodig heeft, of prima zonder DNS kan booten...)

Je hebt DNS nodig zodat het NTP proces zijn werk kan doen onder andere dus... JA, er moet een volledig werkende verbinding beschikbaar zijn tijdens het booten

[ocaj]

deHakkelaar schreef op maandag 21 december 2020 @ 18:21:


Door die CF optie kan dus ook een DNS forwarding loop ontstaan en dan zie je duizenden van dezelfde queries op de web GUI die maar looptie loop doen

O ja, de conditional forwarding, die zou inderdaad een loop kunnen creëeren. Ik heb de CF ingesteld zodat hij beperkt is tot het "fritz.box"-domein en de Fritzbox is daar authoritive nameserver van, dus (net nog even gedubbel-checked in wireshark) de DNS-queries die in het kader van CF van de pihole naar de fritzbox gaan komen niet weer terug als query naar de pihole. Er komt direct een DNS-response terug van de fritzbox naar de pihole die de lokale naam vervolgens weer terugstuurt naar de oorspronkelijke client.

nero355 schreef op dinsdag 22 december 2020 @ 00:34:
[...]

Je hebt DNS nodig zodat het NTP proces zijn werk kan doen onder andere dus... JA, er moet een volledig werkende verbinding beschikbaar zijn tijdens het booten

Bedankt, zoiets zij mijn onderbuikgevoel ook al. Voorlopig laat ik de DNS van de host dus maar lekker zo staan. Voor de niet-pihole containers kan ik overwegen om de DNS handmatig in te stellen naar de pihole.

[ericafterdark]

Ik moet even iets testen met Chrome 87, ik gebruik die browser nooit, en merk op dat DNS queries rechtstreeks met Google worden afgehandeld. Chrome maakt geen gebruik van mijn systeeminstellingen (macOS Big Sur).

De "Use secure DNS" instelling is uitgeschakeld maar het probleem blijft.

Iemand enig idee hoe op te lossen?

-edit-

Oplossing gevonden: https://www.reddit.com/r/..._and_nextdns_profile_not/

[ Voor 16% gewijzigd door ericafterdark op 22-12-2020 10:56 ]

[Anoniem: 567735]

nero355 schreef op dinsdag 22 december 2020 @ 00:34:
[...]
Waren deze vroeger niet voor minder dan € 10 tekoop

En is deze nieuwe versie tenminste wat beter te doen qua koeling dan de voorganger ?
Die werd vaak erg warm bij het minste geringste qua belasting!

Je had meen ik ook nog OrangePi en zo, die waren inderdaad wat goedkoper. De NEO3 is nog maar een paar maand uit en heeft ook een USB-C aansluiting voor de stroom. De temperatuursensor geeft op 400MHz 55° aan, als alles standaard staat 62°, in het meegeleverde plastieken doosje. Kan allemaal nog, IMHO. Kwam op € 31,03 inclusief verzending (2GB versie). Kan naast de Gl-iNet router zo mee op reis

Het grotere broertje NanoPi R4S was ook binnen, die draait veel koeler met z'n metalen behuizing natuurlijk.

[Ben.Hahlen]

Hmmm... Moet nog even de tijd vinden om het écht uit te zoeken, maar mijn Wordpress site (https://www.benweb.eu) is een stuk trager dan vóór dat ik PiHole gebruikte...
Ik heb de WordPress ook in Docker zitten, maar het lijkt wel of PiHole bepaalde requests blocked/vertraagd/iets mee doet, waardoor de site een stuk trager is.
Overigens gaat het niet alleen om die Wordpress site, maar ook nog één andere (https://www.mooistemama.nl) én een "simpele" nginx site met database er achter (https://owls.benweb.eu)

Ik zie ook veel van deze requests voorbij komen

code:

Dec 22 16:21:39 dnsmasq[34485]: query[NS] . from 172.23.0.1
Dec 22 16:21:39 dnsmasq[34485]: forwarded . to 192.168.2.1
Dec 22 16:21:40 dnsmasq[34485]: query[NS] . from 172.23.0.1
Dec 22 16:21:40 dnsmasq[34485]: forwarded . to 192.168.2.1

Vraag me af of dat er iets mee te maken heeft...

[ Voor 24% gewijzigd door Ben.Hahlen op 22-12-2020 16:22 ]

[Hulliee]

Ben.Hahlen schreef op dinsdag 22 december 2020 @ 16:21:
Hmmm... Moet nog even de tijd vinden om het écht uit te zoeken, maar mijn Wordpress site (https://www.benweb.eu) is een stuk trager dan vóór dat ik PiHole gebruikte...
Ik heb de WordPress ook in Docker zitten, maar het lijkt wel of PiHole bepaalde requests blocked/vertraagd/iets mee doet, waardoor de site een stuk trager is.
Overigens gaat het niet alleen om die Wordpress site, maar ook nog één andere (https://www.mooistemama.nl) én een "simpele" nginx site met database er achter (https://owls.benweb.eu)

Ik zie ook veel van deze requests voorbij komen

code:

Dec 22 16:21:39 dnsmasq[34485]: query[NS] . from 172.23.0.1
Dec 22 16:21:39 dnsmasq[34485]: forwarded . to 192.168.2.1
Dec 22 16:21:40 dnsmasq[34485]: query[NS] . from 172.23.0.1
Dec 22 16:21:40 dnsmasq[34485]: forwarded . to 192.168.2.1

Vraag me af of dat er iets mee te maken heeft...

Ik denk niet dat het iets met PiHole te maken heeft. Eenmaal wordt het ip-adres aan de url gekoppeld en klaar.

Je moet het zoeken in de webserver die de sites serveert.

[Ben.Hahlen]

Hulliee schreef op dinsdag 22 december 2020 @ 16:53:
[...]
Ik denk niet dat het iets met PiHole te maken heeft. Eenmaal wordt het ip-adres aan de url gekoppeld en klaar.

Je moet het zoeken in de webserver die de sites serveert.

Ik weet het niet... Het is opvallend dat het nu pas gebeurt... Maar goed, ik moet er dus nog naar op zoek.

Ik zie wel deze requests voorbij komen:

code:

Dec 22 17:15:06 dnsmasq[751]: query[NS] . from 172.23.0.1
Dec 22 17:15:06 dnsmasq[751]: forwarded . to 192.168.2.1
Dec 22 17:15:06 dnsmasq[751]: query[AAAA] www.benweb.eu.home from 172.23.0.1
Dec 22 17:15:06 dnsmasq[751]: forwarded www.benweb.eu.home to 192.168.2.1
Dec 22 17:15:06 dnsmasq[751]: query[A] www.benweb.eu.home from 172.23.0.1
Dec 22 17:15:06 dnsmasq[751]: forwarded www.benweb.eu.home to 192.168.2.1
Dec 22 17:15:07 dnsmasq[751]: query[NS] . from 172.23.0.1
Dec 22 17:15:07 dnsmasq[751]: forwarded . to 192.168.2.1
Dec 22 17:15:09 dnsmasq[751]: query[NS] . from 172.23.0.1
Dec 22 17:15:09 dnsmasq[751]: forwarded . to 192.168.2.1

Wat ik daar vooral raar aan vindt is dat er www.benweb.eu.home van gemaakt wordt...

---

Overigens ben ik bezig om mijn setup klaar te maken voor een MACVLan, zodat alle Docker Containers een eigen IP krijgen in "mijn" range, zodat ik, hopelijk, beter kan zien wat waar vandaan komt en evt kan experimenteren met PiHole als DHCP server.

[ Voor 9% gewijzigd door Ben.Hahlen op 22-12-2020 17:18 ]

[nero355]

Ben.Hahlen schreef op dinsdag 22 december 2020 @ 16:21:
Hmmm... Moet nog even de tijd vinden om het écht uit te zoeken, maar mijn Wordpress site (https://www.benweb.eu) is een stuk trager dan vóór dat ik PiHole gebruikte...
Ik heb de WordPress ook in Docker zitten, maar het lijkt wel of PiHole bepaalde requests blocked/vertraagd/iets mee doet, waardoor de site een stuk trager is.
Overigens gaat het niet alleen om die Wordpress site, maar ook nog één andere (https://www.mooistemama.nl) én een "simpele" nginx site met database er achter (https://owls.benweb.eu)

Ik zie echt grote DNS vertragingen in mijn WebGUI Query Log van Pi-Hole als ik die websites opvraag en daarnaast een hoop requests buiten de website om die ook voor vertraging kunnen en ook lijken te zorgen!

Waarop host je het geheel thuis

Ben.Hahlen schreef op dinsdag 22 december 2020 @ 17:16:
Ik zie wel deze requests voorbij komen:

code:

Dec 22 17:15:06 dnsmasq[751]: query[NS] . from 172.23.0.1
Dec 22 17:15:06 dnsmasq[751]: forwarded . to 192.168.2.1
Dec 22 17:15:06 dnsmasq[751]: query[AAAA] www.benweb.eu.home from 172.23.0.1
Dec 22 17:15:06 dnsmasq[751]: forwarded www.benweb.eu.home to 192.168.2.1
Dec 22 17:15:06 dnsmasq[751]: query[A] www.benweb.eu.home from 172.23.0.1
Dec 22 17:15:06 dnsmasq[751]: forwarded www.benweb.eu.home to 192.168.2.1
Dec 22 17:15:07 dnsmasq[751]: query[NS] . from 172.23.0.1
Dec 22 17:15:07 dnsmasq[751]: forwarded . to 192.168.2.1
Dec 22 17:15:09 dnsmasq[751]: query[NS] . from 172.23.0.1
Dec 22 17:15:09 dnsmasq[751]: forwarded . to 192.168.2.1

Wat ik daar vooral raar aan vindt is dat er www.benweb.eu.home van gemaakt wordt...

Dat is normaal en kan je IMHO verder negeren

[deHakkelaar]

Ben.Hahlen schreef op dinsdag 22 december 2020 @ 17:16:
[...]
Wat ik daar vooral raar aan vindt is dat er ]www.benweb.eu.home van gemaakt wordt...

Dat komt waarchijnlijk omdat de domein naam in de query niet verankert is met een puntje op het einde.
Zonder puntje als ik "nslookup -type=a www.benweb.eu" doe op een client:

code:

pi@ph5:~ $ pihole -t
[..]
04:02:06: query[A] www.benweb.eu.dehakkelaar.nl from 10.0.0.11
04:02:06: cached www.benweb.eu.dehakkelaar.nl is NXDOMAIN
04:02:06: query[A] www.benweb.eu from 10.0.0.11
04:02:06: cached www.benweb.eu is 77.166.92.178

Met puntje op het einde "nslookup -type=a www.benweb.eu." vanaf een client:

code:

pi@ph5:~ $ pihole -t
[..]
04:03:27: query[A] www.benweb.eu from 10.0.0.11
04:03:27: cached www.benweb.eu is 77.166.92.178

nslookup, en misschien ook de app die deze queries maakt, plakken zonder dit puntje op het einde, de domain suffix/search domain achter de query:

code:

C:\>ipconfig /all

Windows IP Configuration
[..]
   DNS Suffix Search List. . . . . . : dehakkelaar.nl
[..]

code:

pi@noads:~ $ cat /etc/dnsmasq.d/02-pihole-dhcp.conf
[..]
domain=dehakkelaar.nl

Dat "home" domain moet je zoeken in de instellingen van je router die DHCP doet.

[Ben.Hahlen]

nero355 schreef op dinsdag 22 december 2020 @ 19:51:
[...]
Ik zie echt grote DNS vertragingen in mijn WebGUI Query Log van Pi-Hole als ik die websites opvraag en daarnaast een hoop requests buiten de website om die ook voor vertraging kunnen en ook lijken te zorgen!

Waarop host je het geheel thuis

Nou, hierop:

#	Category	Product	Prijs	Subtotaal
1	Processors	Intel Pentium G4560 Boxed	€ 54,89	€ 54,89
2	Interne harde schijven	Seagate Barracuda Compute 2,5", 2TB	€ 63,90	€ 127,80
1	Barebones	ASRock DeskMini 110	€ 0,-	€ 0,-
1	Geheugen intern	Crucial CT16G4SFD824A	€ 58,36	€ 58,36
1	Solid state drives	Samsung 970 EVO 500GB	€ 73,-	€ 73,-
Bekijk collectie Importeer producten			Totaal	€ 314,05

Ten tijde van het schrijven:

code:

$ cat /proc/loadavg
0.20 0.21 0.24 1/1303 30065

$ free -h
              total        used        free      shared  buff/cache   available
Mem:           15Gi       2.8Gi       9.3Gi       109Mi       3.2Gi        12Gi
Swap:          11Gi          0B        11Gi

Er draaien 25 containers op, wat makkelijk moet kunnen (en zo ziet het er ook uit).
Na wat meer zoeken zie ik dat er meer mensen zijn die problemen hebben met Wordpress containers en de snelheid.
Nu lijkt de gemene deler ook te zijn dat zowel de WordPress images en de NGinx een database (mariadb) gebruiken, welke ook gedeelt wordt met HomeAssistant, dus misschien dat daar nog wat in zit...

Genoeg uit te zoeken in ieder geval!

[...]

Dat is normaal en kan je IMHO verder negeren

Ok. Dank!

deHakkelaar schreef op woensdag 23 december 2020 @ 04:21:
[...]

Dat komt waarchijnlijk omdat de domein naam in de query niet verankert is met een puntje op het einde.
Zonder puntje als ik "nslookup -type=a www.benweb.eu" doe op een client:

code:

pi@ph5:~ $ pihole -t
[..]
04:02:06: query[A] www.benweb.eu.dehakkelaar.nl from 10.0.0.11
04:02:06: cached www.benweb.eu.dehakkelaar.nl is NXDOMAIN
04:02:06: query[A] www.benweb.eu from 10.0.0.11
04:02:06: cached www.benweb.eu is 77.166.92.178

Met puntje op het einde "nslookup -type=a www.benweb.eu." vanaf een client:

code:

pi@ph5:~ $ pihole -t
[..]
04:03:27: query[A] www.benweb.eu from 10.0.0.11
04:03:27: cached www.benweb.eu is 77.166.92.178

nslookup, en misschien ook de app die deze queries maakt, plakken zonder dit puntje op het einde, de domain suffix/search domain achter de query:

code:

C:\>ipconfig /all

Windows IP Configuration
[..]
   DNS Suffix Search List. . . . . . : dehakkelaar.nl
[..]

code:

pi@noads:~ $ cat /etc/dnsmasq.d/02-pihole-dhcp.conf
[..]
domain=dehakkelaar.nl

Dat "home" domain moet je zoeken in de instellingen van je router die DHCP doet.

"home" domain heb ik idd zelf ingesteld, en ook zo in de CIDR instellingen van PiHole ingesteld. Was voornamelijk benieuwd waarom dat er achter gezet werd.

Het is ook direct een learning experience voor mij, dus dank voor alle hulp tot zover.

[jellebelle]

deHakkelaar schreef op maandag 21 december 2020 @ 22:46:
Als onderstaande voor jouw op de Windows PC resolved naar IP addressen heb je dus een lek en werkt Pi-hole niet volledig effectief:

code:

nslookup tweakers.net 2001:b88:1002::10

Nog even feedback geven: Bovenstaande levert een mooie timeout op

Toch zijn op de Windows client bij de Ethernet eigenschappen nog steeds IPv6 DNS servers van Ziggo zichtbaar (uiteraard verbinding down gebracht en DNS cache ge-flushed...)

Maar het goede nieuws is dus, na een paar dagen aankijken, dat 100% geblocked wordt.
De nslookup op de IPv6 DNS servers van Ziggo geeft timeout - dus kennelijk wordt het verstoord.

Hoewel ik het nog niet 100% snap is de missie geslaagd.
Dank aan deHakkerlaar en ed1703, jullie hebben me op het goede spoor gebracht.

Nog even voor de mee-lezers met eenzelfde issue:
LAN IPv6 de nek om draaien met een 'Ziggo Ubee EVW321B' modem/router lijkt gelukt door deze settings aan te houden:



Dus:
- Alle vinkjes uitgezet, en bij 'Disable Stateless' juist geplaatst.
- Number of adresses veranderd van "255" naar "0"

[Ben.Hahlen]

Goed... Ik heb het opgelost...
Het bleek dat ik van binnenin mijn Docker containers géén externe hosts kon resolven en dat is, iig voor Wordpress, een probleem...
Na wat zoekwerk en prutsen, kwam ik er achter dat mijn resolv.conf op mijn host nog op het IP van de host zelf stond (want dat had ik voor het testen zo gedaan, omdat daar ook PiHole draait, met de port exposed).
Na dat aan te passen naar het IP van mijn router, werkt alles weer prima!

Dank nogmaals voor de hulp!

[MdO82]

Wellicht dat iemand mij hier een tip kan geven.
Ik probeer op dit moment mijn blocklist te vullen met domeinen die ik geblokkeerd wil hebben via pi-hole.

Echter als ik mijn gravity wil updaten krijg ik de volgende foutmelding:

code:

[✓] Storing downloaded domains in new gravity database
  [i] Building tree...
  [✗] Unable to build gravity tree in /etc/pihole/gravity_temp.db
  Error: database or disk is full

Probleem wordt volgens mij veroorzaakt doordat ik een ramdrive heb aangemaakt van 1MB welke zorgt dat mijn sd-kaart niet onnodig beschreven wordt.
Althans dat had ik ervan begrepen.

Echter om mijn database te updaten heb ik meer ruimte nodig.

Nu heb ik dit getracht via deze website

cat /etc/fstab
tmpfs /var/tmp tmpfs nodev,nosuid,size=1M 0 0

Echter blijf ik dit houden

sudo systemctl status tmp.mount -l
Unit tmp.mount could not be found.

Kan iemand mij vertellen waar ik moet zoeken ?

[sven123ab]

is het ondertussen al mogelijk om de advertenties/shopping links op google te gebruiken?

[sweetdude]

sven123ab schreef op woensdag 23 december 2020 @ 12:56:
is het ondertussen al mogelijk om de advertenties/shopping links op google te gebruiken?

Is dit dan onmogelijk geweest?
Dit ligt er volgens mij aan welke blocklists je gebruikt. ik gebruik alleen de default lijst en als extra de alom bekende "dbl.oisd.nl" en heb nergens last van.

[ninjazx9r98]

@MdO82
Jouw tmpfs gebruik je voor /var/tmp maar je verwijst naar een verhaal over /tmp
Waarom /var/tmp en wat heb je nu exact gedaan van de instructie op die url?

[MdO82]

ninjazx9r98 schreef op woensdag 23 december 2020 @ 17:30:
@MdO82
Jouw tmpfs gebruik je voor /var/tmp maar je verwijst naar een verhaal over /tmp
Waarom /var/tmp en wat heb je nu exact gedaan van de instructie op die url?

Even stap voor stap

Ik heb een ramdrive gemaakt want daarbij begreep ik dat je sd-kaart een langer leven heeft.
Ik gebruik overigens nog een raspberry b+.

https://www.domoticz.com/...RAM_drive_on_Raspberry_Pi

Deze ramdrive is 1MB

Ik krijg nu de volgende foutmelding bij het updaten van mijn blocklist.

code:

[✗] Unable to build gravity tree in /etc/pihole/gravity_temp.db
  Error: database or disk is full

Als ik zoek op deze foutmelding kom ik uit op deze link.

Daarin geeft diegene aan dat hij ook een ramdrive gebruikt en hierdoor zijn database niet kan wegschrijven omdat de temp dir te klein is.

Er wordt verwezen naar een oplossing, maar daar loop ik op vast.

Waar ik precies vastloop is de stap

sudo sytemctl status tmpmode.service

Alles netjes gevolgd.
Het bestand staat in /etc/systemd/system

Echter krijg ik het volgende te zien

sudo: sytemctl: command not found

[Freee!!]

MdO82 schreef op woensdag 23 december 2020 @ 18:02:
[...]
Even stap voor stap

Ik heb een ramdrive gemaakt want daarbij begreep ik dat je sd-kaart een langer leven heeft.
Ik gebruik overigens nog een raspberry b+.

https://www.domoticz.com/...RAM_drive_on_Raspberry_Pi

Deze ramdrive is 1MB

Ik krijg nu de volgende foutmelding bij het updaten van mijn blocklist.

code:

[✗] Unable to build gravity tree in /etc/pihole/gravity_temp.db
  Error: database or disk is full

Ik ben niet verbaasd met zo'n kleine RAM-drive (1MB is eigenlijk niks meer tegenwoordig).

[Raven]

MdO82 schreef op woensdag 23 december 2020 @ 18:02:
Alles netjes gevolgd.
Het bestand staat in /etc/systemd/system

Echter krijg ik het volgende te zien

sudo: sytemctl: command not found

Heb je de service wel ge-enabled en gestart?

[MdO82]

Raven schreef op woensdag 23 december 2020 @ 18:08:
[...]

Heb je de service wel ge-enabled en gestart?

Volgens de beschrijving heb ik dit uitgevoerd

sudo systemctl daemon-reload
sudo systemctl enable tmpmode.service 
sudo reboot

[ninjazx9r98]

@MdO82
Je hebt dus een ramdrive voor /var/tmp en NIET voor /tmp wat kennelijk nodig is voor het bouwen van de database. Wat is de output van "df -h" en wat is de volledige inhoud van "/etc/fstab"
Ben bang dat je nu een verkeerde afslag hebt genomen doordat je niet goed weet wat je gedaan hebten waar je naar moet zoeken.

[Raven]

MdO82 schreef op woensdag 23 december 2020 @ 18:13:
[...]


Volgens de beschrijving heb ik dit uitgevoerd

sudo systemctl daemon-reload
sudo systemctl enable tmpmode.service 
sudo reboot

Dat zou voldoende moeten zijn, al kun je de reboot waarschijnlijk wel vervangen door sudo systemctl start tmpmode.service. Zie je niet ergens fouten voorbij komen? sudo journalctl -xe bijv.

[ Voor 6% gewijzigd door Raven op 23-12-2020 18:17 ]

[ninjazx9r98]

MdO82 schreef op woensdag 23 december 2020 @ 18:13:
[...]


Volgens de beschrijving heb ik dit uitgevoerd

sudo systemctl daemon-reload
sudo systemctl enable tmpmode.service 
sudo reboot

Maar dat heeft niets met jouw issue te maken, random dingen proberen omdat de foutmelding lijkt op jouw probleem is vaak vragen om nog meer problemen.
De regel uit jouw fstab hoef je dit niet voor te doen.

[ Voor 6% gewijzigd door ninjazx9r98 op 23-12-2020 18:20 ]

[MdO82]

ninjazx9r98 schreef op woensdag 23 december 2020 @ 18:15:
@MdO82
Je hebt dus een ramdrive voor /var/tmp en NIET voor /tmp wat kennelijk nodig is voor het bouwen van de database. Wat is de output van "df -h" en wat is de volledige inhoud van "/etc/fstab"
Ben bang dat je nu een verkeerde afslag hebt genomen doordat je niet goed weet wat je gedaan hebten waar je naar moet zoeken.

@ninjazx9r98

 $ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        15G  2.4G   12G  17% /
devtmpfs        184M     0  184M   0% /dev
tmpfs           216M  1.2M  215M   1% /dev/shm
tmpfs           216M  3.2M  213M   2% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           216M     0  216M   0% /sys/fs/cgroup
tmpfs           1.0M     0  1.0M   0% /var/tmp
/dev/mmcblk0p1  253M   54M  199M  22% /boot
tmpfs            44M     0   44M   0% /run/user/999
tmpfs            44M     0   44M   0% /run/user/1001

Inhoud van /etc/fstab

proc            /proc           proc    defaults          0       0
PARTUUID=6de0a285-01  /boot           vfat    defaults          0       2
PARTUUID=6de0a285-02  /               ext4    defaults,noatime  0       1
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that
tmpfs /var/tmp tmpfs nodev,nosuid,size=1M 0 0

[ninjazx9r98]

@MdO82
Op je root filesystem en dus ook in /tmp heb je 12GB vrij wat ruim voldoende zou moeten zijn als /tmp gebruikt wordt. Als het toch /var/tmp is dan is 1MB veels te klein en kun je er bijv 100 van maken in fstab of (tijdelijk) weglaten en gewoon wat schrijven accepteren. Kwestie van # er voor in fstab of regel verwijderen en een herstart. Zou ook nog kunnen dat er iets verkeerd, wat doe je precies als het mis gaat?

[MdO82]

ninjazx9r98 schreef op woensdag 23 december 2020 @ 18:34:
@MdO82
Op je root filesystem en dus ook in /tmp heb je 12GB vrij wat ruim voldoende zou moeten zijn als /tmp gebruikt wordt. Als het toch /var/tmp is dan is 1MB veels te klein en kun je er bijv 100 van maken in fstab of (tijdelijk) weglaten en gewoon wat schrijven accepteren. Kwestie van # er voor in fstab of regel verwijderen en een herstart. Zou ook nog kunnen dat er iets verkeerd, wat doe je precies als het mis gaat?

@ninjazx9r98 het disabelen van mijn /var/tmp regel heeft het inderdaad opgelost.
Ga hem maar wat groter zetten dan hoef ik niet meer te kloten bij het updaten

[jpgview]

sven123ab schreef op woensdag 23 december 2020 @ 12:56:
is het ondertussen al mogelijk om de advertenties/shopping links op google te gebruiken?

Handleiding hier.

Controleer of het domain (users.telenet.be) niet geblocked is, voor je een bericht stuurt dat de link niet werkt.

[TheCeet]

Pi-hole Core/Web v5.2.2 and FTL v5.3.3 released!

Changelog:
https://pi-hole.net/2020/...-3-released/#page-content

[asing]

Het ging hier niet helemaal van een lijen dakje.

[Webgnome]

@asing Maar is het uiteindelijk wel gelukt? En zo ja hoe heb je het opgelost?

Ik draai hier twee piholes waarvan eentje op Ubuntu 20 en nergens problemen mee. (Behalve dat mijn aangepaste conf overschreven werd door defaults maar dat was zo gefixed. )

[ Voor 56% gewijzigd door Webgnome op 24-12-2020 18:55 ]

[Raven]

Weet iemand toevallig waarom niet alle ip-adressen onder Top Clients (total) en Top Clients (blocked only) om worden gezet naar de hostnamen van de local DNS lijst? De IPv4 en IPv6 adressen die ik heb ingevoerd op de local DNS lijst kloppen wel, dus dat kan het niet zijn en sudo pihole restartdns heeft niet geholpen..

[ Voor 16% gewijzigd door Raven op 24-12-2020 18:29 ]

[jpgview]

Raven schreef op donderdag 24 december 2020 @ 18:28:
Weet iemand toevallig waarom niet alle ip-adressen onder Top Clients (total) en Top Clients (blocked only) om worden gezet naar de hostnamen van de local DNS lijst? De IPv4 en IPv6 adressen die ik heb ingevoerd op de local DNS lijst kloppen wel, dus dat kan het niet zijn en sudo pihole restartdns heeft niet geholpen..

sinds de vorige update gaat pihole-FTL alleen nog maar op zoek naar de DNS naam van de actieve clients.
Als je wil dat pihole-FTL op zoek gaat naar de naam van onbekende maar niet actieve clients, moet je aan /etc/pihole/pihole-FTL.conf (of maak een nieuw bestand als het nog niet bestaat) de setting REFRESH_HOSTNAMES= toevoegen, mogelijke opties zijn REFRESH_HOSTNAMES=IPV4|ALL|NONE|UNKNOWN

IPV4 is de default, alleen voor IPv4 addresen zal een naam worden gezocht.
ALL refreshed alle hostnames die pihole-FTL kan vinden (veel PTR requests)
UNKNOWN refreshed alleen de clients waarvoor nog geen naam gevonden is.

zie deze forum entry voor meer informatie, lees info over de verschillende werking van de settings in de documentatie (UNKNOWN is nog niet opgenomen in de documentatie)

Om het aantal PTR queries in toom te houden raad ik aan een setting voor MAXDBDAYS= toe te voegen aan de settings. Default is 365, ik gebruik 8. Dit zou ook het aantal entries in de table network_addresses beperken en dus het aantal PTR request.

[asing]

Webgnome schreef op donderdag 24 december 2020 @ 17:31:
@asing Maar is het uiteindelijk wel gelukt? En zo ja hoe heb je het opgelost?

Ik draai hier twee piholes waarvan eentje op Ubuntu 20 en nergens problemen mee. (Behalve dat mijn aangepaste conf overschreven werd door defaults maar dat was zo gefixed. )

Ik heb de voorgestelde oplossing gebruikt. Daarna liet hij door.

[Raven]

jpgview schreef op donderdag 24 december 2020 @ 19:23:
[...]


sinds de vorige update gaat pihole-FTL alleen nog maar op zoek naar de DNS naam van de actieve clients.
Als je wil dat pihole-FTL op zoek gaat naar de naam van onbekende maar niet actieve clients, moet je aan /etc/pihole/pihole-FTL.conf (of maak een nieuw bestand als het nog niet bestaat) de setting REFRESH_HOSTNAMES= toevoegen, mogelijke opties zijn REFRESH_HOSTNAMES=IPV4|ALL|NONE|UNKNOWN

IPV4 is de default, alleen voor IPv4 addresen zal een naam worden gezocht.
ALL refreshed alle hostnames die pihole-FTL kan vinden (veel PTR requests)
UNKNOWN refreshed alleen de clients waarvoor nog geen naam gevonden is.

zie deze forum entry voor meer informatie, lees info over de verschillende werking van de settings in de documentatie (UNKNOWN is nog niet opgenomen in de documentatie)

Om het aantal PTR queries in toom te houden raad ik aan een setting voor MAXDBDAYS= toe te voegen aan de settings. Default is 365, ik gebruik 8. Dit zou ook het aantal entries in de table network_addresses beperken en dus het aantal PTR request.

Alleen actieve, dus als een client een aantal uren of een dagje niet actief is geweest dan geeft ie de naam al niet meer weer? Ookal staat die op de local DNS lijst ingevoerd

[jpgview]

Raven schreef op vrijdag 25 december 2020 @ 10:41:
[...]

Alleen actieve, dus als een client een aantal uren of een dagje niet actief is geweest dan geeft ie de naam al niet meer weer? Ookal staat die op de local DNS lijst ingevoerd

Als de naam eenmaal bekend is, zal die altijd worden weergegeven. De clients, IP en naam (indien bekend) kan je terug vinden in de database (/etc/pihole/pihole-FTL.db), table network_addresses.

[deHakkelaar]

Raven schreef op donderdag 24 december 2020 @ 18:28:
Weet iemand toevallig waarom niet alle ip-adressen onder Top Clients (total) en Top Clients (blocked only) om worden gezet naar de hostnamen van de local DNS lijst? De IPv4 en IPv6 adressen die ik heb ingevoerd op de local DNS lijst kloppen wel, dus dat kan het niet zijn en sudo pihole restartdns heeft niet geholpen..

Wat is lokaal geconfigureerd voor DNS ?

code:

cat /etc/resolv.conf

Misschien heb je last van een oude limitatie die mogelijk weer terug is.
Oudere versies moesten in bovenstaande bestandje het localhost IP 127.0.0.1 als enige nameserver zijn opgegeven of anders werden namen niet weergegeven in de GUI.
Je kunt dit handmatig aanpassen tijdelijk voor diagnose.
Dit bestandje zal gewoon weer hersteldt worden, zoals voorheen, met een herstart.
Je zult ook FTL een schop moeten geven:

code:

pihole restartdns

En je browser verversen met CTRL-F5 voor de zekerheid.

[Raven]

deHakkelaar schreef op vrijdag 25 december 2020 @ 13:41:
[...]

Wat is lokaal geconfigureerd voor DNS ?

code:

cat /etc/resolv.conf

Misschien heb je last van een oude limitatie die mogelijk weer terug is.
Oudere versies moesten in bovenstaande bestandje het localhost IP 127.0.0.1 als enige nameserver zijn opgegeven of anders werden namen niet weergegeven in de GUI.
Je kunt dit handmatig aanpassen tijdelijk voor diagnose.
Dit bestandje zal gewoon weer hersteldt worden, zoals voorheen, met een herstart.
Je zult ook FTL een schop moeten geven:

code:

pihole restartdns

En je browser verversen met CTRL-F5 voor de zekerheid.

Ehm, dat bestand bevat gek genoeg alleen

code:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN

systemd-resolve --status laat echter o.a. dit zien:

code:

         DNS Servers: 8.8.8.8
                      8.8.4.4
                      2001:4860:4860::8888
                      2001:4860:4860::8844

In PiHole heb ik OpenDNS geselecteerd, niet Google, dus waar die dan ineens wegkomen

Maar dan nog blijft het vreemd, het lijkt willekeurig te zijn, welke wel omgezet wordt naar naam van de local DNS lijst en welke niet. Als het leeg zijn van /etc/resolv.conf een probleem was, dan had ik niet één hostnaam moeten zien, toch?

[deHakkelaar]

Raven schreef op vrijdag 25 december 2020 @ 13:58:
Ehm, dat bestand bevat gek genoeg alleen

code:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN

Dat is niet gebruikelijk.
Wat geeft onderstaande weer ?

code:

host -v pi.hole

Wat als je daar een regeltje toevoegt:

code:

nameserver 127.0.0.1

En FTL schopt etc en test.

Raven schreef op vrijdag 25 december 2020 @ 13:58:
systemd-resolve --status laat echter o.a. dit zien:

code:

         DNS Servers: 8.8.8.8
                      8.8.4.4
                      2001:4860:4860::8888
                      2001:4860:4860::8844

systemd-resolved is ook een DNS daemon net als pihole-FTL dat is.
Als je deze actief hebt, kan ik me haast niet voorstellen dat pihole-FTL goed werkt aangezien ze dezelfde poorten willen toe eigenen/binden (53 UDP+TCP) en dus conflicteren:

code:

pi@ph5:~ $ man systemd-resolved
[..]
DESCRIPTION
       systemd-resolved is a system service that provides network name
       resolution to local applications. It implements a caching and
       validating DNS/DNSSEC stub resolver, as well as an LLMNR and
       MulticastDNS resolver and responder. Local applications may
       submit network name resolution requests via three interfaces:

code:

pi@ph5:~ $ service systemd-resolved status
[..]
   Active: inactive (dead)

Ik weet niet wat voor distro je draait maar ik zou er voor zorgen dat je netwerk manager wel zorgt dat dat resolv.conf bestandje voorzien wordt van de juiste nameserver(s).
De meeste software lokaal raadpleegt namelijk dit bestandje als deze willen weten welke DNS servers beschikbaar zijn.

Raven schreef op vrijdag 25 december 2020 @ 13:58:
In PiHole heb ik OpenDNS geselecteerd, niet Google, dus waar die dan ineens wegkomen

Dat doet je netwerk manager (voor Pi-OS Buster is dat /etc/dhcpcd.conf).
Meestal door resolvconf aan te sturen (check: man resolvconf).
Deze DNS servers zijn ook bedoeld voor lokaal gebruik.
De upstream DNS servers die je in Pi-hole opgeeft worden alleen exlusief door pihole-FTL zelf gebruikt.

Raven schreef op vrijdag 25 december 2020 @ 13:58:
Als het leeg zijn van /etc/resolv.conf een probleem was, dan had ik niet één hostnaam moeten zien, toch?

Er is gewoon wat mis met jou setup dus moet je ergens beginnen.

[Raven]

@deHakkelaar

"Dat is niet gebruikelijk."
I know, net nog eens gekeken, nu zie ik ineens toch iets staan:

code:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.53

host -v pi.hole:

code:

Trying "pi.hole"
Host pi.hole not found: 3(NXDOMAIN)
Received 25 bytes from 127.0.0.53#53 in 0 ms
Received 25 bytes from 127.0.0.53#53 in 0 ms

De Google DNS'en lijken na enig zoekwerk van /etc/systemd/resolved.conf te komen, waarbij die uiteindelijk in de dynamische /run/systemd/resolve/resolv.conf geplaatst worden, hier zal de output van systemd-resolve --status dan vermoedelijk vandaan komen.

"Als je deze actief hebt, kan ik me haast niet voorstellen dat pihole-FTL goed werkt aangezien ze dezelfde poorten willen toe eigenen/binden (53 UDP+TCP) en dus conflicteren:"
Het gekke is, is dat PiHole verder wel goed werkt, niet alleen bij queries van de Pi waar die op draait maar ook bij de rest van het netwerk, het is alleen het oppikken van veranderingen op de local host lijst dat niet altijd goed gaat.

"Ik weet niet wat voor distro je draait maar ik zou er voor zorgen dat je netwerk manager wel zorgt dat dat resolv.conf bestandje voorzien wordt van de juiste nameserver(s).
De meeste software lokaal raadpleegt namelijk dit bestandje als deze willen weten welke DNS servers beschikbaar zijn."
Raspbian 9, moet nog steeds over naar 10, d'r ligt al een tijdje een externe ssd met gekloonde en geupgrade install voor klaar als alternatief voor het geheugenkaartje dat er nu in zit.

"Er is gewoon wat mis met jou setup dus moet je ergens beginnen."
Ja, maar waar, het gaat alleen om die lijsten op de dashboard i.c.m. de local host lijst, al lijkt de eerdere opmerking over activiteit ( @jpgview ) het wel te zijn. dat alleen dan de local host lijst wordt gechecked. Ik zie namelijk nu ineens een van de namen opgepikt worden, van een client die net weer actief is geworden.

[deHakkelaar]

Raven schreef op vrijdag 25 december 2020 @ 15:05:
host -v pi.hole:

code:

Trying "pi.hole"
Host pi.hole not found: 3(NXDOMAIN)
Received 25 bytes from 127.0.0.53#53 in 0 ms
Received 25 bytes from 127.0.0.53#53 in 0 ms

Dit klopt niet en het lijkt alsof een andere daemon ook aktief is:

code:

pi@ph5:~ $ host pi.hole 127.0.0.53
Using domain server:
Name: 127.0.0.53
Address: 127.0.0.53#53
Aliases:

pi.hole has address 10.0.0.4

Dat pi.hole domein zit in elke Pi-hole installatie ingebakken:

code:

pi@ph5:~ $ cat /etc/pihole/local.list
10.0.0.4 ph5
10.0.0.4 pi.hole

Wat geeft onderstaande twee weer ?

code:

host -c chaos -t txt version.bind

code:

sudo netstat -nltup | grep 'Proto\|:53 '

Mogelijk dat die andere daemon roet in het eten gooit.

[Raven]

@deHakkelaar
De eerste "Host version.bind not found: 2(SERVFAIL)"
De tweede geeft 5 hits:

code:

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      4136/pihole-FTL
tcp6       0      0 :::53                   :::*                    LISTEN      4136/pihole-FTL
udp        0      0 0.0.0.0:53              0.0.0.0:*                           4136/pihole-FTL
udp        0      0 127.0.0.53:53           0.0.0.0:*                           22886/systemd-resol
udp6       0      0 :::53                   :::*                                4136/pihole-FTL

Systemd-resolved is nu disabled, host -v pi.hole geeft nu resultaat . Nu maar afwachten of dat met het niet meteen oppikken van local host DNS is opgelost.

Wat betreft systemd-resolved, die heb ik zelf nooit geactiveerd en het lijkt erop dat de installer van PiHole daar ook niets mee heeft gedaan, kan mij overigens ook geen waarschuwing herinneren hierover.

[ Voor 10% gewijzigd door Raven op 25-12-2020 15:39 ]

[deHakkelaar]

Raven schreef op vrijdag 25 december 2020 @ 15:36:
Systemd-resolved is nu disabled, host -v pi.hole geeft nu resultaat . Nu maar afwachten of dat met het niet meteen oppikken van local host DNS is opgelost.

Als je zeker wilt zijn dat deze ook niet wordt opgestart door weer een ander process, dan mask je hem:

code:

sudo systemctl mask systemd-resolved.service

[Raven]

deHakkelaar schreef op vrijdag 25 december 2020 @ 15:41:
[...]

Als je zeker wilt zijn dat deze ook niet wordt opgestart door weer een ander process, dan mask je hem:

code:

sudo systemctl mask systemd-resolved.service

Done, thanks

[nero355]

Net naar de laatste versie geüpdate en er lijkt één lijst verdwenen te zijn :

[i] Target: https://mirror1.malwaredomains.com/files/justdomains
  [✗] Status: Not found
  [✗] List download failed: no cached list available

Is dit tijdelijk of is er een vervanger onderweg @deHakkelaar

jpgview schreef op vrijdag 25 december 2020 @ 12:39:
Als de naam eenmaal bekend is, zal die altijd worden weergegeven. De clients, IP en naam (indien bekend) kan je terug vinden in de database (/etc/pihole/pihole-FTL.db), table network_addresses.

Hoe staat dat in relatie tot custom.list en de records die ik zelf heb ingevoerd ?

[ Voor 38% gewijzigd door nero355 op 25-12-2020 18:33 ]

[dss58]

Dat pi.hole domein zit in elke Pi-hole installatie ingebakken:

code:

pi@ph5:~ $ cat /etc/pihole/local.list

Dat kun je hier zien

[ Voor 19% gewijzigd door dss58 op 25-12-2020 19:19 ]

[jpgview]

nero355 schreef op vrijdag 25 december 2020 @ 18:32:
Hoe staat dat in relatie tot custom.list en de records die ik zelf heb ingevoerd ?

Als je naar het pihole log kijkt terwijl die opstart, zie je dat die file eenmalig word ingelezen, en dus gebruikt door FTL. Je ziet in het log verschijnen:

Dec 25 19:43:19 dnsmasq[1191]: read /etc/pihole/custom.list - 0 addresses

bij mij geen addressen, ik gebruik een hosts compatible lijst, bij jou dus waarschijnlijk een hoger aantal.

ik heb geen idee of pihole-FTL de nieuwe entries oppikt als je er met de web interface een toevoegd, kijk in het log, hier de manier die ik gebruik.

edit
about https://mirror1.malwaredomains.com/files/justdomains, read here and here
/edit

[ Voor 12% gewijzigd door jpgview op 25-12-2020 20:16 ]

[TheCeet]

nero355 schreef op vrijdag 25 december 2020 @ 18:32:
Net naar de laatste versie geüpdate en er lijkt één lijst verdwenen te zijn :

[i] Target: https://mirror1.malwaredomains.com/files/justdomains
  [✗] Status: Not found
  [✗] List download failed: no cached list available

Is dit tijdelijk of is er een vervanger onderweg @deHakkelaar

[...]

Hoe staat dat in relatie tot custom.list en de records die ik zelf heb ingevoerd ?

Die lijst werkt al paar maand niet meer.
De makers daarvan hebben handdoek in de ring gegooid.

[deHakkelaar]

nero355 schreef op vrijdag 25 december 2020 @ 18:32:
Net naar de laatste versie geüpdate en er lijkt één lijst verdwenen te zijn :

[i] Target: https://mirror1.malwaredomains.com/files/justdomains
  [✗] Status: Not found
  [✗] List download failed: no cached list available

Is dit tijdelijk of is er een vervanger onderweg @deHakkelaar

Geen idee.
Geen update op Twitter dus zal wel het einde zijn van malwaredomains.com:
https://twitter.com/malwaredomains

nero355 schreef op vrijdag 25 december 2020 @ 18:32:
Hoe staat dat in relatie tot custom.list en de records die ik zelf heb ingevoerd ?

Meer een algemeen verhaaltje waar je denk ik het meeste al vanaf weet.
Met alleen de DNS queries van de clients, kun je eigenlijk alleen de IP adressen achterhalen van de clients die de queries maken.
Aan de hand van deze IP adressen kan Pi-hole de hostnamen achterhalen van actieve DHCP clients door een reverse lookup te doen tegen de DHCP server (dmv oa de CF optie):

code:

pi@ph5:~ $ dig +short @10.0.0.4 -x 10.0.0.220 
laptop.

Maar dit werkt alleen als de DHCP server ook (tijdelijke) DNS records aanmaakt (A,AAAA & PTR) zodra een client zich meldt via DHCP voor een lease.
Voor apparaten waarop je een statisch IP adres configureerd (niet het zelfde als "static DHCP lease") zul je dus deze records zelf handmatig moeten opvoeren in de "Local DNS Records" sectie.
Als je local DNS records aanmaakt, worden deze weggeschreven in onderstaande bestandje:

code:

pi@ph5:~ $ cat /etc/pihole/custom.list
10.0.0.1 router
10.0.0.2 noads
10.0.0.3 nas
10.0.0.9 avr

En ook worden A + AAAA + PTR DNS records aangemaakt door embeded dnsmasq die bovenstaande bestandje leest bij het opstarten:

code:

pi@ph5:~ $ dig +short @localhost nas
10.0.0.3

code:

pi@ph5:~ $ dig +short @localhost -x 10.0.0.3
nas.

MAC addressen voor de IP's worden afgeleid van de ARP/neighbor table:

code:

pi@ph5:~ $ arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
10.0.0.2                 ether   b8:27:eb:xx:xx:xx   C                     eth0
10.0.0.1                 ether   50:46:5d:xx:xx:xx   C                     eth0
10.0.0.220               ether   00:1e:0b:xx:xx:xx   C                     eth0

Al deze data wordt gecombineerd en in de dbase gedumpt:

code:

pi@ph5:~ $ sqlite3 /etc/pihole/pihole-FTL.db '.databases'
main: /etc/pihole/pihole-FTL.db

code:

pi@ph5:~ $ sqlite3 /etc/pihole/pihole-FTL.db '.tables'
aliasclient        ftl                network            queries
counters           message            network_addresses

code:

pi@ph5:~ $ sqlite3 /etc/pihole/pihole-FTL.db '.schema network_addresses'
CREATE TABLE IF NOT EXISTS "network_addresses" ( network_id INTEGER NOT NULL, ip TEXT UNIQUE NOT NULL, lastSeen INTEGER NOT NULL DEFAULT (cast(strftime('%s', 'now') as int)), name TEXT, nameUpdated INTEGER, FOREIGN KEY(network_id) REFERENCES network(id));

code:

pi@ph5:~ $ sqlite3 /etc/pihole/pihole-FTL.db '.schema network'
CREATE TABLE IF NOT EXISTS "network" ( id INTEGER PRIMARY KEY NOT NULL, hwaddr TEXT UNIQUE NOT NULL, interface TEXT NOT NULL, firstSeen INTEGER NOT NULL, lastQuery INTEGER NOT NULL, numQueries INTEGER NOT NULL, macVendor TEXT, aliasclient_id INTEGER);

code:

pi@ph5:~ $ sqlite3 --header --column /etc/pihole/pihole-FTL.db 'SELECT * FROM network_addresses'
network_id  ip          lastSeen    name        nameUpdated
----------  ----------  ----------  ----------  -----------
[..]
7           10.0.0.220  1608885600  laptop.deh  1608884040
[..]

code:

pi@ph5:~ $ sqlite3 --header --column /etc/pihole/pihole-FTL.db 'SELECT * FROM network'
id          hwaddr             interface   firstSeen   lastQuery   numQueries  macVendor              aliasclient_id
----------  -----------------  ----------  ----------  ----------  ----------  ---------------------  --------------
[..]
7           00:1f:3c:xx:xx:xx  eth0        1605526860  1607042951  39          Intel Corporate
[..]

Dus als namen niet weegegeven worden kan het liggen aan alles bovenstaand + de web files + firewall + browser addons die kunnen blokkeren

[ Voor 10% gewijzigd door deHakkelaar op 26-12-2020 10:16 . Reden: Vergat de .tables ]

[deHakkelaar]

jpgview schreef op vrijdag 25 december 2020 @ 19:47:
edit
about https://mirror1.malwaredomains.com/files/justdomains, read here and here
/edit

Aha ik zie dat jpgview al wat heeft gevonden:

As of November 30th, 2020, both AutoShun and Malware Domains feeds will be shut off, and subscribers will no longer receive intel from those sources.
We will continue to make a free, non-commercial version of our threat intel, ShadowNet, while the enhanced full-threat intel feed will be licensed to our commercial partners.

Commerciele rotzooi wordt het dus met belangen in belangen.

[andregroeneveld]

Ik heb na de update problemen met verbinding van mijn nest thermostaat met google home. Iemand anders dit ook ervaren en wat kun je er aan doen?

[Raven]

Weet iemand toevallig een work-around/trucje om PiHole zo ver te krijgen mac-adressen op te pikken van apparaten in andere subnets dan waar PiHole zich in bevind?

Onder Tools->Network zie ik alle apparaten die ook in de query-log voorbij komen, maar bij alles buiten het subnet (zowel IPv4 als IPv6) zie ik bij hardware address "N/A" staan, waardoor PiHole verschillende IP-adressen van hetzelfde apparaat niet aan elkaar kan koppelen zoals die met apparaten binnen het subnet doet.

[deHakkelaar]

Raven schreef op zaterdag 26 december 2020 @ 13:09:
Weet iemand toevallig een work-around/trucje om PiHole zo ver te krijgen mac-adressen op te pikken van apparaten in andere subnets dan waar PiHole zich in bevind?

Pi-hole een voetje geven in alle subnets/vlans.
Dus meerdere IP's op de Pi-hole host meegeven (multihomed) desnoods met meerdere interfaces.
Volg onderstaande relaas maar van @Kopernikus.1979 (wel paar pagina lang):
Kopernikus.1979 in "[Pi-Hole] Ervaringen & discussie"

Of indien mogelijk via EDNS:
https://discourse.pi-hole...s0-client-subnet/35940/10

[ Voor 8% gewijzigd door deHakkelaar op 26-12-2020 13:31 ]

[peer]

Waarschijnlijk heb ik ergens een instelling verkeerd.

Ik heb mijn rpi opnieuw geïnstalleerd, hierna pihole met standaard instellingen, extra lijst toegevoegd, dhcp op de ziggo router uit, dhcp van pihole aan en.... Nog steeds overal advertenties.

Mijn vorige installatie werkte perfect, maar helaas, SD kaart defect, nu draait alles op een externe SSD.

Als ik op de admin pagina kijk zie ik rond de 12.5 % geblokt, met een ipconfig /all zie ik ook netjes de rpi als dhcp en dns server.

Waar gaat het mis 🤔

[Webgnome]

zie je de devices die advertenties krijgen wel in de client list? Is het niet simpelweg een kwestie van een extra blocklist toevoegen?

[MdO82]

peer schreef op zaterdag 26 december 2020 @ 13:59:
Waarschijnlijk heb ik ergens een instelling verkeerd.

Ik heb mijn rpi opnieuw geïnstalleerd, hierna pihole met standaard instellingen, extra lijst toegevoegd, dhcp op de ziggo router uit, dhcp van pihole aan en.... Nog steeds overal advertenties.

Mijn vorige installatie werkte perfect, maar helaas, SD kaart defect, nu draait alles op een externe SSD.

Als ik op de admin pagina kijk zie ik rond de 12.5 % geblokt, met een ipconfig /all zie ik ook netjes de rpi als dhcp en dns server.

Waar gaat het mis 🤔

Je ipadressen released ? Zodat ze gehaald worden van je pihole ?

[peer]

Webgnome schreef op zaterdag 26 december 2020 @ 14:00:
zie je de devices die advertenties krijgen wel in de client list? Is het niet simpelweg een kwestie van een extra blocklist toevoegen?

Ja, ik zie alle devices netjes staan, en heb 1, 193, 001 domains in de blocklist

[peer]

MdO82 schreef op zaterdag 26 december 2020 @ 14:02:
[...]


Je ipadressen released ? Zodat ze gehaald worden van je pihole ?

Dat stuk werkt perfect, als ik de netwerkkabel naar de pi eruit haal heb ik geen internet verbinding meer

[Webgnome]

@peer je probeert toch niet toevallig youtube adds te blokkeren he

[ Voor 3% gewijzigd door Webgnome op 26-12-2020 14:08 ]

[peer]

Webgnome schreef op zaterdag 26 december 2020 @ 14:08:
@peer je probeert toch niet toevallig youtube adds te blokkeren he

Haha nee, dan heb ik hier thuis ruzie met 2 pubers 😂

Gewoon de standaard advertenties, overlays e.d zoals op telegraaf.nl spelletjes e.d

Iets wat tot 2 weken geleden met de oude installatie wel werkte.

[andregroeneveld]

andregroeneveld schreef op zaterdag 26 december 2020 @ 12:50:
Ik heb na de update problemen met verbinding van mijn nest thermostaat met google home. Iemand anders dit ook ervaren en wat kun je er aan doen?

Gevonden! Ik was op het verkeerde netwerk ingelogd. Gisteren was er een T-Mobile storing en is het inloggen op het verkeerde netwerk gedaan door de thermostaat. Nu op het andere netwerk ingelogd en werken.

[Raven]

deHakkelaar schreef op zaterdag 26 december 2020 @ 13:27:
[...]

Pi-hole een voetje geven in alle subnets/vlans.
Dus meerdere IP's op de Pi-hole host meegeven (multihomed) desnoods met meerdere interfaces.
Volg onderstaande relaas maar van @Kopernikus.1979 (wel paar pagina lang):
Kopernikus.1979 in "[Pi-Hole] Ervaringen & discussie"

Of indien mogelijk via EDNS:
https://discourse.pi-hole...s0-client-subnet/35940/10

... dus gewoon een paar VLAN interfaces met IP in juiste subnet aanmaken, op de switch aangeven dat de RPi toegang heeft tot die VLAN's en that's it? Zou het zo simpel zijn

Moeten de DNS requests dan ook over die virtuele interfaces binnenkomen of mogen die over de default interface binnen blijven komen? Anders moet ik zowel de dhcpd.conf, radvd.conf, IPv4 en IPv6 firewall aan gaan passen.

edit: Dat netwerkconfig bestand begint met "::: interface eth0", ik zie die ::: niet terug in geGooglede voorbeelden en docs.

[ Voor 5% gewijzigd door Raven op 26-12-2020 14:36 ]

[deHakkelaar]

Raven schreef op zaterdag 26 december 2020 @ 14:22:
[...]
... dus gewoon een paar VLAN interfaces met IP in juiste subnet aanmaken, op de switch aangeven dat de RPi toegang heeft tot die VLAN's en that's it? Zou het zo simpel zijn

Het komt erop neer dat als je de mogelijkheid hebt om meerdere vlans aan dezelfde switch poort te koppelen waaraan pi-hole hangt, je dan de Pi-hole host met extra "aliased IP's" kunt configureren zodanig dat elke extra alias interface een IP heeft in bijbehorend subnet/vlan.
Als dan de clients via DHCP worden geconfigureerd om het desbetreffende IP voor Pi-hole in dat zelfde subnet te gebruiken voor DNS, zul je individuele MAC addresses zien.

EDIT: heb je geen vlan mogelijkheid dan zal je het moeten doen met meerdere fysieke interfaces aangesloten op de verschillende subnets.

EDIT2: Er treed op deze manier geen routing/masquerading op waardoor het source IP of MAC wordt vervangen met die van de gateway.

[ Voor 14% gewijzigd door deHakkelaar op 26-12-2020 14:59 ]

[Raven]

deHakkelaar schreef op zaterdag 26 december 2020 @ 14:44:
[...]

Het komt erop neer dat als je de mogelijkheid hebt om meerdere vlans aan dezelfde switch poort te koppelen waaraan pi-hole hangt, je dan de Pi-hole host met extra "aliased IP's" kunt configureren zodanig dat elke extra alias interface een IP heeft in bijbehorend subnet/vlan.
Als dan de clients via DHCP worden geconfigureerd om het desbetreffende IP voor Pi-hole in dat zelfde subnet te gebruiken voor DNS, zul je individuele MAC addresses zien.

EDIT: heb je geen vlan mogelijkheid dan zal je het moeten doen met meerdere fysieke interfaces aangesloten op de verschillende subnets.

EDIT2: Er treed op deze manier geen routing/masquerading op waardoor het source IP of MAC wordt vervangen met die van de gateway.

I know, ik heb inmiddels de VLAN voor wifi gekoppeld aan de poort waar de Pi met PiHole aan hangt, met behulp van ip commando een virtuele interface aangemaakt en die laat bij ip addr show een IPv6 adres uit de range van dat wifi subnet zien, gevolgd door sudo pihole restartdns na aanmaken config met die interfacenaam.

Die virtuele interface laat echter geen IPv4 adres zien (die als het goed is via DHCP toegewezen zou moeten worden), maar buiten dat zou in het geval van IPv6 PiHole dus nu wel mac adressen te zien moeten krijgen?

[deHakkelaar]

Raven schreef op zaterdag 26 december 2020 @ 15:14:
maar buiten dat zou in het geval van IPv6 PiHole dus nu wel mac adressen te zien moeten krijgen?

IPv6 werkt niet met MAC addressen maar in plaats daarvan met identifiers:
Wikipedia: IPv6 address
Ik zou het niet weten want ik heb geen IPv6

EDIT: ow ps, als je denkt dat het werkt en je doet een nslookup of ping vanaf een client, zul je ze snel genoeg zien op pi-hole met onderstaande:

code:

arp -n

code:

ip neigh

EDIT2: Ik denk ook dat je Pi-hole moet configureren om op alle interfaces the antwoorden/luisteren met:

code:

pihole -a -i all

code:

pi@ph5:~ $ pihole -a -i -h
Usage: pihole -a -i [interface]
Example: 'pihole -a -i local'
Specify dnsmasq's network interface listening behavior

Interfaces:
  local               Listen on all interfaces, but only allow queries from
                      devices that are at most one hop away (local devices)
  single              Listen only on eth0 interface
  all                 Listen on all interfaces, permit all origins

Als dat werkt kan je local instellen om nog veiliger te maken.

EDIT3:

Raven schreef op zaterdag 26 december 2020 @ 15:14:
na aanmaken config met die interfacenaam.

Ow laat bovenstaande dan maar en zorg dat ie op single staat geconfigureerd als je zelf al een bestandje met een interface= regeltje hebt aangemaakt in de dnsmasq.d folder.
Controleren ofdat alle interfaces zijn geconfigureerd met below:

code:

sudo grep interface= -R /etc/dnsmasq.*

[ Voor 65% gewijzigd door deHakkelaar op 26-12-2020 15:42 ]

[nero355]

Raven schreef op zaterdag 26 december 2020 @ 14:22:
... dus gewoon een paar VLAN interfaces met IP in juiste subnet aanmaken, op de switch aangeven dat de RPi toegang heeft tot die VLAN's en that's it? Zou het zo simpel zijn

Wat mij betreft wel, want ik heb het zo al heel lang draaien sinds deze reactie : nero355 in "[Pi-Hole] Ervaringen & discussie"
Die is echter een tijdje geleden helemaal verbouwd naar aanleiding van een discussie over wat er wel of niet allemaal nodig is om het werkend te krijgen dus nu is het misschien niet meer bepaald de meeste handige HowTo zeg maar...

Moeten de DNS requests dan ook over die virtuele interfaces binnenkomen of mogen die over de default interface binnen blijven komen? Anders moet ik zowel de dhcpd.conf, radvd.conf, IPv4 en IPv6 firewall aan gaan passen.

Beide opties zijn... een optie!

Kijk maar wat je fijner/beter vindt

[Raven]

deHakkelaar schreef op zaterdag 26 december 2020 @ 15:18:
[...]

IPv6 werkt niet met MAC addressen maar in plaats daarvan met identifiers:
Wikipedia: IPv6 address
Ik zou het niet weten want ik heb geen IPv6

Oh ja, maar buiten dat, wat in hetzelfde subnet zit werkt dus wel (client identificatie op basis van mac), zowel IPv4 als 6. Van wat ik heb gelezen wordt in het geval van IPv6 NDP gebruikt, zie ook hieronder.

deHakkelaar schreef op zaterdag 26 december 2020 @ 15:18:
EDIT: ow ps, als je denkt dat het werkt en je doet een nslookup of ping vanaf een client, zul je ze snel genoeg zien op pi-hole met onderstaande:

code:

arp -n

code:

ip neigh

Arp -n doet bij mijn weten alleen IPv4, ip neigh zowel IPv4 als IPv6, al kan bij ip neigh de optie -6 nog toegevoegd worden voor IPv6 only. Wanneer ik die 2e uitvoer zie ik in het lijstje in ieder geval één IPv6 adres in het wifi subnet voorbij komen (yay ), maar zonder mac adres erachter ( ) en de regel eindigt met "FAILED", de rest (default subnet 1) wél een mac adres en "STALE" aan het einde. Er lijkt dus toch nog ergens iets mis te gaan.

deHakkelaar schreef op zaterdag 26 december 2020 @ 15:18:

EDIT2: Ik denk ook dat je Pi-hole moet configureren om op alle interfaces the antwoorden/luisteren met:

code:

pihole -a -i all

code:

pi@ph5:~ $ pihole -a -i -h
Usage: pihole -a -i [interface]
Example: 'pihole -a -i local'
Specify dnsmasq's network interface listening behavior

Interfaces:
  local               Listen on all interfaces, but only allow queries from
                      devices that are at most one hop away (local devices)
  single              Listen only on eth0 interface
  all                 Listen on all interfaces, permit all origins

Als dat werkt kan je local instellen om nog veiliger te maken.

Daar staat niets over in die post van @nero355 over de meerdere interfaces, alleen het aanmaken van een config onder /etc/dnsmasq.d/.

deHakkelaar schreef op zaterdag 26 december 2020 @ 15:18:
EDIT3:

[...]

Ow laat bovenstaande dan maar en zorg dat ie op single staat geconfigureerd als je zelf al een bestandje met een interface= regeltje hebt aangemaakt in de dnsmasq.d folder.
Controleren ofdat alle interfaces zijn geconfigureerd met below:

code:

sudo grep interface= -R /etc/dnsmasq.*

/etc/dnsmasq.conf.dpkg-dist:#interface=
/etc/dnsmasq.conf.dpkg-dist:#except-interface=
/etc/dnsmasq.conf.dpkg-dist:#no-dhcp-interface=
/etc/dnsmasq.d/25.conf:interface=eth0.25
/etc/dnsmasq.d/01-pihole.conf:interface=eth0

[nero355]

Raven schreef op zaterdag 26 december 2020 @ 17:23:
Daar staat niets over in die post van @nero355 over de meerdere interfaces, alleen het aanmaken van een config onder /etc/dnsmasq.d/

Dat werkte toen betrouwbaarder

Dus alleen aan eth0 binden en de rest handmatig toevoegen in een eigen config bestandje

[Raven]

nero355 schreef op zaterdag 26 december 2020 @ 18:00:
[...]

Dat werkte toen betrouwbaarder

Dus alleen aan eth0 binden en de rest handmatig toevoegen in een eigen config bestandje

Ik had al iets gelezen over die ene instelling in de webinterface (luisteren op alle interfaces), dat die niet altijd het gewenste effect had

Inmiddels heb ik m.b.v. het ip-commando virtuele interfaces toegevoegd voor alle andere netwerken en alle 3 pikken IPv6 gegevens uit de verschillende subnetten op. IPv4 inmiddels ook, moest blijkbaar de DHCP-client een schop onder de kont geven.

Nu maar afwachten wat PiHole gaat doen.

edit: @deHakkelaar @nero355 PiHole herkent nu MAC-adressen van apparaten uit andere subnets , echter alleen bij IPv4, vooralsnog niet bij IPv6.

[ Voor 10% gewijzigd door Raven op 26-12-2020 18:54 ]

[sweetdude]

voor de geïnteresseerden, FTL 5.3.4 is ook al released met deze fix:

code:

Do not sync after executing regular expression on a domain

[Freee!!]

sweetdude schreef op zaterdag 26 december 2020 @ 19:22:
voor de geïnteresseerden, FTL 5.3.4 is ook al released met deze fix:

code:

Do not sync after executing regular expression on a domain

Sterker, die zit ook al in de Docker containers.

[deHakkelaar]

Raven schreef op zaterdag 26 december 2020 @ 18:28:
Inmiddels heb ik m.b.v. het ip-commando virtuele interfaces toegevoegd voor alle andere netwerken ...

Als je dit "reboot persistent" wilt maken, zie pointers in onderstaande posting:
https://discourse.pi-hole...e-vlan-interfaces/38982/3

[deHakkelaar]

Raven schreef op zaterdag 26 december 2020 @ 14:22:
Moeten de DNS requests dan ook over die virtuele interfaces binnenkomen of mogen die over de default interface binnen blijven komen?

nero355 schreef op zaterdag 26 december 2020 @ 17:21:
Beide opties zijn... een optie!

Ik zou de clients via DHCP configureren zodanig dat ze alleen het IP van de aliased interface gebruiken voor DNS.
De clients zouden eigenlijk ook niet het IP van de fysieke interface kunnen/mogen aanroepen omdat deze in een ander subnet/vlan zit.
Als ze dit toch nog kunnen in de huidige situatie, dan gaat dit waarschijnlijk via een ongewenste route of port forward optie en dan wordt weer in Pi-hole de gateway geregistreerd ipv de clients.

[Raven]

deHakkelaar schreef op zondag 27 december 2020 @ 05:24:
[...]

Als je dit "reboot persistent" wilt maken, zie pointers in onderstaande posting:
https://discourse.pi-hole...e-vlan-interfaces/38982/3

/etc/network/interfaces wordt toch (vrijwel) niet meer gebruikt?

deHakkelaar schreef op zondag 27 december 2020 @ 06:07:
[...]


[...]


Ik zou de clients via DHCP configureren zodanig dat ze alleen het IP van de aliased interface gebruiken voor DNS.
De clients zouden eigenlijk ook niet het IP van de fysieke interface kunnen/mogen aanroepen omdat deze in een ander subnet/vlan zit.
Als ze dit toch nog kunnen in de huidige situatie, dan gaat dit waarschijnlijk via een ongewenste route of port forward optie en dan wordt weer in Pi-hole de gateway geregistreerd ipv de clients.

Ondanks dat dat toch zo gaat hier, lijkt het wel te werken, behalve IPv6 dus nog. Om de een of andere reden zou het meest gebruikte IPv6 adres (van mijn Galaxy S7) voor het laatst op "2020-12-26 14:55:03" een query gedaan hebben (aldus het overzicht op Tools->Network), de query log zegt toch echter heel wat anders.

ip neigh laat nu meer IPv6 adressen zien in ander subnet, maar allen zonder MAC en allen met FAILED erachter, buiten een fe80 adres waar wel de MAC achter verschijnt plus STALE.

[ Voor 6% gewijzigd door Raven op 27-12-2020 10:59 ]

[peer]

Mijn probleem is opgelost, 2 weken geleden was er hier een ziggo monteur ivm storing op het aop, voor ik het wist had hij het modem gereset, deze zou oude firmware hebben.

Blijkbaar heeft voor die reset het hele ipv6 nooit gewerkt, nu dus wel.

Ik heb bij ziggo een ipv4 profiel aangevraagd en sinds vanochtend gaan alle requests netjes via de rpi met pihole ipv direct via ipv6 naar de ziggo dns server

[nachtwaker]

Denk dat die vraag mogelijk al een keer is gesteld maar kan er niks over vinden, is er een snelle manier om de adlist van https://dbl.oisd.nl/ te importeren op mijn pi hole die draait op Raspbian? Volgende punt is hoe kan je versnellen dat de updates van de ad list sneller verlopen?

[Freee!!]

nachtwaker schreef op zondag 27 december 2020 @ 13:44:
Denk dat die vraag mogelijk al een keer is gesteld maar kan er niks over vinden, is er een snelle manier om de adlist van https://dbl.oisd.nl/ te importeren op mijn pi hole die draait op Raspbian?

Gewoon dat url toevoegen aan het lijstje van urls met blocklists.

Volgende punt is hoe kan je versnellen dat de updates van de ad list sneller verlopen?

Lastig

[nachtwaker]

Dus binnen Pi hole onder Group Management -> Adlists -> add a new adlist en daar https://dbl.oisd.nl/ toevoegen?

[Valderrama]

Over lijsten gesproken...

Hier sinds twee dagen een Pihole geïnstalleerd. Werkt prima. De 2 default lists blokkeren “maar” zo’n 9 a 10% van het verkeer. Het zijn nou ook weer niet onwijs veel adressen die in die lijsten staan.

Wat is nu eigenlijk een mist have lijst om toe te voegen aan de standaard twee stuks? Waar ik niet snel tegen aan wil lopen overigens is dat legitieme sites niet meer default bereikbaar zijn.

[Freee!!]

nachtwaker schreef op zondag 27 december 2020 @ 13:57:
Dus binnen Pi hole onder Group Management -> Adlists -> add a new adlist en daar https://dbl.oisd.nl/ toevoegen?

Precies

[Freee!!]

Valderrama schreef op zondag 27 december 2020 @ 14:00:
Over lijsten gesproken...

Hier sinds twee dagen een Pihole geïnstalleerd. Werkt prima. De 2 default lists blokkeren “maar” zo’n 9 a 10% van het verkeer. Het zijn nou ook weer niet onwijs veel adressen die in die lijsten staan.

Wat is nu eigenlijk een mist have lijst om toe te voegen aan de standaard twee stuks? Waar ik niet snel tegen aan wil lopen overigens is dat legitieme sites niet meer default bereikbaar zijn.

De pal boven je genoemde https://dbl.oisd.nl/
Overigens ben ik verbaasd, dat je er maar twee hebt. Toen ik ermee begon, waren het er zeven.

[Valderrama]

Dan zal ik die lijst gaan toevoegen.

Ik heb Pihole geïnstalleerd naast het al geïnstalleerde Homebridge op een Pi4. Daar middels ssh op ingelogd en vanuit het setup menu gekozen voor een Pihole installatie. Het zijn wel de laatste versies en in die lijst waren er maar 2 lijsten die ik kon kiezen...

Edit: inmiddels de lijst toegevoegd. Nu zo’n 1miljoen adressen erbij. Ben benieuwd naar hoeveel er nu geblokkeerd zal gaan worden in ons internetgebruik.

[ Voor 20% gewijzigd door Valderrama op 27-12-2020 14:13 ]

[nachtwaker]

Dat werkt dus niet, zie overal advertenties voorbij komen

[nachtwaker]

hmm laat maar, lokale dns stond niet goed

[deHakkelaar]

Raven schreef op zondag 27 december 2020 @ 10:52:
/etc/network/interfaces wordt toch (vrijwel) niet meer gebruikt?

Niet gebruikt voor IP addressen zoals vroeger als je al een netwerk manager aktief hebt zoals bv dhcpcd5, network-manager of systemd-networkd.
Maar aangezien ifupdown nog steeds wordt gebruikt door oa Pi-OS/Debian:

pi@ph5:~ $ apt policy ifupdown
ifupdown:
  Installed: 0.8.35

pi@ph5:~ $ service ifupdown-pre status
[..]
   Active: active (exited) since Fri 2020-12-25 10:54:54 CET; 3 days ago

En deze doet wat in het interfaces bestandje geconfigureerd staat:

pi@ph5:~ $ apt show ifupdown
[..]
Description: high level tools to configure network interfaces
 This package provides the tools ifup and ifdown which may be used to
 configure (or, respectively, deconfigure) network interfaces based on
 interface definitions in the file /etc/network/interfaces.

Valt deze nog prima te gebruiken om alleen de aliased interfaces aan te maken en UP te brengen.
Ik zou namelijk niet weten hoe je dit moet doen met dhcpcd5 of welk andere network manager ... nog

Wat betreft MAC's en IPv6, ik betwijfel of via IPv6 only wel een MAC valt te achterhalen.
Zoek op Pi-hole Discourse en misschien vindt je daar een antwoord ???
Of stel de vraag daar.