[Pi-Hole] Ervaringen & discussie

[deHakkelaar]

nero355 schreef op vrijdag 24 juni 2022 @ 16:52:
Je moet dus echt aan de bak met je eigen Webserver voor dat soort dingen : https://discourse.pi-hole...ast-dont-phone-home/12906

Hangt er vanaf welk protocol/taaltje wordt gecommuniceerd.
Als dit geen HTML is zul je wat anders moeten fabriceren wat een juist antwoord geeft om het spammen te stoppen.
Plus jou linkje is voor een HTTP antwoord en dat wordt lastiger als het protocol HTTPS omvat met SSL/TLS certificaten die moeten valideren.
Praktisch onmogelijk zonder MITM en hack.

EDIT:

Church of Noise schreef op woensdag 22 juni 2022 @ 15:00:
(1) Dit blijkt wel degelijk een endpoint voor diagnostics, voor Office specifiek: https://www.bsi.bund.de/S..._blob=publicationFile&v=1

Uit de PDF:

WinINet constructs POST requests such that each request encapsulates multiple diagnostic events.
HttpSendRequestW issues POST requests to
self.events.data.microsoft.com/OneCollector/1.0 through an encrypted communication channel.

Dus kans is groot dat je het niet kunt doen met HTTP uit de link van @nero355.

[ Voor 36% gewijzigd door deHakkelaar op 24-06-2022 20:09 ]

[nero355]

deHakkelaar schreef op vrijdag 24 juni 2022 @ 18:28:
Hangt er vanaf welk protocol/taaltje wordt gecommuniceerd.
Als dit geen HTML is zul je wat anders moeten fabriceren wat een juist antwoord geeft om het spammen te stoppen.
Plus jou linkje is voor een HTTP antwoord en dat wordt lastiger als het protocol HTTPS omvat met SSL/TLS certificaten die moeten valideren.
Praktisch onmogelijk zonder MITM en hack.

Dat is helaas inderdaad steeds meer de trend

[deHakkelaar]

Ik denk dat je meer success hebt als je deze in het OS kan uit zetten:

When deployed, it is available
in the form of a group policy setting at the policy path User Configuration\Administrative
Templates\Microsoft Office 2016\Privacy\Trust Center\Configure the level of
client software diagnostic data sent by Office to Microsoft. It allows users to configure one
of the following diagnostic data levels:
• required: this level configures Office to send to Microsoft the “minimum data needed to keep Office
secure, up-to-date, and performing as expected on the device it's installed” (cit., from the group policy
setting description);
• optional: this level configures Office to send to Microsoft “additional data that helps make product
improvements and provides enhanced information to help detect, diagnose, and remediate issues” (cit., from
the group policy setting description);
• neither: this level configures Office such that “no diagnostic data about Office client software running
on the user's device is sent to Microsoft” (cit., from the group policy setting description).
When the policy setting is not configured, the level optional is applied. For the sake of simplicity, this
work refers to the policy setting Configure the level of client software diagnostic data
sent by Office to Microsoft as Office diagnostic level. Configuring the diagnostic data level
required, optional, or neither results in setting the registry value HKEY_CURRENT_USER\
Software\Policies\Microsoft\office\common\clienttelemetry\sendtelemetry to 1, 2,
and 3, respectively.

https://www.bsi.bund.de/S..._blob=publicationFile&v=1

[deHakkelaar]

@Church of Noise , zat zo te denken, bovenstaande registry waarde kun je vermoedelijk niet wijzigen vanwege bedrijfs policy.
Maar je kunt vermoedelijk wel onderstaande regeltje toevoegen aan het C:\Windows\System32\drivers\etc\hosts bestandje of toch ook niet?

code:

0.0.0.0  self.events.data.microsoft.com

Dan zal deze MS client nog steeds elke keer proberen te verbinden met self.events.data.microsoft.com , maar deze naam naar IP verzoekjes zullen dan niet meer aan Pi-hole gevraagd worden.
En zoals ik al eerder had aangetoond, geen time-out wachttijden:

pi@ph5b:~ $ time nc -vz 0.0.0.0 999
nc: connect to 0.0.0.0 port 999 (tcp) failed: Connection refused

real    0m0.031s
user    0m0.010s
sys     0m0.016s

EDIT: Ow misschien moet je ook een IPv6 adres toevoegen als je die hebt op je LAN:

code:

::  self.events.data.microsoft.com

pi@ph5b:~ $ time nc -vz :: 999
nc: connect to :: port 999 (tcp) failed: Connection refused

real    0m0.032s
user    0m0.010s
sys     0m0.016s

[ Voor 16% gewijzigd door deHakkelaar op 25-06-2022 22:00 ]

[mrdemc]

deHakkelaar schreef op zaterdag 25 juni 2022 @ 21:49:
@Church of Noise , zat zo te denken, bovenstaande registry waarde kun je vermoedelijk niet wijzigen vanwege bedrijfs policy.
Maar je kunt vermoedelijk wel onderstaande regeltje toevoegen aan het C:\Windows\System32\drivers\etc\hosts bestandje of toch ook niet?

code:

0.0.0.0  self.events.data.microsoft.com

Dan zal deze MS client nog steeds elke keer proberen te verbinden met self.events.data.microsoft.com , maar deze naam naar IP verzoekjes zullen dan niet meer aan Pi-hole gevraagd worden.
En zoals ik al eerder had aangetoond, geen time-out wachttijden:

pi@ph5b:~ $ time nc -vz 0.0.0.0 999
nc: connect to 0.0.0.0 port 999 (tcp) failed: Connection refused

real    0m0.031s
user    0m0.010s
sys     0m0.016s

EDIT: Ow misschien moet je ook een IPv6 adres toevoegen als je die hebt op je LAN:

code:

::  self.events.data.microsoft.com

pi@ph5b:~ $ time nc -vz :: 999
nc: connect to :: port 999 (tcp) failed: Connection refused

real    0m0.032s
user    0m0.010s
sys     0m0.016s

Voor het aanpassen van het hosts bestand heb je admin-rechten nodig (gelukkig), dus als je geen register aanpassingen kan doen, dan waarschijnlijk ook geen hosts wijzigingen

[Klippy]

Ik was vandaag nog eens aan het proberen die DNS packet size waarschuwingen weg te krijgen, maar met aanbevolen config edns-packet-max=1232 werken sommige apps op mijn Android telefoon niet meer.

Paar maanden geleden ook geprobeerd met dezelfde issues, maar ik snap niet goed wat er gebeurd.

Want zonder max packet settings werkt alles, dus de waarschuwing reducing dns packet size to 1232 lijkt niet helemaal te doen wat het zegt, tenzij dit de packets afkapt oid en de setting de packets niet eens doorlaat.
Maar los van dat, vraag ik me wel af wat er dan aan de hand is en of er een oplossing is.

Apps die bijvoorbeeld niet meer werken zijn 1Limburg en Perfect Player.
Kan ik op mijn telefoon DNS settings aanpassen? Op Windows heb ik verder nog geen problemen gezien met de setting aan.

Ik draai pihole in Docker gebruik cloudflared in Alpine Docker als DNS server overigens...

[deHakkelaar]

@Klippy , edns-packet-max=1232 is voor de optimale situatie.
Maar je kunt hem ook opschroeven naar bv 1472 (1500 max voor ethernet zonder jumbo) wat voorheen werdt aangeraden en bij mij prima werkte voor een lange tijd.
Of als cloudflared je upstream is in een Docker omgeving, gewoon dat regeltje weg laten in de configuratie zodat de default waarde wordt aangenomen:

pi@ph5b:~ $ man dnsmasq
[..]
       -P, --edns-packet-max=<size>
              Specify the largest EDNS.0 UDP packet which  is  supported
              by  the  DNS  forwarder.  Defaults  to  4096, which is the
              RFC5625-recommended size.

[ Voor 3% gewijzigd door deHakkelaar op 25-06-2022 23:12 ]

[dss58]

deHakkelaar schreef op zaterdag 25 juni 2022 @ 21:49:
@Church of Noise , zat zo te denken, bovenstaande registry waarde kun je vermoedelijk niet wijzigen vanwege bedrijfs policy.
Maar je kunt vermoedelijk wel onderstaande regeltje toevoegen aan het C:\Windows\System32\drivers\etc\hosts bestandje of toch ook niet?

code:

0.0.0.0  self.events.data.microsoft.com

Dan zal deze MS client nog steeds elke keer proberen te verbinden met self.events.data.microsoft.com , maar deze naam naar IP verzoekjes zullen dan niet meer aan Pi-hole gevraagd worden.
En zoals ik al eerder had aangetoond, geen time-out wachttijden:

pi@ph5b:~ $ time nc -vz 0.0.0.0 999
nc: connect to 0.0.0.0 port 999 (tcp) failed: Connection refused

real    0m0.031s
user    0m0.010s
sys     0m0.016s

EDIT: Ow misschien moet je ook een IPv6 adres toevoegen als je die hebt op je LAN:

code:

::  self.events.data.microsoft.com

pi@ph5b:~ $ time nc -vz :: 999
nc: connect to :: port 999 (tcp) failed: Connection refused

real    0m0.032s
user    0m0.010s
sys     0m0.016s

die C:\Windows\System32\drivers\etc\hosts een domain toevoegen heb ik geprobeerd, werkt lang niet altijd, sommige apps onder win10 'kijken' blijkbaar niet naar hosts

[Klippy]

@deHakkelaar Dank voor je antwoord, maar met een hogere waarde krijg ik nog steeds die waarschuwing bij alles groter dan 1232, dus dan kan ik de configuratie net zo goed helemaal weg laten.

[deHakkelaar]

@Klippy , wat ik ervan heb begrepen is dat deze instelling is bedoeld om ervoor te zorgen dat UDP packets al vroeger in het proces worden gefragmenteerd naar TCP ipv UDP.
Als dit niet zou gebeuren, zijn er effectief meer packets nodig die heen en weer worden gecommuniceerd als time-outs onstaan doordat de UDP packet grote te groot is voor upstream.
Maar aangezien cloudflared je upstream is, laat deze dat dan maar lekker uitzoeken

EDIT: Als ik erover nadenk, mogelijk kan jou probleem ook ontstaan als in je docker omgeving het TCP verkeer naar je cloudflared container niet doorkomt.
Geen idee hoe dit te controleren in een Docker omgeving maar zorg ervoor dat je poort vertalingen in je Docker config zowel voor 53 UDP & TCP toepast!
En dat enige firewall ook 53 UDP & TCP doorlaat (EDIT: niet voor je WAN uiteraard)!

[ Voor 31% gewijzigd door deHakkelaar op 25-06-2022 23:38 ]

[Klippy]

Hmm, die zoekt het nu uit, maar ik wilde van die vele waarschuwingen af. Ik zal nog eens met de settings spelen als het ze naar TCP omzet kan een hogere setting misschien toch helpen en de waarschuwing onderdrukken.

[Klippy]

Ah dank voor de edit, mogelijk, maar ik geloof dat poort 53 alles doorlaat nu, zal het morgen eens controleren.

[Klippy]

Sorry voor de triple post, maar weer dank aan @deHakkelaar
Ik had inderdaad voor cloudflared alleen UDP in Docker open staan (werkt al heel lang zo dus niet aan gedacht verder).
Maar het is logisch dat grotere pakketen dan via TCP gaan, dus je hint over UDP en TCP was zeer welkom

Moest nog even opzoeken hoe ik dan beide open zet want alleen TCP werkt niet, maar dat is dus gewoon met 2x de poort mappen

code:

 -p 5054:5054/udp \
 -p 5054:5054/tcp \

Lijkt nu perfect te werken

Overigens vind ik het dan wel apart dat Pihole diagnosis je kapot spamt over grotere packages maar dus niks zegt over dat de upstream DNS niet via TCP te benaderen is in dat geval.

[nero355]

Klippy schreef op zondag 26 juni 2022 @ 14:41:
Overigens vind ik het dan wel apart dat Pihole diagnosis je kapot spamt over grotere packages maar dus niks zegt over dat de upstream DNS niet via TCP te benaderen is in dat geval.

Omdat de hele insteek uitgaat van directe communicatie en geen Docker Container toestanden gok ik

TIP : Laat @Freee!! je effe vertellen hoeveel blijer je wordt van een MACVLAN opzet van je hele Docker Network

[Freee!!]

nero355 schreef op zondag 26 juni 2022 @ 14:48:
[...]
Omdat de hele insteek uitgaat van directe communicatie en geen Docker Container toestanden gok ik

TIP : Laat @Freee!! je effe vertellen hoeveel blijer je wordt van een MACVLAN opzet van je hele Docker Network

Niet het hele Docker Network, maar het is wel fijn als services zoals Pi-Hole en Unbound hun eigen IP-adres hebben, dan loop je niet te kloten met poort-mappings.

[Raven]

Klippy schreef op zaterdag 25 juni 2022 @ 22:29:
Ik was vandaag nog eens aan het proberen die DNS packet size waarschuwingen weg te krijgen,

* Raven krijgt die ook, maar niet continu , met name

code:

reducing DNS packet size for nameserver 2606:4700:4700::1001 to 1280
reducing DNS packet size for nameserver 2606:4700:4700::1111 to 1280

+ 1 met IPv4 adres.

't zijn er 35 sinds 2022-03-17, valt mee dus, tenzij er veel vlak achter elkaar worden samengevoegd tot één melding, dan is het een ander verhaal

Wel irritant, de waarschuwingen blijven als ongelezen staan ookal heb ik ze gelezen, las net ergens dat Pi-Hole ge-herstart moet worden om ze als gelezen te markeren?

[Church of Noise]

mrdemc schreef op zaterdag 25 juni 2022 @ 22:24:
[...]


Voor het aanpassen van het hosts bestand heb je admin-rechten nodig (gelukkig), dus als je geen register aanpassingen kan doen, dan waarschijnlijk ook geen hosts wijzigingen

Dank aan beiden, en inderdaad, op de bedrijfslaptop lukt dat inderdaad niet...
Heb dus maar gewhitelist voorlopig...

[deHakkelaar]

Klippy schreef op zondag 26 juni 2022 @ 14:41:
Maar het is logisch dat grotere pakketen dan via TCP gaan, dus je hint over UDP en TCP was zeer welkom

Deze mod @yubiuser legt het veel beter uit dan ik heb gedaan:

Die Ursache ist folgendes: DNS queries werden normalerweise als UDP Pakete verschickt. Wenn diese zu groß sind, werden sie auf dem Weg vom Sender zum Empfänger an irgendeiner Stelle nicht mehr weitergeleitet bzw. beantwortet. Da UDP nicht verbindungsorientiert ist, erhält der Absender darüber keine Nachricht, sonder merkt nach einer gewissen Zeit, dass keine Antwort kam. Dann verringert er die Größe und sendet die Pakete nochmal. Darüber informiert dich dnsmasq hier, eben dass für 127.0.0.1 die max Paketgröße auf 1280 festgelegt wurde.

Prinzipiell haben größere Pakete den Vorteil, dass mehr Infos auf einmal gesendet werden können. Wenn diese dann ihr Ziel nicht erreichen und der Client wartet bis die Anfrage in den time-out läuft, dann ist das eine sehr viel langwierigere Sache, als wenn der Client gleich mehrere kleine Pakete senden würde.

https://discourse.pi-hole...t-size-meldungen/51910/21

Uiteindelijk als een antwoord of zelfs de vraag echt niet in een enkele UDP packet past, wordt deze gefragmenteerd en overgegaan op TCP.
Voor DNS maakt het namelijk niet uit ofdat je het over UDP of TCP doet behalve als te groot is voor een enkele UDP packet:

pi@ph5b:~ $ dig +short +tcp tweakers.net a
213.239.154.30

pi@ph5b:~ $ dig +short +notcp tweakers.net a
213.239.154.30

pi@ph5b:~ $ man dig
[..]
       +[no]tcp
              This  option uses [or does not use] TCP when querying name
              servers. The default behavior is to use UDP unless a  type
              any  or  ixfr=N  query is requested, in which case the de‐
              fault is TCP. AXFR queries always use TCP.

Klippy schreef op zondag 26 juni 2022 @ 14:41:
Overigens vind ik het dan wel apart dat Pihole diagnosis je kapot spamt over grotere packages maar dus niks zegt over dat de upstream DNS niet via TCP te benaderen is in dat geval.

Daar heb je wel een punt.
Maar er wordt ook vanuit gegaan dat al aan de "Prerequisites" zijn voldaan:
https://docs.pi-hole.net/main/prerequisites/#ports

Heb je mogelijk 1 of andere foute howto gevolgd?
Welke instructies/docs/tuts heb je gevolgd bij het opzetten?

[deHakkelaar]

Raven schreef op zondag 26 juni 2022 @ 15:29:
Wel irritant, de waarschuwingen blijven als ongelezen staan ookal heb ik ze gelezen, las net ergens dat Pi-Hole ge-herstart moet worden om ze als gelezen te markeren?

Je zou onderstaande kunnen proberen als het dezelfde "messages" zijn:
deHakkelaar in "[Pi-Hole] Ervaringen & discussie"

[deHakkelaar]

Church of Noise schreef op zondag 26 juni 2022 @ 15:33:
[...]

Dank aan beiden, en inderdaad, op de bedrijfslaptop lukt dat inderdaad niet...
Heb dus maar gewhitelist voorlopig...

Weet je werk wel dat er telemetrie wordt verzonden naar MS?
Aangezien:

When the policy setting is not configured, the level optional is applied.

• optional: this level configures Office to send to Microsoft “additional data that helps make product
improvements and provides enhanced information to help detect, diagnose, and remediate issues” (cit., from
the group policy setting description);

Mogelijk dat ze ea willen herzien

[Airw0lf]

deHakkelaar schreef op zondag 26 juni 2022 @ 21:12:
[...]

Deze mod @yubiuser legt het veel beter uit dan ik heb gedaan:

[...]

https://discourse.pi-hole...t-size-meldungen/51910/21

Uiteindelijk als een antwoord of zelfs de vraag echt niet in een enkele UDP packet past, wordt deze gefragmenteerd en overgegaan op TCP.
Voor DNS maakt het namelijk niet uit ofdat je het over UDP of TCP doet behalve als te groot is voor een enkele UDP packet:

pi@ph5b:~ $ dig +short +tcp tweakers.net a
213.239.154.31

pi@ph5b:~ $ dig +short +notcp tweakers.net a
213.239.154.30

Mja - ik weet niet - volgens mij maakt het wel wat uit. Alleen... de mate waarin kan nogal wat variëren door de variabelen die er allemaal in het spel zijn.

Bij UDP is er doorgaans geen foutcorrectie in de applicatie gebouwd; bij TCP is dat wel het geval. Dit wil zeggen dat als de DNS-client iets verstuurd over UDP en het pakketje raakt ergens verloren dan zal die na verloop van tijd wellicht een nieuwe poging doen - eventueel "gedwongen" door degene die achter de "knoppenbalk" zit.

Let wel - gebruikersactie kan een menselijke gebruiker zijn. Maar kan ook een IT component of een applicatie zijn.

In de duitstalige reactie wordt dit uitgelegd. Maar wordt niet gesproken over een switch van UDP naar TCP. Hoe zoiets zou moeten weet ik niet => normaliter gaat een client niet spontaan staan luisteren op een TCP-poort voor mogelijke antwoorden . Tenzij er over die poort ook een sessie-aanvraag is verstuurd.

Ik ben niet zo thuis in de werking van DNS-clients. Maar wat ik me kan voorstellen is dat als een DNS-client over UDP een antwoord krijgt waaruit blijkt dat het oorspronkelijke antwoord van de server is opgesplitst, dat de DNS-client dezelfde aanvraag nog eens gaat versturen over TCP. Hierdoor wordt er een tweede sessie opgezet waarna het antwoord wordt opgehakt in een of meer TCP-segmenten. Elk segment wordt weer opgehakt in een of meer ethernet frames .

Zijn er meerdere TCP-segmenten dan heeft de TCP-window size een stevige vinger in de pap als het gaat om de prestaties. Hoe groter de TCP-window size, hoe minder bevestigingen er over-en-weer nodig zijn . De downside is dat als er dan toch een pakketje verloren gaat, dan moet alles tot op dat moment opnieuw verstuurd worden... wat weer extra tijd kost...

[deHakkelaar]

@Airw0lf , de wiki zegt genoeg:

DNS-over-UDP/53 ("Do53")
From the time of its origin in 1983 until quite recently, DNS has primarily answered queries on User Datagram Protocol (UDP) port number 53.[3] Such queries consist of a clear-text request sent in a single UDP packet from the client, responded to with a clear-text reply sent in a single UDP packet from the server. When the length of the answer exceeds 512 bytes and both client and server support Extension Mechanisms for DNS (EDNS), larger UDP packets may be used.[37] Use of DNS-over-UDP is limited by, among other things, its lack of transport-layer encryption, authentication, reliable delivery, and message length.

DNS-over-TCP/53 ("Do53/TCP")
In 1989, RFC 1123 specified optional Transmission Control Protocol (TCP) transport for DNS queries, replies and, particularly, zone transfers. Via fragmentation of long replies, TCP allows longer responses, reliable delivery, and re-use of long-lived connections between clients and servers.

Wikipedia: Domain Name System

Hieronder zie je voor grolsch.nl recursief dat wordt overgegaan naar TCP ipv UDP (eerste keer 193.254.215.241) omdat het antwoord niet past in een enkele UDP packet (EDIT: zie ook 1208 plus 493 bytes TCP antwoorden):
deHakkelaar in "[Pi-Hole] Ervaringen & discussie"

[Airw0lf]

deHakkelaar schreef op zondag 26 juni 2022 @ 23:01:
@Airw0lf , de wiki zegt genoeg:

[...]


[...]

Wikipedia: Domain Name System

Hieronder zie je voor grolsch.nl recursief dat wordt overgegaan naar TCP ipv UDP (eerste keer 193.254.215.241) omdat het antwoord niet past in een enkele UDP packet (EDIT: zie ook 1208 plus 493 bytes TCP antwoorden):
deHakkelaar in "[Pi-Hole] Ervaringen & discussie"

Bedankt voor het uitgebreide antwoord. Enig idee hoe die omschakeling tot stand komt?
Want dat heb ik nog nergens terug kunnen vinden.

Als ik je tcpdump bekijk, dan lijkt het erop dat er in ieder geval een nieuwe sessie gestart is - het poort-nummer aan client-kant is anders.

[ Voor 8% gewijzigd door Airw0lf op 27-06-2022 06:43 ]

[deHakkelaar]

@Airw0lf , na zeker weten doe ik niet.
Ik vermoed dat als er geen UDP antwoord terug komt omdat er of iets fout gaat of omdat hij ergens op het pad naar bestemming niet doorkomt, dat dan nog een keertje hetzelfde verzoekje wordt gedaan alleen dan deze keer over TCP.
Tenminste dat is als ik de tcpdump resultaten goed interpreteer.
Hoe dan de MTU wordt bepaald weet ik ook nog niet zeker.

EDIT:

[b]NogNeetMachinaa in "[Pi-Hole] Ervaringen & discussie"NogNeetMachinaa schreef op zondag 26 juni 2022 @
Als ik je tcpdump bekijk, dan lijkt het erop dat er in ieder geval een nieuwe sessie gestart is - het poort-nummers aan client-kant is anders.

Idd dat is ook een indicatie.

[ Voor 29% gewijzigd door deHakkelaar op 26-06-2022 23:30 ]

[nero355]

Freee!! schreef op zondag 26 juni 2022 @ 14:54:
Niet het hele Docker Network, maar het is wel fijn als services zoals Pi-Hole en Unbound hun eigen IP-adres hebben, dan loop je niet te kloten met poort-mappings.

Gelukkig kan je meerdere netwerken aanmaken als ik het goed heb onthouden!

Raven schreef op zondag 26 juni 2022 @ 15:29:
Wel irritant, de waarschuwingen blijven als ongelezen staan ookal heb ik ze gelezen, las net ergens dat Pi-Hole ge-herstart moet worden om ze als gelezen te markeren?

Ik zou zweren dat ik ze allemaal kan verwijderen via de Pi-Hole webGUI tegenwoordig

Kan me herinneren dat ik een hoop meldingen naar /dev/null heb verplaatst in ieder geval VOORDAT ik met die setting in zowel Pi-Hole als Unbound aan de slag ging een paar maanden geleden

[ Voor 23% gewijzigd door nero355 op 27-06-2022 00:20 ]

[deHakkelaar]

nero355 schreef op maandag 27 juni 2022 @ 00:19:
Ik zou zweren dat ik ze allemaal kan verwijderen via de Pi-Hole webGUI tegenwoordig

Kan het niet vinden.
Wel deze:

[nero355]

deHakkelaar schreef op dinsdag 28 juni 2022 @ 00:24:
Kan het niet vinden.

Ik nu ook niet...

Lijkt een sub-menu te zijn dat alleen beschikbaar is op het moment dat er ook daadwerkelijk errors zijn

/EDIT :

Airw0lf schreef op dinsdag 28 juni 2022 @ 19:24:
Tools iets dat heet Diagnosis (is bij mij altijd aanwezig - ook zonder meldingen).
Via de rode knop met de vuilnisbak zijn ze een voor een te verwijderen.
Via het rechthoekje links kun je ze selecteren en dan met meerdere tegelijk verwijderen.

Zoiets misschien? Of is dit iets anders dan wat jullie in gedachten hebben?

http://192.168.1.2/admin/messages.php zocht ik inderdaad! Thnx!

@deHakkelaar @Raven
Daar kan je ze dus vinden!

* nero355 is soms echt vreselijk kippig als het om dingen vinden gaat...

[ Voor 56% gewijzigd door nero355 op 28-06-2022 22:39 ]

[Airw0lf]

Raven schreef op zondag 26 juni 2022 @ 15:29:

[...]

Wel irritant, de waarschuwingen blijven als ongelezen staan ookal heb ik ze gelezen, las net ergens dat Pi-Hole ge-herstart moet worden om ze als gelezen te markeren?

deHakkelaar schreef op dinsdag 28 juni 2022 @ 00:24:
[...]

Kan het niet vinden.
Wel deze:
[Afbeelding]

nero355 schreef op dinsdag 28 juni 2022 @ 14:59:
[...]

Ik nu ook niet...

Lijkt een sub-menu te zijn dat alleen beschikbaar is op het moment dat er ook daadwerkelijk errors zijn

Dat is ook zo - zij bijgevoegde afbeeldingen.

Zonder ingelogd te zijn laat het Pihole-dashboard het aantal meldingen zien.

Na login is er in tools iets dat heet diagnosis (is bij mij altijd aanwezig - ook zonder meldingen).
Via de rode knop met de vuilnisbak zijn ze een voor een te verwijderen.
Via het rechthoekje links kun je ze selecteren en dan met meerdere tegelijk verwijderen.

Zoiets misschien? Of is dit iets anders dan wat jullie in gedachten hebben?

[ Voor 10% gewijzigd door Airw0lf op 28-06-2022 19:27 ]

[deHakkelaar]

@Airw0lf , ja het wordt ook in de release notes vermeld.
Heb alleen tot nu toe nog geeneen waarschuwing gezien dus ben nog een beetje groen daarin

[Raven]

nero355 schreef op dinsdag 28 juni 2022 @ 14:59:
[...]

Ik nu ook niet...

Lijkt een sub-menu te zijn dat alleen beschikbaar is op het moment dat er ook daadwerkelijk errors zijn

/EDIT :

[...]

http://192.168.1.2/admin/messages.php zocht ik inderdaad! Thnx!

@deHakkelaar @Raven
Daar kan je ze dus vinden!

* nero355 is soms echt vreselijk kippig als het om dingen vinden gaat...

* Raven heeft ze inmiddels één voor één met dat prullenbakicoon verwijdert...

[jpgview]

een topic met daaraan gekoppeld een feature request op discourse.

Wanneer een domain in een lijst voorkomt, en dus 0.0.0.0 als reply krijgt (blocked). zijn er blijkbaar devices/apps die die query eindeloos opnieuw proberen, in de hoop een ander resultaat te bekomen.

Dit zal echter normaal gezien nooit gebeuren, pihole hanteert deze volgorde (decision tree), lees hier de comment van developer DL6ER:
0. special domains (use-application-dns.net and mask.icloud.com + mask-h2.icloud.com)
1. Exact Whitelist
2. Regex Whitelist
3. Exact Blacklist
4. Blocklist domains (AKA gravity)
5. Regex Blacklist
6. dnsmasq configuration files (/etc/dnsmasq.d/)

wanneer er een exact (1) of regex (2) whitelist match is, gaat pihole-FTL dus over op de evaluatie van de dnsmasq configuratie files (6). Hiervan kan je gebruik maken om een ander antwoord dan het blacklist (3, 4, 5) resultaat 0.0.0.0 (default blocking mode) aan het device / app te geven

Na verduidelijking van DL6ER en de use case van Anova3 lijkt er blijkbaar toch een mogelijkheid te zijn om het repetitieve gedrag van de devices/aps te beinvloeden.

Mogelijke oplossing (voorbeeld), hier, beetje ingewikkeld, maar wel haalbaar, nog een goede reden om unbound te gebruiken...

[nero355]

jpgview schreef op vrijdag 1 juli 2022 @ 23:30:
Wanneer een domain in een lijst voorkomt, en dus 0.0.0.0 als reply krijgt (blocked). zijn er blijkbaar devices/apps die die query eindeloos opnieuw proberen, in de hoop een ander resultaat te bekomen.

Na verduidelijking van DL6ER en de use case van Anova3 lijkt er blijkbaar toch een mogelijkheid te zijn om het repetitieve gedrag van de devices/aps te beinvloeden.

Mogelijke oplossing (voorbeeld), hier, beetje ingewikkeld, maar wel haalbaar, nog een goede reden om unbound te gebruiken...

Maar wat gebeurt er dan uiteindelijk effectief of beter gezegd : Wat zijn de gevolgen/het resultaat daarvan

Ik zie het daar namelijk zo gauw niet staan...

[Webgnome]

jpgview schreef op vrijdag 1 juli 2022 @ 23:30:
een topic met daaraan gekoppeld een feature request op discourse.

Wanneer een domain in een lijst voorkomt, en dus 0.0.0.0 als reply krijgt (blocked). zijn er blijkbaar devices/apps die die query eindeloos opnieuw proberen, in de hoop een ander resultaat te bekomen.

Dit zal echter normaal gezien nooit gebeuren, pihole hanteert deze volgorde (decision tree), lees hier de comment van developer DL6ER:
0. special domains (use-application-dns.net and mask.icloud.com + mask-h2.icloud.com)
1. Exact Whitelist
2. Regex Whitelist
3. Exact Blacklist
4. Blocklist domains (AKA gravity)
5. Regex Blacklist
6. dnsmasq configuration files (/etc/dnsmasq.d/)

wanneer er een exact (1) of regex (2) whitelist match is, gaat pihole-FTL dus over op de evaluatie van de dnsmasq configuratie files (6). Hiervan kan je gebruik maken om een ander antwoord dan het blacklist (3, 4, 5) resultaat 0.0.0.0 (default blocking mode) aan het device / app te geven

Na verduidelijking van DL6ER en de use case van Anova3 lijkt er blijkbaar toch een mogelijkheid te zijn om het repetitieve gedrag van de devices/aps te beinvloeden.

Mogelijke oplossing (voorbeeld), hier, beetje ingewikkeld, maar wel haalbaar, nog een goede reden om unbound te gebruiken...

Dus als ik het goed begrijp maak je voor domeinen die je hele pihole vol spammen, omdat er een programmeur zo lui is geweest om geen check toe te voegen dat wanneer je x keer niet kan verbinden er maar mee te kappen, een whitelist entry in een andere config file dan normaal? Dan kun je ze toch ook direct in de whitelist zetten? Of begrijp ik het maar half?

[jpgview]

nero355 schreef op zaterdag 2 juli 2022 @ 00:47:
Wat zijn de gevolgen/het resultaat daarvan

Webgnome schreef op zaterdag 2 juli 2022 @ 06:40:
een whitelist entry in een andere config file dan normaal? Dan kun je ze toch ook direct in de whitelist zetten? Of begrijp ik het maar half?

Het is inderdaad niet helemaal duidelijk in het topic en het feature request waarom je deze oplossing zou gebruiken.
Als je echter al wat langer pihole discourse en reddit artikels leest, zal je ongetwijfeld al een aantal topics gelezen hebben over "spam" applicaties (massa's dns queries wegens blacklisted - recent voorbeeld).
Er zijn een aantal mensen die hebben uitgezocht hoe ze dit probleem kunnen oplossen. Die oplossing is meestal: een andere query reply geven dan 0.0.0.0.

Wat de gebruiker in het topic (niet zo heel duidelijk - summary: je kan een reply voor een domain in gravity NIET wijzigen) aanklaagd is een logisch gevolg van hoe pihole werkt. Hierboven heb ik de "decision tree" (volgorde van afhandelen) opgelijst.
Voorbeelden:
- er is een exact blacklist entry match -> reply 0.0.0.0 to client && stop
- er is een gravity (lijsten) entry match -> reply 0.0.0.0 to client && stop
- er is een whitelist entry match -> pihole-FTL kijkt nu eerst of er een beschikbaar antwoord is in de dnsmasq cache. Die cache bevat ook de entries die in de dnsmasq config files werden gemaakt. matching entry? -> reply to client && stop
- er is een whitelist entry mactch -> geen match in de dnsmasq cache? -> forward to upstream (unbound in mijn config)
belangrijk hierbij is, dat in het geval van whitelist (exact en regex) matches, de blacklist (exact en regex) en gravity (resultaat van je lijsten) niet bekeken wordt en dus de reply niet beinvloeden.

Wat deze oplossing nu specifiek bied (je kan dus een reply voor een domain in gravity WEL wijzigen, mits een whitelist entry en een dnsmasq en / of unbound config file):
- normaal gedrag: app doet query voor example.domain.org, domain in gravity? -> reply is altijd 0.0.0.0, app spams pihole met DNS queries...
- deze oplossing: app doet query voor example.domain.org, domain in gravity MAAR omdat we een exact whitelist entry hebben gemaakt wordt dit nooit gechecked. Zoals hierboven beschreven, word na de whitelist match de dnsmasq cache (o.a. resultaat van de dnsmasq configuratie files) gechecked. Dit bied je dus de mogelijkheid om een ander resultaat dan 0.0.0.0 te configureren (nxdomain of IPaddress m.b.v. dnsmasq, refused m.b.v. unbound)
-> goal achieved: niet langer 0.0.0.0 als antwoord (met DNS spam door app als gevolg) maar een ander antwoord (refused, nxdomain, IPaddress). Kwestie van uit te zoeken welk antwoord nodig is om de DNS spam te doen ophouden. Zal waarschijnlijk niet voor alle apps werken, maar de voorbeelden die werden aangehaald wijzen erop dat het soms wel lukt.

edit
de eerste oplossing maakte gebruik van 2 configuratie files, één voor dnsmasq en één voor unbound, wegens de beperkingen van dnsmasq (geen reply refused mogelijk). Je kan dit ook verwezelijken met één unbound config file, zie hier. Voordeel: single point of administration EN altijd de geconfigureerde reply, ook als pihole disabled is...
/edit

[ Voor 6% gewijzigd door jpgview op 02-07-2022 10:27 ]

[nero355]

jpgview schreef op zaterdag 2 juli 2022 @ 09:04:
Als je echter al wat langer pihole discourse en reddit artikels leest, zal je ongetwijfeld al een aantal topics gelezen hebben over "spam" applicaties (massa's dns queries wegens blacklisted - recent voorbeeld).
Er zijn een aantal mensen die hebben uitgezocht hoe ze dit probleem kunnen oplossen. Die oplossing is meestal: een andere query reply geven dan 0.0.0.0.

Ja, maar daar hebben we het toevallig net al over gehad vanaf deze reactie ongeveer : Church of Noise in "[Pi-Hole] Ervaringen & discussie"

En daarom mis ik dus nog steeds een uitleg van de meerwaarde in dit hele verhaal of eigenlijk beter gezegd : Voor welke applicaties heeft dit als gevolg dat ze toch nog uiteindelijk STFU doen en niet meer je Pi-Hole Queries Log volspammen

Want zoals al eerder gezegd : Voor een heleboel dingen zal je toch echt een eigen server nodig hebben die "terugpraat" op de juiste manier om de DNS Queries op zijn minst te vertragen/minder frequent te laten optreden!

[jpgview]

nero355 schreef op vrijdag 24 juni 2022 @ 16:52:
Zie bijvoorbeeld : https://answers.microsoft...c9-46b1-b591-99e7f22cc7cb

grappig dat je dat windows voorbeeld aanhaalt, dat is exact één van de dingen die ik niet langer van de buitenwereld laat beantwoorden, wel door een file op mijn pihole (/var/www/html/ncsi.txt)

het resultaat hiervan is dat het netwerk icoon in de windows systray niet langer de status van mijn internet verbinding weergeeft, maar wel de status van lighttpd op mijn pihole.




cache wil hier zeggen: beantwoord door een dnsmasq config entry.

code:

host-record=raspberry57.localdomain,ncsi.localdomain,192.168.2.57,2a02:xxxx:yyyy:zzzz::4f5d
cname=www.msftncsi.com,ncsi.localdomain
cname=dns.msftncsi.com,ncsi.localdomain
cname=ipv6.msftncsi.com,ncsi.localdomain
cname=www.msftconnecttest.com,ncsi.localdomain
cname=ipv6.msftconnecttest.com,ncsi.localdomain

Toegegeven, je hebt het al aangehaald (verwijzing naar tweakers en discourse topic), het lukt meer niet dan wel, hoofdzakelijk omdat bijna alles https is.

De bedoeling van deze oplossing is ook niet content beschikbaar te maken, de bedoeling is een andere DNS query reply dan 0.0.0.0 te geven, in de hoop dat de app dan stopt met "spammen"

Indien je echt wil weten waarom Anova3 die specifieke antwoorden wil (refused, IP, NXDOMAIN), en wat hij daarmee hoopt / verwacht op te lossen, zal je hem de vraag op discourse moeten stellen.
Voor mij telt alleen het feit (nice to know) dat het met de huidige versie van pihole + unbound WEL mogelijk is om replies op blacklisted entries te wijzigen.

[Church of Noise]

Is er iemand die weet of er een belangrijk impact is van volgorde van de elementen in unbound.conf?

Ik heb iets vreemd voor: ik draai (zoals eerder aangegeven) een zowel Pi-Hole als Unbound in Docker containers (de redenering hierachter staat in een eerdere post).

Onlangs vroeg ik aan de persoon die de Unbound container voorziet, om ook custom config toe te laten.
Die deed dat, en plaatste een verwijzing naar een directory waar custom config files konden geplaatst worden binnen de 'server:' sectie van zijn unbound.conf. Dit werkte perfect, maar als gevolg kon je dus enkel parameters configureren die binnen de 'server:' sectie vallen.

Een nieuwe request van mijn kant om de 'include:' in het toplevel te brengen, werd ook positief beantwoord maar dan als eerste lijn in de unbound.conf file.
Gevolg is nu vreemd genoeg dat met mijn config geen rekening meer wordt gehouden.

Ik hoop Kyle Harding ('klutchell') te kunnen overtuigen van op zijn minst het verplaatsen van de include sectie naar het eind van zijn config file. Maar ik kan dus niet écht hard maken dat dat zeker gaat werken.

(fyi, het ook op Github bij zowel Unbound als de provider van de Unbound container een issue aangemaakt: https://github.com/klutchell/unbound-docker/issues/70 en https://github.com/NLnetLabs/unbound/issues/710 )

[mrdemc]

Church of Noise schreef op maandag 4 juli 2022 @ 19:43:
Is er iemand die weet of er een belangrijk impact is van volgorde van de elementen in unbound.conf?

Ik heb iets vreemd voor: ik draai (zoals eerder aangegeven) een zowel Pi-Hole als Unbound in Docker containers (de redenering hierachter staat in een eerdere post).

Onlangs vroeg ik aan de persoon die de Unbound container voorziet, om ook custom config toe te laten.
Die deed dat, en plaatste een verwijzing naar een directory waar custom config files konden geplaatst worden binnen de 'server:' sectie van zijn unbound.conf. Dit werkte perfect, maar als gevolg kon je dus enkel parameters configureren die binnen de 'server:' sectie vallen.

Een nieuwe request van mijn kant om de 'include:' in het toplevel te brengen, werd ook positief beantwoord maar dan als eerste lijn in de unbound.conf file.
Gevolg is nu vreemd genoeg dat met mijn config geen rekening meer wordt gehouden.

Ik hoop Kyle Harding ('klutchell') te kunnen overtuigen van op zijn minst het verplaatsen van de include sectie naar het eind van zijn config file. Maar ik kan dus niet écht hard maken dat dat zeker gaat werken.

(fyi, het ook op Github bij zowel Unbound als de provider van de Unbound container een issue aangemaakt: https://github.com/klutchell/unbound-docker/issues/70 en https://github.com/NLnetLabs/unbound/issues/710 )

Je zou in jouw container natuurlijk zelf de configuratie kunnen aanpassen zodat deze een andere volgorde hanteert. In dat geval merk je vanzelf of het wel/niet verschil maakt.

[jpgview]

Church of Noise schreef op maandag 4 juli 2022 @ 19:43:
Is er iemand die weet of er een belangrijk impact is van volgorde van de elementen in unbound.conf?

zelf géén docker, maar heb al wel ervaren dat sommige settings die herhaald worden alleen de laatste waarde telt en sudo /usr/sbin/unbound-checkconf hier géén aandacht aan besteed.

dus, voorbeeld:
(/etc/unbound/unbound.conf.d/01-config.conf):

code:

server:
verbosity: 1

(/etc/unbound/unbound.conf.d/02-config.conf)

code:

server:
verbosity: 2

geeft verbosity 2 als eind resultaat (checkconf -> no errors).

zelfde voor modules, je kan maar één modules config hebben, de laatste word gebruikt, waarschijnlijk (niet getest) is dat ook zo voor andere settings.

[Church of Noise]

Dank voor de antwoorden!

Ondertussen is de config aangepast en werkt het inderdaad opnieuw.

@mrdemc geen idee hoe ik dat doe, ik moet duidelijk nog veel lezen rond hoe Docker containers werken. Ik ging er van uit dat alles dat 'in' de container zit, niet kan bereikt worden.... Weer iets bijgeleerd, dank!
Ben wel blij dat de Docker container zelf nu zo is aangepast dat config van mijn kant kan zonder telkens in de container zelf te moeten gaan rommelen...

@jpgview exact, dat is ook een van de zaken die ik wilde doen (verbosity staat in de container standaard op 1, heb die terug naar 0 gebracht).

[ Voor 17% gewijzigd door Church of Noise op 04-07-2022 23:27 ]

[mrdemc]

Church of Noise schreef op maandag 4 juli 2022 @ 23:23:
Dank voor de antwoorden!

Ondertussen is de config aangepast en werkt het inderdaad opnieuw.

@mrdemc geen idee hoe ik dat doe, ik moet duidelijk nog veel lezen rond hoe Docker containers werken. Ik ging er van uit dat alles dat 'in' de container zit, niet kan bereikt worden.... Weer iets bijgeleerd, dank!
Ben wel blij dat de Docker container zelf nu zo is aangepast dat config van mijn kant kan zonder telkens in de container zelf te moeten gaan rommelen...

@jpgview exact, dat is ook een van de zaken die ik wilde doen (verbosity staat in de container standaard op 1, heb die terug naar 0 gebracht).

Daarvoor kun je https://docs.docker.com/engine/reference/commandline/exec/ gebruiken:

code:

docker exec -it <name> bash

of:

code:

docker exec -it <name> sh

Vervolgens kun je met nano of vi het bestand openen en bewerken.

Let wel: Wanneer de container opnieuw aangemaakt wordt, bijv. omdat de image geupdatet is vanuit de maker, gaan deze wijzigingen wel verloren. Alleen hetgeen je buiten de container hebt staan blijft bestaan (via een volume of host-mount)

[ Voor 10% gewijzigd door mrdemc op 05-07-2022 09:43 ]

[Church of Noise]

Exact, daarom dat het inderdaad makkelijk is dat eigen finetuning via volume of host-mount buiten de container terechtkomt en dus updates overleeft. Maar toch leuk om te weten dat er ook in een container kan getweakt worden

[mrdemc]

Church of Noise schreef op dinsdag 5 juli 2022 @ 10:08:
Exact, daarom dat het inderdaad makkelijk is dat eigen finetuning via volume of host-mount buiten de container terechtkomt en dus updates overleeft. Maar toch leuk om te weten dat er ook in een container kan getweakt worden

Ja, mijn opmerking was dan ook vooral bedoelt voor debugging voor je het ticket zou aanmaken om zeker te weten dat de gevraagde wijziging ook daadwerkelijk het gewenste effect heeft Ik doelde dan ook vooral op dit deel van jouw bericht:

Ik hoop Kyle Harding ('klutchell') te kunnen overtuigen van op zijn minst het verplaatsen van de include sectie naar het eind van zijn config file. Maar ik kan dus niet écht hard maken dat dat zeker gaat werken.

[ Voor 21% gewijzigd door mrdemc op 05-07-2022 11:18 ]

[nero355]

Church of Noise schreef op maandag 4 juli 2022 @ 19:43:
Is er iemand die weet of er een belangrijk impact is van volgorde van de elementen in unbound.conf?

Een nieuwe request van mijn kant om de 'include:' in het toplevel te brengen, werd ook positief beantwoord maar dan als eerste lijn in de unbound.conf file.
Gevolg is nu vreemd genoeg dat met mijn config geen rekening meer wordt gehouden.

Al dat afhankelijk zijn van anderen is allemaal leuk en aardig, maar uiteindelijk moet je gewoon zelf weten waar je mee bezig bent dus het eerste wat bij mij opkomt is :

Heb je https://linux.die.net/man/5/unbound.conf gelezen

Daarin staat namelijk het volgende :

File Format

There must be whitespace between keywords. Attribute keywords end with a colon ':'. An attribute is followed by its containing attributes, or a value.

Files can be included using the include: directive. It can appear anywhere, it accepts a single file name as argument. Processing continues as if the text from the included file was copied into the config file at that point. If also using chroot, using full path names for the included files works, relative pathnames for the included names work if the directory where the daemon is started equals its chroot/working directory. Wildcards can be used to include multiple files, see glob(7).

Dus weet je zeker dat je ook maar één bestand include en niet meerdere met maar één include: directive

Het lijkt misschien een tijdvretende bezigheid, maar met de documentatie lezen en nieuwe dingen uitproberen/leren kom je veel verder dan alleen maar afhankelijk zijn van zo'n "Docker Container maintainer"

Dan kom je ook dit soort dingen te weten :

mrdemc schreef op dinsdag 5 juli 2022 @ 09:42:
Daarvoor kun je https://docs.docker.com/engine/reference/commandline/exec/ gebruiken:

code:

docker exec -it <name> bash

of:

code:

docker exec -it <name> sh

Vervolgens kun je met nano of vi het bestand openen en bewerken.

Let wel: Wanneer de container opnieuw aangemaakt wordt, bijv. omdat de image geupdatet is vanuit de maker, gaan deze wijzigingen wel verloren. Alleen hetgeen je buiten de container hebt staan blijft bestaan (via een volume of host-mount)

[Church of Noise]

nero355 schreef op dinsdag 5 juli 2022 @ 15:04:
[...]

Al dat afhankelijk zijn van anderen is allemaal leuk en aardig, maar uiteindelijk moet je gewoon zelf weten waar je mee bezig bent dus het eerste wat bij mij opkomt is :

Heb je https://linux.die.net/man/5/unbound.conf gelezen

Daarin staat namelijk het volgende :

[...]

Dus weet je zeker dat je ook maar één bestand include en niet meerdere met maar één include: directive

Het lijkt misschien een tijdvretende bezigheid, maar met de documentatie lezen en nieuwe dingen uitproberen/leren kom je veel verder dan alleen maar afhankelijk zijn van zo'n "Docker Container maintainer"

Had ik gelezen, maar het bleek dat de locatie van het include statement (in dit geval na of voor de server statement met de andere parameters) wel degelijk ervoor zorgde dat het de werking ervan beinvloedde. En dat staat werkelijk nergens vermeld - vandaar mijn vraag ook aan Wouter Wijngaards. Geloof me, ik ben zeer bekend met de Unbound manpages...

En gezien ik gebruik wil maken van een bestaande Docker image (want die doet voor het merendeel van de zaken wat ik nodig heb, ik wilde enkel wat meer tweakability), is er idd een zekere afhankelijkheid.

nero355 schreef op dinsdag 5 juli 2022 @ 15:04:
[...]

Dan kom je ook dit soort dingen te weten :

[...]

Fair enough, uiteindelijk was het mijn bedoeling om het ding gewoon structureel werkend te krijgen - zonder in de container te moeten gaan rommelen. Maar ik had het inderdaad kunnen doen om mijn assumptie te valideren. (moest ik kunnen, ik gebruik geen containers, maar dat heb ik eerder al eens uitgelegd. dat verklaart misschien een beetje een onbewuste aarzeling om wat dieper te gaan in hoe het werkt)

[ Voor 5% gewijzigd door Church of Noise op 05-07-2022 16:13 ]

[deHakkelaar]

mrdemc schreef op dinsdag 5 juli 2022 @ 09:42:
Daarvoor kun je https://docs.docker.com/engine/reference/commandline/exec/ gebruiken:

code:

docker exec -it <name> bash

of:

code:

docker exec -it <name> sh

Vervolgens kun je met nano of vi het bestand openen en bewerken.

Je Docker host kan wel het vi commando beschikbaar hebben, maar deze hoeft niet ook in de Docker guest container/image aanwezig te zijn.
Je hebt een redelijk goed overzicht van de commando's beschikbaar in een container, naast diegene die al standaard in Bash zitten, met onderstaande:

code:

sudo docker exec -it <CONTAINER_NAME> ls -1 /bin /sbin /usr/bin /usr/sbin

EDIT: Als ik zo ff snel in de Pi-hole container kijk is sed beschikbaar om bv config bestanden te manipuleren.
Maar dan moet je wel met sed overweg kunnen

code:

man sed

[ Voor 10% gewijzigd door deHakkelaar op 05-07-2022 16:44 ]

[mrdemc]

deHakkelaar schreef op dinsdag 5 juli 2022 @ 16:18:
[...]

Je Docker host kan wel het vi commando beschikbaar hebben, maar deze hoeft niet ook in de Docker guest container/image aanwezig te zijn.
Je hebt een redelijk goed overzicht van de commando's beschikbaar in een container, naast diegene die al standaard in Bash zitten, met onderstaande:

code:

sudo docker exec -it <CONTAINER_NAME> ls -1 /bin /sbin /usr/bin /usr/sbin

EDIT: Als ik zo ff snel in de Pi-hole container kijk is sed beschikbaar om bv config bestanden te manipuleren.
Maar dan moet je wel met sed overweg kunnen

code:

man sed

Klopt, het ligt inderdaad aan het gebruikte basis OS welke mogelijkheden er zijn om bestanden aan te passen, en daar heb je veel mogelijkheden voor, waaronder sed.
In dit geval gebruikt de officiele pihole docker container het debian bullseye-slim image als basis. Debian gebruikt apt-get als package manager welke ook beschikbaar zou moeten zijn binnen de container, dus je kunt altijd de favoriete editor installeren met apt-get install. In het geval van een alpine image is dat dan dus apk add, fedora dnf install en bij RHEL wordt het dan yum install.

[ Voor 4% gewijzigd door mrdemc op 05-07-2022 17:13 ]

[deHakkelaar]

mrdemc schreef op dinsdag 5 juli 2022 @ 17:12:
In dit geval gebruikt de officiele pihole docker container het debian bullseye-slim image als basis.

Aha dat wist ik niet:
https://github.com/linuxcontainers/debian-slim

Ik dacht dat ze gewoon zoiets als Debootstrap zouden gebruiken om packages in een image te installeren:
https://wiki.debian.org/Debootstrap

[mrdemc]

deHakkelaar schreef op dinsdag 5 juli 2022 @ 18:54:
[...]

Aha dat wist ik niet:
https://github.com/linuxcontainers/debian-slim

Ik dacht dat ze gewoon zoiets als Debootstrap zouden gebruiken om packages in een image te installeren:
https://wiki.debian.org/Debootstrap

Dat kende ik nog niet, interessant!

Maar voor de volledigheid, dit is de base image:
https://github.com/pi-hol...r-pi-hole-base/Dockerfile
Waarop deze image wordt gebouwd:
https://github.com/pi-hol...le/blob/master/Dockerfile
Die vervolgens hier terecht komt:
https://hub.docker.com/la...1e11eeb85?context=explore

[deHakkelaar]

mrdemc schreef op dinsdag 5 juli 2022 @ 19:02:
Dat kende ik nog niet, interessant!

M'n Xen hypervisor gebruikt debootstrap om gast VM's/disk images van een Debian release te voorzien
Bedankt voor de linkjes!

[Church of Noise]

mrdemc schreef op dinsdag 5 juli 2022 @ 17:12:
[...]


Klopt, het ligt inderdaad aan het gebruikte basis OS welke mogelijkheden er zijn om bestanden aan te passen, en daar heb je veel mogelijkheden voor, waaronder sed.
In dit geval gebruikt de officiele pihole docker container het debian bullseye-slim image als basis. Debian gebruikt apt-get als package manager welke ook beschikbaar zou moeten zijn binnen de container, dus je kunt altijd de favoriete editor installeren met apt-get install. In het geval van een alpine image is dat dan dus apk add, fedora dnf install en bij RHEL wordt het dan yum install.

Ook de klutchel Unbound container gebruikt Debian bullseye-slim, dus dat is makkelijk!

[dss58]

update pihole https://discourse.pi-hole...re-v5-11-1-released/56384

[Wildfire]

dss58 schreef op donderdag 7 juli 2022 @ 21:31:
update pihole https://discourse.pi-hole...re-v5-11-1-released/56384

*poef* Pi-Hole kaduuk. Update mislukt en PiHole werkt niet meer.

Eens kijken wat daar mis is gegaan...

-- Edit: Pi-Hole was kaduuk. Moest DNS tijdelijk op een andere DNS server instellen zodat de Raspberry Pi weer DNS requests kon doen, daarna werkte de repairfunctie van PiHole weer. En nu werkt alles weer zoals het hoort, is ook up-to-date. Waarom het dan fout ging, geen idee.

[ Voor 30% gewijzigd door Wildfire op 07-07-2022 22:27 ]

[Hansie_P]

Wildfire schreef op donderdag 7 juli 2022 @ 22:18:
[...]


*poef* Pi-Hole kaduuk. Update mislukt en PiHole werkt niet meer.

Eens kijken wat daar mis is gegaan...

-- Edit: Pi-Hole was kaduuk. Moest DNS tijdelijk op een andere DNS server instellen zodat de Raspberry Pi weer DNS requests kon doen, daarna werkte de repairfunctie van PiHole weer. En nu werkt alles weer zoals het hoort, is ook up-to-date. Waarom het dan fout ging, geen idee.

Hier ook een repair moeten uitvoeren. Gelukkig valt de schade mee.

[dss58]

Wildfire schreef op donderdag 7 juli 2022 @ 22:18:
[...]


*poef* Pi-Hole kaduuk. Update mislukt en PiHole werkt niet meer.

Eens kijken wat daar mis is gegaan...

-- Edit: Pi-Hole was kaduuk. Moest DNS tijdelijk op een andere DNS server instellen zodat de Raspberry Pi weer DNS requests kon doen, daarna werkte de repairfunctie van PiHole weer. En nu werkt alles weer zoals het hoort, is ook up-to-date. Waarom het dan fout ging, geen idee.

ik heb er 2 die pihole draaien, bij de 1 no problem, bij de ander was een reboot nodig

[Church of Noise]

Er was blijkbaar een foutje ingeslopen idd, ik zie dat er hotfixes en nieuwe releases (bvb FTL 15.6.1 net en pi-hole core 5.11.3 deze nacht nog) uitkomen.

[ Voor 14% gewijzigd door Church of Noise op 08-07-2022 10:28 ]

[EverLast2002]

Hallo,

ik vraag me het volgende af (en dit kan ik vrijwel nergens terugvinden in de howto's):
je installeert pi-hole op een raspberry (of een Debian/Ubuntu vm).
Je volgt de setup instructies volgens de officiele pi-hole website.
Daarbij installeer je Unbound als recursive DNS server (127.0.0.1#5335).
En alles werkt zoals het hoort.

Maar wat vul je dan als dns-nameservers in bij "/etc/network/interfaces" en bij nameserver in "/etc/resolv.conf" van je host OS waar pi-hole op draait?
Ik vul hier bij allebei in "127.0.0.1", maar is dit wel goed?

[ed1703]

EverLast2002 schreef op vrijdag 15 juli 2022 @ 17:38:
Hallo,

ik vraag me het volgende af (en dit kan ik vrijwel nergens terugvinden in de howto's):
je installeert pi-hole op een raspberry (of een Debian/Ubuntu vm).
Je volgt de setup instructies volgens de officiele pi-hole website.
Daarbij installeer je Unbound als recursive DNS server (127.0.0.1#5335).
En alles werkt zoals het hoort.

Maar wat vul je dan als dns-nameservers in bij "/etc/network/interfaces" en bij nameserver in "/etc/resolv.conf" van je host OS waar pi-hole op draait?
Ik vul hier bij allebei in "127.0.0.1", maar is dit wel goed?

Ja, waarom zou dat niet goed zijn? Dan gaat het verkeer van je host ook via localhost door je pihole heen.

[EverLast2002]

ed1703 schreef op vrijdag 15 juli 2022 @ 17:58:
[...]

Ja, waarom zou dat niet goed zijn? Dan gaat het verkeer van je host ook via localhost door je pihole heen.

Ik vroeg mij dit af omdat wanneer ik een DNS leaktest doe, dan komt er 1 server als resultaat uit (en dat is mijn publieke IP adres)....

[Freee!!]

EverLast2002 schreef op vrijdag 15 juli 2022 @ 18:09:
[...]
Ik vroeg mij dit af omdat wanneer ik een DNS leaktest doe, dan komt er 1 server als resultaat uit (en dat is mijn publieke IP adres)....

Dat klopt, dat is het IP-adres waar die server het antwoord naar toe moet sturen, anders kun je het niet eens lezen.

[deHakkelaar]

EverLast2002 schreef op vrijdag 15 juli 2022 @ 17:38:
Maar wat vul je dan als dns-nameservers in bij "/etc/network/interfaces" en bij nameserver in "/etc/resolv.conf" van je host OS waar pi-hole op draait?
Ik vul hier bij allebei in "127.0.0.1", maar is dit wel goed?

Hangt ervanaf.

1) Voor Pi-OS/Raspbian is het ongebruikelijk om netwerk details in het interfaces of resolv.conf bestandje te configureren:
deHakkelaar in "[Pi-Hole] Ervaringen & discussie"
En andere distro's draaien mogelijk ook een network manager vergelijkbaar met dhcpcd zoals bv connman, netplan of network-manager (zie bv apt show connman).

2) Het loopback IP 127.0.0.1 configureren voor lokale DNS op de Pi-hole host zelf is af te raden omdat als Pi-hole niet meer werkt om wat voor reden dan ook, je bent aan het tweaken of een update gaat fout, dat je dan lokaal ook geen DNS meer hebt om problemen op te lossen/herstellen.
Lang geleden configureerde Pi-hole dat zelf ook tijdens installatie en was zelfs een vereiste voordat "conditional forwarding" werdt geintroduceerd.
Maar daar zijn ze vanaf gestapt en ze laten het nu aan de gebruikers over welke DNS server(s) je configureert voor lokaal.

[andregroeneveld]

Kan iemand mij helpen. Mijn pi-hole doet het niet meer na de laatste update. Ik krijg wel dit te zien:
root@raspberrypi:~# pihole -up
[✓] Update local cache of available packages
[i] Existing PHP installation detected : PHP version 7.4.28
[✓] Checking for git
[✓] Checking for iproute2
[✓] Checking for whiptail
[✓] Checking for ca-certificates

[i] Checking for updates...
error: cannot lock ref 'refs/tags/v5.11': unable to resolve reference 'refs/tags/v5.11': reference broken
error: cannot lock ref 'refs/tags/v5.11.1': unable to resolve reference 'refs/tags/v5.11.1': reference broken
error: cannot lock ref 'refs/tags/v5.11.2': unable to resolve reference 'refs/tags/v5.11.2': reference broken
error: cannot lock ref 'refs/tags/v5.11.3': unable to resolve reference 'refs/tags/v5.11.3': reference broken
error: cannot lock ref 'refs/tags/v5.11.4': unable to resolve reference 'refs/tags/v5.11.4': reference broken
[i] Pi-hole Core: up to date
[i] Web Interface: up to date
[i] FTL: up to date

[✓] Everything is up to date!
En toch zie ik bj dashboard alleen maar zandlopers lopen met de melding dat de dns server not running is.

Error
There was a problem applying your settings.
Debugging information:
PHP error (2): fsockopen(): unable to connect to 127.0.0.1:4711 (Connection refused) in /var/www/html/admin/scripts/pi-hole/php/FTL.php:44

[ Voor 8% gewijzigd door andregroeneveld op 15-07-2022 21:08 ]

[deHakkelaar]

@andregroeneveld :

https://discourse.pi-hole...-failed-to-update/52378/3

Was erg makkelijk te vinden.

[deHakkelaar]

andregroeneveld schreef op vrijdag 15 juli 2022 @ 21:07:
PHP error (2): fsockopen(): unable to connect to 127.0.0.1:4711 (Connection refused) in /var/www/html/admin/scripts/pi-hole/php/FTL.php:44

Ow en wat geeft onderstaande in een prompt?

code:

which timeout

Ivm:
https://discourse.pi-hole...hole-php-ftl-php-44/56428
https://discourse.pi-hole...on-is-not-available/56473

[ Voor 8% gewijzigd door deHakkelaar op 15-07-2022 22:37 ]

[andregroeneveld]

Voor jullie guru`s snap ik dat maar ik ben al enige tijd aan het zoeken op het forum.

[deHakkelaar]

Ben geen guru maar lees wel een boel

[andregroeneveld]

deHakkelaar schreef op vrijdag 15 juli 2022 @ 21:15:
Ben geen guru maar lees wel een boel

Jij bent echt wel een guru.

[andregroeneveld]

Maar ik kom er nog steeds niet uit hoe vaak ik het ook lees en ik wil niet al die commando`s maar dom intypen en kijken wat er gebeurd.

[andregroeneveld]

sudo rm -rf /var/www/html/admin
sudo git clone https://github.com/pi-hole/AdminLTE.git /var/www/html/admin
Then run pihole -r and choose repair.

[deHakkelaar]

Probeer exact wat in dat draadje staat!
Onderstaande verwijdert alle git referenties aanwezig ... geloof ik:

code:

sudo rm -r /etc/.pihole

Onderstaande cloned Pi-hole van Github weer naar lokaal:

code:

sudo git clone -q --depth 20 https://github.com/pi-hole/pi-hole.git /etc/.pihole

En onderstaande repareert een boel (wel repair selecteren!):

code:

pihole -r

[andregroeneveld]

deHakkelaar schreef op vrijdag 15 juli 2022 @ 21:27:
probeer exact wat in dat draadje staat!
Onderstaande verwijdert alle git referenties aanwezig ... geloof ik:

code:

sudo rm -r /etc/.pihole

Onderstaande cloned Pi-hole van Github weer naar lokaal:

code:

sudo git clone -q --depth 20 https://github.com/pi-hole/pi-hole.git /etc/.pihole

En onderstaande repareert een boel (wel repair selecteren!):

code:

pihole -r

Ben ik al mee bezig. De dood of de gladiolen.

[deHakkelaar]

andregroeneveld schreef op vrijdag 15 juli 2022 @ 21:17:
[...]

Jij bent echt wel een guru.

Meningen verschillen.
In de schaal van alles wat met IT te maken heeft weet ik maar bitter weinig

[andregroeneveld]

deHakkelaar schreef op vrijdag 15 juli 2022 @ 21:31:
[...]

Meningen verschillen.
In de schaal van alles wat met IT te maken heeft weet ik maar bitter weinig

Laat ik het dan anders formuleren.

Voor mij ben je een guru

[andregroeneveld]

Helaas nog hetzelfde.

[deHakkelaar]

Wat is nog hetzelfde?
Foutcodes voorbeelden svp?

[andregroeneveld]

There was a problem applying your settings.
Debugging information:
PHP error (2): fsockopen(): unable to connect to 127.0.0.1:4711 (Connection refused) in /var/www/html/admin/scripts/pi-hole/php/FTL.php:44

Pi-hole v5.10 · Update available! FTL v5.16.1 Web Interface v5.13
To install updates, run pihole -up. Terwijl hij zegt na de fix dat alles goed is.

[andregroeneveld]

root@raspberrypi:~# pihole -up
[✓] Update local cache of available packages
[i] Existing PHP installation detected : PHP version 7.4.28
[✓] Checking for git
[✓] Checking for iproute2
[✓] Checking for whiptail
[✓] Checking for ca-certificates

[i] Checking for updates...
error: cannot lock ref 'refs/tags/v5.11': unable to resolve reference 'refs/tags/v5.11': reference broken
error: cannot lock ref 'refs/tags/v5.11.1': unable to resolve reference 'refs/tags/v5.11.1': reference broken
error: cannot lock ref 'refs/tags/v5.11.2': unable to resolve reference 'refs/tags/v5.11.2': reference broken
error: cannot lock ref 'refs/tags/v5.11.3': unable to resolve reference 'refs/tags/v5.11.3': reference broken
error: cannot lock ref 'refs/tags/v5.11.4': unable to resolve reference 'refs/tags/v5.11.4': reference broken
[i] Pi-hole Core: up to date
[i] Web Interface: up to date
[i] FTL: up to date

[✓] Everything is up to date!

[deHakkelaar]

andregroeneveld schreef op vrijdag 15 juli 2022 @ 21:37:
PHP error (2): fsockopen(): unable to connect to 127.0.0.1:4711 (Connection refused) in /var/www/html/admin/scripts/pi-hole/php/FTL.php:44

Wat geeft onderstaande in een prompt?

code:

which timeout

Ivm:
https://discourse.pi-hole...hole-php-ftl-php-44/56428

[andregroeneveld]

deHakkelaar schreef op vrijdag 15 juli 2022 @ 21:40:
[...]

Wat geeft onderstaande in een prompt?

code:

which timeout

Ivm:
https://discourse.pi-hole...hole-php-ftl-php-44/56428

root@raspberrypi:~# which timeout
/usr/bin/timeout

[deHakkelaar]

@andregroeneveld :

code:

timeout --version

code:

pgrep pihole-FTL

code:

sudo nft -n list tables

code:

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

code:

nc -vz localhost 4711

code:

nc localhost 4711 <<< '>version >quit'

???

EDIT: Ow ps, heb je niet meer die "error: cannot lock ref" foutcodes als je pihole -up draait?

[ Voor 16% gewijzigd door deHakkelaar op 15-07-2022 21:58 ]

[andregroeneveld]

deHakkelaar schreef op vrijdag 15 juli 2022 @ 21:51:
@andregroeneveld :

code:

timeout --version

timeout (GNU coreutils) 8.32
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Padraig Brady.

code:

pgrep pihole-FTL

768

code:

sudo nft -n list tables

niets

code:

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

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 768/pihole-FTL
tcp6 0 0 ::1:4711 :::* LISTEN 768/pihole-FTL

code:

nc -vz localhost 4711

Connection to localhost (::1) 4711 port [tcp/*] succeeded!

code:

nc localhost 4711 <<< '>version >quit'

version v5.16.1
tag v5.16.1
branch master
hash 5ff5bed
date 2022-07-08 08:44:12 +0100
als je pihole -up draait?Lijkt goed te gaan en dan blijft hetzelfde na sudo reboot

[ Voor 3% gewijzigd door andregroeneveld op 15-07-2022 21:59 ]

[andregroeneveld]

En nu doet hij het weer

[ Voor 23% gewijzigd door andregroeneveld op 15-07-2022 22:02 ]

[deHakkelaar]

andregroeneveld schreef op vrijdag 15 juli 2022 @ 22:02:
En nu doet hij het weer

Ziet er goed uit:

pi@ph5b:~ $ nc localhost 4711 <<< '>version >quit'
version v5.16.1
tag v5.16.1
branch master
hash 5ff5bed
date 2022-07-08 08:44:12 +0100

[andregroeneveld]

Ik snap hier helemaal geen ene k*t van. Wat is er nu gebeurd???

[deHakkelaar]

@andregroeneveld , de git functionaliteit is weer hersteld.
Daardoor was het ook mogelijk voor repair om ea recht te zetten.

EDIT: Ow pardon, onderstaande draadje was diegene over oa timout etc:
https://discourse.pi-hole...on-is-not-available/56473

[ Voor 36% gewijzigd door deHakkelaar op 15-07-2022 22:26 ]

[andregroeneveld]

deHakkelaar schreef op vrijdag 15 juli 2022 @ 22:08:
@andregroeneveld , de git functionaliteit is weer hersteld.
Daardoor was het ook mogelijk voor repair om ea recht te zetten.

EDIT: Ow pardon, onderstaande draadje was diegene over oa timout etc:
https://discourse.pi-hole...on-is-not-available/56473

Nog steeds abracadabra maar de volgende keer als zoiets gebeurd kan ik het nu zelf proberen.

[dss58]

De laatste update van een dag of 10 terug: Pi-hole v5.11.3 FTL v5.16.1 Web Interface v5.13 is gisteren een kleine update uitgekomen naar 5.11.4, o.a. de logfiles roteerde niet meer dus ik zou zeggen hou het in de gaten, gisteren heb ik die laatste update gedraaid en vannacht keurig geroteerd

[Convoy]

dss58 schreef op zondag 17 juli 2022 @ 13:38:
De laatste update van een dag of 10 terug: Pi-hole v5.11.3 FTL v5.16.1 Web Interface v5.13 is gisteren een kleine update uitgekomen naar 5.11.4, o.a. de logfiles roteerde niet meer dus ik zou zeggen hou het in de gaten, gisteren heb ik die laatste update gedraaid en vannacht keurig geroteerd

7dgn geleden

https://github.com/pi-hole/pi-hole/releases

[dss58]

Convoy schreef op zondag 17 juli 2022 @ 14:10:
[...]


7dgn geleden

https://github.com/pi-hole/pi-hole/releases

tnx, ik zie het ja, ik hou het altijd goed in de gaten maar zo snel naar 5.11.4 was me compleet ontgaan en ik vermoed dat ik de enige niet ben

[Cranzai]

Binnenkort ga ik verhuizen en zal ik mijn netwerken weer opnieuw moeten opzetten.

Op het moment speel ik met het volgende idee, ik wil een eigen router aan de algemene WiFi hangen om mijn eigen sub-netwerkje te maken.

Begrijp ik het goed dat Pi-Hole geen port-forwarding heeft en dus ook binnen dit netwerkje zou kunnen draaien? Betekend geen port-forwarding direct ook veilig gebruik of is het nog steeds mogelijk om de Pi dan van buitenaf te bereiken?

(Een aantal jaar geleden als jochie voor de grap PiHole geïnstalleerd maar toen toch een breach gehad zeg maar...)

[W1ck1e]

@Cranzai Pi-hole heeft geen portforwarding NODIG. En is prima te draaien binnen een eigen netwerk. En doet dns voor je apparatuur in je eigen netwerk.
Als je middels een eigen vpn server in je eigen netwerk je vpn clients gebruikl wil laten maken van je pihole dan heb je voor je pihole geen portforwarding nodig (wel voor je vpn server). Zonder vpn server je pihole aanbieden voor buiten je eigen netwerk kan in principe niet zonder portforwarding maar is niet aan te raden.

[Airw0lf]

Cranzai schreef op zondag 17 juli 2022 @ 21:17:

Op het moment speel ik met het volgende idee, ik wil een eigen router aan de algemene WiFi hangen om mijn eigen sub-netwerkje te maken.

Begrijp ik het goed dat Pi-Hole geen port-forwarding heeft en dus ook binnen dit netwerkje zou kunnen draaien? Betekend geen port-forwarding direct ook veilig gebruik of is het nog steeds mogelijk om de Pi dan van buitenaf te bereiken?

De primaire functie van PiHole is advertenties blokkeren door DNS-aanvragen af te vangen. Daarnaast is het te gebruiken als DHCP-server. Beiden functioneren prima in een eigen LAN.

Ik zou PiHole niet inzetten als router/firewall - daar zijn andere apparaten voor bedoeld.

Inzake veilig gebruik en portforwarding:
Mocht je ergens een router/firewall hebben zitten die portforwarding heeft aan staan en daarbij wijst naar jouw PiHole server, dan istie via internet toegankelijk!

Ik ken je nieuwe situatie niet. Maar een eigen router via een (bridged?) wifi voor PiHole?
Kijk eens of het mogelijk is om je eigen router bekabeld aan te sluiten.
Om vervolgens vanaf dat punt te gaan werken met een PiHole servertje.

[nero355]

Cranzai schreef op zondag 17 juli 2022 @ 21:17:
Op het moment speel ik met het volgende idee, ik wil een eigen router aan de algemene WiFi hangen om mijn eigen sub-netwerkje te maken.

Begrijp ik het goed dat Pi-Hole geen port-forwarding heeft en dus ook binnen dit netwerkje zou kunnen draaien?

Je kan gewoon NAT achter NAT draaien en dan Pi-Hole in het Primaire LAN laten draaien die daardoor vervolgens ook vanuit het Secundaire LAN bereikbaar is als DNS Server

Net of je de Google DNS Server op je eigen PC instelt zeg maar!

Mocht je heel avontuurlijk ingesteld zijn dan kan je zelfs een Raspberry Pi bouwen die :
- WiFi Client kan spelen van een netwerk.
- Zelf voor NAT Router speelt via de WiFi verbinding die als WAN verbinding wordt gebruikt.
- Daarbij dus ook een Firewall en DHCP Server draait.
- En uiteraard ook advertenties filtert!

Betekend geen port-forwarding direct ook veilig gebruik of is het nog steeds mogelijk om de Pi dan van buitenaf te bereiken?

Een Pi-Hole installatie zal zelfs geen uPnP Port Forward actie triggeren dus zolang je het zelf niet verprutst komt het wel goed!

[deHakkelaar]

Cranzai schreef op zondag 17 juli 2022 @ 21:17:
Op het moment speel ik met het volgende idee, ik wil een eigen router aan de algemene WiFi hangen om mijn eigen sub-netwerkje te maken.

nero355 schreef op zondag 17 juli 2022 @ 23:32:
Mocht je heel avontuurlijk ingesteld zijn dan kan je zelfs een Raspberry Pi bouwen die :
- WiFi Client kan spelen van een netwerk.
- Zelf voor NAT Router speelt via de WiFi verbinding die als WAN verbinding wordt gebruikt.
- Daarbij dus ook een Firewall en DHCP Server draait.
- En uiteraard ook advertenties filtert!

Je kunt elk Linux apparaat met twee interfaces gemakkelijk omtoveren in een IPv4 router/gateway.
Daarvoor heb je maar twee dingen nodig.

1) Eerst flip je IP forwarding aan:

code:

sudo sysctl net.ipv4.ip_forward=1

Die maak je reboot persistent met een nieuw config bestandje:

code:

sudo tee /etc/sysctl.d/ip-forwarding.conf <<< 'net.ipv4.ip_forward=1'

2) Alles masqueraden wat naar buiten gaat over de <WAN_INTERFACE_NAME>:

code:

sudo iptables -t nat -A POSTROUTING -o <WAN_INTERFACE_NAME> -j MASQUERADE

* iptables kun je installeren met sudo apt install iptables en mogelijk kun je het ook met nft (zie man nft) maar weet syntax niet.

En ook deze reboot persistent maken:

code:

sudo netfilter-persistent save

* netfilter-persistent kun je installeren met sudo apt install netfilter-persistent

DNS/Pi-hole met z'n eigen DHCP service kun je er naast draaien.
Ook zou ik een firewall adviseren om ea dicht te timmeren zoals oa SSH en mogelijk DHCP voor WAN!!!

EDIT: Ow ik gebruik nog steeds fwbuilder om ingewikkelde firewall en NAT regels op te zetten al istie al lang niet meer in ontwikkeling.
Maar wel nog steeds als package beschikbaar:

pi@ph5b:~ $ apt show fwbuilder
[..]
Description: Firewall administration tool GUI
 Firewall Builder consists of an object-oriented GUI and a set of policy
 compilers for various firewall platforms. In Firewall Builder, firewall
 policy is a set of rules, each rule consists of abstract objects which
 represent real network objects and services (hosts, routers, firewalls,
 networks, protocols). Firewall Builder helps the user maintain a database
 of objects and allows policy editing using simple drag-and-drop operations.
 .
 This is the GUI part of fwbuilder

http://fwbuilder.sourceforge.net/4.0/how_it_works.shtml

Deze draait op m'n desktop/laptop PC en kan dan de aangemaakte firewall/NAT regels distribueren via SSH naar de doel systemen waar meestal een grafische desktop ontbreekt.
En er is zelfs een Windhoos versie beschikbaar

[ Voor 22% gewijzigd door deHakkelaar op 18-07-2022 03:03 ]

[andregroeneveld]

En dan zeggen dat hij geen guru is. Moet je zien wat hij even uit z'n mouw tovert.

Allemaal guru`s hier behalve ik

[ Voor 19% gewijzigd door andregroeneveld op 18-07-2022 06:53 ]

[W1ck1e]

andregroeneveld schreef op maandag 18 juli 2022 @ 06:52:
...Allemaal guru`s hier behalve ik

Hoe denk je dat die begonnen zijn ?

[ed1703]

andregroeneveld schreef op maandag 18 juli 2022 @ 06:52:
En dan zeggen dat hij geen guru is. Moet je zien wat hij even uit z'n mouw tovert.

Allemaal guru`s hier behalve ik

Weet niet hoor, maar door elke dag hier mee te lezen en dingen met linux of Pi-hole in het bijzonder te doen ga je vanzelf een specialist worden (gaat nog redelijk vanzelf ook als je het dagelijks doet)

[Cranzai]

Airw0lf schreef op zondag 17 juli 2022 @ 23:03:
[...]


De primaire functie van PiHole is advertenties blokkeren door DNS-aanvragen af te vangen. Daarnaast is het te gebruiken als DHCP-server. Beiden functioneren prima in een eigen LAN.

Ik zou PiHole niet inzetten als router/firewall - daar zijn andere apparaten voor bedoeld.

Inzake veilig gebruik en portforwarding:
Mocht je ergens een router/firewall hebben zitten die portforwarding heeft aan staan en daarbij wijst naar jouw PiHole server, dan istie via internet toegankelijk!

Ik ken je nieuwe situatie niet. Maar een eigen router via een (bridged?) wifi voor PiHole?
Kijk eens of het mogelijk is om je eigen router bekabeld aan te sluiten.
Om vervolgens vanaf dat punt de gaan werken met een PiHole servertje.

De PiHole als router/firewall was ik ook zeker niet van plan inderdaad. Mijn geheugen laat me in de steek maar ik geloof dat ik toen ook mijn eerste LAMP webservertje op die Pi had draaien en daar toen PiHole bij op had gezet. Toen zal er dus wel een poort open geweest zijn... Toen op mijn desktop de muis ineens begon te bewegen, en icoontjes verdwenen, heb ik maar snel het internet uitgezet

De nieuwe situatie zal een gedeeld huis zijn met een gezamenlijke internet-verbinding. "Wi-Fi" was misschien wat algemeen omschreven maar ik was wel van plan voor bekabeld te gaan wanneer mogelijk inderdaad. Daar dan de PiHole aanhangen moet lukken zonder veiligheidsissues

[W1ck1e]

Cranzai schreef op maandag 18 juli 2022 @ 08:27:
[...]


De PiHole als router/firewall was ik ook zeker niet van plan inderdaad. Mijn geheugen laat me in de steek maar ik geloof dat ik toen ook mijn eerste LAMP webservertje op die Pi had draaien en daar toen PiHole bij op had gezet. Toen zal er dus wel een poort open geweest zijn... Toen op mijn desktop de muis ineens begon te bewegen, en icoontjes verdwenen, heb ik maar snel het internet uitgezet

De nieuwe situatie zal een gedeeld huis zijn met een gezamenlijke internet-verbinding. "Wi-Fi" was misschien wat algemeen omschreven maar ik was wel van plan voor bekabeld te gaan wanneer mogelijk inderdaad. Daar dan de PiHole aanhangen moet lukken zonder veiligheidsissues

Indien je niet iedereen waarmee je de internet verbinding deelt vertrouwt kan ik je aanraden om een eigen router aan de internet verbinding te hangen en je eigen spullen inclusief de pihole aan die eigen router. Liefst bedraad, anders via wifi. Je wifi gegevens niet delen. De anderen kunnen dan niet aan jouw lan door de nat functie van je router (ook een beetje een firewall) Dan moet jouw router wel in een ruimte staan waar de anderen geen kabels kunnen aansluiten op jouw router.

[Cranzai]

W1ck1e schreef op maandag 18 juli 2022 @ 08:46:
[...]
Indien je niet iedereen waarmee je de internet verbinding deelt vertrouwt kan ik je aanraden om een eigen router aan de internet verbinding te hangen en je eigen spullen inclusief de pihole aan die eigen router. Liefst bedraad, anders via wifi. Je wifi gegevens niet delen. De anderen kunnen dan niet aan jouw lan door de nat functie van je router (ook een beetje een firewall) Dan moet jouw router wel in een ruimte staan waar de anderen geen kabels kunnen aansluiten op jouw router.

Niet zozeer een kwestie van geen vertrouwen, meer een verlangen van mijn kant e.e.a. op te zetten en de rest daar niet mee te willen belasten

Heb een heel schappelijke huisbaas getroffen dus dan hou ik graag alles netjes, inclusief de gedeelde internetconnectie.